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

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

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

07.11.2025

RESTful нічого не значить

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

Річ у тому, що справжнє означення REST ми загубили. Наприклад, ось стаття автору цього терміну; зміст статті взагалі важко прикласти до сучасних API. З іншого боку, ось відносно сучасна стаття з блогу StackOverflow, яка розповідає про щось абсолютно інше.

Практично кожний сучасний API використовує дієслова HTTP та ресурси-іменники. І це чудово, насправді! Я не думаю, що хтось повинен відповідати стандарту REST, справжньому чи уявному. Моя теза в тому, що цей термін став порожнім, та використовується лише для красоти.

І це в гарному випадку, що люди не сприймають епітет “RESTful” та пропускають мимо. А можна ж натрапити на педанта, який серйозно присічеться до вашого API та скаже, що там все неправильно, а ваша команда — дилетанти.

А з дійсно цінних епітетів можу виділити два. “Вичерпний” чи “повний” API це важливо, бо я буду знати, що зможу автоматизувати будь-які операції. Часто упираєшся в те, що API зробили тільки для головних функцій. Та, якщо продовжити цю ідею далі — то буде “API-first” - таких сервісів взагалі небагато, зате інтегрувати їх одне задоволення.

06.11.2025

Навіщо потрібний S3?

Натрапив сьогодні на питання: навіщо s3? та в чому його плюси? та чи можна написати свій?. Люблю такі питання, бо хоч воно здається наївним, але я не сумніваюся, що дехто карго-культить (що таке карго-культ?) S3 та дарма не замислюється. Отже.

AWS Simple Storage Service - це глобальне сховище для всього, що нагадує файли. “Simple” воно у тому сенсі, що ми отримуємо безрозмірне масштабування — як в кількості “файлів”, так і в їхньому розмірі, та високу доступність — в тому числі й по HTTP з браузера. А ще — автоматичне шифрування, контроль доступу, автоматичне видалення за правилами та багато такого, про що я навіть не знаю.

“Простішою” альтернативою S3 буде робити власне файлове сховище. До певного масштабу, зберігати файли не так вже й важко, але ви швидко упретесь у розміри диска чи в пропускну здатність каналу чи в обмеження файлової системи… і так далі.

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

Звісно, особливо S3 стає корисним, якщо наші сервіси мають лише ефемерний диск, бо їм треба кудись зберігати дані. А ще S3 широко використовується в самому AWS для всіляких сервісів. Я був здивований дізнатися, що мережевий диск EFS реалізований через S3, хоча ззовні виглядає як “простіша” файлова система.

S3 став стандартом де-факто для збереження “файлів”. Настільки, що багато (якщо не більшість) сховищ пропонують сумісний з S3 API: Cloudflare, Backblaze, Hetzner і так далі. Тобто я хочу сказати, що якщо вам не подобається Amazon, можна знайти альтернативу та зберегти зрозумілий режим доступу.

Або навіть захостити власний: MinIO, Localstack.

05.11.2025

Як шукати причину збільшення CPU

Є у вас сервіс чи база, та в нього раптом виросло споживання процесора. Куди та як дивитися?

По-перше, тобі потрібні метрики. Та не тільки на цей момент, а історичні. Без метрик ти біжиш в темряві: це весело рівно до першої ями.

До речі: достаток метрик — недооцінена особливість AWS та й інших хмарних платформ. Метрики не даються безплатно, їх треба зібрати та зберегти. Та оскільки для нормальної роботи сервісу метрики не потрібні, цілком ймовірно ми до них так і не доберемось. Зате AWS відразу надає купи метрик для кожної бази та сервісу. Нам залишається тільки про них згадати.

Зростання бувають двох типів. Або планомірні, завдяки збільшенню попиту. Або — коли відбулося несподіване. Скоріше за все, ми дивимося на несподіване зростання — планомірне просто не так часто трапляється. Та з можливих причин я б ставив на нову фічу з необачним споживанням. Щоб це підтвердити, шукаємо smoking gun, тобто прямий доказ.

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

Потім можна перейти в інструмент APM - New Relic, Sentry тощо — та перевірити, яка саме активність корелює. Тут-то ми напевно і побачимо нашу проблемну фічу.

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

04.11.2025

Смачні страви польської кухні

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

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

• Журек — суп з житньої закваски. На вигляд білий такий. На смак — кислий. В нього традиційно кладуть картоплю, домашню ковбасу, та варене яйце. Гадаю, в селі таке було легко приготувати, бо закваска на хліб завжди стояла в домі. Сьогодні в Польщі можна купити її в магазині. А поза Польщею — просто пекти хліб та тримати вдома закваску.

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

