Bardin speaks

Новина пройшла трохи повз мене, тому хоч і з запізненням, але ділюся нею з вами. Влад Фурдак, той самий що писав для DOU гайди по вивченню .NET, а також власник та головний контрибʼютор найбільших .NET комʼюніті в Україні створив свій ТГ канал. https://t.me/VladyslavFurdak Влад активно взявся за створення контексту ту доволі часто пише про наболілі теми. Загалом - переходьте, дивіться та за бажання підписуйтесь. Контент дійсно гарний. Ну а від себе додам - це прекрасно, коли україномовний простій поповнюється класними кріейторами. Владе, вітаю!

Моя помічниця)

Як то кажуть - щоб випадково профукати півмільярда доларів, треба мати півмільярда доларів. Нам так не жити.

От нарешті на DOU серйозна дотНет стаття з хардкором того рівня, що колись запустив цей канал. До того ж це Андрій Курдюмов, що на пів шишечки залітав вже на цей канал і колись можливо загляне ще! Читати треба не тому, що ви будете писати свій обфускатор чи навіть використовувати чужий, а тому що: - Це просто цікаво вам як розробнику - Трохи глибше розуміти платформу https://dou.ua/forums/topic/59685 (Апіхи для дебагерів, обфускаторів, профіліровщиків це прямо дуже цікава штука у всіх стеках)

Можливо якимось дивом на мене підписані QA спеціалісти? Відгукніться, будь ласка, в коментарях чи в особисті - є певна пропозиція до вас)

