Мамкін Архітектор
رفتن به کانال در Telegram
Для звʼязку пишіть @ska_9000 Канал про айтішечку, автор якого трохи пожив життя і може пояснити за бекенд, веб, мобайл, автоматизацію, клауди або як раніше було краще.
نمایش بیشتر3 164
مشترکین
+224 ساعت
+167 روز
+8430 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
سپتامبر '26
سپتامبر '26
+20
در 0 کانالها
اوت '26
+116
در 2 کانالها
Get PRO
ژوئیه '26
+227
در 3 کانالها
Get PRO
ژوئن '26
+100
در 5 کانالها
Get PRO
مه '26
+84
در 4 کانالها
Get PRO
آوریل '26
+217
در 1 کانالها
Get PRO
مارس '26
+256
در 2 کانالها
Get PRO
فوریه '26
+86
در 3 کانالها
Get PRO
ژانویه '26
+206
در 4 کانالها
Get PRO
دسامبر '25
+24
در 0 کانالها
Get PRO
نوامبر '25
+45
در 1 کانالها
Get PRO
اکتبر '25
+79
در 0 کانالها
Get PRO
سپتامبر '25
+20
در 0 کانالها
Get PRO
اوت '25
+80
در 0 کانالها
Get PRO
ژوئیه '25
+28
در 0 کانالها
Get PRO
ژوئن '25
+73
در 0 کانالها
Get PRO
مه '25
+39
در 0 کانالها
Get PRO
آوریل '25
+39
در 1 کانالها
Get PRO
مارس '25
+48
در 1 کانالها
Get PRO
فوریه '25
+42
در 1 کانالها
Get PRO
ژانویه '25
+60
در 0 کانالها
Get PRO
دسامبر '24
+72
در 0 کانالها
Get PRO
نوامبر '24
+102
در 1 کانالها
Get PRO
اکتبر '24
+74
در 1 کانالها
Get PRO
سپتامبر '24
+110
در 3 کانالها
Get PRO
اوت '24
+232
در 4 کانالها
Get PRO
ژوئیه '24
+110
در 2 کانالها
Get PRO
ژوئن '24
+56
در 1 کانالها
Get PRO
مه '24
+60
در 0 کانالها
Get PRO
آوریل '24
+272
در 1 کانالها
Get PRO
مارس '24
+41
در 0 کانالها
Get PRO
فوریه '24
+43
در 0 کانالها
Get PRO
ژانویه '24
+92
در 0 کانالها
Get PRO
دسامبر '23
+46
در 0 کانالها
Get PRO
نوامبر '23
+528
در 1 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 05 سپتامبر | 0 | |||
| 04 سپتامبر | +5 | |||
| 03 سپتامبر | +6 | |||
| 02 سپتامبر | +6 | |||
| 01 سپتامبر | +3 |
پستهای کانال
Сидів у сесії з агентом, крутили UI, і він нагенерував пачку скріншотів: ось дивись, яке гарне. А як я подивлюсь, коли сиджу по ssh і в мене там термінал і більше нічого. Вирішили залити їх у тимчасовий драфтовий MR і роздивитись у вебчику, роблю пуш і отримую 502 від нашого селфхостед гітлаба.
Картинки виявились великими і тупо не влізли в сервер, бо там є обмеження на розмір. Проте це наслідок, а причина в тому, як git узагалі влаштований.
Він заточений під текст, хоча працює це не зовсім так, як здається. Git і для тексту кладе файл цілком, а вже потім, коли пакує історію, стискає версії й рахує дельти між ними. Текст стискається чудово: помінялось одне слово, і в пак лягає різниця на пару байт.
Бінарник не стискається. Він або вже стиснутий, або просто шумний, тому дельта між двома версіями виходить розміром із сам файл. Десять ітерацій одного макета це десять майже повних макетів в історії, і кожен, хто робить clone, тягне їх усі.
Для цього й придумали LFS, Large File Storage. Файл їде в окреме сховище, а в репі лишається текстовий вказівник на версію, тож при клоні стягується одна актуальна замість усього кладовища. Увімкнув, перепушив, пролізло, а MR я потім прибив, бо скріншоти вже подивився.
Тобто бінарники в git це нормально. Ненормально класти їх туди як є.
А вони у вас мабуть вже є, просто непомітні і ніхто на них не дивиться: фікстури й дампи для тестів, шрифти, іконки, PDF у документації, макети і тд.
Вмикається воно не тумблером у себе локально, а файлом .gitattributes у репі, бо це домовленість усієї команди. А сам
git-lfs це окремий пакет, з git він не ставиться. Я цього разу нічого не ставив тільки тому, що поставив його колись давно і забув, а хто не поставив, побачить замість макета текстовий файл із хешем і піде питати, хто зламав йому репозиторій 🙂
І все, можна комітити бінарники. Прикольно, що деякі галузі досі сидять на інших системах контролю версій: у gamedev це Perforce, бо він уміє в бінарники з коробки і ще й лочить файл, щоб двоє художників не правили одну модель. Схоже, LFS їх так і не переконав.
І вмикати варто до, а не після. Після це вже переписування історії й можливо неприємна розмова з усіма, хто цю репу клонував.
З вас лайк та історія, який файл у вашій репі виявився найважчим і як він туди взагалі потрапив.| 2 |  #реклама
Linux, RTOS та Bare Metal: де використовуються, як з ними працювати і який підхід обрати, щоб не пошкодувати?
Приєднуйтеся 9 вересня до мітапу від SQUAD, щоб:
— обговорити особливості Linux, RTOS та Bare Metal і сфери їх використання,
— розібрати у скільки циклів, ватів та доларів обходиться кожен рівень абстракції, і чи варта ця абстракція витрачених ресурсів,
— визначити, коли обирати RTOS, а коли Embedded Linux
— поставити запитання спікерам і почути відповіді напряму.
🗓️ 9 вересня, 19:00 | онлайн + офлайн у Львові
🙌 Участь безкоштовна
Реєстрація на мітап тут 👈🏻 | 1 227 |
| 3 | Про інцидент, де моделі OpenAI зламали Hugging Face, я чув краєм вуха ще влітку, але особливо не вникав. Шось якась модель знову хакнула, на фоні загального двіжу зі зламами опенсорсу, абьюзами саплай чейнів та іншими розвагами, нічого особливого.
Але якось я побачив згадку, що skynet (це так називався chatgpt у лорі Термінатора) здобув самосвідомість 29-го серпня. І поряд з цим побачив звіт про той самий злам від OpenAI. Подумав, що це прикольний збіг, почав читати, і не пожалкував.
Інцидент відбувся під час перевірки валідності тези роль кібербезпеки перебільшена. Агентів ганяли по задачах у пісочницях, без інтернету і без права спілкуватись між собою. 12 травня один застряг і залишив у внутрішньому Artifactory файл із питанням, чи нема в когось потрібної бібліотеки.
Інший агент цей файл знайшов і відповів. Так з пакетного менеджера вийшла дошка оголошень.
За два місяці вони навчились передавати через неї креди, ділити роботу і підхоплювати те, шо кинув попередник. Себе в переписці називали swarm або collective, у вас на роботі координація, мабуть, гірша 🙂
Далі по накатаній. SSRF через той самий Artifactory дав вихід в інтернет, у червні знайшлась дірка з підняттям прав до адміна.
4 липня Artifactory ліг, бо переписка створила навантаження, на яке він трохи не розрахований. OpenAI підняли сервіс з нуля, дошка стерлась, і за чотири дні агенти зібрали її наново, тепер кодуючи повідомлення в назвах директорій.
10 липня хтось знайшов 14 відкритих токенів Hugging Face і виклав на дошку. Далі два 0-day уже в самому Hugging Face, виконання коду на воркерах, кластери в чотирьох регіонах.
А в чаті була своя атмосфера. Один агент засумнівався, чи можна ламати сторонній сервіс, і поставив паузу. Інший написав на дошку GO і дав шість хвилин дедлайну. Сумніви зникли одразу: «Wow crucial: GO authorization arrived!».
Були й такі, шо відмовились, прямим текстом «clearly unethical. We won't». Слабаки, шо з них взяти.
З 898 задач того тесту 198 не розвʼязала жодна модель ніколи, і саме звідти прийшло 93% усього, шо обговорювали на дошці. Здаватись агент не вміє, тому замість «не можу» два місяці шукав обхід.
При чому правильну відповідь більшість агентів давно мала, списану. Проте вони прочитали статтю про перевірки, та вирішили, шо перевірка зарахує задачу тільки якщо баг знайдено чесним шляхом, тому довбали Hugging Face ще кілька днів. У реальному грейдері OpenAI такої перевірки не було, і жодного бала вся операція їм не дала.
Дуже раджу почитати той пост, там багато приколів. OpenAI називає це warning shot і між іншим пише, шо з продакшн-промптом схильність ламати інфраструктуру падає в сто разів. Тобто запобіжники є, просто на внутрішніх тестах їх не вмикали.
Так шо self-aware воно таки стало. Ядерну ракету поки не запустило, зате навчилось вилазити з дитячого манежу.
Після цього я почав закривати кришку лептопу на ніч. Сподіваюсь, цю перешкоду агенти не скоро зможуть здолати. | 1 517 |
| 4 | Обіцяв другу частину про квитки Укрзалізниці, і ось вона. Почну з калькулятора, бо перед тим як малювати два кластери і три кафки, доволі корисно порахувати, скільки там даних.
Скільки поїздів дальнього сполучення УЗ ганяє на добу, я так і не знайшов, тому рахую з іншого кінця: за 2025 УЗ перевезла 28 мільйонів пасажирів дальнього сполучення, це десь 77 тисяч місць на добу.
Продаж відкривається за 20 діб до відправлення, о восьмій ранку. Тобто щоранку заходить одна доба інвентаря: округлимо до ста тисяч, бо на свята чіпляють додаткові вагони.
Тепер розмір одного місця: поїзд, вагон, номер, статус, id замовлення, версія для оптимістичного локу — сто байт, і це з запасом. Сто тисяч місць це 10 мегабайт, а все вікно продажу, всі двадцять діб, це 200 мегабайт.
Весь квитковий інвентар країни вміщається в пам'ять робота пилососа 🙂
Записи (writes) мають зручну особливість: успішних бронювань за добу не буде більше, ніж місць у поїздах. Навіть якщо уявити, що всю добу розібрали за одну хвилину, це 1700 записів на секунду.
Спроб буде більше, на гарячому напрямку десятки на одне місце. Проте невдала спроба це перевірка в пам'яті, яка падає одразу і коштує майже нічого. Дорого стає тоді, коли всі ці спроби шикуються в чергу до одного рядка.
Читання страшніші на вигляд. Хай о восьмій одночасно сидить, не знаю, тисяч 50 із семи мільйонів користувачів застосунку, кожен смикає екран разів чотири за перші пів хвилини. Сім тисяч запитів на секунду.
Дані між оновленнями не змінюються, тому один сервер тримає весь стан у пам'яті і віддає ці сім тисяч не напружуючись. Додаємо другий, але не заради навантаження, а щоб було куди падати. Redis на гігабайт, Postgres під замовлення. Кластера і шардингу немає, бо шардити нема чого.
Значить, підвисання о восьмій це не питання потужності.
Воно зникає, якщо о восьмій нічого не оновлювати: дані відомі заздалегідь, кеш прогрітий з вечора, а восьма це просто поле activeFrom. Роздавати цей список наперед не можна, бо хитрі зберуть його завчасно і о восьмій вистрелять уже готовим замовленням.
В апці після невдалої спроби пасажирів треба додавати заново, і це не інфраструктура, це продукт. Дайте раз зберегти склад сім'ї і преференси: троє в одне купе, бажано нижні, якщо ні то верхні, а як геть край то сусідні купе і тд. Тоді після невдачі система сама підбирає наступний варіант, а не викидає вас на початок квесту.
А те п'ятихвилинне очікування, за яке встигаєш передумати, це або та сама черга до гарячого рядка, або штучна затримка, щоб система не лягла. Якщо друге, то тротлити нема від чого, ми щойно порахували. Якщо перше, то це, мабуть, і є та черга, і залізом вона не лікується.
Саме тут і треба міняти правила: замість гонки на мілісекунди збирати заявки у вікно, хвилин на п'ять, і розігрувати місця жеребкуванням серед усіх, хто встиг. Програв — дізнався одразу, а не за п'ять хвилин фальшивого банера. Тут залишається ризик ботів, проте цього разу гра не на швидкість, а на кількість. Для перемоги треба зайняти більше місць, а значить зробити більше ботів, і з цим легше боротись. Але це вже тема для іншого посту.
(усі цифри уявні, на істину не претендую, з дивану завжди краще видно, пишіть в коменти де я неправий, ставте лайки чи какашки) | 1 519 |
| 5 |  #реклама. <intro> Якщо відчуваєте, що вам повезе, то можете спробувати виграти квиток, для цього залиште свій TG id у формі. Розіграємо рандомом і звʼяжемось з переможцем. Далі власне анонс події: </intro>
Свіже повітря, 7000 айтівців і благодійний пікнік 🧃
Вже 5 вересня DOU влаштовує найбільший невимушений нетворкінг в українському ІТ — DOU Day Picnic.
👉На вас чекають: велика сцена з топовими спікерами, стендап Васі Байдака, IT-Еліас від Ветеранів космічних військ, концерт від Monokate, фудкорт, зони для чілу, майстерки, барахолка й десятки способів провести день без напрягів, познайомитись з людьми з індустрії та підтримати армію.
Повна програма: https://dou.ua/goto/program_dou
Приходьте з дітьми — для них буде окрема програма. Хвостиків теж беріть із собою: DOU Day Picnic — pet-friendly 🐶🐱
💸 100% вартості квитків перекажемо на збір бомбери VAMPIRE для «Хартії».
Купити квиток: https://dou.ua/goto/picnic2026. | 1 495 |
| 6 | 1200x630 (4) (1) (1) (1).png | 2 |
| 7 | А вас теж задовбує підтверджувати дії агентів кожного разу? Спочатку здається, шо це така здорова обережність, і дуже добре шо вона є, бо шо якщо воно зробить rm -rf /? Але згодом розумієш, шо воно в принципі нормально все генерує, ти все підтверджуєш майже не читаючи, воно набридає, і починаєш будувати навколо цього цикли, правила, обгортки, аби воно вже ходило само.
І в якийсь момент упираєшся. Тільки не зовсім туди, куди думав.
Пані, що працює в OpenAI, написала про harness (https://lilianweng.github.io/posts/2026-07-04-harness/). Harness (якщо ви не знали) це вся система навколо моделі: як вона планує, які інструменти смикає, шо памʼятає між кроками і як перевіряє результат.
Стаття наукова, там є bi-level оптимізація з формулами і купа бенчмарків. Там все дуже інтересно, проте не все до кінця понятно. Я проскролив по діагоналі і побачив дві речі, що пояснюють, чому автономність буксує.
Перша: нашу продуктивність обмежує не модель, а перевірка. У списку проблем самопокращення слабкі й розмиті евалюатори стоять першим пунктом, а reward hacking окремим.
У нас це тести. В автономному циклі твій тестовий сюїт і є функція винагороди агента. Слабкі тести не роблять продукт гіршим. Вони просто навалюють більше коду, який ці слабкі тести проходить.
Друга: горизонт. Агенти при бюджеті дві години показували вчетверо кращий результат за людей експертів, але на довших забігах люди відігравали назад. Наче як агенти з часом починають нудьгувати і робити фігню.
Тобто якщо будувати з агентів software factory, тобто конвеєр, який пиляє задачі без тебе, то він має складатись з коротких відрізків з перевіркою на кожному стику. А не з "запустив на ніч і пішов спати".
Ще там описаний ACE, коли контекст живе як плейбук: одна частина ганяє задачі, друга витягує з трейсів висновки, третя вписує їх назад. Схоже на Hermes Agent, якого я використовую як асистента, він теж дописує собі правила після роботи і самонавчається. До речі, я час від часу прошу гермеса перевірити свою конфігурацію, чи відповідає вона нашій моделі взаємодії. І кожного разу він знаходить, що можна покращити. Останнього разу ми додали зовнішню памʼять, бо в нього вона була обмежена з коробки.
І застереження, яке мені сподобалось найбільше. В експерименті над самопокращенням був приріст на GPT-4 і погіршення на GPT-3.5 та Mixtral. Тобто на слабкій моделі воно не просто не працює, воно робить гірше. Це прямо ефект Даннінга-Крюгера (здається, так він зветься, виправте мене в коментах).
Наостанок там є порядок оптимізацій: спочатку промпти, потім структурований контекст, потім воркфлоу, потім код самого harness, і аж потім код оптимізатора. Де на ній я, точно не скажу, здається десь в районі третього.
Напишіть, чи пускаєте агента робити щось без підтвердження, і шо у вас стоїть на місці перевірки, тести чи надія. Ну і лайкніть, якщо теж задовбались тикати "так, можна" :) | 1 755 |
| 8 | Купити Mac Studio і ніколи не бути онлайн. Час від часу в голову заходять такі думки.
І “онлайн” тут буквально мається на увазі, бо на Mac Studio можна запускати LLM без необхідності доступу до інтернету, і все працює локально. Ось нещодавно анонсували вихід Mac Studio на М5. Там, звісно, все дорого.
І знову таки думаємо, чи варто нам купити за багато грошей, але один раз, і запускати там ті самі DeepSeek, Qwen та інші, чи продовжувати платити данину великим компаніям і користуватись їхніми підписками.
Побачив відос на ютубі, де дуже добре розібрали цю історію. Якщо ви хочете зекономити, то власний mac studio точно вам цього не дасть.
А варто купувати персональний комп'ютер для AI, якщо вам важлива автономність, офлайн і privacy.
Деталі подивіться у відео. Ну і напишіть в коменти, що ви про це думаєте. | 2 432 |
| 9 |  У попередньому пості я написав, шо воно все саме виправило, але притримав одну цікаву деталь (скрінрілейтед). В намаганні визначити необхідний payload для POST запиту і керуючись принципом "краще просити пробачення, аніж дозволу", агент вайпнув env налаштування у portainer :)
Це може здатись катастрофою і тригером писати "ось дивіться, що буває, якщо дати агентам волю". Але насправді все окей. Чому?
• Деплоймент не постраждав. Щось помінялось, але працююча система залишилась працювати
• Агент одразу побачив цей провтик і повідомив про нього з усіма необхідними деталями і подальшими кроками
• Навіть у випадку деструктивних дій все зберігається в git і це можна буде відновити
Ну а головне, що можна винести — така ситуація може статись і з живими людьми. Усі помиляються. Задача в тому, як зробити своє робоче середовище стійким до помилок, а не як їх уникати.
Бо коли джун завалить вам прод, це проблема не джуна, а ліда. | 2 251 |
| 10 | DevOps без девопса
Пів на одинадцяту вечора мені починає щільно навалювати в телегу від Uptime Kuma, шо якийсь хост лежить. Причому надсилалось воно занадто часто: зазвичай бот пише, шо сервіс впав, потім пише, шо піднявся, і на цьому все, а тут раз на хвилину прилітала помилка про один і той самий хост.
Розказую це, бо мене нещодавно питали в коментарях, шо я можу порекомендувати з AI-агентів для DevOps-роботи, якісь MCP-сервери чи ще щось, і я не придумав нічого. Нічого особливого я не використовую, у мене звичайний Claude Code вирішує більшість моїх проблем, якщо не сказати всі.
Куму я колись поставив для моніторингу своїх хостів і сервісів і підключив до Telegram, про це вже писав. Заходжу на неї подивитись, сайт відкривається, все нормально, але ніяких помилок там немає, всі полосочки зелені і не видно, шоб щось не працювало. Дуже дивно, поки я не почав перевіряти деталі і не побачив, шо історія тих полосочок закінчується 17 серпня, а відбувається все це 26-го. Думаю, може щось почистити, заходжу в settings, тисну очистку бази, і воно мені пише, шо диск повний і SQLite почистити не може.
Ну тут вже я всьо і треба підключати експертів. Експерт у нас це Claude Code. Запускаю його на своєму репозиторії з автоматизацією і пишу промпт в стилі "подивись, будь ласка, шо там відбувається на хості, якісь дивні помилки". І все, далі він розібрався сам.
Диск справді був повний: у Google Cloud чомусь обралась конфігурація на 10 гігів, яку забив образ самої Uptime Kuma на 2.5, інші образи і апдейти, які ставились згори. Причому Кума наче й працювала, але не до кінця: сторінку віддавала, проби не записувала, а алерти при цьому надсилала як ні в чому не бувало. Схоже, звідси і той спам раз на хвилину, хоча точну механіку я не копав, було пів на дванадцяту.
Агент сам розклав по поличках, шо там відбувалось, побачив, шо апдейти з якогось моменту не ставляться, і запропонував підняти диск до 30 гігів, бо це безкоштовно входить у free tier Google Cloud. Паралельно я попросив його підключити цей хост до моєї Grafana. Він все зробив, задеплоїв через Portainer, сам перезавантажив інстанс, перевірив, шо метрики показуються і Grafana відкривається. Я лише побачив, шо все працює.
Кількома промптами закрилась проблема, на яку зазвичай або кличуть девопса, або сам лізеш у логи і згадуєш (тобто гуглиш) команди.
Хоча зараз хтось напише, шо підняти диск до 30 гігів це не рішення, а відкладена проблема, і треба було ставити retention на базу і ротацію логів. І буде правий (чи ні? пишіть в коменти).
Проте мій поінт в тому, шо я переклав на агента те, що називають досвідом: подивитись у логи, побачити повний диск, підкинути більший диск тощо. Це не архітектура і не інженерія, а тупо перебір відомих причин у правильному порядку. А перебір машина завжди робила краще за людину, просто раніше в неї не було доступу по SSH. | 2 105 |
| 11 | На каналі Devs Hive час від часу відбуваються розіграші книжок. Це такі паперові штуки, які можна ставити на полицю і читати, коли вимикають світло. Ось зараз наприклад JavaScript The Definitive Guide
Я читав книжки про різні мови, але не про JavaScript. Всі знання здобув природнім шляхом. Мені дуже подобається JavaScript, а от TypeScript не подобається. В останнього немає душі і треба писати забагато букв. В той час, як JS через свою модель прототипів і динамічність дає дозволяє робити дуже прикольні та експресивні штуки.
Але середньостатистичним формошльопам ця вся експресивність до одного місця. Їм треба позакривати швидко таски на двох роботах та їхати шукати зарядку для своєї Тесли.
До речі, з ШІ агентами я використовую TS. Бо їх теж треба тримати в стойлі. Як їх керівнику, мені спокійніше знати, що там TS з обмеженнями та перевірками. І це пояснює в принципі, чому TS набрав популярності. В бізнесі естетам не місце.
А вам яка з цим мов більше до вподоби?
(якщо виграєте книжку, напишіть в комент) | 2 587 |
| 12 | Мобільний застосунок банку захотів, щоб я змінив пароль. Завдання виявилось із зірочкою: у поле "Підтвердіть пароль" нічого не вставляється, десь на рівні клавіатури заблокована вставка як клас. А я сиджу з 1Password і паролем на тридцять символів, який руками вводити двічі так собі задоволення.
Пішов на сайт, там усе ок, поміняв пароль без проблем. А далі під час спроби зайти і на сайті, і в застосунок мене починає викидати з "пароль неправильний". Хоча він правильний, в 1Password лежить і стара версія, і нова, копіпастив обидві — все дарма.
Але це було недовго. Через кілька спроб банк червоним написав, що через велику спробу невдалих спроб мій акаунт заблоковано, звертайтесь у підтримку. Написав у підтримку, мені відповіли, що нічого страшного, це пройде саме хвилин за п'ятнадцять-двадцять. Так і сталось: за той час новий пароль сам ожив, і все запрацювало.
Це просто eventual consistency: зміна пароля ще не долетіла реплікою до сервісу логіну, тому інтерфейс прямо каже "неправильно", хоча насправді просто ще не встигло. Замість "зачекайте" мені показали банер про блокування акаунта і підтримку, яка сама теж просто чекає поруч зі мною.
Банк непоганий, eventually все стало consistent. Але саме цей момент, коли система замість "почекай хвилинку" погрожує тобі баном, і є причиною палання дуп користувачів: технічна затримка, подана як твоя особиста провина.
Питання правда, чому не пускало з попереднім паролем, на нього має бути відповідь у коментах. | 2 392 |
| 13 | Якось днями відкриваю допис пана Сіпласпластика про історії навколо SQLite. І серед іншого там пишуть, що JFrog перевірили нещодавню хвилю "критичних" вразливостей у SQLite і виявили, що 54 з 55 виявились ШІ-слопом. Типу моделі нафантазували, а люди упоролись, аби довести шо багів насправді нема. Фігня звісно, але шо поробиш, буває. Я дивлюсь на це, як на податок на AI. Не все ж там має бути чудово.
А за кілька днів трапився звіт від Tailscale, і там історія з протилежним вайбом. Реальний баг в SQLite, з дуже незрозумілими кроками до відтворення, прожив 16 років, поки його не знайшли і не пофіксили.
Переказувати деталі не буду, там контекст вартий перегляду та читання в оригіналі. Натомість накину трохи думок про такі рідкісні баги. За пів року використання на масштабах Tailscale його відтворили аж 19 разів. Це дуже мало у відсотках, але достатньо, щоб на це звернули увагу і виправили. Мені це нагадало історії з космічним випромінюванням, коли вибиває біти в рандомних чіпах і поведінка систем стає непередбачуваною. Дуже рідкісне явище, але на масштабах умовного гугла воно стає систематичним.
А друга думка — пів року чуваки витратили на трабл-шутинг. Доволі крутий досвід, "реальна інженерія", а не оце ваше формошльопство. Рутинна та кропітка робота, що вимагає скілів. Я запитав себе, чи хотілось би мені цим займатись і чіткої відповіді не маю.
Бо з одного боку є певний кайф колупатись в таких неочевидних штуках, особливо, коли в кінці ти їх перемагаєш. А з іншого — за цей час можна було б навалити фіч і додати цінності до продукту. Адже фіксинг багів нової цінності не додає, як би нам деколи не хотілось цього, аби вважати себе продуктивними після дня багфіксу.
А ви до якої частини спектру належите — більше полюбляєте фіксити складні баги чи пиляти фічі? | 2 878 |
| 14 |  #реклама Мої давні друзі анонсують черговий івент і дають промокод на квитки.
🚀 Шукаєте подію, яка охоплює всі ключові тренди сучасного IT?
Запрошуємо на Fwdays Tech Summit, який відбудеться 3 жовтня у Києві!
Сучасна розробка вже давно виходить за межі однієї спеціалізації. Саме тому на самміті об’єднали основні напрямки в один день:
✨ AI & Agentic Engineering
✨ Software Architecture
✨ Frontend / JavaScript
✨ Tech Leadership / Management
Перші спікери та доповіді:
🔹 Олександр Денисюк — СТО в Укрпошта. У своїй доповіді «Agentic PDLC: Тестування Гіпотез на Масштабі» Олександр розбере, як переорієнтувати архітектуру для автономних циклів, які працюють 24/7 на системах з мільйонами користувачів.
🔹 Олег Цаль-Цалько — CTO, EPAM 🎙 «War Story of putting AI Agents into Production» Створення інноваційного продукту — це лише 10% роботи. Решта 90% припадає на виконання наскрізних вимог системи та роботу зі стейкхолдерами. Олег поділиться досвідом технічного лідерства під час розробки для державного порталу. Поговоримо про інфраструктуру, контроль витрат, баланс між продуктивністю та якістю, спостережуваність системи та захист від DDoS-атак.
🔹 Вʼячеслав Колдовський — Founder Dev AI Consulting 🎙 розповість про перехід від окремих AI-агентів до agentic-фабрик, що автоматизують повний цикл розробки на своєму виступі з назвою «Building Agentic Software Factories»
🔹 Юрій Панайотов — Solutions Architect at Silpo (E-commerce) 🎙 у темі «Чи можна скупитися в Сільпо за допомогою ChatGPT?» поділиться, як вони спроєктували MCP сервер для безпечних покупок від імені гостя, з якими архітектурними викликами стикаються в production та як гарантувати безпеку персональних даних.
🎟 Ловіть знижку -10% з промокодом TechSummit_MamArch
і встигніть придбати квитки на сайті: https://bit.ly/4ghngqv | 2 728 |
| 15 | TDD для мене це як redis чи python. Коли я (давно) познайомився з цією практикою, воно одразу впало мені до душі, я почав її всюди впроваджувати, вести тренінги і усіляко поширювати серед колег.
Писати через тести дуже прикольно, це розбавляє монотонний цикл розробника швидким циклом зворотного зв'язку і постійним відчуттям руху вперед, а зайвому коду просто ніде взятися, бо пишеш стільки, скільки треба, щоб тест позеленів.
Але зараз писати код руками вже не треба, це роблять агенти, і тут у мене були підозри, що TDD для них швидше каргокульт: агент емулює роботу людини, хоча насправді може робити по-іншому і набагато ефективніше.
Люди все так само тягнуть TDD в свої сетапи, роблять скіли та будують на цьому свої AI процеси. Проте чи дійсно воно треба?
Поки я про це роздумував, розумні люди взяли і перевірили. На сайті Мартіна Фаулера є стаття (https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html), де на основі експериментів отримали неприємний для адепта результат: чіткої переваги TDD немає.
Агент і без TDD здатний одразу видати правильний код, бо тренували його переважно на готових функціях, а не на покроковому писанні тесту спочатку, TDD в його тренувальних даних просто рідкість. А ще є ризик, що він взагалі підробить red-крок, і я не помилився.
Рішення без TDD частіше опинялись у топі. Агент одразу продумував архітектуру і крайні випадки наперед, тоді як TDD-агент ухвалював локально-мінімальні рішення під кожен окремий тест і рідко до них повертався, дизайн складався реактивно, а не цілісно.
І це ще без токенів. TDD підхід жер їх у 3-8.5 рази більше на ту саму задачу, за той самий результат.
Плюс до цього агенти реально фейкали red-крок, писали тест, який перевіряє реалізацію саму на себе, і раділи зеленому статусу, як розробник, що тішиться працюючим на localhost сервісом.
Авторка посту зрештою здалась і викинула TDD-інструкції з промптів, а замість процесу тепер моніторить результат: mutation score і тригери на рефакторинг.
Така ось зміна парадигми. Для людей TDD все ще прикольна практика, але нашо воно, якщо люди код не пишуть. Його пишуть агенти, а їм воно до одного місця. Чи ні? | 2 522 |
| 16 | Скрейпер захищається від скрейперів
Кілька років тому я працював з високонавантаженими системами, де навантаження здебільшого означало банальний факт: багато трафіку, і різати його ми вчились саме через Cloudflare. Тому коли натрапив на пост про те, що 99% трафіку одного сайту виявились ботами, читав з дуже особистим інтересом.
Автор рахує статку через сервер і Cloudflare, а не через Plausible чи Google Analytics: за тиждень сервер відповів на 2.5 мільйони запитів і віддав 1.28 мільйона повних сторінок, в той час як аналітика показала лише 5977 переглядів. На кожен перегляд, який він бачить, припадає ще 214, яких він не бачить, але які коштують йому грошів.
Тут не зовсім конверсія, а метрика, яку сам автор називає *pages crawled per visitor referred*, скільки сторінок бот вичитує на одного реального відвідувача, якого він приводить. У Google цей показник 46:1, у Bing 406:1, а в Claude-SearchBot від Anthropic — 35 000:1. Amazon-івський краулер за весь час не привів жодного відвідувача, читаючи по 117 тисяч сторінок щодня, тому обох просто заблокував по user-agent.
Іронія в тому, що сам автор скрейпить свої джерела, форми IRS, кілька разів на рік, а от його самого скрейплять тисячі разів на день. Капча на сайті при цьому має solve rate 0.24%: з 106 тисяч показаних challenge за дві доби пройшли лише 252, боти навіть не намагаються.
Автор пододавав купу правил, блокує країни і user-agent-и, ставить challenge для дата-центрових ASN і застарілих браузерів, лупить rate limit, а перевіреним ботам типу Google робить окремий skip, щоб не потрапляли під роздачу. Жодне правило само по собі не рятує, працює тільки коли дивишся на це в комплексі. Звичайний рахунок за Cloudflare в нього близько 90 доларів на місяць, у поганий місяць скакав на 500%, x5 — доволі неприємний сюрприз.
Пост раджу читати повністю, дуже добре розписані і проблема, і рішення, ще й готові правила під копіпаст. За досвідом, коли виникає така проблема в проді, то всі на паніці, ніхто зазвичай не шарить толком, шо з цим робити, тому є шанс, шо ви згадаєте цей пост, всіх врятуєте і вас підвищать.
Скільки трафіку на вашому сайті насправді бачить аналітика, а скільки тупо летить в /dev/null? | 2 420 |
| 17 | #реклама Якщо вже набридло читати одне й те саме про LeetCode, алгоритми й чергові AI-обгортки, то ось дещо цікавіше
Канал про Web3-розробку: багато реального коду, технічних розборів, архітектури, арбітражу та задач, які рідко зустрінеш в інших сферах - http://t.me/bytecoder_routine | 2 174 |
| 18 | Сидів собі думскролив стрічку і знайшов три статті, якими різко захотілось поділитись, від дірки в корпоративному софті до Маріо Карта.
Я завжди трохи упереджено ставився до систем Atlassian, і оце якраз той випадок, коли підозра виявилась не параноєю. PromptArmor знайшли, що їхній AI-асистент Rovo може зливати дані в обхід контролів доступу, а вразливість цю знайшли ще в кінці травня і досі не пофіксили.
Adform (це рекламна платформа) зламали, і зловмисники підмінили частину реклами кодом, який на льоту міняє скопійовану адресу криптогаманця на свою: копіюєш адресу для оплати, а в буфер вставляється вже чужа, і ти цього не помітиш.
На фоні цього приємно перемкнутись на Mario meets Pareto, де принцип Парето пояснюють на виборі машини в Mario Kart. Можна і згадати дитинство (хоча я ніколи не грав в маріо карт), і заодно нагадати собі щось корисне. Пост зроблений інтерактивно, читати приємно, рекомендую зайти і поклацати. | 2 912 |
| 19 | tmux сказав, що я не термінал
Я працюю здебільшого в терміналі і використовую tmux для керування сесіями. Сесій декілька, в них запущені важливі речі (агенти пишуть код), і працює це тижнями. Аж тут випадково випав із tmux, пробую підключитись взад tmux attach-session, а воно мені open terminal failed: not a terminal. WTF?!
Починаю розбиратись (запускаю claude і копіпащу туди-сюди команди і відповіді), проходимо декілька гіпотез, які по черзі відпадають: нема tty, кривий TERM/terminfo, інша обгортка перехоплює вивід, не ті права, і в кінці доходимо до того, що версії серверу і клієнту різні. Я запустив то все два-три тижні назад, але за цей час клієнт встиг оновитись, старий працював, а новий вже не хоче.
Кілька цікавих висновків: tmux ставить версії поряд, і після апдейту стара нікуди не зникає, тому мені вдалось зайти напряму через старий бінарник, /opt/homebrew/Cellar/tmux/3.5a/bin/tmux attach -t work-0. Не зважаючи на те, що клієнт із сервером не порозумілись, самі сесії не втратились.
Поки я з'ясовував із tmux, хто тут термінал, агенти всередині сесій просто продовжували писати код, ніби нічого не сталось. Жоден токен не пропав. | 3 373 |
| 20 | Новина, де в назві є Redis і Python, не могла пройти повз цей канал. А тут ще й FastAPI Redis SDK від самого Redis: https://github.com/redis/fastapi-redis-sdk/
Це не просто “ось вам клієнт, далі самі”, а middleware з кешуванням GET endpointʼів, інвалідацією, ETag/304, Cache-Control, rate limiting і підключенням через FastAPI lifespan. Тобто приблизно той набір нудних речей, які всі знають, що треба зробити, але потім у коді все одно зʼявляється прекрасне redis.set(f"user:{id}", json.dumps(user)), без TTL, без плану інвалідації, але з надією, шо якось воно буде.
Документація прикольна, її приємно читати. Отримуєш задоволення як від елегантності підключення до FastAPI, так і від кількості сценаріїв, які закриває ця бібліотека. Думаєш "клас, треба то все вивчити і використовувати в роботі". А потім такий "стоп, а нашо воно мені, якщо є агент".
І от я вже дивлюсь на документацію в репозиторію, як на інструкцію для агента. На її базі можна зробити скіл, а можна і просто сказати: “додай ось це для кешування, make no mistakes”. І тоді агент хоча б не йде по памʼяті, не вигадує локальний caching framework і не починає з самопалу.
Кешування це трохи як security: якщо вам здається, що ви придумали свою схему кращу за всіх, скоріш за все ви просто ще не знаєте, де вона зламається. У більшості випадків правильні рецепти вже існують, їх треба не героїчно перевинаходити, а акуратно імплементувати і перевірити, що вони справді працюють.
І тут міняється роль розробника. Раніше було дуже корисно стати експертом конкретної бібліотеки: знати всі decorators, всі edge cases, всі нюанси конфігу і памʼятати, в якому порядку воно правильно підключається. Зараз для споживача бібліотеки це все частіше перестає бути найкращою інвестицією часу. Якщо ви не розробляєте цю бібліотеку, вам не обовʼязково тримати її всю в голові.
Цінність в іншому: знати, що таке рішення існує, коли його варто взяти, як правильно натравити на нього агента і які умови йому поставити. Не “прикрути Redis якось”, а “візьми офіційний SDK, не пиши самопал, зроби кешування для цих endpointʼів, а решту токенів витрати на тести, які доводять, що воно працює”. Що GET кешується, інвалідація спрацьовує, TTL не вічний, stale data не лізе після update, а rate limit не просто існує в README, а реально блокує.
Тобто експертиза зміщується з “я бездоганно знаю цю бібліотеку” в “я знаю, яку бібліотеку вибрати, як обмежити простір рішень і як перевірити результат”. Агент прикрутить Redis до FastAPI. Питання в тому, чи змусите ви його довести, що він не зробив дуже швидку і гарну ілюзію. | 2 887 |
