``

Genetik algoritmanın temel fikri şudur: Elimizde bir popülasyon vardır. Popülasyondaki her birey, olası bir çözümü temsil eder. Bu bireylere çoğu zaman kromozom denir. Kromozom; bit dizisi, sayı vektörü, rota listesi veya başka bir veri yapısı olabilir. Her kromozomun başarısı bir uygunluk fonksiyonu ile ölçülür. Amaç, uygunluğu yüksek bireyleri seçip melezlemek ve zamanla daha iyi çözümler üretmektir.

Matematiksel olarak bir optimizasyon probleminde amaç genellikle şu biçimdedir:

Burada $S$ çözüm uzayı, $x$ aday çözüm, $f(x)$ ise uygunluk değeridir. Genetik algoritma, $S$ içinde tek tek tüm noktaları gezmek yerine “umut vadeden bölgeleri” keşfetmeye çalışır. Biraz dedektif, biraz çiftçi, biraz da çılgın bilim insanı gibi davranır.

Basit bir örnek düşünelim: 0 ve 1’lerden oluşan 20 bitlik bir dizide mümkün olduğunca çok 1 elde etmek istiyoruz. Bu, eğitim amaçlı “OneMax” problemidir. Uygunluk fonksiyonu, kromozomdaki 1 sayısıdır. Yani $f(x)=\sum x_i$. Kulağa kolay geliyor ama aynı yapı, daha zor problemlerde rota optimizasyonu, çizelgeleme veya parametre ayarlama için de kullanılabilir.

Aşağıdaki C++ kodu orta düzey bir iskelet sunar. Popülasyon oluşturur, uygunluk hesaplar, turnuva seçimi yapar, çaprazlama ve mutasyon uygular:

#include <bits/stdc++.h>
using namespace std;

const int GENE_LENGTH = 20;
const int POP_SIZE = 50;
const int GENERATIONS = 100;
const double MUTATION_RATE = 0.02;

mt19937 rng(random_device{}());

using Chromosome = vector<int>;

int fitness(const Chromosome& c) {
    return accumulate(c.begin(), c.end(), 0);
}

Chromosome randomChromosome() {
    uniform_int_distribution<int> bit(0, 1);
    Chromosome c(GENE_LENGTH);
    for (int& gene : c) gene = bit(rng);
    return c;
}

Chromosome tournamentSelect(const vector<Chromosome>& pop) {
    uniform_int_distribution<int> dist(0, POP_SIZE - 1);
    Chromosome a = pop[dist(rng)];
    Chromosome b = pop[dist(rng)];
    return fitness(a) > fitness(b) ? a : b;
}

Chromosome crossover(const Chromosome& p1, const Chromosome& p2) {
    uniform_int_distribution<int> pointDist(1, GENE_LENGTH - 2);
    int point = pointDist(rng);
    Chromosome child(GENE_LENGTH);
    for (int i = 0; i < GENE_LENGTH; i++)
        child[i] = (i < point) ? p1[i] : p2[i];
    return child;
}

void mutate(Chromosome& c) {
    uniform_real_distribution<double> prob(0.0, 1.0);
    for (int& gene : c)
        if (prob(rng) < MUTATION_RATE) gene = 1 - gene;
}

Bu parçalar ana döngüde birleştirilir: Eski popülasyondan ebeveyn seçilir, çocuk üretilir, mutasyon uygulanır ve yeni nesil oluşturulur. Her nesilde en iyi bireyi izlemek, algoritmanın gerçekten evrimleşip evrimleşmediğini görmemizi sağlar.

Genetik algoritmalarda sihirli tek bir ayar yoktur. Mutasyon oranı çok düşükse popülasyon birbirine benzer hale gelir; çok yüksekse öğrenilmiş iyi özellikler sürekli bozulur. Bu denge, keşif ve sömürü arasındaki klasik optimizasyon dansıdır. Keşif yeni bölgeleri aramak, sömürü ise bulunan iyi bölgeleri iyileştirmektir.

