Стендап Сьогодні

Що я зробив, що я хочу зробити, і що це все значить.
Повсякденні здобутки в форматі стендапу.
Детальніше в статті

Підписатись на RSS
📢 Канал в Telegram @stendap_sogodni
🦣 @stendap_sogodni@shevtsov.me в Федиверсі

22.01.2026

Досвід використання EcoFlow PowerOcean

Після відключень влітку 2024 я вирішив підійти до резерву живлення серйозно та замовити EcoFlow PowerOcean. Це резерв живлення, що стаціонарно підключається до щитка. В мене однофазний, а є ще трифазний.

Зовнішньо, дуже приємно зроблено. PowerOcean складається в стопочку з батарей, а згори ставиться інвертор. В мене батарея наразі одна — виходить, 5 кВт-год резерву із 6 кВт потужністю. Все це достатньо компактно. Встановив — фізично — я його сам, без особливих труднощів. Двома болтами кріпиться на стіну, плюс стоїть на підставці. Вписалося в коридорі навіть красиво.

До щитка підключав електрик. Хоча схема підключення — нічого складного. Відразу має сенс вивести бойлери поза резервом — бойлер сам собі батарея, а EcoFlow посадить швиденько. Окрема історія — додати лічильник витрат, яких в комплекті з PowerOcean було аж два, на вибір: скрізний та з котушкою.

Значно цікавіше ввести його в експлуатацію. Для того в Україні доведеться зареєструватися як компанія-інсталятор через застосунок EcoFlow Pro. На щастя, це процес прямолінійний. Ну, хіба підтвердження на пошту надходить не відразу. В мене було більше проблем через те, що я хотів уникнути “інсталяції”: в застосунку EcoFlow прилад вже зʼявився, тільки не вмикав резерв. А от виявилося, що це все ж обовʼязково та відразу після “інсталяції” всі функції увімкнулися.

PowerOcean підʼєднується до Ethernet та Wi-Fi, але я б радив залишити модуль Bluetooth також увімкненим, бо він дає доступ до приладу навіть якщо роутер не заживлений. А воно всяко буває. За досвідом.

А найбільше в мене було проблем з тим, що зарядка йшла тільки на 600 Вт. Обшукав вже весь застосунок, та ще й схеми підключення передивлявся. Нарешті, знайшов, що для зарядки від мережі потрібно створити “графік зарядки”, вказати в ньому час — від 0 до 24 годин та потужність — максимальну. І з таким “графіком”, нарешті, прилад розкрився на повну. Абсолютно неочевидно.

Далі… З наявною напругою в мережі треба ставити стабілізатор. Стандартно PowerOcean вибиває вже на 201V - але це можна змінити в налаштуваннях мережі. Втім, низька напруга інвертору загрожує. Я спочатку думав — як це так — низька та загрожує? Проте, що менше напруга, то більше струм при тій же ж потужності — а саме струм і спалить зрештою ваш інвертор. Так що закладайте в бюджет відразу. Плюс, стабілізатор треба брати як мінімум у 2 рази потужніше за інвертор, знову-таки через те, що потужність заявляється при ідеальній напрузі.

Ось так. Щось, гадаю, в нас такі агрегати рідко купують — але я своїм задоволений. EcoFlow є EcoFlow.

21.01.2026

OpenSearch - база даних, яка не дуже шанує свої дані

От цікаво ж, що в OpenSearch/ElasticSearch головним змістом бази є індекси, а не дані.

Дані, тобто документи, можна взагалі не зберігати. Є режим, коли документи не зберігаються, а реконструюються з індексів - synthetic _source. Або взагалі ніяк не зберігати — повертати тільки ID. Пішло це, як я розумію, від того, що ElasticSearch починалася як рушій пошуку для іншої бази.

Але навіть коли ми зберігаємо документи, вони займають другорядну посаду. Доступ до них повільний. Як тільки ми спираємось на інформацію, недоступну з індексів — наприклад, робимо пошук за скриптом - запит уповільнюється в рази.

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

