Engineer — Software — Портфоліо та нотатки

Спроєктувала комплексну інфраструктурну систему для науково‑дослідного інституту, що охопила 14 департаментів, з гнучкими модулями, уніфікованими пайплайнами даних та структурованими стратегіями підтримки для довгострокового впровадження.

2026-10-09T14:31:15+02:00

Ситуація. У науково‑дослідному інституті, що об’єднував 14 різнопрофільних дослідницьких груп, кожна група працювала з різними джерелами даних, форматами, масштабами та програмними інструментами. Технічна експертиза та доступні ІТ‑ресурси суттєво відрізнялися між групами. Хоча декільком групам вдалося створити й розгорнути власні ІТ‑рішення, багато інших стикалися зі складністю власних потреб у сфері дата‑інфраструктури, що відволікало цінний час і увагу від основної дослідницької роботи.

Завдання. Завдання полягало в тому, щоб розробити рішення, яке дозволило б дослідникам зосередитися на науковій роботі, а не на ІТ‑проблемах. Метою було спроєктувати та впровадити масштабовану дата‑інфраструктуру для всього інституту, здатну задовольнити широкі та відмінні одна від одної вимоги більшості дослідницьких груп.

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

Результат. Отриманий план інфраструктури виявився і технічно обґрунтованим, і стратегічно узгодженим із дослідницькими цілями інституту. Він об’єднав бачення управління даними в межах усієї організації, окреслив чіткий шлях до зменшення ІТ‑навантаження на дослідників і заклав основу для спільного, ефективного та готового до майбутнього дослідницького середовища даних. План отримав високу оцінку за інклюзивність, чіткість та адаптивність, задавши чіткий напрям трансформації дата‑інфраструктури інституту.

Прискорила продуктивність пайплайну географічних даних у 50 разів, вдосконаливши SQL‑програмування та моделювання даних у PostgreSQL, MS SQL та Google Cloud BigQuery.

2026-10-09T14:31:15+02:00

Ситуація. Організація стикалася зі значними затримками в обробці великих обсягів географічних даних, що впливало на ефективність процесів прийняття рішень на основі даних та аналітичної звітності.

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

Дія. Було ретельно проаналізовано наявні структури SQL‑програмування та моделювання даних у PostgreSQL, MS SQL і Google Cloud BigQuery, що виявило вузькі місця, пов’язані з неефективними стратегіями індексації, неоптимальним дизайном запитів та відсутністю належних обмежень. Для вирішення цих проблем:

Моделі даних було перепроєктовано для нормалізації критично важливих наборів даних, а також впроваджено стратегії партиціонування для скорочення часу отримання даних.
Застосовано розширені техніки індексації, зокрема B‑tree та GiST індекси для PostgreSQL, фільтровані індекси в MS SQL і кластеризацію в BigQuery.
Оптимізовано складні SQL‑запити шляхом рефакторингу підзапитів, скорочення операцій з’єднання та впровадження матеріалізованих подань там, де це доречно.
Встановлено обмеження цілісності даних, такі як зовнішні ключі та обмеження перевірки, для забезпечення узгодженості даних без шкоди для продуктивності.

Результат. Ці комплексні оптимізації прискорили продуктивність пайплайну географічних даних у 50 разів, суттєво скоротивши час обробки даних. Це покращення уможливило аналітику в режимі реального часу, розширило можливості звітності та надало зацікавленим сторонам своєчасні дані для прийняття рішень, що зрештою сприяло ухваленню більш обґрунтованих стратегічних рішень.

Підвищила продуктивність застосунку географічних карт у 10 разів завдяки стратегічному переходу бази даних з MSSQL на PostgreSQL, включно з data cutover, оптимізувавши обробку та безпеку даних.

2026-10-09T14:31:15+02:00

Ситуація. Географічний картографічний застосунок організації, що підтримував просторові запити в реальному часі для багатьох користувачів, зазнавав серйозних проблем із продуктивністю. Затримки при рендерингу картографічних шарів і виконанні запитів до даних на основі місцезнаходження впливали як на користувацький досвід, так і на надійність бекенд‑сервісів. Система працювала на застарілій базі даних Microsoft SQL Server (MSSQL), яка не мала нативної геопросторової індексації.

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

Дія. Здійснено стратегічну міграцію бази даних з MSSQL на PostgreSQL із розширенням PostGIS для забезпечення нативної підтримки геопросторових даних.

Спроєктовано нову схему, оптимізовану для просторових даних, з упровадженням індексів GIST та SP‑GiST на стовпцях geometry та geography для пришвидшення запитів.
Визначено суворі обмеження зовнішніх ключів і обмеження перевірки для забезпечення реляційної цілісності та застосування правил валідації даних для просторових координат.
Мігровано понад 50 мільйонів просторових записів за допомогою ETL‑пайплайнів із кроками трансформації даних для відповідності новим стандартам SRID (EPSG:4326).
Налаштовано параметри конфігурації PostgreSQL (наприклад, work_mem, effective_cache_size) для оптимальної продуктивності вводу‑виводу за умов паралельного доступу.
Впроваджено рольове керування доступом (RBAC) та безпеку на рівні рядків для забезпечення політик захисту даних для кількох груп користувачів.

Результат. Досягнуто підвищення продуктивності просторових запитів у 10 разів, скоротивши середній час відповіді з 2,5 секунди до менш ніж 250 мілісекунд. Навантаження на CPU бекенду знизилося на 65%, а доступність системи покращилася в періоди пікового навантаження. Рівень безпеки також посилено завдяки деталізованим політикам доступу та обмеженням валідації даних, що зменшило ймовірність пошкодження просторових даних.

Вирішила 1 000 проблем у географічних даних та часових рядах, використовуючи GDAL, ArcGIS, PostGIS, Mapbox, QGIS, SQL (PL/pgSQL, Transact‑SQL), Bash, забезпечивши високоякісну обробку великих даних.

2026-10-09T14:31:15+02:00

Ситуація. Під час роботи над масштабним проєктом геопросторової аналітики команда виявила численні невідповідності й аномалії в географічних наборах даних і часових рядах. Ці проблеми впливали на точність просторового аналізу та інструментів прийняття рішень, що використовувалися в кількох підрозділах.

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

Дія. Просторові помилки систематично діагностувалися та виправлялися за допомогою комбінації інструментів, зокрема GDAL, QGIS та ArcGIS, а автоматизовані робочі процеси на Bash дозволяли пришвидшити повторювані завдання з очищення даних. PostGIS забезпечував виконання складних просторових запитів і просторову індексацію, а надійні процедури на PL/pgSQL і Transact‑SQL використовувалися для управління та трансформації географічних і часових даних у базах даних PostgreSQL та SQL Server. Крім того, очищені дані було інтегровано в інтерактивні візуалізації за допомогою Mapbox, що підвищило доступність даних для кінцевих користувачів.

Результат. Завдяки цим зусиллям було усунено понад 1 000 критичних проблем, що суттєво покращило точність даних і швидкість обробки. Це безпосередньо сприяло скороченню часу виконання просторових запитів на 35% і уможливило проведення командою надійнішого просторового аналізу. Робота забезпечила постійну доступність якісних, готових до використання даних для аналітики та звітності, підтримуючи стратегічні рішення в межах усієї організації.

Спроєктувала, реалізувала та адмініструвала 6 пайплайнів ETL/ELT, використовуючи Google BigQuery, MSSQL, PostgreSQL, Shell scripting, PL/pgSQL та Transact‑SQL, інтегрувавши дані для ефективної обробки через Python API.

2026-10-09T14:31:15+02:00

Ситуація. Організації потрібно було консолідувати та обробляти великі обсяги структурованих даних із віддаленого сховища даних, розташованого за IPSec VPN. Ці дані мали критичне значення для роботи внутрішніх аналітичних дашбордів і зовнішніх Python API, якими користувалися клієнти й партнери.

Завдання. Мета полягала в тому, щоб спроєктувати, реалізувати та підтримувати набір надійних автоматизованих ETL/ELT‑пайплайнів для безпечного отримання, трансформації та завантаження даних у Google BigQuery, забезпечуючи точність даних, продуктивність і масштабованість у всіх системах.

Дія. Було спроєктовано, реалізовано та адміністровано 6 наскрізних ETL/ELT‑пайплайнів на основі кількох технологій, включно з Google BigQuery, MSSQL, PostgreSQL, Shell‑скриптами, PL/pgSQL та Transact‑SQL.

Налагоджено захищені з’єднання з віддаленим сервером, захищеним IPSec VPN, для автоматизації отримання даних.
Заплановано та виконано завантаження стиснутих архівів даних, що містили файли Parquet, CSV та .bak.
Розроблено скрипти на Bash і Python для витягування та класифікації файлів за типом і схемою.
Для файлів .bak резервні копії відновлювалися в локальному екземплярі MSSQL Server за допомогою робочих процесів RESTORE DATABASE, а цілісність схеми перевірялася.
Завантажено структуровані дані в проміжні схеми в MSSQL і PostgreSQL за допомогою інструментів bcp, psql та SSIS, залежно від формату джерела.
Написано модульні та придатні для повторного використання процедури PL/pgSQL і T‑SQL для очищення, нормалізації та збагачення даних відповідно до бізнес‑логіки.
Експортовано впорядковані набори даних і таблиці в проміжні формати, стиснуто їх за допомогою gzip і безпечно передано в бакет Google Cloud Storage.
Автоматизовано процеси завантаження та зіставлення схем у Google BigQuery за допомогою bq CLI та скриптів для завантаження даних на основі Python.

Результат. Ці автоматизовані пайплайни суттєво скоротили ручні витрати та час обробки — з понад 3 годин ручної роботи до менш ніж 20 хвилин наскрізно, водночас покращивши актуальність даних із щотижневої до щоденної синхронізації. Python API, що споживали ці дані, отримали приріст продуктивності на 30%, а покращена прозорість допомогла бізнес‑аналітикам швидше надавати інсайти зацікавленим сторонам. Рішення залишається масштабованим і легко розширюваним для підключення нових джерел даних у міру зростання бізнесу.

Реалізувала 8 проєктів Power BI з докладними посібниками, інтегрувавши інструменти Microsoft Power BI з NodeJS API та Python FastAPI для ефективної аналітики та візуалізації даних.

2026-10-09T14:31:15+02:00

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

Завдання. Розробити інтерактивні дашборди та рішення для звітності, здатні ефективно подавати як дані в реальному часі, так і історичні географічні та електричні дані, даючи змогу зацікавленим сторонам швидко виявляти тренди, аномалії та показники продуктивності.

Дія. Інтегровано Microsoft Power BI з власним бекенд‑стеком на основі NodeJS API та Python FastAPI для оптимізації приймання, трансформації та візуалізації даних. Спроєктовано й реалізовано дашборди з картографічними візуалізаціями, показниками споживання енергії, відстеженням відключень та індикаторами ефективності електромережі. Розроблено багаторазові шаблони та детальну документацію для підтримки масштабованості та зручності використання.

Результат. Успішно реалізовано 8 проєктів з аналітики даних, підвищивши ефективність формування звітів на 60% і давши змогу міжфункціональним командам ухвалювати швидші рішення на основі даних. Зацікавлені сторони повідомили про суттєве покращення розуміння регіональної продуктивності електромереж і точності планування ресурсів.

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

2026-10-09T14:31:15+02:00

Ситуація. Команда управляла величезними наборами даних, що генерувалися розумними лічильниками, встановленими в кількох географічних регіонах. Ці розумні лічильники виробляли деталізовані часові ряди даних про споживання електроенергії, які використовували енергетичні аналітики, інженери та регіональні планувальники для операційних і стратегічних рішень.

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

Дія. Було створено та надано понад 500 детальних аналітичних звітів, використовуючи чистий SQL для виконання всіх завдань з видобування, трансформації та аналізу даних, працюючи безпосередньо в хмарних середовищах, таких як PostgreSQL і BigQuery. Дані включали геолокаційні координати, ідентифікатори лічильників, дані про споживання енергії з часовими мітками та метадані про довкілля. SQL‑скрипти використовували CTE, віконні функції, підзапити та геопросторові з’єднання, що забезпечувало масштабовану та ефективну обробку.

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

Результат. Звіти стали стандартним довідковим матеріалом у різних підрозділах, допомагаючи в балансуванні регіонального навантаження, плануванні енергоефективності та виявленні аномалій. Забезпечуючи повну прозорість і відтворюваність, ця робота допомогла підвищити довіру зацікавлених сторін до даних і сприяла створенню точніших прогнозних моделей та покращенню ефективності операційного планування на 10–15%.

Спроєктувала, створила та керувала 100 базами даних сховищ даних на PostgreSQL, MS SQL та Google BigQuery, переважно з GIS‑даними та часовими рядами, оптимізувавши продуктивність і масштабованість.

2026-10-09T14:31:15+02:00

Ситуація. У технологічній компанії, що стрімко зростала, виникла критична потреба створювати, керувати та оптимізувати різноманітний портфель зі 100+ баз даних у PostgreSQL, Microsoft SQL Server та Google BigQuery. Ці бази даних переважно оброблювали складні набори даних, включно з даними геоінформаційних систем (GIS) (наприклад, просторові координати та аналітика на основі місцезнаходження) і часовими рядами (наприклад, показання сенсорів, логи та метрики в реальному часі). Наявна інфраструктура стикалася з проблемами масштабованості, продуктивності запитів і узгодженості даних, особливо в міру експоненційного зростання обсягу даних. Організації була потрібна надійна архітектура для забезпечення надійності даних і скорочення операційних витрат.

Завдання. Основна мета полягала в тому, щоб спроєктувати, реалізувати та підтримувати масштабовану, високопродуктивну екосистему сховища даних, адаптовану для GIS‑даних і часових рядів. Це включало:

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

Дія. Для досягнення цих цілей:

Спроєктовано масштабовані архітектури:

Створено нормалізовані та денормалізовані схеми для PostgreSQL і SQL Server із застосуванням просторової індексації (наприклад, PostGIS для PostgreSQL) і партиціонування часових рядів для оптимізації продуктивності запитів.
Використано таблиці BigQuery з розбиттям за часом та кластеризацією для ефективної обробки великомасштабних часових рядів.

Впроваджено стратегії оптимізації:

Застосовано техніки оптимізації запитів, такі як індексація, матеріалізовані подання та кешування, для скорочення затримки GIS‑запитів і запитів до часових рядів.
Застосовано стиснення даних і колонкове зберігання в BigQuery для мінімізації витрат на зберігання й підвищення швидкості сканування.

Здійснено співпрацю щодо міжплатформної інтеграції:

Задокументовано найкращі практики моделювання GIS‑даних і часових рядів для орієнтування команд у майбутніх проєктах.

Результат. Ці ініціативи призвели до суттєвих покращень:

Приріст продуктивності: час відповіді на запити для GIS‑даних і часових рядів скоротився на 40–60%, що уможливило швидшу аналітику та прийняття рішень.
Операційна надійність: автоматизований моніторинг скоротив час простою на 50%, тоді як стандартизовані процеси підвищили продуктивність команди та зменшили кількість помилок.
Вплив на бізнес: оптимізована інфраструктура дала змогу компанії запустити нові продукти на основі даних (наприклад, дашборди аналітики в реальному часі) і виконати нормативні вимоги щодо управління даними (data governance).

Ця робота зміцнила здатність організації розв’язувати складні проблеми, пов’язані з даними.

Автоматизувала розгортання GIS SaaS‑застосунку, обробку даних та систему звітності за допомогою GitHub Actions CI/CD, Python, Bash та SQL.

2026-10-09T14:31:15+02:00

Ситуація. Розгортання GIS SaaS‑застосунку, обробка його даних та формування звітів були повністю ручними кроками — а ручні кроки одночасно й повільні, і тихо небезпечні. Кожен реліз забирав час інженерів і ніс ризик помилки, а повторювана робота з даними та звітністю сиділа там, з’їдаючи потужність тиждень за тижнем.

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

Дія. Весь шлях було автоматизовано. Пайплайни GitHub Actions взяли на себе цикл test‑build‑deploy, тож реліз перестав залежати від того, чи хтось пам’ятає всі кроки. Повторювана обробка даних та звіти перейшли в заплановані завдання на Python, Bash та SQL, тож вони просто виконувалися, а не були чиєюсь рутинною роботою. А конфігурація та секрети були стандартизовані так, щоб кожне середовище поводилося однаково — саме це усуває несподіванки на кшталт «у мене на машині працює», бо не залишається «моєї машини», яка відрізняється від продакшну.

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

Автоматизувала постачання 20 пайплайнів GIS‑даних та ETL‑процесів даних застосунку, оптимізувавши автоматизацію інфраструктури та звітність.

2026-10-09T14:31:15+02:00

Ситуація. Платформа працювала на великій кількості GIS‑пайплайнів даних та ETL‑процесів для даних застосунку, які постачалися й контролювалися вручну. Ручні пайплайни створюють вузькі місця, вони втрачають узгодженість, і найгірше — вони несуть постійний невеликий ризик того, що один із них тихо відмовить, і ніхто цього не помітить, доки дані далі за потоком уже не стануть неправильними.

Завдання. Завданням була автоматизація постачання цих пайплайнів та ETL‑процесів — щоб дані надходили надійно та передбачувано без того, щоб хтось їх супроводжував.

Дія. Двадцять GIS‑пайплайнів даних та ETL для даних застосунку перейшли на автоматизоване постачання, від початку до кінця. Планування, логування та обробку відмов було стандартизовано, тож кожен пайплайн поводився однаково і, що важливо, було видно, коли якийсь із них поводився інакше — тиха відмова залишається тихою, лише якщо ніхто не стежить. І їх було вбудовано в наявну автоматизацію інфраструктури та звітність, тож вони стали частиною однієї узгодженої системи, а не шухляди зі скриптами, які хтось мусив пам’ятати запустити.

Результат. Усі двадцять пайплайнів та їхній ETL працювали автоматично й передбачувано, а вся картина автоматизації інфраструктури та звітності стала охайнішою. Бізнес отримав надійні, актуальні дані без того, щоб хтось проводив їх вручну — і без ризику тихої відмови, що висів над цим.

Очолила розробку програмного забезпечення GIS‑картографічного застосунку, збільшивши дохід у 10 разів та позиціонувавши продукт як основний актив даних.

2026-10-09T14:31:15+02:00

