Online judge nasıl çalışır?

Bir değerlendirme sisteminin temel girdileri kaynak kod, programlama dili ve problem kimliğidir. Sistem önce kodu derler, ardından her test için programı çalıştırır. En basit toplam değerlendirme süresi şöyle düşünülebilir:

Programın herhangi bir testte süre sınırını aşması TLE, fazla bellek kullanması MLE, hatalı çıktı üretmesi ise WA sonucuna yol açar. Doğru sonuç yalnızca çıktının doğru olması değildir; programın belirlenen kaynak sınırları içinde çalışması da gerekir.

Gönderilen kod güvenilir kabul edilmez. Sonsuz döngüye girebilir, süreç oluşturmaya çalışabilir veya dosya sistemine erişmek isteyebilir. Bu nedenle judge sunucuları Linux kullanıcıları, cgroups, chroot, container veya benzeri izolasyon mekanizmalarından yararlanır. Kısacası değerlendirme sunucusu, yarışmacının koduna “Seni çalıştırırım ama evin anahtarını vermem” der.

Üç platformun karşılaştırması

DOMjudge: ICPC ruhunun temsilcisi

DOMjudge, takım yarışmaları ve klasik ICPC kuralları için oldukça uygundur. Yanlış gönderimler ceza süresine eklenir; problem çözüldüğünde süre hesabı kesinleşir. Basitleştirilmiş ceza modeli şöyledir:

Burada $T_{kabul}$ kabul dakikası, $W$ ise kabulden önceki yanlış gönderim sayısıdır. DOMjudge; yarışma yönetimi, canlı sıralama, hakem işlemleri ve ayrı judgehost makineleriyle ölçeklendirme konusunda güçlüdür. Üniversite kulübünde gerçekçi bir ICPC provası düzenlemek istiyorsanız genellikle ilk adaydır.

DMOJ: Esnek ve geliştirici dostu

DMOJ, sürekli açık problem arşivleri ve eğitim platformları için öne çıkar. Çok sayıda dili destekler; özel checker, interaktif problem ve kısmi puanlama gibi özellikler sunar. Django tabanlı web uygulaması ile değerlendirme düğümleri birbirinden ayrılabilir.

Bir problemin basit yapılandırması kavramsal olarak şöyle görünebilir:

archive: data.zip
time: 2
memory: 256
test_cases:
  - points: 20
    input: sample.in
    output: sample.out
  - points: 80
    batched:
      - input: secret.in
        output: secret.out

Bu yapı süreyi, bellek sınırını ve testlerin puan ağırlığını tanımlar. Gerçek sözdizimi sürüme ve problem paketine göre değişebilse de temel fikir aynıdır: değerlendirme davranışı kod yerine yapılandırmayla açıklanır.

CMS: Olimpiyat seviyesinde kontrol

Contest Management System, özellikle IOI biçimindeki yarışmalara yöneliktir. Alt görevler, geri bildirim düzeyleri, token sistemi ve ayrıntılı puanlama senaryolarında çok başarılıdır. Örneğin çözüm ilk alt görevden 20, ikinci alt görevden 30 puan alabilir; en zor grup başarısız olsa bile toplam puan korunur.

CMS güçlüdür ancak kurulumu ve işletimi diğer seçeneklere göre daha fazla sistem yönetimi bilgisi ister. Servislerin dağıtılması, worker makinelerinin hazırlanması ve yarışma verilerinin doğru modellenmesi dikkat gerektirir.

Hangisini seçmeli?

Tek günlük ICPC benzeri bir etkinlik için DOMjudge, okul veya topluluk tabanlı sürekli bir soru platformu için DMOJ, ulusal olimpiyat düzeyinde alt görevli yarışmalar için CMS daha doğal seçimdir. Platformdan bağımsız olarak yedekleme, HTTPS, kaynak izolasyonu ve yarışma öncesi yük testi ihmal edilmemelidir. Çünkü en zor algoritma sorusu bile çözülebilir; yarışma ortasında çöken judge sunucusu ise herkese aynı anda sistem tasarımı dersi verir.

Önce temel: OpenAPI nedir?

OpenAPI, REST tabanlı bir API’nin insanlar ve makineler tarafından okunabilen sözleşmesidir. Endpoint yolları, HTTP metotları, parametreler, veri modelleri, kimlik doğrulama yöntemleri ve olası yanıtlar YAML veya JSON biçiminde tanımlanır.

Bir API sözleşmesini kabaca şu fonksiyonla düşünebiliriz:

Burada $P$ yolları, $R$ istekleri, $M$ veri modellerini, $A$ kimlik doğrulamayı ve $E$ hata yanıtlarını temsil eder. Sözleşme ne kadar eksiksizse istemci üretimi, test otomasyonu ve geliştirici deneyimi o kadar başarılı olur.

Swagger UI ve Redoc bu sözleşmeyi görselleştirir. Docusaurus ise rehberler, eğitimler, sürüm notları ve kavramsal açıklamalar için genel bir dokümantasyon sitesi sunar.

