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.

Temel fikir şudur: Mitolojik karakterleri düğüm, aralarındaki bağları kenar kabul ederiz. Yani elimizde küçük bir grafik vardır: $G=(V,E)$. Burada $V$ kişiler, tanrılar, canavarlar veya yarı tanrılar; $E$ ise ebeveynlik, eşlik, kardeşlik, yaratılma ya da lanetlenme gibi ilişkilerdir. Klasik soy ağacında ilişki genelde $parent \rightarrow child$ biçimindedir; fakat mitolojide aynı varlık birden fazla kaynağa göre farklı ebeveynlere sahip olabilir. Bu nedenle kaynak bilgisini ayrı tutmak altın kuraldır.

SQL tarafında ilişkisel ama grafik tadında bir şema kurabiliriz:

CREATE TABLE beings (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  culture TEXT NOT NULL,
  being_type TEXT CHECK (being_type IN ('god','human','hero','monster','titan','spirit')),
  notes TEXT
);

CREATE TABLE sources (
  id INTEGER PRIMARY KEY,
  title TEXT NOT NULL,
  tradition TEXT,
  reliability_score NUMERIC CHECK (reliability_score BETWEEN 0 AND 1)
);

CREATE TABLE relationships (
  id INTEGER PRIMARY KEY,
  from_id INTEGER REFERENCES beings(id),
  to_id INTEGER REFERENCES beings(id),
  relation_type TEXT NOT NULL,
  source_id INTEGER REFERENCES sources(id),
  certainty NUMERIC CHECK (certainty BETWEEN 0 AND 1)
);

Bu yapıda relationships tablosu ana sahnedir. Örneğin from_id = Zeus, to_id = Athena, relation_type = parent diyebiliriz. Ancak Athena’nın doğumu sıradan olmadığı için notes veya ayrı bir olay tablosu ile kafadan doğma gibi anlatıları saklayabiliriz. Matematiksel olarak her ilişkinin ağırlığı $w \in [0,1]$ olabilir; burada $w$ kesinlik değeridir. Böylece tartışmalı soylar için veritabanı dogmatik davranmaz.

Örnek veri ekleyelim:

INSERT INTO beings VALUES
(1, 'Zeus', 'Greek', 'god', 'Olympian sky god'),
(2, 'Athena', 'Greek', 'god', 'Born from Zeus according to common tradition'),
(3, 'Odin', 'Norse', 'god', 'All-father figure'),
(4, 'Thor', 'Norse', 'god', 'Thunder god'),
(5, 'Loki', 'Norse', 'god', 'Trickster with complex kinship');

INSERT INTO sources VALUES
(1, 'Theogony', 'Greek', 0.90),
(2, 'Poetic Edda', 'Norse', 0.85);

INSERT INTO relationships VALUES
(1, 1, 2, 'parent', 1, 0.95),
(2, 3, 4, 'parent', 2, 0.90),
(3, 5, 4, 'ally', 2, 0.60);

Asıl eğlence recursive CTE ile başlar. Bir karakterin tüm atalarını bulmak için:

WITH RECURSIVE ancestry(depth, ancestor_id, descendant_id) AS (
  SELECT 1, from_id, to_id
  FROM relationships
  WHERE relation_type = 'parent' AND to_id = 2

  UNION ALL

  SELECT a.depth + 1, r.from_id, a.descendant_id
  FROM relationships r
  JOIN ancestry a ON r.to_id = a.ancestor_id
  WHERE r.relation_type = 'parent'
)
SELECT depth, b.name AS ancestor
FROM ancestry
JOIN beings b ON b.id = ancestry.ancestor_id;

Bu sorgu Athena’nın ebeveyninden başlayıp yukarı doğru tırmanır. depth değeri nesil uzaklığını gösterir: $depth=1$ ebeveyn, $depth=2$ büyükanne veya büyükbaba gibi düşünülebilir. Eğer döngü ihtimali varsa, yani bir mitolojik anlatıda karakter kendi soyuna garip şekilde bağlanıyorsa, ziyaret edilen düğümleri takip eden ek bir kolon kullanmak gerekir.

Kültürler arası bağlantı kurarken aynı karakterin varyantlarını da düşünmeliyiz. Roma Jüpiter’i ile Yunan Zeus’u birebir aynı kayıt mı olmalı, yoksa equivalent_to ilişkisiyle mi bağlanmalı? Genelde ikinci yaklaşım daha sağlıklıdır; çünkü $Zeus \neq Jupiter$ demek tarihsel bağlamı korur, ama equivalent_to ile benzerliği sorgulanabilir yapar.