C++ tarafında dikkat edilmesi gereken önemli noktalardan biri kopyalama maliyetidir. Büyük kromozomlarda vector kopyalamak pahalı olabilir; gerekirse referans, taşıma semantiği veya özel veri yapıları kullanılabilir. Ayrıca rastgele sayı üretiminde rand() yerine std::mt19937 tercih etmek daha sağlıklı sonuçlar verir.

Sonuç olarak genetik algoritmalar, kesin cevabı garanti eden sihirli değnekler değildir; ama karmaşık ve geniş arama uzaylarında oldukça pratik sezgisel yöntemlerdir. C++ ile birleştiğinde hızlı deneyler yapabilir, farklı uygunluk fonksiyonları deneyebilir ve algoritmanın küçük dijital canlılar gibi gelişmesini izleyebilirsiniz. Kısacası: Eğer probleminiz “çok fazla seçenek, çok az sabır” diyorsa, evrimi biraz koda dökmenin zamanı gelmiş olabilir.

Gerçek zamanlı sohbetin temelinde HTTP’nin klasik “istek-cevap” modelinden farklı bir yaklaşım vardır. Normal HTTP’de istemci sunucuya sorar, sunucu cevaplar ve bağlantı kapanır. Sohbette ise bağlantının açık kalması, sunucunun da istediği an istemciye mesaj gönderebilmesi gerekir. Bu yüzden WebSocket kullanırız. WebSocket, tek bir TCP bağlantısı üzerinde çift yönlü iletişim sağlar.

Teorik olarak her bağlantı için bir iş parçacığı açmak pahalıdır. Go’nun goroutine modeli bu maliyeti azaltır. Kabaca düşünürsek klasik thread maliyeti $M_t$, goroutine maliyeti $M_g$ olsun. Genellikle $M_g \ll M_t$ olduğu için aynı RAM ile çok daha fazla eşzamanlı bağlantı yönetilebilir. Toplam bellek tüketimini basitçe şöyle düşünebiliriz:

Burada $n$ aktif bağlantı sayısıdır. Ama sadece hafif olmak yetmez; bağlantılar arasında güvenli mesaj aktarımı da gerekir. İşte burada Go kanalları ve merkezi bir “hub” yapısı devreye girer.

Minimal mimarimiz üç parçadan oluşacak: Client, Hub ve WebSocket handler. Client tek bir kullanıcı bağlantısını temsil eder. Hub, gelen mesajları tüm istemcilere dağıtan küçük trafik polisi gibidir.

package main

import (
    "log"
    "net/http"

    "github.com/gorilla/websocket"
)

type Client struct {
    conn *websocket.Conn
    send chan []byte
}

type Hub struct {
    clients    map[*Client]bool
    broadcast  chan []byte
    register   chan *Client
    unregister chan *Client
}

Bu yapıların amacı nettir: clients aktif bağlantıları tutar, broadcast herkese gönderilecek mesajları taşır, register yeni gelenleri ekler, unregister ayrılanları siler. Kanallar sayesinde farklı goroutine’ler aynı veriye doğrudan saldırmaz; mesajlaşarak anlaşır.

Şimdi hub döngüsünü yazalım. Bu döngü sunucunun kalbidir; gelen olaya göre kullanıcı ekler, siler veya mesaj dağıtır.

func (h *Hub) run() {
    for {
        select {
        case client := <-h.register:
            h.clients[client] = true

        case client := <-h.unregister:
            if _, ok := h.clients[client]; ok {
                delete(h.clients, client)
                close(client.send)
            }

        case message := <-h.broadcast:
            for client := range h.clients {
                select {
                case client.send <- message:
                default:
                    close(client.send)
                    delete(h.clients, client)
                }
            }
        }
    }
}

Buradaki default kısmı önemlidir. Eğer bir istemci mesajları okuyamayacak kadar yavaşsa, tüm sistemi kilitlemesine izin vermeyiz. Gerçek zamanlı sistemlerde “en yavaş kullanıcı herkesi bekletmemeli” kuralı altın değerindedir.

