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

Цікаво, що що ж там за пост був))))

Але з іншого боку 💅

Чому в ІТ стало стільки ж драми як в холостяку? Якщо вставити свої 5 копійок, то мене однаково напрягають обидві сторони конфлікту. Тео часом дуже дивні відео записує, може скластись враження що він експерт у всіх технологіях. Але може так і є? https://x.com/windscribecom/status/1982645218307694825

Це точно mad skills. Бути автором купи бібліотек, курсів, залученим в цікаві проекти і тд. І щей стільки дітей робити 🧑‍🍳

https://react.dev/reference/react-compiler/directives/use-no-memo )))))

Якщо АІ слабо інтегрований у вашу роботу, можливо, ви втрачаєте конкурентоздатність. Не знаю, чи помічали ви багато твітів про те, як люди використовують агентів типу Claude Code та інших у більш інтегрований спосіб. Наприклад, через GitHub issues, де описують задачу, а агент робить зміни, створює PR, і це можна мерджити. Але от ця межа між бульбашкою АІ-комʼюніті (в твіттері чи ще десь) і реальністю все більше розмивається. Тому для мене індикатором є саме застосування подібного підходу в нас на проєкті. Ми користуємось Linear для трекінгу задач. Там маємо Claude інтеграцію - на неї можна заасайнити таск, як на юзера, і воно почне щось там кодити. Сподобалось, що тімейт пішов ще далі - просто в локальному Claude Code агенті попросив створити таск у Linear і заасайнити його на Claude Code. Таск був досить простий, але воно непогано його виконало, і залишилось тільки коротке ревʼю коду та мердж. На цей таск пішло би трохи більше часу, якби його робив девелопер. Так от, може, це часом і неприємно визнавати, але АІ розвивається такими темпами, що деякі задачі дійсно можуть швидко закриватись. І тут потрібно тримати руку на пульсі, щоб не відставати від прогресу.

Музична перерва 💅 https://music.youtube.com/watch?v=uAO_R-SOd3k

Not bad

Наглядно показано, чому Effect це не ще один RxJS та що таке errors as values. Взагалі, я глянув це відео заради прикладу LSP, але там і всі інші теми класні і зрозумілі. https://youtu.be/V_XfZbxabI8

Pull request і його ревювер

Wouter - мікро роутер Давно висить у моєму списку цікавих проєктів, але ніяк не доходили руки про нього тут написати. Коротко - це справді дуже маленький роутер з обмеженою кількістю функціоналу. Але з досвіду - цього вистачає у 80% випадків. API схожий на React Router, працює для React та Preact. Ми полізли його юзати спочатку для створення ізольованих hash-роутів всередині деяких інтерфейсів. Але крім цього він мені цікавий (хоча я в процесі роботи над PoC) тим, що дозволяє створювати паралельні роутери і відловлювати зміни в навігації. А от RR це блочить, просто забороняє мати, наприклад, MemoryRouter всередині BrowserRouter і т.д. Він справді дуже маленький, в source коді легко розібратись. https://github.com/molefrog/wouter/tree/v3

Музична перерва 🫀 https://music.youtube.com/watch?v=e1N_fJlJaXY

Oxlint розвивається, ставка на ESLint-формат Раніше я вже писав про Oxlint - альтернативний лінтер для JS, написаний на Rust і заточений під високу продуктивність. Але от проблема всіх цих нових інструментів - adoption. Важко впарити щось таке розробникам, якщо воно хоч трохи не покриває їхній поточний сетап. Тому Oxlint йде вперед і пробує дати можливість писати плагіни для їх лінтера на JS, на додачу з можливістю залишити ESLint-формат. Але найцікавіше в цьому - як їм це вдається зробити і не зашкодити продуктивності? Бо комунікація між JS і Rust мусять бути по якійсь шині, а дані мають серіалізуватись та десеріалізуватись, а це все додаткова робота і, відповідно, час. Так от, вони пробують дуже цікавий підхід, працює він приблизно отак: 1. Oxlint вбудовує середовище Node.js усередину Rust, тому обидва працюють у спільному просторі пам’яті. 2. Використовується N-API (`napi-rs`), щоб напряму передавати дані та функції з Rust у JavaScript. 3. Rust розбирає код і зберігає AST у спільному блоці пам’яті (арені). 4. JavaScript-плагіни отримують легкі проксі-об’єкти, які читають поля вузлів через N-API з цієї арени. 5. Без JSON і копіювання - JS просто читає пам’ять Rust напряму -> мінімальні накладні витрати. Круто і обнадійливо, бачу шанси впровадити це в роботі. https://voidzero.dev/posts/announcing-oxlint-js-plugins https://oxc.rs/blog/2025-10-09-oxlint-js-plugins.html#under-the-hood

