Ще один цікавий генератор тем для shadcn.
Але з якоюсь цікавою фічою - АІ генерація.

Я поки не зрозумів як на основі короткого опису проекті АІ має видумати кольори, але щось воно там собі робить.

Якщо вам не подобєаться tweakcn, то можна спробувати цей.

https://www.styleglide.ai/themes

Ladybird - чули?

Я так застряг у Chrome, що майже й не користувався іншими браузерами, хіба для тестування чогось. Трошки там Arc і, може, ще щось. Я б із радістю, але всі non-chromium браузери просто мають відсталий devtools, особливо Safari. Це, до речі, геморой, коли робиш додатки на Tauri, бо він юзає Safari.

На Arc уже підзабили - в них нова ідея, та й взагалі їх, здається, купили Atlassian. Але й Chrome трохи напрягає вже. Він усе більше тупить у щоденній роботі.

Але ось на горизонті є новинка, про яку я думав написати раніше й тупо забув. Називається Ladybird.

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

1. Це не черговий браузер-обгортка Chrome, який просто додає АІ до всього підряд. Навіть навпаки - на сайті нічого про АІ не написано.
2. Він написаний з нуля (плюс-мінус).
3. Має відкритий код.

Просто скачати його поки не вийде, але можна стягнути репозиторій і зібрати самому. Зовсім недавно вони написали, що браузер уже проходить 90% тестів (хз, чи це об’єктивно), але він явно рухається до релізу. Та ще й має декілька великих спонсорів, тож не мав би вивітрити всі кошти.

Не знаю, чи це буде гарний досвід, чи ще один Safari, але час покаже.

https://github.com/LadybirdBrowser/ladybird

Щоб робити гарні відео треба справді запаритись

Колись я на 4 айфоні міг ізі набирати текст і не промазував (переважно). А зараз на суттєво більшому екрані я ніби отупів і пальці стали вдвічі грубші. А щей такі баги, кайф

https://x.com/NekoMichiUBC/status/1979948046352871821

npm install на 7 хвилин

Було б цікаво, якби був live chart по вижатих еспрессо під час AWS downtime. Там точно був би скачок, ну бо що ще робити як не каву, коли купу сервісів відпочивають?

Коли в фейсбуку стало надто тісно....

Крім 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