Airbnb опублікували статтю про міграцію ~3500 тестів з Enzyme на React Testing Library за допомогою LLM. Ручна міграція зайняла б півтора року, автоматизація скоротила її до шести тижнів.

Це вражає 🤯, адже Enzyme і RTL мають різну структуру та філософію тестування.

Якщо коротко, Airbnb використали LLM у циклічному процесі:
1️⃣ Виконувалась міграція
2️⃣ Система сама себе валідувала
3️⃣ LLM виправляв знайдені помилки

Цікава ідея, і, схоже, добре спрацювала. Хоча я трохи менше довіряв би таким тестам 🤔.

З власного досвіду: ми теж інколи використовуємо LLM для рефакторингу, зокрема з jscodeshift.

Наприклад, якщо потрібно перенести імпорти, які були локальними, але код мігрував у пакет 📦. Простий пошук не допоможе, бо імпорти можуть бути розбиті між файлами. А jscodeshift усе правильно оновить.

Користуєтесь Storybook? Я — так! 🎨📖

У нас на проєкті багато тестів безпосередньо в Storybook. Там використовується та сама React Testing Library, але тести виконуються всередині сторі з візуальним відображенням.

Ці тести ми також запускаємо в CI, щоб відловити регресії 🐛. Проте чим їх більше, тим важче запускати, бо CI використовує headless-браузер (без інтерфейсу). Навантаження накопичується, і деякі тести починають падати через нестачу ресурсів.

Рішення? Я підглянув його в Playwright, який Storybook використовує під капотом. Тести можна розбивати на шарди (shards) й запускати кілька CI-процесів для рівномірного розподілу навантаження ⚡.

У підсумку всі тести, які запускалися разом, тепер розбиваються на N шардів і виконуються паралельно.

Рішення просте й зручне, але трохи дорожче, якщо не кешувати артефакти типу node_modules 📦.

Чули про перцептрон? 🤖 Якщо цікавитесь машинним навчанням та AI, то, можливо, вже зустрічалися з цим поняттям.

У цьому відео автор детально пояснює технічні досягнення Френка Розенблата (батьки — мігранти-євреї з Хмельницької області) та їхній вплив на розвиток AI сьогодні.

Відео англійською, без авто-перекладу, але автор говорить чітко та зрозуміло, тож, сподіваюся, проблем із переглядом не буде. 🎥

https://www.youtube.com/watch?v=l-9ALe3U-Fg

Часто помічаю, як новачки встановлюють пакети для дуже дрібних задач. Напевно, найпопулярніше — це генератори для унікальних ідентифікаторів, особливо коли висока унікальність взагалі не потрібна (типу uuid).

Для таких потреб значно краще і зручніше використовувати вже наявні інструменти:

const randomId = (length = 6) => {
  return Math.random()
    .toString(36)
    .substring(2, length+2);
};

Ось проста функція для генерації коротких, унікальних ID, цілком достатня для індентифікаторів даних (до кілька-десят тисяч, але не мільйонів) записів.

Код скопіював не з голови а взяв тут.

Поділюсь цікавим подкастом, але спершу трохи лірики.

Для досвідчених розробників — пам’ятаєте Atom? Едітор, що передував VSCode. Саме завдяки ньому з’явився Electron, який зараз використовують Notion, Slack, VSCode, Linear та багато інших.

У цьому подкасті один із core-розробників Zed (про який я вже писав) розповідає цю історію та як вона вплинула на їхній новий, сучасний продукт.

🎧 Ідеально для вечірнього прослуховування на фоні — так я і зробив учора. 😌

https://www.youtube.com/watch?v=HJTVwNZ_fQM

Років два тому мав інтерв’ю з компанією, яка хотіла повторити, наскільки швидко й приємно працює Notion, але для іншого бізнесу.

Було кілька раундів, і на одному з них мені потрібно було підготувати прикладний та детальний підхід до організації такої системи. Завдання не з простих — Notion унікальний, і його важко не просто повторити, а й переосмислити. Але одна їхня стаття допомогла мені краще підготуватись, тож вирішив поділитися.

