Розробка третьої хвилі

https://wpvip.com/future-of-the-web-2026/ )))))))

Слухав свійжий подкаст про Effect, там в чергове зачіпили тему надиктовування замість друкування промптів. Я вже раніше ставив собі Superwhisper, але якось не пішло. Тепер от, після того як сотню раз воно мені світилось, поставив Hex Змішані відчуття, інколи здається що друкую я краще ніж говорю, але дам шанс. Цікаво почути досвід підписників з такими інструментами.

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

Хехехе https://x.com/mitchellh/status/2067970516951150721

Дуже зацінив цю статтю і ділюсь з вами. Як я розумію, це хтось з Anthropic написав. Інтерпретую її як набір досить якісних і цілком конкретних порад. В плані бери і юзай, прикладні речі. В ній декілька разів згадується Річард Геммінг, дуже навіть видатна людина, яка мала безпосередній вплив на наше з вами сучасне життя. Я на хвилі хайпу, вже деякий час тому, теж здобув собі друковану копію його книги перевидану Stripe. Але, ще в процесі прочитання. Ну, стаття то не книга, тому рекомендую прочитати за можливості. https://x.com/itsreallyvivek/status/2064686372737454155

Most importantly for problem-solving, black boxes are rigid. They must explicitly reveal some dials and knobs, and hide others, committing to a particular view about what it is essential to expose to the user, and what is noise. In doing so, they present a fixed level of abstraction which may be too high-level or too low-level for the problem, As an example, a high-level web server may provide a terrific interface for serving JSON, but be useless if one wants an interface for serving incomplete data streams, such as output from a program. In theory, you can always look inside the box, but in code, the abstraction level at any one time is fixed.

Дуже сподобався цей абзац зі статтi `Think in Math. Write in code` Вона висіла в моєму списку до прочитання декілька місяців, нарешті дойшов. Її висновки більше про те, що мови прогармування це лиш один зі способів репрезентації ідей та підходів, але не найгнучкіший. Це і є фундаментальним обмеженням. А альтернативою є математичне відображення. Не раз шкодував, що не вивчав математику краще, коли був ще в школі і універі. Це, звісно, і не потрібно щоб робити CRUD АРІ, але дуже корисно для чогось більшого, для логіки та розуміння. Тому всі, хто не балдів як я - моя повага. https://www.jmeiners.com/think-in-math/

Декілька цікавих людей, зокрема співзасновник Signal, працюють над дослідницьким проектом, метою якого є крипографічно захищені багатокристувацькі застостунки. Там є великий PDF, це основне. Самого проекту ще немає. Працюють за підтримки Microsoft. Як це працює, якщо коротко: • сервер не має жодних ключів і не бачить вміст • усі зміни записуються в журнал, а спеціальні докази (zero-knowledge) дозволяють швидко перевірити, що все правильно • ключі змінюються, коли хтось приєднується чи виходить, тож нові люди не бачать старих даних, а видалене справді видаляється • для розробників це виглядає як звичайна база даних (схоже на Firebase), а шифрування ховається під капотом Круто для журналістів, лікарів, активістів і тд. Короче, там де витік даних може мати серйозний вплив на їх життя. Мені це цікаво, бо воно представлено як sync engine. Побачив цей лінк в діскорді Ink&Switch. https://encryptedspaces.org/

Останнім часом стало дуже легко зрозуміти, що код написаний Opus 4.8 - він почав додавати нереальну кількість коментарів в коді Навіть якщо йому скажеш видалити всі, які очевидні - він видалить десь половину, решту перефразує, БО ВОНИ ТРЕБА, ЧЕСНЕ СЛОВО Трошки замучив він з цим. І ніякі заборони в CLAUDE.md не допомагають...

Клас, ще одна причина таки взяти собі mac mini Мак міні, особисто для мене, вгилядає дуже привабливим продуктом. Навіть базова версія дає досить багато можливостей. Всякі прості моделі можна крутити локально, декілька віртуалок підняти, докер хостити. Ну це все можна і не на мак міні, звісно ж. Але тут готовий запакований продукт, який гарно виглядає і займає мало місця. Тільки от вже версія на 48гб оперативки коштує суттєво дорожче 😒 https://www.youtube.com/watch?v=9prKU2Vuo-0

Такс, ну чуть довгий текст вийшов, ну буває АЛЕ ПРОБЛЕМА Ж ЦІКАВА 🫨