Araçların karşılaştırması

Kısacası Swagger UI laboratuvar, Redoc düzenli bir ansiklopedi, Docusaurus ise bütün kampüstür.

Küçük bir OpenAPI sözleşmesi

Aşağıdaki dosya, kullanıcı bilgisini kimliğe göre döndüren bir endpoint tanımlar:

openapi: 3.0.3
info:
  title: Kullanıcı API
  version: 1.0.0
paths:
  /users/{id}:
    get:
      summary: Kimliğe göre kullanıcı getirir
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer
      responses:
        '200':
          description: Kullanıcı bulundu
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '404':
          description: Kullanıcı bulunamadı
components:
  schemas:
    User:
      type: object
      required: [id, name]
      properties:
        id:
          type: integer
        name:
          type: string

Bu tanım tek bir doğruluk kaynağıdır. Aynı dosya arayüz oluşturmak, sözleşme testi yapmak veya istemci SDK’sı üretmek için kullanılabilir.

Swagger UI ve Redoc’u çalıştırmak

En hızlı yöntem Docker kullanmaktır:

# Etkileşimli Swagger UI

docker run --rm -p 8080:8080 \
  -e SWAGGER_JSON=/spec/openapi.yaml \
  -v "$PWD:/spec" swaggerapi/swagger-ui

# Okuma odaklı Redoc

docker run --rm -p 8081:80 \
  -e SPEC_URL=openapi.yaml redocly/redoc

İlk komut API’yi localhost:8080 üzerinde deneyebilmenizi sağlar. İkinci komut aynı sözleşmeyi daha sade ve referans odaklı bir görünümle sunar. Gerçek projede dosyayı Redoc sunucusunun erişebileceği dizine kopyalamak veya bir URL üzerinden yayımlamak gerekir.

Docusaurus ile merkezi portal

Docusaurus projesinde kavramsal rehberleri Markdown ile tutabilir, API referansına menüden bağlantı verebilirsiniz:

// docusaurus.config.js
export default {
  themeConfig: {
    navbar: {
      items: [
        { to: '/docs/intro', label: 'Rehberler' },
        { href: '/api/redoc.html', label: 'API Referansı' },
        { href: '/swagger/', label: 'API’yi Dene' }
      ]
    }
  }
};

Bu yapı kullanıcıya üç katman sunar: “Neden kullanmalıyım?” sorusunu rehberler, “Hangi alanlar var?” sorusunu Redoc, “Bu istek gerçekten çalışıyor mu?” sorusunu Swagger UI cevaplar.

Sürdürülebilir iş akışı

OpenAPI dosyasını uygulama koduyla aynı depoda saklayın. CI sürecinde sözdizimini doğrulayın, kırıcı değişiklikleri karşılaştırın ve başarılı derlemeden sonra üç aracı da yayımlayın. Sürüm numarasını URL’ye eklemek, eski istemcilerin dokümantasyona erişmesini kolaylaştırır.

Ayrıca örneklerde gerçek erişim anahtarları kullanmayın. Swagger UI üzerindeki yetkilendirme alanlarını yalnızca güvenli test ortamlarına bağlayın. Böylece güzel görünen değil; güncel, test edilebilir ve güvenilir bir API dokümantasyon sistemi elde edersiniz.

``

API testi aslında neyi doğrular?

Bir istemci API’ye HTTP isteği gönderir; sunucu ise durum kodu, başlıklar ve gövde içeren bir yanıt üretir. Test aracının temel görevi bu alışverişi görünür ve tekrar edilebilir hâle getirmektir.

Örneğin bir kullanıcı endpoint’i için yalnızca 200 OK almak yeterli değildir. Yanıt gövdesindeki id alanının bulunması, içerik türünün JSON olması ve sürenin belirlenen sınırı aşmaması da kontrol edilmelidir.

Performansı basitçe şöyle değerlendirebiliriz:

Bir test 400 ms sürüyorsa bunun tamamı sunucunun işlem süresi değildir. Ağ gecikmesi ve yanıt boyutu da sonucu etkiler. Çoklu isteklerde ortalama süre ise

formülüyle hesaplanabilir. Bu nedenle tek bir hızlı yanıt görüp zafer dansına başlamak yerine testi birkaç kez çalıştırmak daha sağlıklıdır.

Üç aracın karakteri

Hoppscotch: Tarayıcıyı aç ve isteği gönder

Hoppscotch, kurulumla uğraşmadan REST, GraphQL ve WebSocket istekleri denemek isteyenler için idealdir. Arayüzü hafiftir; URL’yi, metodu ve gerekli başlıkları girerek saniyeler içinde sonuç alabilirsiniz. Özellikle eğitimlerde, hata ayıklamada ve geçici kontrollerde parıldar.

Ancak hassas token’larla çalışırken ekip politikalarını ve verinin nerede saklandığını incelemek gerekir. Tarayıcı kolaylığı, güvenlik değerlendirmesini ortadan kaldırmaz.

Bruno: Koleksiyonlar da kod gibi yaşasın