Тобто шукати ми можемо багато, а читати — менше. Ще одна цікава відмінність від типової бази даних. Та дивись, для деяких сценаріїв це дуже вигідно — наприклад, якщо документів дуже багато, але цікавлять нас одиниці. Як-от типове зберігання журналу. А для інших сценаріїв — взагалі не підходить.

20.01.2026

Що там у MCP, взагалі?

Спілкувалися про реалізацію мого саморобного MCP, та мені захотілося хоч трохи заглибитися в те, що ж воно в принципі з себе являє.

Цікава технологія LLM, взагалі, в неї спільного із традиційними, знайомими програмами, як в хімії неорганічної та органічної. Жере текст, плюється текстом у відповідь. На тому побудовано 100% всіх інструментів, бо нічого іншого просто немає.

У агентному режимі, наприклад, моделі навчені плюватися певними командами, коли це доречно. Тільки вони все одно видають виклик команди в тексті. Потім програма-обвʼязка — яка й називається “агент” - парсить вихід, помічає в ньому розмітку команди та виконує її. В цілому, для LLM що згенерувати сонет в стилі Шекспіра, що виконати команду оболонки — задачі однакові.

Якщо в моделі є можливість виконати код оболонки, то технічно вона вже здатна робити майже будь-які дії. Довгий час саме так я ними й користувався. Але. В такого способу є стеля. Команди стають надто складними для практичного використання. В них і помилитися легше, і контекст вони забивають дедалі більше.

Взагалі, LLM ніколи не варто використовувати для задачі, яку може виконати звичайна програма. Та MCP є звичайною програмою, що абстрагує складніші задачі та робить це з алгоритмічною точністю.

Model Context Protocol надає LLM інструменти, де кожна команда виконує більше логіки, має складніший стан тощо. Самі команди тривіальні: довільний JSON на вхід, довільний JSON на вихід. До того MCP містить можливість перелічити наявні команди та інші зручності.

Все це звучить трохи зайвим. Ну хіба в нас недостатньо протоколів та схем? Сама специфікація MCP порівнює стандарт із USB-C. Може, не найпозитивніше порівняння. Чи нагадує MCP xkcd 927? Авжеж.

Але з усім тим, MCP є технологією теперішнього часу. Такий вже zeitgeist. Згенерувати обгортку для вашого API, випустити у світ, зловити трошки уваги на хвилі ШІ. Навіщо нам суворі специфікації, якщо “текст в текст” достатньо добре працює?

19.01.2026

Динамічність — абстракція, яка тече

Хотів прокоментувати пост з Федиверсу. Якщо коротко: чому в JavaScript звернення pixels[i*2+1] буде швидше за pixels[i].x? Ну тобто, чому масив значень швидше за масив обʼєктів зі значеннями?

Якби це був C чи навіть Go, то відповідь зрозуміла. Там масив — це блок даних в памʼяті, а обʼєкти — окремі блоки. Це зрозуміло, наприклад, тому, що для зміни довжини масиву його потрібно виділяти наново. Операції з безперервним блоком памʼяті - швидше. Але ж JavaScript дозволяє нам взагалі додавати елементи в будь-який індекс масиву, не зважаючи на його довжину. Тобто масиви в JavaScript - це очевидно не просто блок памʼяті. Чому ж все одно масив швидше?

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

(Хто працює з C чи Go підтвердить — що там як раз легко зробити масив структур, який буде такий саме швидкий, як “голий” масив. Якщо це були структури, а не вказівники. Де-де, а в C оголошення структур для споживання блоків памʼяті — класична техніка.)

В JavaScript можна піти далі та зробити масив типу Float64Array. От він вже точно буде єдиним блоком памʼяті, як в статичній мові — з такими саме обмеженнями. Якби я робив щось з графікою, то, мабуть, його б і використовував… якщо без нього було б повільно, не треба оптимізувати наперед!

