Книжку Лісл Кларк і Ребекка Рокефеллер — Не купуй нічого, май усе

Ботсвана, Сінегал, Кенія, Мозамбік змогли налагодити повноцінний paypal — і ми зможемо. Колись. Мабуть )))

Ні, люблю читати різні наукові статі.

Наявна наукова кореляція між високим інтелектом батьків (особливо у технічних професіях) та підвищеним ризиком народження дитини з аутизмом. Дослідження показують, що діти батьків з високим IQ або схильністю до систематизації (інженери, програмісти, науковці тощо) мають вищу ймовірність аутизму. Наприклад, у місті Ейндховен (центр IT-індустрії в Нідерландах) рівень аутизму був удвічі вищим, ніж у містах без такої концентрації технічних спеціалістів. Аналогічний зв’язок доведено в Кремнієвій долині США.​

Причинами є генетична схожість між здатністю до систематизації та ризиком аутизму, а також явище асортативного добору, коли люди з подібними когнітивними якостями обирають одне одного в пару. Згідно з теорією Барон-Коена, аутизм часто поєднується з сильними навичками аналізу систем та механізмів, що є ключовим для технічних професій.​

Важливо пам’ятати: хоча відносний ризик зростає, абсолютний ризик для більшості сімей залишається низьким (1-2%). Кореляція не означає пряму причину, але відображає загальні генетичні та когнітивні чинники.​

Основні джерела:

— pubmed.ncbi.nlm.nih.gov/31026573 (відношення IQ батька і аутизму)​
— www.scientificamerican.com/...​to-have-kids-with-autism (зв’язок технічних професій і аутизму)​
— www.autismresearchcentre.com/...​-stem-regions-and-autism (Ейндховенське дослідження)​
— pmc.ncbi.nlm.nih.gov/articles/PMC4927579 (генетика, систематизація та аутизм)​
— pubmed.ncbi.nlm.nih.gov/31200929 (асортативний добір у аутизмі)​
— docs.autismresearchcentre.com/papers/2009_BC_nyas.pdf (теорія емпатії-систематизації)​

У батьків Айтішніків високий ризик народження дитини-аутіста. Отаке от.

Дитячий садок якийсь.

Наведіть приклад наративу де бот не справився. А ось що каже бот на ваше повідомлення: У тексті простежується упередження негативу — схильність акцентувати увагу на недоліках і недооцінювати потенційні переваги чи цінність системи. Схоже бот має якусь цінність.

А є бот, який буде перевіряти відповіді цього бота?

1. Гадаю що ми ще далеко не на вершині розвитку ШІ, а це значить що ще є купа часу для адаптації, технології розвиваються ривками.

2. Ми ще не бачимо які нові потреби породить розвиток ШІ, коли з коней пересіли на трактори, ніхто й гадки не мав що потрібні будуть спеціалісти по встановленню конденціонерів у трактори.

3. Впровадження ШІ буде вимагати спеціалістів з широкими знаннями, щоб узгодити роботу зоопарку ШІ.

4. Різкий ривок впровадження ШІ, може викликати соціальний спротив. Протести сценаристів у Голівуді. Тому знову ж таки для балансу системи — все буде розвиватися поступово і буде час на адаптацію.