Ситуація. Основним викликом була побудова платформи, здатної відстежувати, моніторити та оптимізувати активи відновлюваної енергетики, такі як сонячні панелі та вітрові турбіни. Проте початкове рішення не мало надійних геопросторових можливостей, через що клієнтам було важко візуалізувати розташування активів, аналізувати просторові дані чи отримувати практичні висновки. Розпізнавши цю прогалину, керівна команда пріоритизувала розробку GIS‑застосунку (Geographic Information System) для карт, щоб підвищити цінність платформи та відповідати потребам клієнтів, що змінювалися.

Завдання. Завданням було очолити розробку GIS‑застосунку — критичного компонента для диференціації продукту на конкурентному ринку зеленої енергетики. Роль виходила за межі розробки програмного забезпечення, охоплюючи технічного лідера, DevOps‑інженера, інженера даних та SRE (Site Reliability Engineer), забезпечуючи узгодженість рішення з траєкторією зростання компанії. Метою було створити масштабований, інтуїтивно зрозумілий GIS‑інструмент, що безшовно інтегрувався б із SaaS‑платформою, даючи змогу користувачам візуалізувати розташування активів, відстежувати показники продуктивності та використовувати просторові дані для прийняття рішень. Це вимагало балансування технічних інновацій з обмеженнями зростаючого стартапу, забезпечуючи водночас можливість продукту розвиватися разом із компанією.

Дія. Почалося зі співпраці із зацікавленими сторонами для визначення основних функцій GIS‑застосунку, з фокусом на інтеграцію з наявною SaaS‑платформою та візуалізацію даних у реальному часі. З огляду на невеликий розмір команди, було спроєктовано модульну архітектуру з використанням бібліотек GIS з відкритим кодом, щоб система залишалася легкою й масштабованою. Також були впроваджені пайплайни CI/CD, автоматизоване надання інфраструктурних ресурсів та інструменти моніторингу для забезпечення надійності. У міру зростання команди нових інженерів наставляли, налагоджували міжфункціональну співпрацю та пріоритизували зворотний зв’язок від користувачів для ітеративного вдосконалення застосунку. З часом GIS‑інструмент еволюціонував від базового прототипу до складної платформи, включаючи розширену аналітику та кастомні дашборди для задоволення потреб клієнтів.

Результат. GIS‑застосунок став наріжним каменем SaaS‑платформи, забезпечивши зростання доходу у 10 разів завдяки допродажам, ліцензуванню даних та залученню нових клієнтів. Його здатність візуалізувати активи зеленої енергетики в реальному часі підвищила операційну ефективність для клієнтів, а безперервне вдосконалення інструменту закріпило за ним статус основного інформаційного активу. Успіх проєкту не лише зміцнив репутацію компанії в секторі відновлюваної енергетики, а й продемонстрував цінність міждисциплінарного підходу в динамічному стартап‑середовищі. Поєднання технічної експертизи зі стратегічним баченням зробило GIS‑застосунок ключовим диференціатором, що підживлював довгострокове зростання та інновації.

Керувала full‑stack розробкою GIS‑карт, наглядаючи за PostgreSQL, Mapbox, ReactJS та NodeJS, щоб постачити інтегроване рішення.

2026-10-09T14:31:15+02:00

Ситуація. На цьому етапі GIS‑карта перестала бути просто функцією і стала причиною, чому клієнти взагалі заходили в систему. Проблема полягала в тому, що вона розросталася фрагментарно. Просторові дані зберігалися в PostgreSQL, саму карту малював Mapbox, а застосунок навколо неї складався з ReactJS на фронтенді та NodeJS на бекенді. Кожна частина працювала сама по собі. Просто їх не було побудовано так, щоб вони поєднувалися одна з одною, і шви вже почали розходитися.

Завдання. Роль охоплювала full‑stack розробку карти та відповідний технічний напрям: модель даних, рендеринг, API та React‑фронтенд. Метою було перетворити чотири речі, які випадково опинилися в одному репозиторії, на єдиний продукт, за який не соромно.

Дія. Спочатку було визначено архітектуру, а далі робота велася близько до коду, а не з відстані. З боку даних просторову модель у PostgreSQL підтримували в порядку, щоб запити не сповільнювалися до повзання зі зростанням наборів даних. Mapbox відповідав за малювання; завдання полягало в тому, щоб подавати йому правильні дані на правильних рівнях масштабування, а не все одразу. З боку застосунку код на ReactJS і NodeJS проходив перевірку, команду підштовхували до спільних конвенцій, а відповідальність постійно повертали на той рівень, якому вона належала, щойно вона починала протікати в сусідній. Значна частина цієї роботи була неефектною: виловлювати дрібні неузгодженості, доки вони не застигли в архітектурі.

Результат. У результаті вийшов єдиний інтегрований картографічний застосунок, у якому дані, рендеринг та інтерфейс нарешті тягнули в один бік. Він став ключовою частиною платформи — тим, що команда могла й далі розширювати, не побоюючись, що все ламатиметься щоразу, коли додається новий шар.

Оптимізувала стратегії прогнозування та інвестування для 11 операторів електромереж, підвищивши операційну ефективність за допомогою GIS‑рішень на основі даних.

2026-10-09T14:31:15+02:00

Ситуація. Оператори електромереж живуть і гинуть рішеннями про те, де підсилювати мережу і куди вкладати гроші, а одинадцять із них ухвалювали ці рішення майже без геопросторового аналізу під ними. У них були операційні дані. Чого в них не було — це способу побачити ці дані на карті, там, де насправді живуть закономірності.

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

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

Результат. Оператори отримали прогнози, яким можна довіряти, та інвестиційні рішення, спрямовані на конкретну мету, а не засновані на сподіваннях. Прив’язка планування до того, що показувала карта, зробила весь процес ефективнішим — гроші та увага спрямовувалися туди, куди вказували дані, а не туди, куди вела звичка.

Представила 200 покращень UI/UX для GIS‑картографічного застосунку, збільшивши дохід у 10 разів завдяки вдосконаленим функціям програмного забезпечення.

2026-10-09T14:31:15+02:00

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

Завдання. Завдання полягало в тому, щоб знайти ці розриви і провести виправлення до кінця: роботу з юзабіліті, яка мала зробити продукт простішим для отримання цінності і, не випадково, комерційно ціннішим.

Дія. Замість того, щоб здогадуватися, що не так, робота велася на основі зворотного зв’язку та даних про використання, і з цього утворився беклог із 200 конкретних покращень UI/UX. До них не ставилися як до рівнозначних — їх ранжували за впливом, а ті, що мали значення, відстоювалися і проводилися через команду, щоб бути випущеними як реальні функції, а не як список побажань, що застарівав у документі.

Результат. Інтерфейс став помітно зручнішим у використанні, а цінність продукту зросла відповідно: ця робота сприяла зростанню доходу у 10 разів. Це приклад, вартий того, щоб до нього повертатися, бо він чітко доводить думку — ретельна робота над UX не є косметикою, вона позначається на рахунку.

Керувала виконанням 30 успішних GIS‑проєктів, продемонструвавши керівництво в постачанні інноваційних рішень у галузі.

2026-10-09T14:31:15+02:00

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

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

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

Результат. Усі тридцять проєктів було здано. Ця послідовність важила більше, ніж будь‑який окремий проєкт, — клієнт, який тридцять разів бачив постачання вчасно, не хвилюється за тридцять перший, і ця репутація значною мірою пояснює, чому компанія продовжувала зростати.

Очолила розробку, розгортання та підтримку понад 30 GIS‑проєктів, продемонструвавши експертизу в технологіях PostgreSQL, Bash, Python, JavaScript, GDAL, ArcGIS, PostGIS та Mapbox.

2026-10-09T14:31:15+02:00

Ситуація. Увесь випуск компанії становив GIS «на замовлення» — кастомна картографія та просторові системи, побудовані під конкретну проблему клієнта, а потім підтримувані в роботі після запуску. Побудувати систему — це лише половина справи; геопросторовий проєкт, який запускається, а потім падає в продакшені, насправді не було доставлено.

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

Дія. Постачання охопило понад тридцять GIS‑проєктів, з практичною роботою по всьому стеку. PostgreSQL із PostGIS в основі для просторових даних, GDAL/OGR для перенесення їх між форматами — shapefiles, GeoJSON, GeoTIFF, KML, vector tiles — а також QGIS і JOSM для самої роботи з даними. На фронті — вебкарти, побудовані на Mapbox GL і Leaflet, іноді з використанням API ArcGIS чи HERE, з рівнем застосунку на JavaScript, Python, PHP і SQL. Робота охоплювала діапазон від 2D- і 3D‑цифрової картографії через обробку LiDAR, георектифікацію та векторизацію до карт приміщень і навігації в них. І відповідальність не закінчувалася на моменті запуску — розгортання та подальша підтримка в продакшені теж входили до неї, тож проблеми не передавалися комусь іншому; з ухваленими рішеннями доводилося жити.

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

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

2026-10-09T14:31:15+02:00

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

Завдання. Участь у процесі UI‑дизайну була частиною ролі — допомагати робити інтерфейси такими, що люди справді вважали б їх інтуїтивними та приємними у використанні, а не просто функціональними.

Дія. Роль не була роллю дизайнера, але вона була присутня в процесі дизайну і привносила інженерну перспективу — акцентуючи увагу на розкладці, на потоці проходження завдання, на тому, чи справді екран був зрозумілим, чи лише звичним для тих, хто його побудував. Це були фронтенди на React, Angular і Vue поверх карт Mapbox і Leaflet, і значна частина юзабіліті полягала в деталях: як фільтрувався набір даних, як відбувався перехід між поверхами на карті приміщення, чи повідомляла система, що саме вона робить. Здебільшого це означало ставити «наївні» запитання від імені користувача рано, поки їх було ще дешево виправити, а не після релізу, коли плутанина поверталася у вигляді звернень у підтримку.

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

Реорганізувала внутрішні процеси, заощадивши 8 000 годин завдяки вдосконаленню архітектури програмного забезпечення, систем та ефективності планування.

2026-10-09T14:31:15+02:00

Ситуація. У внутрішніх процесах накопичилися типові нашарування — архітектура програмного забезпечення, що розросталася стихійно, а не за задумом, системи, які працювали, але неефективно, і планування, через яке люди то простоювали, то були перевантажені. Нічого з цього не «горіло», саме тому це й залишали без змін, але тихо це коштувало багато часу.

Завдання. Метою було докорінно переглянути ці процеси — знайти витрати й усунути їх, а не продовжувати за них платити.

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

Результат. Переробка зекономила приблизно 8 000 годин завдяки суттєвому підвищенню ефективності архітектури, систем і планування. Це потужності, які пішли безпосередньо на роботу з вищою цінністю, а не на накладні витрати, які раніше ніхто навіть не ставив під сумнів.

Розробила систему звітності Data Analytics, збільшивши квартальний дохід від програмного забезпечення на 400% завдяки PDF‑звітам на базі Python.

2026-10-09T14:31:15+02:00

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

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

Дія. Систему звітності, яка генерувала PDF‑звіти на Python, було побудовано так, щоб автоматизувати весь ланцюжок: вибірку даних, проведення аналізу та представлення результатів у чіткому, узгодженому форматі, який зацікавлені сторони справді могли прочитати. Суть полягала в регулярності та ясності — той самий професійний звіт з’являвся передбачувано, тож цифри стали тим, на що люди дивилися як на звичну справу, а не тим, що доводилося самостійно розшукувати.

Результат. Саме ця звітність спричинила зростання квартального доходу від програмного забезпечення на 400%. Покращення й пришвидшення аналітики не було просто зручністю для бек‑офісу — коли перед людьми, які ухвалюють комерційні рішення, з’являються чіткі й своєчасні цифри, рішення стають кращими, і тут це напряму позначилося на доході.

Розробила 100 вебзастосунків за допомогою HTML/HTML5, CSS/SCSS, Django, WordPress та Joomla, забезпечивши різноманітну онлайн‑присутність.

2026-10-09T14:31:15+02:00

Ситуація. Клієнти хотіли вебзастосунки, і хотіли вони дуже різні речі — різні масштаби, різні бюджети, різні рівні від «просто виведіть мене онлайн» до «зробіть мені щось індивідуальне». Відповідати цьому означало бути універсальним, а не заганяти кожного клієнта в межі однієї й тієї самої технології.

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

Дія. Було створено сто вебзастосунків, і суть полягала в тому, щоб підбирати інструмент під завдання, а не мати улюблений. Там, де клієнту потрібне було щось індивідуальне, у хід ішли HTML/HTML5, CSS/SCSS та Django; там, де потрібне було щось більш стандартне, з чим клієнт міг би впоратися і самостійно, швидшою й розумнішою відповіддю ставали WordPress або Joomla. Частина майстерності полягала саме в тому, щоб розрізняти ці випадки — відмовити клієнту в індивідуальній розробці, яка йому не потрібна, або переконати в тій, яка потрібна.

Результат. Сто застосунків дали клієнтам різноманітну, дієву присутність онлайн, кожен реалізований на технології, яка справді йому підходила. Саме підбір підходу під клієнта, а не навпаки, зробив їх ефективними, а не просто зданими в експлуатацію.

Спроєктувала 30 вебсайтів, надавши унікальні та гнучкі рішення завдяки перетворенню дизайнів Photoshop на HTML.

2026-10-09T14:31:15+02:00

Ситуація. Клієнти приходили з бажаним виглядом сайту — часто це вже був готовий візуальний дизайн — і потребували, щоб вебсайт був побудований точно за ним. Розрив між файлом дизайну та робочим сайтом — це саме те місце, де здебільшого виграється або втрачається якість: легко здати щось приблизно правильне, але з непомітними відхиленнями.

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

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

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

Адмініструвала 40 вебсайтів на хостинг‑серверах Ubuntu Linux з Apache та Nginx, забезпечивши високу доступність і продуктивність.

2026-10-09T14:31:15+02:00

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

Завдання. Завдання полягало в тому, щоб адмініструвати ці сайти та підтримувати їхню високу доступність і швидкість.

Дія. Сорок вебсайтів працювали на хостинг‑серверах Ubuntu Linux, на поєднанні Apache та Nginx — конфігурація, налаштування продуктивності, постійне обслуговування для підтримання надійності під реальним трафіком. Саме реальний трафік тут ключовий: сайт, який нормально почувається, коли ним ніхто не користується, і падає, щойно ним починають користуватися, насправді не адмініструвався — його просто залишили без уваги. Тож робота полягала в тому, щоб підтримувати їхню справність під фактичним навантаженням.

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

Спроєктувала, розробила, впровадила та підтримувала інфраструктуру, обробку даних і картографічний застосунок безперервно протягом 2 років без вихідних, свят чи відпустки, по 10–14 годин на день.

2026-10-09T14:31:15+02:00

Ситуація. Стартап у сфері зеленої енергетики на ранній стадії розвитку залежав від єдиної платформи для відстеження, моніторингу та оптимізації активів відновлюваної енергетики, проте не мав ані окремої інфраструктурної команди, ані сформованої інженерної організації для її побудови й експлуатації. Усю технічну основу — хмарну інфраструктуру, пайплайни обробки даних і клієнтський GIS‑застосунок з картою — потрібно було створити й підтримувати в безперервній роботі на ринку, де будь‑який простій чи розрив у даних напряму підривав довіру клієнтів і дохід.

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

Дія. Протягом двох років інфраструктура, пайплайни даних і картографічний застосунок проєктувалися, впроваджувалися та підтримувалися без перерв — без вихідних, свят чи відпусток, часто по 10–14 годин на день. Було обрано прагматичну, модульну архітектуру, щоб зберегти придатність до підтримки одноосібної експлуатації, з автоматизованим розгортанням, моніторингом та сповіщеннями, аби проблеми виявлялися й вирішувалися швидко. Обробка даних постійно донастроювалася для надійності та продуктивності, релізи випускалися поступово, і кожен рівень — від серверів до карти, орієнтованої на користувача, — підтримувався та вдосконалювався особисто, у відповідь на реальне використання клієнтами.

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

Оптимізувала бюджетні витрати у 10 разів без втрати продуктивності для міжнародного клієнта, переосмисливши загальну інфраструктуру, усунувши непотрібні сервіси та перенісши систему з хмари AWS.

2026-10-09T14:31:15+02:00

Ситуація. Міжнародний клієнт ніс на собі суттєво роздуті інфраструктурні витрати. Її налаштування AWS було надлишково забезпечене ресурсами й накопичило сервіси, якими вже ніхто не користувався, тож рахунок за хмару повністю вийшов з будь‑якої пропорції до того, що бізнесу дійсно було потрібно. Історія звична — ніхто не планує перевитрачати, це просто накопичується, коли ніхто не стежить за лічильником.

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

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

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

Спроєктувала багаторівневу морську платформу, розділивши фронтенд Next.js PWA, API на Go (Huma/Fiber) та рівень функцій PostgreSQL, зберігши всю бізнес‑логіку в базі даних.

2026-10-09T14:31:15+02:00

Ситуація. Продукт мав стати морською платформою — професійні мережі, відгуки про компанії, спонсорована освіта — і це був молодий продукт, що є ввічливим способом сказати, що вимоги мали суттєво змінюватися. Чого варто було уникнути — це архітектури, у якій зміна бізнес‑правила означала одночасне втручання у фронтенд, API та базу даних. На невеликій кодовій базі, яка швидко росте, саме такий рівень зв’язаності перетворює зміну у два рядки коду на роботу на ціле пообіддя.

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

Дія. Усе усталилося у три рівні, кожен зі своєю роллю. Фронтенд на Next.js відповідає за представлення й інтерактивність і більше ні за що. API на Go — Huma поверх Fiber — навмисно тонкий: він маршрутизує, валідує запит, застосовує фільтрацію безпеки та оркеструє, але не містить жодної бізнес‑логіки. Уся бізнес‑логіка живе у функціях PostgreSQL, які збирають повний результат і повертають його, щоб API просто передав далі. Тож коли правило змінюється, воно змінюється в одному рівні, у SQL, а решта двох про це навіть не знають. Межі було зафіксовано письмово, а потім закріплено через код‑рев’ю, адже конвенція, яку ніхто не контролює, перестає бути конвенцією.

Результат. Систему й далі було легко тримати в голові. Бізнес‑логіка розташована в одному місці, яке справді можна перевірити, API — нудний у хорошому сенсі адаптер, а фронтенд не переймається, коли схема змінюється під ним. Саме це розділення дало продукту змогу й далі нарощувати функціональність без тихого гниття архітектури.

