Нещодавно писав про 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.

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

Сьогодні поділюсь з вами невеликою бібліотекою для визначення домінантного кольору зображення (а також відео) 🎨

Одразу скажу — сам ще не використовував, але натрапив на неї в одній статті про роботу з кольорами.

Ідея проста: знайти колір, який домінує на зображенні. Застосувань багато — від кастомних тіней і градієнтів до фонів або прев’ю під час завантаження зображення.

Автор також ділиться посиланнями на схожі рішення — можливо, десь є й кращі. Але ця бібліотека виглядає цікаво, особливо тим, що має підтримку Node.js.

https://github.com/fast-average-color/fast-average-color

Чому 2038 рік є дещо особливим із точки зору розробки?

Підказка — це пов’язано з 1970 роком 😉

Здогадались? Пояснюю.

Коли створювали першу версію операційної системи UNIX, вирішили вибрати точку відліку в часі — так звану UNIX epoch. Нею стало 1 січня 1970 року о 00:00. Всі подальші значення часу — це кількість секунд від тієї миті. Наприклад, t1 — це 00:00:01, а t1745011491 — час, коли я пишу цей пост (квітень 2025).

Так от, у UNIX (написаному на C) значення часу зберігається як signed 32-бітне ціле число. Його максимальне значення — 2 147 483 647. Цей момент настає 19 січня 2038 року. Після цього значення переповниться, і час почне "йти назад" — як Y2K, тільки серйозніше 😅

Як це вирішують? Одне з рішень — перехід на 64-бітні типи. У деяких мовах (наприклад, Java) це вже вирішено сучасними time API. У JavaScript — також використовується 64-бітне представлення.

Цікаво, що у Windows проблема не виникає — там епоха починається з 1601 року, і одразу використовувався 64-бітний формат ⏳

На попередній пост про UNIX epoch мене надихнуло відео про те, як операційна система обробляє команду sleep — яка є доволі поширеною у низькорівневих мовах програмування.

Якщо коротко: кожен процес, який призупинився через sleep, потрапляє в окрему чергу. Туди його переміщує ОС і створює точку часу, коли його слід "розбудити" — саме цю точку і обчислюють на основі UNIX epoch (оскільки мова йде про UNIX-подібні системи).

Цікаве спостереження: коли процес переноситься з черги очікування назад у чергу виконання, немає гарантії, що він одразу ж виконається. Він просто повертається в чергу разом з іншими, і все залежить від планувальника. Тому універсальні ОС (general-purpose OS) не можуть гарантувати мілісекундну точність.

А от на спеціалізованих пристроях — наприклад, мікроконтролерах з RTOS (Real-time Operating System) — така точність вже підтримується. В реальному часі "sleep" справді означає "прокинься через точно стільки-то мілісекунд".

Але це лише мій переказ — рекомендую глянути відео. Автор дуже доступно показує, як це все працює на найнижчому рівні 🧠

Ех, якби такі відео були в той час, коли ми програмували асемблер на папері в універі… 😄

https://youtu.be/e5g8eYKEhMw?si=Lq75JdnmevOEcEQH

Зараз трохи заглядаю в Obsidian — безкоштовний нотатник з цікавою філософією. Підчитував блог його автора і згадав, що вже колись натрапляв на його статтю про палітру Flexoki.

Розкажу коротко: Flexoki — це кольорова палітра, створена автором Obsidian спеціально для свого блогу. Її ідея — зробити кольори різноманітними, але водночас впізнаваними та з характером. Мета звучить умовно, але підхід — дуже продуманий.

Ясна річ, про те, які кольори "правильні", можна сперечатись вічно. Велике значення має особисте сприйняття, контекст, ціль. Але у Flexoki зроблено акцент саме на людське сприйняття — палітра доволі м’яка, тепла, приємна для очей.