Sonuçta bu proje, SQL öğrenmek için harika bir oyun alanıdır. Normalizasyon, yabancı anahtarlar, çoktan çoğa ilişkiler, recursive sorgular ve belirsizlik modelleme aynı kazanda kaynar. Üstelik test verisi sıkıcı müşteri tabloları değil; titanlar, yarı tanrılar, devler ve kader tanrıçalarıdır. Bir sonraki adım olarak ilişkilere tarihsel dönem, coğrafya ve anlatı varyantı ekleyip kendi mitolojik bilgi grafiğinizi küçük bir dijital Olimpos’a dönüştürebilirsiniz.

C’nin minimalizmini anlamak için onu daha yüksek seviyeli dillerle karşılaştırmak faydalıdır:

Bellek adresleriyle konuşmak, C’nin en güçlü ama en dikkat isteyen tarafıdır. Örneğin 32 bitlik bir sistemde adres uzayı teorik olarak $2^{32}$ bayttır, yani yaklaşık 4 GB. Bir aygıtın kontrol register’ı belirli bir adrese eşlenmişse, kernel bu adrese yazarak aygıta komut verebilir. Buradaki temel fikir şudur: $Adres = Taban + Ofset$. Basit görünüyor, ama bu denklem ekran kartından zamanlayıcıya kadar pek çok donanım etkileşiminin temelidir.

Aşağıdaki örnek, bellek eşlemeli bir donanım register’ına erişim mantığını gösterir. Bu kod gerçek bir cihaz sürücüsünün sadeleştirilmiş halidir:

#include <stdint.h>

#define TIMER_BASE 0x40000000u
#define TIMER_CTRL (*(volatile uint32_t *)(TIMER_BASE + 0x00))
#define TIMER_COUNT (*(volatile uint32_t *)(TIMER_BASE + 0x04))

void timer_start(void) {
    TIMER_COUNT = 1000;      // Sayaç başlangıç değeri
    TIMER_CTRL = 0x1;        // Timer etkinleştir
}

void timer_stop(void) {
    TIMER_CTRL = 0x0;        // Timer durdur
}

Burada volatile kritik önemdedir. Derleyici normalde gereksiz gördüğü bellek okumalarını veya yazmalarını optimize edebilir. Ancak donanım register’ları sıradan değişken değildir; değerleri dış dünyadan değişebilir. volatile, derleyiciye şu mesajı verir: Bu adrese gerçekten git, okuma veya yazmayı atlama.

Kernel modülleri yazarken yalnızca C bilmek yetmez; işlemci mimarisini de tanımak gerekir. Kullanıcı modu ve çekirdek modu ayrımı, sistem çağrıları, kesmeler ve sayfalama mekanizması bu dünyanın temel taşlarıdır.

Bit işlemleri kernel kodunda neredeyse günlük ekmek gibidir. Bir register’ın yalnızca üçüncü bitini açmak istiyorsanız tüm değeri değiştirmek yerine maskeleme yaparsınız. Matematiksel olarak bir bit maskesi $2^n$ ile temsil edilebilir. Örneğin üçüncü bit için maske $2^3 = 8$ olur.

#define ENABLE_BIT (1u << 3)

void enable_device(volatile uint32_t *reg) {
    *reg |= ENABLE_BIT;   // Sadece ilgili biti 1 yap
}

void disable_device(volatile uint32_t *reg) {
    *reg &= ~ENABLE_BIT;  // Sadece ilgili biti 0 yap
}

Bu küçük örnekler, C’nin neden hâlâ kernel dünyasında yaşadığını anlatır. Dil sizi korumaz; ama size engel de olmaz. Yanlış adrese yazarsanız sistem çökebilir, fakat doğru adrese doğru biti yazarsanız donanım sizinle konuşmaya başlar. Bu biraz eski tip bir radyo tamirciliği gibidir: kablolar, sinyaller, küçük tornavidalar ve bolca dikkat.

Sonuç olarak C’nin minimalizmi bir eksiklik değil, bilinçli bir tasarımdır. İşletim sistemleri gibi donanıma en yakın yazılımlarda fazladan soyutlama bazen lüks değil, risktir. C; pointer’ları, bit işlemleri, sade veri yapıları ve düşük seviye kontrol gücüyle modern bilgisayarların temelini anlamak isteyenler için hâlâ en iyi laboratuvarlardan biridir.