Спроєктувала архітектуру наскрізної передачі JSON, у якій функції PostgreSQL повертають повний JSON, що дослівно пересилається через Go API, усунувши проміжний unmarshalling та унезалежнивши фронтенд від змін схеми.

2026-10-09T14:31:15+02:00

Ситуація. Звичний шлях даних від бази до браузера — це естафета трансформацій. База даних передає API рядки, API десеріалізує їх у структури (structs), переформатовує, серіалізує назад у JSON, і лише тоді дані йдуть далі. Кожен із цих переходів — це код, який потрібно написати, код, який потрібно протестувати, і ще одне місце, де уявлення API про дані та уявлення бази даних про них можуть розійтися.

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

Дія. Тож це було побудовано як пряму передачу без проміжних перетворень. Функції PostgreSQL збирають усю відповідь у вигляді JSON — формування є завданням SQL, виконуваним там, де дані вже є. Обробник на Go отримує це назад як json.RawMessage і передає далі без змін; він ніколи не розкладає це на частини, ніколи не перекодовує. Невеликий допоміжний метод QueryJSON перетворив цей патерн на шлях найменшого опору, а не на те, про що щоразу треба пам’ятати окремо. Випало все проміжне обладнання, яке зазвичай накопичує традиційний шаруватий API — DTO, мапери, структури відповідей.

Результат. Код обробників став суттєво коротшим, а що важливіше — фронтенд перестав бути прив’язаним до Go. Достатньо змінити те, що повертає функція, і нова форма даних напряму доходить до клієнта без редагування жодного рядка коду обробника. Менше рухомих частин, і цілий клас розбіжностей між рівнями тут просто не існує.

Спроєктувала систему перемикання контексту організації з клієнтським localStorage та серверним дзеркалюванням cookie, що дозволила користувачам діяти від імені керованих організацій, забезпечуючи авторизацію за принципом найменших привілеїв.

2026-10-09T14:31:15+02:00

Ситуація. На платформі морський фахівець може керувати організаціями — компаніями, академіями — які не мають власних облікових записів для входу. Обліковим записом є сама людина; організація — це те, від імені чого вона діє. Тож користувачу потрібно переміщуватися по всьому застосунку як будь‑яка з організацій, якими він керує, вільно перемикаючись між ними, і ця зручність не повинна перетворюватися на діру в авторизації.

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

Дія. За це відповідає OrganizationContext зі зберіганням стану на обох сторонах. На клієнті джерелом істини щодо того, від імені якої організації користувач наразі діє, є localStorage, тож перемикання відбувається миттєво — без звернення до сервера. Серверний cookie дзеркалить цей стан, щоб сторінки, що рендеряться на сервері, визначали той самий контекст під час SSR; на сервері є getServerViewMode, який його зчитує. Важливо, що жодне з цього не використовується для ухвалення рішень щодо доступу. Авторизація повторно перевіряється на сервері під час кожного запиту. Контекст на фронтенді існує заради досвіду користування — показати саме те, що потрібно, — а сервер є єдиним джерелом істини щодо того, що дозволено робити.

Результат. Користувач може діяти від імені будь‑якої організації, якою керує, без жодних перешкод, а інтерфейс залишається синхронізованим і на клієнті, і на сервері. Але оскільки права щоразу перевіряються на сервері, ця зручність жодним чином не послаблює безпеку. Втручання у вміст localStorage змінює лише те, що бачить власний інтерфейс користувача, і нічого більше — сервер усе одно відмовить.

Мігрувала HTTP API з Fiber на Huma v2 — 649 шляхів і 760 операцій — досягнувши та втримавши 100% відповідність між маршрутами, які реєструє сервер, і описом OpenAPI, який він публікує.

2026-10-09T14:31:15+02:00

Ситуація. API розпочинав своє життя на Fiber, із валідацією запитів, написаною вручну для кожного ендпоінта окремо. Це нормально, коли ендпоінтів жменька. Але перестає бути нормальним, коли поверхня API розростається: рукописна валідація перетворюється на податок на підтримку, а дрібні неузгодженості накопичуються, бо перевірки кожного ендпоінта — це своя окрема сніжинка. І ніде не було жодного єдиного опису форми API.

Завдання. Метою було отримати валідацію, що походить із типів, а не з рукописних перевірок, і справжній контракт, який описує API, — без зупинки на повномасштабне переписування.

Дія. HTTP‑рівень перенесено на Huma v2 поверх Fiber, тож наявний рантайм зберігся. Кожен ендпоінт отримує вхідні та вихідні структури (structs), а Huma генерує валідацію запитів і моделювання відповіді на основі цих типів. Опис OpenAPI виходить із цього безкоштовно, а це означає, що документація йде в ногу з кодом, а не застаріває десь у вікі. Усе нове писалося під Huma, а наявні маршрути перенесено, залишивши рівно два ендпоінти на чистому Fiber — це WebSocket‑ендпоінти, де справді потрібен саме сокет, а модель запиту/відповіді Huma не підходить. Те, у що це виросло, — 649 шляхів із 760 операціями та перевірка в CI, яка порівнює маршрути, що їх сервер справді реєструє, з тими, що їх декларує опис OpenAPI. Паритет становить 100%, і він там і лишається, бо маршрут, який не описано, завалює білд.

Результат. Нові ендпоінти отримують валідацію та актуальну документацію без додаткових зусиль, а цілий клас помилок обробки запитів — на кшталт «ой, а тут ми забули перевірити це поле» — зник. На 760 операціях цей опис — єдиний практичний спосіб, у який хтось узагалі читає API, тож гарантія його повноти важить більше, ніж важила на п’ятдесяти. Типізований контракт зробив API одночасно безпечнішим для змін і простішим для передачі іншій людині, адже типи самі повідомляють, чого очікує ендпоінт.

Згенерувала контракт API з бази даних назовні — OpenAPI, типізований TypeScript‑клієнт на 44 076 рядків, 61 mock‑обробник та обмеження, які застосовує UI, — з перевіркою на кожній ланці, що падає при розходженні.

2026-10-09T14:31:15+02:00

Ситуація. Фронтенд і бекенд розвиваються у власному темпі, і їхні уявлення про payload запиту можуть непомітно розходитися. Зазвичай про це дізнаються за 422 у браузері — вже після того, як розбіжність потрапила в продакшн, а це найдорожчий момент, щоб про неї дізнатися. Написання обох сторін вручну за одним документом цього не виправляє: воно лише переносить розбіжність на того, хто забув перечитати документ.

Завдання. Обидві сторони мали генеруватися з одного джерела, а не узгоджуватися між двома, і кожен крок цієї генерації мав перевірятися, а не братися на віру.

Дія. Ланцюг починається з бази даних і йде назовні. Схема та її функції визначають структури даних; типи Go визначають API; Huma формує з них опис OpenAPI; з цього опису генерується типізований клієнт TypeScript — 44 076 рядків; поряд із ним генерується 61 mock‑обробник, тож власні тести фронтенду виконуються проти реального контракту, а не проти рукописної фікстури; а обмеження, які UI застосовує до форми, походять із того самого місця, замість того щоб їх перенабирали у валідаторі. Кожен перехід має запобіжник. Перевірка контракту в CI порівнює те, що надсилає фронтенд, із тим, що очікує API, і завалює білд за розбіжності, а під нею є перевірка схеми, яка звіряє реальну структуру даних, а не її опис. Вона свідомо охоплює місця, де розбіжності люблять ховатися: опціональні поля тіла запиту, де плутають «відсутнє» і null, та enum‑и query‑параметрів, де обидві сторони можуть тихо розійтися в допустимих значеннях.

Результат. Поле не може змінитися лише з одного боку — воно завалюється на першому ж переході, який це помічає, у білді, за кілька хвилин після зміни. Це усунуло повторюваний і по‑справжньому набридливий клас багів: непомітний під час code review і такий, що проявляється лише в рантаймі. Ціна — крок генерації посеред усього: перегенерація є рутиною, а ланцюг вартий довіри рівно настільки, наскільки надійна його найменш захищена ланка, — тому запобіжник отримав кожен перехід.

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

2026-10-09T14:31:15+02:00

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

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

Дія. Три провайдери стоять за одним інтерфейсом — SendGrid як основний, а SMTP2GO та Azure Communication Services позаду нього, — і перемикання між ними автоматичне, а не є зміною конфігурації, зробленою під тиском. Доставка не вважається даністю: вхідні webhooks повідомляють, що кожен провайдер зробив із листом, і обидві сторони записуються — у журнал надсилань і таблицю подій доставки, — тож «чи отримала ця людина свій лист із верифікацією» є запитом, а не здогадом. Шаблонізація тримає тіла листів поза кодом, а окрема схема broadcast — 5 таблиць і 24 функції — доставляє кампанії сегментам користувачів, і це інша задача, ніж транзакційна пошта, тож її й будували як іншу. Перед усім цим стартова перевірка надсилає реальний лист через увесь стек, за прапорцем: у середовищі розробки це просто логує попередження й продовжує роботу, бо ніхто не хоче, щоб ноутбук відмовлявся запускатися через прострочений ключ пісочниці, а в staging і production збій є фатальним і процес завершується, а не розгортає білд, який не може надсилати пошту. Сам шлях надсилання проходить через клієнт із захистом від SSRF і тайм‑аутом 30 секунд, а асинхронний шлях доставки має retries і backoff, тож короткочасний збій не втрачає повідомлення.

Результат. Ціла категорія тихих збоїв перейшла зі стану «користувач помічає це через кілька днів» у стан «розгортання зупиняється», а невдалий день у провайдера став деградованим шляхом, а не аварією. Ціна — три інтеграції, які треба підтримувати робочими замість однієї, і журнали доставки, що ростуть і потребують чищення; обидві прийнятні, бо пошта — це канал, який платформа не може обійти.

Спроєктувала рівень даних PostgreSQL, побудований насамперед на функціях — 1 275 збережених функцій у 34 схемах — щоб кожне читання й кожен запис проходили через функцію, на яку база даних може видати права, а не через таблицю.

2026-10-09T14:31:15+02:00

Ситуація. Бізнес‑логіка має звичку просочуватися. Частина потрапляє в API, частина — у якийсь SQL, що виконується прямо в обробнику, і незабаром те саме правило виявляється записаним двома‑трьома трохи різними способами, і немає жодного місця, на яке можна вказати й сказати: «ось що система робить зі своїми даними». Так у систему потрапляють баги й діри в безпеці.

Завдання. Метою було одне місце для всього цього: кожне читання й запис проходить через базу даних, API залишається тонким адаптером, який не знає бізнес‑правил, а все разом можна щільно замкнути.

Дія. Рівень даних побудовано за принципом function‑first. Схему поділено за доменами — identity, organization, review, message, notification і ще 29 інших, 34 разом, — і кожна операція, яку може виконати застосунок, є однією з 1 275 функцій PostgreSQL, які він викликає; прямого доступу до таблиць із Go взагалі немає. Далі це забезпечує сама база даних. Роль, під якою логіниться API, mariner, має EXECUTE на функціях застосунку та USAGE на схемах — і нічого більше: жодного SELECT, жодного INSERT, жодного способу торкнутися таблиці напряму — а це виходить приблизно 4 000 явних грантів, а не один загальний. Функції виконуються як SECURITY DEFINER, належать окремій non‑login ролі function_owner із зафіксованим search_path, а обліковий запис суперкористувача лишається зарезервованим для міграцій і cron, подалі від застосунку, що працює.

Результат. Логіка живе в одному місці, яке справді можна перевірити, API лишається тонким і нудним у хорошому сенсі, а межу доступу забезпечує сам Postgres, а не те, що всі пам’ятають правила. Якщо API раптом буде скомпрометовано, воно все одно не зможе зробити нічого, чого не дозволяють функції. На 1 275 функціях ця дисципліна коштує чогось реального — нове поле означає міграцію та зміну функції, а не рядок у запиті, — і це тертя є ціною того, що межа тримається.

Впровадила deep‑merge на основі каталогу для збережених JSON‑налаштувань, запобігши збоям через відсутні ключі при еволюції схеми.

2026-10-09T14:31:15+02:00

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

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

Дія. Однорівневе злиття замінено на deep‑merge, керований значеннями за замовчуванням як каталогом. Значення за замовчуванням розглядаються як авторитетний перелік усіх ключів, які мають існувати; збережені значення користувача рекурсивно накладаються зверху, тож усе, що є в каталозі, гарантовано присутнє на виході — незалежно від того, чи було воно в збереженому blob. Додається ключ до значень за замовчуванням — і він автоматично з’являється в ефективних налаштуваннях кожного наявного рядка, включно з вкладеними ключами. Це впроваджено через міграцію, тож наявні дані отримали перевагу одразу, а не чекали на переписування.

Результат. Налаштування можуть зростати без побоювань. Додавання параметра більше не ризикує крашем через undefined‑поле на клієнті, а фронтенд перестав потребувати захисних перевірок, розкиданих у кожному місці, де він читає налаштування. Це також дало решті платформи надійний спосіб розширювати будь‑який збережений JSON‑blob — не лише окреме виправлення, а й сам патерн.

Змоделювала морський домен — фахівців, компанії, судна, вакансії, відгуки та решту — у 348 нормалізованих таблицях у межах 34 схем PostgreSQL, з довідниками SMALLINT та ключами UUID v7.

2026-10-09T14:31:15+02:00

Ситуація. Серцем платформи є щільний морський домен — фахівці, компанії, судна, вакансії, відгуки, — і всі ці сутності постійно посилаються одна на одну. Фахівець ходить у рейси на суднах, працює в компаніях, залишає відгуки; компанія володіє суднами й публікує вакансії. Майже кожна функція — це запит через усю цю мережу зв’язків, тож від того, наскільки добре змодельовані дані, залежить, наскільки добре працює більшість застосунку і наскільки розумно його розширювати.

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

Дія. Дані організовано як нормалізовані схеми PostgreSQL, згруповані за доменами, — 348 таблиць у 34 схемах на цей момент. Численні дрібні стабільні переліки — статуси, типи, категорії — перетворено на довідкові таблиці SMALLINT, що робить рядки компактними, а джойни дешевими, замість того щоб зберігати текстові коди всюди. Сутності отримують первинні ключі UUID v7, тож вони глобально унікальні, але водночас часово впорядковані в індексі. Крізь усе проходить одна угода про іменування — таблиці в множині всередині схем з іменами в однині, — застосована без винятків, що як бонус дає змогу уникнути багатьох конфліктів із зарезервованими словами. А зв’язки підтримуються реальними foreign key та constraints, тож цілісність — це робота бази даних, а не те, що застосунок мусить пам’ятати сам.

Результат. Результатом стала модель даних, яка є послідовною і швидкою, а працювати з нею передбачувано, бо ті самі правила діють усюди — немає особливих випадків, які треба запам’ятовувати. Додавання функції зазвичай означає розширення схеми за наявною логікою, а не боротьбу проти неї, і це єдина причина, чому 34 схеми — це структура, а не розповзання. Це той фундамент, на якому стоїть решта платформи.

Побудувала фронтенд на Next.js 16 зі свідомими стратегіями SSR, SSG і CSR та багаторазовою фабрикою prefetched‑server‑page, що усуває каскад N+1 на кожній автентифікованій сторінці, перенесеній на неї.

2026-10-09T14:31:15+02:00

Ситуація. Автентифікований дашборд мав відчуватися швидким і водночас залишатися по‑справжньому інтерактивним, а ці дві мети тягнуть у різні боки, якщо підійти до них наївно. Якщо забирати все на клієнті, перше завантаження затягується, а гірше — виникає патерн N+1, коли кожен компонент прокидається і робить власний запит, тож одна сторінка перетворюється на каскад мережевих звернень.

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

Дія. Фронтенд на Next.js 16 використовує для кожної поверхні застосунку той режим, який їй підходить, замість одного рішення на всі випадки. Маркетингові й публічні сторінки генеруються статично — вони не змінюються залежно від користувача, тож рендерити їх на кожен запит немає сенсу. Справді інтерактивні частини лишаються клієнтськими. А там, де каскад N+1 справді дошкуляє, — автентифікований дашборд і великі сторінки‑каталоги — рішення винесли у фабрику, а не робили вручну: createPrefetchedServerPage отримує дані сторінки на сервері й передає їх клієнту вже заповненими, тож компоненти одразу з’являються зі своїми даними, а не йдуть по них кожен окремо. Стратегія інвалідації кешу задокументована для кожного запиту, тож дані лишаються актуальними без повторного завантаження того, що застосунок уже має.

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

Реалізувала повну підтримку Progressive Web App — з можливістю встановлення та офлайн‑роботи — з кешуванням Workbox під час виконання через next‑pwa.

2026-10-09T14:31:15+02:00

Ситуація. Значна частина користувачів платформи перебуває в морі. Моряки та польовий персонал працюють з телефонів, часто офлайн або на нестабільному з’єднанні, — це не люди за робочим столом зі стабільним офісним wifi. Якби застосунок будувався так, ніби в усіх є швидка й постійна мережа, це непомітно відсікло б значну частину реальної аудиторії.

Завдання. Застосунок мав встановлюватися як нативний і залишатися придатним до використання навіть при зникненні мережі.

Дія. Продукт постачається як повноцінний Progressive Web App. Він встановлюється на головний екран з коректними іконками різних розмірів, екраном заставки та кольорами теми, тож виглядає і запускається як застосунок, а не як закладка. Service worker налаштовано через плагін next‑pwa, а Workbox для runtime‑кешування використовує стратегію CacheFirst для того, що не змінюється від запиту до запиту, — шрифтів, зображень, аудіо, відео, CDN‑ресурсів, — разом з розумними HTTP‑заголовками cache‑control. Оскільки service worker коректно працює лише через HTTPS, тестування на основі HTTPS підтвердило офлайн- та інсталяційну поведінку на реальних пристроях, замість того щоб просто сподіватися, що все спрацює.

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

Спроєктувала дизайн‑систему iOS 26 'Liquid Glass' та канонічний реєстр компонентів, дотримання якого забезпечували правила лінтингу для запобігання розбіжностям UI.

2026-10-09T14:31:15+02:00

Ситуація. UI без спільної візуальної мови й фіксованого набору компонентів пливе, і пливе швидко. Кожен новий екран винаходить власні кнопки, бейджі й картки, трохи інакші щоразу, і ці дрібні неузгодженості накопичуються, доки продукт не починає виглядати нецілісним, а будь‑яка зміна означає торкатися п’яти саморобних версій одного й того самого.

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