Bruno, koleksiyonları düz metin dosyalarında saklayarak Git üzerinden sürümlemeyi kolaylaştırır. Böylece API değişiklikleri pull request içinde görülebilir; “Bu header’ı kim değiştirdi?” sorusu polisiye romana dönüşmez.

Örnek bir Bruno isteği şöyle görünebilir:

meta {
  name: Kullanıcı Getir
  type: http
  seq: 1
}

get {
  url: {{baseUrl}}/users/42
  body: none
  auth: bearer
}

assert {
  res.status: eq 200
  res.body.id: eq 42
}

Bu dosya isteğin adresini tanımlar ve yanıtın durum koduyla kullanıcı kimliğini doğrular. CLI desteği sayesinde aynı koleksiyon CI/CD hattında da çalıştırılabilir.

Insomnia: Düzenli ve kapsamlı çalışma masası

Insomnia; ortam değişkenleri, kimlik doğrulama yöntemleri, GraphQL desteği ve koleksiyon organizasyonuyla kapsamlı projelerde rahat bir deneyim sunar. Çok sayıda servisi olan ekipler için klasörlü yapı ve yeniden kullanılabilir değişkenler önemlidir.

Örneğin geliştirme ve üretim adreslerini ayrı ayrı yazmak yerine şu mantık kullanılabilir:

{
  "base_url": "https://api.example.com",
  "token": "{{ secret_token }}"
}

Böylece isteklerde `` kullanılır ve ortam değiştirirken her endpoint’i elle düzenlemek gerekmez. Token değerlerini repoya eklememek ise temel güvenlik kuralıdır.

Hangisini seçmelisiniz?

Hızlı, kurulumsuz denemeler için Hoppscotch; koleksiyonları Git ile yönetmek ve testleri pipeline’a taşımak için Bruno; kapsamlı masaüstü deneyimi ve düzenli proje yönetimi için Insomnia öne çıkar. En iyi araç, en fazla düğmeye sahip olan değil, ekibinizin testleri düzenli çalıştırmasını sağlayandır. Küçük bir örnek API’yi üçünde de deneyin; ardından hız, paylaşım, güvenlik ve otomasyon ihtiyaçlarınıza göre karar verin.

Yer imi sistemi aslında ne yapar?

İyi bir bookmark sistemi yalnızca URL depolamaz. Bir bağlantıyı; başlık, açıklama, etiket, eklenme tarihi ve arşivlenmiş içerikle birlikte saklar. Teorik olarak her kaydı şu kümeyle gösterebiliriz:

Burada $u$ adresi, $t$ başlığı, $d$ açıklamayı, $E$ etiketler kümesini, $z$ eklenme zamanını ve $a$ arşiv kopyasını temsil eder. Etiketleme sayesinde arama alanı küçülür. Toplam $N$ bağlantının yalnızca belirli bir etikete ait $k$ tanesini incelemek, zihinsel yükü kabaca $N$ öğeden $k$ öğeye indirir.

Örneğin python, veritabanı ve okunacak etiketlerinin kesişimi şöyle düşünülebilir:

Bu yaklaşım klasörlerden daha esnektir; çünkü aynı bağlantı birden fazla bağlama ait olabilir.

Üç aracın karakteri

Linkwarden

Linkwarden, bağlantı çürümesine karşı en güçlü seçenektir. Bir web sayfası silinse bile ekran görüntüsü veya PDF benzeri arşivleri koruyabilir. Koleksiyon paylaşımı ve kullanıcı yönetimi sayesinde ekipler için de uygundur. Bunun bedeli daha fazla RAM, depolama ve kurulum bileşenidir.

Linkding

Linkding, “yer imimi ekleyeyim ve hemen bulayım” yaklaşımını benimser. Arayüzü dikkat dağıtmaz; etiketleme, arama, içe aktarma ve tarayıcı eklentileri günlük kullanımda oldukça yeterlidir. SQLite kullanması yedeklemeyi de kolaylaştırır: Çoğu durumda veritabanı dosyasını güvenli biçimde kopyalamak yeterlidir.

Shaarli

Shaarli, eski bir dizüstünü sunucuya dönüştürenlerin kahramanıdır. PHP çalıştırabilen mütevazı bir sunucuda yaşayabilir ve veritabanı sunucusu gerektirmez. Arayüzü rakipleri kadar modern değildir; fakat taşınabilirlik ve sadelik konusunda oldukça güçlüdür.

Docker ile Linkding kurulumu

Aşağıdaki compose.yaml, Linkding servisini başlatır ve verileri kalıcı bir klasörde tutar:

services:
  linkding:
    image: sissbruecker/linkding:latest
    container_name: linkding
    ports:
      - "9090:9090"
    volumes:
      - ./data:/etc/linkding/data
    environment:
      - LD_SUPERUSER_NAME=admin
      - LD_SUPERUSER_PASSWORD=guclu-bir-parola
    restart: unless-stopped

Dosyanın bulunduğu dizinde şu komutu çalıştır:

docker compose up -d