NFC, Near Field Communication ifadesinin kısaltmasıdır ve çok kısa mesafede çalışan kablosuz iletişim teknolojisidir. Genellikle $d ≤ 4cm$ gibi yakın bir aralıkta anlamlıdır. Bunun sebebi güvenlik kadar fiziksel çalışma mantığıdır: NFC, radyo dalgasından çok manyetik alan eşleşmesine dayanır. Mesafe arttıkça alan etkisi yaklaşık $P ≈ 1/r^3$ gibi hızlı azalır; yani etiketi masanın öbür ucundan okumaya çalışmak, kedinize SQL öğretmeye benzer: teorik olarak konuşulur, pratikte zordur.

Web NFC tarafında ana karakterimiz NDEFReader sınıfıdır. NDEF, NFC Data Exchange Format anlamına gelir. Etiketin içinde metin, URL, MIME verisi veya uygulamaya özel kayıtlar saklanabilir. JavaScript burada donanıma doğrudan hükmetmez; tarayıcı, güvenlik izinleri ve işletim sistemi üzerinden kontrollü bir köprü kurar.

Web NFC kullanırken üç önemli koşul vardır: HTTPS üzerinde çalışmak, kullanıcıdan izin almak ve destekleyen bir tarayıcı kullanmak. Masaüstünde veya iOS Safari tarafında destek sınırlı olabilir. Bu yüzden üretim uygulamalarında özellik kontrolü yapmak şarttır.

if ('NDEFReader' in window) {
  console.log('Bu cihaz Web NFC destekliyor.');
} else {
  console.log('NFC desteklenmiyor, alternatif akış göster.');
}

Bu küçük kontrol, uygulamanın panik butonudur. Destek yoksa kullanıcıya QR kod, manuel kod girişi veya Bluetooth gibi alternatifler sunabilirsiniz. İyi kullanıcı deneyimi, sadece çalışan cihazı değil, çalışmayan senaryoyu da düşünür.

Bir NFC etiketi okumak için scan() metodu kullanılır. Tarayıcı izin penceresi gösterebilir ve kullanıcı cihazını etikete yaklaştırdığında reading olayı tetiklenir.

const reader = new NDEFReader();

async function startScan() {
  try {
    await reader.scan();
    console.log('NFC tarama başladı.');

    reader.addEventListener('reading', event => {
      const decoder = new TextDecoder();

      for (const record of event.message.records) {
        if (record.recordType === 'text') {
          console.log('Okunan metin:', decoder.decode(record.data));
        }
      }
    });
  } catch (error) {
    console.error('Tarama hatası:', error);
  }
}

Burada kodun yaptığı iş basit ama güçlüdür: okuyucu başlatılır, etiket algılanınca mesaj kayıtları dolaşılır ve metin verisi çözümlenir. NFC verisi ham baytlar halinde geldiği için TextDecoder kullanmak gerekir. Bu noktada JavaScript, küçük bir tercüman gibi davranır.

Yazma işlemi de benzer şekilde yapılır. Örneğin bir müze uygulaması, sergi salonundaki NFC etiketine eser kimliği yazabilir.

async function writeTag() {
  const writer = new NDEFReader();

  try {
    await writer.write({
      records: [
        {
          recordType: 'text',
          data: 'eser:van-gogh-1889'
        }
      ]
    });

    console.log('Etikete veri yazıldı.');
  } catch (error) {
    console.error('Yazma başarısız:', error);
  }
}

Elbette her etikete sonsuz veri yazamayız. NFC etiketlerinin kapasitesi sınırlıdır; bazıları 144 bayt, bazıları birkaç kilobayt veri tutar. Bu nedenle etikete genellikle tüm veriyi değil, veritabanındaki kaydı temsil eden kısa bir anahtar yazılır. Yani etiket depo değil, kapı numarasıdır.

Güvenlik tarafında en kritik ilke şudur: NFC’den gelen veriye asla körü körüne güvenmeyin. Etiket kopyalanabilir, değiştirilebilir veya kötü niyetli URL içerebilir. Okunan değerler sunucuda doğrulanmalı, hassas işlemler için kullanıcı oturumu ve yetki kontrolü yapılmalıdır. Matematiksel olarak düşünürsek, güvenlik sadece $veri + cihaz$ değil; $veri + cihaz + kullanıcı + sunucu doğrulaması$ birleşimidir.

