``

Aralıklı tekrar neden işe yarar?

Hermann Ebbinghaus’un unutma eğrisi, bir bilginin hatırlanma gücünün zamanla üstel biçimde azaldığını öne sürer. Basitleştirilmiş bir model şöyledir:

Burada $R(t)$ hatırlama olasılığını, $t$ son çalışmadan beri geçen süreyi, $S$ ise anının dayanıklılığını temsil eder. Aynı kelimeyi başarıyla hatırladıkça $S$ büyür; böylece tekrarlar arasındaki süre uzatılabilir.

Örneğin “serendipity” kelimesini ilk gün öğrendiğimizi düşünelim. İlk tekrar bir gün sonra, sonraki tekrar üç gün sonra, ardından sekiz veya on gün sonra yapılabilir. Amaç, kartı tamamen unutmadan hemen önce göstermektir. Çok erken tekrar zaman kaybettirir, çok geç tekrar ise öğrenme sürecini başa sarar.

AnkiWeb, Mochi ve Mnemosyne karşılaştırması

Bu araçların ortak hedefi aynı olsa da kullanıcı deneyimleri ve veri modelleri farklıdır:

Anki ekosistem ve özelleştirme konusunda öne çıkar. Mochi, kartları birbirine bağlayarak kişisel bilgi ağı kurmayı kolaylaştırır. Mnemosyne ise daha sade ve akademik bir yaklaşım sunar. Kısacası Anki bir kontrol paneli, Mochi dijital bahçe, Mnemosyne ise sakin bir çalışma masası gibidir.

Temel veri modeli

Kendi sistemimizde her kart için kelime, anlam, örnek cümle, tekrar tarihi, kolaylık katsayısı ve tekrar sayısı saklanabilir. Ayrıca öğrenme yönünü değiştirmek yararlıdır: “apple → elma” kartı tanımayı, “elma → apple” kartı ise aktif hatırlamayı ölçer.

Basit bir kart modeli şu alanları içerebilir:

• front: Sorulan kelime veya ipucu
• back: Anlam ve örnek cümle
• interval: Bir sonraki tekrara kalan gün
• ease: Kartın kişisel zorluk katsayısı
• due: Gösterileceği tarih

Basitleştirilmiş SM-2 zamanlayıcısı

Aşağıdaki Python fonksiyonu, kullanıcının 0 ile 5 arasındaki cevabına göre yeni tekrar aralığını hesaplar:

def schedule_card(quality, repetitions, interval, ease):
    # 3'ten düşük puan, kartın hatırlanamadığını gösterir.
    if quality < 3:
        repetitions = 0
        interval = 1
    else:
        repetitions += 1

        if repetitions == 1:
            interval = 1
        elif repetitions == 2:
            interval = 6
        else:
            interval = round(interval * ease)

    # Başarılı cevap kolaylığı artırır, zor cevap azaltır.
    ease += 0.1 - (5 - quality) * (0.08 + (5 - quality) * 0.02)
    ease = max(1.3, ease)

    return repetitions, interval, ease

print(schedule_card(4, 2, 6, 2.5))

Fonksiyon kart unutulduğunda programı sıfırlar; doğru cevaplarda ise mevcut aralığı kolaylık katsayısıyla büyütür. $I_{yeni} = I_{eski} \times E$ ilişkisi, uzun vadede tekrar sayısını ciddi biçimde azaltır. Gerçek bir uygulamada saat dilimi, günlük kart sınırı, gecikmiş tekrarlar ve kullanıcı alışkanlıkları da hesaba katılmalıdır.

İyi bir sistemin sırrı

Algoritma tek başına mucize yaratmaz. Kartlar kısa olmalı, tek bir bilgiyi sınamalı ve kelimeyi bağlam içinde göstermelidir. Görsel, ses kaydı ve gerçek bir örnek cümle hatırlamayı güçlendirir. En iyi araç; en gelişmiş formüle sahip olan değil, her gün açmayı unutmadığınız araçtır. Beş dakikalık düzenli tekrar, pazar gecesi yapılan iki saatlik kelime maratonunu çoğu zaman rahatça yener.

``

Mekanik hesaplamanın doğuşu

Bilgisayarların uzak atalarından biri, 1642 yılında Blaise Pascal tarafından geliştirilen Pascaline adlı mekanik hesap makinesiydi. Dişli çarklar kullanan bu cihaz toplama ve çıkarma yapabiliyordu. Gottfried Wilhelm Leibniz ise 1670’lerde sistemi geliştirerek çarpma ve bölme işlemlerini de mekanikleştirdi.

Bu makinelerin temel fikri, sayıları fiziksel konumlarla temsil etmekti. Örneğin bir çarkın on farklı konumu, 0 ile 9 arasındaki rakamlara karşılık geliyordu. Günümüzde aynı yaklaşım elektrik sinyalleriyle uygulanır; ancak on durum yerine çoğunlukla iki durum kullanılır:

Mekanik sistemlerde hareket eden parçalar bilgiyi taşırken modern bilgisayarlarda bu görevi gerilim seviyeleri üstlenir.

Programlanabilir makine fikri

1800’lerin başında Joseph Marie Jacquard, dokuma tezgâhlarını delikli kartlarla kontrol etti. Kartlardaki delikler bir tür komut dizisi oluşturuyordu. Charles Babbage bu fikirden etkilenerek 1837’de Analitik Makine tasarımını ortaya koydu.

