Kontrol döngülerinde hedef yalnızca az bellek kullanmak değildir; aynı zamanda zamanlamayı da garanti etmektir. Örneğin bir motor kontrol döngüsünde örnekleme süresi $T_s = 1ms$ ise, bellek ayırma yüzünden oluşan rastgele gecikmeler kabul edilemez. Bu yüzden gömülü C projelerinde malloc ve free çoğu zaman yasaklı kelimeler gibidir. Heap parçalanması, başlangıçta çalışıp saatler sonra çöken cihazların klasik sebeplerindendir.

Dinamik ayırma gerekiyorsa, genel amaçlı heap yerine sabit bloklu bir bellek havuzu daha güvenlidir. Aşağıdaki örnek, 16 adet sabit boyutlu mesaj bloğunu yönetir. Böylece ayırma süresi yaklaşık sabittir ve parçalanma oluşmaz.

#include <stdint.h>
#include <stddef.h>

#define BLOCK_SIZE 32
#define BLOCK_COUNT 16

typedef struct {
    uint8_t data[BLOCK_SIZE];
    uint8_t used;
} Block;

static Block pool[BLOCK_COUNT];

void *pool_alloc(void) {
    for (uint8_t i = 0; i < BLOCK_COUNT; i++) {
        if (!pool[i].used) {
            pool[i].used = 1;
            return pool[i].data;
        }
    }
    return NULL;
}

void pool_free(void *ptr) {
    for (uint8_t i = 0; i < BLOCK_COUNT; i++) {
        if (pool[i].data == ptr) {
            pool[i].used = 0;
            return;
        }
    }
}

Bu kodda belleğin tamamı derleme zamanında ayrılır. pool_alloc, boş bir blok bulur ve işaretçi döndürür. pool_free ise bloğu tekrar kullanılabilir hâle getirir. Dezavantajı, her bloğun aynı boyutta olmasıdır; 5 byte veriye de 32 byte ayrılır. Ancak gömülü sistemlerde öngörülebilirlik çoğu zaman maksimum verimden daha değerlidir.

Stack kullanımı da ayrıca izlenmelidir. Büyük dizileri fonksiyon içinde tanımlamak cazip görünür ama tehlikelidir. Örneğin uint8_t buffer[1024]; satırı, 2 KB RAM bulunan bir mikrodenetleyicide felaketin yarısı olabilir. Büyük tamponlar global veya static tanımlanmalı, mümkünse boyutları hesaplanmalıdır: \(Buffer_{toplam}=N_{paket}\times Boyut_{paket}\). Eğer UART üzerinden 8 paket tutulacak ve her paket 32 byte olacaksa toplam tampon 256 byte eder; kulağa az gelir ama 2 KB RAM içinde yüzde 12.5 demektir.

Veri tipi seçimi de byte avcılığının eğlenceli kısmıdır. Sıcaklık 0-100 arasıysa uint8_t yeterli olabilir; sayaç 100000 değerine çıkacaksa uint32_t gerekir. Ancak işlemci 8 bit ise 32 bit aritmetik daha yavaş olabilir. Yani bellek optimizasyonu ile CPU maliyeti birlikte düşünülmelidir.

Pratikte iyi bir strateji şudur: önce bellek haritasını çıkar, global değişkenleri say, maksimum stack derinliğini tahmin et, kesme rutinlerinde büyük işlem yapma ve iletişim tamponlarını matematiksel olarak boyutlandır. Derleyicinin map dosyası bu noktada hazine haritasıdır; hangi sembolün kaç byte tuttuğunu gösterir.

Sonuç olarak C ile gömülü sistemlerde bellek yönetimi, biraz muhasebe biraz da mühendislik sezgisidir. Her byte’ın bir görevi olmalı, her tamponun nedeni bilinmeli ve her kontrol döngüsü zamanında bitmelidir. Kaynak kısıtlı olabilir; ama iyi tasarlanmış bir bellek düzeniyle küçük bir mikrodenetleyici bile şaşırtıcı derecede kararlı ve güçlü çalışabilir.

Bulmaca çözmek aslında arama problemidir

Birçok mantık bulmacası, bilgisayar bilimi açısından bir durum uzayı araması problemidir. Elimizde başlangıç durumu, geçerli hamle kuralları ve hedef durum vardır. Örneğin Sudoku için hedef, her satırda, sütunda ve 3x3 kutuda 1’den 9’a kadar sayıların çakışmadan yerleşmesidir.

Teorik olarak her boş hücre için olasılıkları deneriz. Eğer $b$ her adımda ortalama seçenek sayısı, $d$ ise boş hücre sayısıysa kaba karmaşıklık $O(b^d)$ olur. Kulağa korkutucu geliyor; çünkü gerçekten de öyle. Ama kısıtlar ve akıllı seçim stratejileriyle arama ağacını ciddi biçimde budayabiliriz.

Tarayıcı neden harika bir oyun alanı?

Tarayıcı bize üç güzel şey verir: DOM ile görsel arayüz, Canvas/SVG ile çizim ve async/await ile adım adım animasyon. Böylece algoritma sadece sonucu basmaz; hangi hücreyi denediğini, nerede çuvalladığını ve neden geri döndüğünü de gösterir. Kullanıcı için bu, kara kutu yerine cam kutu deneyimidir.