Я впевнений, що серед 186 людей є ті, хто активно тренуються. Діліться секретами, як ви переживаєте день ніг ;(…

Нє, ну це вже традиція…

Оновлене посилання: https://youtube.com/live/yqd_VLKlA7Y?feature=share

У мене ні дня без приколів з OBS. За декілька хвилин дам посилання

Під час чергового інциденту у Github Actions можемо спостерігати наслідки AI SDLC🤷

Понеділок день важкий ;(

Останнім часом помітив кілька не дуже приємних тенденцій, про які хочеться поговорити. Доступ до швидкого створення рішень для більшої кількості людей — це, звісно, круто. Але водночас це буквально двері в цифрове пекло, якщо за цими рішеннями немає базового інженерного мислення. 1. Люди нормально не тестують свої рішення І часто навіть не розуміють, як це робити на фундаментальному рівні. Для багатьох усе зводиться до: “happy path спрацював — значить, усе ок”. Наприклад, той самий плагін для Excalidraw справді зміг згенерувати мені діаграму. Але виглядала вона жахливо. І тут одразу питання: автор взагалі тестував edge cases? Перевіряв різні типи вхідних даних? Дивився, що буде на складніших сценаріях? 2. Немає базового розуміння оптимізації токенів Згенерувати дві діаграми мені коштувало щось близько 30к токенів. Це дуже багато для такої задачі. І проблема не лише в ціні. Проблема в тому, що люди часто не думають про архітектуру промптів, кешування контексту, розділення задач, формат вхідних/вихідних даних і загальну ефективність рішення. 3. Коду стає більше, а підтримки — менше На фоні того, що коду генерується все більше за одиницю часу, якість і кількість підтримки цих рішень просідає. За останні кілька днів я бачив близько 10 репозиторіїв з різними skills/plugins/tools, де висять десятки відкритих PR-ів, але активності майже нуль. Тобто рішення ніби є, люди ним користуються, хтось навіть намагається щось покращити, але підтримка фактично відсутня. 4. Підтримувати такі рішення стало складніше Бо значна частина PR-ів — це AI slop, згенерований без нормального контролю, без розуміння контексту проєкту, без тестів і без відповідальності за результат. У підсумку мейнтейнер отримує не допомогу, а ще більше роботи: треба розбиратися, що саме згенеровано, чи воно взагалі має сенс, чи не ламає існуючу логіку, чи не тягне supply chain ризики, і чи не додає ще більше хаосу в кодову базу. І от у цьому, на мою думку, головна проблема: AI сильно знизив поріг входу в створення софту, але не знизив складність відповідальності за цей софт. Згенерувати рішення стало простіше. Зробити його якісним, безпечним, дешевим у підтримці й придатним до реального використання — ні

Ось так буває: ставиш собі якийсь скіл, а він у подарунок тягне supply chain ризики, бо банально не пінить версії залежностей. Це ж не складно. Якщо ви робите скіли, плагіни, темплейти, CLI-тулзи чи будь-що інше - піньте версії. Так, у майбутньому це вимагатиме підтримки та ручного оновлення. Але натомість ви отримуєте значно кращий захист від купи потенційних проблем: від неочікуваних breaking changes до більш серйозних supply chain інцидентів. А щоб не пропускати нові версії залежностей - налаштуйте Dependabot у репозиторії. І буде вам щастя

Вівторок, 26 травня — перший стрім по OpenVitals. На стрімах будуємо self-hosted платформу для агрегації даних з носимих девайсів. Але це половина сюжету. Друга половина — AI-driven SDLC як практика, а не як слоган. AI використовується постійно в кожній фазі розробки — від планування до рев'ю коду. Паралельно ж будуть експерименти з підходами, інструментами, воркфлоу. Що працює, що ні — покажу чесно, включно з факапами. Тобто на стрімах буде: - реальний проєкт від пустого репо до production deployment - AI як повноцінний учасник команди, а не «autocomplete на стероїдах» - обговорення рішень вголос — чому саме так, а не інакше Перший стрім: огляд проєкту, розбор архітектурних рішень, розклад наступних фаз. Практично — «laying the groundwork» в прямому ефірі. Де: YouTube, https://youtube.com/live/__B0KzBcICI?feature=share. Запис залишиться. Коли: вівторок 26 травня, 19:00 за Києвом. Якщо щось термінове по роботі прилетить — перенесу і попереджу за день

Думаю сьогодні Усик провів один із найважчих і найцікавіших боїв за дуже довгий час. РІко не будучи боксером в класничному розумінні показав неймовірний рівень техніки та майстерності з дуже-дуже сильним суперником. Загалом, ситуація із зупинкою бою за секунду до завершення раунду виглядає суперечливою, але не мені судити та коментувати - я не боксер. Проте, як би там не було - думаю в 12 раунді Усик знайшов би як добити. А от якби справа зайшла б у підразунок очок - не знаю, чесно.. Ріко весь бій давай гідну відповідь, і подекуди я б сказав виглядав впевненіше за Саню. Але, результат на табло, Усика вітаю з перемогою, та бажаю продовжувати ставити та досягати амбітних цілей. 🇺🇦 🇺🇦 p.s. окремої поваги заслуговує промова Верховена після поєдинку, де він не скотився у треш-ток, а прямо сказав, що вважає зупинку передчасною, але визнав поразку. Це, як на мене, найвищий рівень професіоналізму та спортивної етики

А хтось ще помітив, що Claude та Claude Code почали дуже агресивно всюди пхати \n\r?! Я зараз дуже багато працюю з markdown файлами, і це пісець як задовбує. Задовбує настільки, що я вже почав всюди писати щоб він НЕ додавав їх де це непотрібно

Подумав, подивився на аналоги — проєкту бути. Робоча назва — OpenVitals. Self-hosted платформа, яка агрегує дані з носимих девайсів (Garmin, Oura, далі — як піде) і робить з ними те, чого вендорські аплікухи структурно не вміють: дивиться на дані з кількох джерел одночасно. Три речі, які змінилися відносно перших начерків: 1. Жодних "який девайс точніший". На сирі значення впливає 100500 неконтрольованих факторів — позиція на руці, температура шкіри, рух уві сні — надійно ранжувати девайси неможливо. Замість цього система дивиться на патерни: чи HRV впала на обох девайсах одночасно, чи тільки на одному. Узгоджений сигнал = довіряємо. Розбіжність = окремий сигнал сам по собі, не помилка. 2. Модульний моноліт + окремі інжестори. .NET бекенд, React фронт, на кожен провайдер — окремий контейнер-інжестор, який абстрагує вендорське API від моноліту. Розгортається в k3s або просто docker compose. Без мікросервісів, без "а раптом 1000 користувачів". 3. Мультикористувацька з першого дня. Не SaaS — кожен піднімає в себе. Але архітектура з самого початку рахує, що користувачів кілька, а не один. Код відкритий, все робиться публічно

А тим часом, вчорашньому стріму залишилось менше 20 переглядів для того, щоб стати найпопулярнішим відео на каналі. Тому, хто ще не дивився - запрошую до перегляду 👇 https://www.youtube.com/live/fuZ7ac1Brxs?is=blc-DEp-dDRO2C4q

Я щасливий власник Garmin Fenix 8. Ну, принаймні я так думав. Загалом це справді класний девайс. Він знає про тебе достобіса всього: відстежує показники, тренування, активність, відновлення — і в цьому класі йому, здається, майже немає рівних. Проте навіть тут не все ідеально. І є одна велика проблема. Насправді — не одна. Перша проблема — дуже закрита інфраструктура. Настільки закрита, що отримувати дані в реальному часі від Garmin практично неможливо. З цим ще можна жити: наприклад, через певні сторонні інструменти можна витягувати дані з акаунту й далі щось із ними робити. У мене вже понад пів року є Grafana з дашбордами по даних з Garmin. Вони кожні 5 хвилин витягуються скриптом з акаунту. Також є невеликий агент, який працює з локальною SQLite-базою і вміє аналізувати ці ж дані. Це все ще не ідеальний флоу, але він працює — і я реально можу цим користуватися. Проте є друга проблема, рішення якої я поки не бачу. Це якість метрик сну й усього, що з цим пов’язано. Бо будь-який годинник, наскільки я розумію, не трекає сон достатньо точно. Водночас є Oura Ring 4 від європейського бренду — один із найточніших consumer-девайсів для трекінгу сну, який за деякими дослідженнями наближається до медичних рішень. Зараз я дуже багато уваги приділяю здоров’ю, фізичній активності, сну та відновленню. Саме тому почав думати про покупку Oura — щоб краще відстежувати сон, recovery та загальний стан організму. Плюс у них є багато інших даних — загалом близько 50 метрик — і сама каблучка виглядає як класний аксесуар. І тут виникає питання: як усім цим користуватися і кому вірити? Який девайс точніше вимірює конкретний показник? Garmin чи Oura? Що брати як основне джерело правди для сну? А що — для тренувань, активності, пульсу, стресу, відновлення? Просто вивантажувати дані з двох систем, двічі дивитися на одні й ті самі графіки й вручну робити метааналіз усього цього зоопарку — не дуже хочеться. Тому я думаю зробити щось простеньке на .NET, Python та React, загорнути це в красивий UI і сховати всю шерехатість інтеграцій, систем та метааналізу даних під нормальний інтерфейс. Для мене це звучить як дуже прикольний pet project. Але є ще одне питання: чи було б вам цікаво дивитися це у форматі стрімів? Одразу скажу: кількість і частота стрімів, скоріш за все, не будуть дуже стабільними. Але що точно буде: * system design; * brainstorming з AI; * Claude та Codex у розробці; * багато затупів; * багато тупняків; * я, який втикає в величезні `.md`-файли від агентів і намагається зрозуміти, що вони взагалі нагенерували. Тобто це не буде щось дуже швидке, динамічне й відполіроване. Скоріше — реальна робота інженера з AI-агентами така, як вона є насправді. Мені здається, це могло б бути цікаво, бо проєкт закриває дуже широкий спектр тем: від планування й проєктування до розробки, інтеграцій, запуску та реального використання. Дослідження для контексту: https://pmc.ncbi.nlm.nih.gov/articles/PMC9412437/

Стрім вийшов доволі коротким, але сподіваюсь цікавим. Поділіться, будь ласка, фідбеком як вам, чи все гуд, чи треба щось міняти? Запис тут: https://www.youtube.com/live/fuZ7ac1Brxs?is=V7afg5maUsrmjCkC