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.

Dinamik sayfa oluşturmanın temel fikri basittir: kullanıcıdan gelen istek, sunucuda işlenir ve her kullanıcıya bağlama göre farklı bir çıktı döner. Bunu küçük bir formülle düşünebiliriz: $Sayfa = Veri + Yetki + Şablon$. Örneğin aynı konu sayfası, moderatöre silme butonu gösterirken normal üyeye sadece yanıtla butonu gösterebilir.

Bir forumun veritabanı modeli genellikle birkaç ana tablo etrafında döner: kullanıcılar, konular, mesajlar, kategoriler ve roller. Basit ilişki şöyle kurulabilir: bir kullanıcının birçok mesajı vardır, bir konunun birçok mesajı vardır. Matematiksel olarak bunu $User \rightarrow Posts$ ve $Topic \rightarrow Posts$ ilişkileriyle düşünebiliriz. Trafik arttığında sorgu sayısı da önem kazanır; toplam maliyet kabaca $T_{toplam}=T_{sql}+T_{php}+T_{network}$ şeklinde okunabilir.

Güvenli iletişimin kalbi ise hazırlıklı sorgulardır. Kullanıcıdan gelen metni doğrudan SQL cümlesine eklemek, SQL injection davetiyesidir. PDO ile parametre bağlamak, veriyi komut olmaktan çıkarıp yalnızca veri haline getirir.

