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.

Neden LIKE Yetmez?

Klasik arama genellikle şöyle başlar:

SELECT *
FROM posts
WHERE content LIKE '%veritabanı%';

Bu sorgu küçük tabloda sevimlidir, ama milyon satırlık forumda kahve molası ister. Çünkü başında joker karakter olan %kelime% ifadesi çoğu durumda normal indeksi verimli kullanamaz. Veritabanı satır satır gezip metnin içinde kelime arar. Bu işlem yaklaşık olarak $O(n)$ maliyetlidir; yani veri büyüdükçe bekleme süresi de büyür.

Tam metin arama ise metni önceden parçalar, kelimeleri işler ve ters indeks denilen bir yapı kurar. Ters indeks mantığı basittir: kelimeden belgeye giden bir harita oluşturulur. Yani veritabanı artık belge içinde kelime aramaz; kelimenin geçtiği belgeleri doğrudan bulur.

Arama Motoru Mantığının Temeli

Tam metin aramada ilk adım tokenization, yani metni anlamlı parçalara ayırmaktır. Örneğin Kullanıcılar hızlı arama istiyor cümlesi kullanıcılar, hızlı, arama, istiyor gibi kelimelere bölünür. Ardından stop word temizliği yapılabilir. Türkçede ve, ile, bir gibi çok sık geçen ama anlam değeri düşük kelimeler atılabilir.

Sonra stemming veya lemmatization devreye girer. Amaç arama, aramak, arandı gibi varyasyonları ortak köke yaklaştırmaktır. PostgreSQL gibi sistemlerde dil yapılandırması bu yüzden önemlidir.

Alaka puanı genellikle kelime sıklığına ve nadirliğine dayanır. Basit bir model şöyle düşünülebilir:

$score = tf * log(N / df)$

Burada $tf$ kelimenin ilgili belgede kaç kez geçtiğini, $N$ toplam belge sayısını, $df$ ise kelimenin kaç belgede bulunduğunu gösterir. Yani nadir ama aranan kelimeler daha değerli hale gelir. Forumda veritabanı kelimesi binlerce kez geçebilir, ama gin index daha az yerde geçiyorsa daha ayırt edici olabilir.

PostgreSQL ile Örnek Kurgu

PostgreSQL, tam metin arama konusunda oldukça güçlüdür. tsvector metnin indekslenmiş halini, tsquery ise arama ifadesini temsil eder.

CREATE TABLE posts (
    id SERIAL PRIMARY KEY,
    title TEXT NOT NULL,
    content TEXT NOT NULL,
    search_vector TSVECTOR
);

Bu tabloda search_vector, başlık ve içerikten üretilmiş arama alanı olarak kullanılabilir. Başlığa daha fazla ağırlık vermek de mümkündür:

UPDATE posts
SET search_vector =
    setweight(to_tsvector('turkish', title), 'A') ||
    setweight(to_tsvector('turkish', content), 'B');

Burada başlık A ağırlığında, içerik B ağırlığında değerlendirilir. Böylece aranan kelime başlıkta geçiyorsa sonuç daha yukarı çıkabilir. Arama için ise şöyle bir sorgu yazılabilir:

SELECT id, title,
       ts_rank(search_vector, plainto_tsquery('turkish', 'sql indeks')) AS rank
FROM posts
WHERE search_vector @@ plainto_tsquery('turkish', 'sql indeks')
ORDER BY rank DESC
LIMIT 10;

Bu sorgu, kullanıcının yazdığı ifadeyi arama sorgusuna dönüştürür, eşleşen kayıtları bulur ve alaka puanına göre sıralar. Yani artık sadece bulmakla kalmayız; en mantıklı sonuçları en üste taşırız.

Performans için GIN indeksi eklemek gerekir:

CREATE INDEX posts_search_idx
ON posts
USING GIN (search_vector);

GIN indeksi, çok değerli metin alanları için ters indeks mantığını verimli uygular. Büyük forumlarda fark dramatik olabilir.

MySQL ve Diğerleri

MySQL tarafında da FULLTEXT indeksi kullanılabilir:

ALTER TABLE posts
ADD FULLTEXT INDEX post_fulltext_idx (title, content);

SELECT id, title,
       MATCH(title, content) AGAINST('sql indeks' IN NATURAL LANGUAGE MODE) AS score
FROM posts
WHERE MATCH(title, content) AGAINST('sql indeks' IN NATURAL LANGUAGE MODE)
ORDER BY score DESC;

Pratik Tasarım İpuçları