Babbage’ın makinesi tamamlanamamış olsa da işlem birimi, bellek, giriş ve çıkış gibi modern bilgisayar bileşenlerini teorik olarak içeriyordu. Ada Lovelace ise makinenin Bernoulli sayılarını hesaplaması için bir algoritma hazırladı ve tarihin ilk bilgisayar programcısı kabul edildi.

Elektronik bilgisayarlar sahneye çıkıyor

1940’larda mekanik parçaların yerini röleler ve vakum tüpleri aldı. 1946’da tanıtılan ENIAC, yaklaşık 18.000 vakum tüpü kullanıyor ve saniyede binlerce işlem gerçekleştirebiliyordu. Ne var ki devasa boyutlu, enerji oburu ve arızaya yatkındı.

Transistör ve mikroişlemci devrimi

1947’de transistörün geliştirilmesi bilgisayarları küçülttü, hızlandırdı ve daha güvenilir hâle getirdi. Ardından çok sayıda transistörün aynı yüzeye yerleştirildiği entegre devreler ortaya çıktı. 1971’de Intel 4004, ticari açıdan başarılı ilk mikroişlemcilerden biri oldu.

İşlemci performansı kabaca saat frekansı, çekirdek sayısı ve saat başına tamamlanan komut miktarıyla ilişkilendirilebilir:

Burada $f$ frekansı, $C$ çekirdek sayısını, $IPC$ ise döngü başına işlenen komut sayısını temsil eder. Gerçek performans bellek, önbellek ve yazılım tasarımından da etkilenir.

İkili sistemin temel mantığını küçük bir Python örneğiyle görebiliriz:

def ikili_topla(a, b):
    # Metin biçimindeki ikili sayıları onlu sisteme çevirir.
    toplam = int(a, 2) + int(b, 2)

    # Sonucu yeniden ikili gösterime dönüştürür.
    return bin(toplam)[2:]

print(ikili_topla("1010", "0111"))  # 10001

Bu kod, işlemcideki gerçek mantık kapılarının yaptığı işi soyut düzeyde taklit eder. Donanımda toplama; AND, OR ve XOR gibi devrelerle gerçekleştirilir.

Günümüz: Paralellik ve uzmanlaşma

Transistör sayısının yaklaşık iki yılda bir artacağını öngören Moore Yasası, onlarca yıl boyunca sektöre yön verdi. Fiziksel küçülmenin zorlaşmasıyla üreticiler yalnızca frekansı artırmak yerine çok çekirdekli mimarilere yöneldi. GPU’lar grafik işlemlerinin yanında yapay zekâ ve bilimsel hesaplama için kullanılmaya başlandı. NPU gibi özel birimler ise belirli görevleri daha az enerjiyle tamamlıyor.

Kısacası bilgisayarın gelişimi, “daha hızlı hesaplama” arzusundan “doğru işi doğru donanımla yapma” anlayışına evrildi. Pascal’ın çarklarından modern işlemcilerin nanometre ölçeğindeki transistörlerine kadar değişmeyen temel amaç ise aynı kaldı: bilgiyi temsil etmek, kurallara göre işlemek ve anlamlı sonuç üretmek.

``

Aralıklı tekrar neden işe yarar?

İnsan belleği, kullanılmayan bilgiyi zamanla silikleştirir. Basitleştirilmiş bir unutma eğrisi şu şekilde gösterilebilir:

Burada $R(t)$ bilgiyi hatırlama olasılığı, $t$ son tekrardan beri geçen süre, $S$ ise belleğin dayanıklılığıdır. Bir kartı başarıyla hatırladığımızda $S$ büyür; böylece bir sonraki tekrar daha ileri bir tarihe taşınabilir.

Basit bir planlayıcı, yeni aralığı yaklaşık olarak şöyle hesaplayabilir:

$I$ tekrar aralığını, $E$ kartın kolaylık katsayısını, $P$ ise kullanıcının verdiği performans puanını temsil eder. Gerçek uygulamalar başarısızlıkları, gecikmiş tekrarları ve öğrenme geçmişini hesaba katan daha gelişmiş modeller kullanır. Dolayısıyla amaç her kartı her gün göstermek değil, unutmaya yaklaşırken göstermektir.

Üç uygulama, üç farklı karakter

Anki: Ayar panelini sevenlerin laboratuvarı

Anki; kart şablonları, etiketler, medya desteği ve eklentileriyle oldukça esnektir. Modern sürümlerde FSRS gibi, geçmiş tekrar verilerinden yararlanarak daha verimli aralıklar üretmeyi amaçlayan zamanlama seçenekleri bulunur. Buna karşılık ilk deste hazırlamak, alanlarla şablonların farkını anlamak ve ayarları düzenlemek başlangıçta yorucu olabilir.

Dil öğrenenler, tıp öğrencileri ve binlerce kart yöneten kullanıcılar için güçlü bir seçenektir. Fakat her ayarı değiştirmek zorunda değilsiniz; varsayılanlarla başlayıp gerçek ihtiyaca göre ilerlemek daha sağlıklıdır.

Mnemosyne: Gösterişsiz ama disiplinli