До речі, зайшов подивитися на їхній продукт — на жаль, нічого з того, що планували, не реалізували, але суттєво підсіли на GraphQL (що було частиною моєї рекомендації, виходячи з їхньої архітектури). 😅

https://www.notion.com/blog/data-model-behind-notion

Сьогодні знову трохи відійду від веб розробки й повернусь до embedded.

Хто пробував Arduino, той, напевно, знайомий з Arduino IDE. Для мінімальних задач вистачає, але, якщо чесно, це жахливо незручно. 😅

Альтернатива? PlatformIO — популярний, безкоштовний та відкритий інструмент. І найцікавіше: це український продукт! 🇺🇦

PlatformIO інтегрується у VSCode та суттєво спрощує роботу:
✅ Менеджер залежностей (як npm для Node.js)
✅ Юніт-тести
✅ Дебаггер (на реальному пристрої)
✅ Багато іншого

З власного досвіду — після Arduino IDE це просто кайф! Постійно користуюсь і вам рекомендую. 🚀

https://platformio.org/

Раз вже сьогодні почав про embedded, поділюсь ще одним цікавим контентом.

Rust набирає популярності, хоча C++-скептики з цим миритись не поспішають. 😅
Мені мова теж цікава, але поки не вистачає часу заглиблюватись.

Проте було цікаво дізнатись, як виглядає embedded на Rust і чи достатньо розвинуті інструменти. Так я й натрапив на канал The Rusty Bits. Відео виходять нечасто, але дуже якісні (усього 6 відео й 21 тис. підписників).

З усього, що я знайшов в інтернеті, це найкраще джерело на цю тему.
Якщо цікавитесь Rust + embedded — рекомендую до перегляду! 🚀

https://www.youtube.com/watch?v=TOAynddiu5M

Часто працював над продуктами з open source пакетами, і помічав: деякі користувачі переживають через розмір пакета на npm чи в сервісах типу Bundlephobia. 😰

Але тут варто памʼятати: сучасні пакети часто публікуються одразу у кількох форматах — ESM, CJS тощо. І хоча не все можна оптимізувати, у випадку з ESM більшість роботи робиться автоматично. Завдяки tree shaking, не всі залежності потрапляють у фінальний бандл користувача.

Нещодавно натрапив на круте відео з React Day Berlin, де один із авторів React Query пояснює це буквально по пунктах. Якщо ви теж стикаєтесь із такими питаннями — скиньте відео своїм юзерам.


https://youtu.be/8-RTNnn9GR8?t=220

Ще один цікавий виступ з React Day Berlin — цього разу про оптимізацію рендеру за допомогою React Ref. ⚛️

Автор показує на прикладі таблиці з можливістю змінювати ширину колонок, як уникнути зайвих перерендерів. І не просто зменшити, а повністю прибрати re-render при редагуванні!

Це чудовий приклад типової помилки та нестандартного, але ефективного вирішення. Раджу глянути, навіть якщо ви досвідчений React-розробник — можливо, здивуєтесь. 👀

https://www.youtube.com/watch?v=TgpTG5XYoz4

Дуже популярний у свій час підхід до стилізації компонентів у React — Styled Components — нещодавно повідомив, що припиняє активну розробку. Залишиться лише мінімальна підтримка.

Я користувався цим рішенням у кількох проєктах, але не можу сказати, що це був мій улюблений підхід. Проте, це все одно одне з найвпливовіших рішень у світі стилів для React.

Чому проєкт згортають?

Проблеми з React Server Components — немає підтримки Context API

Tailwind та подібні підходи стали набагато популярнішими

Автор більше не має змоги активно підтримувати проєкт

Шкода, але доволі очікувано. Styled Components суттєво вплинули на розвиток стилізації у React і точно заслуговують на повагу. 🙌

https://opencollective.com/styled-components/updates/thank-you

Був впевнений, що вже писав про Panda CSS, але схоже, це мені приснилось. 🐼

У продовження теми стилізації — поділюсь альтернативою Tailwind.

Якщо коротко, це майже те саме, що Tailwind, але з іншим підходом до синтаксису + кілька фіч із коробки:

- Стилізація через JS-обʼєкти або React props, повна TypeScript типізація
- Готові утиліти на кшталт CVA (про них я вже згадував)
- "Рецепти" — стилі для компонентів, що складаються з кількох частин