WebSocket yükseltmesini yapan handler ise HTTP bağlantısını kalıcı, çift yönlü bir kanala dönüştürür.

var upgrader = websocket.Upgrader{
    CheckOrigin: func(r *http.Request) bool {
        return true
    },
}

func serveWs(hub *Hub, w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println(err)
        return
    }

    client := &Client{conn: conn, send: make(chan []byte, 256)}
    hub.register <- client

    go client.writePump()
    go client.readPump(hub)
}

readPump istemciden gelen mesajları okur ve hub’a yollar. writePump ise hub’dan gelen mesajları istemciye yazar. Okuma ve yazmayı ayrı goroutine’lere bölmek, bağlantının aynı anda hem dinleyip hem konuşabilmesini sağlar.

func (c *Client) readPump(hub *Hub) {
    defer func() {
        hub.unregister <- c
        c.conn.Close()
    }()

    for {
        _, message, err := c.conn.ReadMessage()
        if err != nil {
            break
        }
        hub.broadcast <- message
    }
}

func (c *Client) writePump() {
    defer c.conn.Close()

    for message := range c.send {
        if err := c.conn.WriteMessage(websocket.TextMessage, message); err != nil {
            break
        }
    }
}

Son olarak main fonksiyonu ile sistemi ayağa kaldırırız.