Adını Yunan mitolojisindeki hafıza tanrıçasından alan Mnemosyne, aralıklı tekrar dünyasının köklü araçlarındandır. Arayüzü modern uygulamalar kadar parlak görünmeyebilir; buna karşın kart oluşturma ve puanlama akışı nettir. Açık kaynak yaklaşımı ve araştırma odaklı geçmişi önemli avantajlarıdır.

“Not sistemi değil, yalnızca düzgün çalışan bir tekrar aracı istiyorum” diyorsanız Mnemosyne mantıklı bir adaydır. Daha küçük eklenti ekosistemi ve sınırlı görsel cilası ise bazı kullanıcıları Anki veya Mochi’ye yöneltebilir.

Mochi: Not alırken kart üretmek

Mochi, Markdown notları ile flashcard sistemini aynı ortamda buluşturur. Kartlar arasında bağlantı kurabilmek, tek tek gerçekleri ezberlemek yerine kavram ağı oluşturmayı kolaylaştırır. Özellikle yazılım, tarih veya felsefe gibi ilişkisel konularda bu yaklaşım değerlidir.

Ancak zengin bağlantılar kurmak, otomatik olarak iyi öğrenme anlamına gelmez. Kartlar kısa, açık ve tek bir bilgiyi ölçer durumda olmalıdır. Ayrıca çevrim içi özellikler ve ücretlendirme seçenekleri zamanla değişebileceğinden güncel planlar kontrol edilmelidir.

Mini bir zamanlayıcı nasıl çalışır?

Aşağıdaki Python kodu, doğru yanıtta aralığı büyüten, yanlış yanıtta kartı ertesi güne döndüren basitleştirilmiş bir modeldir:

def sonraki_aralik(mevcut_gun, puan, kolaylik=2.2):
    # 0-2 başarısız, 3-5 başarılı kabul edilir.
    if puan < 3:
        return 1

    performans = 0.8 + (puan - 3) * 0.2
    yeni_aralik = mevcut_gun * kolaylik * performans
    return max(1, round(yeni_aralik))

print(sonraki_aralik(7, 4))  # Yaklaşık 15 gün

Bu örnek öğreticidir; gerçek planlayıcılar çok daha fazla veri kullanır. Yine de temel fikir açıktır: başarı aralığı büyütür, başarısızlık kartı yaklaştırır.

Hangisini seçmeli?

Maksimum özelleştirme ve büyük deste yönetimi için Anki, sade ve açık kaynaklı bir çalışma düzeni için Mnemosyne, bağlantılı Markdown notlarıyla öğrenmek için Mochi öne çıkar. En iyi sistem, en gelişmiş algoritmaya sahip olan değil, her gün açmayı sürdürebildiğiniz sistemdir. Önce 20 kartlık küçük bir deste hazırlayın, bir hafta deneyin ve kararınızı gerçek çalışma alışkanlığınıza göre verin.

``

Rastgelelik gerçekte ne anlama gelir?

Bir sistemde $N$ adet soru varsa ve sınav için bunlardan $k$ tanesi eşit olasılıkla seçiliyorsa, belirli bir sorunun sınava girme olasılığı yaklaşık olarak

olur. Örneğin 100 soruluk havuzdan 20 soru seçildiğinde her sorunun sınavda görünme olasılığı $0.20$ seviyesindedir. Ancak gerçek kalite yalnızca rastgele seçimden gelmez. Zorluk, konu dağılımı ve öğrenme çıktıları da dengelenmelidir.

Daha kontrollü bir modelde sınav; 4 kolay, 4 orta ve 2 zor sorudan oluşturulabilir. Buna katmanlı rastgele seçim denir. Böylece bir öğrenci tamamen kolay, başka biri tamamen zor bir sınavla karşılaşmaz.

Üç yaklaşımın karşılaştırması

H5P ile hızlı etkileşim

H5P; Multiple Choice, Fill in the Blanks ve Question Set gibi içerik türleriyle çalışır. Seçenek sıralaması karıştırılabilir ve bir soru setinden belirli sayıda içerik gösterilebilir. En büyük avantajı, öğrencinin anında geri bildirim almasıdır.

Bununla birlikte H5P çoğunlukla önceden hazırlanmış içerikleri rastgele sunar. Örneğin her seferinde farklı katsayılara sahip bir denklem oluşturmak istiyorsanız ek JavaScript geliştirmesi veya harici bir servis gerekebilir.

Moodle Question Bank ile kontrollü seçim

Moodle soruları kategoriler altında saklayabilir. “Cebir/Kolay” ve “Cebir/Zor” gibi kategoriler oluşturup sınava her kategoriden rastgele soru eklemek mümkündür. Ayrıca Calculated Question türü, değişkenleri belirli aralıklardan seçerek parametrik sorular üretir.

Örneğin $a$ ve $b$ rastgele seçildiğinde öğrenciye $a+b$ sorulabilir. $a \in [2,10]$ ve $b \in [5,20]$ tanımlanırsa sistem çok sayıda varyasyon oluşturur. Tolerans, birim ve ondalık hassasiyeti gibi ayrıntılar da Moodle üzerinden yönetilebilir.

Özel algoritma nasıl kurulur?

Basit bir JavaScript fonksiyonu, iki katsayı seçip birinci dereceden denklem üretebilir:

function denklemUret() {
  const x = Math.floor(Math.random() * 9) + 1;
  const a = Math.floor(Math.random() * 8) + 2;
  const b = Math.floor(Math.random() * 20) + 1;

  return {
    soru: `${a}x + ${b} = ${a * x + b} denkleminde x kaçtır?`,
    cevap: x
  };
}