По моїх відчуттях — кольори справді мають щось затишне. Цілком можливо, що використаю їх у якомусь зі своїх мініпроектиків. А ще її можна легко інтегрувати як кольорову тему для редактора — якщо вам теж зайде, як і мені 😊

https://stephango.com/flexoki

Нещодавно натрапив на відео, де автор в емоційній формі “булить” React Native. Глянув — важко не погодитись, звісно. Ось чому.

Багато продуктів, що досі висять на сторінці React Native Showcase, насправді вже давно ним не користуються. Інформація трохи застаріла. З одного боку — засмучує. Але якщо глянути уважніше на те, що потрібно цим продуктам — часто це висока продуктивність, гнучкість, швидкий реліз — і тут нативні рішення беруть гору.

Проте я не думаю, що це якось серйозно б’є по RN. Є Expo, яке суттєво бустить розробку. Є доволі активне ком’юніті, купа пакетів з байндингом на нативний код, плюс Meta досі розвиває фреймворк. RN, можливо, вже не на хайпі — але точно не “мертвий”.

Особисто я теж використовую React Native у своєму мініпроєкті. І чесно — мені зручно. Можна швидко запустити щось просте, не вивчаючи дві додаткові мови та екосистеми. Як для невеликих задач — чудовий вибір.

До речі, Flutter зараз виглядає не краще — понад 12 тисяч issues на GitHub, і загальна динаміка не дуже оптимістична.

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

Часта проблема в JavaScript — потрібно порівняти два об'єкти.

Найпростіше рішення — JSON.stringify() обох об'єктів і порівняння рядків. Працює, але…
🔸 не підходить для циклічних структур
🔸 блокує основний потік на великих об'єктах
🔸 не завжди надійне через порядок ключів

Погана ідея для продакшену, коротше.

🧠 Але TC39 (комітет, що розвиває JS) розглядає нову пропозицію — Composite.
Це новий тип об'єкта, який:
✔ виглядає як звичайний об'єкт
✔ підтримує всі стандартні API
❌ але immutable — тобто змінити його не можна

Що це дає?
🔹 Надійне порівняння
🔹 Прогнозованість
🔹 Безпека при передачі об'єктів

Composite зараз на Stage 1 — тобто комітет активно розглядає ідею і шукає альтернативи. Якщо все піде добре — перейде на Stage 2, а там і до реалізації недалеко.

Більше деталей дуже добре пояснив Matt Pocock у Twitter — рекомендую почитати, залишу лінк ⬇

https://x.com/mattpocockuk/status/1911705407233393027

Пригадую коли ще був молодим розробником, компанія де я працював вимагала проходити “екзамен” щоб піднятись на наступний рівень. Ну тобто з джуна на мідла, і тд.

В той час ІТ ще не було настільки заповнене людьми (або мені так здавалось), вчитись не було сильно в кого. Гугл працював, але не було якогось фреймворку знань — з чого почати, чим закінчити, що важливе, а що можна пропустити. Тож я готувався до цих всіх екзаменів сам. А потім ще передавав в спадщину всі свої нотатки, трелло дошку з темами і тд.

Одна з тем яка мені була дуже цікавою — як працює JavaScript всередині? Ну там Event Loop, черга, стек, мікротаски і тд. Розбирався я в цьому читаючи статті та окрему літературу. Тоді ще був досить популярним Medium.

І от зараз, дивлюсь як змінилась ситуація — і я радий. Якщо ти зараз починаєш свій шлях — просто відкриваєш YouTube, вводиш “event loop javanoscript” і в тебе купа крутих, вилизаних відео з графікою, прикладами, іноді навіть симуляторами.

Тож для новачків сьогодні поділюсь цим класним відео, де провізуалізовано все що пов’язано з Event Loop. Я і сам переглянув повністю, щоб перевірити чи нічого не забув.

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

Вирішив знову понюхати АІ пороху і навайбкодив 💅 за один вечір простий таймер під macOS, щось типу помодоро.