Tam metin aramayı gerçek bir üründe kullanırken başlık, etiket ve içerik aynı öneme sahip olmamalıdır. Başlıkta geçen kelime genellikle daha değerlidir. Ayrıca arama kutusuna yazılan metni doğrudan karmaşık sorguya çevirmek yerine güvenli fonksiyonlar kullanmak gerekir.

Bir diğer önemli konu güncellemedir. Yazı değiştiğinde search_vector da güncellenmelidir. Bunun için trigger kullanılabilir veya uygulama katmanında kayıt güncellenirken arama alanı da yeniden oluşturulabilir.

Sonuç olarak SQL ile tam metin arama, küçük bir özellik gibi görünse de kullanıcı deneyimini doğrudan değiştirir. Doğru indeks, doğru ağırlıklandırma ve iyi bir alaka puanı ile forumunuz artık dev bir metin çöplüğü değil, kullanıcıların aradığını hızla bulduğu akıllı bir bilgi haritası olur.

C++ ile çalışırken kritik soru şudur: Bu matematiksel ifadeleri bellekte nasıl temsil edeceğiz? Çünkü CPU, veriye hızlı erişirse hesaplama da hızlanır. Dağınık std::vector<std::vector<float>> yapıları okunabilir olsa da satırlar bellekte parçalı durabilir. Tek boyutlu, ardışık bir dizi ise cache dostudur.

Bir matrisi tek boyutlu sakladığımızda $W_{ij}$ elemanına erişim formülü şöyledir: $index = i \times cols + j$. Bu küçük formül, C++ tarafında büyük performans farkları yaratabilir.

#include <vector>
#include <cmath>

struct DenseLayer {
    int in, out;
    std::vector<float> W;
    std::vector<float> b;

    DenseLayer(int input, int output)
        : in(input), out(output), W(input * output), b(output) {}

    std::vector<float> forward(const std::vector<float>& x) const {
        std::vector<float> y(out, 0.0f);

        for (int i = 0; i < out; ++i) {
            float sum = b[i];
            const int row = i * in;
            for (int j = 0; j < in; ++j) {
                sum += W[row + j] * x[j];
            }
            y[i] = std::tanh(sum); // aktivasyon
        }
        return y;
    }
};

Bu kodda W matrisi tek boyutlu tutulur. row + j erişimi, satırdaki elemanları ardışık okuduğu için işlemci önbelleğiyle iyi anlaşır. Yani CPU’ya “al bakalım, sıradaki veriler tam yanında” demiş oluruz. Bu da özellikle büyük katmanlarda önemlidir.

Öğrenme aşamasında geri yayılım devreye girer. Temel fikir zincir kuralıdır: $\frac{\partial L}{\partial W} = \frac{\partial L}{\partial y} \cdot \frac{\partial y}{\partial W}$. Ardından ağırlıklar şu şekilde güncellenir: $W := W - \eta \frac{\partial L}{\partial W}$. Buradaki $\eta$ öğrenme oranıdır; çok büyükse model zıplar, çok küçükse kaplumbağa gibi ilerler.

Performans için dikkat edilmesi gerekenlerden biri gereksiz kopyalardır. Büyük vektörleri fonksiyonlara değer ile geçirmek yerine const reference kullanmak gerekir. Ayrıca eğitim döngüsünde sürekli yeni bellek ayırmak pahalıdır; mümkünse buffer’lar önceden oluşturulmalı ve tekrar kullanılmalıdır.

Daha ileri seviyede alignas(64), SIMD komutları, OpenMP veya BLAS kütüphaneleri kullanılabilir. Ancak temeli anlamadan bu araçlara atlamak, turbo motoru bisiklete takmaya benzer. Önce veri yerleşimi, döngü sırası ve matematiksel akış net olmalıdır.

C++ ile sinir ağı yazmak, hazır kütüphane kullanmaya göre daha zahmetlidir; fakat karşılığında modelin kalp atışını duyarsınız. Her çarpım, her toplama, her bellek erişimi sizin kontrolünüzdedir. İşte bu yüzden C++, yapay sinir ağlarını yalnızca kullanmak değil, gerçekten anlamak isteyenler için harika bir laboratuvardır.

Ters proxy, istemcinin gerçek uygulama sunucularıyla doğrudan konuşmasını engelleyen aracı katmandır. İstemci api.ornek.com adresine istek atar; ters proxy bu isteği arkadaki service-1, service-2 veya service-3 gibi sunuculara iletir. Böylece güvenlik, gözlemlenebilirlik, önbellekleme, TLS sonlandırma ve yük dengeleme tek noktadan yönetilebilir.