Дія. Візуальну мову й систему компонентів було спроєктовано як одне ціле. Мова — це вигляд у стилі iOS 26 «Liquid Glass»: напівпрозорі панелі з розмиттям фону, шаруваті тіні, легка рефракція, пружинні анімації, — побудований на утилітах Tailwind. Над цим стоїть канонічний набір компонентів, з яких має складатися кожен екран: Card, Label, Button, GlassIconButton, DirectoryGrid та інші. Тримається все це завдяки лінтингу: правила відхиляють саморобний бейдж чи чіп і натомість вказують на канонічний компонент, тож систему підтримує інструментарій, а не пам’ять того, хто саме цього дня перевіряє код. А документація супроводжується конкретними нотатками «помилка → рішення»: замість абстрактного принципу — приклад неправильного та правильного варіанта.

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

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

2026-10-09T14:31:15+02:00

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

Завдання. UI та UX продукту було опрацьовано наскрізно — макети, патерни взаємодії та дрібніші речі на кшталт того, як провести людину крізь форму, не змушуючи її відчувати тиск.

Дія. Основну роботу виконали кілька рішень. Сітки каталогів мають перемикач картка/таблиця, тож можна переглядати дані візуально або сканувати щільну таблицю, і застосунок пам’ятає обраний варіант. Форми використовують живі валідатори вимог, розташовані над полем вводу: кожне правило показується зеленим, коли воно виконане, і жовтогарячим, коли ні, — тож користувача скеровують під час вводу, а не докоряють йому після відправлення. Навігація — це послідовні хлібні крихти та двоколонкові макети сутностей, тож сторінки відчуваються як один продукт, а не набір непов’язаних екранів. А філософія помилок — це підказка замість провалу: жодних червоних стін, редиректи замість глухих кутів, застосунок намагається вести користувача далі, а не зупиняти його.

Результат. У результаті вийшов вилощений, послідовний досвід, який робить щільні морські дані доступними для сприйняття та проводить людей крізь складні місця. Він виглядає продуманим і таким, якому можна довіряти, а на платформі, яку люди використовують для власної кар’єри, це не просто косметика: якщо все виглядало б недбало, вони довіряли б даним менше, і мали б рацію.

Посилила захист застосунку за допомогою CSP на основі nonce, HSTS, cookie SameSite, ролей бази даних за принципом найменших привілеїв та серверних повторних перевірок прав доступу.

2026-10-09T14:31:15+02:00

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

Завдання. Платформу потрібно було захистити на кожному рівні — фронтенд, API, база даних, — так, щоб безпеку забезпечував сервер незалежно від того, що саме дозволяв інтерфейс.

Дія. На фронтенді проксі‑мідлвар Next.js — proxy.ts — встановлює Content‑Security‑Policy з nonce для кожного запиту та strict‑dynamic, а також HSTS і SameSite cookies, тож браузер жорстко обмежений у тому, що він виконає й надішле. На рівні API діють rate limiting, CORS, обмеження розміру запиту, валідація вводу до того, як щось торкнеться бази даних, і логування подій, пов’язаних із безпекою. У базі даних API входить під роллю з мінімальними привілеями, яка може лише виконувати (EXECUTE) функції застосунку, самі функції запускаються з SECURITY DEFINER, а все параметризовано. А права доступу — тариф, роль, організація, прив’язка до судна — перевіряються сервером повторно на кожен запит, тоді як фронтендні обмеження розглядаються лише як UX. Ці обмеження визначають, що видно; сервер визначає, що дозволено робити.

Результат. Безпека не залежить від того, як поводиться UI. Захист побудовано шарами так, щоб подолання одного рівня не давало проходу через решту, а вся система базується на припущенні, що клієнту довіряти не можна, — і це правильне припущення для даних, які люди довіряють платформі.

Створила систему інтернаціоналізації для англійської та данської мов, що несе 12 027 повідомлень на локаль у 458 файлах namespace, зі словником, дотримання якого забезпечував лінтер, та бюджетом у 400 рядків на файл.

2026-10-09T14:31:15+02:00

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

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

Дія. Систему побудовано на next‑intl з правилами, які інструментарій справді примусово застосовує. Данська сторона має зафіксований словник і стиль — буквальні æøå, неформальне звертання «du», правильні наголоси в наказовому способі та семантичні відповідники для складних іменників, щоб їх перекладали за змістом, а не дослівно, — і лінтер стежить за цим. Діє жорсткий ліміт у 400 рядків на файл namespace, з підходом split‑and‑merge: велика область ділиться на вкладені файли, які потім чисто зливаються назад, замість того щоб один файл ріс нескінченно; саме через цей ліміт 12 027 повідомлень на локаль живуть у 458 файлах, а не в кількох величезних. Лінтер‑перевірка звіряє ключі між локалями, тож нічого не протікає і не губиться. А збережені overrides зливаються на основі каталогу, а не через крихкі фолбеки верхнього рівня — та сама ідея deep‑merge, що використовується для налаштувань.

Результат. Обидві локалі лишаються коректними й узгодженими на 24 054 повідомленнях між ними, а файли лишаються придатними до підтримки навіть у міру зростання кількості рядків. Якість мови стала тим, що інструментарій гарантує на кожному коміті, а не тим, що непомітно псується щоразу, коли хтось поспіхом додає рядок. Саме ліміт є несучою конструкцією: без обмеження на файл замість 458 файлів було б дванадцять, і ніхто б їх не відкривав.

Заклала засадничі рішення платформи в тижні після відкриття репозиторію в листопаді 2025 року — поділ на рівні, доступ до даних передусім через базу даних та планку без жодних попереджень — і вони тримаються дев'ять місяців потому.

2026-10-09T14:31:15+02:00

Ситуація. Репозиторій відкрито 25 листопада 2025 року, і в ньому не було нічого. Те, що вирішується в перші кілька тижнів такого проєкту, має непропорційну вагу: поділ на рівні, місце, де дозволено жити бізнес‑логіці, планка якості. Такі рішення дешево ухвалювати на третій день і майже неможливо скасувати на шостий місяць, бо на той момент усе написане відтоді вже на них спирається.

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

Дія. Основну роботу зробили три рішення. Стек поділено на рівні так, щоб кожна частина мала одну роботу — фронтенд на Next.js, Go API, який валідує й передає далі, рівень функцій PostgreSQL, якому належать бізнес‑правила, — замість того щоб логіка опинялася там, де було зручно того дня. Доступ до даних із самого початку сховано за збереженими функціями, і саме з цього рішення випливає все інше, що стосується бази даних; впровадити його заднім числом означало б переписати кожен обробник. А планку нульових попереджень запроваджено ще до того, як з’явилося багато коду, який треба їй підпорядкувати, бо стандарт, уведений на коміті 5 000, — це проєкт із прибирання, тоді як той самий стандарт на коміті 50 — це просто те, як працює репозиторій. Жодне з цих трьох рішень не було легким варіантом на той момент, і всі три коштували темпу в перший місяць.

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

Розробляла та підтримувала вебзастосунки на Django для IPTV‑платформи, постачаючи нові функції та покращуючи продуктивність і стабільність.

2026-10-09T14:31:15+02:00

Ситуація. Навколо IPTV‑платформи існували вебзастосунки на Django — саме та частина, на яку люди реально натискали, — і вони мали продовжувати рухатися вперед: нові функції, а також продуктивність і стабільність, яких вимагає платформа, що працює цілодобово.

Завдання. Завдання полягало в тому, щоб ці застосунки лишалися багатофункціональними, швидкими й стабільними.

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

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

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

2026-10-09T14:31:15+02:00

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

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

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

Результат. Системи залишалися функціональними та ефективними ще довго після їх побудови, працюючи роками майже без змін. Саме така довговічність і є справжнім мірилом інфраструктурної роботи — зробити щось, що працює сьогодні, може будь‑хто; зробити щось, що тихо продовжує працювати через роки, — завдання значно складніше й цінніше.

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

2026-10-09T14:31:15+02:00

Ситуація. Це був SaaS‑стартап у сфері зеленої енергетики — з перспективною ідеєю, але практично без технічної основи під нею. Прихід на посаду одним із перших співробітників означав той етап, коли підтримувати ще нічого, бо нічого ще не існує, — закладання ґрунту, на якому згодом стоятимуть усі інші.

Завдання. Завданням було з нуля побудувати основну інфраструктуру та процеси навколо неї.

Дія. Було спроєктовано та побудовано всю базову інфраструктуру й супутні процеси — сервери, мережі, потоки даних, безпеку, операційну складову. У стартапі це означає ухвалення рішень, які потім важко скасувати, тож мета полягала не просто в тому, щоб «щось запрацювало», а в тому, щоб закласти фундамент, здатний витримати вагу швидкого зростання без потреби зривати все й переробляти в момент, коли компанія стане більшою. Ранні інфраструктурні рішення або стають тим, що дає змогу масштабуватися, або тим, що потім рік доводиться розбирати; мета однозначно була в першому.

Результат. Стартап отримав міцну технічну основу, і саме вона дала бізнесу змогу згодом швидко зростати. Бути тим, хто будує таку основу з нуля, — це особлива відповідальність: зроби правильно — і ніхто не помітить, зроби неправильно — і помітять усі, — і в цьому випадку основа витримала.

Підтримувала та вдосконалювала застарілий сайт на Hugo, водночас долучаючись до покращень UI/UX основного продукту з управління активами.

2026-10-09T14:31:15+02:00

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

Завдання. Завдання полягало в тому, щоб підтримувати сайт у робочому стані й водночас покращувати досвід користування продуктом.

Дія. Статичний сайт на Hugo підтримувався й вдосконалювався — залишався актуальним і працездатним, — тоді як покращення UI/UX і зворотний зв’язок водночас спрямовувалися в основний продукт управління активами. Розподіл уваги між застарілим сайтом і флагманським продуктом — це насамперед про те, щоб не дати старому занепасти, поки увага прикута до нового; обидва так чи інакше представляли компанію перед кимось, тож обидва мали залишатися в належному стані.

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

Забезпечила успіх клієнтів у вебі, поєднавши розробку та дизайн індивідуальних вебсайтів із SEO, контент‑стратегією та копірайтингом.

2026-10-09T14:31:15+02:00

Ситуація. Клієнтам насправді потрібен був не вебсайт сам по собі — їм потрібно було те, що вебсайт має для них робити: щоб його знаходили, щоб він приваблював клієнтів, щоб він справді працював як канал. Гарний сайт, який ніхто не може знайти, — це провал, що маскується під успіх.

Завдання. Завдання полягало в тому, щоб об’єднати розробку та зростання в одну пропозицію, а не просто передати клієнту готовий сайт і побажати удачі.

Дія. Було об’єднано дві складові — розробку та дизайн вебсайтів на замовлення з одного боку, SEO, контент‑стратегію та копірайтинг з іншого, — щоб клієнт отримував продукт, який був водночас якісно побудований і справді помітний у пошуку. Зазвичай це вважають окремими завданнями, тому й з’являються то чудові сайти, яких немає в жодній видачі, то добре оптимізовані сайти, якими неприємно користуватися. Поєднання обох напрямів означало, що сайт із самого початку проєктувався так, щоб його знаходили, а не оптимізувався заднім числом.

Результат. Клієнти отримали вищу видимість і більше залучення — їхні сайти працювали як справжні канали зростання, а не як онлайн‑буклети. Саме поєднання розробки та пошукової доступності в одному процесі перетворило вебсайт із витрати на те, що дійсно окупало себе.

Побудувала багаторівневий набір автоматизованих тестів — 981 тест Go, 543 фронтендні та браузерні специфікації, 494 поведінкові тести SQL — з мутаційним тестуванням, property‑based тестами та обов'язковою перевіркою доступності.

2026-10-09T14:31:15+02:00

Ситуація. Платформа, що тримає свою бізнес‑логіку в базі даних, має проблему з тестуванням, якої немає в більшості проєктів. Логіка написана не тією мовою, з якою добре працює тестовий фреймворк, — вона в SQL, за фасадом функцій, а SQL — це саме той код, який лишається непокритим, бо тестувати його незручно. Якщо зверху додати API на Go та фронтенд на Next.js, «важливі частини покрито» тихо перетворюється на «покрито ті частини, які було легко покрити».

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

Дія. Чотири рівні отримали чотири види тестів. API на Go несе 981 тестову функцію в 310 файлах. Фронтенд несе 543 spec‑файли Vitest і Playwright, зокрема 48 end‑to‑end файлів і 30 браузерних spec‑файлів. База даних несе 494 файли поведінкових тестів — 116 876 рядків SQL, які перевіряють свої припущення через 6 654 згенеровані винятки, — тож збережена функція тестується в самій базі даних, а не крізь три рівні застосунку над нею. Над ними стоять тести, що тестують тести: мутаційне тестування Stryker навмисно ламає рядок коду й падає, коли цього ніхто не помічає, а fast‑check генерує вхідні дані, які нікому не спало на думку записати. Гейт на axe‑core вимагає нуля порушень WCAG 2.0 і 2.1 рівнів A та AA, тож доступність стає падінням білду, а не знахідкою аудиту через кілька місяців. Пороги покриття рухаються лише вгору. Увесь набір виконується як 10 задач у workflow на 612 рядків.

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

Побудувала рівень платежів і прав доступу — Stripe поряд із внутрішньозастосунковими покупками Apple і Google — обмеживши каталог, пошук та експорт моделлю доступу з 11 таблиць, яку перевіряє сервер.

2026-10-09T14:31:15+02:00

Ситуація. Гроші — це та частина платформи, до якої нікому не дозволено ставитися недбало. Підписка мусить пережити закінчення строку дії картки, повернення коштів, зміну тарифу, вебхук, що прийшов двічі, і вебхук, що прийшов не в тому порядку. Щойно оплата починає відбуватися на трьох вітринах — карткою у вебі, через Apple в одному app store, через Google в іншому, — з’являються три різні версії того, що саме людина купила, а продуктові все одно потрібна одна відповідь на одне запитання: що цій людині дозволено робити просто зараз?

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

Дія. Stripe опрацьовує картки й підписки через 18 файлів Go, а in‑app‑покупки Apple і Google приходять через власну перевірку квитанцій. Усі три сходяться в схемі payments із 9 таблиць і 34 функцій — і на цьому спиняються. Те, про що продукт запитує насправді, — це окрема схема access, 11 таблиць і 34 функції, яка відповідає на «чи можна цьому обліковому запису зробити це?», не знаючи й не цікавлячись, яка саме вітрина за це заплатила. Ця відповідь закриває каталог компаній, пошук і експорт даних, і вона перевіряється сервером повторно на кожен запит, бо прихована кнопка — це ввічливість, а не механізм контролю.

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

Перенесла повільну роботу зі шляху запиту в чергу завдань River — 15 модулів воркерів, 8 запланованих задач та 20 завдань pg_cron — щоб запит повертався, поки робота за ним триває.

2026-10-09T14:31:15+02:00

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

Завдання. Фоновій роботі потрібне було довговічне місце для життя: черга, яка переживає перезапуск, повторює невдалу спробу і в яку можна зазирнути, коли щось не сталося.

Дія. Вибір упав на River — переважно тому, що він тримає свою чергу в PostgreSQL: база даних і так є авторитетним джерелом даних, тож задача і рядки, яких вона торкається, комітяться або відкочуються разом, і немає другого шматка інфраструктури, який треба запускати й тримати в голові. За ним стоять 15 модулів‑воркерів і 8 запланованих задач. Нижче 20 задач pg_cron виконують ту підтримку, яку базі даних зручніше робити самій: підчищати партиції, ротувати солі, оновлювати агрегати. Усе, що було достатньо повільним, щоб це помітили, перенесено зі шляху запиту на одне з цих двох.

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

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

2026-10-09T14:31:15+02:00

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

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

Дія. Побудовано дві частини. OpenTelemetry відповідає за трасування через OTLP, тож повільний запит можна простежити наскрізь через фронтенд, API та базу даних, а не здогадуватися про нього. Поруч стоїть власний пайплайн помилок — сервіс errmon і сервіс ingest, — який санітизує payload перед збереженням, групує помилки у повторювані проблеми замість плаского списку, виявляє сплески й регресії з періодом очікування, щоб один невдалий деплой не смикнув когось сорок разів, перетворює мінімізовані стектрейси фронтенду назад на читабельний код і запускає синтетичний heartbeat, щоб довести, що сам пайплайн живий. Усе це осідає в базі даних як події помилок, групи помилок, inbox, латентність API та семпли стеків, а назовні виходить через 11 операторських подань, зокрема одне для service level objectives.

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

Побудувала засоби протидії зловживанням за принципом fail‑closed — 22 обмежувачі частоти на Redis, Cloudflare Turnstile, ідемпотентність запитів та прив'язку до origin — щоб платформа відсікала ботів і напливи, а не довіряла тим, хто її викликає.

2026-10-09T14:31:15+02:00

Ситуація. Публічний каталог компаній і фахівців стає мішенню того самого дня, коли виходить у світ. Скраперам потрібні дані, спам‑акаунтам — охоплення, а ендпоінтом, обслуговування якого коштує платформі реальних грошей — пошук, експорт, будь‑що, що торкається зовнішнього API, — варто зловживати вже тому, що викликати його безкоштовно. Нічого з цього не є злим наміром, спрямованим саме проти цієї платформи; це фонова погода відкритого інтернету.

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

Дія. Обмежувачів частоти запитів тут 22, і кожен сконструйований під той шлях, який він захищає, замість одного глобального ліміту, бо спроба входу, пошук і масовий експорт стають зловживанням на кардинально різних швидкостях. Стан живе в Redis, тож ліміт спільний для всіх інстансів, а не існує окремо в кожному процесі, звідки його тривіально обійти. Важливе рішення — що відбувається, коли Redis недоступний: обмежувачі закриваються (fail closed). Трафік відхиляється, а не пропускається помахом руки, — це менш зручна відповідь і єдина, яку можна відстояти. Навколо них стоять Cloudflare Turnstile на шляхах, які варто перевіряти челенджем, 351 рядок мідлвару ідемпотентності, щоб повторений запис не перетворився на два, origin‑lock, що відкидає запити, які прийшли не через парадні двері, і власний челендж на самому каталозі.

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

