Bu basitlik aldatıcıdır. Çünkü her piksel için aynı işlem yapılmasına rağmen sonuçlar dramatik biçimde değişir. Bir piksel 10 yinelemede kaçarken komşusu 500 yineleme boyunca dayanabilir. İşte renkleri de genellikle bu kaçış hızına göre veririz.

Aşağıdaki C++ kodu, Mandelbrot kümesini PPM formatında bir görsele yazar. PPM seçmemizin nedeni eğlenceli derecede basit olmasıdır: dosyanın başına birkaç bilgi, ardından RGB değerleri. Yani kütüphane canavarı çağırmadan piksel piksel resim üretebiliriz.

#include <fstream>
#include <complex>

int main() {
    const int width = 900;
    const int height = 600;
    const int maxIter = 300;

    std::ofstream out("mandelbrot.ppm");
    out << "P3\n" << width << " " << height << "\n255\n";

    for (int y = 0; y < height; ++y) {
        for (int x = 0; x < width; ++x) {
            double real = -2.5 + x * (3.5 / width);
            double imag = -1.2 + y * (2.4 / height);

            std::complex<double> c(real, imag);
            std::complex<double> z(0, 0);

            int iter = 0;
            while (std::abs(z) <= 2.0 && iter < maxIter) {
                z = z * z + c;
                ++iter;
            }

            int r = (iter * 9) % 256;
            int g = (iter * 5) % 256;
            int b = (iter * 13) % 256;

            if (iter == maxIter) {
                r = g = b = 0;
            }

            out << r << " " << g << " " << b << " ";
        }
        out << "\n";
    }
}

Kodda real ve imag değişkenleri, ekran koordinatını matematiksel düzleme çevirir. Yani (x, y) pikselini doğrudan çizmek yerine, onu karmaşık sayı düzlemindeki bir noktaya dönüştürürüz. Sonrasında z = z * z + c satırı fraktalın motorudur. Bu satır her piksel için yüzlerce kez çalışır; C++ burada hız avantajını gösterir.

Renk seçimi tamamen deney alanıdır. Yukarıdaki örnekte mod alma ile basit ama canlı bir palet oluşturduk. Daha yumuşak geçişler için logaritmik renklendirme kullanılabilir. Teorik olarak kaçış süresi $n$ ise, renk fonksiyonu $color=f(n)$ gibi düşünülebilir. Fonksiyon ne kadar yaratıcıysa fraktal o kadar “galaksi posteri” havasına bürünür.

Fraktalların büyüsü, deterministik olmalarına rağmen organik görünmeleridir. Aynı formül, aynı başlangıç, aynı sonuç; fakat sonuç, doğadaki kıyı çizgilerini, bulutları ve damar yapılarını hatırlatır. Kaos teorisi burada “rastgelelik” değil, başlangıç koşullarına aşırı duyarlılık demektir.

Bu programı geliştirmek için yakınlaştırma parametreleri ekleyebilir, PNG çıktısı almak için stb_image_write kullanabilir veya çok çekirdekli işlem için pikselleri paralel hesaplatabilirsiniz. Sonuçta C++ ile fraktal üretimi sadece görsel bir oyuncak değildir; matematik, performans ve yaratıcılığın aynı döngüde buluştuğu küçük bir evrendir.

Teorik olarak kaynak koddan çalışmaya giden yol şöyle modellenebilir:

Burada “VM”, sanal makine demektir. Gerçek CPU yerine kendi küçük işlemcimizi C içinde simüle ederiz. Mesela ADD x 3 komutu, bellekteki x değerini alıp üzerine 3 ekleyen bir bytecode talimatına dönüşür.

Önce komut kümemizi tanımlayalım. Bu dilde üç işlem olsun: değişkene değer atama, toplama ve ekrana yazdırma. Matematiksel olarak belleği bir fonksiyon gibi düşünebiliriz: $M(v)$, v değişkeninin değeridir. ADD x 3 çalışınca yeni durum $M’(x)=M(x)+3$ olur.

typedef enum {
    OP_SET,
    OP_ADD,
    OP_PRINT,
    OP_HALT
} OpCode;

typedef struct {
    OpCode op;
    int var;
    int value;
} Instruction;

Bu yapı bizim mini makine dilimizdir. op hangi işlemin yapılacağını söyler, var değişkenin kimliğini, value ise sayısal argümanı taşır. Gerçek makinelerde bunlar baytlara sıkıştırılır; biz okunabilir kalsın diye struct kullandık.