Ardından http://sunucu-adresi:9090 üzerinden giriş yapabilirsin. volumes bölümü, konteyner silinse bile kayıtların data klasöründe kalmasını sağlar. Gerçek kullanımda güçlü parola, HTTPS ve düzenli yedekleme şarttır; yönetim panelini doğrudan internete açmak iyi bir macera türü değildir.

Hangisini seçmelisin?

Kalıcı web arşivi ve ekip paylaşımı istiyorsan Linkwarden, hızlı ve dengeli bir kişisel sistem arıyorsan Linkding, en düşük kaynak tüketimiyle bağımsızlık hedefliyorsan Shaarli seç. En iyi araç, yüzlerce özelliği olan değil, yeni bağlantı eklemeyi erteletmeyecek kadar rahat olandır. Sistemi seçtikten sonra az sayıda tutarlı etiket belirle, tarayıcıdaki eski yer imlerini içe aktar ve otomatik yedekleme kur. Dijital çekmecen sonunda gerçekten düzenli kalabilir.

Sağlam bir yedekleme sisteminin mantığı

Yedekleme, dosyaları başka bir klasöre kopyalamaktan ibaret değildir. Güvenilir bir plan için yaygın 3-2-1 kuralı uygulanabilir:

• Verinin en az 3 kopyası bulunmalı.
• Kopyalar 2 farklı ortamda tutulmalı.
• Kopyalardan 1 tanesi uzak konumda olmalı.

Depolama ihtiyacını azaltmak için üç araç da artımlı yedekleme yaklaşımından yararlanır. İlk çalıştırmada tüm veri saklanırken sonraki çalıştırmalarda yalnızca değişiklikler gönderilir. Basitleştirilmiş depolama hesabı şöyledir:

Burada $F$ ilk tam yedeğin boyutunu, $\Delta_i$ ise her çalıştırmada değişen veri miktarını temsil eder. Tekilleştirme sayesinde aynı veri bloklarının tekrar saklanması önlenebilir. Örneğin 10 GB’lık bir dosyanın yalnızca küçük bir bölümü değiştiğinde yeniden 10 GB göndermek gerekmez.

Üç aracın karşılaştırması

Duplicati, tarayıcıdan yönetilen arayüzü sayesinde zamanlama, hedef seçimi ve geri yükleme işlemlerini kolaylaştırır. Google Drive, OneDrive ve S3 gibi hedeflere doğrudan bağlanabilmesi önemli bir avantajdır. Buna karşılık büyük yedek kümelerinde veritabanı bakımı gerekebilir.

BorgBackup, içerik tanımlı parçalama ve güçlü tekilleştirme özellikleriyle özellikle Linux sunucularında parlar. Depoların SSH üzerinden kullanılabilmesi güvenli ve hızlı bir yapı sunar. Ancak grafik arayüz bekleyen kullanıcılar için biraz fazla terminal kokabilir.

Restic ise sade komutları, tek dosyalık kurulumu ve platformlar arası desteğiyle öne çıkar. Şifreleme varsayılan tasarımın parçasıdır; yedek deposu ele geçirilse bile parola olmadan içerik okunamaz.

BorgBackup ile örnek yedekleme

Önce şifreli bir depo oluşturulur, ardından proje dizini arşivlenir:

borg init --encryption=repokey-blake2 /mnt/backup/borg-repo
borg create --stats /mnt/backup/borg-repo::proje-{now} ~/projeler

İlk komut şifreli depoyu hazırlar. İkinci komut, tarih bilgisini taşıyan yeni bir anlık görüntü oluşturur. Eski yedekleri kontrollü biçimde temizlemek için şu politika uygulanabilir:

borg prune --list /mnt/backup/borg-repo \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6

Bu komut son yedi günlük, dört haftalık ve altı aylık yedeği korur.

Restic ile uzak hedef kullanımı

Restic deposu SFTP üzerinde hazırlanabilir:

export RESTIC_REPOSITORY=sftp:user@sunucu:/yedekler/restic
restic init
restic backup ~/Belgeler ~/Fotoğraflar
restic check

backup verileri şifreleyerek gönderirken check, depo bütünlüğünü denetler. Parola otomasyon sırasında açıkça yazılmamalı; izinleri sınırlandırılmış bir parola dosyası veya güvenli sır yönetim sistemi kullanılmalıdır.

Hangisini seçmeli?

Masaüstünde kolay yönetim ve bulut bağlantıları için Duplicati, Linux sunucusunda yüksek verimlilik için BorgBackup, farklı sistemlerde sade ve güvenli kullanım için Restic güçlü adaydır. Hangi araç seçilirse seçilsin, yalnızca yedek almak yeterli değildir. Düzenli geri yükleme testi yapılmayan bir yedek, açılana kadar Schrödinger’in yedeğidir: Hem vardır hem yoktur!

``

Temel fikir: Proof of Work

Bu sistemlerin merkezinde iş ispatı veya benzeri görünmez doğrulama mekanizmaları bulunur. Sunucu, istemciye çözülmesi ölçülü miktarda işlem gerektiren bir problem verir. Tarayıcı çözümü bulur; sunucu ise sonucu çok daha düşük maliyetle doğrular.