Aşağıdaki örnek, basitleştirilmiş bir Sudoku çözücünün kalbini gösterir. Amaç, boş hücre bulmak, geçerli sayıları denemek ve çıkmaz sokakta geri almaktır.

function findEmpty(board) {
  for (let r = 0; r < 9; r++) {
    for (let c = 0; c < 9; c++) {
      if (board[r][c] === 0) return { r, c };
    }
  }
  return null;
}

function isValid(board, r, c, n) {
  for (let i = 0; i < 9; i++) {
    if (board[r][i] === n || board[i][c] === n) return false;
  }

  const sr = Math.floor(r / 3) * 3;
  const sc = Math.floor(c / 3) * 3;

  for (let i = sr; i < sr + 3; i++) {
    for (let j = sc; j < sc + 3; j++) {
      if (board[i][j] === n) return false;
    }
  }
  return true;
}

Bu iki fonksiyon hakem gibi çalışır. findEmpty, sıradaki problemi bulur; isValid ise önerilen hamlenin kurallara uygun olup olmadığını söyler. Şimdi buna görsellik ekleyelim.

const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));

async function solve(board, render) {
  const cell = findEmpty(board);
  if (!cell) return true;

  for (let n = 1; n <= 9; n++) {
    if (isValid(board, cell.r, cell.c, n)) {
      board[cell.r][cell.c] = n;
      render(board, cell, 'try');
      await sleep(80);

      if (await solve(board, render)) return true;

      board[cell.r][cell.c] = 0;
      render(board, cell, 'backtrack');
      await sleep(80);
    }
  }
  return false;
}

Burada render fonksiyonu arayüzü günceller. try durumunda hücre yeşil, backtrack durumunda kırmızı gösterilebilir. Böylece kullanıcı algoritmanın düşündüğü yolları izler.

Daha zeki çözücü: en az adaylı hücre

Sıradaki boş hücreyi soldan sağa seçmek kolaydır ama her zaman akıllıca değildir. Daha iyi strateji, aday sayısı en az olan hücreyi seçmektir. Buna genellikle MRV, yani minimum remaining values denir. Eğer bir hücrede sadece 2 ihtimal, diğerinde 7 ihtimal varsa önce 2 ihtimalli hücreye bakmak mantıklıdır.

Bu yaklaşım arama ağacını küçültür. Örneğin teorik olarak $5^{40}$ gibi devasa bir deneme alanı, iyi kısıtlarla çok daha yönetilebilir hale gelir. Elbette garanti sihir değildir; fakat gerçek bulmacalarda fark şaşırtıcıdır.

Görsel bulmacalara genişletmek

Aynı model Sudoku dışında Nonogram, KenKen, labirent, taş kaydırma oyunları ve hatta satranç problemleri için kullanılabilir. Değişen şey isValid fonksiyonunun kurallarıdır. Nonogram’da satır ipuçlarını, labirentte duvarları, satrançta taş hareketlerini kontrol edersiniz. Genel iskelet aynı kalır: durum üret, geçerliliği kontrol et, uygunsa ilerle, değilse geri dön.

Son dokunuşlar

Kullanıcıya hız kontrolü, adım sayacı, duraklat-devam et düğmesi ve çözüm geçmişi eklerseniz proje bir algoritma demosundan mini eğitim aracına dönüşür. Hatta her hamleyi bir listeye yazıp neden seçildiğini açıklayabilirsiniz. İşin eğlenceli tarafı şu: JavaScript burada yalnızca çözüm üreten bir araç değil, algoritmanın zihnini görünür kılan bir sahne yönetmenidir.

Basit akış şöyledir:

1. Sosyal medya platformunda olay gerçekleşir.
2. Platform, sizin belirlediğiniz URL’ye HTTP POST isteği gönderir.
3. Python uygulamanız imzayı ve veriyi doğrular.
4. Olay türüne göre hedef sitede konu açılır.
5. Sonuç loglanır, hata varsa tekrar deneme kuyruğuna alınır.

Teorik olarak bir webhook sistemini şu fonksiyon gibi düşünebiliriz:

Burada $event$ sosyal medya hareketini, $action$ ise başka sitede konu açma işlemini temsil eder. Ancak gerçek dünyada iş biraz daha baharatlıdır: güvenlik, tekrar eden istekler, zaman aşımı, API limitleri ve veri eşleme gibi konular devreye girer.

Güvenlik tarafında en önemli noktalardan biri imza doğrulamadır. Platform genellikle gövde verisini gizli anahtarla imzalar. Siz de aynı hesabı yapıp gelen imzayla karşılaştırırsınız:

Eğer imzalar eşleşmiyorsa istek reddedilmelidir. Çünkü internete açık bir endpoint, robotların ve meraklı kişilerin favori oyun alanıdır.

Aşağıdaki örnek Flask ile yazılmış orta düzey bir webhook alıcısıdır. Gelen olayı doğrular, aynı olayın iki kez işlenmesini engeller ve hedef foruma konu açmak için örnek bir POST isteği gönderir.

import os
import hmac
import hashlib
import requests
from flask import Flask, request, abort, jsonify

app = Flask(__name__)

SECRET = os.environ.get('WEBHOOK_SECRET', 'dev-secret')
FORUM_API = os.environ.get('FORUM_API', 'https://forum.example.com/api/topics')
FORUM_TOKEN = os.environ.get('FORUM_TOKEN', 'demo-token')

processed_events = set()