Sonuç olarak Web NFC, mobil web uygulamalarına fiziksel dünya ile tatlı bir tokalaşma imkânı verir. Depo yönetimi, akıllı kartvizitler, müze deneyimleri, eğitim materyalleri ve hızlı yapılandırma ekranları için oldukça kullanışlıdır. Yeter ki tarayıcı desteğini kontrol edin, kullanıcı iznini saygıyla isteyin ve NFC etiketlerini minik ama güçlü anahtarlar gibi tasarlayın.

Düzenli ifadeleri bir tür metin mikroskobu gibi düşünebiliriz. Normal arama işlemi sadece birebir kelime bulurken, regex belirli bir şekle uyan metinleri yakalar. Örneğin e-posta adresleri farklı kullanıcı adlarına ve alan adlarına sahip olabilir; ama çoğu benzer bir forma uyar: kullanıcı, @, alan adı ve uzantı. Bu yüzden regex, tek tek kelime değil, kalıp arar.

Teorik olarak bir regex deseni, karakter kümeleri ve tekrar kurallarıyla tanımlanır. Basitçe şöyle düşünebiliriz: bir metin $T$, bir desen $P$ ile taranır ve eşleşme fonksiyonu $M(T, P)$ bize bulunan parçaları döndürür. Eğer amaç filtreleme ise sonuç doğru/yanlış olabilir; eğer amaç içerik üretimi ise bulunan parçalar yeni bir yapıya dönüştürülür.

PHP tarafında regex işlemleri çoğunlukla PCRE motoru ile yapılır. Desenler genellikle /.../ sınırlandırıcıları arasına yazılır. Sona eklenen i, büyük-küçük harf duyarsızlığı sağlar. Örneğin /php/i, hem PHP hem php hem de Php ifadelerini yakalayabilir.

<?php
$text = 'İletişim: destek@example.com veya satis@site.com.tr';
$pattern = '/\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b/i';

preg_match_all($pattern, $text, $matches);

foreach ($matches[0] as $email) {
    echo $email . PHP_EOL;
}

Bu kodun yaptığı iş basit ama güçlüdür: metin içindeki e-posta biçimine benzeyen tüm parçaları toplar. \b kelime sınırını, [A-Z0-9._%+-]+ kullanıcı adını, @ zorunlu karakteri, devamındaki bölüm ise alan adını temsil eder. Buradaki + operatörü en az bir tekrar anlamına gelir. Yani matematiksel olarak x+, $x$ karakterinin $n \ge 1$ kez tekrar etmesi demektir.

Regex öğrenirken en kritik konu açgözlülük davranışıdır. .* mümkün olan en uzun eşleşmeyi almaya çalışır. Bu bazen çok kullanışlı, bazen de tam bir metin canavarıdır.

Şimdi küçük bir otomatik içerik çıkarıcı yazalım. Diyelim ki elimizde ham HTML benzeri bir metin var ve içindeki başlıkları listeleyerek mini bir özet üretmek istiyoruz.

<?php
$html = '<h2>Regex Nedir?</h2><p>Kalıp arama tekniğidir.</p><h2>PHP ile Kullanımı</h2>';
$pattern = '/<h2>(.*?)<\/h2>/i';

preg_match_all($pattern, $html, $matches);

$summary = [];
foreach ($matches[1] as $title) {
    $summary[] = '- ' . trim(strip_tags($title));
}

echo implode(PHP_EOL, $summary);

Burada (.*?) kısmı yakalama grubudur. preg_match_all sonucunda $matches[0] tam eşleşmeleri, $matches[1] ise parantez içindeki özel bölümü verir. Böylece etiketleri değil, sadece başlık içeriğini kullanarak otomatik özet çıkarabiliriz.

Filtreleme tarafında ise preg_replace oldukça pratiktir. Örneğin yorumlardan telefon numarası gibi hassas verileri maskeleyebilirsiniz.

<?php
$comment = 'Beni 0555 123 45 67 numarasından ara.';
$clean = preg_replace('/\b0\d{3}\s\d{3}\s\d{2}\s\d{2}\b/', '[telefon gizlendi]', $comment);

echo $clean;

