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.

``

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

Bir online derleyici temel olarak kaynak kodunu ve kullanıcı girdisini alır, uygun çalışma ortamını seçer ve işlemi yalıtılmış bir alanda yürütür. Derlenen dillerde süreç genellikle şu şekildedir:

Python gibi yorumlanan dillerde derleme adımı görünür olmayabilir; ancak ortam hazırlama ve süreç başlatma maliyeti devam eder. Sistem, çalıştırma sonunda standart çıktıyı, standart hatayı, durum kodunu, süreyi ve bellek tüketimini döndürür.

Yalıtım kritik önemdedir. Kullanıcının gönderdiği kod sonsuz döngüye girebilir, dosya sistemini kurcalayabilir veya bir fork bombası başlatmayı deneyebilir. Bu nedenle container, namespace, cgroup, seccomp ve ayrıcalıksız kullanıcı gibi mekanizmalar kullanılır. Basitleştirilmiş bir kaynak koşulu şöyledir:

Bu sınırlardan biri aşılırsa çalıştırma sonlandırılır. Kısacası sistem yalnızca kodu çalıştırmaz; ona güvenli bir oyun alanı da çizer.

Üç sistemin karakteri

Judge0

Judge0, özellikle otomatik değerlendirme sistemlerine yakışır. Bir gönderim oluşturur, dil kimliğini, kaynak kodunu ve girdiyi iletirsiniz. Sonucu eşzamanlı alabilir veya daha ölçeklenebilir biçimde bir token üzerinden sorgulayabilirsiniz. Zaman ve bellek sınırları, derleme çıktısı ve çalışma durumu gibi alanlar eğitim platformları için oldukça değerlidir.

Piston

Piston, farklı dillerde kod çalıştırmayı anlaşılır bir HTTP API arkasında toplar. Dil paketleri ve sürümleri yönetilebilir; bu da onu web tabanlı editörler, Discord botları veya hızlı prototipler için çekici yapar. Judge0 kadar yarışma odaklı bir değerlendirme modeli sunmak yerine, “kodu ver, çıktıyı al” deneyimine yaklaşır.

Aşağıdaki JavaScript örneği, Piston uyumlu bir uç noktaya Python kodu gönderir:

const response = await fetch("https://example.com/api/v2/execute", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    language: "python",
    version: "3.x",
    files: [{ content: "print(sum([4, 8, 15, 16, 23, 42]))" }]
  })
});

const result = await response.json();
console.log(result.run.stdout);

Kod, çalıştırılacak dosyayı JSON gövdesine yerleştirir ve dönen standart çıktıyı gösterir. Gerçek sürüm değeri ile uç nokta, kullandığınız Piston kurulumundan sorgulanmalıdır.

Wandbox

Wandbox özellikle C++ dünyasında farklı derleyicileri, sürümleri ve bayrakları karşılaştırırken parlar. Aynı kodu GCC ve Clang ile deneyip standart sürümünü değiştirmek, taşınabilirlik sorunlarını yakalamayı kolaylaştırır. Bu nedenle klasik bir sınav motorundan çok etkileşimli bir derleyici laboratuvarına benzer.

Hangisini seçmelisiniz?

Otomatik puanlama, test senaryoları ve ayrıntılı durum yönetimi istiyorsanız Judge0 güçlü adaydır. Küçük ve anlaşılır bir kod çalıştırma servisi arıyorsanız Piston daha rahat hissettirebilir. Derleyici sürümleri ve bayraklarla deney yapacaksanız Wandbox öne çıkar.

Hangi sistemi seçerseniz seçin API’yi doğrudan sınırsız biçimde internete açmayın. Kimlik doğrulama, istek kotası, çıktı boyutu sınırı, zaman aşımı ve düzenli imaj güncellemeleri ekleyin. Çünkü online derleyicide en zor soru “Kod çalıştı mı?” değil, “Kod çalışırken sunucu hâlâ güvende mi?” sorusudur.

Bir sunucunun çalışıyor görünmesi, sağlıklı olduğu anlamına gelmez. İşlemci tavana vurmuş, disk dolmak üzere veya ağ gecikmesi kullanıcıları çileden çıkarıyor olabilir. Sunucu izleme sistemleri; altyapının nabzını ölçer, sorunları görünür hâle getirir ve gece telefonunuz çalmadan önce sizi uyarır. Bu alandaki üç güçlü seçenek Zabbix, Nagios ve Checkmk’tir. ``