<?php
$pdo = new PDO(
    'mysql:host=localhost;dbname=forum;charset=utf8mb4',
    'forum_user',
    'secret_password',
    [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
);

$title = trim($_POST['title'] ?? '');
$userId = $_SESSION['user_id'] ?? null;

if ($title === '' || !$userId) {
    http_response_code(400);
    exit('Geçersiz istek');
}

$stmt = $pdo->prepare(
    'INSERT INTO topics (user_id, title, created_at) VALUES (:user_id, :title, NOW())'
);
$stmt->execute([
    'user_id' => $userId,
    'title' => $title
]);

Bu kodun görevi yeni bir konu başlığı eklemektir. Dikkat ederseniz $title doğrudan SQL içine gömülmez; :title parametresine bağlanır. Böylece kullanıcı başlığa garip karakterler yazsa bile sorgunun yapısı bozulmaz.

Dinamik sayfa üretirken güvenlik sadece veritabanı ile bitmez. Mesaj içeriğini ekrana basarken HTML kaçışlama gerekir. Aksi halde biri konuya zararlı JavaScript yazabilir. Basit çıktı örneği:

<p><?= htmlspecialchars($post['body'], ENT_QUOTES, 'UTF-8') ?></p>

Ayrıca forumlar sosyal sistemlerdir; teknik tasarım topluluk davranışını etkiler. Bildirimler, rozetler, beğeniler ve moderasyon kuyrukları sadece özellik değil, katılım mekanizmasıdır. Ancak her yeni özellik yeni veri ilişkileri ve yeni güvenlik kontrolleri demektir.

Modern PHP ekosisteminde Laravel veya Symfony gibi çatılar, yönlendirme, ORM, middleware ve CSRF koruması sunarak bu yükü azaltır. Yine de temeli anlamak önemlidir: istek gelir, kimlik doğrulanır, yetki kontrol edilir, güvenli sorgu çalışır, veri temizlenir ve şablona aktarılır. Kısacası iyi bir topluluk platformu, yalnızca konuşma alanı değil; veritabanı, güvenlik ve kullanıcı deneyiminin dengeli bir orkestrasıdır.

Bu işin teorik temeli üç katmandan oluşur: ilişkisel model, dilsel ön işleme ve semantik yakınlık. İlişkisel modelde her metin; yazar, eser, bölüm, cümle ve token gibi parçalara ayrılır. Dilsel ön işlemede kelimeler küçük harfe çevrilir, noktalama temizlenir, kök veya lemma bulunur. Semantik yakınlıkta ise kelimelerin aynı bağlamlarda görünme sıklığı ölçülür. Basit fikir şudur: İki kavram benzer cümlelerde sık görünüyorsa anlam uzayında birbirine yakındır. ``

Matematiksel olarak birlikte görünme oranını şöyle düşünebiliriz: $P(a,b)=\frac{count(a,b)}{N}$, burada $count(a,b)$ iki kelimenin aynı pencere içinde kaç kez geçtiğini, $N$ ise toplam pencere sayısını gösterir. Daha kullanışlı bir ölçü olan PMI ise $PMI(a,b)=\log\frac{P(a,b)}{P(a)P(b)}$ formülüyle beklenenden güçlü ilişkileri yakalar. Örneğin töz ve nitelik sıradan sıklıkta görünse bile birlikte görünmeleri beklenenden fazlaysa felsefi açıdan anlamlı bir bağ oluşur.

Örnek bir şema şöyle tasarlanabilir: authors, works, sentences, tokens, roots ve co_occurrences. Token tablosu her kelimeyi satır olarak tutar; root tablosu ise etimolojik veya morfolojik kökeni saklar. Böylece hem metinsel hem de tarihsel sorgular yazabiliriz.

-- Aynı kökten gelen kelimelerin filozoflara göre dağılımı
SELECT
  a.name AS philosopher,
  r.root_text AS root,
  COUNT(*) AS usage_count
FROM tokens t
JOIN sentences s ON s.id = t.sentence_id
JOIN works w ON w.id = s.work_id
JOIN authors a ON a.id = w.author_id
JOIN roots r ON r.id = t.root_id
WHERE r.root_text IN ('logos', 'ratio', 'nous')
GROUP BY a.name, r.root_text
ORDER BY usage_count DESC;

Bu sorgu, farklı dillerde akıl, söz, düzen veya ilke anlamlarına yaklaşan kökleri filozof bazında karşılaştırır. Elbette burada felsefi yorum SQL’den çıkmaz; SQL yalnızca izleri görünür kılar. Yorum, araştırmacının tarihsel ve kavramsal bilgisinde başlar.

Daha heyecanlı kısım semantik ağdır. Cümle içinde beş kelimelik bir pencere düşünelim. Eğer özgürlük ile zorunluluk aynı pencerede sık görülüyorsa aralarında kenar oluşur. Aşağıdaki sorgu bu ilişkiyi kabaca çıkarır:

-- Aynı cümlede geçen kavram çiftlerini bulma
SELECT
  t1.lemma AS concept_a,
  t2.lemma AS concept_b,
  COUNT(*) AS co_count
FROM tokens t1
JOIN tokens t2
  ON t1.sentence_id = t2.sentence_id
 AND t1.position < t2.position
 AND ABS(t1.position - t2.position) <= 5
WHERE t1.pos IN ('NOUN', 'ADJ')
  AND t2.pos IN ('NOUN', 'ADJ')
  AND t1.lemma <> t2.lemma
GROUP BY t1.lemma, t2.lemma
HAVING COUNT(*) >= 10
ORDER BY co_count DESC;

Burada position kelimenin cümledeki sırasıdır. ABS ile pencere sınırı belirlenir. Böylece bütün metni torbaya atmak yerine yakın bağlamı dikkate alırız. Bu, Aristoteles’te form-madde çiftini, Spinoza’da töz-kip ilişkisini, Kant’ta deneyim-akıl gerilimini daha görünür hâle getirebilir.

Performans için indeksler şarttır. Devasa metinlerde sentence_id, lemma, root_id ve position alanlarına indeks eklemek sorgu süresini dramatik biçimde azaltır. Ayrıca sık kullanılan sonuçlar materialized view olarak saklanabilir.

CREATE INDEX idx_tokens_sentence_position
ON tokens(sentence_id, position);

CREATE MATERIALIZED VIEW concept_edges AS
SELECT t1.lemma AS source, t2.lemma AS target, COUNT(*) AS weight
FROM tokens t1
JOIN tokens t2 ON t1.sentence_id = t2.sentence_id
WHERE t1.position < t2.position
GROUP BY t1.lemma, t2.lemma;

Sonuçta SQL, felsefeyi otomatikleştiren sihirli bir değnek değildir; daha çok karanlık bir arşivde güçlü bir el feneridir. Hangi kavramların hangi köklerden beslendiğini, hangi eserlerde yoğunlaştığını ve hangi semantik komşularla gezdiğini gösterir. Filozoflar argüman kurar, SQL ise bu argümanların metin içindeki ayak izlerini sabırla sayar.

Alan Turing’in 1950’de önerdiği ünlü “taklit oyunu”, bir makinenin düşünüp düşünmediğini doğrudan sormak yerine daha pratik bir soru sorar: Bir insan değerlendirici, yazılı sohbet üzerinden makineyi insandan ayırt edemezse, makine zeki davranış sergiliyor sayılabilir mi? Bu yaklaşım zekâyı içsel bir özden çok gözlemlenebilir davranış üzerinden ele alır. Yani test, beynin içinde ne olduğunu değil, konuşmanın karşı tarafta nasıl bir izlenim bıraktığını ölçer.

Burada psikoloji devreye girer. İnsan iletişimi yalnızca bilgi aktarımı değildir; niyet, bağlam, bellek, duygu tonu ve beklenti yönetimi içerir. Bir kullanıcı “Bugün berbat geçti” dediğinde iyi bir sistem sadece “Üzgünüm” dememeli; cümlenin duygusal ağırlığını, devam sorusu ihtiyacını ve fazla mekanik görünmeme riskini de hesaba katmalıdır. Bu yüzden modern yapay zekâ sistemlerinde dil modeli kadar “sohbet dinamiği modeli” de önemlidir.

Böyle sistemler geliştirmek için önce konuşmayı parçalara ayırmak gerekir. Niyet tanıma, duygu analizi, bağlam takibi ve cevap üretimi ayrı katmanlar gibi düşünülebilir. Aşağıdaki küçük Python örneği, oyuncak seviyesinde bir sohbet değerlendiricisi kurar. Amaç, cevabın yalnızca anahtar kelimeye değil, duygu tonuna da tepki vermesidir.

class MiniTuringBot:
    def __init__(self):
        self.memory = []

    def detect_emotion(self, text):
        sad_words = ['kötü', 'berbat', 'üzgün', 'yoruldum']
        happy_words = ['harika', 'güzel', 'sevindim', 'başardım']
        if any(word in text.lower() for word in sad_words):
            return 'sad'
        if any(word in text.lower() for word in happy_words):
            return 'happy'
        return 'neutral'

    def reply(self, user_text):
        emotion = self.detect_emotion(user_text)
        self.memory.append(user_text)

        if emotion == 'sad':
            return 'Bunu yaşaman zor olmalı. İstersen ne olduğunu birlikte açabiliriz.'
        if emotion == 'happy':
            return 'Bu güzel haber! Sence bunu mümkün kılan en önemli şey neydi?'
        return 'Anladım. Biraz daha detay verirsen daha iyi takip edebilirim.'

bot = MiniTuringBot()
print(bot.reply('Bugün gerçekten berbat geçti'))

Bu kod “zeki” değildir; fakat önemli bir fikri gösterir: İnsan benzeri sohbet, tek seferlik cevaplardan değil, durum değerlendirmesinden oluşur. Gerçek sistemlerde bu yapı büyük dil modelleri, vektör veritabanları, kullanıcı profilleri ve güvenlik filtreleriyle genişletilir. Yine de temel soru değişmez: Cevap, karşıdaki kişinin zihinsel durumuna uygun mu?

Turing Testi’nin en eğlenceli tarafı, bizi “zeka nedir?” sorusundan “zeki görünmek ne demektir?” sorusuna taşır. Bu ikisi aynı şey değildir. Bir sistem insanı kandırabilir ama gerçekten anlamıyor olabilir; yine de pratik yazılım geliştirmede kullanıcı deneyimi açısından bu inandırıcılık değerlidir. Özellikle eğitim, müşteri desteği, terapi destek araçları ve oyun karakterlerinde dilin psikolojik dokusu kritik hale gelir.

Sonuç olarak Turing Testi, yapay zekâ geliştiricilerine hâlâ güçlü bir pusula sunar. Daha iyi modeller kurmak istiyorsanız sadece algoritmaya değil, insanın konuşurken yaptığı küçük bilişsel numaralara da bakın: ima, tereddüt, bağlam, duygu ve hatırlama. Çünkü bazen bir botu inandırıcı yapan şey en doğru cevabı vermesi değil, doğru anda “hmm, bunu biraz açalım” diyebilmesidir.