Şimdi basit bir değişken tablosu yazalım. Oyuncak örnekte değişkenleri tek harf kabul etmek işi çok kolaylaştırır: a, b, x gibi. Böylece x - 'a' bize 0-25 arası bir indeks verir.

int var_id(const char *name) {
    if (name[0] >= 'a' && name[0] <= 'z' && name[1] == '\0')
        return name[0] - 'a';
    return -1;
}

Parser tarafında satırı okuyup ilk kelimeye göre karar verebiliriz. Bu, tam teşekküllü bir parser değildir ama sözdizimi analizinin özünü gösterir: beklenen kalıba uyuyor mu?

int compile_line(char *line, Instruction *out) {
    char cmd[16], name[16];
    int value;

    if (sscanf(line, "SET %15s %d", name, &value) == 2) {
        out->op = OP_SET;
        out->var = var_id(name);
        out->value = value;
        return out->var >= 0;
    }

    if (sscanf(line, "ADD %15s %d", name, &value) == 2) {
        out->op = OP_ADD;
        out->var = var_id(name);
        out->value = value;
        return out->var >= 0;
    }

    if (sscanf(line, "PRINT %15s", name) == 1) {
        out->op = OP_PRINT;
        out->var = var_id(name);
        out->value = 0;
        return out->var >= 0;
    }

    return 0;
}

Bu kodun eğlenceli yanı, sscanf ile minik bir dilbilgisi kontrolü yapmasıdır. Daha ciddi bir projede token üretir, ardından recursive descent parser yazardık. Örneğin expr -> term ((+|-) term)* gibi kurallarla matematiksel ifadeleri ayrıştırmak mümkün olurdu.

Son adımda bytecode’u çalıştıran sanal makineyi yazıyoruz:

void run(Instruction *code, int count) {
    int memory[26] = {0};

    for (int ip = 0; ip < count; ip++) {
        Instruction in = code[ip];

        switch (in.op) {
            case OP_SET:
                memory[in.var] = in.value;
                break;
            case OP_ADD:
                memory[in.var] += in.value;
                break;
            case OP_PRINT:
                printf("%d\n", memory[in.var]);
                break;
            case OP_HALT:
                return;
        }
    }
}

Buradaki ip, instruction pointer’dır; yani sıradaki talimatın adresini gösterir. CPU’larda da benzer bir mantık vardır. Program sayacı ilerler, talimat çözülür, işlem yapılır. Bizim VM bunu C döngüsüyle taklit eder.

Örnek program şöyle olabilir:

SET x 10
ADD x 7
PRINT x

Derleme sonucunda yaklaşık olarak şu bytecode dizisi oluşur:

Çıktı doğal olarak 17 olur. Küçük ama güçlü bir fikir yakaladık: sözdizimi sadece metin kontrolü değildir; anlamlı eylemlere açılan kapıdır. Buradan sonra ifadeler, koşullar, döngüler ve hata mesajları ekleyerek mini dilinizi büyütebilirsiniz. Bir noktadan sonra fark edeceksiniz: derleyiciler büyü yapmıyor, sadece çok disiplinli bir çeviri işi gerçekleştiriyor.

Blokzincirin kalbinde kriptografik özetleme fonksiyonu yani hash vardır. Bir hash fonksiyonu, herhangi uzunluktaki girdiyi sabit uzunlukta bir çıktıya dönüştürür. Örneğin SHA-256 çıktısı 256 bittir. Matematiksel olarak şöyle düşünebiliriz:

Burada $x$ veri, $y$ ise özet değerdir. İyi bir hash fonksiyonunda küçük bir değişiklik bile sonucu tamamen farklılaştırır. Buna çığ etkisi denir. Yani Merhaba ile MerhabA aynı görünse de hash açısından bambaşka evrenlerdir.

Bir blok genellikle şu alanlardan oluşur: veri, zaman damgası, kendi hash değeri ve önceki bloğun hash değeri. İşin sihri son alandadır. Çünkü her blok, kendinden öncekinin özetini taşır. Böylece üçüncü bloğu değiştirmek isterseniz sadece üçüncü bloğun hash’i değil, dördüncü, beşinci ve devamındaki tüm bloklar bozulur.

Basit formülümüz şu olabilir:

Şimdi Go tarafına geçelim. Aşağıdaki kod, minimal bir blok yapısı tanımlar ve SHA-256 ile hash üretir:

package main

import (
    "crypto/sha256"
    "encoding/hex"
    "fmt"
    "time"
)

type Block struct {
    Index        int
    Timestamp    string
    Data         string
    PreviousHash string
    Hash         string
}

func calculateHash(b Block) string {
    record := fmt.Sprintf("%d%s%s%s", b.Index, b.Timestamp, b.Data, b.PreviousHash)
    sum := sha256.Sum256([]byte(record))
    return hex.EncodeToString(sum[:])
}

Burada calculateHash, bloğun anlamlı alanlarını tek bir metne çevirir ve SHA-256’dan geçirir. hex.EncodeToString ise ham byte çıktısını okunabilir onaltılık formata dönüştürür.

Şimdi yeni blok üretelim:

func createBlock(index int, data string, previousHash string) Block {
    block := Block{
        Index:        index,
        Timestamp:    time.Now().String(),
        Data:         data,
        PreviousHash: previousHash,
    }
    block.Hash = calculateHash(block)
    return block
}

Bu fonksiyon bloğu oluşturur, ardından hash değerini hesaplayıp bloğun içine yazar. İlk bloğa genellikle genesis block denir. Çünkü zincirin başlangıç noktasıdır ve önceki bloğu yoktur.

func main() {
    genesis := createBlock(0, "Genesis Block", "")
    second := createBlock(1, "Ali -> Ayşe: 10 token", genesis.Hash)
    third := createBlock(2, "Ayşe -> Mehmet: 4 token", second.Hash)

    blockchain := []Block{genesis, second, third}

    for _, block := range blockchain {
        fmt.Println("Index:", block.Index)
        fmt.Println("Data:", block.Data)
        fmt.Println("Prev:", block.PreviousHash)
        fmt.Println("Hash:", block.Hash)
        fmt.Println("---")
    }
}

Bu programı çalıştırdığınızda her bloğun, bir önceki bloğun hash değerini taşıdığını görürsünüz. Zincir fikri tam olarak budur: Her halka, kendinden önceki halkanın dijital parmak izini saklar.

Peki biri ikinci bloğun verisini değiştirirse ne olur? Mesela Ali -> Ayşe: 10 token yerine Ali -> Ayşe: 1000 token yazarsa, ikinci bloğun hash’i değişir. Ancak üçüncü blok hâlâ eski ikinci hash’e bağlıdır. Böylece zincir tutarsız hale gelir.

Bunu kontrol etmek için basit bir doğrulama fonksiyonu yazabiliriz:

func isChainValid(chain []Block) bool {
    for i := 1; i < len(chain); i++ {
        current := chain[i]
        previous := chain[i-1]

        if current.Hash != calculateHash(current) {
            return false
        }
        if current.PreviousHash != previous.Hash {
            return false
        }
    }
    return true
}

Bu fonksiyon iki şeyi denetler: Bloğun kendi hash’i gerçekten içeriğinden mi üretilmiş, ayrıca önceki bloğa doğru şekilde mi bağlanmış? İkisinden biri bozulursa zincir geçersizdir.

Gerçek blokzincirlerde buna ek olarak dağıtık ağ, mutabakat algoritmaları, proof of work, imzalar ve cüzdanlar bulunur. Ancak çekirdek düşünce değişmez: Geçmişi değiştirmek pahalı, görünür ve pratikte sürdürülemez olmalıdır.

Özetle Go ile yazdığımız bu mini zincir, blokzincirin büyüsünü sadeleştirir: veri + önceki hash + kriptografik özet = birbirine kilitlenmiş kayıtlar. Gerçek dünyadaki dev sistemlerin altında da bu basit ama güçlü fikir yatar.

Mikro servis yaklaşımında ise sistem $n$ adet küçük servise bölünür. Kabaca karmaşıklığı şöyle düşünebiliriz: monolitikte değişiklik etkisi çoğu zaman $O(n)$ modüle yayılırken, iyi ayrılmış servislerde etki alanı $O(1)$ veya sınırlı birkaç servise iner. Elbette bu sihirli bir değnek değildir; dağıtık sistem karmaşıklığı, ağ hataları ve veri tutarlılığı gibi yeni problemler getirir.