İzleme sistemlerinin temel mantığı

Bir izleme platformu belirli aralıklarla metrik toplar. CPU kullanımı, boş disk alanı, bellek tüketimi ve HTTP yanıt süresi bu metriklere örnektir. Toplanan değerler önceden belirlenmiş eşiklerle karşılaştırılır; şart sağlandığında olay oluşturulur ve bildirim gönderilir.

Basit bir CPU kullanım oranı şöyle hesaplanabilir:

Ancak tek bir yüksek ölçüm her zaman sorun değildir. Kısa süreli sıçramaları filtrelemek için hareketli ortalama kullanılabilir:

Örneğin son beş ölçümün ortalaması yüzde 90’ı geçerse alarm üretmek, anlık bir yükselişte gereksiz bildirim almaktan daha mantıklıdır. Aksi hâlde izleme sistemi yardımcı olmak yerine dijital bir yangın alarmına dönüşür.

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

Zabbix: Her şey tek çatı altında

Zabbix; metrik toplama, grafik çizme, alarm üretme, otomatik keşif ve raporlama özelliklerini birlikte sunar. Agent kullanarak işletim sisteminden ayrıntılı veri alabilir; SNMP, IPMI, JMX ve HTTP kontrolleriyle farklı cihazları izleyebilir.

Linux sunucuya kurulan agent’ın temel durumunu şu komutlarla kontrol edebilirsiniz:

sudo systemctl enable --now zabbix-agent2
sudo systemctl status zabbix-agent2

İlk komut servisi başlatıp sistem açılışına ekler; ikincisi agent’ın düzgün çalışıp çalışmadığını gösterir. Zabbix özellikle merkezi gösterge panelleri ve geçmiş veriler üzerinden kapasite planlaması isteyen ekipler için başarılıdır.

Nagios: Eklentilerle büyüyen klasik

Nagios, izleme dünyasının deneyimli ustasıdır. Temel felsefesi basittir: Bir eklenti kontrol gerçekleştirir ve durum kodu döndürür. 0 başarılı, 1 uyarı, 2 kritik, 3 ise bilinmeyen durum anlamına gelir.

Örneğin disk kullanımını denetleyen bir eklenti şöyle çağrılabilir:

/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /

Bu kontrol, kök bölümde boş alan yüzde 20’nin altına inince uyarı, yüzde 10’un altına inince kritik durum üretir. Nagios son derece esnektir; ancak eklenti ve yapılandırma yönetimi büyüyen ortamlarda ciddi emek isteyebilir.

Checkmk: Otomasyon sevenlerin seçeneği

Checkmk, Nagios ekosisteminin kontrol mantığından yararlanırken keşif, yapılandırma ve görselleştirme süreçlerini kolaylaştırır. Tek bir agent çıktısından yüzlerce servisi otomatik keşfedebilir. Bu özellik, çok sayıda benzer sunucuyu yöneten ekiplerin tekrar eden işlerini azaltır.

Kural tabanlı yapılandırma sayesinde aynı disk eşiğini her sunucu için ayrı ayrı yazmak yerine sunucu gruplarına uygulayabilirsiniz. Raw Edition açık kaynak odaklıdır; Enterprise Edition ise daha gelişmiş performans ve kurumsal özellikler sunar.

Hangisini seçmelisiniz?

Hazır grafikler, geniş protokol desteği ve bütünleşik deneyim istiyorsanız Zabbix güçlü bir tercihtir. Kontrolleri tamamen özelleştirmek ve geniş eklenti ekosisteminden yararlanmak istiyorsanız Nagios uygundur. Hızlı keşif, kolay yönetim ve düşük operasyon yükü önceliğinizse Checkmk öne çıkar.

Son kararı özellik listesinden önce ekibinizin deneyimi, izlenecek cihaz sayısı ve alarm yönetimi ihtiyacı belirlemelidir. Çünkü en iyi izleme sistemi, en fazla grafiği çizen değil; doğru sorunu, doğru kişiye, doğru zamanda bildiren sistemdir.

``

Önce problemi doğru tanımlayalım