Bu yaklaşım özellikle moderasyon sistemlerinde, log temizleme işlemlerinde ve veri anonimleştirmede işe yarar. Yine de regex her sorunun çekici değildir. HTML ayrıştırma için karmaşık yapılarda DOMDocument daha güvenlidir; parola doğrulamada regex yardımcıdır ama tek başına güvenlik politikası değildir.

Sonuç olarak PHP ve regex ikilisi, metin yığınları içinde düzen arayan geliştiriciler için hızlı, ekonomik ve güçlü bir araç setidir. Mantığı kavradığınızda, bir log satırından hata kodu çekmek de, makalelerden otomatik etiket üretmek de aynı temel fikre dayanır: kalıbı tanımla, eşleşmeyi yakala, sonucu anlamlı bir çıktıya dönüştür.

Olasılık dağılımı nedir?

Bir rassal değişkenin alabileceği değerleri ve bu değerlerin gerçekleşme olasılıklarını tarif eden yapıya olasılık dağılımı denir. Örneğin adil bir para için sonuç kümesi $S={Yazı, Tura}$ ve her sonuç için olasılık $P(Yazı)=P(Tura)=0.5$ olur.

Eğer $X$, 10 atışta gelen yazı sayısını temsil ederse, $X$ artık binom dağılımına uyar:

Burada $n$ deneme sayısı, $k$ başarı sayısı, $p$ ise tek denemedeki başarı olasılığıdır. Para adilse $p=0.5$.

Yazı-tura simülasyonu

Teorik olarak adil parada yazı oranı $0.5$ olmalıdır. Ama 10 atışta 8 yazı gelmesi şaşırtıcı değildir. Deneme sayısı büyüdükçe oran teorik değere yaklaşır. Buna büyük sayılar yasası denir.

import random

def coin_flip_simulation(n):
    heads = 0
    ratios = []

    for i in range(1, n + 1):
        flip = random.choice(['Yazı', 'Tura'])
        if flip == 'Yazı':
            heads += 1
        ratios.append(heads / i)

    return heads, ratios

heads, ratios = coin_flip_simulation(10000)
print('Yazı sayısı:', heads)
print('Son oran:', ratios[-1])

Bu kodda her atış bağımsızdır; yani önceki sonucun sonraki sonucu etkilemediğini varsayarız. İşte bu nokta önemlidir: Art arda 5 kez tura gelmesi, bir sonraki atışta yazı olasılığını artırmaz. Hâlâ $P(Yazı)=0.5$.

Dağılımı sayarak görmek

10 kez para atıp kaç yazı geldiğini bir kez hesaplamak yerine, bu deneyi binlerce kez tekrar edebiliriz. Böylece deneysel binom dağılımını elde ederiz.

from collections import Counter
import random

def count_heads_in_trial(n):
    return sum(random.choice([0, 1]) for _ in range(n))

def binomial_experiment(trials, flips_per_trial):
    results = []
    for _ in range(trials):
        results.append(count_heads_in_trial(flips_per_trial))
    return Counter(results)

dist = binomial_experiment(20000, 10)
for heads_count in sorted(dist):
    print(heads_count, dist[heads_count] / 20000)

Burada 0’dan 10’a kadar yazı sayılarının göreli frekanslarını görürüz. Teorik olarak en yüksek değerler 5 civarında toplanır; çünkü 10 atışta 5 yazı gelme olasılığı uç değerlere göre daha fazladır.

Koşullu olasılık: Monty Hall paradoksu

Koşullu olasılık, bir olayın gerçekleştiğini bildiğimizde başka bir olayın olasılığını günceller. Formül şöyledir:

Monty Hall probleminde 3 kapı vardır. Birinde araba, ikisinde keçi bulunur. Oyuncu bir kapı seçer. Sunucu, arabanın olmadığı bir kapıyı açar. Oyuncuya seçim değiştirme hakkı verilir. Sezgisel cevap “fark etmez, olasılık yarı yarıya” olabilir; ama doğru strateji değiştirmektir.

import random

def monty_hall(change=True, trials=10000):
    wins = 0
    doors = [0, 1, 2]

    for _ in range(trials):
        car = random.choice(doors)
        choice = random.choice(doors)

        possible_opens = [d for d in doors if d != choice and d != car]
        opened = random.choice(possible_opens)

        if change:
            choice = [d for d in doors if d != choice and d != opened][0]

        if choice == car:
            wins += 1

    return wins / trials