def verify_signature(payload, received_signature):
    expected = hmac.new(
        SECRET.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, received_signature or '')

def create_topic(event):
    username = event.get('username', 'bilinmeyen')
    text = event.get('text', '')
    platform = event.get('platform', 'sosyal medya')

    data = {
        'title': f'{platform} üzerinde yeni hareket: {username}',
        'body': f'Kullanıcı: {username}\n\nİçerik:\n{text}',
        'category': 'Sosyal Medya'
    }

    headers = {
        'Authorization': f'Bearer {FORUM_TOKEN}'
    }

    response = requests.post(FORUM_API, json=data, headers=headers, timeout=10)
    response.raise_for_status()
    return response.json()

@app.post('/webhooks/social')
def social_webhook():
    payload = request.get_data()
    signature = request.headers.get('X-Signature')

    if not verify_signature(payload, signature):
        abort(401)

    event = request.get_json()
    event_id = event.get('id')

    if event_id in processed_events:
        return jsonify({'status': 'duplicate_ignored'})

    processed_events.add(event_id)

    if event.get('type') == 'mention':
        result = create_topic(event)
        return jsonify({'status': 'topic_created', 'result': result})

    return jsonify({'status': 'ignored'})

Bu kodda processed_events örnek amaçlı bellekte tutuluyor. Gerçek projede Redis, PostgreSQL veya benzeri kalıcı bir sistem kullanmak daha doğrudur. Çünkü uygulama yeniden başlarsa bellek sıfırlanır ve aynı olay tekrar konu açabilir. Bu probleme idempotency denir: aynı isteğin birden fazla kez gelmesi durumunda sistemin aynı sonucu üretmesi gerekir.

Veri eşleme de önemlidir. Sosyal medya olayı doğrudan forum konusuna dönüşmez; arada anlamlı bir çeviri katmanı gerekir.

Hata yönetimi tarafında üstel geri çekilme kullanabilirsiniz. Örneğin tekrar deneme süresi şu şekilde büyüyebilir:

Burada $n$ deneme sayısıdır, üst sınır ise 300 saniyedir. Böylece hedef site kısa süreli çökerse sisteminiz panikle spam atmaz.

Sonuç olarak Python ile webhook entegrasyonu, sadece bir endpoint yazmaktan ibaret değildir. Güvenli doğrulama, idempotency, veri dönüştürme, loglama ve tekrar deneme stratejileriyle birleşince ortaya sosyal medya hareketlerini otomatik aksiyona dönüştüren sağlam bir tetikleyici mekanizma çıkar. Küçük başlar, sonra bir bakmışsınız forumunuz sosyal medyanın nabzını gerçek zamanlı tutan mini bir haber merkezine dönüşmüş!

Teorik olarak blok tabanlı aygıtlarda en küçük adreslenebilir birim genellikle sektördür. Klasik disklerde sektör boyutu çoğunlukla 512 bayt, yeni disklerde ise 4096 bayt olabilir. Bir okuma işleminin yaklaşık maliyeti şu şekilde düşünülebilir:

Burada $B$ okunan bayt miktarı, $R$ aktarım hızı, $T_{arama}$ mekanik kafanın konumlanma süresi, $T_{gecikme}$ ise dönüş gecikmesidir. SSD ve USB adaptörlerde mekanik süreler yoktur ama komut kuyruğu, veri yolu gecikmesi ve köprü yongasının davranışı hâlâ önemlidir.

C tarafında en temel fikir, donanım kayıtlarını temsil eden kesin boyutlu veri tipleri kullanmaktır. uint8_t, uint16_t ve uint32_t bu yüzden önemlidir. Ayrıca derleyicinin optimizasyon sırasında donanım erişimini “gereksiz” sanıp silmemesi için volatile kullanılır.

#include <stdint.h>

#define ATA_DATA       0x1F0
#define ATA_SECTOR_CNT 0x1F2
#define ATA_LBA_LOW    0x1F3
#define ATA_COMMAND    0x1F7

static inline void outb(uint16_t port, uint8_t value) {
    __asm__ volatile ("outb %0, %1" : : "a"(value), "Nd"(port));
}

static inline uint8_t inb(uint16_t port) {
    uint8_t value;
    __asm__ volatile ("inb %1, %0" : "=a"(value) : "Nd"(port));
    return value;
}

Bu örnekte x86 üzerinde I/O portlarına erişen küçük yardımcı fonksiyonlar var. outb donanıma komut veya parametre gönderir, inb ise durum bayrağı okur. Gerçek bir çekirdek sürücüsünde bunlar doğrudan kullanıcı programından çağrılamaz; ayrıcalıklı kip gerekir. Linux’ta bu iş çekirdek modülü, Windows’ta ise WDM/KMDF sürücüsü üzerinden yapılır.

Bir sürücü algoritmasının kalbi genellikle durum makinesidir. Aygıta komut verilir, aygıt meşgul olur, sonra hazır bayrağı beklenir. Basitleştirilmiş akış şöyledir:

enum disk_state {
    DISK_IDLE,
    DISK_SEND_CMD,
    DISK_WAIT_READY,
    DISK_TRANSFER,
    DISK_ERROR
};

int wait_ready(void) {
    for (int i = 0; i < 100000; i++) {
        uint8_t status = inb(ATA_COMMAND);
        if ((status & 0x80) == 0 && (status & 0x08))
            return 0;
    }
    return -1;
}