Bir abonelik sisteminde billing, müşterinin ne kadar borçlandığını hesaplar; invoicing, bu borcu resmi veya ticari bir belgeye dönüştürür; payment processing ise paranın tahsil edilmesini sağlar. Bu kavramları tek sepete atmak, ileride mimari karmaşaya yol açabilir.

Basit bir aylık ücret şu şekilde gösterilebilir:

Burada $S$ sabit abonelik ücreti, $q$ tüketilen miktar, $p$ birim fiyat, $d$ indirim ve $v$ vergi tutarıdır. Kullanım bazlı bir SaaS ürününde asıl zorluk, $q$ değerini güvenilir biçimde toplamak ve doğru döneme yerleştirmektir.

Üç aracın karakteri

Kill Bill: Ağır sıklet motor

Kill Bill, abonelik yaşam döngüsünü ayrıntılı yönetmek isteyen ekipler için güçlüdür. Deneme süresi, yükseltme, düşürme, iptal, ödeme eklentileri ve gecikmiş hesap politikaları gibi konularda geniş bir model sunar. Birden fazla ödeme sağlayıcısını destekleyen, kuralları zamanla karmaşıklaşacak bir platform kuruyorsanız iyi bir adaydır.

Bunun bedeli operasyonel karmaşıklıktır. Kill Bill yalnızca birkaç API çağrısı yapıp unutacağınız hafif bir araç değildir. Katalog tasarımı, eklentiler, veri tabanı, olaylar ve sürüm yükseltmeleri için sahiplik gerekir.

Invoice Ninja: Fatura tarafının pratik ustası

Invoice Ninja daha çok müşteriye teklif hazırlama, fatura gönderme, ödeme takibi ve gider yönetimi gibi iş süreçlerinde parlar. Ajanslar, danışmanlar ve küçük işletmeler için anlaşılır bir merkez oluşturur. Müşteri portalı ve yinelenen faturalar sayesinde klasik abonelik ihtiyaçlarını da karşılayabilir.

Ancak saniyede binlerce kullanım olayı üreten bir API platformunda, karmaşık ölçüm ve kademeli fiyatlama için tek başına ideal motor olmayabilir. Burada Invoice Ninja son belgeyi oluşturan katman olarak değerlendirilebilir.

Lago: Kullanım bazlı SaaS yaklaşımı

Lago; API çağrısı, depolama miktarı veya aktif kullanıcı sayısı gibi olaylardan ücret üretmeye odaklanır. Sabit ücret ile tüketimi birleştiren hibrit modellerde esnektir. Örneğin ilk 10.000 isteğin pakete dahil, sonraki her 1.000 isteğin ücretli olduğu bir plan modellenebilir.

Uygulamanın Lago’ya tutarlı olay göndermesi gerekir:

import requests

payload = {
    "transaction_id": "evt_98421",
    "external_customer_id": "customer_42",
    "code": "api_request",
    "properties": {"requests": 1250}
}

requests.post(
    "https://billing.example.com/api/v1/events",
    json=payload,
    timeout=5
).raise_for_status()

Bu kod, müşterinin ölçülen API kullanımını tekil işlem kimliğiyle faturalandırma sistemine iletir. transaction_id, tekrar gönderilen olayların çift ücret üretmesini önlemeye yardımcı olur. Üretimde kuyruk, yeniden deneme ve gözlemlenebilirlik de eklenmelidir.

Hangisini seçmeli?

Kararı özellik listesinden önce iş modeline göre verin. Karmaşık abonelik ve tahsilat orkestrasyonu için Kill Bill, kolay fatura ve müşteri operasyonları için Invoice Ninja, olay tabanlı ücretlendirme için Lago daha doğal seçimdir. Bazı mimarilerde Lago kullanım tutarını hesaplar, Invoice Ninja belgeyi üretir; Kill Bill ise ödeme yaşam döngüsünü yönetir. Yani bunlar her zaman rakip değil, doğru sınırlar çizildiğinde aynı orkestranın farklı enstrümanlarıdır.

Fatura hazırlamak yalnızca birkaç ürünü alt alta yazıp toplamı göstermek değildir. Müşteri kayıtları, vergiler, para birimleri, ödeme durumları ve yasal numaralandırma kuralları işin içine girdiğinde küçük bir tablo hızla mini bir muhasebe sistemine dönüşür. Neyse ki Invoice Ninja, Akaunting ve Crater gibi açık kaynak araçlar bu karmaşayı yönetilebilir hâle getiriyor.