АІ скоро все буде робити за нас, навіть тупіти... https://x.com/alex_prompter/status/1980224548550369376

Too long; Didn’t watch Побачив свіжий, цікавий і симпатичний інструмент для вижимки інформації з YouTube відосів. Так ще й open-source! Закинув йому на пробу відео на 35 хв. Йому знадобилась приблизно одна хвилина, щоб дістати з нього текст (певно напряму через API) та додати його в контекст LLM. З цього він зміг створити власні таймкоди, показати весь транскрипт та підготувати можливі запитання, які я міг би запромптити до моделі. Ну і в додачу я спробував одне з цих запитань та отримав відповідь з таймкодами. Сподобалось Лінк з прикладом

GitHub збирає фідбек Недавно в команді GitHub з’явився новий SVP - Jared Palmer. Ви могли чути про нього з Vercel, де він досить довго працював. Так от, він почав збирати фідбек про GitHub у твіттері. Найпопулярнішим запитом були stacked diffs. Чесно кажучи, я надто тупий, щоб зрозуміти, що саме зміниться в інтерфейсі, щоб це додати. Але, прочитавши декілька статей про це, я зрозумів, що і так використовував цей підхід на постійній основі. В чому суть? Дуже коротко - ви робите PR і не чекаєте на його апрув чи мердж, а просто відколюєте нову гілку та працюєте в ній. Якщо перший PR буде змерджено, то PR з нової гілки буде направлений на main. Це дозволяє вам не бути заблокованими, поки чекаєте на рев’ю. Загалом це все, ідея ніби проста як двері, але буде видно, що саме зміниться в GitHub. Можливо, це я не так інтерпретую щось. https://newsletter.pragmaticengineer.com/p/stacked-diffs https://graphite.dev/guides/stacked-diffs https://www.stacking.dev/ https://x.com/jaredpalmer/status/1980619222918262842

А, ну так)))

В мене на сьогодні тільки наперед написані пости, але просто не можу обійти увагою реліз браузера від OpenAI - назвали Atlas. Цих АІ-enabled браузерів зараз наспавнилось як грибів у лісі. І можливо, це я дід, але щось ніяк ця тема мене не може зацікавити. Я от недавно писав про Ladybird, який має зовсім іншу ціль. А ці браузери - це все той самий Chromium, тільки обгорнутий в інший дизайн та з власним баченням АІ-інтеграції. Але чому я маю довірити АІ користувацькі можливості ще й у браузері? Щоб він клікав за мене, бачив усе, що на сторінці, і т.д.? Мало того, що АІ в терміналі і так має доступ до всіх не-sudo команд (і було б краще це якось більше обмежувати), так воно і в буденні речі проникатиме. Коротше, я поки не клюнув на цю тему. Але в додачу, не можу пройти повз купу постів, які показують, які ці АІ-браузери ще сирі. Проблеми prompt-injection реальні, і ніхто з АІ-гігантів толком це ще не поборов. Ось є браузер від Perplexity - називається Comet. А ось дослідження його безпеки: https://x.com/brave/status/1980667345317286293 Ну і в Atlas те ж саме: https://x.com/p1njc70r/status/1980701879987269866 . А в додачу, він ще й шепче OpenAI на вушко, можливо, забагато: https://x.com/praeclarum/status/1980780881188167804 Така ж біда недавно була в Notion - prompt-injection у документі. Я не хейтер, але бачу в цьому більше мінусів, ніж плюсів. https://genai.owasp.org/llmrisk2023-24/llm01-24-prompt-injection/