Burada 0x80 meşgul bayrağını, 0x08 veri hazır bayrağını temsil eder. Döngü sonsuza kadar beklemek yerine zaman aşımı uygular; çünkü donanım dünyasında “cevap gelmedi” de geçerli bir cevaptır. Sağlam sürücü yazmanın sırrı, mutlu yoldan çok hata yollarını ciddiye almaktır.

Harici adaptörlerde tablo biraz değişir. USB-SATA köprüleri çoğunlukla Mass Storage Class ya da UASP kullanır. Siz doğrudan ATA portuna yazmazsınız; SCSI benzeri komut paketleri gönderirsiniz. Yani algoritma yine blok okuma/yazma yapar ama alttaki taşıma protokolü farklıdır. Bu yüzden iyi tasarımda “blok aygıt arayüzü” ile “taşıma katmanı” ayrılır.

Son olarak güvenlik notu: Gerçek disklere deneme sürücüsüyle yazmak veri kaybına yol açabilir. Önce QEMU, Bochs, loop device veya sahte blok aygıtlarıyla test yapmak en sağlıklı yoldur. C ile donanım konuşmak, biraz arkeoloji biraz da elektrikli ejderha terbiyeciliğidir: protokolü okur, bayrakları izler, zaman aşımını koyar ve asla donanıma körü körüne güvenmezsiniz.

Şifreleme fikri: kilit, anahtar ve dönüşüm

Bir şifreleme algoritmasını kabaca şu fonksiyon gibi düşünebiliriz: $C = E(M, K)$. Burada $M$ açık mesaj, $K$ anahtar, $E$ şifreleme fonksiyonu ve $C$ şifreli metindir. Çözme tarafında ise $M = D(C, K)$ ya da asimetrik sistemlerde farklı bir anahtar kullanılarak $M = D(C, K_{private})$ elde edilir.

Temel ayrım şudur:

Bu yazıda eğitim amacıyla küçük bir RSA benzeri yapı kuracağız. Gerçek dünyada kendi kriptonuzu üretip canlı sistemde kullanmak genellikle kötü fikirdir; AES, ChaCha20, RSA-OAEP gibi incelenmiş standartlar ve OpenSSL/libsodium gibi kütüphaneler tercih edilmelidir. Ama mantığı kodlamak öğrenmenin en iyi yollarından biridir.

RSA’nın matematiksel kalbi

RSA, büyük asal sayıların çarpanlara ayrılmasının zorluğuna dayanır. İki asal seçeriz: $p$ ve $q$. Sonra $n = p \times q$ hesaplanır. Bu $n$, hem açık hem özel anahtar tarafında kullanılır.

Euler phi değeri: $\varphi(n) = (p-1)(q-1)$.

Açık üs $e$, $\varphi(n)$ ile aralarında asal seçilir. Özel üs $d$ ise şu koşulu sağlar: $d \times e \equiv 1 \pmod{\varphi(n)}$.

Şifreleme: $C = M^e \mod n$
Çözme: $M = C^d \mod n$

Buradaki sihir, modüler aritmetiktedir. Sayılar devasa büyümeden üs alma yapmak için “hızlı üs alma” tekniği kullanılır.

C++ ile mini RSA deneyi

Aşağıdaki kod güvenli değildir; çünkü çok küçük asal sayılar kullanır. Amacı, RSA mantığını elle tutulur hale getirmektir.

#include <iostream>
#include <vector>
#include <cstdint>
using namespace std;

uint64_t modPow(uint64_t base, uint64_t exp, uint64_t mod) {
    uint64_t result = 1;
    base %= mod;
    while (exp > 0) {
        if (exp & 1) result = (result * base) % mod;
        base = (base * base) % mod;
        exp >>= 1;
    }
    return result;
}

int64_t egcd(int64_t a, int64_t b, int64_t &x, int64_t &y) {
    if (b == 0) { x = 1; y = 0; return a; }
    int64_t x1, y1;
    int64_t g = egcd(b, a % b, x1, y1);
    x = y1;
    y = x1 - (a / b) * y1;
    return g;
}

uint64_t modInverse(uint64_t e, uint64_t phi) {
    int64_t x, y;
    egcd(e, phi, x, y);
    return (x % (int64_t)phi + phi) % phi;
}

int main() {
    uint64_t p = 61, q = 53;
    uint64_t n = p * q;
    uint64_t phi = (p - 1) * (q - 1);
    uint64_t e = 17;
    uint64_t d = modInverse(e, phi);

    uint64_t message = 42;
    uint64_t encrypted = modPow(message, e, n);
    uint64_t decrypted = modPow(encrypted, d, n);

    cout << "Acik anahtar (e,n): (" << e << "," << n << ")\n";
    cout << "Ozel anahtar d: " << d << "\n";
    cout << "Mesaj: " << message << "\n";
    cout << "Sifreli: " << encrypted << "\n";
    cout << "Cozulen: " << decrypted << "\n";
}

modPow fonksiyonu, $M^e$ gibi astronomik büyüyebilecek ifadeleri güvenli şekilde mod içinde tutar. egcd yani genişletilmiş Öklid algoritması ise modüler ters bulur; RSA’daki özel anahtarın matematiksel üretim noktası burasıdır.

Neden gerçek sistemlerde daha fazlası gerekir?