Basitleştirilmiş bir problem şöyle düşünülebilir:

Burada $H$ bir özet fonksiyonu, $n$ tarayıcının aradığı sayı ve $T$ zorluk eşiğidir. Eşik küçüldükçe uygun sayı bulmak zorlaşır. Ortalama hesaplama maliyeti yaklaşık olarak:

şeklinde yorumlanabilir. Meşru bir kullanıcı için birkaç yüz milisaniyelik iş önemsizdir; milyonlarca sahte istek gönderen bot açısından aynı maliyet çarpılarak büyür. Yine de bu yöntem botları sihirli biçimde yok etmez, yalnızca saldırının ekonomisini bozar.

Üç çözümün karşılaştırması

ALTCHA, sade protokolü ve self-hosting seçeneğiyle uygulama mimarisine kolayca yerleşir. Friendly Captcha, operasyon yükünü azaltmak isteyen ekipler için yönetilen hizmet deneyimine odaklanır. mCaptcha ise açık kaynaklı, bağımsız ve uyarlanabilir bir CAPTCHA altyapısı kurmak isteyenler açısından dikkat çekicidir.

ALTCHA ile örnek sunucu akışı

Aşağıdaki Express örneği bir challenge üretir ve tarayıcıdan gelen çözümü doğrular:

import express from "express";
import { createChallenge, verifySolution } from "altcha-lib";

const app = express();
app.use(express.json());

const hmacKey = process.env.ALTCHA_HMAC_KEY;

app.get("/captcha/challenge", async (req, res) => {
  const challenge = await createChallenge({
    hmacKey,
    maxNumber: 100000
  });

  res.json(challenge);
});

app.post("/contact", async (req, res) => {
  const valid = await verifySolution(req.body.altcha, hmacKey);

  if (!valid) {
    return res.status(400).json({ error: "CAPTCHA doğrulanamadı" });
  }

  res.json({ success: true });
});

app.listen(3000);

maxNumber, istemcinin yapabileceği maksimum arama miktarını sınırlar. HMAC anahtarı challenge’ın sunucu tarafından üretildiğini kanıtlar; bu anahtar istemciye kesinlikle gönderilmemelidir. Kullanılan kütüphane sürümüne göre fonksiyon imzalarının kontrol edilmesi de önemlidir.

Hangisini seçmeli?

Hızlı entegrasyon ve yönetilen altyapı istiyorsanız Friendly Captcha pratik olabilir. Veriyi, anahtarları ve doğrulama sürecini kendi sisteminizde tutmak istiyorsanız ALTCHA daha hafif bir seçenek sunar. Tamamen açık kaynak bir CAPTCHA servisini bağımsız çalıştırmak ve iş yükünü dinamik ayarlamak istiyorsanız mCaptcha güçlü bir adaydır.

Hiçbiri tek başına yeterli savunma değildir. CAPTCHA’yı rate limiting, IP ve hesap bazlı kota, tekrar saldırısı engelleme, kısa challenge süresi ve davranışsal sinyallerle destekleyin. Mobil cihazlarda aşırı zorluk pil tüketebilir; çok düşük zorluk ise bot maliyetini artırmaz. En iyi ayar, güvenlik ile gerçek kullanıcıların bekleme süresi arasındaki dengedir.

``

Hata takip sistemi nasıl çalışır?

Uygulamaya eklenen SDK, yakalanmamış bir istisna oluştuğunda bir hata olayı üretir. Bu olay genellikle hata mesajını, stack trace bilgisini, sürümü, çalışma ortamını ve isteğe bağlı kullanıcı bağlamını içerir. Veriler bir DSN adresi üzerinden sunucuya gönderilir.

Sistem, benzer olayları tek bir sorun altında gruplandırmaya çalışır. Böylece aynı NullReferenceException hatası bin kez oluştuğunda panelde bin bağımsız kayıt yerine, gerçekleşme sayacı yükselen tek bir sorun görürüz.

Belirli sürede oluşan olay sayısını $E$, süreyi dakika cinsinden $t$ kabul edersek hata yoğunluğu şöyle ifade edilebilir:

Örneğin 10 dakikada 500 olay alınması, $R = 50$ olay/dakika anlamına gelir. Ancak yüksek sayı her zaman daha kritik hata demek değildir. Etkilenen kullanıcı sayısı, hata oranı ve işlemin önemi birlikte değerlendirilmelidir.

Üç aracın kısa karşılaştırması

Sentry, hata takibinin yanında performans izleme, dağıtık tracing, sürüm takibi ve oturum tekrarı gibi geniş özellikler sunar. Yönetilen bulut hizmeti operasyon yükünü azaltır; fakat yoğun trafik, veri kotası ve gizlilik gereksinimleri dikkatle değerlendirilmelidir.