5. Завжди можна буде повісити на стовпі об`яву — відремонтую ваш домашній ШІ. Для пенсіонерів знижки.

Для тих кому потрібен справжній челендж (у .md форматі)

Деталізований шеститижневий план без прив’язки до календарних дат. Бюджет часу на день: **3,5 години** (60 хв теорія, 120 хв задачі, 30 хв проговорювання). Тиждень = 7 днів без «обов’язкових» вихідних, але ви можете перерозподілити дні 7/14/21/28/35/42 як полегшені.

**Ритм дня (рекомендація):**

— **Теорія — 60 хв**: сфокусоване читання/конспект (одне джерело + систематизація).
— **Практика — 120 хв**: 3–5 задач/міні-імплементацій за темою дня + короткий код-рев’ю самого себе.
— **Проговорювання — 30 хв**: пояснення теми «інженеру-колезі» за структурою: Контекст → Механізм → Трейд-офи → Приклади → Підводні камені.

---
### Тиждень 1 — JavaScript: область видимості, замикання, прототипи, event loop

**День 1**
— Теорія (60): Лексичне оточення, область видимості, замикання.
— Практика (120): once, memoize, лічильник із приватним станом; аналіз витоків через замикання.
— Проговорювання (30): «Що таке замикання і чим воно корисне/небезпечне?»

**День 2**
— Теорія: Hoisting, TDZ, var/let/const.
— Практика: Реалізація simple module pattern; кейси з TDZ.
— Проговорювання: «Hoisting без магії — пояснення на псевдокоді компонування.»

**День 3**
— Теорія: Прототипи, [[Prototype]] vs prototype, ланцюг.
— Практика: Найпростіше прототипне наслідування; ручна реалізація new.
— Проговорювання: «Прототипи vs класи — що під капотом?»

**День 4**
— Теорія: this, call/apply/bind; лексичний this у стрілкових функціях.
— Практика: Поліфіл Function.prototype.bind; кейси втрати контексту.
— Проговорювання: «Як я обираю спосіб прив’язки контексту в проді?»

**День 5**
— Теорія: Event loop, стек/черги, microtask vs macrotask.
— Практика: Трасування послідовності log’ів; Promise vs setTimeout гонки.
— Проговорювання: Покроково описати кадр event loop.

**День 6**
— Теорія: Проміси: стани, ланцюги, обробка помилок.
— Практика: Реалізація маленького promise-like; all/race підкапотна логіка.
— Проговорювання: «Типові антипатерни з промісами.»

**День 7**
— Теорія: Рефреш тижня (короткий огляд).
— Практика: Змішані задачі на замикання/прототипи/event loop.
— Проговорювання: 15-хв «міні-лекція» + 15-хв відповіді на «провокаційні» питання.

---
### Тиждень 2 — JavaScript: async/await, генератори, модулі, продуктивність

**День 8**
— Теорія: async/await, обробка помилок, паралелізм vs послідовність.
— Практика: Рефактор ланцюгів промісів в async/await; обмеження конкуренції (пул).
— Проговорювання: «Де async/await гірші за проміси?»

**День 9**
— Теорія: Ітератори й генератори; протокол Iterable.
— Практика: Власний ітератор; генератор для лінивих послідовностей.
— Проговорювання: «Де генератори спрощують код?»

**День 10**
— Теорія: ESM vs CJS, імпорти/експорти, tree-shaking принципи.
— Практика: Міні-проєкт із ESM, динамічний import().
— Проговорювання: «Чому інколи treeshaking не спрацьовує?»

**День 11**
— Теорія: Типізація мислення: контракти, runtime-валідація, JSDoc як мінімум.
— Практика: Легка runtime-валідація вхідних даних без бібліотек.
— Проговорювання: «Де статична типізація економить час?»

**День 12**
— Теорія: Пам’ять, збирач сміття, профілювання.
— Практика: Пошук витоків: замикання, таймери, посилання в кеші.
— Проговорювання: «Як доводжу відсутність витоку?»

**День 13**
— Теорія: Базові патерни JS (Module, Factory, Pub/Sub).
— Практика: Подієва шина; розділення модулів.
— Проговорювання: «Коли Pub/Sub шкідливий?»

**День 14**
— Теорія: Збірний огляд.
— Практика: Композитна задача на async + структури.
— Проговорювання: 30-хв міні-мок за темою 1–2 тижнів.

---
### Тиждень 3 — React-патерни: hooks, context, state management трейд-офи

**День 15**
— Теорія: Правила хуків, рендер-цикл, ефекти, фази.
— Практика: usePrevious/useEvent, контроль залежностей ефекту.
— Проговорювання: «Навіщо хуки й як не порушувати інваріанти?»

**День 16**
— Теорія: Колокація стану, підйом/спуск, проп-дрилінг.
— Практика: Рефактор todolist: локальний vs піднятий стан.
— Проговорювання: «Як вирішую конфлікт колокації vs повторного використання?»

**День 17**
— Теорія: Context: сегментація, селектори контексту, продуктивність.
— Практика: Багаторівнева тема з кількома контекстами.
— Проговорювання: «Чому ‘все в контекст’ — погано?»

**День 18**
— Теорія: useReducer, кінцеві автомати, композиція reducer’ів.
— Практика: Складний екран із ред’юсером + контекст.
— Проговорювання: «Reducer vs локальний state.»

**День 19**
— Теорія: Продуктивність: мемоізація, ключі, списки, звірка.
— Практика: Виміряти/знизити зайві рендери; профайлинг.
— Проговорювання: «useMemo/useCallback — коли це шкода?»

**День 20**
— Теорія: Server state vs client state; кешування клієнтських запитів; стратегії інвалідації.
— Практика: Власний простий кеш фетчів із TTL і дедуплікацією.
— Проговорювання: «Коли обирати бібліотеку керування серверним стейтом.»

**День 21**
— Теорія: Тестування компонентної логіки (React Testing Library — концептуально).
— Практика: Набір unit-тестів на хуки/ред’юсери (без фреймворків, псевдо-асерти).
— Проговорювання: «Піраміда тестів у UI.»

---
### Тиждень 4 — CSS-архітектура: BEM, pragmatic/utility-first, responsive systems

**День 22**
— Теорія: BEM: неймінг, рівні, модифікатори.
— Практика: Рефактор стилів екрана в BEM.
— Проговорювання: «BEM як договір, а не релігія.»

**День 23**
— Теорія: Шарові підходи (ITCSS/CUBE CSS), специфічність.
— Практика: Розкласти стилі по шарах, знизити специфічність.
— Проговорювання: «Чому каскад — це інструмент?»

**День 24**
— Теорія: Pragmatic/utility-first (утилітарні токени), trade-offs vs BEM.
— Практика: Набір утилітних класів (spacing/typography).
— Проговорювання: «Межі утилітарного підходу.»

**День 25**
— Теорія: Responsive: контейнерні запити, fluid-типографіка, гріди.
— Практика: Сітка з авто-адаптацією без медіа-виразів.
— Проговорювання: «Чому контейнерні запити часто кращі за брейкпоінти?»

**День 26**
— Теорія: Дизайн-токени: CSS custom properties, теми.
— Практика: Темізація (light/dark/high-contrast).
— Проговорювання: «Як вводити токени без ламальних релізів.»

**День 27**
— Теорія: Інкапсуляція стилів: CSS Modules/CSS-in-JS trade-offs.
— Практика: Маленька вітрина компонентів із трьома варіантами стилізації.
— Проговорювання: «Ціна рантайм-стилів.»

**День 28**
— Теорія: Продуктивність CSS і a11y (фокус, контраст, prefers-reduced-motion).
— Практика: Аудит специфічності, видалення мертвих стилів.
— Проговорювання: «Як аргументую доступність бізнесу.»

---
### Тиждень 5 — Системний дизайн фронтенду: масштабування, кешування, продуктивність

**День 29**
— Теорія: Межі компонентів/фіч, файлова архітектура, dependency graph.
— Практика: Арх-скелет із явними шарами (entities/features/ui).
— Проговорювання: «Як масштабуємо команди й модулі.»

**День 30**
— Теорія: Бандлінг, код-спліттінг, маршрутизація на чанках.
— Практика: Сценарії поділу: за маршрутами, за фічами, за критичністю.
— Проговорювання: «Критерії спліттінгу.»

**День 31**
— Теорія: HTTP-кеш: Cache-Control, ETag, SW; варіанти інвалідації.
— Практика: Розрахунок TTL, схеми версіонування асетів.
— Проговорювання: «Де кеш небезпечний?»

**День 32**
— Теорія: Web Vitals (LCP, CLS, INP), TTI/TTFB; критичний шлях рендерингу.
— Практика: Декомпозиція LCP; lazy/hint/preload.
— Проговорювання: «Як пріоритезую оптимізації.»

**День 33**
— Теорія: Пагінація/інфініт-скрол, backpressure, скасування запитів.
— Практика: Демонстрація батчингу й скасування (AbortController).
— Проговорювання: «Вибір стратегії під навантаження.»

**День 34**
— Теорія: SSR/SSG/ISR/edge; гідрація; частковий рендер.
— Практика: Проєктування рендер-стратегії для сторінки каталогу.
— Проговорювання: «Компроміси SSR vs CSR.»

**День 35**
— Теорія: Безпека: XSS, CSP, CORS, залежні вразливості.
— Практика: Впровадження CSP, санітайзинг, audit deps.
— Проговорювання: «Як пояснити ризик XSS менеджеру.»

---
### Тиждень 6 — Мок-інтерв’ю через день (36, 38, 40, 42)

**День 36 (мок-день)**
— Теорія (60): Розбір слабких місць тижнів 1–2.
— Практика (120): Мок-інтерв’ю 60 + 60 таргет-вправи за фідбеком.
— Проговорювання (30): Ретроспектива відповідей, покращення формулювань.

**День 37**
— Теорія: Оновлення шпаргалок по глибоких темах JS.
— Практика: 120 хв задач на слабкі теми.
— Проговорювання: «Топ-3 інсайти з мока.»

**День 38 (мок-день)**
— Теорія: React-патерни.
— Практика: Мок 60 + 60 targeted React perf/state.
— Проговорювання: «Аргументація трейд-офів.»

**День 39**
— Теорія: CSS-архітектура, доступність.
— Практика: 120 хв задач/рефактор стилів.
— Проговорювання: «Домовленості в команді.»

**День 40 (мок-день)**
— Теорія: Системний дизайн фронтенду.
— Практика: Мок 60 + 60 кейси кеш/рендер/архітектура.
— Проговорювання: «Діаграми за 3 хвилини.»

**День 41**
— Теорія: Підсумковий огляд + поведінкові питання.
— Практика: Сесія «rapid fire» по всіх темах.
— Проговорювання: 30 хв «фінальна презентація про себе».

**День 42 (фінальний мок-день)**
— Теорія: Легкий розігрів (флеш-карти).
— Практика: Фінальний мок 60 + 60 усунення останніх прогалин.
— Проговорювання: «Плани на перші 90 днів на новій роботі.»

---
### Метрики та артефакти (щоденно):

— 1–2 сторінки конспекту за темою дня; 1 мікропроєкт або набір задач; 1 аудіо/відео 5–10 хв із поясненням.
— Раз на тиждень: 1 сторінка «роз’яснювального документа» (ADR-стиль) по складній темі.

Можна.

Слухаю дінаміки на навколишне середовище

Порада тим Хто ще не купив а думає. Тре брати 100w від того ж Baseus. Там всьо норм з температурою на таких потужностях.

А де запобіжник?

Для ноута треба Банку сили щонайменше 65W + має бути підтримка PD 20V/3A по type-c выходу. З високою ймовірністю перехідники з вашого посилання запрацють, але кабель має бути теж не менше 60W, бажано 100W. Також цей перехідник зможе живити ноут від адаптера накшталт BASEUS 65W. Власне собі так і зробив сховавши рідний БП десь на чорний день.

Воу воу полехчи. Бизнес думает о людях?

15%? не бояться потерять? Да когда принимают бюджет там идет грызня за каждый процент. Что бы было понятней, это тоже самое что от твоего тела отпилить 15% — тебе это понравится? :))))

Слабые разработчики им пользоваться не смогут.
Сильные не захотят.
Все таки, для кого же он?

Все актуально, что может прилизить цель. Другой вопрос как пользоваться этим инструментом.
Фишка в том, что если люди подходят друг другу — то хоть супа-спид дейтинг, у них все будет ок.
Если не подходят — хоть год встречайтесь, результат будет никудашний.

Краще Баеры 770, вони не будуть заважати оточуючим.