PHP ile mikro servis yazmak için illa devasa framework kullanmak zorunda değilsiniz. Laravel, Symfony veya Slim gibi frameworkler servis geliştirmeyi kolaylaştırır. Önemli olan servis sınırlarını doğru çizmektir. Örneğin bir e-ticaret sisteminde şu servisler olabilir:

• User Service: kullanıcı kaydı, giriş, yetkilendirme
• Catalog Service: ürün ve kategori yönetimi
• Order Service: sipariş oluşturma ve durum takibi
• Payment Service: ödeme alma ve doğrulama
• Notification Service: e-posta, SMS, push bildirimleri

Servisler genellikle HTTP/REST, gRPC veya mesaj kuyrukları üzerinden haberleşir. PHP tarafında basit bir REST endpoint şöyle görünebilir:

<?php

require 'vendor/autoload.php';

use Slim\Factory\AppFactory;

$app = AppFactory::create();

$app->get('/users/{id}', function ($request, $response, $args) {
    $userId = (int) $args['id'];

    $data = [
        'id' => $userId,
        'name' => 'Ada Lovelace',
        'role' => 'admin'
    ];

    $response->getBody()->write(json_encode($data));
    return $response->withHeader('Content-Type', 'application/json');
});

$app->run();

Bu örnekte küçük bir kullanıcı servisi, /users/{id} adresinden JSON veri döndürür. Gerçek dünyada burada veritabanı bağlantısı, doğrulama, loglama ve hata yönetimi de bulunur. Ama temel fikir basittir: servis tek bir sorumluluğa odaklanır.

Mikro servislerde en kritik konulardan biri veri yönetimidir. Her servisin kendi veritabanına sahip olması önerilir. Çünkü ortak veritabanı kullanılırsa servisler görünmez şekilde birbirine bağlanır. Bu durum mikro servis görünümünde monolit üretir; yani tabelada mikro servis yazar ama içeride herkes aynı mutfağı kullanır.

Örneğin ödeme tamamlandığında Payment Service, payment.completed adlı bir olay yayınlayabilir. Order Service bu olayı dinleyip sipariş durumunu günceller. Böylece servisler birbirini doğrudan çağırmak zorunda kalmaz. Bu modelde sistemin toplam güvenilirliği için basitçe $R_{sistem} = R_1 \times R_2 \times … \times R_n$ gibi düşünebiliriz. Servis sayısı arttıkça gözlemleme, retry ve circuit breaker gibi mekanizmalar daha önemli hale gelir.

PHP ekosisteminde RabbitMQ, Redis Streams veya Kafka ile olay tabanlı iletişim kurulabilir. Docker ise her servisi ayrı konteyner olarak çalıştırmak için neredeyse standarttır. Böylece User Service PHP 8.3 ile, Notification Service farklı bağımlılıklarla çalışabilir.

Sonuç olarak PHP ile mikro servis mimarisi, büyük uygulamaları daha yönetilebilir hale getirmek için güçlü bir yaklaşımdır. Ancak her projeye otomatik olarak uygulanmamalıdır. Küçük bir uygulamada monolit daha hızlı ve ekonomiktir. Mikro servis, ekip büyüdüğünde, domain sınırları netleştiğinde ve bağımsız ölçekleme ihtiyacı doğduğunda parlamaya başlar. Kısacası önce problemi büyütün, sonra mimariyi bölün; yoksa mikro servis değil, mikro kaos üretirsiniz.

``

Fikir: Her Cümle Bir Adaydır

Bir makaleyi cümlelere böldüğümüzde aslında elimizde küçük aday özet parçaları oluşur. Amacımız, her cümleye bir önem puanı vermektir. Bu puan; kelime sıklığı, cümlenin konumu ve metnin genel temasına benzerliği gibi sinyallerden oluşabilir.

Basit bir ağırlık formülü şöyle düşünülebilir:

$score(s)=0.5 \times freq(s)+0.3 \times sim(s)+0.2 \times pos(s)$

Burada $freq(s)$ cümlede geçen önemli kelimelerin toplam ağırlığıdır. $sim(s)$ cümlenin tüm belge vektörüne benzerliğini, $pos(s)$ ise cümlenin metindeki stratejik konumunu temsil eder. Örneğin giriş ve sonuç bölümlerindeki cümleler çoğu zaman daha bilgilendiricidir.

Teorik Altyapı: TF-IDF ve Kosinüs Benzerliği