Рішення від авторів Chakra UI, які у 3-й версії повністю перейшли на PandaCSS. Сам користуюсь зараз у одному з проєктів — загалом задоволений. Є нюанси з post-build кастомізацією, але це радше винятки.

Якщо подобається підхід Tailwind, але не хочеться писати стилі в рядок — Panda точно вартий уваги. ✅

https://panda-css.com/

Пробували Shadcn або щось подібне? Якщо ні — дуже раджу! Але це для веба. А що з React Native?

Раніше я вже згадував про NativeWind — Tailwind-підхід для RN. А ось кілька схожих рішень, які рекомендують розробники:

- Gluestack
- React Native Reusables
- NativeWindUI

На мій смак, NativeWindUI — найгарніше рішення, але більшість компонентів платні. Gluestack виглядає симпатично і має великий набір, але я трохи скептично ставлюсь до "універсальних" рішень.

Тому найбільше уваги приділив би React Native Reusables — орієнтовані саме на RN, хоч і мають web preview (через Expo). Точно спробую цей варіант у своїх міні-проєктах!

Нещодавно писав про MCP і як ця ідея набирає обертів. І от — Notion випустив власний сервер.

Налаштування виглядає простим і добре задокументованим. Але як завжди — юзери вже знайшли кілька багів (впевнений, швидко виправлять).

Якщо ви хочете інтегрувати AI у ваш Notion — саме час спробувати. Один із найочевидніших кейсів — пошук по документації, яку часто тримають саме в Notion. Це може бути зручно для користувачів вашого сервісу.

https://github.com/makenotion/notion-mcp-server

Якщо ви заглядали в код React або Lexical (чи інших бібліотек від Meta), то точно бачили виклики invariant(...).

Що це? Це аналог assert з інших мов: перевіряє умову, і якщо вона неправдива — кидає помилку. Але лише в DEV режимі. У PRODUCTION версії ця перевірка видаляється (tree shaking або через компілятор).

На жодному з проєктів, де я працював, цей підхід не використовувався — але в open source його часто зустрінеш. Наприклад, Lexical активно ним користується — і це реально зручно під час розробки бібліотек.

Згадав про це, бо побачив у Twitter ще цікавіший варіант invariant(...) із debugger всередині. До речі, є кілька готових npm-пакетів для цього — раджу глянути:

tiny-invariant

invariant

Можуть стати в нагоді, особливо для інструментів і SDK.

Пам’ятаєте масштабну кібератаку NotPetya в 2017 році? Вірус, створений країною-терористом для завдання максимальної шкоди українській інфраструктурі. Я ще заглянув в випуски ТСН за той період, як же відрізнявся світ тоді.

Нещодавно натрапив на свіже відео, де детально розбирають механіку вірусу та як саме Windows-вразливості дозволили йому поширитись так швидко. Дуже рекомендую — навіть якщо ви пам’ятаєте ті події, це дозволить поглянути глибше.
А головне - як ці вразливості стали відомими.

Особливо цікаво дізнатись, як саме така атака стала можлива — не лише технічно, а й через халатність і відсутність елементарної кібергігієни.

Пам’ятайте: кібербезпека не важлива… доки не стане важливою. Особливо в наш час.

https://youtu.be/3-MSlNVqzYY?si=i--bxK_jMJeklfFf

Б'я́рне Страуструп забив у тривожний дзвоник.

Хто не знає — це творець C++, не молодий, але досі активно бере участь у розвитку мови.

Так от, нещодавно він виступив із закликом захистити C++ перед зростаючою хвилею критики, яка посилилася завдяки стрімкому розвитку таких мов, як Rust, Go, C# тощо. Хоча, на мою думку, основний акцент тут таки на Rust як головному конкуренті. 🦀

То в чому ж полягає критика?
Основна суть: C++ дозволяє opt-out memory safety — тобто працювати з пам’яттю напряму, але за бажання можна використати безпечніші абстракції. У Rust усе навпаки — opt-in: доступ до “небезпечної” пам’яті можливий, але потребує явного дозволу й зусиль з боку розробника (borrow checker, unsafe тощо).

