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.

``

İnternet radyosu nasıl çalışır?

Tipik bir sistemde ses önce bir kaynak istemci tarafından MP3, AAC veya Opus biçiminde kodlanır. Kodlanmış veri Icecast gibi bir yayın sunucusuna gönderilir. Dinleyiciler ise belirli bir bağlantıya bağlanarak aynı akışı küçük bir tampon gecikmesiyle alır.

Temel mimari şöyledir:

Mikrofon / Otomasyon
        |
        v
Kodlayıcı veya AutoDJ
        |
        v
Icecast Yayın Sunucusu
        |
        +----> Web oynatıcı
        +----> Mobil uygulama
        +----> Masaüstü oynatıcı

Gerekli bant genişliği yaklaşık olarak şu formülle hesaplanabilir:

Burada $N$ eş zamanlı dinleyici sayısını, $R$ ise kişi başına bit hızını ifade eder. Örneğin 100 dinleyiciye 128 kbps yayın yaparsak:

Sunucunun diğer trafiğini de düşünerek bunun üzerinde bir bağlantı kapasitesi seçmek gerekir.

Üç araç arasındaki fark

Bu yazılımlar aynı problemi farklı katmanlarda çözer. Icecast dağıtım motorudur; AzuraCast ve LibreTime ise otomasyon, takvim ve yönetim özellikleri sunar.

AzuraCast, hızlı başlangıç isteyenler için en pratik seçenektir. İstasyon oluşturma, müzik yükleme, çalma listeleri, DJ hesapları, istatistikler ve web oynatıcı tek panelde bulunur. Arka planda genellikle Liquidsoap ve Icecast gibi bileşenleri birlikte yönetir.

LibreTime, radyo programcılığı ve yayın akışı planlamasına odaklanır. Saatlik programlar, tekrarlar, önceden kaydedilmiş içerikler ve canlı stüdyo geçişleri için güçlüdür. Özellikle ekip halinde çalışan topluluk radyolarına uygundur.

Icecast ise daha yalındır. Otomasyon sağlamaz; kendisine gönderilen sesi /radio.mp3 gibi bir bağlama noktası, yani mount point üzerinden dinleyicilere ulaştırır. Kendi panelini geliştirmek veya yalnızca dağıtım katmanı kurmak isteyenler için idealdir.

AzuraCast ile hızlı kurulum

Docker destekli güncel bir Linux sunucusunda AzuraCast kurulum betiği kullanılabilir:

mkdir -p /var/azuracast
cd /var/azuracast
curl -fsSL https://get.azuracast.com | bash

Bu komut kurulum yöneticisini indirir ve gerekli konteynerleri hazırlar. İşlem tamamlandığında tarayıcıdan sunucunun adresine giderek yönetici hesabı ve ilk istasyon oluşturulur. Çalma listesine parçalar eklendiğinde AutoDJ yayına başlayabilir.

Alan adı kullanıyorsanız HTTPS yapılandırmayı unutmayın. Yönetim panelini doğrudan internete açmak yerine güçlü parolalar, güvenlik duvarı ve düzenli yedekleme kullanmak önemlidir.

Icecast bağlantısını test etmek

Sunucunun yayın durumunu terminalden kontrol etmek için şu komut kullanılabilir:

curl -I https://radyo.example.com/radio.mp3

Başarılı bir bağlantıda 200 OK yanıtı görülür. Akışı VLC ile denemek için bağlantıyı doğrudan açabilir veya şu komutu çalıştırabilirsiniz:

vlc https://radyo.example.com/radio.mp3

Hangisini seçmelisin?

Tek sunucuda hızla çalışan modern bir istasyon istiyorsan AzuraCast, ayrıntılı yayın takvimi ve ekip iş akışı arıyorsan LibreTime, özel bir sistem geliştiriyor ve yalnızca güvenilir ses dağıtımı istiyorsan Icecast seçebilirsin. Küçük başlayıp ölçüm yapmak en sağlıklısıdır: düşük bit hızında deneme yayını aç, gecikmeyi gözlemle, ardından dinleyici sayısına göre işlemci ve bant genişliğini artır. Böylece dijital frekansın parazitsiz, sunucun da dumansız çalışır!

``

Temel mantık: Dosyadan müzik servisine