print('Değiştirirse:', monty_hall(True))
print('Değiştirmezse:', monty_hall(False))

Sonuçlar genellikle değiştirme stratejisinin yaklaşık $\frac{2}{3}$, değiştirmeme stratejisinin ise yaklaşık $\frac{1}{3}$ kazandırdığını gösterir.

Sonuç

Python ile olasılık dağılımlarını modellemek, formülleri ezberlemekten daha kalıcı bir öğrenme sağlar. Simülasyonlar bize şunu öğretir: Kısa vadede rastgelelik gürültülüdür, uzun vadede ise matematik kendini belli eder. Yazı-tura örneği büyük sayılar yasasını, Monty Hall ise koşullu olasılığın sezgilerimize karşı nasıl galip geldiğini gösterir. Kısacası Python, istatistiği kuru bir konu olmaktan çıkarıp deney yapılabilir bir oyun alanına dönüştürür.

Go’nun concurrency yaklaşımını anlamanın ilk adımı şu ayrımı netleştirmektir: Concurrency aynı zaman aralığında birden fazla işle ilerleyebilme yeteneğidir; parallelism ise gerçekten aynı anda, farklı CPU çekirdeklerinde çalışmaktır. Yani concurrency bir tasarım modeli, parallelism ise donanımın sunduğu fiziksel imkândır.

Basitçe ifade edersek:

Go runtime içinde ünlü M:P:G modeli çalışır. Burada G goroutine’i, M işletim sistemi thread’ini, P ise işlemci bağlamını temsil eder. Kabaca ilişkiyi şöyle düşünebiliriz: $G \rightarrow P \rightarrow M$. Eğer $N$ adet goroutine’iniz ve $P$ adet işlemci bağlamınız varsa, Go scheduler bu goroutine’leri uygun thread’lere dağıtarak verimli çalıştırır. Bu yüzden binlerce goroutine açmak çoğu senaryoda binlerce OS thread açmaktan çok daha ucuzdur.

Goroutine başlatmak şaşırtıcı derecede kolaydır:

package main

import (
    "fmt"
    "time"
)

func sendEmail(user string) {
    time.Sleep(500 * time.Millisecond)
    fmt.Println("E-posta gönderildi:", user)
}

func main() {
    users := []string{"ada", "linus", "grace"}

    for _, user := range users {
        go sendEmail(user)
    }

    time.Sleep(1 * time.Second)
}

Bu örnekte her kullanıcı için ayrı bir goroutine başlatılır. sendEmail fonksiyonu bloklansa bile ana akış diğer işleri başlatmaya devam eder. Ancak gerçek projelerde time.Sleep ile beklemek pek yakışıklı değildir; bu, restoranda garsona “yemekler herhalde gelir” deyip göz kararı beklemek gibidir.

Daha kontrollü bir yapı için channel kullanırız. Channel’lar goroutine’ler arasında güvenli veri aktarımı sağlar. Go’nun meşhur sözü burada devreye girer: Belleği paylaşarak iletişim kurma; iletişim kurarak belleği paylaş.

package main

import (
    "context"
    "fmt"
    "time"
)

func worker(ctx context.Context, jobs <-chan string, results chan<- string) {
    for {
        select {
        case <-ctx.Done():
            return
        case job, ok := <-jobs:
            if !ok {
                return
            }
            time.Sleep(300 * time.Millisecond)
            results <- fmt.Sprintf("İş tamamlandı: %s", job)
        }
    }
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()

    jobs := make(chan string)
    results := make(chan string)

    for i := 0; i < 3; i++ {
        go worker(ctx, jobs, results)
    }

    go func() {
        defer close(jobs)
        for i := 1; i <= 5; i++ {
            jobs <- fmt.Sprintf("görev-%d", i)
        }
    }()

    for i := 1; i <= 5; i++ {
        fmt.Println(<-results)
    }
}

Burada üç worker goroutine’i aynı jobs kanalından görev alır ve sonuçları results kanalına gönderir. context ise servis kapanışı, timeout veya iptal sinyalleri için temiz bir kontrol mekanizması sunar. Bu yapı, e-posta gönderimi, görsel işleme, log toplama veya webhook tüketimi gibi arka plan servislerinde sıkça kullanılır.

