Крім 3д друку дуже не вистачало доступної CNC опції. Думаю це не на довго, бо ось такі продукти будуть потрози заходити на ринок.

Звісно що ціна досить висока (на фоні цін на принтери звісно, чуть більше 2к євро. Але з ростом ринку впаде і ціна, напевне

Там ще потрошки розриваються інстурменти для виготовлення PCB плат вдома, але теж на зародкових стадіях.

Цікаво загалом

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

Не так багато цікавих проекті які справді юзають WebAssembly, але Figma це дуже класний приклад.
Тим не менше, WA прогерсує і факт того, що тепер адресний простір буде 64-бітним звучить дуже круто. Там і інші оновлення підвезли, деталі у відео.

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

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

Бути трудоголіком може і фінансово вигідно, але все має свої межі. Тим не менш, якщо це приносить задоволення то катастрофи нема

Або, як казав відомий діяч: «філософія, психологія, мотивація то є сильна»

Там, до речі, Zed вийшов під Windows

https://www.reddit.com/r/ZedEditor/comments/1o9ovoz/zed_on_windows_performance_comparison/

Zed та агенти

Деякий час тому, ну може місяць чи півтора, редактор Zed додав підтримку вбудованого інтерфейсу для першого агента - Claude Code. Потім додали і гуглівський агент.
Я так і не потестував їх, бо (1) вистачало звичайного чату та (2) вже якраз щупав Opencode.

Але ось є перша версія підтримки і для Opencode, і найцікавіше - що жодних змін у Zed для цього не було потрібно. А все тому, що вони перед першим релізом агента створили кастомний шар, адаптер, фасад - називайте як хочете. І назвали це Agent Client Protocol (ACP).
Тому тепер, зробивши мапінг будь-якого агента під ACP, ви автоматично зможете юзати його у вбудованому UI всередині Zed.

Звісно, як і зі всіма абстракціями, тут точно будуть якісь обмеження. А CLI-інтерфейс агентів завжди буде симпатичніший і унікальніший порівняно з тим, що в Zed - це ціна уніфікації.

https://agentclientprotocol.com/

https://github.com/sst/opencode/pull/2947

В мене на сьогодні тільки наперед написані пости, але просто не можу обійти увагою реліз браузера від 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/

А, ну так)))

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

Too long; Didn’t watch

Побачив свіжий, цікавий і симпатичний інструмент для вижимки інформації з YouTube відосів.
Так ще й open-source!

Закинув йому на пробу відео на 35 хв. Йому знадобилась приблизно одна хвилина, щоб дістати з нього текст (певно напряму через API) та додати його в контекст LLM.

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

Сподобалось

Лінк з прикладом

АІ скоро все буде робити за нас, навіть тупіти...

https://x.com/alex_prompter/status/1980224548550369376

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://music.youtube.com/watch?v=e1N_fJlJaXY

Wouter - мікро роутер

Давно висить у моєму списку цікавих проєктів, але ніяк не доходили руки про нього тут написати.

Коротко - це справді дуже маленький роутер з обмеженою кількістю функціоналу. Але з досвіду - цього вистачає у 80% випадків.

API схожий на React Router, працює для React та Preact.

Ми полізли його юзати спочатку для створення ізольованих hash-роутів всередині деяких інтерфейсів.

Але крім цього він мені цікавий (хоча я в процесі роботи над PoC) тим, що дозволяє створювати паралельні роутери і відловлювати зміни в навігації. А от RR це блочить, просто забороняє мати, наприклад, MemoryRouter всередині BrowserRouter і т.д.

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

https://github.com/molefrog/wouter/tree/v3

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

Наглядно показано, чому Effect це не ще один RxJS та що таке errors as values.

Взагалі, я глянув це відео заради прикладу LSP, але там і всі інші теми класні і зрозумілі.

https://youtu.be/V_XfZbxabI8

Not bad

Це красиво

.scroller {
animation: mask-up;
animation-timeline: scroll(self);
animation-range: 0 1rem;
mask-composite: exclude;
}
@​keyframes mask-up {
to { mask-size: 100% 120px, 100% 100%; }
}

https://x.com/jh3yy/status/1789359851094614449

Музична перерва 💅

https://music.youtube.com/watch?v=uAO_R-SOd3k