Bir müzik sunucusu yalnızca MP3 dosyalarını internete açmaz. Önce belirlediğiniz klasörleri tarar, ID3 veya Vorbis etiketlerinden sanatçı, albüm ve tür bilgilerini çıkarır, kapak görsellerini indeksler ve sonuçları bir veritabanına kaydeder. Kullanıcı oynat düğmesine bastığında dosya doğrudan gönderilebilir veya cihazın desteklediği formata transcode edilebilir.

Aynı anda dinleyen kullanıcıların ihtiyaç duyduğu yaklaşık bant genişliği şöyle hesaplanır:

Burada $n$ eş zamanlı dinleyici sayısı, $b$ ise parça başına bit hızıdır. Örneğin 5 kullanıcı 320 kbps ses dinliyorsa gereken yükleme kapasitesi yaklaşık $5 \times 320 = 1600$ kbps olur. FLAC arşivlerinde bu değer hızla büyüdüğü için mobil kullanıcılara 128 veya 192 kbps dönüştürme yapmak mantıklıdır.

Üç sistemin karakteri

Funkwhale, müzik dünyasının federasyon meraklısıdır. ActivityPub sayesinde farklı Funkwhale sunucuları birbirleriyle iletişim kurabilir. Kanallar, kütüphaneler, takip ve paylaşım özellikleriyle yalnızca kişisel oynatıcı değil, küçük bir bağımsız müzik topluluğu oluşturabilirsiniz. Bunun bedeli daha fazla servis, daha karmaşık kurulum ve daha yüksek RAM tüketimidir.

Navidrome, “klasörümü göster, gerisini hallet” yaklaşımını benimser. Go ile yazıldığı için tek çalıştırılabilir dosyayla bile ayağa kalkabilir. Subsonic ve OpenSubsonic uyumluluğu sayesinde Symfonium, Ultrasonic veya play:Sub gibi istemcilerle çalışır. Federasyon ya da sosyal ağ özellikleri sunmaz; buna karşılık hızlı, sade ve düşük güçlü ev sunucuları için idealdir.

Ampache ise bu üçlünün deneyimli arşiv yöneticisidir. PHP tabanlı yapısı klasik bir web sunucusu ortamına kolayca yerleşir. Geniş katalog yönetimi, kullanıcı yetkileri, çalma listeleri ve API seçenekleri sunar. Arayüzü Navidrome kadar minimalist değildir; fakat büyük ve düzenli koleksiyonlarda güçlü kontrol sağlar.

Navidrome ile hızlı başlangıç

En hafif seçeneği denemek için aşağıdaki Docker Compose dosyası yeterlidir:

services:
  navidrome:
    image: deluan/navidrome:latest
    user: "1000:1000"
    ports:
      - "4533:4533"
    environment:
      ND_SCANSCHEDULE: "1h"
      ND_LOGLEVEL: "info"
      ND_ENABLETRANSCODINGCONFIG: "true"
    volumes:
      - ./data:/data
      - /srv/music:/music:ro
    restart: unless-stopped

/srv/music arşivi salt okunur bağlanır; böylece uygulama yanlışlıkla parçalarınızı değiştiremez. ./data ise veritabanını ve ayarları kalıcı tutar. docker compose up -d komutundan sonra http://sunucu-adresi:4533 üzerinden ilk yönetici hesabı oluşturulur.

Hangisini seçmeli?

Raspberry Pi, mini PC veya NAS üzerinde kişisel Spotify alternatifiniz olsun istiyorsanız Navidrome en pratik tercihtir. Müzik paylaşımını sosyal ve federatif bir yapıya taşımak istiyorsanız Funkwhale daha heyecan vericidir. PHP ekosistemine hâkimseniz, ayrıntılı kullanıcı ve katalog yönetimi arıyorsanız Ampache güçlü bir seçenektir.

Hangi sistemi kurarsanız kurun HTTPS, güçlü parolalar, düzenli yedekleme ve mümkünse ters proxy kullanın. Ayrıca yalnızca paylaşma hakkına sahip olduğunuz içerikleri yayımlayın. Kendi müzik bulutunuzu kurmak özgürlük getirir; sunucu yöneticiliği sorumluluğunu da çalma listesine ekler.