Kelime saymak tek başına yeterli değildir. “ve”, “bir”, “ile” gibi kelimeler çok geçer ama anlam taşıma güçleri düşüktür. Bu yüzden TF-IDF kullanırız. TF, bir kelimenin cümlede ne kadar sık geçtiğini; IDF ise o kelimenin tüm cümleler arasında ne kadar ayırt edici olduğunu gösterir.

Matematiksel olarak:

$tfidf(t,d)=tf(t,d) \times idf(t)$

Bir cümleyi ve tüm belgeyi vektör olarak düşündüğümüzde, aralarındaki açı bize benzerliği verir:

$cos(\theta)=\frac{A \cdot B}{|A||B|}$

Açı küçüldükçe benzerlik artar. Yani cümle, makalenin genel fikrine yaklaşıyorsa özet için güçlü bir adaydır.

Python ile Orta Seviye Bir Uygulama

Aşağıdaki kod, metni cümlelere ayırır, TF-IDF matrisi üretir, her cümleyi belge ortalamasıyla karşılaştırır ve en yüksek puanlı cümleleri seçer.

import re
import numpy as np
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity

STOPWORDS = {'ve', 'ile', 'bir', 'bu', 'da', 'de', 'için', 'gibi', 'çok', 'ama'}

def split_sentences(text):
    sentences = re.split(r'(?<=[.!?]) +', text.strip())
    return [s for s in sentences if len(s.split()) > 4]

def clean(sentence):
    sentence = sentence.lower()
    sentence = re.sub(r'[^a-zA-ZçğıöşüÇĞİÖŞÜ0-9 ]', ' ', sentence)
    words = [w for w in sentence.split() if w not in STOPWORDS]
    return ' '.join(words)

def summarize(text, ratio=0.3):
    sentences = split_sentences(text)
    cleaned = [clean(s) for s in sentences]

    vectorizer = TfidfVectorizer()
    matrix = vectorizer.fit_transform(cleaned)

    document_vector = matrix.mean(axis=0)
    similarities = cosine_similarity(matrix, document_vector)

    scores = []
    n = len(sentences)
    for i, sim in enumerate(similarities.flatten()):
        position_score = 1 - (i / max(n - 1, 1)) * 0.3
        final_score = 0.8 * sim + 0.2 * position_score
        scores.append((i, final_score))

    count = max(1, int(n * ratio))
    selected = sorted(scores, key=lambda x: x[1], reverse=True)[:count]
    selected_indexes = sorted(i for i, score in selected)

    return ' '.join(sentences[i] for i in selected_indexes)

Kodda TfidfVectorizer, her cümleyi sayısal bir vektöre dönüştürür. document_vector, bütün metnin ortalama anlam merkezidir. Her cümle bu merkeze ne kadar yakınsa, cosine_similarity sonucu o kadar yüksek çıkar. Son olarak, skorlar büyükten küçüğe sıralanır; seçilen cümleler orijinal sırasına göre birleştirilir. Böylece özet, hem anlamlı hem de okunabilir kalır.

Çıkarımsal ve Soyutlayıcı Özetleme

Bu projede çıkarımsal yöntemi seçmemizin sebebi, daha anlaşılır ve kontrol edilebilir olmasıdır. Özellikle ilk NLP projeleri için harika bir başlangıçtır.

Geliştirme Fikirleri

Bu aracı daha akıllı hale getirmek için Türkçe kök bulma, özel isim tanıma veya başlık ağırlığı eklenebilir. Ayrıca sentence-transformers gibi modellerle cümleleri bağlamsal vektörlere çevirerek daha güçlü benzerlik hesapları yapılabilir.

Sonuç olarak, otomatik özetleme sadece “kısaltma” işi değildir; metnin matematiksel haritasını çıkarma sanatıdır. Python ise bu haritayı çizmek için oldukça eğlenceli bir pusula sunar.

``

Anomali tespiti, verinin beklenen davranıştan anlamlı biçimde sapmasını bulma işidir. Log dünyasında bu sapma; hata sayısında ani artış, belirli bir servisin alışılmadık gecikmesi, tek bir IP’den anormal istek yağması veya normalde hiç görülmeyen hata kodlarının ortaya çıkması olabilir. Temel fikir şudur: Önce “normal” davranışı tanımlarız, sonra güncel değerin bu normale ne kadar uzaklaştığını ölçeriz.

En yaygın yöntemlerden biri z-skorudur. Bir ölçümün ortalamadan kaç standart sapma uzakta olduğunu gösterir:

Burada $x$ gözlenen değer, $\mu$ geçmiş ortalama, $\sigma$ ise standart sapmadır. Örneğin bir serviste dakikada ortalama 20 hata varken standart sapma 5 ise, 45 hata geldiğinde $z = 5$ olur. Bu, “dostum burada bir şey yanıyor olabilir” demenin matematiksel hâlidir.

Diyelim ki elimizde app_logs adlı bir tablo var: ts, service_name, level, status_code, duration_ms, message. İlk hedefimiz, her servis için dakikalık hata sayılarını çıkarmak olsun.

WITH minute_errors AS (
  SELECT
    DATE_TRUNC('minute', ts) AS minute_bucket,
    service_name,
    COUNT(*) AS error_count
  FROM app_logs
  WHERE level = 'ERROR'
  GROUP BY 1, 2
)
SELECT *
FROM minute_errors
ORDER BY minute_bucket DESC;

Bu sorgu ham logları daha anlamlı bir zaman serisine dönüştürür. Anomali tespitinde ilk büyük adım genellikle budur: Gürültülü satırları ölçülebilir metriklere çevirmek.

Şimdi geçmiş davranışı kullanarak z-skoru hesaplayalım. Aşağıdaki örnek PostgreSQL sözdizimine yakındır ve her servis için genel ortalama ile standart sapmayı çıkarır.

WITH minute_errors AS (
  SELECT
    DATE_TRUNC('minute', ts) AS minute_bucket,
    service_name,
    COUNT(*) AS error_count
  FROM app_logs
  WHERE level = 'ERROR'
  GROUP BY 1, 2
), baseline AS (
  SELECT
    service_name,
    AVG(error_count) AS avg_errors,
    STDDEV(error_count) AS std_errors
  FROM minute_errors
  WHERE minute_bucket < NOW() - INTERVAL '15 minutes'
  GROUP BY service_name
)
SELECT
  m.minute_bucket,
  m.service_name,
  m.error_count,
  ROUND((m.error_count - b.avg_errors) / NULLIF(b.std_errors, 0), 2) AS z_score
FROM minute_errors m
JOIN baseline b USING (service_name)
WHERE m.minute_bucket >= NOW() - INTERVAL '15 minutes'
  AND (m.error_count - b.avg_errors) / NULLIF(b.std_errors, 0) > 3
ORDER BY z_score DESC;

Burada NULLIF küçük ama hayat kurtaran bir detaydır; standart sapma sıfırsa bölme hatasını engeller. z_score > 3 eşiği klasik bir başlangıç noktasıdır, fakat her sistem için kutsal değildir. Ödeme sisteminde eşik daha hassas, test ortamında daha gevşek olabilir.

Bazı durumlarda genel ortalama yanıltıcıdır. Pazartesi sabahı trafiği ile pazar gecesi trafiği aynı kefeye konmaz. Bu yüzden bağlamsal baz çizgiler kullanmak daha sağlıklıdır.

Gecikme anomalileri için yüzdelikler de çok değerlidir. Ortalama bazen aldatır; birkaç aşırı yavaş istek ortalamayı şişirebilir. Bu yüzden p95 veya p99 gibi değerler kullanılır.

SELECT
  DATE_TRUNC('minute', ts) AS minute_bucket,
  service_name,
  PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY duration_ms) AS p95_latency
FROM app_logs
GROUP BY 1, 2
HAVING PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY duration_ms) > 1000
ORDER BY minute_bucket DESC;

Bu sorgu, isteklerin yüzde 95’inin altında kaldığı gecikme değerini bulur. Eğer p95 1000 ms üstüne çıkıyorsa kullanıcıların ciddi bir kısmı yavaşlık hissediyor olabilir.

Son olarak, SQL ile anomali tespiti sadece alarm üretmek değildir; açıklanabilirlik de sağlar. “Bir model söyledi” yerine “son 15 dakikada payment-api hata sayısı normalin 4.7 standart sapma üstüne çıktı” diyebilirsiniz. Bu da hem geliştiricinin hem SRE ekibinin hızlı aksiyon almasını kolaylaştırır.

Özetle SQL, log okyanusunda el feneri gibidir. Doğru gruplama, istatistiksel eşikler, pencere fonksiyonları ve bağlamsal düşünme ile beklenmeyen sistem hatalarını üretim ortamı yangına dönmeden yakalayabilirsiniz.

``

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.