console.log(denklemUret());

Kod önce doğru cevabı belirler, ardından bu cevaba uygun denklem kurar. Bu yaklaşım önemlidir; rastgele bir soru üretip sonradan çözmeye çalışmak yerine, cevaptan soruya doğru üretim hatalı veya çözümsüz örneklerin önüne geçer.

Adil ve güvenilir bir sistem için

Gerçek sınavlarda sözde rastgele sayı üreteci için bir seed saklamak yararlıdır. Aynı seed kullanıldığında aynı sınav yeniden oluşturulabilir; böylece öğrenci itirazları incelenebilir. Ayrıca algoritma şu kontrollerden geçmelidir:

• Aynı sorunun sınav içinde tekrarlanmaması
• Yanlış seçeneklerin doğru cevaptan farklı olması
• Zorluk dağılımının korunması
• Üretilen değerlerin anlamlı aralıklarda kalması
• Soru sürümlerinin ve seed bilgilerinin kaydedilmesi

Hızlı ve görsel etkinliklerde H5P, kurumsal sınavlarda Moodle, benzersiz ve uyarlanabilir senaryolarda ise özel algoritmalar öne çıkar. En güçlü çözüm çoğu zaman bunları yarıştırmak değil, H5P’nin etkileşimini Moodle’ın soru bankası ve özel bir üretim servisinin esnekliğiyle birleştirmektir.

``

Sistemin temel mantığı

Platformu üç katmanlı düşünmek işleri kolaylaştırır. H5P, sorunun kullanıcıya nasıl sunulacağını belirler. Moodle; kullanıcı, ders, yetki, not ve raporlama süreçlerini yönetir. Özel soru bankası ise soruların kategorilerini, zorluk seviyelerini, sürümlerini ve istatistiklerini saklar.

Bir sorunun zorluk değeri yalnızca geliştiricinin tahminiyle belirlenmemelidir. Kullanıcıların başarı oranından yararlanılabilir. Bir soruyu $N$ kişi çözmüş ve $D$ kişi doğru cevaplamışsa kolaylık indeksi şöyle hesaplanır:

$p$ değeri 1’e yaklaştıkça soru kolaylaşır. Zorluk puanını $z = 1-p$ olarak tanımlarsak yüksek değerler daha zor soruları temsil eder. Örneğin 100 kişiden 25’i doğru cevap verdiyse $p=0.25$ ve $z=0.75$ olur.

Hangi bileşen ne yapmalı?

H5P içeriği Moodle içine eklentiyle yerleştirilebilir. Ancak sorular farklı uygulamalarda da kullanılacaksa içerikleri yalnızca H5P dosyalarında tutmak yerine merkezi bir API üzerinden sunmak daha sağlıklıdır. Böylece mobil uygulama, web sitesi ve Moodle aynı kaynaktan beslenir.

Örnek soru veri modeli

Aşağıdaki JavaScript nesnesi, çoktan seçmeli bir mantık sorusunun sadeleştirilmiş veri yapısını gösterir:

const question = {
  id: "logic-1042",
  type: "multiple-choice",
  category: "örüntü",
  difficulty: 0.65,
  prompt: "2, 6, 12, 20 dizisindeki sonraki sayı nedir?",
  options: [28, 30, 32, 36],
  correctIndex: 1,
  explanation: "Terimler n × (n + 1) düzenini izler.",
  timeLimit: 45,
  tags: ["matematik", "örüntü"]
};

Bu modelde difficulty uyarlanabilir test üretmek, explanation öğretici geri bildirim göstermek, timeLimit ise süreye dayalı puanlama yapmak için kullanılır. API, bu veriyi H5P’ye uygun biçime dönüştürebilir veya doğrudan özel arayüzde gösterebilir.

Puanlama ve oyunlaştırma

Sadece doğru cevaba puan vermek, rastgele tahminleri ödüllendirebilir. Süreyi ve ipucu kullanımını hesaba katan bir formül daha dengelidir:

Burada $B$ temel puan, $d$ zorluk çarpanı, $t$ harcanan süre, $T$ süre sınırı ve $h$ kullanılan ipucu sayısıdır. max bölümü, doğru fakat yavaş çözümlerin tamamen puansız kalmasını önler. Rozetler, günlük seriler ve kategori bazlı seviyeler de motivasyonu artırabilir; fakat liderlik tablosu zorunlu olmamalıdır.

Uygulama yol haritası

İlk sürümde Moodle kurulumu, H5P eklentisi, kullanıcı girişi ve temel soru API’si hazırlanmalıdır. İkinci aşamada soru editörü, sürümleme, ayrıntılı çözüm açıklamaları ve zorluk analizi eklenebilir. Son aşamada uyarlanabilir sınav motoru devreye girer: Kullanıcı doğru cevapladıkça daha zor, zorlandıkça daha öğretici sorular seçilir.

Ayrıca soru metinleri kullanıcı girdisi içeriyorsa XSS filtreleri uygulanmalı, API erişimi yetkilendirilmeli ve deneme kayıtları kişisel verilerden ayrıştırılmalıdır. Böylece platform, “birkaç bilmece yayınlayan site” olmaktan çıkıp ölçülebilir, genişletilebilir ve gerçekten öğretici bir öğrenme ekosistemine dönüşür.