func main() {
    hub := &Hub{
        clients:    make(map[*Client]bool),
        broadcast:  make(chan []byte),
        register:   make(chan *Client),
        unregister: make(chan *Client),
    }

    go hub.run()

    http.HandleFunc("/ws", func(w http.ResponseWriter, r *http.Request) {
        serveWs(hub, w, r)
    })

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

Bu haliyle sunucu minimalisttir ama güçlü bir temel sunar. Üretim ortamında CheckOrigin kontrolünü sıkılaştırmalı, kullanıcı kimlik doğrulaması eklemeli, mesajlara oda bilgisi koymalı ve yatay ölçekleme için Redis Pub/Sub gibi bir ara katman kullanmalısınız. Yine de ana fikir değişmez: WebSocket bağlantıyı açık tutar, goroutine’ler hafif paralellik sağlar, hub ise mesaj trafiğini düzenler. Kısacası Go ile sohbet sunucusu yazmak, az kodla çok bağlantı yönetmenin en keyifli yollarından biridir.

Tarayıcı tabanlı oyunlarda en popüler araçlardan biri HTML5 Canvas’tır. Canvas, piksel piksel çizim yapmamızı sağlayan bir sahne gibidir. JavaScript ise bu sahnedeki oyuncuları, topları, düşmanları ve puanları yöneten yönetmendir.

Bir oyunun kalbi game loop, yani oyun döngüsüdür. Bu döngü genelde üç şey yapar: girdileri okur, oyun durumunu günceller, sonra ekrana çizer. Matematiksel olarak konum güncellemesini şöyle düşünebiliriz: $x_{yeni}=x+vx*dt$. Burada x konum, vx yatay hız, dt ise iki kare arasında geçen zamandır. Retro oyunlarda çoğu zaman bu formül yeterince güçlüdür.

Aşağıdaki örnek, Canvas üzerinde basit bir Pong topu hareketi oluşturur. Kodun amacı topu ekranda sektirmek ve temel oyun döngüsünü göstermektir:

<canvas id='game' width='640' height='360'></canvas>
<script>
const canvas = document.getElementById('game');
const ctx = canvas.getContext('2d');

const ball = {
  x: 320,
  y: 180,
  r: 10,
  vx: 180,
  vy: 140
};

let lastTime = 0;

function update(dt) {
  ball.x += ball.vx * dt;
  ball.y += ball.vy * dt;

  if (ball.x < ball.r || ball.x > canvas.width - ball.r) {
    ball.vx *= -1;
  }

  if (ball.y < ball.r || ball.y > canvas.height - ball.r) {
    ball.vy *= -1;
  }
}

function draw() {
  ctx.fillStyle = '#111';
  ctx.fillRect(0, 0, canvas.width, canvas.height);

  ctx.fillStyle = '#00ff99';
  ctx.beginPath();
  ctx.arc(ball.x, ball.y, ball.r, 0, Math.PI * 2);
  ctx.fill();
}

function loop(time) {
  const dt = (time - lastTime) / 1000;
  lastTime = time;

  update(dt);
  draw();
  requestAnimationFrame(loop);
}

requestAnimationFrame(loop);
</script>

Buradaki önemli detay dt kullanımıdır. Eğer sadece ball.x += 3 yazsaydık, oyun farklı cihazlarda farklı hızlarda çalışabilirdi. dt sayesinde hareket zamana bağlanır. Yani saniyedeki kare sayısı değişse bile oyun daha tutarlı kalır. Basitçe hız formülü $v = mesafe / zaman$ mantığına dayanır.

Çarpışma kontrolü de retro oyunların vazgeçilmezidir. En basit yöntemlerden biri dikdörtgen çarpışmasıdır. İki kutu üst üste biniyorsa çarpışma vardır.

Klavye kontrolü için tuş durumlarını saklamak iyi bir pratiktir. Böylece tek tek “tuşa basıldı” olayına bağlı kalmak yerine, her karede mevcut durumu okuyabiliriz:

const keys = {};
const player = { x: 40, y: 150, w: 12, h: 60, speed: 240 };

document.addEventListener('keydown', e => keys[e.key] = true);
document.addEventListener('keyup', e => keys[e.key] = false);

function updatePlayer(dt) {
  if (keys['ArrowUp']) player.y -= player.speed * dt;
  if (keys['ArrowDown']) player.y += player.speed * dt;

  player.y = Math.max(0, Math.min(360 - player.h, player.y));
}

Bu yapı, oyuncunun paddle’ını yukarı-aşağı hareket ettirir ve ekran dışına çıkmasını engeller. Aslında burada küçük bir durum makinesi kurmuş oluruz: tuş basılıysa hareket et, değilse bekle.

Retro hissi artırmak için piksel fontlar, sınırlı renk paleti, basit ses efektleri ve düşük çözünürlüklü görseller kullanabilirsiniz. Önemli olan, oyunu karmaşıklaştırmadan “oynanabilir döngüyü” hızlıca kurmaktır: başlat, oyna, kaybet, tekrar dene.

Sonuç olarak JavaScript ile retro oyun yapmak; değişkenler, fonksiyonlar, döngüler, olaylar, matematik ve durum yönetimi gibi temel konuları tek bir eğlenceli projede birleştirir. Bir topu sektirmekle başlayan yolculuk, kısa sürede kendi Pong’unuza, Snake’inize veya uzay nişancı oyununuza dönüşebilir. Üstelik tek ihtiyacınız olan şey bir tarayıcı, biraz merak ve bolca “bir tur daha” isteği!

MVC Mantığı Nedir?

MVC, Model-View-Controller kelimelerinin kısaltmasıdır. Basit bir denklemle düşünebiliriz: $Uygulama = Veri + Mantık + Arayüz$. MVC bu parçaları birbirinden ayırarak karmaşıklığı azaltır. Yani aynı anda hem SQL yazıp hem HTML basıp hem de kullanıcı yetkisi kontrol etmek yerine, her katmana net bir sorumluluk veririz.

Buradaki kritik fikir sorumluluk ayrımıdır. Bir sınıfın değişmesi için tek bir nedeni olmalıdır. Matematiksel düşünürsek, karmaşıklığı $K$ ile gösterirsek monolitik bir dosyada $K = V * M * C$ gibi büyürken, MVC’de parçalar ayrıldığı için yönetilebilirlik $K = V + M + C$ seviyesine yaklaşır. Elbette bu tam bir bilimsel formül değil; ama zihinde güzel bir alarm yakar: çarpım büyür, toplam daha kolay yönetilir.

Akış Nasıl Çalışır?

Bir kullanıcı /users adresine girdiğinde süreç genellikle şöyledir:

1. Router isteği ilgili Controller metoduna yollar.
2. Controller, Model’den gerekli veriyi ister.
3. Model veritabanı sorgusunu çalıştırır ve sonucu döndürür.
4. Controller sonucu View’e gönderir.
5. View HTML üretir.

Bu akışta Controller patron gibi görünse de aslında “orkestra şefi”dir; kemanı kendi çalmaz, davula kendi vurmaz, sadece doğru parçayı doğru anda çağırır.

Basit Bir PHP MVC Örneği

Aşağıdaki örnekte kullanıcı listesini çeken bir Model, bunu çağıran bir Controller ve View dosyasını yükleyen küçük bir View yardımcı sınıfı görüyoruz. Kodun amacı tam bir framework yazmak değil; MVC fikrini sade biçimde göstermektir.

final class UserModel
{
    public function __construct(private PDO $db) {}

    public function activeUsers(): array
    {
        $stmt = $this->db->prepare('SELECT id, name, email FROM users WHERE active = :active');
        $stmt->execute(['active' => 1]);

        return $stmt->fetchAll(PDO::FETCH_ASSOC);
    }
}

final class UserController
{
    public function __construct(private UserModel $model) {}

    public function index(): void
    {
        $users = $this->model->activeUsers();
        View::render('users/index', ['users' => $users]);
    }
}

final class View
{
    public static function render(string $file, array $data = []): void
    {
        extract($data);
        require __DIR__ . '/views/' . $file . '.php';
    }
}

Burada UserModel sadece veriye odaklanır. SQL sorgusu Controller içinde değildir; bu harika bir şeydir çünkü yarın MySQL yerine başka bir kaynak kullansanız Controller’ın bozulma ihtimali azalır. UserController iş akışını yönetir: kullanıcıları alır ve View’e gönderir. View::render() ise ilgili PHP şablonunu yükler.

Klasik PHP ile MVC Karşılaştırması

Dikkat Edilmesi Gerekenler

MVC kullanırken en yaygın hata, Controller’ı şişirmektir. Controller içine uzun validasyonlar, karmaşık hesaplamalar ve SQL sorguları yazarsanız mimari yine çorbaya döner; sadece adı “MVC çorbası” olur. İş mantığı büyüdüğünde Service katmanı eklemek iyi fikirdir. Örneğin ödeme hesaplama, stok kontrolü veya kampanya kuralları Model ile Controller arasına yerleşen servislerde durabilir.

Ayrıca View dosyalarında mümkün olduğunca az PHP mantığı bulundurun. View’in görevi karar vermek değil, gösterim yapmaktır. if ve foreach makuldür; ancak indirim hesaplama algoritması View içinde yaşıyorsa küçük bir mimari yangın başlamış demektir.

Sonuç

PHP ile MVC mimarisi, projeyi daha profesyonel hale getiren güçlü bir düşünme biçimidir. Veritabanı sorgularını Model’e, kullanıcı arayüzünü View’e, istek akışını Controller’a taşıyarak hem bug bulmayı kolaylaştırır hem de yeni özellik eklemeyi daha güvenli hale getirirsiniz. Küçük projelerde bile bu alışkanlığı kazanmak, büyük projelerde sizi ciddi teknik borçtan kurtarır. Kısacası MVC, PHP dünyasında düzenli masa, etiketli çekmece ve kaybolmayan tornavida etkisi yaratır.

Teorik olarak her soru için bir değerlendirme fonksiyonu vardır. Öğrencinin cevabını $S$, beklenen çıktıyı $E$, üretilen çıktıyı $O$ kabul edelim. Basit bir çıktı karşılaştırmasında puan fonksiyonu şöyle yazılabilir: $score(S)=100$ eğer $O=E$, aksi halde $0$. Daha gelişmiş sistemlerde çoklu test kullanılır: \(score=\frac{passed\_tests}{total\_tests}\times100\) Böylece öğrencinin çözümü bazı durumları doğru ele alıyorsa kısmi puan alabilir.

En küçük auto-grader çekirdeği, öğrencinin kodunu geçici bir dosyaya yazıp belirli girdilerle çalıştırabilir. Aşağıdaki örnek, zaman aşımı olan basit bir değerlendirme yapar. Bu sürüm öğretici amaçlıdır; üretimde Docker, kullanıcı yetkisi düşürme ve dosya sistemi izolasyonu eklenmelidir.

import subprocess
import tempfile
from pathlib import Path

TESTS = [
    {'input': '2 3\n', 'expected': '5'},
    {'input': '10 -4\n', 'expected': '6'},
]

def grade_python_code(source_code, timeout=2):
    results = []
    with tempfile.TemporaryDirectory() as tmp:
        path = Path(tmp) / 'solution.py'
        path.write_text(source_code, encoding='utf-8')

        for test in TESTS:
            try:
                run = subprocess.run(
                    ['python', str(path)],
                    input=test['input'],
                    text=True,
                    capture_output=True,
                    timeout=timeout
                )
                output = run.stdout.strip()
                passed = output == test['expected']
                results.append({
                    'passed': passed,
                    'output': output,
                    'expected': test['expected'],
                    'error': run.stderr.strip()
                })
            except subprocess.TimeoutExpired:
                results.append({
                    'passed': False,
                    'output': '',
                    'expected': test['expected'],
                    'error': 'Zaman aşımı'
                })

    score = sum(r['passed'] for r in results) / len(results) * 100
    return score, results

Bu kodun yaptığı iş şudur: gönderilen Python kodu geçici klasöre kaydedilir, her test girdisi programa verilir, standart çıktı yakalanır ve beklenen sonuçla karşılaştırılır. timeout parametresi sonsuz döngüleri durdurmak için ilk savunma hattıdır. Fakat tek başına yeterli değildir; öğrenci kodu open() ile dosya okuyabilir veya çok bellek harcayabilir.

Daha güvenli mimaride her çözüm ayrı bir konteyner içinde çalışır. Docker tabanlı yaklaşımda işlemci, bellek ve dosya sistemi sınırlandırılır. Mantık kabaca şöyledir:

import subprocess

def run_in_docker(file_path):
    return subprocess.run(
        [
            'docker', 'run', '--rm',
            '--network', 'none',
            '--memory', '128m',
            '--cpus', '0.5',
            '-v', f'{file_path}:/app/solution.py:ro',
            'python:3.12-slim',
            'python', '/app/solution.py'
        ],
        text=True,
        capture_output=True,
        timeout=3
    )

Burada --network none ağ erişimini kapatır, --memory bellek sınırı koyar, --cpus işlemci kullanımını kısıtlar. Dosya :ro ile salt okunur bağlanır. Yani öğrenci kodu küçük bir akvaryumda yüzer; okyanusa açılamaz.

Test tasarımı da en az güvenlik kadar önemlidir. Sadece örnek testlerle notlandırma yapmak, öğrencileri çıktı ezberlemeye iter. İyi bir sistemde görünür testler öğrenmeyi destekler, gizli testler ise genelleme yeteneğini ölçer. Ayrıca geri bildirim metinleri pedagojik olmalıdır: yalnızca yanlış demek yerine, hangi durumda hata oluştuğunu söylemek öğrencinin öğrenmesini hızlandırır.

Sonuç olarak Python ile auto-grader geliştirmek; subprocess, test mühendisliği, güvenlik ve eğitim psikolojisini bir araya getiren harika bir projedir. Küçük başlayın: birkaç test, zaman sınırı ve JSON sonuçları üretin. Sonra Docker sandbox, gizli test havuzu, kısmi puanlama ve web arayüzü ekleyin. Bir süre sonra fark edeceksiniz: artık sadece kod çalıştıran bir araç değil, öğrenciye anında geri bildirim veren mini bir öğretmen inşa ettiniz.

Matematiksel olarak kullanıcı yolculuğunu bir dizi gibi düşünebiliriz: $J_u = [e_1, e_2, e_3, …, e_n]$. Burada $u$ kullanıcıyı, $e_i$ ise i. olayı temsil eder. Eğer kullanıcıların bir sonraki adımını tahmin etmek istiyorsak, basitçe şu olasılıkla ilgileniriz: $P(e_{i+1} \mid e_i)$. Yani kullanıcı ürün detayına baktıysa, bir sonraki adımının sepete ekleme olma ihtimali nedir?

Örneğin farklı platformlarda ürün görüntüleme sonrası sepete ekleme oranını ölçmek isteyelim. Aşağıdaki sorgu, kullanıcıların olay sırasını inceler ve view_product olayından sonra gelen adımı yakalar:

WITH ordered_events AS (
  SELECT
    user_id,
    platform,
    event_name,
    event_time,
    LEAD(event_name) OVER (
      PARTITION BY user_id, platform
      ORDER BY event_time
    ) AS next_event
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '30 day'
), transitions AS (
  SELECT
    platform,
    COUNT(*) AS product_views,
    SUM(CASE WHEN next_event = 'add_to_cart' THEN 1 ELSE 0 END) AS cart_adds
  FROM ordered_events
  WHERE event_name = 'view_product'
  GROUP BY platform
)
SELECT
  platform,
  product_views,
  cart_adds,
  ROUND(cart_adds * 100.0 / NULLIF(product_views, 0), 2) AS conversion_rate
FROM transitions;

Bu sorgu bize örneğin mobilde ürün görenlerin daha fazla sepete eklediğini, webde ise kullanıcıların kararsız kaldığını gösterebilir. Böylece web kullanıcılarına karşılaştırma kartları, mobil kullanıcılara hızlı ödeme butonu sunmak mantıklı hale gelir.

Kişiselleştirme tarafında ise davranışları puanlamak çok işe yarar. Basit bir skor formülü şöyle kurulabilir:

Bu formül mükemmel olmak zorunda değildir; başlangıç için sezgisel olması yeterlidir. SQL ile bunu hesaplayabiliriz:

SELECT
  user_id,
  category_id,
  SUM(
    CASE
      WHEN event_name = 'add_to_cart' THEN 5
      WHEN event_name = 'view_product' THEN 3
      WHEN event_name = 'favorite' THEN 2
      WHEN event_name = 'bounce' THEN -4
      ELSE 0
    END
  ) AS interest_score
FROM events
WHERE event_time >= CURRENT_DATE - INTERVAL '14 day'
GROUP BY user_id, category_id
HAVING SUM(
  CASE
    WHEN event_name = 'add_to_cart' THEN 5
    WHEN event_name = 'view_product' THEN 3
    WHEN event_name = 'favorite' THEN 2
    WHEN event_name = 'bounce' THEN -4
    ELSE 0
  END
) > 0;

Bu çıktıyı içerik tablosuyla birleştirerek kullanıcılara en yüksek skorlu kategorilerden öneriler gösterebilirsiniz. Mesela oyun laptoplarına bakan ama satın almayan kullanıcıya inceleme videosu, sepete ekleyip çıkan kullanıcıya sınırlı süreli indirim sunulabilir.

Elbette bu analizlerde dikkat edilmesi gereken iki büyük konu vardır: veri kalitesi ve gizlilik. Aynı kullanıcının farklı cihazlarda parçalanması, saat dilimi hataları veya yanlış event isimleri sonuçları bozabilir. Ayrıca kişiselleştirme yaparken kullanıcı rızası, anonimleştirme ve veri minimizasyonu unutulmamalıdır.

Sonuç olarak SQL, sadece veri çekme dili değil; kullanıcı davranışlarını anlamak için güçlü bir mercek gibidir. Doğru modellenmiş olay verisi, pencere fonksiyonları ve akıllı skorlama ile platformlarınız kullanıcıya ‘beni anlıyor’ hissi verebilir. Ve kabul edelim: İyi yazılmış bir SQL sorgusu, bazen en havalı yapay zekâ modelinden bile daha hızlı değer üretir.

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.