Так як я молодий дід, а сидіти весь день в кріслі — не найкраще для спини, то вирішив раз на годину робити якісь вправи. Короткі, на декілька хвилин. Ідея з помодоро ніби підходить, але я полазив по App Store — нічого не знайшов, щоб мені справді сподобалось. Все або занадто складне, або негарне, або з рекламою. Ну і я вирішив — час спробувати Swift і SwiftUI.

Якщо чесно, враховуючи що я взагалі не писав на Swift до цього, все виявилось досить просто, якщо відкинути нюанси macOS-платформи (як зробити апку тільки в тулбарі, як правильно підписати для запуску тощо). Схожий принцип як і в React, тай в тому ж Flutter. Є дерево елементів (view) в цьому випадку, складаєш як треба. Ще й прев’юшки в Xcode кайфові, можна UI прямо редагувати і воно одразу з’являється в коді.

Цікавим було зробити спільний стейт між кількома View, ще цікавіше — між кількома вікнами (бо я зробив окреме Settings-вікно). Але загалом — нічого критичного, документації достатньо, гугл працює.

Мінімалку таймера зібрав за один вечір: старт, пауза, скидання, нотифікація коли час вийшов. Потім ще хвилин 10 щоб зібрати все в .dmg.

Можливо ще трохи покручу її і викладу тут, якщо буде виглядати достойно. А поки — плюс один експеримент в колекцію.

Загалом, довайбкодив я таймер, який починав раніше.

Під моїм пильним наглядом АІ не встиг повністю налажати, але косяків було більш ніж достатньо. Чим довше я працював над апкою, тим більше прокидався в мені старий добрий АІ-скептик. Але так як я не перший рік в цьому бізнесі, то вчасно надавав LLM по руках — мовляв, отут не імпровізуй, отут не вигадуй, а отут просто мовчи.

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

Можна вважати це деанон-моментом — бо раніше я вів цей канал без імені. Але раз вже ділюсь апкою, то автоматично ділюсь і своїм GitHub.

🧱 Репозиторій тут:
👉 https://github.com/bohdanbirdie/time-to-stretch-app

Можна скачати .dmg або збілдити собі самому. Якщо хочете щось покрутити, додати чи пофіксити — будь ласка, велкам.

Фічі:

⏱️ Редагування інтервалів таймера

🔁 Зациклення таймера

🔔 Системні сповіщення коли таймер завершується

🎹 Глобальні шорткати з можливістю редагування

🌗 Темна і світла тема

🚀 Автозапуск при старті macOS

Я точно буду користуватись, щоб не забувати рухатись під час роботи. Сподіваюсь, і вам стане в пригоді.

Накидайте зірочок ⭐

Так як я вже вчора поділився з вами своїм гітхабом, то сьогодні можна і поділитись своїм веб блогом.

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

Так от, в одній зі статей я писав про GraphQL, з акцентом на Apollo Client. Це був основний елемент, який у нас відповідав за шар даних на попередній роботі, і під собою він агрегував більше двох десятків мікросервісів.

Найбільше що мені подобається — це нормалізація даних на клієнті, яку повністю бере на себе Apollo. Тут у них є перевага, бо graphql-схема вже описує всі можливі об’єкти, і за ID кожного об’єкта його можна зберігати у вигляді key-value, відтворювати дерево і діставати дані по цьому ж ключу.

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

Зрештою, читайте статтю, буду радий отримати якийсь фідбек!

https://www.bohdanptyts.com/blog/efficient-data-handling-with-graphql-and-apollo

Давайте сьогодні трошки поговоримо про продуктивність, принаймні як я її бачу.