Побудувала операторський бек‑офіс — близько 40 адміністративних маршрутів та 128 компонентів, що охоплюють заявки на володіння, модерацію, feature flags, кеш і діагностику, — щоб платформою можна було керувати без доступу до бази даних.

2026-10-09T14:31:15+02:00

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

Завдання. Керувати платформою щодня мало бути можливо без shell, щоб операційна робота належала тому, хто на зміні, а не тому, у кого є облікові дані.

Дія. Бек‑офіс склав приблизно 40 адміністративних маршрутів, побудованих зі 128 компонентів, і охоплює роботу такою, якою вона реально надходить: розгляд заявок на володіння компаніями, модерація відгуків і дописів, перемикання feature flags, перегляд і очищення кешів, читання діагностики та звітність, яку просить CEO. Він працює на тій самій дизайн‑системі й тому самому згенерованому API‑клієнті, що й публічний продукт, — і це був вирішальний вибір: внутрішній інструмент, побудований на власному стеку, стає тією частиною, яку ніхто не оновлює, а далі — тією, якій ніхто не довіряє.

Результат. Люди, які керують платформою, справді можуть нею керувати, а кожна дія проходить через ту саму авторизацію й лишає той самий слід, що й будь‑яка інша. Це велика поверхня, яку треба тримати протестованою й доступною заради невеликої внутрішньої аудиторії, і ця ціна платиться постійно. Вона все одно менша за альтернативу — інженера, який о дев’ятій вечора в неділю набирає UPDATE на продакшні.

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

2026-10-09T14:31:15+02:00

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

Завдання. Мав існувати шлях від «це моя компанія» до справжніх повноважень над записом — з людським рішенням посередині й слідом позаду.

Дія. Заявки на володіння побудовано наскрізно — 108 комітів і обидва застосунки. Користувач подає заявку з доказами; вона потрапляє в чергу в бек‑офісі; адміністратор розглядає її та схвалює або відхиляє з причиною, яка повертається заявникові. Найцікавіше — що саме робить схвалення: це не прапорець у рядку. Схвалення переписує граф авторизації, тож обліковий запис отримує реальний зв’язок з організацією — той самий зв’язок, до якого вже звертається кожна перевірка прав на платформі. Воротами є рішення людини, а не гілка в коді, і жодній функції не довелося дізнаватися про заявки, щоб ці ворота поважати.

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

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

2026-10-09T14:31:15+02:00

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

Завдання. Внесок мав бути вимірюваним і винагороджуваним, а баланс — таким, який не можна витратити двічі.

Дія. Схема лояльності налічує 31 таблицю та 67 функцій, статус — ще 5 таблиць і 32 функції, а поруч стоять схеми discovery й персоналізації, які вирішують, що саме бачить конкретний учасник. Над реєстром надбудовані ліги, бейджі та крамниця обміну, де баланс перетворюється на щось реальне. Найбільше уваги забрав найдавніший баг у світі: перевірити баланс, потім списати його — і два запити, що прийшли одночасно, обидва проходять перевірку. Кожна мутація бере блокування рядка гаманця, перш ніж його прочитати, тож другий запит чекає на завершення першого, а не змагається з ним. І те, що гаманець лежить у тій самій базі даних, що й усе інше, — саме це взагалі робить таке можливим: баланс і те, що на нього куплено, комітяться разом або не комітяться зовсім.

Результат. Внесок вимірюється й винагороджується, а баланс — це арифметика, а не наближення. Блокування рядка — повільніша відповідь, і його все одно обрано: конкуренція за гаманець — це черга, а альтернатива — учасник, який витрачає ті самі бали двічі, і хтось, хто потім звіряє це вручну.

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

2026-10-09T14:31:15+02:00

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

Завдання. Соціальний рівень треба було додати так, щоб він не став другою системою з власними правилами, власними дозволами та власним способом зберігати дані.

Дія. Дописи, стрічка, групи, згадки, граф підписників і дайджест подій зайшли в продукт за 188 комітів — усе на тому самому рівні даних, побудованому насамперед на функціях, що й решта платформи. Це обмеження зробило більшу частину роботи: граф підписників — це такі самі таблиці й функції, як усе інше, згадка розв’язується через ту саму схему identity, яку використовує каталог, а допис успадковує чергу модерації, уже побудовану для відгуків. Нічому тут не знадобилося власне сховище чи власна модель дозволів. Єдине місце, яке чинило опір, — це стрічка, бо ефективно зібрати персоналізовану стрічку подій справді інша задача, ніж дістати рядок, і саме тут робота з персоналізації та discovery виправдовує своє місце.

Результат. У платформи з’явилася причина бути відкритою в день, коли нікому не треба шукати компанію, і з’явилася без паралельного стеку, який довелося б підтримувати. Чи є соціальний рівень правильною інвестицією для морського каталогу — це продуктове питання, а не інженерне: він тут, бо цього попросив продукт, і побудований так само, як усе навколо нього.

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

2026-10-09T14:31:15+02:00

Ситуація. Комерційний аргумент на користь морської професійної мережі — це найм: компаніям потрібні екіпажі та офіцери, а морякам потрібні посади на суднах. Обидві половини вже існували на платформі, але не в тій формі — компанії були в каталозі, фахівці мали профілі, і ніщо не поєднувало вакансію з людиною, кваліфікованою її закрити. Найскладніше — саме кваліфікація, бо в цій галузі це сертифікати, ранги й задокументований стаж плавання, а не назва посади.

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

Дія. Побудовано два домени. Сторона найму налічує 32 таблиці та 118 функцій і охоплює вакансії, заявки, формування короткого списку та погляд роботодавця на весь потік кандидатів. Кар’єрний робочий простір несе 16 таблиць і 33 функції, у яких зберігаються сертифікати, просування в рангах і стаж плавання, разом із завантаженням документів і чергою ручної перевірки, щоб кваліфікацію було перевірено, а не просто задекларовано. Саме моделювання просування як графа, а не списку, робить зіставлення корисним: одного рангу можна досягти з іншого за наявності певних сертифікатів і достатнього зафіксованого часу в морі, і саме ця структура дає змогу зіставляти вакансію з кар’єрою, а не з ключовим словом. Кар’єрний робочий простір постачається за feature flag і ще не випущений повністю; сторона найму вже працює.

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

Втримала всю компанію на одному хості з 512 МБ і одним ядром — git‑форж, вебсервер для семи доменів, Tor, два сервери альтернативних протоколів, резервні копії та блокування вторгнень — розглядаючи 464 МБ доступної пам'яті як зобов'язальне архітектурне обмеження.

2026-10-09T14:31:15+02:00

Ситуація. Робочий хост компанії — це одноядерний хмарний примірник із 512 МБ пам’яті та 10 ГБ диска, з яких придатними до вжитку є близько 464 МБ. Усе, що бізнес виконує публічно, стоїть на ньому: вебсервер, що термінує TLS для семи доменів, git‑форджа, onion‑служба Tor, сервер Gemini, сервер Gopher, зашифровані резервні копії та блокування вторгнень. Звична реакція на цей перелік — придбати більшу машину.

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

Дія. Пам’ять стала аргументом, що вирішував суперечки. Немає ані агента моніторингу, ані конвеєра метрик, ані панелі — звітність є витягуванням, сім команд, що читають хост і формують Markdown, нічого не змінюючи й запускаючись лише на прохання. Наглядачем є systemd, а не другий менеджер процесів, накладений поверх нього, а контейнерна площина — це модулі Quadlet під тим самим наглядачем, а не демон із власним. Платформи з вебпанелями відкинуто ще на етапі задуму з тієї самої причини. Коли постало питання, чи витримає хост onion‑службу, відповідь надійшла з доби вимірюваних зразків, а не з думки: доступна пам’ять ніколи не опускалася нижче приблизно 310 МБ із 464, підкачування трималося на 2,6 відсотка, а процесор був вільним на 99,7 відсотка.

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

Розгорнула власний git‑форж компанії на Soft Serve, приватний за замовчуванням і без вебпанелі, з портом SSH, прив'язаним до loopback за хостом‑переходом, і зробила посадкову сторінку перед ним артефактом збірки основного сайту, а не копією, яку тримають руками.

2026-10-09T14:31:15+02:00

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

Завдання. Канонічний git‑сервер треба було підняти на наявному хості, з якнайменшою поверхнею атаки й без вебпанелі адміністрування, і поставити перед ним посадкову сторінку, що не гниє.

Дія. Форджа — це єдиний двійковий файл під наглядом операційної системи, встановлений із пакункового репозиторію постачальника, свідомо обраний за те, що він передусім працює через SSH і не має адміністративного вебінтерфейсу: що менше інтерфейсу, то менше треба захищати. Він приватний усталено: анонімний доступ відхиляється, доступ без ключа відхиляється, і кожен оголошений репозиторій позначено як приватний, а не покладено на невідомість. Його слухач SSH прив’язується лише до інтерфейсу зворотної петлі на порту 23231 і досяжний ззовні через хост‑перехід, тож оголошена поверхня брандмауера не зростає. Мультиплексор протоколів, що поставив би HTTPS і git‑SSH на один публічний порт, оглядаючи перші байти з’єднання, написано й готово за головним вимикачем, і цей вимикач вимкнено: багатокористувацький git через публічний порт поки не потрібен, а слухач, яким ніхто не користується, є поверхнею. Посадкова сторінка перед ним була цікавішою задачею. Вона була рукотворною копією оформлення головного сайту у власному репозиторії, і кожна знайдена між ними відмінність виявилася випадковістю, а не рішенням: шкала розмірів, що подавала словесний знак приблизно на дев’ять відсотків завеликим, оголошення шрифту, що зводило дві насиченості до однієї на будь‑якій машині зі встановленою гарнітурою, оздоби, приховані нижче певної ширини, тож відсутні на кожному телефоні, насиченість, використана без постаченого для неї шрифту, і жодного головного орієнтира чи заголовка верхнього рівня на жодній сторінці. П’ять із п’яти, і жодної видимої на знімку екрана. Копію видалено; посадкову сторінку тепер будують власні шаблони головного сайту й доставляють як артефакт.

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

Побудувала багатомовний статичний сайт на Hugo зі 108 файлів шаблонів, з яких 53 партіали, що публікує кожну сторінку у чотирьох представленнях з одного дерева контенту трьома мовами, і ще раз під сімома сфокусованими субдоменами, зібраними з того самого дерева.

2026-10-09T14:31:15+02:00

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

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

Дія. Це статичний сайт: 108 файлів шаблонів, з яких 53 є частковими шаблонами і 18 — шорткодами, три мови, жодного бекенду часу виконання й один власний скрипт, наданий як обмежений виняток для фільтра портфоліо, чий кожен елемент керування прихований, доки скрипт не запуститься. Спроможність додається під час збирання, а не в браузері, і це продуктове рішення, записане саме як рішення. Кожну сторінку публікують у чотирьох поданнях з одного дерева вмісту — HTML, двійник у Markdown, документ Gemini та пункт меню Gopher, — а головна сторінка додає до цього три стрічки та маніфест встановлюваного застосунку. Таксономій навмисно дві, а не одна, і ця відмінність є несучою: категорія є тематичною позначкою на роботі, послуга є тим, що компанія продає, і злиття їх зробило б каталог переліком навичок замість переліку пропозицій. Те саме дерево потім збирають ще сім разів, по одному на кожен сфокусований субдомен, скеровуючи генератор на інший каталог вмісту, а не відгалужуючи будь‑що.

Результат. Сайт віддає три мови та чотири подання з одного дерева, не має бекенду для атаки й нічого для оплати, а той єдиний шматок JavaScript у ньому тримається контракту, який примусово застосовує лінтер. Ціна в тому, що все інтерактивне має розв’язуватися під час збирання або ніяк, і це відкинуло кілька речей, що були б легкими із сервером, і є причиною, чому пошуковий індекс оцінили та відклали, а не випустили.

Скоротила керовані браузером ворота якості сайту з 1 636 секунд до 615, плануючи їхні перевірки від найдовшої через пул воркерів, обмежений чотирма смугами, вимірявши, що абеткова черга коштувала 320 секунд проти 224.

2026-10-09T14:31:15+02:00

Ситуація. Одинадцять перевірок сайту керують браузером без вікна: розкладка за кожної форми вікна, яку малює дизайн, шкала розмірів, розширення перекладеного тексту, контраст, правила доступності, примусові кольори, розміри маскота, рух, друк у шести комбінаціях паперу, помилки консолі та візуальна регресія. Виконувані по одній, вони брали 1 636 секунд, трохи більш ніж двадцять сім хвилин. Перевірка, що триває двадцять сім хвилин, — це перевірка, яку пропускають, а пропущену перевірку не відрізнити від пройденої.

Завдання. Час за годинником мав опуститися настільки, щоб їх запуск був усталеним варіантом, а не рішенням, і жодну з них при цьому не можна було послабити.

Дія. Робота почалася з вимірювання. Кожну перевірку заміряно окремо на дванадцятиядерній машині: розкладка на 405 секундах, шрифт на 301, переклад на 282, контраст на 189, доступність на 178 і далі вниз аж до сімнадцяти. Відповідь сформували два висновки. Виконувати всі одразу було повільніше, ніж по чотири за раз, — 265 секунд проти 224, — бо кожна перевірка сама є браузером, що виконує паралельну роботу, і надмірне навантаження машини коштує більше, ніж виграє паралельність. А впорядкування за найдовшим часом обробки спершу перемогло абеткове майже на третину, 224 секунди проти 320, і це класичний результат теорії розкладів, який виявляється тут тому, що перевірки різняться у вартості в двадцять разів. Тож виконавцем є обмежений пул робітників, розмір якого береться з кількості ядер із підлогою в два та стелею в чотири, і який годують найдовшим спершу. Поряд із цим перевірки радше розширили, ніж звузили: вони тепер спільно використовують одну таблицю з двадцяти двох форм вікна, виведену з кожного медіазапиту, який насправді містить таблиця стилів, і це саме лише підняло перевірку розкладки з 95 секунд до 405.

Результат. Перевірка пішла з 1 636 секунд на 615, тоді як самі перевірки стали ширшими, а не тоншими — послідовна вартість зросла, а час за годинником упав. Вимірювання є тією частиною, яку варто зберегти: два розумні на слух вибори, виконувати все одразу й виконувати в порядку написання, кожен виявився вимірювано гіршим за альтернативу.

Замінила 27 відтворених розмірів шрифту, чиї найближчі сусіди різнилися на 0,6%, шестикроковою шкалою Major Third і написала лінтер, який валить двадцять восьмий.

2026-10-09T14:31:15+02:00

Ситуація. Вимірювання поданого тексту сайту виявило двадцять сім різних розмірів шрифту в ужитку. Кілька з них розділяв менш ніж один відсоток — п’ять значень між 0,8 і 0,85 від розміру основного тексту були живими одночасно, а це різниця, якої жоден читач не здатен відчути і до якої кожен наступний редактор додасть свою. Два заголовки таблиця стилів не розмічала за розміром узагалі, і вони провалювалися до власних усталених значень браузера, у співвідношення 1,33, що не відповідало нічому іншому на сторінці.

Завдання. Розміри мали стати шкалою з оголошеним співвідношенням, і щось мало завадити появі двадцять восьмого.

Дія. Шкалою є велика терція зі співвідношенням 1,25, шість іменованих щаблів від дрібного шрифту до плакатного, кожен із яких є токеном, а не значенням. Заголовки явно накладено на щаблі замість успадкування того, що думає браузер, і саме це виправило ті два, що не мали власного розміру. Підлогу встановлено лише для найнижчого щабля, тож дрібний шрифт лишається читним на телефоні без прив’язування всієї шкали. Логотипи звільнено за іменем, а не випадково. Лінтер є тією частиною, що тримає це разом: він подає сайт і валить збирання на двадцять восьмому різному розмірі. Він уже двічі виправдав своє місце — спіймав заголовок, що прибув на 1,17 від розміру основного тексту, а це не щабель нічого, і назвав співвідношення в повідомленні про відмову; і спіймав вбудований код на 0,9, а це саме той різновид значення, заради запобігання якому шкала й існує. Поряд зі шкалою пішла міра приблизно у сімдесят два символи, що замінила успадковану фіксовану ширину, яка давала дев’яносто один символ на сторінці відгуку і сто десять на сторінці контактів.

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

Довела WCAG 2.2 рівня AA на 32 представницьких сторінках — по одній на шаблон на мову — в обох колірних темах, плюс два критерії AAA, із задокументованим записом відповідності та перевіркою, що захищає кожне твердження.

2026-10-09T14:31:15+02:00

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

Завдання. Сайт мав відповідати WCAG 2.2 на рівні AA на кожній сторінці, кожною мовою та в обох темах, і цю відповідність мали захищати перевірки, а не заява в документі.

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

Результат. Відповідність заявлено на рівні AA трьома мовами й у двох темах, з двома критеріями AAA понад це та одним, названим як виняток, і за кожною заявою стоїть перевірка. Найважчою була контрастність над фотографією, яку автоматичний механізм правил позначає як таку, що її не оцінити, і яку сайт захищав аргументом, а не числом: справжні показники — 49 із 64 пар сторінки й теми нижче AA. Причиною виявилися дві поверхні, якими дизайн ніколи не володів, а перевірка, що їх знайшла, тепер є підлогою: кожна пара має витримувати AA над стіною, яку малює збірка, а пара, що не витримує, валить збірку. Те, що сайт каже на власній сторінці подяк, є чесною частиною: жоден автоматичний інструмент не знаходить більш ніж приблизно третину порушень WCAG, підписи, що з’являються під вказівником, не можна закрити клавішею, бо для цього потрібен скрипт, а сайт виконує лише один, і випробувань зі справжніми допоміжними технологіями не було — ці межі записано там, де читач їх побачить, а не вилучено із заяви.

Знайшла й виправила 11 дефектів доступності, які браузер звітував здоровими: вісім посилань підвалу, що лишалися в порядку табуляції за pointer‑events, шкалу прокрутки, яка обрізала колофон на трьох сторінках, і механізм правил, що виконував 70 зі своїх 105 правил.

2026-10-09T14:31:15+02:00

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

Завдання. Дефекти треба було знайти, виправити та описати як реєстр із правилом, яке породив кожен із них, щоб закривався клас дефектів, а не окремий випадок.