GlitchTip, Sentry SDK’larıyla uyumlu açık kaynaklı bir deneyim sağlamayı amaçlar. Arayüzü daha sade, self-hosted kurulumu ise genellikle daha ulaşılabilirdir. Sentry’nin bütün ileri analiz özelliklerini beklemeyen ekipler için güçlü bir dengedir.

Bugsink, “önce hatayı yakalayalım” yaklaşımına yakındır. Daha az bileşenle çalışması, küçük sunucularda yönetimi kolaylaştırabilir. Kapsamlı observability platformu yerine anlaşılır bir hata kutusu isteyen projelere uygundur.

Python uygulamasına SDK eklemek

Üç ürün de Sentry protokolüyle uyumlu kurulum senaryoları sunabildiğinden Python tarafında çoğunlukla resmi SDK kullanılabilir:

import sentry_sdk

sentry_sdk.init(
    dsn="https://anahtar@hata-sunucusu.example/1",
    environment="production",
    release="magaza-api@2.4.0",
    traces_sample_rate=0.1,
)

def fiyat_hesapla(toplam, adet):
    return toplam / adet

fiyat_hesapla(250, 0)

Bu kodda DSN, olayların gideceği projeyi belirtir. environment üretim ve test kayıtlarını ayırır; release ise hatanın hangi sürümde başladığını bulmayı kolaylaştırır. traces_sample_rate=0.1, performans işlemlerinin yaklaşık yüzde 10’unu örnekler. Ürün ve sürüme göre desteklenen SDK özellikleri değişebileceğinden uyumluluk belgeleri kontrol edilmelidir.

Hangisini seçmeli?

Hazır servis, gelişmiş analiz ve minimum bakım istiyorsanız Sentry mantıklı başlangıçtır. Veriyi kendi altyapınızda tutmak, açık kaynak kullanmak ve daha ölçülü kaynak tüketmek istiyorsanız GlitchTip değerlendirilebilir. Yalnızca temel hata toplama, gruplama ve bildirim özelliklerine ihtiyacınız varsa Bugsink sadeliğiyle öne çıkar.

Seçimden önce günlük olay hacmini, saklama süresini ve örnekleme oranını hesaplayın. Ayrıca parola, erişim belirteci ve kişisel veri gibi hassas bilgileri SDK filtreleriyle temizleyin. Çünkü iyi bir hata takip sistemi yalnızca çok veri toplayan değil, doğru veriyi güvenli biçimde anlamlı hale getiren sistemdir.

Bir güvenlik araştırmacısı kritik bir açık bulduğunda kime, nasıl ve hangi kanıtlarla ulaşacağını bilmelidir. Open Bug Bounty veya HackerOne benzeri özel bir sistem; araştırmacıları, güvenlik ekiplerini ve ürün sahiplerini aynı iş akışında buluşturur. Fakat bu proje, sıradan bir destek talebi uygulamasından daha fazlasıdır: hassas verileri korumalı, mükerrer raporları yakalamalı ve kontrollü açıklama sürecini yönetmelidir. ``

Temel iş akışı

Bir raporun yaşam döngüsü durum makinesi olarak modellenebilir:

Taslak → Gönderildi → İnceleniyor → Doğrulandı → Çözüldü → Açıklandı

Rapor geçersizse Reddedildi, daha önce bildirilmişse Mükerrer durumuna taşınır. Durum makinesi kullanmak, örneğin çözülmüş bir raporun yanlışlıkla yeniden “gönderildi” yapılmasını engeller.

Bu ayrım, en az ayrıcalık ilkesi üzerine kurulmalıdır. Yalnızca giriş yapmış olmak yeterli değildir; her API isteğinde rol, kaynak sahipliği ve program üyeliği ayrıca denetlenmelidir.

Önem derecesi ve ödül hesabı

Açıkların önceliği CVSS gibi standartlarla belirlenebilir. Daha sade bir özel puanlama için şu model kullanılabilir:

Her değişken 1 ile 5 arasında seçilirse en yüksek risk puanı $5^3 = 125$ olur. Ödül ise taban tutar ve risk oranıyla hesaplanabilir:

Ancak otomatik sonuç yalnızca öneri olmalıdır. Kaliteli açıklama, çalışan kavram kanıtı ve daha önce raporlanmış olma durumu nihai kararı değiştirebilir.

Veri modeli ve güvenlik

Temel tablolar users, programs, assets, reports, comments, attachments, rewards ve audit_logs olabilir. Rapor; başlık, etkilenen varlık, açıklık türü, tekrar üretme adımları, etki açıklaması ve çözüm önerisi içermelidir.

Kanıt dosyaları doğrudan herkese açık klasörlere konulmamalıdır. Nesne depolamada şifrelenmeli, kısa ömürlü imzalı bağlantılarla sunulmalı ve zararlı dosya taramasından geçirilmelidir. Parolalar Argon2id ile özetlenmeli; oturumlarda çok faktörlü kimlik doğrulama desteklenmelidir. Audit log kayıtları da “kim, neyi, ne zaman değiştirdi?” sorusunu yanıtlamalıdır.

Güvenli durum geçişi örneği