Oyuncak RSA sadece iskeleti gösterir. Gerçek kriptografide asal üretimi, rastgelelik, dolgu şemaları ve yan kanal saldırılarına dayanıklılık kritik önemdedir.

Pratikte RSA genellikle tüm dosyayı şifrelemek için değil, AES anahtarını güvenli taşımak için kullanılır. Buna hibrit şifreleme denir: hızlı simetrik algoritma veriyi şifreler, asimetrik algoritma ise anahtarı korur.

Sonuç olarak C++ ile kriptografi yazmak, matematik ve sistem programlamayı aynı masaya oturtur. Kendi mini aracınızı geliştirmek size $\mod$, asal sayılar ve anahtar mantığını öğretir; ancak üretimde güvenlik için test edilmiş kütüphanelere güvenmek en akıllıca hamledir.

Go bu iş için çok uygundur çünkü goroutine’ler hafiftir. Her URL için dev bir işletim sistemi thread’i açmak yerine, Go runtime binlerce işi verimli biçimde planlar. Channel’lar ise URL kuyruğu, sonuç akışı ve hata bildirimleri için temiz bir iletişim modeli sağlar.

Aşağıdaki örnekte kontrollü bir worker pool kuruyoruz. Amaç, URL listesini channel üzerinden worker’lara dağıtmak ve her sayfanın HTML uzunluğunu örnek olarak toplamaktır. Gerçek projede burada başlık, meta açıklama, ürün fiyatı veya linkler ayrıştırılabilir.

package main

import (
    "fmt"
    "io"
    "net/http"
    "sync"
    "time"
)

type Result struct {
    URL    string
    Length int
    Err    error
}

func fetch(client *http.Client, url string) Result {
    resp, err := client.Get(url)
    if err != nil {
        return Result{URL: url, Err: err}
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return Result{URL: url, Err: err}
    }

    return Result{URL: url, Length: len(body)}
}

func worker(id int, client *http.Client, jobs <-chan string, results chan<- Result, wg *sync.WaitGroup) {
    defer wg.Done()
    for url := range jobs {
        fmt.Println("Worker", id, "işliyor:", url)
        results <- fetch(client, url)
    }
}

func main() {
    urls := []string{
        "https://example.com",
        "https://go.dev",
        "https://pkg.go.dev",
    }

    client := &http.Client{Timeout: 8 * time.Second}
    jobs := make(chan string)
    results := make(chan Result)

    var wg sync.WaitGroup
    workerCount := 3

    for i := 1; i <= workerCount; i++ {
        wg.Add(1)
        go worker(i, client, jobs, results, &wg)
    }

    go func() {
        for _, url := range urls {
            jobs <- url
        }
        close(jobs)
        wg.Wait()
        close(results)
    }()

    for r := range results {
        if r.Err != nil {
            fmt.Println("Hata:", r.URL, r.Err)
            continue
        }
        fmt.Println(r.URL, "boyut:", r.Length)
    }
}

Kodda http.Client için timeout vermek küçük ama hayati bir ayrıntıdır. Timeout yoksa bir istek sonsuza kadar asılı kalabilir ve scraper’ınız kahve molasından dönmeyen stajyer gibi ortadan kaybolur. workerCount değeri ise hız ile nezaket arasındaki dengedir. Çok düşük olursa yavaş kalırsınız, çok yüksek olursa hedef site sizi engelleyebilir.

HTML ayrıştırmak için standart kütüphane yeterli olmayabilir. Go ekosisteminde goquery, jQuery benzeri seçicilerle pratik bir çözüm sunar. Örneğin h1, .price, a[href] gibi seçicilerle veri çekilebilir. Fakat dinamik olarak JavaScript ile oluşan sayfalarda klasik HTTP isteği yetmez; bu durumda tarayıcı otomasyonu veya API keşfi gerekir.

Sonuç olarak Go ile scraper yazmak sadece hızlı istek göndermek değildir; küçük bir dağıtık sistem tasarlamaktır. Kuyruklar, worker’lar, timeout’lar ve hata yönetimi bir araya geldiğinde saniyeler içinde binlerce sayfayı gezebilen sağlam bir indeksleyici ortaya çıkar. Hız güzel, ama kontrollü hız daha güzeldir.

Socket Mantığı: HTTP’den Farkı Ne?

Klasik HTTP modelinde tarayıcı sunucuya istek atar, sunucu cevap verir ve bağlantı kapanır. Bu model forum sayfası yüklemek için harikadır; fakat “yeni mesaj var mı?” sorusunu her 2 saniyede bir sormak verimsizdir. Socket yaklaşımında ise bağlantı açık kalır. Sunucu, olay oluştuğunda istemciye kendisi veri gönderir.

Basit gecikme fikrini şöyle düşünebiliriz: $latency = t_{receive} - t_{send}$. Canlı bildirimlerde hedef bu değeri olabildiğince küçük tutmaktır. Polling’de bu süre istek aralığına bağlıyken, WebSocket’te olay gerçekleştiği anda veri kanala yazılır.

Temel Mimari

Canlı bildirim sisteminde genellikle üç ana parça vardır: istemci, socket sunucusu ve veri kaynağı. Kullanıcı yeni mesaj gönderdiğinde önce API veya socket sunucusu bu olayı alır. Ardından ilgili odaya, kullanıcıya veya gruba bildirim yayılır. Buradaki kritik kavram “room” yani odadır. Örneğin forumdaki her konu bir oda olabilir.