До чого я це все… Навіть в мові, яка не змушує тебе думати про розмір масиву чи типи даних, все одно різні мовні конструкції будуть швидше чи повільніше — незалежно від алгоритмічної складності.

16.01.2026

Думати та діяти

Зловив себе на тому, що справи зрушуються тоді, коли починаєш діяти.

Чи це очевидно? Ну якщо дивитися в ретроспективі, то може й так. Як кажуть англійською, hindsight is 20/20. Можна скільки завгодно думати та планувати — від того у світі нічого не зміниться.

Ну, тільки в мене постійно зʼявляється причина не діяти. Давно вже припинив вірити класичному “немає часу”. Не тому, що він є — навпаки, часу завжди немає, а все-таки, якісь справи робляться. Час то взагалі ілюзія.

Загалом, в мене, діяти заважає те, що справа не продумана. Тобто маємо певну пастку: щоб діяти, треба спочатку подумати. Якщо довго думати, знову нічого не зробиш.

Та, наступна знахідка: скільки не продумувати, але контакт зі світом неодмінно змінює розуміння та плани. Хай то буде розробка нового модуля чи планування відпустки — дуже рідко я відразу, в голові знаю всі нюанси.

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

Також ділюся способом, який мені дуже допоміг останнім часом: замість пошуку єдиного кращого варіанту, я ставлю собі задачу знайти пʼять варіантів. Пʼять готелів, пʼять продуктів, пʼять альтернатив рішення. Так розслабляється внутрішній критик. Потім чарівним чином зʼявляється той самий правильний вибір — або ж, як писав вище, розуміння того, що навіть питання потрібно переглянути.

15.01.2026

Розширення можливостей помічника ШІ засобами MCP

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

Для тих, хто не знає, MCP (Model Context Protocol) - це спосіб дати агенту ШІ нові інструменти. Типовий агент з коробки вміє редагувати файли, виконувати команди оболонки та шукати в інтернеті. А шляхом MCP до нього можна додати буквально будь-які функції.

Для того нам потрібний сервер MCP. Це допоміжна програма, яка спілкується з оболонкою агента пакетами JSON. Оболонка запускає сервер, забирає з нього набір доступних дій, та робить доступними для агентів. А коли агент звертається до певної дії, передає команди сервера MCP та той їх виконує. Сервер MCP є звичайною програмою та отримує доступ до локальних ресурсів — наприклад, може прочитати файл конфігурації. Також сервер запускається надовго, а значить, може мати власний стан — чи навіть підключення до інших сервісів.

Все це звучить помірно цікаво, якщо мова йде про загальні MCP. Ну може, такий, що вміє надсилати пошту. Ще й з чужим кодом всередині.

Але ось моя головна думка тут: не обовʼязково шукати чийсь незрозумілий MCP. Ти завжди можеш згенерувати собі свій, під конкретні обставини та задачі. Так, я відразу кажу “згенерувати”, а не “написати”, бо писати власноруч сенсу мало. А агент цілком здатний згенерувати MCP за твоїми вимогами.

Мій приклад такий: хотілося мати консоль Rails на стейджингу. Тоді значно спрощується перевірка невидимих частин логіки, бо агент може це робити власноруч. (Ба більше, оскільки він знає код проєкту, то що писати в консоль, теж добре розуміє.) Отже, згенерував MCP, який і знає, як на стейджинг потрапити, і де взяти ключі. Зручно надзвичайно.

14.01.2026

Google BigQuery

Я взагалі не люблю Google Cloud. В них все не як у людей. Але якщо є причина користуватися Google Cloud, то це буде BigQuery.

BigQuery - це база даних OLAP. Не потребує розгортування, тобто доступна як сервіс. Легка на підйом та безрозмірна. Заливаєш туди дані, робиш запити. Працює все швидко навіть на терабайтах даних.

