Günlük Bir İzleme Listesini Otomatikleştirmek: Veriyi Çeken, Sinyalleri Hesaplayan ve Rapor Yazan Zamanlanmış Bir Betik ve API Anahtarı ile İstek Limiti Tuzakları

Neler öğreneceksiniz

• Not defteri hücrelerinin fonksiyonlar, bir main() giriş noktası ve bir yapılandırma dosyası içeren bir betiğe nasıl yeniden yapılandırılacağı.
• API anahtarlarının koddan nasıl uzak tutulacağı ve istek limitlerinin bekleme ve üstel geri çekilme (exponential back-off) ile nasıl yönetileceği.
• Sabah 07:30'da işe yarayan bir raporun nasıl yazılacağı: sıralanmış bir tablo, birkaç uyarı işareti ve bir zaman damgası.
• Betiğin cron veya Windows Görev Zamanlayıcı ile nasıl zamanlanacağı ve sessiz hataların fark edilmeden geçmemesi için neyin günlüğe kaydedilmesi gerektiği.

Açıklama

Not defteri keşif içindir; betik ise siz izlemeden aynı işi her gün tekrarlar. Göstergeler (6. ders) ve sinyal mantığı (7. ve 8. dersler) aynı kalır; etraflarındaki her şey değişir.

Betiğin yapısı

İşi, her biri tek bir görevi olan fonksiyonlara bölün: load_config(), fetch(ticker), compute_signals(df), build_report(rows) ve main(). if __name__ == '__main__': main() koruması, dosyayı çalıştırmanıza ve fonksiyonlarını testlere içe aktarmanıza da olanak tanır. İzleme listesini, parametreleri ve çıktı klasörünü config.yaml veya config.json içinde tutun; böylece kodu düzenlemeden değiştirilebilirler.

API anahtarları ve gizli bilgiler

Bir anahtarı asla kaynak koda veya paylaşabileceğiniz ya da Git'e ekleyebileceğiniz (commit) bir not defterine yazmayın. Anahtarı bir ortam değişkeninden veya .env dosyasından os.environ['DATA_API_KEY'] ile okuyun (python-dotenv paketi .env dosyasını yükler) ve .env dosyasını .gitignore içinde listeleyin. Anahtara bir parola gibi davranın ve sızarsa yenileyin.

İstek limitleri, yeniden denemeler ve geri çekilme

İstek limiti (rate limit), bir sağlayıcının dakika veya gün başına izin verdiği azami istek sayısıdır; aşılması bir HTTP 429 hatası döndürür ya da daha kötüsü, hata vermeden boş veri döndürür. Döngünün hızını time.sleep(60 / max_per_minute) ile ayarlayın. Geçici hatalar (429, 500, zaman aşımları) için üstel geri çekilme ile yeniden deneyin: 1 sn, 2 sn, 4 sn, 8 sn bekleyin, ardından vazgeçin ve sembolü eksik olarak günlüğe kaydedin. Asla sıkı bir döngü içinde yeniden denemeyin; anahtarlar bu şekilde engellenir.

• def fetch_with_retry(ticker, tries=4, base=1.0):
• for n in range(tries):
• try:
• return fetch(ticker)
• except TransientError as e:
• wait = base * 2 ** n
• log.warning('%s: %s, %.0f sn sonra yeniden denenecek', ticker, e, wait)
• time.sleep(wait)
• log.error('%s: vazgeçildi', ticker)
• return None

Ham indirmeleri önbelleğe alın (data/raw/TICKER_YYYY-MM-DD.parquet): aynı gün yapılan ikinci bir çalıştırma kota harcamak yerine dosyayı okur ve betiğin ne gördüğüne dair bir denetim izi tutmuş olursunuz.

Sinyallerden önce doğrulama

Veri, beklediğinizden daha sık bozuk gelir: eksik bir son çubuk, eskimiş bir tarih, 0'lık bir kapanış, düzeltilmemiş bir bölünme. Son tarihin beklenen işlem tarihine eşit olduğunu, son 20 satırda NaN bulunmadığını ve bugünün mutlak getirisinin 50 % gibi bir makullük eşiğinin altında olduğunu kontrol edin. Başarısız kontroller, hatalı bir fiyat kaydına dayanarak alım sinyali üretmek yerine raporun "veri sorunları" bölümüne gider.

Rapor