``

Fatura sisteminin temel mantığı

Bir fatura uygulamasında müşteri, ürün ve ödeme birbirinden bağımsız veriler olarak saklanır. Fatura ise bunları belirli bir tarihte bir araya getiren belgedir. Bu yaklaşım aynı müşteriyi veya ürünü her işlemde yeniden yazmayı önler.

Temel hesaplama şu şekilde ifade edilebilir:

Vergi ve indirim eklendiğinde ödenecek tutar:

Örneğin 500 TL tutarındaki bir hizmete yüzde 10 indirim ve ardından yüzde 20 vergi uygulanırsa sonuç $500-50+90=540$ TL olur. Burada işlem sırası önemlidir; verginin indirimden önce hesaplanması farklı bir sonuç üretir.

Üç güçlü aday

Invoice Ninja

Invoice Ninja; teklif oluşturma, yinelenen faturalar, zaman takibi ve çevrim içi ödeme konularında öne çıkar. Serbest çalışanlar ve ajanslar için oldukça uygundur. Müşteriye özel portal sunması sayesinde faturalar görüntülenebilir, indirilebilir ve desteklenen ağ geçitleri üzerinden ödenebilir.

Özellik sayısı fazla olduğundan ilk yapılandırma biraz zaman alabilir. Buna karşılık otomatik hatırlatmalar ve yinelenen faturalar, düzenli hizmet veren işletmelerin ciddi zaman kazanmasını sağlar.

Akaunting

Akaunting yalnızca fatura kesmek isteyenlerden ziyade gelir, gider, banka hesabı ve nakit akışı takibi yapmak isteyen işletmelere hitap eder. Çift taraflı muhasebe gibi gelişmiş ihtiyaçlar eklentilerle karşılanabilir.

Modüler yapı önemli bir avantajdır; ancak ihtiyaç duyulan bazı özelliklerin ücretli uygulamalar olarak sunulabileceği unutulmamalıdır. “Fatura da keseyim, şirketin finansal durumunu da izleyeyim” diyorsanız güçlü aday budur.

Crater

Crater modern arayüzü ve sade kurulumu ile dikkat çeker. Fatura, teklif, gider ve ödeme yönetimi gibi temel işlevleri gereksiz kalabalık yaratmadan sunar. Küçük işletmeler veya kendi sunucusunda hafif bir çözüm isteyen geliştiriciler için güzel bir başlangıçtır.

Bununla birlikte proje seçerken güncelleme sıklığını, topluluk etkinliğini ve güvenlik yamalarını kontrol etmek gerekir. Açık kaynak dünyasında iyi görünen bir arayüz kadar sürdürülebilir bakım da değerlidir.

Basit bir fatura hesabı

Aşağıdaki JavaScript fonksiyonu satır toplamlarını hesaplar, indirimi uygular ve vergi ekler:

function calculateInvoice(items, discountRate, taxRate) {
  const subtotal = items.reduce(
    (sum, item) => sum + item.quantity * item.unitPrice,
    0
  );

  const discount = subtotal * discountRate;
  const taxableAmount = subtotal - discount;
  const tax = taxableAmount * taxRate;

  return {
    subtotal,
    discount,
    tax,
    total: taxableAmount + tax
  };
}

const result = calculateInvoice(
  [{ quantity: 2, unitPrice: 750 }],
  0.10,
  0.20
);

console.log(result.total); // 1620

Bu kod eğitim amaçlıdır. Gerçek sistemlerde kayan nokta hatalarını önlemek için para tutarları kuruş cinsinden tam sayı olarak veya hassas ondalık kütüphaneleriyle saklanmalıdır.

Hangisini seçmeli?

Yinelenen faturalar, müşteri portalı ve ödeme entegrasyonları öncelikliyse Invoice Ninja; kapsamlı finans takibi isteniyorsa Akaunting; hızlı, sade ve geliştirici dostu bir deneyim aranıyorsa Crater daha uygundur. Son karardan önce yedekleme, e-posta teslimatı, yerel vergi mevzuatı, Türkçe desteği ve projenin güncelliği mutlaka test edilmelidir.