Bir metni başka bir dile çevirmek kolay görünür: kelimeyi bul, karşılığını yaz, kahveni yudumla! Gerçekteyse dil; bağlam, sözcük sırası, çekim ve kültürel ifadelerle dolu karmaşık bir sistemdir. Açık kaynak dünyasında LibreTranslate, Argos Translate ve Apertium bu probleme farklı katmanlardan yaklaşır. Biri kullanışlı bir web API’si sunarken diğeri çevrimdışı sinir ağı modellerine, ötekiyse dilbilgisi kurallarına güvenir.

``

Makine çevirisinin temel mantığı

Makine çevirisi sistemleri genel olarak kural tabanlı, istatistiksel veya sinir ağı tabanlı çalışır. Kural tabanlı yöntemde kaynak cümle sözcük ve biçimbirimlerine ayrılır; ardından sözlükler ile dilbilgisi kuralları uygulanır. Sinir ağı tabanlı yöntemdeyse model, bütün cümlenin bağlamını sayısal vektörlerle temsil ederek hedef cümleyi üretir.

Bir sinir ağı modelinde en olası çeviri basitleştirilmiş biçimde şöyle aranır:

Burada $X$ kaynak cümleyi, $Y$ olası hedef cümleyi ve $\hat{Y}$ modelin seçtiği çeviriyi ifade eder. Model yalnızca kelime karşılıklarını değil, hedef dilde doğal görünme olasılığını da hesaba katar.

Üç araç arasındaki farklar

LibreTranslate

LibreTranslate, kendi sunucunuza kurabileceğiniz açık kaynaklı bir çeviri API’sidir. Tarayıcı arayüzü bulunsa da asıl yıldızı REST API desteğidir. Verilerin üçüncü taraf bir servise gönderilmemesi; şirket içi belgeler, kişisel notlar ve eğitim projeleri için önemli bir avantajdır.

Aşağıdaki Python kodu, çalışan bir LibreTranslate sunucusuna istek gönderir:

import requests

payload = {
    "q": "Açık kaynak yazılımlar özgürlük sağlar.",
    "source": "tr",
    "target": "en",
    "format": "text"
}

response = requests.post(
    "http://localhost:5000/translate",
    json=payload,
    timeout=30
)

response.raise_for_status()
print(response.json()["translatedText"])

Kod, kaynak metni ve dil kodlarını JSON olarak API’ye yollar; dönen sonuçtan çevrilmiş metni çıkarır. Üretim ortamında zaman aşımı, kimlik doğrulama ve hata yönetimi ayrıca planlanmalıdır.

Argos Translate

Argos Translate, indirilebilir dil paketleriyle tamamen yerel çalışabilir. İnternet bağlantısı olmadan çeviri yapması hem gizlilik hem de taşınabilirlik sağlar. Ancak bir dil çiftinin desteklenmesi için uygun model paketinin kurulması gerekir. Ayrıca doğrudan bir model yoksa Türkçeden belirli bir dile çeviri, İngilizce gibi ara bir dil üzerinden gerçekleştirilebilir. Bu zincirleme yaklaşım erişimi artırırken hataları da biriktirebilir.

Apertium

Apertium’un dünyası biraz daha “dilbilim laboratuvarı” gibidir. Sistem sözlükler, biçimbirimsel çözümleyiciler ve aktarım kuralları kullanır. Özellikle İspanyolca–Katalanca gibi yapısal olarak yakın dillerde güçlü sonuçlar verebilir. Kurallar incelenebilir ve düzeltilebilir; buna karşılık yeni bir dil çifti hazırlamak ciddi dilbilim emeği ister.

Kaliteyi nasıl değerlendirmeli?

Çeviri kalitesi yalnızca “doğru görünüyor” hissiyle ölçülmez. BLEU gibi metrikler, üretilen çevirideki sözcük dizilerini referans çevirilerle karşılaştırır. Yine de yüksek puan her zaman doğal veya anlamca kusursuz sonuç demek değildir. Deyimler, teknik terimler ve alan bilgisi için insan değerlendirmesi gereklidir.

Hızlı bir API ve kolay entegrasyon istiyorsanız LibreTranslate, gömülü ya da çevrimdışı bir çözüm arıyorsanız Argos Translate, kuralları denetlemek ve yakın diller üzerinde çalışmak istiyorsanız Apertium mantıklı seçimdir. Kısacası en iyi araç mutlak değildir; dil çiftine, donanıma, gizlilik beklentisine ve “bu cümle neden böyle çevrildi?” sorusuna ne kadar ayrıntılı cevap istediğinize bağlıdır.

``

Akış şemasının temel mantığı

Akış şeması, bir süreci düğümler ve bu düğümler arasındaki yönlendirilmiş bağlantılar ile temsil eder. Matematiksel olarak bir şemayı $G=(V,E)$ biçiminde düşünebiliriz. Burada $V$ işlem, karar veya başlangıç gibi düğümleri; $E$ ise düğümler arasındaki geçişleri ifade eder.

Örneğin kullanıcı girişini denetleyen bir süreçte düğümler; “bilgileri al”, “doğru mu?” ve “paneli aç” olabilir. Karar düğümünden iki farklı yol çıkması, algoritmadaki if/else yapısının görsel karşılığıdır.