Serverless це окремий світ зі своїми дивними правилами. Сьогодні про одне з них. Я собі фоново пиляю міні-проєктик Cloudstash. Живе він на Cloudflare і фактично зібраний навколо двох примітивів - Workers і Durable Objects. Днями додав нових юзерів, активність підросла - і виліз баг, який тихенько сидів з самого початку. Баг цікавий, хочеться розказати. Але спершу швидкий екскурс по примітивах: 1️⃣ Worker - це v8 isolate. Ізольований екземпляр рантайму з власним heap. Стартує мікроскопічно швидко і коштує копійки. З мінусів - купа обмежень, немає файлової системи і є нюанси з повною ізоляцією. 2️⃣ Durable Object - це той самий воркер, але з власною SQLite-базою. Простіше кажучи, stateful-воркер. За рахунок чого вся ця історія така дешева: • у воркерах ти платиш тільки за CPU cycles. Для порівняння, в AWS Lambda платиш за весь час виконання, навіть поки код тупо чекає. • до Durable Object можна підключитись по веб-сокету і тримати конект скільки завгодно, не платячи за простій. Воркер просто «засинає» і прокидається, коли прилітає нове повідомлення. Нюанс по оплаті: на відміну від звичайного воркера, DO рахує саме час виконання, а не CPU. Але це все одно копійки, бо він засинає. Уявіть чат у Slack. Тисяча людей онлайн. Сама кімната - це один Durable Object, який тримає всю переписку. Всі підключені, але якщо ніхто не пише - DO спить, і оплата йде в нуль. Хтось кинув повідомлення - DO прокинувся, розіслав його всім по веб-сокетах, через пару секунд знову заснув. Кайф у тому, що в тебе живий WS-конект, а ти за простій не платиш. Окей, екскурс закінчили. Cloudstash робить по DO на кожного юзера. Тобто всі твої посилання, описи, теги, метадані лежать у твоєму особистому DO. Навіть якщо в тебе відкрита одна вкладка - WS-конект живий, але DO спить, поки ти не кинеш нове посилання на збереження. І ось тут зарита проблема. Щоб DO заснув, має зійтися 4 умови. Коротко: немає незавершених fetch`-запитів; не юзається стандартний WebSocket API (тільки Hibernation API); не обробляється жоден request; і - ключове в моєму випадку - немає живих таймерів типу `setInterval чи setTimeout. Якщо висить хоча б один незавершений таймер - все, DO спати не піде. І от коли юзерів стало більше, мені прилітає алерт: один із Durable Objects вижер увесь доступний ліміт. Дивина, бо при кількох активних юзерах це впринципі не має бути можливим. З агентом проблему таки розкопали, і я попросив його розжувати мені все по повній, в інтерактиві. Не зовсім /teach-скіл, але щось схоже. Що зʼясувалось (по можливості коротко): Клієнт на UI спілкується з DO через RPC поверх WS. RPC-сервер, який крутиться всередині самого DO, написаний на Effect і кастомний - він не рве конект, поки юзер сам не відвалиться. Щоб тримати підключення відкритим, він юзав Effect.never. Це штука, яка лишає Effect-потік висіти вічно, поки його не закриють примусово. А тепер сама засада: всередині Effect.never реалізований через setInterval. Оце і вся проблема. Для Node.js це нормальний трюк - так програма не завершується раніше часу, для Effect.never логічно. Але всередині DO цей таймер просто не дає йому заснути. Агент підкинув альтернативу - функцію, яка дає той самий ефект для програми, але DO від засинання вже не дискваліфікує. Тепер найсмачніше - що це давало по грошах. Агент прикинув, скільки юзерів влазить у безкоштовний ліміт до і після фіксу, по типах активності: • легкий юзер (1 сокет, 4 год на день): до фіксу - близько 7 юзерів, після - близько 50 000 • середній (1.5 сокета, 8 год): до - десь 2.4, після - близько 25 000 • важкий (2 сокети, 16 год): до - менше одного (!), після - близько 13 000 Тобто до фіксу один важкий юзер з відкритою вкладкою на цілий день буквально не влазив навіть сам у безкоштовний тариф. Після фіксу - десятки тисяч. Один незавершений таймер вартував мені приблизно трьох порядків. Детальніше розписав проблему тут: github.com/livestorejs/livestore/issues/1328 Правопис лиш чучуть підправив з АІ 😁

Zed поділились деталями розробки над DeltaDB - їхня альтернатива для контролю версій. Не ясно чи це заміна Git чи додадок до нього. Коротко: початкова ідея була для колаборації людей над кодом. Їх бачення зводилось до думки, коли ти вже закомітив, то це може бути трошки запізно для обговорення змін, часті найважливіші розмови стаються до цього. З приходом агентів розмови про код буквально перенеслись в IDE, де ви обговорює рішення з моделями. Тільки от ці рішення ніде не записуються, а я раніше кидав оцей Entire тул. Цікаво, незвично https://zed.dev/blog/introducing-deltadb

Дуже класне пояснення, якщо не раз думали про те як працюсь різні чіти але ніколи не цікавились Тай загалом, канал дуже цікавий, не раз кидав відео з нього https://www.youtube.com/watch?v=OlKvnvZKzcg

Досі юзаю цей підхід з VM, але не дуже активно Є певні мінуси, DX стає гіршим. Найбільше мене, напевне, нервувала неможливість вставляння скріншотів в Claude Code через SSH. Купу всяких хаків доводилось робити, щоб це працювало нормально і не потрібно було давати доступ до файлової системи хост машини. Потім почав користуватись вбудованим інтерфесом для агентів в Zed через їх ACP, проблема зі скрінами автоматично вирішилась. Але це має інші мінуси, бо уніфікований функціонал ніколи не буде таким як оригінальний. Саб-агенти не крутяться на фоні, все попадає в стрім агента. Пошуку по сесії теж немає, принаймні поки. Немає способу весь час бачити наскільки забитий контекст. Але зберігається сесія після перезавантаження IDE. Схоже, ще буду пробувати dev containers. Там свої проблеми та обмеження. В ідеалі було б добре мати свій кеш проксі в окремому контейнері, щоб чуть економити місце на хості і швидше ставити пакети, але це теж не безкоштовно. Нічого зручніше за роботу на хості немає, чимось треба жертвувати.

Це жоско, дуже https://github.com/oven-sh/WebKit/pull/249