Дія. Вони поділилися на три групи. Розміри: ключове слово таблиці стилів, ужите так, ніби воно відносне, прив’язало цілу ділянку до шістнадцяти пікселів, тоді як основний текст сягав двадцяти двох; елемент нижнього індексу вжито у значенні «менший»; зменшення тексту подовжило рядок так, що заголовок сягнув дев’яноста шести символів; а виміряна стеля висоти була переросла саме тим перевизначенням відступів, підтримку якого сайт заявляє. Фокус і обрізання: вісім посилань підвалу лишалися в порядку табуляції за властивістю, що прибирає взаємодію вказівником і більш нічого; правило переповнення створило контейнер прокручування, якого ніхто не хотів; а анімація, керована прокручуванням, яка просто неактивна на сторінці, надто короткій для прокручування, назавжди обрізала підвал на трьох сторінках. І два дефекти в самих вартових, які варто назвати окремо, — кожна форма вікна, яку відкривала перевірка розкладки, мала дев’ятсот пікселів заввишки, тож телефон у альбомній орієнтації на 852 на 393 давав сім пікселів між двома елементами, і жодна перевірка туди ніколи не дивилася; а рушій правил виконував сімдесят зі своїх ста п’яти правил, тож правила, яке спіймало б відсутній орієнтир, у наборі не було.

Результат. Одинадцять дефектів виправлено і, що корисніше, чотири правила, які їх переживуть: вартовий, що перевіряє одну вісь, захищає одну вісь; набір правил, що не містить правила, не може його примусово застосувати; висота є виміром, тож перевіряйте її; і доводьте видимість у пікселях, а не в документі. Коли перевірку розкладки належно відкрили заново, вона провалилася сто двадцять вісім разів трьома мовами, зокрема на вікні завбільшки з телефон, де завершальний рядок головного блоку сидів на двадцять один піксель нижче згину.

Згенерувала 495 сторінок досягнень трьома мовами з експорту SQLite лише для читання, де адресу сторінки авторовано як дані, тож виправлення речення більше не пересувало сторінку й не ламало посилання.

2026-10-09T14:31:15+02:00

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

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

Дія. Експортер читає базу даних лише для читання й пише по одній сторінці на досягнення на мову — 495 сторінок — плюс дані таксономії та послуг, потрібні шаблонам. Він використовує лише стандартну бібліотеку, тож збирання сайту не залежить від середовища генератора, а закомічений вивід означає, що сайт збирається самостійно. Найбільш наслідкове рішення в ньому стосується адрес. Раніше сайт виводив URL сторінки з перших слів її англійського твердження, тож виправлення речення мовчки переносило сторінку й ламало кожне посилання на неї — сайт, чиїм аргументом на власну користь є те, що він виправляє речі, штрафував себе мертвим посиланням щоразу, коли це робив. Адресу тепер створюють як дані: по одному рядку на адресу на досягнення, перша є поточною, а кожна наступна є відставленою адресою, яку сайт видає як перенаправлення. З тієї самої роботи записано ще дві пастки. Порівняння періоду з текстовим стовпчиком мовчки збіглося з усіма тридцятьма двома рядками через те, як база даних призначає спорідненість типів у порівнянні. І перелік мов тепер є єдиною віссю, з якої виводять і цикл запису, і файли даних, і запити, тож додати четверту мову — це один запис у відображенні, а не пошук.

Результат. Чотириста дев’яносто п’ять сторінок генерується з одного джерела, виправлення твердження нічого не коштує, а адреси, які цей сайт колись публікував, і далі відповідають. Експортер також володіє рівно одним рішенням про подання — тим, як послуги групуються в тематичні розділи, — і це навмисно: усе інше, що він пише, належить базі даних, а заголовок групи без якоїсь мови валить експорт, а не подає англійську поверх перекладеного вмісту.

Закрила систему кольорів на 28 задокументованих кольорах із лінтером, який валить значення, намальоване але незадокументоване, задокументоване але ненамальоване, хибно виміряне, переписане як літерал або в межах перцептивної відстані 0,02 від уже наявного.

2026-10-09T14:31:15+02:00

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

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

Дія. Двадцять вісім кольорів, кожен задокументований із коефіцієнтом контрасту, який він показує на поверхні, де з’являється, та одинадцять брендових значень, оголошених один раз як токени. Поріг є числовим, а не редакційним: два кольори, ближчі за перцептивну відстань 0,02 в однорідному колірному просторі, є одним кольором із двома написаннями. Лінтер валить збирання п’ятьма різними способами — значення пофарбоване, але незадокументоване; задокументоване, але непофарбоване; записане з хибним коефіцієнтом; у межах порога від того, що вже є; або брендове значення, переписане як літерал. Він одразу знайшов два: колір теми, що існував у двох написаннях на відстані 0,018, і колір тла, що заміняв стіну, від якої стояв на 0,021. Прозорість використовує відносний колірний синтаксис, а не функцію змішування, саме тому, що вартовий не бачить крізь суміш, а палітрний вартовий, якого можна обійти, не є вартовим. Правило, що йде з цим, коротке: змінюйте токен, а не правило, додавайте колір лише тоді, коли жоден не пасує, і ніколи не знижуйте задокументований коефіцієнт, щоб дизайн запрацював.

Результат. Палітра є замкненим виміряним набором, що не може тихо зростати, а два майже однакові написання, які до цього спонукали, зникли. Це обмеження, що подеколи каже ні: дизайн, який хоче трохи інший синій, мусить узяти той, що існує, або обґрунтувати двадцять дев’ятий колір, і це обґрунтування має містити коефіцієнт.

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

2026-10-09T14:31:15+02:00

Ситуація. Сайт постачає дві колірні теми. Темна є усталеною і на неї дивляться постійно; світла є перевизначенням, що з’являється лише за системною вподобою, а це означає, що її бачать значно рідше і ніхто з тих, хто її перевіряє. Паритет тем є класом дефектів, у якому поверхню будують один раз і переказують один раз, а переказ тихо губить шар.

Завдання. Паритетові потрібне було твердження, бо єдиною альтернативою є людина, яка пам’ятає перемкнути вподобу й подивитися.

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

Результат. Шар, відсутній в одній темі, тепер валить коміт, а той, що був відсутнім від дня написання, пофарбовано. Це і є форма дефекту, на яку націлено весь підхід із перевірками: нічого не було зламано, нічого не давало помилки, сторінка подавалася правильно, і вона була хибною місяцями.

Зробила зменшений рух чесним, знайшовши одинадцять селекторів, які досі анімувалися під цією настройкою, бо універсальне правило transition‑none програє за специфічністю будь‑якому правилу з класом.

2026-10-09T14:31:15+02:00

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

Завдання. Уподобу треба було шанувати насправді, а причина, чому очевидне правило не спрацювало, мала стати тим, чого наступна людина не зможе повторити.

Дія. Причиною є специфічність. Універсальне правило набирає найнижчий бал у каскаді й програє будь‑якому правилу з класом, тож суцільне вимкнення переходів програє кожній продуманій анімації на сторінці — а це і є кожна анімація, яку варто вимикати. Виправлення було структурним, а не латкою: усе, що рухається, тепер живе в одній пізній частині таблиці стилів, а лінтер валить перехідне перетворення будь‑де інде. Розрізнення, яке проводить правило, є навмисним і вужчим за очевидне: зменшуйте рух, а не колір. Згасання кольору не є рухом, і його вимкнення робить інтерфейси на відчуття зламаними для людей, які цього не просили, тож перехід, що перелічує колірні властивості, проходить, а перехід на русі — ні. Рух також зобов’язаний виражатися як перехід, а не як анімація за ключовими кадрами, бо перший тривіально скасовується, а друга — ні. З тієї самої роботи вийшли дві суміжні пастки, записані з вимірюваннями: оздоба меню проходила тридцять один градус із шістдесятиградусного повороту, перш ніж стати наполовину видимою, і оскільки форма періодична, півповорот має однаковий вигляд за третину вартості; і п’ять різних властивостей кожна робить елемент вмісним блоком для всього, спозиційованого відносно вікна перегляду, що мовчки зменшило шар закривання до частки екрана.

Результат. Уподобу шанують насправді, а не за наміром, і одинадцять живих анімацій, які суцільне правило нібито покривало, покрито справді. Загальний урок записано на початку того документа: правило, що програє за специфічністю, відмовляє мовчки, і кожен звіт називає це якось інакше.

Побудувала друкований стиль на 637 рядків проти чотирьох задокументованих поведінок рушія відтворення, зокрема вбудованих заголовків, які друкувалися білим по білому для будь‑якого читача, чий браузер надавав перевагу темному.

2026-10-09T14:31:15+02:00

Ситуація. Кейси сайту є тим артефактом, який хтось роздруковує й несе на зустріч. Це робить папір справжнім виходом, а не люб’язністю, а папір є іншим носієм, ніж вузький екран — розмір паперу читача невідомий, орієнтація читача невідома, а поведінка браузера під час друку різниться між рушіями так, як жодний екранний перегляд не покаже.

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

Дія. Це одна таблиця стилів на 637 рядків з єдиним правилом сторінки й одним блоком друку. Правило сторінки задає поле й навмисно не задає розміру паперу, тож те, що читач обере в діалозі, проходить наскрізь, і все інше до цього пристосовується. Кореневий розмір шрифту закріплено в пунктах, тож кожне відносне вимірювання має фізичний якір, а одну міру приблизно у сімдесят два символи застосовано до чотирьох блоків верхнього рівня — і це аркуш перемагає дизайн, бо альбомна сторінка інакше розганяла б рядок приблизно до ста десяти символів. Чотири види поведінки рушіїв задокументовано як пастки, і кожен спричинив справжній дефект. Одиниці вікна перегляду розв’язуються в коробку сторінки в одному рушії й у вікно в іншому, тож сторінка, надрукована з широкого вікна, має третину кожного рядка обрізаною в другому. Елементи з фіксованим положенням малюються на кожному аркуші, тож декоративні прибрано, а два з них перепризначено на бланк і колофон. Палітра усталено бере білий текст, бо усталеною темою є темна, і це друкувало чотири підзаголовки розділів білим по білому — слова просто були відсутні. А сторінковий носій не може розділити гнучку чи сіткову коробку, що дало порожній перший аркуш на сторінці досягнення. Це покриває перевірка з шести частин, що випробовує шість комбінацій паперу й орієнтації, обидві вподоби колірної схеми та справжню кількість сторінок проти тієї, яку передбачає висота вмісту.

Результат. Сайт друкується на невідомому папері в обох темах, а чотири види поведінки рушіїв записано разом із дефектом, який спричинив кожен. Відомі межі записано, а не приховано: немає ні номерів сторінок, ні колонтитулів, один рушій ігнорує контроль висячих рядків, а буквиці не є універсальними. Одного разу випадковий термінатор коментаря змусив лінтер CSS проковтнути ціле правило і двічі пройти чисто — помітила це лише перевірка друку.

Віддзеркалила весь сайт як 777 документів Gemini і 777 документів Gopher з того самого розгорнутого дерева, з нульовою зміною байтів у HTML.

2026-10-09T14:31:15+02:00

Ситуація. Сайт статичний, не має ні стеження, ні бекенду часу виконання, і його аргумент полягає в тому, що документові не потрібен мегабайт JavaScript, аби його прочитали. Цей аргумент легко висловити й важко продемонструвати. Два невеликі інтернет‑протоколи демонструють його безпосередньо, бо жоден із них узагалі не здатен нести скрипт.

Завдання. Увесь сайт мав публікуватися через Gemini і Gopher із того самого вмісту, без другого дерева вмісту й без змін у HTML.

Дія. Обидва є форматами виводу того самого збирання, а не окремим конвеєром. Генераторові сайту надали власні типи носіїв і формати виводу, і кожна сторінка, розділ та термін таксономії дістали ще по два подання поруч зі своїм HTML і двійником у Markdown. Результатом є 777 документів Gemini і 777 меню Gopher, вироблені з того самого джерела, розгорнуті в те саме дерево й віддавані двома невеликими демонами на тому самому хості. Дві властивості зробили це вартим роботи, а не дивиною. Обидва формати позначено як неальтернативні подання, тож у HTML не змінилося нічого — жодного байта, і це виміряли, а не припустили. А формат Gopher не має способу вкласти посилання всередину речення, бо рядок меню є полями, розділеними табуляціями, тож прозу жорстко переносять на шістдесят восьмому стовпчику під час збирання; це обмеження вигострило письмо так, як HTML ніколи не вимагав. Поруч із ними стоїть onion‑дзеркало Tor, і це єдине публічне обличчя, яке платформа могла додати, не відкриваючи порту брандмауера, бо демон додзвонюється назовні, а всередину не дзвонить ніхто.

Результат. Сайт читний чотирма протоколами з одного збирання, по 777 документів на кожен і з нульовою зміною HTML, а альтернативні подання коштують приблизно дванадцять відсотків від власної ваги HTML на диску. Лише один із чотирьох вимірюється щодо трафіку, і це зазначено у власному документі статистики платформи, а не тихо проігноровано.

Замінила 963 анонімні блоки структурованих даних, які переповідали компанію 1 671 раз, одним пов'язаним графом із 16 типів, викарбуваним зі стабільних ідентифікаторів походження.

2026-10-09T14:31:15+02:00

Ситуація. Сайт видавав структуровані дані так, як це робить більшість сайтів: по блоку на сторінку, і кожен описував організацію заново з нуля. На весь сайт це дало 963 блоки, що переказували ту саму компанію 1 671 раз, анонімно — жодного стабільного ідентифікатора ніде, тож ніщо із тих, хто це споживає, не могло сказати, що організація на одній сторінці є організацією на іншій.

Завдання. Структуровані дані мали стати одним графом зі стабільною тотожністю, а не купою блоків, що випадково містять ті самі слова.

Дія. Ідентифікатори тепер карбують із джерела сайту — один для організації, один для сайту, один для особи, — і кожен блок посилається на них, а не переказує їхній вміст. Ідентифікатори є спільними для джерела, а не окремими для кожної мови, бо компанія є тією самою компанією й данською. У грі шістнадцять типів, що охоплюють каталог послуг і його пропозиції, відгуки та роботу, яку вони описують, добірки та їхні навігаційні ланцюжки. Два рішення втримали вагу. Сторінки переліків публікують свої елементи лише за URL, а не вбудовують їх, і це виміряли: назвати їх на індексі портфоліо означало б 107 повних тверджень і зростання стиснутої сторінки на 52 відсотки. А перевірка, що це стереже, не просто підтверджує синтаксис — вона стверджує, що кожен блок розбирається, що кожен ідентифікатор розв’язується і що кожну URL‑адресу, яку називає граф, справді було зібрано, тож граф, що вказує на неіснуючу сторінку, валить перевірку.

Результат. Один граф зі стабільною тотожністю замінює 963 анонімні переказування, і сторінки несуть менше, а не більше. Вимірювання, з якого почалася робота, варто тримати в голові: сайт видавав той самий опис організації 1 671 раз, і ніщо не могло їх поєднати.

Скоротила пакунок стилів із 87 КБ до 31 КБ, вийнявши з нього шрифт у base64, і відкинула 756 КБ у 22 файлах, які публікувалися при кожному розгортанні й на які ніщо не посилалося.

2026-10-09T14:31:15+02:00

Ситуація. Пакет таблиць стилів сайту важив 87 КБ, а для документного сайту без фреймворку це більша частина ваги сторінки, витрачена ще до прибуття будь‑якого вмісту. Сайт до того ж публікував каталог піктограм за кожного розгортання, згенерований один раз і відтоді ні з чого не згаданий.

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

Дія. Спершу вимірювання. Дві третини найбільшої таблиці стилів були одним шрифтом, закодованим у base64, — приблизно 56 КБ тексту, що кодували приблизно 42 КБ шрифту, — вбудованим заради виграшу в першому промальовуванні, який попередньо завантажений зовнішній файл дає й так, і оплачуваним на кожній сторінці незалежно від того, чи потрібна була та вага. Його вилучення забрало цей файл з 84 КБ до 28, а весь пакет з 87 до 31. Три насиченості шрифту натомість попередньо завантажуються, і третя приєдналася до переліку лише тоді, коли польові дані показали, що вона закриває найдовший критичний ланцюжок, а не тому, що три звучить завершено. Окремо перевірка того, що розгортання насправді публікувало, виявила двадцять одну згенеровану піктограму та дублікат файлу налаштувань, 756 КБ, що вивантажувалися щоразу й не згадувалися нізвідки; а власний файл піктограм сайту впав із 145 КБ до 15. Сучасний формат зображень оцінили для знака бренду, виміряли й відхилили — він вийшов більшим, а механізм вибору бере за порядком, а не за розміром, тож сучасний браузер брав би скрізь важчий файл. Дві перевірки тепер тримають межу: жодну світлину не можна показувати ширшою за половину її вихідних пікселів, і кожну ілюстрацію треба публікувати в розмірі, який підтримують її власні пікселі і за звичайної, і за високої щільності.

Результат. Пакет важить 31 КБ замість 87, 756 КБ мертвих ресурсів перестали розгортатися, і за кожним рішенням стоїть вимірювання — зокрема за тим, що пішло в інший бік, і це корисніший запис із двох.

Виправила мапу сайту, де 172 з 176 URL мали одну позначку часу зміни, взявши дату з історії git після встановлення, що експорт переписує кожен файл при кожному запуску.

2026-10-09T14:31:15+02:00

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

Завдання. Дати мали описувати вміст, а не файл, не вигадуючи точності, якої репозиторій не має.

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

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

Підвела 10 242 рядки JavaScript воріт якості під форматувальник і лінтер, встановивши, що це найбільший обсяг коду в репозиторії й єдиний, якого ніщо не читало, виправила 13 знахідок і не придушила жодної.

2026-10-09T14:31:15+02:00

Ситуація. Перевірка якості сайту — це тридцять два скрипти загальним обсягом 10 242 рядки JavaScript. Це був із великим відривом найбільший масив коду в репозиторії, і це був єдиний масив коду, якого ніщо не читало — ані форматувальник, ані лінтер, ані перевірка типів. Програми, що примусово застосовували кожне правило в проєкті, були єдиними програмами, на які не поширювалося жодне з них.

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