Temel farkı şöyle özetleyebiliriz:

Yük dengelemenin mantığı ise basit ama kritiktir. Elimizde $n$ adet backend varsa ve gelen toplam istek sayısı $R$ ise ideal durumda her sunucunun yaklaşık yükü şu olur: $R_i \approx \frac{R}{n}$. Gerçekte CPU, bellek, ağ gecikmesi ve hata oranları farklı olduğundan bu dağılım her zaman eşit değildir. Bu yüzden round-robin, weighted round-robin veya least-connections gibi algoritmalar kullanılır.

Go’da en yalın ters proxy örneği httputil.NewSingleHostReverseProxy ile yazılabilir. Aşağıdaki kod, gelen isteği tek bir backend’e aktarır; ayrıca X-Forwarded-Host başlığıyla orijinal host bilgisini korur.

package main

import (
    "log"
    "net/http"
    "net/http/httputil"
    "net/url"
)

func main() {
    target, err := url.Parse("http://localhost:8081")
    if err != nil {
        log.Fatal(err)
    }

    proxy := httputil.NewSingleHostReverseProxy(target)

    originalDirector := proxy.Director
    proxy.Director = func(req *http.Request) {
        originalDirector(req)
        req.Header.Set("X-Forwarded-Host", req.Host)
        req.Header.Set("X-Gateway", "go-reverse-proxy")
    }

    log.Println("Proxy :8080 üzerinde çalışıyor")
    log.Fatal(http.ListenAndServe(":8080", proxy))
}

Bu kodda Director, isteğin backend’e gitmeden önce nasıl değiştirileceğini belirler. Örneğin path yeniden yazılabilir, header eklenebilir veya belirli istekler engellenebilir. Pratikte burada kimlik doğrulama, IP filtreleme ya da rate limit kontrolü de uygulanabilir.

Şimdi bunu küçük bir round-robin yük dengeleyiciye çevirelim:

package main

import (
    "log"
    "net/http"
    "net/http/httputil"
    "net/url"
    "sync/atomic"
)

type Backend struct {
    URL   *url.URL
    Proxy *httputil.ReverseProxy
}

type LoadBalancer struct {
    backends []Backend
    counter  uint64
}

func (lb *LoadBalancer) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    index := atomic.AddUint64(&lb.counter, 1) % uint64(len(lb.backends))
    backend := lb.backends[index]
    r.Header.Set("X-Selected-Backend", backend.URL.String())
    backend.Proxy.ServeHTTP(w, r)
}

func main() {
    addresses := []string{
        "http://localhost:8081",
        "http://localhost:8082",
        "http://localhost:8083",
    }

    lb := &LoadBalancer{}
    for _, addr := range addresses {
        u, err := url.Parse(addr)
        if err != nil {
            log.Fatal(err)
        }
        lb.backends = append(lb.backends, Backend{
            URL:   u,
            Proxy: httputil.NewSingleHostReverseProxy(u),
        })
    }

    log.Println("Load balancer :8080 üzerinde hazır")
    log.Fatal(http.ListenAndServe(":8080", lb))
}

Burada atomic.AddUint64, eşzamanlı isteklerde sayaç yarışını engeller. Her istek farklı backend’e gönderilir. Matematiksel olarak seçim index = counter \bmod n şeklindedir. Yani sayaç büyür, backend listesi döngüsel biçimde kullanılır.

Güvenlik tarafında birkaç noktayı atlamamak gerekir. Proxy’niz dış dünyaya açık olduğu için header spoofing, yavaş istek saldırıları ve büyük body gönderimleriyle karşılaşabilir. http.Server yapılandırmasında timeout değerleri vermek iyi bir başlangıçtır.

server := &http.Server{
    Addr:              ":8080",
    Handler:           lb,
    ReadHeaderTimeout: 5 * time.Second,
    ReadTimeout:       10 * time.Second,
    WriteTimeout:      15 * time.Second,
    IdleTimeout:       60 * time.Second,
}

Sonuç olarak Go, ters proxy yazmak için şaşırtıcı derecede güçlü bir araçtır. Küçük bir kod tabanıyla trafik yönlendirme, servis gizleme ve basit yük dengeleme yapabilirsiniz. Üretim ortamında buna health check, loglama, metrik toplama, TLS ve circuit breaker eklediğinizde kendi mini API gateway’inizi inşa etmiş olursunuz. Kısacası: Go ile ağ geçidi yazmak, hem öğretici hem de oldukça keyifli bir mühendislik egzersizidir.