Çalıştırma zaman damgasını ve veri tarihini, sıralamanıza göre dizilmiş bir tabloyu (örneğin ATR birimleri cinsinden 50 günlük SMA'ya uzaklık), dünden bu yana oluşan yeni sinyalleri (bir önceki günün kaydedilmiş sinyal dosyasıyla karşılaştırılarak) ve veri sorunlarını içeren bir Markdown veya HTML dosyası yazın. Geçmişin korunması için dosyayı reports/watchlist_2026-10-30.md olarak kaydedin; işaretlenen her sembol için grafikler (10. ders) isteğe bağlıdır.

Zamanlama ve günlük kaydı

Linux ve macOS'ta cron komutları bir zaman çizelgesine göre çalıştırır: 30 6 * * 1-5 /path/venv/bin/python /path/watchlist.py >> /path/logs/cron.log 2>&1 hafta içi her gün 06:30'da çalışır; Windows'ta Görev Zamanlayıcı aynı işi bir iletişim kutusu üzerinden yapar. Sanal ortamın Python'unun tam yolunu kullanın (1. ders), çünkü zamanlayıcılar ortamları etkinleştirmez. logging modülüyle bir dosyaya günlük kaydı tutun: başlangıç, çekilen semboller, bulunan sinyaller, bitiş. Bugün için kayıt yoksa zamanlayıcı başarısız olmuştur. Bilgisayarlar uyku moduna geçer, ağlar kopar, uç noktalar (endpoint) değişir; kontrol etmediğiniz bir betik otomasyon değildir.

Çözümlü örnek

Varsayımsal örnek: 40 Avrupa ve ABD hissesinden oluşan bir izleme listesi; dakikada 5 ve günde 500 istek limiti olan ücretsiz bir veri planı (uydurma rakamlar; sağlayıcınızın güncel koşullarını kontrol edin).

1. Hız ayarı. Dakikada 5'ten 40 sembol = 40 / 5 = en az 8 dakika. Betik çağrılar arasında 12 saniye bekler. 06:30'da zamanlamak, verinin yaklaşık 06:40'ta hazır olması anlamına gelir.
2. Kota. Bir çalıştırma günlük 500 çağrının 40'ını kullanır (22 işlem günüyle ayda 880). Her 10 dakikada bir yeniden çalışan bir hata saatte 240 çağrı tüketir ve yaklaşık iki saatte sınıra ulaşır; disk önbelleği bu riski ortadan kaldırır.
3. Geri çekilme. İki sembol ilk denemede HTTP 429 döndürür. 1, 2 ve 4 saniye sonraki yeniden denemeler ikinci denemede başarılı olur; en kötü durumda eklenen süre sembol başına 1 + 2 + 4 + 8 = 15 saniyedir, dolayısıyla çalıştırma yine 10 dakikalık bütçe içinde tamamlanır.
4. Rapor. Kural: "kapanış, RSI(14) 60'ın altındayken 50 günlük SMA'yı yukarı keser". Dünkü dosyada 3 aktif sinyal vardı; bugünkü çalıştırma 5 sinyal buluyor ve bunların 2'si yeni. Rapor önce 2 yeni ismi, ardından devam eden 3 ismi listeliyor ve son çubuğu iki gün eski olduğu için 1 sembolü "veri sorunları" altında gösteriyor.

Kapsam dışı: bu örnek sinyalin kârlı olup olmadığı hakkında hiçbir şey söylemez; yalnızca günlük hazırlığı güvenilir ve tekrarlanabilir kılar.

Sık yapılan hata

Uygulama etkinliği

Kâğıt üzerinde: sağlayıcınız dakikada 30 ve günde 2,000 isteğe izin veriyor. 150 sembollük bir izleme listesini 06:00'da bir kez çalıştırmak ve 20 öncelikli sembolü 09:00 ile 17:30 (CET) arasında her 30 dakikada bir yenilemek istiyorsunuz. (a) Dakika başına limite uyan, çağrılar arasındaki asgari bekleme süresi nedir? (b) Tam bir gün kaç çağrı kullanır? Bu günlük kotanın içinde mi? (c) 06:00 çalıştırması 150 sembolün çekildiğini bildiriyor, ancak tüm sinyaller dünküyle aynı. Verinin güncel olup olmadığını size söyleyecek iki kontrolü belirtin.

Önemli çıkarımlar

• Betikler fonksiyonlara, bir yapılandırma dosyasına, bir main() korumasına ve günlük kaydına ihtiyaç duyar; not defterleri duymaz.
• Anahtarları ortam değişkenlerinde veya .env içinde tutun; istekleri limite göre ayarlayın ve üstel geri çekilmeyle yeniden deneyin, ardından vazgeçip günlüğe kaydedin.
• Sinyalleri hesaplamadan önce tarihleri ve satır sayılarını doğrulayın; ham indirmeleri önbelleğe alın.
• Sanal ortamın Python'unun tam yolunu kullanarak cron veya Görev Zamanlayıcı ile zamanlayın ve günlük kaydını her gün kontrol edin.

Sonraki adım

13. ders her şeyi veriden rapora kadar eksiksiz bir araştırma not defteri projesinde bir araya getiriyor ve bunu ileriye bakma yanlılığına ve aşırı uyuma karşı bir kontrol listesiyle gözden geçiriyor.