Додаткового вогню в ситуацію додає той факт, що американські урядові агенції з кібербезпеки вже публічно заявляють про бажання відмовитися від мов, які не мають вбудованої безпеки при роботі з пам’яттю (тобто C++). Причина — критичні баги безпеки майже завжди пов’язані з помилками в управлінні пам’яттю. 🔐

Відверто кажучи, мені важко повірити, що мільйони рядків коду, особливо в застарілому софті, можна буде перенести на інші мови в якісь розумні терміни. Хоч я й усе більше вірю в те, що Rust стане домінантним над C++, але це точно не станеться швидко.

А на зображенні видно пропорції причин критичних багів (2019 рік), ось джерело.

Глянув Release notes у Zero Sync Engine (раніше вже писав про нього) — нарешті додали кастомні мутації. Справді велике оновлення! Але про це якось іншим разом.

Читаючи документацію до мутацій, натрапив на коротку статтю, яка пояснює, як серверні мутації не конфліктують із тим, що відбувається в користувача на екрані. Це концепція Server Reconciliation 🧩

Мені ця тема видається дуже важливою. Попри те, що приклади подані на основі гри, суть залишається актуальною і для веб-додатків.

Йдеться про типову ситуацію, коли після дії користувача минає певний час, поки сервер опрацює запит і надішле відповідь. Щоб покращити UX, інтерфейс часто оновлюють одразу — ще до відповіді сервера — сподіваючись, що все пройде без помилок. У вебі це відомо як optimistic update. Але виникає проблема, якщо таких запитів кілька — інтерфейс «стрибає» між станами, що псує досвід.

Одне з рішень — індексація запитів і відновлення стану з урахуванням тих, що вже були оброблені. Проста й елегантна ідея. Раджу глянути всю статтю!

Відкритий код — це як благодать. Ми рідко задумуємось, звідки він взявся, скільки праці, часу та коштів у нього вкладено. Просто беремо й додаємо пакети на будь-який смак до свого проєкту.

Але чи були ви коли-небудь по інший бік цього? Я — так. У мене є кілька публічних пакетів. Я не веду їх активно, але принаймні виправляю критичні баги та оновлюю залежності, якщо хтось повідомляє про вразливості. Це невеликі проєкти, десь під сотню зірок на GitHub'і.

А от інструменти з мільйонами завантажень щотижня — це вже інша справа. Часто, перед використанням пакету, я заглядаю в issues, щоб оцінити, що там відбувається. І інколи бачу страшне: користувачі приходять і вимагають фічі від авторів у грубій формі. Особливо відзначаються представники країни-терориста, яких буквально розриває, коли їм роблять зауваження за тон 🤷‍♂️

Ділюсь відео про проблеми open-source і приклад того, як деякі безкоштовні інструменти стали платними. Освіжає розум і нагадує: до залежностей треба ставитися з обережністю.

https://www.youtube.com/watch?v=GxTdBkcn1jM

Рік тому Раян Дал — автор Node.js, а згодом і Deno — релізнув JSR: JavaScript Registry.

Але ж у нас вже є знайомий NPM. Навіщо ще один registry? Давайте розбиратись 🕵️‍♂️

Оскільки головний фокус Раяна зараз — це Deno, то й JSR тісно пов’язаний із ним. Однією з головних фіч Deno є нативна підтримка TypeScript (Bun теж підхопив цей тренд). Мотивацією створити JSR було усунення деяких обмежень NPM. Насамперед — можливість публікувати пакети без транспіляції, тобто просто завантажувати TS-код. Крім того, JSR не підтримує CommonJS — лише ESM.

А вишенькою на торті є спрощений процес публікації 📦 Публікація в NPM виглядає простою... але щоб грамотно налаштувати package.json, додати підтримку різних форматів, стилів тощо — треба постаратись. У JSR ці кроки автоматизовані. Плюс є підтримка інших рантаймів (з певними обмеженнями) — зокрема, Node.js і Bun.

Особисто я зустрічав лише одну людину, яка реально щось туди публікувала, тож глибокого досвіду ще не маю. Але ідея виглядає перспективною 🚀