З власного досвіду — коли я перейшов на віддалену роботу, ще до ковіду, то відволікаючих факторів стало суттєво більше. Теніс в офісі я грав нечасто, не сильно втягнувся у всякі забавки, не виходив курити з колегами і т.д. А в опен спейсах якось і незручно робити собі перерви, щоб повтикати в ютуб. Ну а вдома — все інакше. Ніхто над тобою не стоїть, сам плануєш час, і легко піддаєшся різним подразникам — тим же ютубам чи інстаграмам. А я ще люблю поприбирати — як в тих відосах про ADHD, де починаєш одне, а потім уже цілий стек дрібних справ.

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

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

Одне з основних правил — не дивитись ютуб під час роботи (окрім випадків, коли щось реально треба по роботі), але дозволяти собі це під час обіду або визначених перерв.

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

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

Більшість з того, що я клею — це щось позаробоче: ідеї, дрібні справи. Але завдяки цьому я не відволікаюсь від основної роботи.

Ще я практикую подібне з вкладками в браузері. Наприклад, почув щось цікаве в подкасті — загуглив, відкрив вкладку і відсунув її кудись вбік. А ввечері повертаюсь.

Написати цей текст мене надихнуло відео з одного каналу, на який я останнім часом підсів — про продуктивність. Там було про правило 5 хвилин. Хоч воно й дещо інше від того, що я описав вище, але ідея теж цікава.

https://www.youtube.com/watch?v=CnQVe-nXq50

Вчора була презентація по Skia, в стилі Apple (це зараз дуже модно). Бачу, що я про це раніше не писав, тому якщо коротко: Skia — це рушій для 2D-графіки, особливо популярний у React Native (завдяки зусиллям Shopify).

Я вже трохи пробував Skia, але дуже поверхнево, бо слабо розуміюсь у графіці. Та після вчорашньої презентації ентузіазм повернувся — і ось чому:

З’явилась підтримка WebGPU в React Native, що відкриває можливості для однорідного API між вебом та RN. Можна буквально скопіювати код із вебу й запускати на телефоні. Це також покращує перформанс і дозволяє використовувати окремий потік для графіки, не блокуючи інтерфейс.

Суттєво вища підтримка 3D.

Показали колаборації з іншими командами, як-от Software Mansion, їхній TypeGPU та інші інструменти.

Заделіверили 0 нових фіч, але сильно попрацювали над продуктивністю.

І трохи розповіли про майбутнє Skia Graphite — рушія поверх WebGPU.

Приклади виглядають круто, але я часто розчаровуюсь, коли починаю сам щось робити — бо це вимагає глибшого розуміння графіки та шейдерів 💅

Але думаю, я таки повернусь до Skia.

До речі, знали, що весь інтерфейс Flutter-додатків — це саме Skia? Вони повністю обходять нативні інтерфейси. Пішли своїм шляхом, так би мовити.

https://www.youtube.com/watch?v=t9t-VXwIc4I

Нещодавно мав багато роботи по оптимізації й автоматизації релізу пакетів. У таких PR легко випадково зламати package-lock.json, коли з’являється кілька десятків тисяч змін — весь CI червоний, важко зрозуміти, що саме спричинило проблему. Найпростіше рішення в такому випадку — взяти lock-файл з main і перезапустити npm install, щоб усе синхронізувалось.

Але не раз бачив, як такі зміни залишались непоміченими, і хтось мерджив pull request з величезним diff'ом у lock-файлі. Потім у когось щось не працює, і починається відлов проблем. Один із типових сценаріїв — коли у вас локально різні версії NPM, і через це змінюється формат package-lock.json.

Тому я вирішив зробити простий «захист від дурня». За один вечір накинув і релізнув GitHub Action, який перевіряє, чи не занадто великі зміни, і якщо так — залишає коментар у PR.

Тестував на окремому репозиторії — все працює швидко, бо перевірка доволі проста. Коментар можна вимкнути, а CI навіть може фейлити, якщо перевищено ліміт. Є кілька варіантів конфігурації, тому якщо цікаво — спробуйте!

https://github.com/bohdanbirdie/fat-lock-action