Дія. Форматувальник ішов першим, і ширина відступу була цікавим рішенням. Усталеним значенням репозиторію є чотири пробіли; за чотирьох пробілів форматувальник переписав би 2 173 рядки найбільшого перевіряльника. Перевизначення на два пробіли для цих файлів звело це до 38 рядків справжнього розходження. Записаний із цим принцип полягає в тому, що форматувальник припасовують до коду, а не код до форматувальника — переформатування двох тисяч рядків заради вподобання знищує здатність читати історію файлу. Далі лінтер, що дав тринадцять справжніх висновків, усі виправлено й жодного не придушено. Перевіряльники на Python дістали те саме поводження через перевіряч типів, налаштований на середню суворість із тридцятьма окремими правилами суворого рівня, увімкненими понад це й обраними за вимірюванням: за цього налаштування дерево мовчить, і з тридцяти кандидатів двадцять дев’ять уже мовчали, а один спрацював — і його виправили, а не звільнили. Перевіряч типів знайшов два справжні дефекти, які лінтер пропустив чистими, обидва про форму значення, а не про його синтаксис.

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

Побудувала на Python генератор CV, рекомендацій, портфоліо та супровідних листів на основі бази даних — 41 модуль, 10 580 рядків — що відтворює шість форматів виводу з одного джерела SQLite на 23 таблиці, зібраного ідемпотентним конвеєром із 19 кроків.

2026-10-09T14:31:15+02:00

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

Завдання. Одне джерело фактів мало виробляти кожен документ, кожною мовою, у кожному форматі, з упорядкуванням, яке вирішує код, а не той, хто останнім редагував файл.

Дія. Джерелом є база даних SQLite із двадцяти трьох таблиць — досягнення, посади, компанії, регіони, категорії, послуги, профілі, рекомендації, резюме, — зібрана конвеєром із дев’ятнадцяти кроків, що йде від порожнього файлу до повної бази даних однією командою. Кроки впорядковано, і кожен написано так, щоб його було безпечно повторювати, тож конвеєр можна виконати проти наявної бази даних, не дублюючи жодного рядка. Сорок один модуль Python загальним обсягом 10 580 рядків подають із неї шість вихідних форматів: HTML, PDF у двох варіантах, звичайний текст, Markdown і JSON, через шість шаблонів Jinja і вісім таблиць стилів. Залежності часу виконання втримано рівно на двох, шаблонний рушій і рендерер PDF, з тим аргументом, що генератор документів, який не вдасться встановити за п’ять років, нічого не зберіг. Націлювання є повноцінним поняттям, а не ручним редагуванням: профіль обирає, які досягнення з’являються і в якому порядку, тож документ, спрямований на один різновид читача, є запитом, а не копією.

Результат. Шість форматів, три мови й п’ять тем виходять з однієї бази даних, а виправлене речення виправляють один раз. Ціна в тому, що система тепер є єдиним способом виробити документ — більше немає файлу, який можна поспіхом відкрити й відредагувати, а додати мову означає додати її скрізь, перш ніж узагалі щось збереться.

Втримала генератор на 981 тестовому випадку із порогом покриття гілок 92% і попередженнями як помилками та ствердила ідемпотентність, запустивши весь конвеєр збірки двічі з порожнього файлу й вимагаючи, щоб другий прохід нічого не змінив.

2026-10-09T14:31:15+02:00

Ситуація. Генератор, що збирає базу даних з нуля, має особливий різновид вади: він працює першого разу й псує другого. Кроки, що вставляють без перевірки, кроки, що залежать від порядку виводу попереднього кроку, кроки, безпечні поодинці й не разом. Нічого з цього не виявляється в тесті, що починає з нічого й виконується один раз.

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

Дія. Тест ідемпотентності є прямолінійним і найкориснішим: зібрати всю базу даних із порожнього файлу, зробити знімок, виконати весь дев’ятнадцятикроковий конвеєр знову поверх результату й вимагати, щоб другий прохід нічого не змінив. Кількості рядків, вміст та ідентифікатори мають збігатися. Довкола нього стоять 383 тестові функції — 981 випадок, коли параметризовані розгортаються, — у сорока п’яти файлах і 7 944 рядках, що охоплюють конвеєр, рендерери, завантажувачі вмісту, логіку націлювання та перевіряльників. Покриття гілок несе підлогу в дев’яносто два відсотки, примусово застосовану в збиранні, а не подану в підсумку, і набір наразі показує близько 95 відсотків, тож підлога має запас і не є декоративною. Попередження налаштовано як відмови, і саме це налаштування на практиці важить найбільше — сповіщення про застарілість, що друкується два роки, є сповіщенням, якого ніхто не читає, а прогін, що перетворює його на червоний тест, є тим прогоном, після якого його виправлять.

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

Встановила відповідність PDF/UA‑1 на дев'яти документах за 106 зі 106 правил і виявила, що архівний варіант валить одне правило зі 146 — майже‑успіх, який читається як успіх для будь‑кого, хто не запускає валідатор.

2026-10-09T14:31:15+02:00

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

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

Дія. Дев’ять документів — CV у своїх варіантах, аркуш рекомендацій, портфоліо та супровідний лист, у різних мовах — прогнали через незалежний валідатор окремо для профілю доступності й архівного профілю. Профіль доступності проходить на 106 зі 106 правил, і це вимагало тегованої структури, оголошеної мови документа, альтернативного тексту на кожній недекоративній графіці, справжнього заголовка в метаданих і явного порядку читання замість того, який випадково дає розкладка. Архівний профіль дає цікавіший результат: він валить рівно одне правило зі 146. Це та форма результату, яку легко подати хибно. Сто сорок п’ять пройдених у підсумку читається як відповідність, і це не відповідність; це документ, який відхилить система, що застосовує стандарт. Правило, яке не проходить, записано разом із тим, що воно є і чому його не закрито, а не заокруглено геть.

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

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

2026-10-09T14:31:15+02:00

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

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

Дія. Вибір повного набору правил дав 1 815 висновків на першому прогоні. Їх опрацьовували за категоріями, а не за файлами, бо категорії про щось кажуть: невживані аргументи та затінені вбудовані імена є шумом, а категорія безпеки, категорія змінюваних усталених значень і категорія обробки винятків кожна вказувала на справжню поведінку. Справжні несумісності існують — форматувальник і лінтер можуть розходитися щодо того самого рядка, а кілька правил суперечать власним свідомим виборам проєкту, — і кожне з невеликої кількості звільнень несе письмову причину в тому місці, де звільнення береться, і каже, чого хотіло правило й чому цей код робить інакше. Два з них ідуть далі й підперті перевіркою, а не коментарем, тож звільнення не може тихо розширитися: правило вимкнено, а тест стверджує саме ту властивість, яку правило примусово застосувало б. Поряд працює перевірка типів у суворому режимі, а це окремий і жорсткіший стандарт, і саме вона спіймала дефекти, яких лінтер не бачив, бо вони про те, чим значення є, а не про те, як його записано.

Результат. Лінтер працює на повну силу з нулем висновків, і кожне відхилення задокументовано в тому рядку, де його взято. Ціна реальна й варта називання: найсуворіше налаштування дає висновки, на які щиро не варто зважати, і хтось має ухвалювати це рішення 1 815 разів, а не один раз.

Вбудувала кодувальник QR — Ріда‑Соломона над GF(256), фіксоване розташування модулів, вісім шаблонів маски — на 522 рядках, замість брати третю залежність часу виконання, і перевірила його, зчитавши готову матрицю незалежно написаним декодером.

2026-10-09T14:31:15+02:00

Ситуація. Документам потрібен був QR‑код із посиланням на онлайнову версію. Кожна доступна бібліотека це вміє, і взяти одну з них означало б додати третю залежність часу виконання до проєкту, що свідомо тримався двох — шаблонного рушія й рендерера PDF — з тим аргументом, що генератор документів має встановлюватися й через багато років.

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

Дія. Кодувальник має 522 рядки й реалізує ті частини специфікації, які насправді потрібні для цього вжитку: кодування в байтовому режимі, виправлення помилок за Ридом‑Соломоном над полем Галуа з 256 елементів із твірним многочленом, побудованим у потрібному степені, фіксовану розкладку модулів із її пошуковими взірцями, часовими взірцями та взірцями вирівнювання, інформацію про формат і версію, а також усі вісім взірців маскування даних, оцінених за чотирма штрафними правилами специфікації, тож обирається маска з найнижчим балом, а не стала. Саме перевірка зробила це захисним. Випробовувати кодувальник проти його власної логіки не доводить нічого, тож готову матрицю модулів зчитує назад декодувальник, написаний незалежно за порядком читання зі специфікації, і тест стверджує, що декодований рядок дорівнює вхідному. Це перетворює «воно дає правдоподібне зображення» на «воно дає код, що декодується в правильну URL‑адресу», і це перевіряють за кожного прогону, а не один раз оком і телефоном.

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

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

2026-10-09T14:31:15+02:00

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

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

Дія. Результатом є 874 файли у каталозі вмісту, впорядкованих за видом, а потім за мовою: досягнення, відгуки, резюме, посади, компанії, регіони, категорії, послуги, профілі, рекомендації та фрагменти супровідних листів. Файли з полями через табуляцію, де одиницею є рядок з ідентифікатором, і окремі файли, де одиницею є абзац. Завантажувач читає їх під час збирання, і база даних збирається з них, тож дерево є джерелом, а база даних — похідною. Два висновки вийшли безпосередньо зі здатності рахувати. Деякі перекладені рядки більше не мали жодного англійського відповідника — мертві записи, яких ніщо не подавало і яких ніхто не міг би помітити, доки вони були вкладені в код, бо непосиланий ключ словника має точнісінько такий вигляд, як посиланий. А перевірка вмісту, що мала оцінювати кожне досягнення, читала лише ту підмножину, яку могла розв’язати, оцінювала тридцять сім із дев’яноста трьох і звітувала про успіх. Перетворення корпусу на каталог зробило обидва ці факти видимими як розбіжність у кількості файлів.

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

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

2026-10-09T14:31:15+02:00

Ситуація. Найшкідливіший різновид помилки перекладу в CV — не незграбна фраза. Це число, що зникає. Англійське речення, що заявляє п’ятдесятикратне поліпшення, перекладене реченням, яке каже «значно», є заявою, тихо відкликаною на одному ринку й збереженою на іншому, — і жодна перевірка орфографії, граматики чи людське читання самої лише цільової мови цього ніколи не помітить, бо перекладене речення є цілком доброю прозою.

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

Дія. Перевірка чисел витягує кожне число, відсоток, множник та одиницю з англійського рядка й вимагає, щоб кожне з них з’явилося в кожному перекладі того рядка, з формами множників, зіставленими для кожної мови окремо, а не збіганими буквально: англійська форма «у п’ятдесят разів» відповідає певній данській і певній українській вимові, і перевірка знає це зіставлення, а не вимагає самих лише цифр. Перевірка нотації є її дзеркалом: кожна мова має конвенції, які мусить вживати, і конвенції, яких вживати не має, зокрема десяткові розділювачі, групування тисяч і лапки. Українська бере лапки‑ялинки; англійські подвійні лапки в українському реченні є так само хибними, як пропущене число, і їх набагато легше внести копіюванням. Перший повний прогін виявив два данські описи, де показник, присутній в англійській, було втрачено, і шістнадцять українських фрагментів із лапками в англійському стилі.

Результат. Вісімнадцять справжніх дефектів закрито, а разом із ними закрито й клас, бо кожен майбутній переклад порівнюється зі своїм англійським джерелом, перш ніж його можна закомітити. Чого перевірка не вміє, так це судити про зміст: вона доводить, що число вижило і що пунктуація рідна, а переклад, що зберігає кожне число й водночас перевертає заяву навпаки, проходить її без зауважень.

Побудувала нативний клієнт обміну повідомленнями для macOS на Swift 6 і SwiftUI — 11 141 рядок у 53 файлах — поверх C‑інтерфейсу ядра на Rust, злінкованого як статичний архів із зафіксованої ревізії.

2026-10-09T14:31:15+02:00

Ситуація. Протокол обміну повідомленнями мав добре випробуване ядро, написане на Rust, і клієнти на кількох платформах, але настільний досвід на macOS був кросплатформною оболонкою — він не мав вигляду програми для Mac, не поводився як така й ніс середовище виконання, якого рідній програмі не потрібно. Ядро відкриває свою спроможність через C‑інтерфейс, а це означає, що будь‑яка мова, здатна викликати C, може на ньому будувати, і Swift здатен.

Завдання. Рідного клієнта треба було збудувати безпосередньо на тому C‑інтерфейсі, поточною мовою платформи та її поточним інтерфейсним каркасом, із ядром, вкомпонованим усередину, а не постаченим поруч.

Дія. Програма має 11 141 рядок Swift у п’ятдесяти трьох файлах у цілі застосунку, збудована на SwiftUI з ядром, вкомпонованим як статичний архів, зібраний із закріпленої висхідної ревізії. Закріплення ревізії, а не стеження за гілкою, є тим рішенням, що робить збирання відтворюваним: C‑інтерфейс є контрактом, і рухоме ядро змінює контракт, не змінюючи жодного рядка Swift. Шарування тримає небезпечну поверхню малою — тонка обгортка володіє кожним вказівником і кожним рядком, що перетинає межу, моделі над нею є звичайними значеннями Swift, а інтерфейсний шар ніколи не бачить сирого вказівника. Усе, що повертає C‑інтерфейс, має правило володіння, і помилитися в одному з них означає або витік, або аварію без жодного попередження компілятора між ними, тож саме в обгортці живе вся дисципліна пам’яті проєкту. Збиранням керує виконавець завдань із п’ятдесятьма шістьма цілями, що охоплюють компіляцію ядра, збирання Swift, набори тестів, лінтери та пакування.

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

Спинила застосунок, що наповнював пам'ять зі швидкістю 41 МБ за секунду — зафіксовані 111 ГБ стиснених сторінок на машині з 36 ГБ, — обмеживши кожен потік подій, підписуючись за типом події та поклавши бюджет швидкості на журналювання, що звело 610 996 рядків журналу до 1 411.

2026-10-09T14:31:15+02:00

Ситуація. Програма наповнювала пам’ять, доки операційна система її не вбивала. Зафіксований інцидент сягнув 111 ГБ стиснутих сторінок на машині з 36 ГБ, зростаючи приблизно на 41 МБ за секунду, а файл журналу за один короткий сеанс тримав 610 996 рядків. Машина в такому стані не повільна, вона непридатна — вбивство приходить після того, як підкачування вже змусило все інше на робочому столі перестати відповідати.

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

Дія. Причин‑множників було три, і саме множення пояснює, чому це відбувалося так швидко. Потік подій із ядра споживався без жодної межі, тож події надходили швидше, ніж інтерфейс міг їх застосувати, і доробок утримувався, а не відкидався. Кожен передплатник отримував кожну подію й фільтрував після цього, тож вартість однієї події множилася на кількість слухачів, і фільтрування кожного слухача виділяло пам’ять. А журналювання було небюджетованим, тож кожна подія породжувала рядки журналу — і це складений доданок, бо обсяг журналювання був пропорційним до обсягу того, що йшло не так. Виправлення взялося за всі три: обмежені буфери з явною політикою того, що стається за їх заповнення, передплата за типом події, тож слухача будять лише для подій, яких він хоче, і бюджет швидкості на журналювання, що згортає повтори, а не пише кожен. Регресійний тест жене високу швидкість подій і стверджує, що стеля пам’яті тримається, тож межа є властивістю збирання, а не коментарем.

Результат. Пам’ять лишається рівною під тривалим навантаженням, і той самий сеанс, що давав 610 996 рядків журналу, дає 1 411. Чесним зауваженням є те, що бюджет швидкості на журналювання відкидає інформацію: коли щось іде не так швидко, запис про це тепер навмисно неповний, і це обмін, зроблений свідомо проти альтернативи, якою є машина, що спиняється.

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

2026-10-09T14:31:15+02:00

Ситуація. Повна сувора перевірка паралельності у Swift 6 перетворює гонитви за даними на помилки компіляції замість переривчастих аварій. Впроваджувати її проти бібліотеки на C — саме там, де стає важко: цикл подій ядра є блокувальним викликом, що має вічно виконуватися поза головним потоком, а значення, які він повертає, є вказівниками без жодних гарантій щодо паралельності. Компілятор не може міркувати про це все й відхилятиме всі, доки межу не буде описано явно.

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

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

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

Написала парсер, який читає справжній C‑заголовок на 7 308 рядків і перевіряє кожне місце виклику, кожну константу переліку й те, що кожен клас‑власник вказівника є final, після того як рукописний заголовок‑заглушка дозволив викликам до трьох вилучених функцій скомпілюватися, злінкуватися й впасти.

2026-10-09T14:31:15+02:00

Ситуація. На початку проєкту C‑інтерфейс представляв рукописний заголовний файл, що описував функції, яких очікувала програма. Той заголовок компілювався, програма зв’язувалася, а виклики трьох функцій, яких у ядрі більше не існувало, доходили до моменту виклику й аварійно завершувалися. І компілятор, і компонувальник задовольнилися описом бібліотеки замість самої бібліотеки, а розрив виявився лише під час виконання.

Завдання. Справжній заголовок — 7 308 рядків і 268 оголошень — мав стати авторитетом, і кожне його використання в коді Swift треба було звіряти з ним автоматично, а не переглядом.

Дія. Перевіркою є розбирач, що читає справжній висхідний заголовок і будує множину функцій, констант переліку й типів, які той оголошує, а потім читає код Swift і розв’язує кожне місце виклику та кожне посилання на константу проти цієї множини. Виклик функції, якої заголовок не оголошує, валить збирання. Посилання на константу переліку, яку перейменували, валить збирання. Поточне число — 132 з 268 оголошень, на які є посилання, і знати, які 136 не використовуються, саме собою корисно, бо це каже точно, якої частини ядра клієнт не досяг. Розбирач також примусово застосовує правило, якого не може компілятор: кожен клас Swift, що володіє вказівником у ядро, має бути фінальним. Нефінальний клас, що володіє вказівником, можна успадкувати, а підклас, що перевизначає деініціалізацію або додає власний час життя, змінює момент звільнення вказівника — використання після звільнення без жодного небезпечного ключового слова поблизу. Правило перевіряють за іменем по всьому дереву.

Результат. Клас дефектів, що спричинив початкову аварію, не може повторитися, бо застаріле посилання тепер є відмовою збирання, а не відмовою під час виконання. Обмеженням є те, що розбирач розуміє оголошення заголовка, а не його семантику: він доводить, що функція існує з відповідним іменем, а функція, чиє значення чи правило володіння змінилося вище за течією зі збереженням сигнатури, проходить без зауважень.