Performans açısından bakarsak, goroutine’lerin başlangıç stack’i küçüktür ve ihtiyaç oldukça büyür. Klasik thread’lerde stack maliyeti megabaytlarla ifade edilebilirken, goroutine’lerde başlangıç maliyeti kilobayt seviyesindedir. Teorik olarak toplam bellek tüketimini şöyle düşünebiliriz: $ToplamBellek \approx n \times s$. Burada $n$ görev sayısı, $s$ ise görev başına stack maliyetidir. $s$ küçüldükçe aynı makinede daha fazla eşzamanlı iş yönetebilirsiniz.

Tabii goroutine açmak bedava değildir; sadece ucuzdur. Sonsuz sayıda goroutine başlatmak, mutfağa sınırsız sipariş yollayıp aşçıdan mucize beklemek gibidir. Bu nedenle worker pool, rate limit, context cancellation ve buffer’lı channel gibi tekniklerle sisteminize sınır koymalısınız.

Sonuç olarak Go’nun concurrency mimarisi, basit sözdizimiyle güçlü bir runtime mühendisliğini birleştirir. Goroutine’ler sayesinde arka plan servisleri hem okunabilir hem de yüksek verimli olabilir. Eğer kuyruk tüketen, API çağrılarını paralelleştiren veya binlerce bağlantıyı yöneten bir servis yazıyorsanız, Go size “thread açalım mı?” diye sormaz; zarifçe go anahtar kelimesini uzatır ve “hadi işi bölelim” der.

Teorik olarak sistemi şu denklemle düşünebiliriz: $IDE = Editör + LSP + DAP + TaskRunner + Eklenti$. Burada LSP, Language Server Protocol yani dil sunucusu protokolüdür. Kod tamamlama, sembole gitme, hata işaretleme gibi özellikleri sağlar. DAP, Debug Adapter Protocol ile hata ayıklama dünyasını standartlaştırır. TaskRunner ise derleme, test, lint ve deploy gibi komutları yönetir.

Çoklu dil çalışma alanında önemli kavramlardan biri bağımlılık grafiğidir. Diyelim ki önyüz projesi API tiplerini otomatik üretilen bir dosyadan alıyor. Bu durumda $frontend \rightarrow generatedTypes \rightarrow backendSchema$ şeklinde bir ilişki oluşur. IDE bu ilişkiyi görevlerle temsil ederse, geliştirici tek tuşla önce şemayı güncelleyip sonra önyüzü başlatabilir.

type Task = { name: string; run: () => Promise<void> };

const tasks: Task[] = [
  { name: 'api:generate', run: async () => console.log('OpenAPI tipleri üretildi') },
  { name: 'frontend:lint', run: async () => console.log('Önyüz kontrol edildi') },
  { name: 'frontend:dev', run: async () => console.log('Vite geliştirme sunucusu açıldı') }
];

async function runPipeline() {
  for (const task of tasks) {
    console.log('Çalışıyor:', task.name);
    await task.run();
  }
}

runPipeline();

Bu kod basit bir görev hattını temsil eder. Gerçek IDE içinde bu yapı çoğu zaman launch, tasks veya workspace ayarlarıyla tanımlanır. Ama mantık aynıdır: görevler sıraya alınır, çıktılar terminalde toplanır, hata olursa zincir durdurulur ya da kullanıcı uyarılır.

Gelişmiş IDE’lerde bu entegrasyonun eğlenceli kısmı otomasyondur. Örneğin dosya kaydedildiğinde formatter çalışır, testler tetiklenir, tip dosyaları yenilenir ve önyüz sıcak yenileme ile güncellenir. Kullanıcı sadece kod yazar; IDE sahne arkasında küçük bir robot ordusu gibi çalışır. Ancak bu robot ordusunun kontrolden çıkmaması için net kurallar gerekir: görev adları anlamlı olmalı, ortam değişkenleri belgelenmeli, her dilin bağımlılık yönetimi izole edilmelidir.

Pratikte iyi bir çoklu dil IDE mimarisi için üç öneri öne çıkar. Birincisi, her teknolojinin kendi doğal aracını kullanın; Python için venv, Node için pnpm veya npm, Java için Maven gibi. İkincisi, ortak akışları IDE görevlerine bağlayın. Üçüncüsü, debug yapılandırmalarını ekip içinde paylaşın. Böylece yeni gelen geliştirici projeyi klonladığında sadece kodu değil, çalışma ritüelini de devralır.