Тут, мабуть, ще відступлю та скажу, що таке база даних OLAP. Така база спроєктована для виконання рідких складних запитів на великих обсягах даних. В протилежність базам OLTP - з якими звикли мати справу розробники — як PostgreSQL чи MySQL тощо. Важливо розуміти, що в базах OLAP завжди закладена “стартова ціна” та навіть на маленьких обсягах вони будуть дорожче та повільніше. Якщо база OLTP здатна грати роль OLAP, поки даних мало, то навпаки не вийде.

В BigQuery легко збирати дані — власне, для OLAP-бази це необхідність. Я навіть писав конектор через gRPC. Але того робити не обовʼязково — є купа вбудованих рішень — наприклад, через Cloud Storage. Або з журналів, звісно.

Зверху BQ є Looker Studio - платформа для звітів та графіків. Наші аналітики від всього цього в захваті. А інженерам важливо знати, чого хочуть аналітики.

Головний недолік BigQuery, для мене — це навіть не сама ціна, а те, що вона привʼязана до обʼєму оброблених даних. Та можна легко пробити дно навіть простим запитом, якщо він достатньо широко бере. Треба бути обережним.

13.01.2026

Вайб-видалення коду

Що, думаєте, LLM здатні тільки генерувати код? Поганий, брудний, зайвий код?

А якщо я скажу, що сьогодні видалив понад 1000 рядків коду — повністю через Cursor? Власноруч не видалив жодного рядка! Просто написав запит, зачинив очі, та — код зник!

Йдеться про певну застарілу функціональність, яка знята з використання ще три роки тому. Але видалити не було нагоди, бо ця тисяча рядків коду розкидана по багатьох частинах та шарах застосунку. Досі вона сиділа та чекала, поки в когось зʼявиться зайвий день, щоб її вичистити. (А не зʼявиться він ніколи.)

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

Агент все знайшов за лічені хвилини. Причому це ж Rails, тому рядки треба шукати як BlueMoon, так і blue_moon, а на фронтенді ще й redMoon - бо функціональність колись перейменували. І тести вичистив. І маршрути. І всі згадки в інших моделях. Ще й Rubocop заспокоїв.

(До речі: що стосується Rubocop та інших інструментів, то я роблю так: запускаю, та якщо щось йде не так — виділяю весь вихід комбінацією Cmd+Shift+Up та надсилаю агенту: Cmd+L. Нехай розбирається.)

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

12.01.2026

Реверс-інжинірінг власної мети

Початок року — традиційний час, коли люди думають про майбутнє та ставлять цілі. Потім про них забувають, бо цілі надто розбігаються з реальністю.

Адже в реальності в нас і так завжди є певна мета. Тут, як на мене, важливо розрізняти мету політичну та фактичну. Перша — те, що ми проголошуємо назовні. Друга — керує нашим життям.

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

Ну, наприклад, непогана мета - “забезпечувати сімʼю” чи “бути корисним на роботі”. Може, воно не так яскраво звучить, але в усвідомленні таких речей зʼявляється особиста свобода — далі ти їх робиш, бо ти хочеш, а не тому, що від тебе хочуть.

Втім, піти в спортзал та добре харчуватись теж завжди вчасно.

А ще на цю тему є комікс.

09.01.2026

Не люблю додавати сервіси

Знаєте, я колись грався в мікросервіси. Один раз. Вистачило.

Зараз в мене сувора нелюбов до створення сервісів. Нехай буде не так красиво, зате ефективно.

Та й де там красиво. Красиво — це поки не вглядаєшся. Та не думаєш про ціну розділення.

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

Та й в коді ще один застосунок — теж ціна. Бо тепер доведеться окремо стежити за стилем. Повторювати базові речі. Оновлювати залежності.

А тепер ще й комунікувати з додатковим сервісом буде складніше. Треба API робити. Злагоджувати. Спрощувати інтерфейс: ніякого спільного стану, ніяких замикань.

Тому мені завжди хочеться обійтися мінімумом сервісів. Одним? Та ні, можна взагалі не робити власних сервісів та взяти щось на кшталт Firebase. Оце так!

Раніше