E-kitap, yazılım lisansı, tasarım şablonu veya çevrim içi eğitim satmak kulağa basit gelir: Dosyayı yükle, fiyatı belirle ve satışları bekle! Fakat güvenli teslimat, ödeme doğrulama, vergi, lisans yönetimi ve müşteri deneyimi devreye girdiğinde küçük dükkânımız gerçek bir yazılım projesine dönüşür. Bu yazıda WooCommerce, Easy Digital Downloads ve PrestaShop seçeneklerini karşılaştırarak doğru sistemi nasıl kurabileceğimizi inceleyeceğiz.

``

Dijital satışın temel mantığı

Dijital ürünlerde fiziksel stok bulunmasa da erişim hakkı bir çeşit stok gibi düşünülmelidir. Başarılı bir siparişin yaşam döngüsü şöyledir:

1. Müşteri ürünü sepete ekler.
2. Ödeme sağlayıcısı işlemi doğrular.
3. Sistem siparişi tamamlandı durumuna geçirir.
4. Kullanıcıya süreli veya indirme sayısı sınırlı bir bağlantı verir.
5. İşlem fatura, e-posta ve kayıt mekanizmalarına aktarılır.

Dosyanın herkese açık bir klasörde tutulması büyük hatadır. Teslimat bağlantısı tahmin edilemez, kullanıcıya özel ve mümkünse zaman aşımına sahip olmalıdır. Örneğin bağlantının geçerliliği $T = 24$ saat, indirme limiti ise $L = 3$ olarak tanımlanabilir.

Satışın ekonomik tarafını da unutmamalıyız. Basitleştirilmiş net gelir hesabı:

Burada $F$ satış fiyatını, $K$ ödeme komisyonunu, $V$ vergiyi, $I$ ise iade maliyetini temsil eder. Platform seçerken yalnızca kurulum ücretine değil, bu değişkenlerin nasıl yönetildiğine de bakılmalıdır.

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

WooCommerce, ileride fiziksel ürün satmayı düşünenler için esnek bir seçimdir. Tema ve eklenti ekosistemi oldukça geniştir; ancak gereksiz eklentiler performansı ve güvenliği olumsuz etkileyebilir.

Easy Digital Downloads, kısaca EDD, dijital teslimatı merkeze alır. İndirme kayıtları, müşteri geçmişi ve dosya erişimi daha sade biçimde yönetilir. Yazılım lisansı, üyelik veya abonelik için ücretli eklentiler gerekebilir.

PrestaShop ise bağımsız ve kapsamlı bir mağaza motorudur. Çoklu dil, para birimi ve büyük katalog yönetiminde güçlüdür. Yalnızca birkaç PDF satılacaksa biraz top ile sivrisinek avlamak sayılabilir!

WooCommerce ile örnek erişim kontrolü

Aşağıdaki PHP kodu, tamamlanan sipariş sonrasında basit bir kayıt oluşturur. Gerçek projede kayıt; lisans anahtarı, süre sonu ve ürün kimliğiyle genişletilmelidir.

add_action('woocommerce_order_status_completed', 'urun_erisim_kaydi');

function urun_erisim_kaydi($order_id) {
    $order = wc_get_order($order_id);

    foreach ($order->get_items() as $item) {
        if ($item->get_product()->is_downloadable()) {
            update_post_meta(
                $order_id,
                '_dijital_erisim_zamani',
                current_time('mysql')
            );
        }
    }
}

woocommerce_order_status_completed kancası sipariş tamamlandığında çalışır. Kod, siparişte indirilebilir ürün bulunursa erişim zamanını meta veri olarak saklar. Böylece destek, denetim veya özel lisans süreçleri için iz bırakılır.

Hangi platformu seçmelisin?

Hızlıca e-kitap, müzik veya şablon satacaksan EDD en temiz başlangıçtır. Dijital ve fiziksel ürünleri aynı sepette buluşturmak istiyorsan WooCommerce daha mantıklıdır. Çok dilli, kapsamlı ve bağımsız bir mağaza hedefliyorsan PrestaShop öne çıkar.