• Карпатка - “торт-еклер”. Складається з двох шарів заварного тіста, між якими заварний (або інший) крем. Зверху карпатка посипається пудрою та певною мірою нагадує гори Карпати — заварне тісто сходить горбами. Я в принципі люблю еклери, та щасливий обійти відразу і формування тістечок, і начинення.

А ще є пирОги, запіканки, пачки, крижана зубрівка…. Та макарон з трускавкою. 🍓

03.11.2025

Бази даних відрізняються не тільки швидкістю

Потрапив мені на очі пост Kafka is fast - I’ll use Postgres. Теза в ньому така, що PostgreSQL теж може бути буфером подій, та ще й з непоганою швидкістю, тож нащо та Kafka потрібна?

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

Наприклад. Є у вас критичний шматок інфраструктури, який генерує події. Класичний випадок — телеметрія. Якісь віддалені датчики надсилають показники — та вони точно не пристосовані, щоб зберігати пакети на своєму боці чи пробувати надсилати повторно. Додамо до того ще й те, що оновлювати ПЗ датчика — настільки складно, що, може, ми ніколи цього не будемо робити.

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

Або ось ще практичний приклад. Протягом останнього вильоту в AWS не запускалися функції Lambda. Якщо ваші дані приходили прямо у Lambda - вітаю, їх ніхто не обробив та тепер вони втрачені. А якщо перед Lambda стояла Kafka - то єдине, що загрожувало, це затримка обробки.

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

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

Така надійність та безвідмовність значить більше, ніж чисті показники швидкості.

31.10.2025

Наскільки важливо розуміти спеціалізацію бази даних

Трохи допомагав хлопцям із проблемним навантаженням на ElasticSearch. Виявилося, проблема з запитами, де фігурував пошук зі скриптом. Скрипт виконував операцію на кшталт foo - bar > THRESHOLD.

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

Але як тільки для пошуку доводиться читати самі документи — швидкість провалюється на порядок. Бо з операцій над множинами ми скочуємося до операцій над документами.

Тобто можливість пошуку за скриптом існує, щоб закрити рідку потребу, зробити щось неможливе можливим. Але вона ніяк не годиться для базового функціоналу. Це може приголомшити, якщо ти приходиш з бази загального призначення — як Postgres - де пошук по foo - bar не сильно відрізняється за пошуком по foo чи bar.

В цьому сенсі я завжди любив документацію з Redis - в ній для кожної команди виписана обчислювана складність. Колись я робив складний рушій на основі Redis, та це було критично важливо для планування.

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

30.10.2025

Несподівано складна задача конвертації PDF в інший формат

Проблема: “Синево” тепер дають результат аналізів тільки у вигляді PDF. Для перегляду чи друку це нормально, зате для машинної обробки… Скажімо так, в мене була світла ідея передати результат у ШІ та спитати поради.

…ШІ той PDF прочитав “за діагоналлю”. Наплутав всі показники. Я чогось такого й очікував, тож планував конвертувати PDF в текстовий формат. Виявилося, це нелегко.

Звісно, річ не у тім, що PDF є двійковим форматом. Справжній його недолік в тому, що PDF є більше векторним зображенням, ніж текстом. Там немає аж ніякої структури документа.

В PDF відсутня викладка тексту як така. Кожний безперервний рядок стає окремим елементом файлу. Та й таблиці теж відсутні. Те, що ми бачимо, як таблицю — насправді є супом з текстових рядків. “Глюкоза” з координатами 123,456, “40” з координатами 145, 567, “г/моль” з координатами 156, 634.

З цього супу і параграфи не так легко скласти! А як таблицю — то взагалі задача непіднімна. (Як виявляється.)

Найкраще в мене впорався застосунок Tabula - він принаймні вірно визначив таблицю, тільки підписи з перенесеннями перетворював на окремі рядки таблиці. Технічно, далі можна вручну виправити цю таблицю — позливати рядки разом — але в мене на це часу немає. Залишуся без ШІ-терапевта. 😄 (Бо в такому вигляді він теж читає неправильно.)

PDF - формат абсолютно несемантичний. Це нагадує, як важлива семантичність, наприклад, в HTML. Конвертори PDF у HTML існують, звісно, але залишають зміст у вигляді абсолютно позиційованих елементів <div>.

Звісно, в PDF є й потужна перевага — він ідеально відтворюється як на екрані, так і на аркуші. Я вас тільки прошу пропонувати й альтернативні формати.

29.10.2025

ExifTool та робота над домашньою фотобібліотекою

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

А саме: в Apple Photos немає дерева каталогів, а фотографії насамперед впорядковані за датою. Плюс, звісно, альбоми, ключові слова, геолокація, але це все вторинне. І всього цього в мене взагалі немає. Є вбудована можливість створити з тек на диску альбоми, втім це мені теж мало допоможе — та й не хочу я купу зайвих альбомів.