Aşağıdaki FastAPI kodu, istemcinin istediği her duruma serbestçe geçmesini engeller:

from enum import Enum
from fastapi import FastAPI, HTTPException

app = FastAPI()

class Status(str, Enum):
    submitted = "submitted"
    triage = "triage"
    confirmed = "confirmed"
    resolved = "resolved"
    rejected = "rejected"

ALLOWED = {
    Status.submitted: {Status.triage, Status.rejected},
    Status.triage: {Status.confirmed, Status.rejected},
    Status.confirmed: {Status.resolved},
    Status.resolved: set(),
    Status.rejected: set()
}

@app.post("/reports/{report_id}/transition")
def transition(report_id: int, current: Status, target: Status):
    if target not in ALLOWED[current]:
        raise HTTPException(409, "Geçersiz durum geçişi")

    # Burada rol kontrolü ve veritabanı güncellemesi yapılır.
    return {"report_id": report_id, "status": target}

Gerçek uygulamada current değeri kullanıcıdan alınmamalı, veritabanından okunmalıdır. Güncelleme atomik bir işlem içinde yapılmalı ve audit log kaydı aynı işlemde oluşturulmalıdır.

Sistemi olgunlaştıran özellikler

Mükerrer rapor tespiti için başlık benzerliği, açıklık türü ve etkilenen varlık birlikte değerlendirilebilir; ancak gizlilik nedeniyle araştırmacıya başka raporun ayrıntıları gösterilmemelidir. Bildirimler e-posta ve uygulama içi kanallardan iletilebilir. Oran sınırlama, CAPTCHA ve kötüye kullanım tespiti de spam saldırılarını azaltır.

Son olarak açık bir kapsam politikası hazırlayın: test edilebilen alan adları, yasak yöntemler, hizmet kesintisi kuralları, yanıt süreleri ve güvenli liman şartları net olsun. İyi bir bug bounty platformunun asıl süper gücü yalnızca kodu değil, araştırmacıyla kurulan güveni de korumasıdır.

RSS okuyucu nasıl çalışır?

RSS, bir internet sitesinin güncel içeriklerini XML biçiminde yayımlamasını sağlayan standarttır. Akış içerisinde genellikle başlık, bağlantı, yayın tarihi, yazar ve içerik özeti bulunur. Okuyucu uygulama belirli aralıklarla bu XML belgesini indirir, daha önce görmediği kayıtları veritabanına ekler ve kullanıcıya okunabilir bir arayüz sunar.

Bir RSS sisteminin yaklaşık günlük istek sayısını şöyle düşünebiliriz:

Burada $N$ takip edilen akış sayısını, $T$ dakika cinsinden yenileme aralığını temsil eder. Örneğin 100 akışı 30 dakikada bir kontrol etmek teorik olarak günde $100 \times 48 = 4800$ HTTP isteği oluşturur. Bu nedenle çok sık güncelleme yapmak her zaman daha iyi değildir; hem sunucunuzu hem de içerik sağlayıcıları gereksiz yere yorabilir.

Üç okuyucunun karakteri

FreshRSS

FreshRSS, dengeli bir çözüm arayanlar için güvenli tercihtir. Birden fazla veritabanını destekler, tema ve eklentilerle kişiselleştirilebilir. Klasörler, etiketler, filtreler ve çoklu kullanıcı desteği bakımından zengindir. Arayüzü ilk bakışta biraz klasik görünse de çok sayıda akışı yönetirken oldukça pratiktir.

Miniflux

Miniflux, “az özellik, temiz deneyim” felsefesini benimser. Go ile geliştirildiği için hızlı çalışır ve düşük kaynak tüketir. Klavye kısayolları, sade okuma görünümü ve içerik temizleme yetenekleri başarılıdır. Ancak PostgreSQL zorunluluğu, yalnızca küçük bir SQLite dosyasıyla ilerlemek isteyen kullanıcılar için fazladan operasyon demektir.

Tiny Tiny RSS

Tiny Tiny RSS, kısaca TT-RSS, ayrıntılı filtreleme ve eklenti seçenekleri isteyen deneyimli kullanıcılara hitap eder. Makaleleri kurallara göre etiketlemek, puanlamak veya işlemek mümkündür. Buna karşılık kurulumu ve bakımı diğer iki seçeneğe göre daha fazla dikkat ister. Güçlüdür; fakat kontrol panelindeki düğmelerle dostluk kurmanız biraz zaman alabilir.

Docker ile örnek FreshRSS kurulumu

Aşağıdaki compose.yaml dosyası FreshRSS’i kalıcı veri alanı ve otomatik yeniden başlatma politikasıyla çalıştırır:

services:
  freshrss:
    image: freshrss/freshrss:latest
    container_name: freshrss
    ports:
      - 8080:80
    volumes:
      - freshrss_data:/var/www/FreshRSS/data
      - freshrss_extensions:/var/www/FreshRSS/extensions
    environment:
      TZ: Europe/Istanbul
      CRON_MIN: '*/20'
    restart: unless-stopped

volumes:
  freshrss_data:
  freshrss_extensions:

CRON_MIN değeri akışların 20 dakikada bir yenilenmesini sağlar. Servisi başlatmak için dosyanın bulunduğu dizinde şu komut yeterlidir:

docker compose up -d

Ardından http://sunucu-adresi:8080 adresini açarak kurulum sihirbazını tamamlayabilirsiniz. İnternet üzerinden erişim verecekseniz ters proxy, HTTPS ve düzenli yedekleme kullanmayı unutmayın.

Hangisini seçmelisiniz?

Hızlı karar formülü basit: Esneklik ve kolay kurulum istiyorsanız FreshRSS, dikkat dağıtmayan hafif bir sistem arıyorsanız Miniflux, ayrıntılı kurallar ve eklentiler sizin için vazgeçilmezse Tiny Tiny RSS seçin. Kararsız kalan çoğu kullanıcı için FreshRSS iyi bir başlangıç noktasıdır; minimalistlerin gönlünü ise büyük olasılıkla Miniflux çalacaktır.

``

RSS nasıl çalışır?

RSS yayını, çoğunlukla XML biçiminde sunulan ve içerik kayıtlarını belirli kurallarla sıralayan bir belgedir. Bir RSS okuyucu, yayının URL’sini düzenli aralıklarla sorgular; yeni bir guid veya daha güncel bir tarih gördüğünde kaydı kullanıcıya gösterir.

Basitleştirilmiş bir RSS belgesi şöyledir:

<rss version="2.0">
  <channel>
    <title>Teknoloji Günlüğü</title>
    <link>https://ornek.com</link>
    <item>
      <title>Yeni Yazı</title>
      <link>https://ornek.com/yeni-yazi</link>
      <guid>yazi-42</guid>
    </item>
  </channel>
</rss>

Sorgulama aralığı $T$, günlük istek sayısı ise yaklaşık $N$ olsun. Tek bir okuyucu için yük şu şekilde düşünülebilir:

Örneğin her 30 dakikada bir kontrol yapıldığında $T=1800$ olur ve günde yaklaşık 48 istek gönderilir. Çok sık sorgulamak güncelliği artırır; ancak sunucu yükünü de büyütür. Önbellekleme bu dengenin gizli kahramanıdır.

Üç yaklaşımın karşılaştırması

WordPress RSS akışını kullanmak

WordPress çoğu kurulumda RSS üretimini otomatik yapar. Ana yayın genellikle aşağıdaki adrestedir:

https://siteadresi.com/feed/

Kategoriye özel yayın için /category/yazilim/feed/, yorumlar için /comments/feed/ kullanılabilir. functions.php veya SEO eklentileriyle özet, görsel ve özel alanlar akışa eklenebilir. Ancak çekirdek dosyaları düzenlemek yerine çocuk tema ya da özel eklenti kullanmak güncellemelerde yaşanacak sürprizleri önler.

Python Feedgen ile özel yayın

Veriler bir API’den, veritabanından veya küçük bir otomasyon betiğinden geliyorsa Feedgen oldukça kullanışlıdır:

from feedgen.feed import FeedGenerator

feed = FeedGenerator()
feed.title("Haftalık Python Notları")
feed.link(href="https://ornek.com", rel="alternate")
feed.description("Otomatik oluşturulan yazılım notları")

entry = feed.add_entry()
entry.id("python-101")
entry.title("Generator Mantığı")
entry.link(href="https://ornek.com/generator")
entry.description("Bellek dostu yineleyicilere giriş.")

feed.rss_file("rss.xml")

Bu kod bir kanal oluşturur, kanala tek bir kayıt ekler ve sonucu rss.xml dosyasına yazar. Üretim ortamında her kayda benzersiz kimlik, yayın tarihi ve kalıcı bağlantı eklemek gerekir. Betiği cron ile periyodik çalıştırarak tamamen otomatik bir yayın hattı kurulabilir.

RSSHub ile akışı olmayan kaynaklar

RSSHub, desteklediği platformları “rota” adı verilen adreslerle RSS’e dönüştürür. Docker ile yerel kurulum yapılabilir:

docker run -d --name rsshub -p 1200:1200 diygod/rsshub

Ardından akışlara http://localhost:1200/rota/parametre biçiminde erişilir. Gerçek rota, takip edilen platforma göre RSSHub belgelerinden seçilir. Herkese açık örnek sunucular deneme için uygundur; düzenli kullanımda kendi örneğini barındırmak hız, gizlilik ve kota kontrolü sağlar.

Sağlam bir yayın için son dokunuşlar

RSS çıktısını bir XML doğrulayıcıyla test et, açıklamalardaki HTML’i güvenli biçimde temizle ve ETag ile Last-Modified başlıklarını etkinleştir. Böylece okuyucular değişmeyen dosyayı tekrar indirmez. Kısacası WordPress hızlı başlangıç, Feedgen özel üretim, RSSHub ise keşif ve dönüştürme aracıdır. Üçünü birlikte kullandığında dağınık internet, düzenli ve sana ait bir haber merkezine dönüşür.