Sonuç olarak çoklu dil mimarisi, IDE’yi pasif bir editörden aktif bir geliştirme merkezine dönüştürür. Arka plandaki otomasyon betikleri, önyüz projeleri ve servisler aynı sahnede buluştuğunda üretkenlik artar. Doğru kurgulanmış bir workspace, geliştiriciye şu hissi verir: Farklı diller konuşan bir ekip var, ama hepsi aynı orkestrada çalıyor.

Bu tür uygulamaların temelinde üç kavram vardır: uyaran, tepki ve ölçüm. Uyaran; ekranda gösterilen soru, görsel, renk ya da görevdir. Tepki; kullanıcının tıklaması, yazması, sürüklemesi veya beklemesidir. Ölçüm ise bu tepkinin zamana, doğruluğa veya tutarlılığa göre sayısallaştırılmasıdır. Basit bir modelle kullanıcı davranış skoru şöyle düşünülebilir: $S = w_1 x_1 + w_2 x_2 + w_3 x_3$. Burada $x$ değerleri davranış ölçümlerini, $w$ değerleri ise bu ölçümlerin ağırlıklarını temsil eder.

Daha genel biçimde, bir test puanını şu şekilde ifade edebiliriz:

Bu formül bize şunu söyler: Her cevap aynı önemde olmak zorunda değildir. Örneğin bir hafıza testinde doğru cevap kadar cevap verme süresi de anlamlı olabilir.

Dinamik DOM manipülasyonu burada sahnenin ışıkçısı gibidir. Kullanıcı bir soruya cevap verdiğinde yeni soru gösterilir, renkler değişir, sonuç ekranı oluşturulur veya zorluk seviyesi artırılır. Böylece sayfa yenilenmeden akıcı bir deney tasarlanır.

Aşağıdaki örnek, basit bir dikkat testi mantığını gösterir. Kullanıcıdan ekranda beliren hedef renge mümkün olduğunca hızlı tıklaması istenir:

const app = document.querySelector('#app');
const colors = ['red', 'blue', 'green', 'purple'];
let startTime = 0;
let results = [];

function newRound() {
  const target = colors[Math.floor(Math.random() * colors.length)];
  startTime = performance.now();

  app.innerHTML = `
    <p>Hedef renk: <strong>${target}</strong></p>
    <div class='grid'>
      ${colors.map(color => `<button class='box' data-color='${color}' style='background:${color}'></button>`).join('')}
    </div>
  `;

  document.querySelectorAll('.box').forEach(button => {
    button.addEventListener('click', () => {
      const reaction = performance.now() - startTime;
      const correct = button.dataset.color === target;
      results.push({ reaction, correct });
      showFeedback(correct, reaction);
    });
  });
}

function showFeedback(correct, reaction) {
  app.innerHTML = `
    <p>${correct ? 'Doğru!' : 'Yanlış!'}</p>
    <p>Tepki süresi: ${Math.round(reaction)} ms</p>
    <button id='next'>Yeni Tur</button>
  `;
  document.querySelector('#next').addEventListener('click', newRound);
}

newRound();

Bu kodda performance.now() milisaniye hassasiyetinde zaman ölçer. Kullanıcının doğru renge tıklayıp tıklamadığı dataset üzerinden kontrol edilir. DOM, her turda yeniden çizilerek testin akışı yönetilir.

Sosyolojik veya psikolojik deneylerde en kritik konu etik tasarımdır. Kullanıcıdan açık rıza alınmalı, veriler anonimleştirilmeli ve sonuçlar kesin tanı gibi sunulmamalıdır. “Zekan 142 çıktı” demek yerine “Bu mini testte hızlı örüntü tanıma eğilimi gösterdin” demek çok daha sağlıklıdır.

Sonuç ekranı da davranış analizi kadar önemlidir. Kullanıcıya grafikler, ortalama tepki süresi ve doğru cevap oranı gösterilebilir. Örneğin doğruluk oranı $D = doğru / toplam$ formülüyle hesaplanır. Bu basit oran, anlaşılır bir geri bildirim üretir.

JavaScript ile tarayıcı üzerinde böyle deneyler tasarlamak; DOM, event yönetimi, veri modelleme ve kullanıcı deneyimi bilgisini aynı projede buluşturur. Küçük başlayın: üç soru, bir sayaç ve basit bir skor ekranı yeterli. Sonra rastgeleleştirme, grafikler, localStorage ve erişilebilirlik ekleyerek projenizi gerçek bir interaktif araştırma aracına dönüştürebilirsiniz.