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

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

Zed editor нарешті релізнув Agent Panel. До цього я, коли треба було поюзати АІ, користувався Windsurf, доводилось переключатись.
Але схоже, що це вже позаду. Pro підписка за 20$ виглядає непогано, дуже імовірно що перейду з Windsurf.

https://zed.dev/blog/fastest-ai-code-editor

Довго думав що про це написати, але навіть не зміг зібрати слів
Це або якийсь вайб кодинг або новий рівень нахабності

https://github.com/krzyzanowskim/ObjectivePGP/pull/236

До речі, коли я захотів зробити таймер на Mac, то задумався: яку ж анімацію він має мати? Можна було вибрати щось типу аналогового годинника, pie chart і т.д. Але я згадав, що є дуже гарний стиль анімації для змінного тексту. Не знаю, хто це першим придумав, але я давно зберіг собі один пакет для вебу. Дивно, що він досі не потрапив у Shadcn.

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

Поділюсь і з вами: https://number-flow.barvian.me/

Безпощадний ринок ІТ — ніколи не знаєш, звідки буде наступний удар.

Microsoft звільнили (layoff) одного з початкових та довготривалих розробників TypeScript. Одразу зазначу, що він не був головним автором, але давно працював над цим проєктом. А в Microsoft взагалі пропрацював 18 років.

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

Не знаю коли я вже використаю Drizzle десь в проекті, але їх вайб це бомба!

https://mssql.drizzle.team/

https://x.com/DrizzleORM/status/1922728686089904554

В ідеальному світі додатків лоадінг-спіннери взагалі не мали б існувати.

Жоден юзер не хоче дивитись на спіннери, скелетони та інші хаки й шпаги від девелопера. Юзер хоче бачити одразу цінну для себе інформацію. До речі, local-first підхід намагається максимально наблизити нас до того, щоб кількість випадків, коли потрібен спіннер, була менша за умовний 1%.

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

І ось, щоб менше тригерити своїх юзерів — іноді можна їх трошки обманути (заради їхнього ж блага).

Проста ідея: не показувати спіннер одразу. Наприклад, якщо запит триває менше 150 мс — взагалі нічого не показуй. Бо з точки зору юзера, спіннер навіть на 150 мс привертає увагу й дратує більше, ніж якби нічого не відбулося і все просто плавно оновилось.

А для прикладу — от вам зручний пакет: https://www.npmjs.com/package/spin-delay