Bir şemadaki olası yürütme yollarının sayısı karar noktalarıyla büyür. Her karar iki seçeneğe sahipse, kaba bir üst sınır olarak $P=2^d$ yazılabilir. Buradaki $d$, karar düğümü sayısıdır. Beş karar noktası teorik olarak $2^5=32$ farklı yol oluşturabilir. Şemalar tam da bu karmaşıklığı fark etmeyi kolaylaştırır.

Üç aracın kısa karşılaştırması

draw.io: Görsel özgürlük

draw.io, günümüzde diagrams.net adıyla da bilinen görsel bir diyagram aracıdır. Kutuları çalışma alanına bırakır, okları bağlar ve renkleri arayüz üzerinden ayarlarsınız. Teknik sözdizimi öğrenmek istemeyen ekipler için oldukça rahattır.

En büyük avantajı, karmaşık yerleşimleri elle hassas biçimde düzenleyebilmenizdir. Ağ topolojileri, organizasyon şemaları ve bulut mimarileri için geniş bir şekil kütüphanesi sunar. Buna karşılık XML tabanlı dosyalarında yapılan değişiklikleri Git karşılaştırmalarında okumak pek keyifli değildir. “Kutuyu üç piksel sola aldım” değişikliği, kod incelemesinde küçük bir destana dönüşebilir.

Mermaid: Markdown’ın diyagram arkadaşı

Mermaid, diyagramları kısa bir metinle tanımlamanızı sağlar. GitHub ve birçok dokümantasyon sistemi tarafından desteklenmesi önemli bir avantajdır.

flowchart TD
    A[Bilgileri al] --> B{Bilgiler doğru mu?}
    B -- Evet --> C[Paneli aç]
    B -- Hayır --> D[Hata göster]
    D --> A

Bu kod; giriş bilgilerini alan, doğrulama yapan ve sonuca göre yönlenen bir akış üretir. Metin tabanlı olduğu için değişiklikler Git üzerinde satır satır izlenebilir. Ancak çok büyük şemalarda otomatik yerleşim her zaman hayalinizdeki estetik sonucu vermeyebilir.

PlantUML: Diyagramların İsviçre çakısı

PlantUML; akışların yanında sınıf, sıra, durum ve bileşen diyagramları üretmekte güçlüdür. Sözdizimi Mermaid’e göre biraz daha ayrıntılıdır, fakat büyük yazılım sistemlerinde daha fazla kontrol sağlar.

@startuml
start
:Bilgileri al;
if (Bilgiler doğru mu?) then (Evet)
  :Paneli aç;
else (Hayır)
  :Hata göster;
endif
stop
@enduml

Burada start ve stop sürecin sınırlarını, if bloğu karar noktasını, iki nokta arasındaki ifadeler ise işlem adımlarını belirtir. Kod dokümantasyon deposunda saklanabilir ve otomatik derleme süreçlerinde PNG veya SVG çıktısına dönüştürülebilir.

Hangisini seçmeli?

Toplantıda hızlıca kutu çizmek, özel ikonlar kullanmak ve görsel kontrolü tamamen elinizde tutmak istiyorsanız draw.io iyi seçimdir. README veya teknik belgelerde küçük ve sürümlenebilir şemalar gerekiyorsa Mermaid daha pratiktir. UML ağırlıklı, kapsamlı ve otomatik üretilecek mimari dokümantasyon içinse PlantUML öne çıkar.

Kısacası en iyi araç mutlak değildir: Şemanız sunum odaklıysa fareyi, dokümantasyon odaklıysa kodu seçin. Hatta ekipler çoğu zaman ilk taslağı draw.io ile hazırlayıp kalıcı teknik belgeyi Mermaid veya PlantUML ile yeniden üreterek üç dünyanın da avantajından yararlanabilir.

``

Önce temel mantık: Bağış sistemi nasıl çalışır?

Tipik bir bağış akışı; bağışçı, form, ödeme sağlayıcısı, işlem kaydı ve raporlama katmanlarından oluşur. Kullanıcı formu doldurduğunda sistem ödeme sağlayıcısına bir istek gönderir. Başarılı işlem sonrasında bağış kaydedilir, makbuz oluşturulur ve gerekiyorsa bağışçıya otomatik e-posta gönderilir.

Bir kampanyanın net geliri basitçe şöyle modellenebilir:

Burada $o_{komisyon}$ ödeme sağlayıcısının oransal kesintisini, $M_{sabit}$ işlem başına sabit maliyetleri temsil eder. Dolayısıyla yalnızca yazılımın fiyatını değil, ödeme komisyonlarını ve operasyon yükünü de karşılaştırmak gerekir.

Üç sistemin karakteri

CiviCRM: Kurumsal hafıza isteyenlere

CiviCRM yalnızca ödeme almakla kalmaz; bağışçıları, üyelikleri, etkinlikleri, e-postaları ve geçmiş etkileşimleri tek profilde toplar. Drupal, Joomla veya WordPress ile çalışabilir. Özellikle aynı destekçiyle yıllar boyunca ilişki kuran kuruluşlar için güçlüdür.

Bunun karşılığında kurulum ve bakım daha zahmetlidir. Veri modeli, roller, izinler ve zamanlanmış görevler doğru yapılandırılmalıdır. Küçük bir kampanya için ağır gelebilir; fakat binlerce kişiyle çalışan bir STK için adeta dijital genel merkezdir.