Bu ifade bize ölçekleme baskısını hatırlatır. 10 kullanıcıda çalışan sistem, 10.000 kullanıcıda bağlantı, bellek ve yayın stratejisi ister.

Sunucu Tarafı: Socket.IO ile Başlangıç

Aşağıdaki örnekte Node.js ve Socket.IO kullanıyoruz. Kodun görevi, kullanıcıyı ilgili forum konusunun odasına almak ve yeni cevap geldiğinde sadece o odaya bildirim göndermek.

import { Server } from 'socket.io';
import http from 'http';

const server = http.createServer();
const io = new Server(server, {
  cors: {
    origin: 'http://localhost:3000'
  }
});

io.on('connection', (socket) => {
  console.log('Bağlandı:', socket.id);

  socket.on('forum:join', ({ topicId, userId }) => {
    socket.join(`topic:${topicId}`);
    socket.data.userId = userId;
  });

  socket.on('forum:new-reply', ({ topicId, message, author }) => {
    io.to(`topic:${topicId}`).emit('notification:new', {
      type: 'reply',
      topicId,
      message,
      author,
      sentAt: Date.now()
    });
  });

  socket.on('disconnect', () => {
    console.log('Ayrıldı:', socket.id);
  });
});

server.listen(4000);

Burada forum:join istemcinin hangi konuyu dinleyeceğini belirler. forum:new-reply ise yeni cevap olayını alır ve sadece topic:123 gibi ilgili odaya yayın yapar. Böylece herkes her bildirimi almaz; sistem daha temiz ve ekonomik çalışır.

İstemci Tarafı: Dinleme ve Yeniden Bağlanma

Tarayıcı tarafında bağlantı kurar, odaya katılır ve bildirim olaylarını dinleriz. Bağlantı koparsa Socket.IO otomatik yeniden bağlanmayı destekler; yine de kullanıcı deneyimi için durum bilgisini göstermek akıllıcadır.

import { io } from 'socket.io-client';

const socket = io('http://localhost:4000', {
  transports: ['websocket'],
  reconnectionAttempts: 5,
  reconnectionDelay: 1000
});

socket.on('connect', () => {
  console.log('Canlı kanal açık');
  socket.emit('forum:join', { topicId: 42, userId: 7 });
});

socket.on('notification:new', (payload) => {
  console.log('Yeni bildirim:', payload.message);
  showToast(`${payload.author}: ${payload.message}`);
});

socket.on('disconnect', () => {
  console.log('Bağlantı koptu, tekrar deneniyor...');
});

function showToast(text) {
  const div = document.createElement('div');
  div.textContent = text;
  div.className = 'toast';
  document.body.appendChild(div);
  setTimeout(() => div.remove(), 4000);
}

Bu yapı sayesinde kullanıcı forum konusunu açık tutarken yeni cevapları anında görür. Mesajlaşma platformunda da aynı mantık room:${conversationId} ile uygulanabilir.

Güvenlik ve Performans İpuçları

Socket bağlantısı açık diye her olaya güvenmemeliyiz. Kullanıcının gerçekten ilgili odaya erişim yetkisi var mı, sunucuda kontrol edilmelidir. Ayrıca olay adlarını standartlaştırmak, payload boyutunu küçük tutmak ve gereksiz yayınlardan kaçınmak gerekir.

Özetle dinamik socket iletişimi, modern web uygulamalarının nabzıdır. Doğru oda modeli, güvenli kimlik doğrulama ve kontrollü yayın stratejisiyle forumlar, sohbetler ve bildirim panelleri gerçekten canlı hissettirilir.

Küçük bir matematiksel sezgiyle API yükünü şöyle düşünebiliriz: Toplam istek maliyeti $T = n \times c$ olsun. Burada $n$ istek sayısı, $c$ ise her isteğin ortalama maliyetidir. Gereksiz büyük yanıtlar veya kötü sorgular $c$ değerini büyütür; sayfalama, filtreleme ve indeksli veritabanı sorguları ise API’yi hızlandırır.

Standart yanıt yapısı API’nin farklı platformlarda tahmin edilebilir olmasını sağlar. Örneğin her cevapta success, data, message ve errors alanlarını kullanmak, istemci tarafındaki kodu sadeleştirir. Başarılı listeleme için durum kodu $200$, kayıt oluşturma için $201$, yetkisiz erişim için $401$, bulunamayan kaynak için $404$ tercih edilir.

Aşağıdaki örnek, basit ama düzenli bir PHP API iskeleti gösterir. PDO ile hazırlanmış sorgular SQL injection riskini azaltır, json_response fonksiyonu ise tüm çıktıları tek biçime sokar.

<?php
header('Content-Type: application/json; charset=utf-8');

$pdo = new PDO(
    'mysql:host=localhost;dbname=app;charset=utf8mb4',
    'api_user',
    'secret_password',
    [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
);

function json_response($status, $success, $data = null, $message = '', $errors = []) {
    http_response_code($status);
    echo json_encode([
        'success' => $success,
        'data' => $data,
        'message' => $message,
        'errors' => $errors
    ], JSON_UNESCAPED_UNICODE);
    exit;
}

$method = $_SERVER['REQUEST_METHOD'];
$path = trim(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH), '/');
$parts = explode('/', $path);