Platform ne olursa olsun SSL, düzenli yedekleme, güvenli ödeme altyapısı, KVKK uyumu ve test siparişleri zorunlu kabul edilmelidir. En iyi sistem, en fazla özelliğe sahip olan değil; müşterinin ödemeden indirmeye kadar sorunsuz ilerlediği sistemdir.

``

Temel Yaklaşımları

WooCommerce bağımsız bir e-ticaret yazılımı değil, WordPress üzerine kurulan bir eklentidir. WordPress içerik yönetiminde güçlüyken WooCommerce ona ürün, sepet, sipariş ve ödeme özellikleri kazandırır. Blog ile mağazayı aynı çatı altında yönetmek isteyenler için doğal bir seçimdir.

PrestaShop doğrudan e-ticaret amacıyla geliştirilmiştir. Katalog, stok, vergi, para birimi ve çoklu mağaza gibi özelliklere daha merkezi yaklaşır. Özellikle orta ölçekli ve büyüme hedefleyen mağazalarda ayrıntılı yönetim araçları sunar.

OpenCart ise sade ve görece hafif bir e-ticaret sistemidir. Yönetim paneli kolay öğrenilir, temel sunucularda çalışabilir ve hızlı başlangıç sağlar. Bununla birlikte gelişmiş ihtiyaçlar ortaya çıktığında eklenti veya özel geliştirme gerekebilir.

Maliyet Yalnızca Kurulum Değildir

Üç platform da ücretsiz indirilebilir. Ancak “açık kaynak” ifadesi mağazanın tamamen ücretsiz olacağı anlamına gelmez. Toplam sahip olma maliyetini şu şekilde düşünebiliriz:

Burada $H$ barındırma, $E$ eklenti ve tema, $G$ geliştirme, $B$ bakım, $O$ ise operasyon maliyetidir. Örneğin WooCommerce ucuz bir hosting ile başlayabilir; fakat trafik arttıkça önbellekleme, güvenlik ve veritabanı optimizasyonu gerekebilir. PrestaShop’un bazı modülleri bütçeyi yükseltebilir. OpenCart ekonomik başlayabilir, ancak özel entegrasyonlar geliştirici maliyeti oluşturabilir.

Platform seçiminde beklenen işlem yükü de önemlidir:

Ziyaretçi sayısı tek başına yeterli bir ölçü değildir. Filtreleme, arama, kampanya kuralları ve eş zamanlı ödeme işlemleri sunucu yükünü ciddi biçimde etkileyebilir.

Entegrasyon Mantığı

Modern mağazalar yalnızca ürün göstermez; kargo, muhasebe, ödeme ve pazaryeri servisleriyle konuşur. Bu nedenle API ve kanca mekanizmaları önemlidir. Aşağıdaki basitleştirilmiş WooCommerce örneği, sipariş tamamlandığında kayıt oluşturur:

add_action('woocommerce_order_status_completed', function ($orderId) {
    $order = wc_get_order($orderId);

    error_log(sprintf(
        'Sipariş tamamlandı: #%d, Toplam: %s',
        $orderId,
        $order->get_total()
    ));
});

Bu kod, sipariş durumu tamamlandığında çalışır ve sipariş numarasıyla toplam tutarı sunucu günlüğüne yazar. Gerçek bir projede aynı nokta ERP sistemine veri göndermek veya müşteriye özel bildirim üretmek için kullanılabilir. PrestaShop “hooks”, OpenCart ise “events” sistemiyle benzer genişletme noktaları sağlar.

Hangisini Seçmelisiniz?

Yoğun içerik, SEO ve blog çalışmaları planlıyorsanız WooCommerce avantajlıdır. Çoklu dil, para birimi, ayrıntılı katalog ve büyüme senaryoları ön plandaysa PrestaShop güçlü bir adaydır. Hızlı kurulan, sade yönetilen ve kaynak tüketimi görece düşük bir mağaza arıyorsanız OpenCart mantıklıdır.

Son karar yalnızca özellik listesine göre verilmemelidir. Ekibinizin deneyimi, yerel ödeme modülleri, güncelleme sıklığı, güvenlik takibi ve geliştirici erişimi değerlendirilmelidir. En iyi platform, en fazla özelliğe sahip olan değil; işletmenin bugünkü ihtiyaçlarını karşılarken yarının büyümesine gereksiz teknik borç oluşturmadan eşlik edendir.