Назвала кожен суто піктограмний елемент керування в інтерфейсі для зчитувачів екрана після того, як кнопка надсилання оголошувалася як «arrow up circle, button», і написала лінтер, що вимагає підпис у межах восьми рядків від піктограми.

2026-10-09T14:31:15+02:00

Ситуація. Інтерфейс використовував системні символи для своїх елементів керування, а символ без мітки доступності екранний читач озвучує його власним внутрішнім іменем. Кнопка надсилання оголошувалася як «стрілка вгору коло, кнопка». Так само робив кожен інший елемент керування лише з піктограмою в програмі, кожен по‑своєму — сімнадцять із них описували власний малюнок замість своєї функції.

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

Дія. Кожному із сімнадцяти надали мітку, що називає дію, а не форму, і там, де значення елемента залежить від стану, мітка йде за станом, а не є сталою. Перевірка є тією частиною, яку варто описати, бо загального правила «чи це доступно» для цього не існує. Лінтер шукає конструкцію, що створює елемент керування лише з піктограмою, і далі вимагає мітки доступності в межах восьми рядків від неї. Вісім рядків є навмисно грубою евристикою, і її обрано вимірюванням: вона достатньо довга, щоб охопити кожен законний спосіб, яким кодова база пише один із цих елементів разом із його модифікаторами, і достатньо коротка, щоб мітка, приєднана до іншого подання нижче, її випадково не задовольнила. Точне правило тут мало б розуміти ланцюжки модифікаторів SwiftUI як дерево, а дешеве правило близькості ловить справжню помилку — а це не хибно підписаний елемент, це непідписаний.

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

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

2026-10-09T14:31:15+02:00

Ситуація. Інтерфейс, збудований додаванням подань, накопичує значення: радіус заокруглення тут, шрифт у чотирнадцять пунктів там, анімація на дві десятих секунди десь іще. Кожне окремо є розумним, а разом вони є дизайном, якого не можна змінити, бо не існує такої речі, як «радіус заокруглення», щоб її змінити, — їх сорок, злегка різних, розсипаних по п’ятдесяти файлах.

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

Дія. Системою є сорок вісім токенів у шести групах: відступи, типографіка, колір, радіус, підняття та рух. Колір і матеріал збудовано на семантичних кольорах платформи та її скляному матеріалі, а не на сталих значеннях, і саме це змушує інтерфейс іти за системним виглядом, акцентним кольором і налаштуваннями контрасту без жодного коду, що за ними стежить. Типографіка відображається на текстові стилі платформи, тож вона масштабується з уподобою розміру в користувача замість прив’язки до пунктового значення. Лінтер відхиляє три речі: числовий літерал там, де належить токен відступу чи радіуса, жорстко заданий кегль будь‑де і анімацію, оголошену без шанування уподоби зменшеного руху. Третя є тією, що інакше руйнувалася б найшвидше, бо анімацію додають у мить наведення блиску, і саме перевірку уподоби пропускають — тож правило робить саму анімацію неможливою для написання без неї, а не просить когось пам’ятати.

Результат. Сорок вісім токенів описують увесь інтерфейс, вигляд іде за системою, і жодне з трьох руйнувань не можна закомітити. Межею є те, що система токенів обмежує узгодженість, а не якість, — тепер усе пасує одне до одного, а пасувати не те саме, що бути добре спроєктованим, і це судження не виносить жоден лінтер у цьому проєкті.

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

2026-10-09T14:31:15+02:00

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

Завдання. Недосяжну спроможність треба було задіяти й покрити, і тести мали виконуватися проти справжньої бібліотеки, а не проти заміщувача.

Дія. Прийнятим правилом було жодних імітацій для ядра. Імітація C‑інтерфейсу кодує переконання розробника про те, що робить бібліотека, а кожен вартий пошуку дефект тут є місцем, де це переконання хибне, — тож пройдений тест на імітації є свідченням про імітацію. Натомість тести створюють справжні облікові записи в тимчасових каталогах, ганяють справжню бібліотеку і стверджують про те, що вона насправді повертає, і кожен набір прибирає власний стан. Саме це зробило покриття змістовним: задіяти перенесення резервних копій означало обробити машину станів справжнього перенесення та її шляхи відмов, а задіяти перевірені запрошення означало сконструювати справжній формат посилання й дати бібліотеці його розібрати. Підлоги покриття задано на кожен шар окремо, а не одним числом: вісімдесят чотири відсотки для обгортки ядра, сімдесят п’ять для допоміжних функцій і шістдесят п’ять для моделей, з тим міркуванням, що шар, який торкається сирих вказівників, слід тримати найвище, а модель, яка здебільшого складається зі збережених властивостей, не варто набивати тестами заради середнього.

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

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

2026-10-09T14:31:15+02:00

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

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

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

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

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

2026-10-09T14:31:15+02:00

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

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

Дія. В основі згенерованого зображального матеріалу лежать два рукотворні малюнки — знак компанії та шестірня, що стала фавіконом, — і кожну піктограму, яку публікує сайт, вироблено з них. Знак є растровим малюнком; шестірня є вектором. З них скрипти виробляють кожну похідну форму: набір favicon у потрібних розмірах, дотикові піктограми, зображення для соціальних попереднів, адаптивні растрові варіанти в кожній ширині й у кожному сучасному форматі та версії для конкретних тем. Генерація є завданням, яке може виконати будь‑хто, тож питання «звідки взявся цей файл» має відповідь, що є командою. Перевірка застарілості є тим шматком, що тримає це разом: вона порівнює час зміни кожного похідного ресурсу з його джерелом і падає, коли похідний файл старіший, і це ловить саме ту відмову, задля запобігання якій цей задум існує, — хтось редагує джерело, забуває перегенерувати, і опублікований сайт далі показує графіку, що більше не відповідає оригіналові. Правило, що похідні файли ніколи не редагують вручну, зазначено там, де живуть джерела.

Результат. Два малюнки виробляють кожну опубліковану піктограму, перегенерація є однією командою, а застарілий ресурс валить збирання. Компромісом є жорстка залежність від набору інструментів: похідні файли закомічено, тож сайт збирається будь‑де, але зміна ідентичності вимагає, щоб генераційне знаряддя досі працювало, а вихідний формат, який перестане читатися, забере всю ідентичність із собою.

Опублікувала сайт як onion‑дзеркало в Tor на читабельній адресі, що починається з engineer, з ключем, згенерованим поза хостом, тож він ніколи не потрапив ні до цього репозиторію, ні на ноутбук, і лишила ці двері єдиними з чотирьох, які ніколи не рахують.

2026-10-09T14:31:15+02:00

Ситуація. Сайт уже відповідав на трьох протоколах з однієї збірки. Читач, якому треба було дістатися до нього, не виказуючи, що він дістався, усе ще робив гак через вихідний вузол до звичайної адреси, а це слабше за власні двері. Очевидне заперечення проти четвертих дверей – це фаєрвол, і воно не діє: демон анонімності виходить у мережу, будуючи вихідні ланцюги, тож ніхто не дзвонить усередину, жоден порт не відкривається, і жодному з двох шарів фаєрвола нема чого узгоджувати.

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

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

Результат. Сайт має четверо дверей до однієї збірки, і ці – єдині, яких ніколи не рахують. Запити Gemini та з’єднання Gopher підраховують щодня без адреси й без шляху; в onion немає лічильника й немає прапорця, щоб його додати, бо порахувати там читача – це саме те єдине, заради запобігання чому протокол існує, і сліпота тут ціна позиції, а не прогалина у звітності. Дзеркало окупилося ще й як друга думка: його перші читачі сиділи на іншому рушії браузера, який не реалізує керовану прокруткою анімацію, на яку спирався колофон, тож кожен із них отримав колофон, намальований поверх головної сторінки. Це був справжній дефект звичайного сайту, знайдений аудиторією, яка не мала іншого способу про нього повідомити.

Підкреслення, яке не обходило літери

2026-10-09T14:31:15+02:00

Наш власний сайт підкреслює кожне посилання й дозволяє браузеру вирізати проміжок там, де хвостик літери перетинає лінію, — g, p, кома. У Safari цього не відбувалося. Лінія йшла просто крізь них. І так було на англійських та данських сторінках відтоді, як сайт став багатомовним.

Причиною були три оголошення шрифту для абетки, яку ті сторінки ніколи не завантажують.

Що браузер має робити

text-decoration-skip-ink — це властивість, яка піднімає підкреслення над нижнім виносним елементом. Вона ввімкнена за замовчуванням, і роками відповіддю на «моє підкреслення має неправильний вигляд» було взятися за text-underline-offset і посунути лінію нижче. Це хибний рефлекс: зсув лінії змінює дизайн, а бракувало насправді саме проміжку.

Перш ніж дійти до цікавого, ми знайшли дві справжні причини, і обидві варті уваги.

Підкреслення завтовшки 1px отримує проміжок розміром 1px. Розрив, який вирізає рушій, пропорційний товщині лінії, що його вирізає. Наш стиль зафіксував товщину на одному пікселі, і це лишало близько 0,6px повітря з кожного боку штриха — технічно проміжок, візуально лінія просто крізь літеру. text-decoration-thickness: auto змасштабував обидві величини разом і збільшив проміжок з 3,5px до 12,4px, не зсунувши підкреслення ані на піксель.
from-font — не той безпечний варіант, яким здається. Він читає товщину, яку оголошує сам шрифт, а Ubuntu оголошує 0,056em для Light, 0,020em для Medium і 0,120em для Bold — родина, у якої лінія Medium важить менше за половину лінії Light. На великих розмірах це шестипіксельна лінія поряд із двопіксельною на одній сторінці.

Це виправило Chrome. Safari й далі вів лінію крізь усе.

Частина, яка забрала найбільше часу

Ми виміряли це як належить: запустити справжній Safari, перефарбувати підкреслення, зробити знімок екрана у восьмикратному масштабі й порахувати пікселі, де лінія уривається й починається знову.

	намальована товщина	проміжок навколо виносного елемента
Chrome	2,00px	5,8 / 12,5 / 6,3px
Safari	1,38px	1,8 / 1,0 / 1,0px

Отже, Safari таки вирізав проміжок. Просто вшестеро вужчий за Chrome, а в розмірі для читання проміжок в один піксель — це не проміжок. Гірше: звичний важіль лише погіршував справу. За товщини 3px Safari падав із трьох проміжків до одного, за 4px — до жодного, бо він не масштабує проміжок разом із лінією. Він фіксує його приблизно на 0,07em за будь-якого розміру, тоді як Chrome дає 0,6em.

Ми перебрали проти нього близько двадцяти оголошень — skip-ink: all, обидва застарілі написання властивості, кожну товщину від половини пікселя до чотирьох, text-underline-position, font-smoothing, text-rendering, paint-order. Ніщо не розширило проміжок. Чесний висновок на той момент був такий: WebKit просто обмежує проміжок, і зі стилів більше нічого не вдіяти.

Той висновок виявився хибним, а зламав його звіт про ваду проти шрифтового проєкту: Safari ігнорує skip-ink, коли шрифт завантажено з нелатинською підмножиною.

Справжня причина

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

Усі шість були оголошені під однією назвою родини — це найочевидніший спосіб це записати. І саме він є спусковим гачком, зафіксованим як вада WebKit 255159: коли одне накреслення в родині оголошує нелатинський діапазон символів, Safari погіршує skip-ink для кожного символу цієї родини — зокрема для латинського тексту на сторінці, яка ніколи не завантажує той інший файл.

Англійська сторінка малювала свої підкреслення погано, бо десь у стилях існувало українське оголошення шрифту. Коли ми видалили ті три рядки під час виконання й не змінили більше нічого, проміжки зросли з 1,8/1,0/1,0px до 4,5/11,0/5,0px.

Виправлення

Дайте другій системі письма власну назву родини й назвіть її у стеку шрифтів після першої:

@font-face {
    font-family: UbuntuCyrillic;   /* було: Ubuntu */
    src: url(ubuntu_300_cyrillic.woff2) format('woff2');
    unicode-range: U+0400-045F, U+0490-0491;
}

:root {
    --body-font: Ubuntu, UbuntuCyrillic, system-ui, sans-serif;
}

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

Три перейменовані оголошення й один запис у стеку. Проміжки в Safari зросли до 4,5/11,0/5,0px, Chrome лишився недоторканим, підкреслення не зрушило з місця, а українська й далі набирається в Ubuntu з тими самими ширинами.

Що ми сказали б наступному

Вимірювання skip-ink справедливе лише для того рушія, який його дав. Ми мали таблицю чисел, правильний діагноз і справжнє виправлення — і все це було Chromium. Знімок екрана, який відкрив справу наново, надійшов від людини, яка подивилася на сторінку.
Беріться за товщину раніше, ніж за зсув. Ширший проміжок зберігає дизайн; зсув лінії вниз його замінює.
Ділити шрифт за системами письма — правильно, але поділ має бути й у назві родини. Одна назва на кілька систем письма читається краще й коштує вам skip-ink у Safari. Злити їх назад має вигляд прибирання, а є регресом.
Завантаження ніколи не було проблемою. Будь-яка інтуїція підказує, що сторінка, яка малюється погано через кириличний шрифт, мусить завантажувати щось зайве. Вона не завантажувала. Досить було самого оголошення.

Джерела

Як відкрити dApp у мобільних гаманцях Solana

2026-10-09T14:31:15+02:00

React-dApp, побудований на @solana/wallet-adapter-react, без проблем під’єднує десктопні гаманці, але на телефоні той самий потік розсипається: гаманець має відкрити dApp у власному вбудованому браузері, а deeplinks, які мали б це зробити, просто мовчки не спрацьовують. Backpack виводить на сторінку «завантажте застосунок»; Solflare відкриває застосунок, але ніколи — сайт; здається, що не працює жоден варіант. Ми розібрали проблему на частини, і виявилося, що це чотири окремі проблеми з одним спільним симптомом.

Чотири проблеми

Посилання для Backpack було сформоване неправильно. Єдиний задокументований формат — https://backpack.app/ul/v1/browse/<url>?ref=<ref>: універсальне посилання із цільовим URL у шляху та обов’язковим ref. Здогадка з власною схемою на кшталт backpack://ul/v1/browse?url=... не збігається з жодним маршрутом, який реєструє застосунок, тож користувач опиняється на сторінці встановлення гаманця.
Solflare теж потребує свого універсального посилання: https://solflare.com/ul/v1/browse/<url>?ref=<ref>, а не голої схеми solflare://. Гола схема може запустити застосунок, не спрямувавши його — а це саме те, що «застосунок відкривається, але вкладку із сайтом доводиться відкривати вручну».
Обидва параметри мають бути закодовані. url — це повна абсолютна адреса dApp, а ref — origin, який робить запит; кожен проходить через encodeURIComponent. Незакодований ? або & у цілі псує розбір, і гаманець відкривається на своєму головному екрані замість вкладки браузера.
Спосіб запуску важить не менше за саме посилання. Універсальні посилання перемикають застосунки лише під час навігації, якій довіряє операційна система — і вони навмисно не роблять нічого, коли їх вставляють в адресний рядок, і саме так цілком коректне посилання «не працює» під час тестування.

Задокументовані формати

Phantom: https://phantom.app/ul/browse/<url>?ref=<ref> — саме тут без /v1.
Solflare: https://solflare.com/ul/v1/browse/<url>?ref=<ref>
Backpack: https://backpack.app/ul/v1/browse/<url>?ref=<ref>

Один шаблон покриває всі три:

const WALLET_BROWSE = {
  phantom: (url, ref) =>
    `https://phantom.app/ul/browse/${url}?ref=${ref}`,
  solflare: (url, ref) =>
    `https://solflare.com/ul/v1/browse/${url}?ref=${ref}`,
  backpack: (url, ref) =>
    `https://backpack.app/ul/v1/browse/${url}?ref=${ref}`,
};

function walletBrowseLink(
  walletName,
  targetUrl = window.location.href,
) {
  const build = WALLET_BROWSE[walletName.toLowerCase()];
  if (!build) return null;
  return build(
    encodeURIComponent(targetUrl),
    encodeURIComponent(window.location.origin),
  );
}

Як запустити посилання, щоб iOS та Android його прийняли

Рендерте справжній якір, обчислений заздалегідь. Звичайний <a href={walletBrowseLink('phantom')}> — найнадійніший спосіб запуску на обох платформах.
Якщо це має бути програмно, присвоюйте window.location.href синхронно всередині обробника натискання — без await, без fetch, без setTimeout перед цим. Після асинхронної роботи контекст жесту втрачено, і iOS відкочується до вебсайту гаманця. Ніколи не використовуйте window.open.
Ніколи не тестуйте вставлянням в адресний рядок. Універсальні посилання навмисно там не спрацьовують; тестуйте посиланням, на яке натискають, або QR-кодом, який сканує камера.
Зважайте на webview месенджерів. Відкриті у вбудованому браузері Telegram або Instagram, універсальні посилання часто просто поглинаються, і натомість завантажується звичайний вебсайт гаманця. Визначення за user-agent — у кращому разі евристика, тож дайте користувачам ще й видимий запасний вихід: «відкрийте в Safari чи Chrome, а тоді під’єднайтеся».

Ґрунтовніше виправлення на Android

Саморобні deeplinks — це історія про iOS. На Android Mobile Wallet Adapter від Solana Mobile дає dApp, що працює в мобільному браузері, під’єднатися прямо до встановленого застосунку гаманця, узагалі без гаку через вбудований браузер. Свіжі версії @solana/wallet-adapter-react реєструють мобільний адаптер автоматично, тож оновлення пакетів wallet-adapter може полагодити Android саме собою. Цільова архітектура: Mobile Wallet Adapter на Android, універсальні browse-посилання на iOS, де Apple не дозволяє нічого рівноцінного.

Перевірка на пристрої

Справжній пристрій, встановлений гаманець, посилання відкрито із системного браузера — не з месенджера.
Натисніть відрендерене посилання або відскануйте QR-код; ніколи не вставляйте в адресний рядок.
Переконайтеся, що гаманець відкривається і dApp завантажується у вкладці його вбудованого браузера — саме друга половина і ламається.
Повторіть без встановленого гаманця: універсальне посилання має деградувати до вебсайту гаманця. Якщо ця сторінка з’являється, коли застосунок встановлено, — посилання або спосіб запуску все ще неправильні.
Потім перевірте шлях через месенджер і додайте підказку «відкрийте у браузері», якщо там не спрацьовує.