if ($parts[0] !== 'api' || $parts[1] !== 'users') {
    json_response(404, false, null, 'Kaynak bulunamadı');
}

if ($method === 'GET') {
    $stmt = $pdo->query('SELECT id, name, email FROM users ORDER BY id DESC LIMIT 20');
    json_response(200, true, $stmt->fetchAll(PDO::FETCH_ASSOC), 'Kullanıcılar listelendi');
}

json_response(405, false, null, 'Bu metod desteklenmiyor');

Bu kodun yaptığı şey basit: Gelen isteğin metodunu ve yolunu okur, /api/users kaynağına gelen GET isteklerinde kullanıcıları JSON olarak döndürür. Gerçek projede bu yönlendirme mantığını ayrı bir router sınıfına almak, controller katmanı eklemek ve veritabanı işlemlerini repository yapısına taşımak daha sürdürülebilir olur.

Güvenlik tarafında en kritik konu kimlik doğrulamadır. Oturum tabanlı klasik yaklaşım yerine API’lerde genellikle token kullanılır. Kullanıcı giriş yapınca bir erişim token’ı alır ve sonraki isteklerde Authorization: Bearer TOKEN başlığıyla gönderir. Token doğrulanmadan hassas kaynaklara erişim verilmemelidir.

Basit bir token kontrolü şöyle kurgulanabilir:

function require_token() {
    $headers = getallheaders();
    $auth = $headers['Authorization'] ?? '';

    if (!str_starts_with($auth, 'Bearer ')) {
        json_response(401, false, null, 'Token eksik');
    }

    $token = substr($auth, 7);
    if ($token !== 'demo-secure-token') {
        json_response(403, false, null, 'Token geçersiz');
    }
}

Elbette canlı sistemde sabit token kullanılmaz; JWT, OAuth2 veya veritabanında saklanan süreli erişim anahtarları tercih edilir. Ayrıca API sürümleme unutulmamalıdır: /api/v1/users gibi bir yapı, ileride kırıcı değişiklikleri yönetmeyi kolaylaştırır.

Sonuç olarak PHP ile RESTful API tasarlamak, yalnızca birkaç endpoint yazmak değildir. Kaynak modelleme, HTTP semantiği, güvenlik, hata standardı ve performans bir araya geldiğinde platform bağımsız, güvenilir ve keyifli bir veri köprüsü ortaya çıkar. Doğru kuralları koyarsanız, cihazlarınız aynı veritabanıyla kavga etmeden konuşur.

Konteyner mantığını anlamak için önce şu fikri netleştirelim: Konteyner, tam bir sanal makine değildir. İşletim sisteminin çekirdeğini paylaşır; fakat dosya sistemi, ağ, süreçler ve ortam değişkenleri açısından izole davranır. Bu yüzden hızlı başlar, az kaynak tüketir ve taşınabilirdir. Basitçe kaynak maliyetini şöyle düşünebiliriz: $M_{toplam}=M_{imaj}+M_{runtime}+M_{veri}$. Sanal makinelerde buna çoğu zaman ayrı bir işletim sistemi maliyeti de eklenir.

Python tarafında en yaygın yaklaşım Docker Engine API ile konuşmaktır. Docker aslında arka planda bir HTTP API sunar; docker komutu da bu API’ye istek atan bir istemcidir. Python’da docker SDK kullanarak bu API’ye zarifçe bağlanırız. Böylece uygulama konteyneri, PostgreSQL konteyneri, test veritabanı veya geçici worker süreçleri kodla yönetilebilir.

import docker

client = docker.from_env()

container = client.containers.run(
    'nginx:alpine',
    name='mini-web',
    ports={'80/tcp': 8080},
    detach=True
)

print('Konteyner başladı:', container.id[:12])

Bu kod, yerel Docker ortamına bağlanır, nginx:alpine imajından bir konteyner başlatır ve konteynerin 80 portunu makinedeki 8080 portuna bağlar. detach=True, sürecin arka planda çalışmasını sağlar. Buradaki kritik düşünce şudur: Python kodu artık altyapıyı tarif eden küçük bir otomasyon robotudur.

Veritabanı senaryosu daha da ilginçtir. Diyelim ki her test çalışmasında temiz bir PostgreSQL istiyorsunuz. Konteyner API’siyle test başlamadan veritabanını ayağa kaldırır, test bitince yok edersiniz. Bu yaklaşım özellikle CI/CD hatlarında çok değerlidir.

import docker
import time

client = docker.from_env()

db = client.containers.run(
    'postgres:16-alpine',
    name='test-postgres',
    environment={
        'POSTGRES_PASSWORD': 'secret',
        'POSTGRES_DB': 'appdb'
    },
    ports={'5432/tcp': 55432},
    detach=True,
    remove=True
)

time.sleep(5)
print('Test veritabanı hazır:', db.name)

Burada environment parametresi konteyner içindeki ortam değişkenlerini belirler. remove=True, konteyner durunca otomatik temizlenmesini sağlar. Elbette gerçek projede sleep yerine sağlık kontrolü yapmak daha doğru olur; çünkü veritabanının hazır olma süresi makineye göre değişebilir.

Konteyner yönetiminde yaşam döngüsü genellikle şu adımlardan oluşur:

Kaynak tüketimini izlemek de otomasyonun önemli parçasıdır. Örneğin bir konteynerin CPU kullanımını yaklaşık olarak $CPU\%=\frac{container_delta}{system_delta}\times cores\times100$ mantığıyla yorumlarız. Docker SDK, ham istatistikleri verir; siz bu verilerden alarm, rapor veya otomatik ölçekleme kararları üretebilirsiniz.

container = client.containers.get('mini-web')

for line in container.logs(stream=True, tail=5):
    print(line.decode('utf-8').strip())

Bu örnek, çalışan bir konteynerin loglarını akış halinde okur. Log okuma; hata ayıklama, canlı izleme ve otomatik analiz için temel bir tekniktir. Bir uygulama 500 hatası üretmeye başladığında Python betiğiniz bunu yakalayıp Slack mesajı atabilir, yeni konteyner başlatabilir veya sorunlu olanı yeniden başlatabilir.

Tabii güç arttıkça sorumluluk da artar. Konteyner API’lerine erişen Python kodu, sistemde ciddi yetkilere sahip olabilir. Bu yüzden socket erişimini sınırlamak, gizli bilgileri koda gömmemek, imajları güvenilir kaynaklardan çekmek ve ağ yapılandırmasını bilinçli yapmak gerekir.

Sonuç olarak Python ile konteyner yönetimi API’leri, uygulama ve veritabanlarını küçük sanal odalara yerleştirip bu odaların ışığını, kapısını, havalandırmasını kodla kontrol etmeye benzer. Geliştirme ortamı kurma, entegrasyon testi, geçici servis çalıştırma ve mini DevOps otomasyonları için oldukça güçlü bir yaklaşımdır. Birkaç satır Python ile altyapıya dokunmak hem pratik hem de biraz sihirli hissettirir.

Temel Mantık

Cron’u bir çalar saat, Python scriptini de o alarm çalınca mutfağa gidip kahve yapan robot gibi düşünebiliriz. Cron sadece zamanı bilir; işin detayını Python yapar. Matematiksel olarak periyodik bir görevi şöyle ifade edebiliriz: $T = n \times \Delta t$. Burada $\Delta t$ çalıştırma aralığı, $n$ tekrar sayısıdır. Örneğin 24 saat boyunca her 1 saatte bir çalışan görev için $T = 24 \times 1$ olur.

Raporlama tarafında ise genellikle bir özet değer hesaplarız. Örneğin günlük toplam satış: $R = \sum_{i=1}^{n} tutar_i$. Python bu toplamı API’den gelen JSON verisi üzerinden kolayca çıkarabilir.

Python ile API’den Veri Çekme

Aşağıdaki örnek, sahte bir satış API’sinden veri çeker, toplam satış miktarını hesaplar ve günlük raporu CSV dosyasına yazar. Gerçek projelerde API anahtarını doğrudan koda yazmak yerine ortam değişkeni kullanmak daha güvenlidir.

import csv
import os
from datetime import datetime
import requests

API_URL = 'https://api.example.com/sales'
API_KEY = os.getenv('SALES_API_KEY')

headers = {
    'Authorization': f'Bearer {API_KEY}'
}

response = requests.get(API_URL, headers=headers, timeout=20)
response.raise_for_status()

data = response.json()
items = data.get('sales', [])

total_amount = sum(item.get('amount', 0) for item in items)
report_date = datetime.now().strftime('%Y-%m-%d')

with open(f'report_{report_date}.csv', 'w', newline='') as file:
    writer = csv.writer(file)
    writer.writerow(['date', 'sale_count', 'total_amount'])
    writer.writerow([report_date, len(items), total_amount])

print(f'Rapor hazır: {report_date}, toplam: {total_amount}')

Bu kodda requests.get API çağrısını yapar, response.raise_for_status hatalı HTTP durumlarında scriptin sessizce devam etmesini engeller. sum fonksiyonu ise gelen kayıtların amount alanlarını toplar. Yani küçük ama işlevsel bir raporlama hattı kurmuş oluruz.

Cron İfadesini Okumak

Cron satırları beş zaman alanı ve bir komuttan oluşur:

# dakika saat gün ay haftanın_günü komut
0 9 * * * /usr/bin/python3 /home/app/reports/daily_report.py

Bu örnek her gün saat 09:00’da scripti çalıştırır. Yıldız karakteri tüm değerler anlamına gelir. Yani gün, ay ve haftanın günü fark etmez.

Cron ayarlamak için terminalde şu komutu kullanabilirsiniz:

crontab -e

Ardından cron satırınızı ekleyip kaydedersiniz. Scriptin çalıştığından emin olmak için log yönlendirmesi yapmak akıllıca olur:

0 9 * * * /usr/bin/python3 /home/app/reports/daily_report.py >> /home/app/logs/report.log 2>&1

Buradaki >> çıktıyı log dosyasına ekler, 2>&1 ise hata mesajlarını da aynı dosyaya gönderir. Böylece sorun çıktığında dedektif gibi terminal geçmişi aramak zorunda kalmazsınız.

Dikkat Edilmesi Gerekenler

Sonuç olarak Python ve cronjobs, düşük maliyetli ama güçlü bir otomasyon altyapısı sunar. Büyük bir veri platformu kurmadan önce, basit bir script ve iyi ayarlanmış bir cron satırıyla günlük raporlarınızı otomatikleştirebilirsiniz. Küçük başlar, loglarınızı izler, hata yönetimini güçlendirirseniz bu yapı zamanla güvenilir bir mini veri operasyonuna dönüşür.