``

Açık artırmanın temel mantığı

En yaygın model İngiliz tipi açık artırmadır. Satıcı bir başlangıç fiyatı belirler, katılımcılar giderek daha yüksek teklifler verir ve süre sonunda en yüksek teklif kazanır. Basit görünse de sistemin arkasında birkaç kritik değişken bulunur:

• Başlangıç fiyatı
• Minimum teklif artışı
• Rezerv fiyat
• Başlangıç ve bitiş zamanı
• Otomatik teklif üst sınırı
• Kazananın ödeme süresi

Mevcut en yüksek teklif $B$, minimum artış miktarı $I$ ise yeni teklifin sağlaması gereken koşul şöyledir:

Örneğin güncel fiyat 1.000 TL ve artış 50 TL ise sistem 1.049 TL’lik teklifi reddetmeli, 1.050 TL veya üzerini kabul etmelidir. Rezerv fiyat ise satıcının ürünü satmayı kabul ettiği gizli alt sınırdır. En yüksek teklif bu değere ulaşmazsa açık artırma kazanan olmadan kapanabilir.

OpenCart ve WooCommerce karşılaştırması

Her iki platformda da özellikler doğrudan çekirdeğe değil, çoğunlukla üçüncü taraf eklentilere bağlıdır. Bu nedenle satın almadan önce sürüm uyumluluğu ve geliştirici desteği mutlaka kontrol edilmelidir.

OpenCart, yalnızca satışa odaklanan sade bir mağaza isteyenler için avantajlı olabilir. WooCommerce ise açık artırmaları blog içerikleri, üyelik paketleri, SEO araçları ve pazarlama otomasyonlarıyla birleştirmek isteyenlere daha geniş bir oyun alanı sunar.

Otomatik teklif nasıl çalışır?

Proxy bidding adı verilen yöntemde kullanıcı, ödemeye razı olduğu maksimum tutarı sisteme bildirir. Sistem bu tutarı herkese göstermez; rakip teklif geldikçe minimum artış kadar otomatik yükseltme yapar. Böylece kullanıcının ekran başında sürekli nöbet tutması gerekmez.

function sonrakiTeklif($mevcut, $artis, $kullaniciLimiti) {
    $aday = $mevcut + $artis;

    if ($aday > $kullaniciLimiti) {
        return null;
    }

    return $aday;
}

Bu örnek, mevcut fiyata artış miktarını ekler ve sonucun kullanıcının gizli limitini geçip geçmediğini denetler. Gerçek projede aynı anda gelen tekliflere karşı veritabanı işlemi ve satır kilitleme de kullanılmalıdır. Aksi hâlde iki kullanıcı kendisini kazanan sanabilir; dijital müzayede salonunda sandalye kavgası çıkar.

Kritik eklenti özellikleri

Tercih edeceğiniz çözüm şu yetenekleri mümkün olduğunca sunmalıdır:

1. Rezerv fiyat ve şimdi satın al seçeneği
2. Otomatik teklif ve teklif geçmişi
3. E-posta veya SMS bildirimleri
4. Son saniye tekliflerine karşı süre uzatma
5. Kazanana otomatik sipariş oluşturma
6. Ödeme yapmayan kullanıcılar için yaptırım
7. Saat dilimi ve zamanlanmış görev desteği

Son saniyede gelen teklif sonrası süreyi $T$ dakika uzatan anti-sniping yaklaşımı, botların ve hızlı bağlantı avantajının etkisini azaltır. Zaman kontrolü tarayıcı saatine göre değil, mutlaka sunucu saatine göre yapılmalıdır.

Hangisini seçmelisiniz?

Mevcut mağazanız OpenCart üzerindeyse yalnızca açık artırma uğruna platform değiştirmek çoğu zaman gereksizdir. İçerik pazarlaması, çok sayıda entegrasyon ve kolay yönetim önceliğinizse WooCommerce daha uygun olabilir. Kararı verirken demo ortamında teklif verme, süre bitimi, sipariş oluşumu, iade ve e-posta senaryolarını test edin. İyi bir açık artırma sistemi yalnızca en yüksek fiyatı bulmaz; kullanıcıya adil, şeffaf ve teknik olarak güvenilir bir yarış sunduğunu da hissettirir.