GiveWP: WordPress içinde pratik çözüm

GiveWP, mevcut WordPress sitesini bağış platformuna dönüştürür. Kampanya formları, hedef göstergeleri, bağışçı panelleri ve tekrarlayan ödeme özellikleri sunar. İçerik ekibinin WordPress’e aşina olması önemli bir avantajdır.

Basit bir entegrasyon mantığı şu şekilde düşünülebilir:

add_action('give_insert_payment', function ($payment_id) {
    $amount = give_get_payment_total($payment_id);
    error_log('Yeni bağış tutarı: ' . $amount);
});

Bu örnek, yeni ödeme kaydedildiğinde bağış tutarını günlük dosyasına yazar. Gerçek projede aynı kanca CRM bildirimi göndermek veya özel bir teşekkür süreci başlatmak için kullanılabilir. Ancak ücretli eklentiler, ödeme ağ geçitleri ve WordPress güvenliği toplam maliyete eklenmelidir.

Open Collective: Şeffaflık varsayılan ayar

Open Collective özellikle açık kaynak projeleri, yerel topluluklar ve gayriresmî gruplar için dikkat çekicidir. Gelirler ve giderler herkese açık gösterilebilir. Bir mali sponsor kullanıldığında topluluk, ayrı bir tüzel kişilik kurmadan para kabul etme ve harcama olanağı bulabilir.

Platformun en güçlü tarafı şeffaflıktır; ancak klasik CRM özellikleri veya tamamen özelleştirilebilir bağış deneyimi bekleyen kuruluşlar için sınırlı kalabilir.

Hangisini seçmeli?

Karar verirken bağış hacmi, ekip kapasitesi, veri gizliliği ve raporlama gereksinimleri birlikte değerlendirilmelidir. Kısacası CiviCRM ilişkiyi, GiveWP dönüşümü, Open Collective ise güveni ve şeffaflığı merkeze koyar. En iyi sistem en fazla özelliğe sahip olan değil, kuruluşunuzun günlük iş akışına en az sürtünmeyle uyum sağlayandır.

Birim dönüştürme uygulamaları ilk bakışta yalnızca “metreyi kilometreye böl” seviyesinde görünür. Ancak sıcaklık, alan, hacim, hız ve türetilmiş bilimsel birimler işin içine girince küçük hesap makinemiz adeta laboratuvar önlüğü giymeye başlar. ConvertAll yaklaşımını örnek alan ve MathJS kullanan bir web sitesi; kullanıcıya esnek, güvenilir ve genişletilebilir bir dönüştürme deneyimi sunabilir. ``

Birim dönüşümünün temel mantığı

Aynı fiziksel büyüklüğü temsil eden birimler arasında genellikle bir ölçek katsayısı bulunur. Örneğin metre ile santimetre arasındaki ilişki şöyledir:

Dolayısıyla $x$ metreyi santimetreye dönüştürmek için $x \times 100$ hesaplanır. Genel doğrusal dönüşüm modeli şu şekilde ifade edilebilir:

Burada $a$ ölçek katsayısı, $b$ ise başlangıç noktası farkıdır. Uzunluk dönüşümlerinde çoğunlukla $b=0$ olur. Sıcaklıkta ise durum farklıdır. Celsius’tan Fahrenheit’a dönüşüm:

Bu ayrım önemlidir; her birimi yalnızca bir sayıyla çarpmak doğru sonuç üretmez.

ConvertAll yaklaşımı nedir?

ConvertAll, kullanıcının kaynak ve hedef birimleri özgürce seçebilmesini sağlayan masaüstü odaklı bir dönüştürme aracıdır. En güçlü fikri, yalnızca hazır dönüşüm düğmeleri sunmak yerine birim ifadelerini ayrıştırmasıdır. Böylece km/hour, meter/second veya kg*m/s^2 gibi bileşik ifadeler anlamlandırılabilir.

Bir web projesinde aynı yaklaşımı uygulamak için üç temel katman gerekir:

1. Kullanıcı ifadesini ayrıştıran giriş katmanı,
2. Birimlerin uyumluluğunu denetleyen hesaplama motoru,
3. Sonucu anlaşılır biçimde gösteren arayüz.

Kütle ile uzunluğu dönüştürmeye çalışmak matematiksel olarak anlamsızdır. Sistem, 5 kg → metre isteğine rastgele bir sayı vermek yerine boyut uyuşmazlığı hatası göstermelidir.

MathJS ile dönüşüm motoru

MathJS; JavaScript için ifadeler, matrisler, büyük sayılar ve birimler konusunda kapsamlı özellikler sunar. Tarayıcıda veya Node.js ortamında kullanılabilir. Temel bir dönüşüm oldukça kısa yazılır:

import { create, all } from "mathjs";

const math = create(all);

function donustur(deger, kaynak, hedef) {
  const miktar = math.unit(deger, kaynak);
  return miktar.toNumber(hedef);
}

console.log(donustur(10, "km", "m")); // 10000
console.log(donustur(25, "degC", "degF")); // 77

math.unit() sayıyı birimiyle birlikte temsil eder. toNumber() ise miktarı hedef birime çevirerek sayısal sonucu döndürür. Bu yöntem, dönüşüm katsayılarını elle yazmaktan daha güvenlidir.