Отже, виходить, треба підготувати фотографії так, щоб в Apple Photos в них можна зорієнтуватися. Та допоміг мені в цьому ExifTool - програма, яку обовʼязково треба знати для роботи з метаданими фотографій або навіть відео.

Почнемо з того, що вона сама вміє знаходити фотографії в дереві, робити резервні копії, а також навіть виконувати деяку логіку (наприклад, “записати метатег, тільки якщо його ще немає”.)

Потім, ExifTool здатний записати в титул фотографії її шлях. Це збереже той порядок, який був у фотографіях раніше, та принаймні допоможе їх впізнавати.

Далі, мені пощастило, що фотографії були розкладені в теки за роком. Щоб Apple Photos про це теж знав, можна взяти рік зі шляху, та записати у метатег DateTimeOriginal. Тепер хоч приблизно все в порядку!

Вийшло щось таке — вся робота однією командою:

exiftool -r \
  '-Title<${directory}' \
  -if 'not $DateTimeOriginal' '-DateTimeOriginal<${directory; $_=(split m!/!, $_)[1] . ":01:01 12:00:00"}' \
  .

28.10.2025

Long Poll та проблеми зі звʼязком

Памʼятаєш, я казав, що дивним чином під час останнього збою AWS в нас застряг SQS - нічого не отримував, але й не відвалювався? Знайшов причину.

Отримання повідомлень з SQS працює за моделлю Long Poll: клієнт робить запит до сервера, а сервер відповідає тоді, коли в черзі зʼявляться повідомлення. Однак якщо черга порожня, то сервер через зазначений інтервал дасть порожню відповідь. В деяких реалізаціях Long Poll працює інакше — це клієнт обриває підключення. Але в AWS SQS все залежить саме від сервера.

Отже, що відбувається під час обриву звʼязку? Тут є важливий момент: обривів звʼязку не існує. Підключення TCP - це лише домовленість між клієнтом та сервером про майбутній обмін пакетами. Але відрізнити відсутність пакетів від “обриву” просто неможливо. Немає ніякого другого каналу, через який ми можемо “побачити” сервер та дізнатися, чи він досі підключений. Ти знаєш про це тільки з того, що він надіслав тобі пакет.

А отже виходить, якщо клієнт чекає відповідь через Long Poll від відключеного сервера — він ніколи не отримає пакетів, але також не отримає й помилки. І буде чекати звістки… нескінченно.

Вихід з цього зрозумілий: впровадити тайм-аут з боку клієнта. Що взагалі гарна ідея в будь-яких ситуаціях, як бачимо! Обриви звʼязку — абсолютно нормальна ситуація в інтернеті.

В деяких AWS SDK цей тайм-аут вже зробили — наприклад, aws-sdk-js та aws-sdk-php. А в aws-sdk-go - поки ні. Зате його можна додати вручну з тим же ж результатом. Тайм-аут цей повинен трохи перебільшувати інтервал очікування, і тоді ми будемо надійно захищені від обривів.

27.10.2025

Що такого особливого в AWS us-east-1?

Якщо ти трохи спостерігаєш за подіями в інфраструктурі, може в тебе є два питання. Ну те, що us-east-1 - це регіон, тобто ізольована частина AWS, розташована умовно на сході США — сподіваюся, і так зрозуміло. Та, хоч в AWS є понад 30 регіонів, чому здається, що всі користуються AWS us-east-1? Та чому як проблеми з AWS - то обовʼязково саме us-east-1? Вони що дурні?

us-east-1 є найстарішим регіоном в AWS. Звісно, тут набереться найбільше клієнтів, особливо тих, що вже великі та успішні. Але також, цей регіон обріс найбільшим шаром технічного боргу. Попри це…

us-east-1 є першим регіоном для всього нового. Будь-який сервіс спочатку запускається в us-east-1, та інші регіони інколи суттєво відстають. А значить, є суттєво стабільнішими. :) Мабуть, в ідеальному світі самий “заборгований” регіон не був би ще й передовим по фічах, але маємо те що маємо.

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

us-east-1 містить контрольну площину. Такі фундаментальні сервіси, як IAM чи Route 53 - існують саме в цьому регіоні. Тож, деякі проблеми в us-east-1 будуть розповсюджуватися й на всі інші регіони. Наприклад, проблеми з DNS чи моделлю авторизації.

Отже, якщо підсумувати, us-east-1 є “столицею” AWS. Проблеми в ньому й більш ймовірні, й більш помітні, ніж в будь-якому іншому регіоні. Тож немає нічого дивного в тому, що він завжди на слуху.