Kullanıcı girişleri doğrudan işlenmemeli; hata yakalama mekanizması eklenmelidir:

function guvenliDonustur(deger, kaynak, hedef) {
  try {
    if (!Number.isFinite(deger)) {
      throw new Error("Geçerli bir sayı girilmedi.");
    }

    const sonuc = math.unit(deger, kaynak).toNumber(hedef);
    return { basarili: true, sonuc };
  } catch (hata) {
    return { basarili: false, mesaj: hata.message };
  }
}

Bu fonksiyon arayüzün çökmesini önler ve kullanıcıya açıklayıcı geri bildirim sağlar.

Arayüz ve geliştirme fikirleri

Başarılı bir dönüştürme sitesi; kategori seçimi, iki birim listesi, değer alanı ve birimleri ters çevirme düğmesi içermelidir. Son kullanılan dönüşümleri yerel depolamada saklamak da kullanıcı deneyimini iyileştirir.

Özel birimler math.createUnit() ile tanımlanabilir. Böylece uygulamaya yerel ölçüler veya projeye özgü teknik birimler eklenebilir. Son aşamada otomatik testlerle bilinen eşitlikler doğrulanmalıdır: $1\,inch=2.54\,cm$ ve $0\,^{\circ}C=32\,^{\circ}F$ gibi. Böylece siteniz yalnızca şık görünmez; hesap yaparken de cetveli ters tutmaz.

``

Üç platform, üç yaklaşım

Decidim, Barselona çıkışlı kapsamlı bir katılımcı demokrasi altyapısıdır. Teklif oluşturma, destek toplama, toplantı düzenleme, anket, bütçeleme ve sonuç takibi gibi süreçleri modüler biçimde sunar. Bir dilekçe sistemi kurmanın yanında tüm karar alma döngüsünü yönetmek isteyen kurumlara uygundur.

CONSUL DEMOCRACY, vatandaş önerileri, tartışmalar, oylamalar ve katılımcı bütçeleme üzerine yoğunlaşır. Teklif belirli bir destek eşiğine ulaştığında değerlendirme ya da oylama aşamasına geçirilebilir. Bu nedenle klasik “öneri ver, imza topla, gündeme taşı” modeliyle oldukça uyumludur.

FixMyStreet ise doğrudan bir dilekçe platformu değildir. Vatandaşların harita üzerinde çukur, kırık sokak lambası veya kaçak döküm gibi yerel sorunları bildirmesini sağlar. Bildirim, konuma göre sorumlu kuruma yönlendirilir ve çözüm durumu kamuya açık şekilde izlenebilir.

İmza sistemi nasıl düşünülmeli?

Basit modelde her dilekçenin bir destek sayısı ve hedefi bulunur. İlerleme oranı şöyle hesaplanabilir:

Burada $S$ doğrulanmış destek sayısını, $H$ hedeflenen desteği, $P$ ise yüzde ilerlemeyi ifade eder. Örneğin 2.000 destek hedefleyen bir öneri 1.250 doğrulanmış imzaya ulaştığında ilerleme oranı yüzde 62,5 olur.

Fakat yalnızca sayaç tutmak yeterli değildir. Aynı kişinin tekrar imza atması engellenmeli, e-posta veya kimlik doğrulaması yapılmalı ve kişisel veriler gereksiz yere yayımlanmamalıdır. İdeal süreç şu durum makinesini izleyebilir:

Taslak → Moderasyon → Yayında → Eşik Aşıldı → Kurumsal İnceleme → Sonuçlandı

Aşağıdaki basitleştirilmiş Python fonksiyonu, doğrulanmış ve benzersiz destekleri sayar:

def petition_progress(signatures, target):
    # Doğrulanmış kullanıcı kimliklerini kümeye alarak tekrarları eler.
    verified_users = {
        item["user_id"]
        for item in signatures
        if item["verified"] is True
    }

    support_count = len(verified_users)
    percentage = min((support_count / target) * 100, 100)

    return {
        "support_count": support_count,
        "percentage": round(percentage, 2),
        "threshold_reached": support_count >= target
    }

Gerçek sistemde user_id değerleri herkese açık gösterilmemeli; mümkünse tek yönlü özetler, yetkilendirme katmanları ve kayıt saklama politikaları kullanılmalıdır. Ayrıca kötüye kullanım önleme mekanizması erişilebilirliği bozmamalıdır: aşırı CAPTCHA kullanımı gerçek vatandaşları da kaçırabilir.

Hangisini seçmelisiniz?

Seçimde yalnızca özellik listesini değil; kurulum ekibinin Ruby/Rails deneyimini, barındırma bütçesini, moderasyon kapasitesini, çok dillilik ihtiyacını ve kurum içi süreçleri de değerlendirmek gerekir. En parlak arayüz bile arka tarafta dilekçeyi yanıtlayacak bir iş akışı yoksa dijital bir öneri kutusuna dönüşür.

Sonuç olarak Decidim geniş kapsamlı bir demokrasi laboratuvarı, CONSUL DEMOCRACY yapılandırılmış bir öneri ve oylama motoru, FixMyStreet ise konum tabanlı belediye sorunları için uzmanlaşmış bir araçtır. Başarılı seçim, “Hangisi daha güçlü?” sorusundan önce “Vatandaş hangi sürece katılacak?” sorusunu yanıtlamakla başlar.