``

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.

``

Üç 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.

``

Oylamanın teorik temeli

Basit çoğunluk oylamasında aday $i$ için kullanılan oy sayısını $v_i$ ile gösterirsek kazanan şöyle bulunur:

Ancak gerçek dünyadaki her karar “tek aday seç” biçiminde değildir. Seçmenler adayları sıralayabilir, birden fazla seçeneği destekleyebilir veya bütçe önerilerine oy verebilir. Ayrıca sistemin dört temel beklentiyi dengelemesi gerekir:

• Gizlilik: Bir oyun kime ait olduğu açıklanmamalıdır.
• Bütünlük: Oylar değiştirilememeli veya silinememelidir.
• Doğrulanabilirlik: Seçmen, oyunun sayıma katıldığını kontrol edebilmelidir.
• Uygunluk: Yalnızca yetkili kişiler ve izin verilen sayıda oy kullanabilmelidir.

Bu özellikler bazen çatışır. Kimlik doğrulamasını güçlendirmek gizlilik riskini artırabilir; tamamen anonim katılım ise mükerrer oyları engellemeyi zorlaştırabilir.

Üç platform, üç farklı karakter

Helios Voting: Matematik sandık başında

Helios, oyları açık anahtarlı şifreleme ile korur ve seçim sonucunun doğrulanabilmesi için kriptografik kanıtlar üretir. Homomorfik şifrelemenin sadeleştirilmiş fikri şudur:

Yani sistem, tek tek oyların içeriğini açmadan şifreli oyları birleştirip toplamı elde edebilir. Seçmen genellikle oyuna karşılık gelen bir takip değeri alır ve bu değerin yayımlanan sandık kayıtlarında bulunup bulunmadığını denetler. Böylece “oyum kayboldu mu?” sorusu teknik olarak kontrol edilebilir.

Bununla birlikte uçtan uca doğrulanabilirlik, seçmenin cihazında zararlı yazılım bulunmadığını otomatik olarak garanti etmez. Resmî ve yüksek riskli seçimlerde bağımsız güvenlik incelemesi şarttır.

Decidim: Oylamadan daha büyük bir sahne

Ruby on Rails tabanlı açık kaynak Decidim, yalnızca sandık kurmaz; karar alma sürecini baştan sona modellemeye çalışır. Katılımcılar öneri oluşturabilir, tartışabilir, toplantılara katılabilir ve bütçe projelerini destekleyebilir.

Bu nedenle Decidim’i “seçim uygulaması” yerine katılım altyapısı olarak düşünmek daha doğrudur. Bir belediyenin park önerilerini toplaması, projeleri tartışmaya açması ve ardından bütçe oylaması yapması için uygundur. Süreç şeffaflığı güçlüdür; fakat gizli oy gerektiren kritik seçimlerde kullanılacak özel bileşenler ayrıca incelenmelidir.

CIVS: Tercih sıralarının gücü

CIVS, seçmenlerin adayları sıralamasına dayanır. Condorcet yaklaşımında bir aday, diğer her adayı ikili karşılaştırmada yeniyorsa kazanan kabul edilir. $P(a,b)$, $a$ adayını $b$ adayına tercih edenlerin sayısı olsun:

Bu yöntem, yalnızca birinci tercihleri saymak yerine seçmenlerin genel eğilimini yakalar. Ancak döngüler oluşabilir: A, B’yi; B, C’yi; C de A’yı yenebilir. CIVS bu durumları çözmek için belirli Condorcet tamamlayıcı yöntemlerinden yararlanır.

Aşağıdaki Python kodu, iki aday arasındaki basit ikili üstünlüğü hesaplar:

def pairwise_winner(rankings, a, b):
    scores = {a: 0, b: 0}

    for ranking in rankings:
        if ranking.index(a) < ranking.index(b):
            scores[a] += 1
        else:
            scores[b] += 1

    if scores[a] == scores[b]:
        return 'berabere'
    return max(scores, key=scores.get)

Fonksiyon, her sıralamada hangi adayın daha yukarıda bulunduğunu kontrol eder. Gerçek bir Condorcet sistemi, bu işlemi bütün aday çiftleri için yaparak bir karşılaştırma matrisi oluşturur.

Hangisini seçmeli?

Kriptografik doğrulanabilirlik önceliğinizse Helios, kapsamlı katılımcı süreçler tasarlıyorsanız Decidim, seçenekleri adil biçimde sıralamak istiyorsanız CIVS güçlü adaylardır. Son karar; tehdit modeline, seçmen kitlesine, kimlik doğrulama ihtiyacına ve kullanılan seçim yönteminin anlaşılabilirliğine dayanmalıdır. Unutmayın: İyi bir dijital sandık yalnızca doğru sonucu üretmez, sonucun neden güvenilir olduğunu da gösterebilir.

``

Dosya arama sistemi nasıl çalışır?

Bir arama motoru dosyaları doğrudan sihirli biçimde anlamaz. Önce dosyanın metni çıkarılır, temizlenir ve indekslenebilir bir belgeye dönüştürülür. Tipik veri akışı şöyledir:

1. Dosya sisteme yüklenir.
2. Apache Tika, PDF.js veya benzeri bir araçla metin çıkarılır.
3. Başlık, dosya yolu, uzantı ve kullanıcı izinleri gibi metadata eklenir.
4. Belge arama motoruna gönderilir.
5. Kullanıcı sorgusu indeks üzerinde çalıştırılır.

Bu sistemlerin temelinde ters indeks bulunur. Geleneksel bir listede her belgenin içindeki kelimeler tutulurken ters indeks, her kelimenin hangi belgelerde geçtiğini saklar:

Böylece motor, bütün dosyaları tek tek okumak yerine ilgili kayıtları doğrudan bulur. Alaka sıralamasında sık kullanılan BM25 yaklaşımının basitleştirilmiş fikri şöyledir:

Burada $TF$, kelimenin belgede ne kadar sık geçtiğini; $IDF$ ise kelimenin tüm koleksiyon içindeki ayırt ediciliğini temsil eder. Örneğin “dosya” kelimesi sıradanken “Kubernetes” daha yüksek ayırt ediciliğe sahip olabilir.

Üç arama motorunun karşılaştırması

Elasticsearch, devasa veri kümeleri, dağıtık mimari ve ayrıntılı sorgu ihtiyacı olduğunda güçlüdür. Ancak shard, analyzer ve mapping gibi kavramları öğrenmek gerekir. Küçük bir proje için uzay mekiğiyle markete gitmek gibi hissedilebilir.

Meilisearch, geliştirici deneyimine odaklanır. Yazım hatalarını otomatik tolere eder ve iyi sonuçlara ulaşmak için uzun yapılandırmalar istemez. MVP, kurum içi doküman araması ve içerik siteleri için oldukça pratiktir.

Typesense ise sadelik ile kontrol arasında güzel bir denge kurar. Şema tanımı zorunludur; bu yaklaşım ilk aşamada ek iş çıkarsa da veri yapısının tutarlı kalmasını sağlar.

Örnek belge indeksleme

Aşağıdaki JavaScript kodu, metni çıkarılmış bir dosyayı Meilisearch indeksine ekler:

import { MeiliSearch } from 'meilisearch';

const client = new MeiliSearch({
  host: 'http://localhost:7700',
  apiKey: process.env.MEILI_MASTER_KEY
});

const documents = client.index('documents');

await documents.addDocuments([
  {
    id: 'rapor-2026',
    title: '2026 Güvenlik Raporu',
    path: '/raporlar/guvenlik.pdf',
    extension: 'pdf',
    content: 'Sunucu güvenliği, erişim kontrolü ve yedekleme...',
    allowedUsers: ['user-17', 'user-42']
  }
]);

const result = await documents.search('sunucu güvenligi', {
  filter: 'allowedUsers = user-17',
  limit: 10
});

console.log(result.hits);

Kod, belgeyi documents indeksine ekler ve yazım hatası içeren bir sorgu çalıştırır. Gerçek projede erişim filtresi kritik önemdedir: Kullanıcının göremediği bir dosya, arama sonucunda da görünmemelidir. Ayrıca API anahtarını istemci tarafına koymak yerine backend üzerinde saklamak gerekir.

Hangisini seçmeli?

Milyonlarca belge, karmaşık filtreler ve ayrıntılı analiz gerekiyorsa Elasticsearch doğru adaydır. Birkaç saatte çalışan, kullanıcı dostu bir arama deneyimi hedefleniyorsa Meilisearch öne çıkar. Düşük gecikme, güçlü yazım toleransı ve açık bir veri şeması isteniyorsa Typesense tercih edilebilir.

Motor seçiminden bağımsız olarak başarıyı belirleyen asıl unsurlar; kaliteli metin çıkarma, doğru metadata, Türkçe dil analizi, yetkilendirme ve düzenli indeks güncellemesidir. Motor arabanın kalbidir; fakat tekerlekler yoksa hiçbir yere gidemezsiniz.

Zihin haritasının teorik mantığı

İnsan zihni bilgileri yalnızca doğrusal listeler şeklinde saklamaz. Kavramlar arasında çağrışımlar, hiyerarşiler ve neden-sonuç bağlantıları kurar. Zihin haritası da bu yapıyı taklit eder: merkezde ana konu, çevresinde alt başlıklar ve onların altında ayrıntılar bulunur.

Bir haritanın kullanılabilirliğini basitçe şöyle düşünebiliriz:

Burada $V$ haritanın sağladığı zihinsel verim, $B$ görünür bağlantıların faydası, $K$ görsel karmaşıklık ve $G$ gereksiz ayrıntıdır. Daha fazla düğüm eklemek her zaman daha iyi değildir. Amaç, beynin yükünü başka bir yere taşırken yeni bir görsel canavar oluşturmamaktır.

İyi bir sistem üç katmandan oluşabilir:

1. Yakalama: Fikirleri sansürlemeden hızla kaydetmek.
2. Düzenleme: Benzer fikirleri gruplamak ve ilişkileri tanımlamak.
3. Sunma: Haritayı başkalarının anlayabileceği temiz bir çıktıya dönüştürmek.

Hangi araç ne zaman kullanılmalı?

Mindmaps türü araçlarda Tab ile alt dal, Enter ile kardeş dal açmak düşünce akışını hızlandırır. draw.io, ızgara ve bağlayıcıları sayesinde düzenli sonuç verir. Excalidraw’ın el çizimi görünümü ise taslağın henüz değişebilir olduğunu hissettirir; böylece ekip üyeleri kusursuz görünen bir diyagramı eleştirmekten çekinmez.

Tek araç yerine iş akışı kurmak

En verimli yöntem, araçları rakip değil aşama olarak görmektir. Örneğin yeni bir yazılım projesinde fikirleri önce Mindmaps veya Excalidraw üzerinde toplayabilir, ardından kalıcı mimariyi draw.io ile çizebilirsin.

Akışı kodla ifade etmek, sistemin tekrar kullanılmasını kolaylaştırır. Aşağıdaki Mermaid şeması fikirden dokümantasyona giden süreci tanımlar:

flowchart LR
    A[Ham fikirler] --> B[Mindmap ile dallandır]
    B --> C{Harita karmaşık mı?}
    C -- Hayır --> D[Excalidraw ile anlat]
    C -- Evet --> E[draw.io ile yapılandır]
    D --> F[Ekiple gözden geçir]
    E --> F
    F --> G[Dokümantasyona ekle]

Bu kod, desteklenen Markdown ortamlarında görsel diyagrama dönüşür. Ayrıca draw.io içindeki Mermaid ekleme özelliğiyle başlangıç şeması olarak kullanılabilir. Böylece kutuları tek tek oluşturmadan yapıyı kodla kurup daha sonra görsel olarak düzenlersin.

Sürdürülebilir haritalar için kurallar

Her düğümde mümkünse üç ila beş kelime kullan. Renkleri dekorasyon için değil, anlam taşımak için seç: kırmızı risk, yeşil tamamlanan iş, mavi bilgi gibi. Çapraz bağlantıları yalnızca gerçekten ilişki varsa ekle; aksi hâlde harita örümcek ağına döner.

Dosya adlarında da ortak bir düzen benimse:

proje-konu-asama-tarih.ext
odeme-sistemi-fikirler-2026-09.excalidraw
odeme-sistemi-mimari-v2.drawio

Son olarak her haritaya bir amaç sorusu yaz: “Bu harita hangi kararı vermeme yardım edecek?” Cevap yoksa muhtemelen düşünce üretmiyor, yalnızca renkli kutular biriktiriyorsundur. Doğru araç ve sade kurallarla zihin haritası, fikir mezarlığı değil yaşayan bir düşünme sistemi olur.

``

Aynı tablo, farklı düşünce biçimleri

Bu araçları karşılaştırmadan önce elektronik tablo ile veritabanı arasındaki temel farkı anlamalıyız. Elektronik tabloda hücreler merkezdedir; veritabanında ise kayıtlar, alanlar ve aralarındaki ilişkiler önemlidir.

Bir sipariş tablosunun toplam tutarı basitçe şöyle hesaplanabilir:

Burada $q_i$ ürün miktarını, $p_i$ birim fiyatı temsil eder. EtherCalc bu hesabı doğrudan hücre formülleriyle yapar. Baserow ve NocoDB ise miktar ile fiyatı yapılandırılmış alanlarda saklayıp hesaplanan alanlar veya sorgular üzerinden işler. Veri büyüdüğünde bu ayrım oldukça önemlidir.

EtherCalc: Hemen aç, birlikte yaz

EtherCalc, Google Sheets benzeri gerçek zamanlı bir çalışma deneyimi sunar. Hesap oluşturma zorunluluğu olmadan tablo paylaşabilmesi, toplantılar, geçici listeler ve ortak hesaplamalar için büyük kolaylıktır. Formül bilen biri araca neredeyse anında uyum sağlar.

Bununla birlikte EtherCalc bir veritabanı değildir. Karmaşık kayıt ilişkileri, ayrıntılı yetkilendirme veya gelişmiş otomasyon gerektiğinde sınırlarına çabuk ulaşır. Kısacası hızlıdır; fakat kurumsal veri mimarisinin omurgası olmaya çalışmaz.

Baserow: Tablodan uygulamaya geçiş

Baserow, elektronik tablo rahatlığını ilişkisel veritabanı disipliniyle birleştirir. Metin, sayı, seçim, dosya ve bağlantılı kayıt gibi alan türleri tanımlanabilir. Örneğin müşteriler ile siparişleri ayrı tablolarda tutup birbirine bağlayabilirsiniz. Böylece müşteri adı değiştiğinde yüzlerce satırı elle düzeltmeniz gerekmez.

Basit bir otomasyon istemcisi şu şekilde kayıt ekleyebilir:

import requests

url = "https://baserow.example/api/database/rows/table/42/"
headers = {"Authorization": "Token API_ANAHTARI"}
data = {"Musteri": "Ada Yazılım", "Tutar": 4800, "Durum": "Yeni"}

response = requests.post(url, headers=headers, json=data)
response.raise_for_status()
print(response.json())

Bu kod, Baserow API’sine yeni bir satış kaydı gönderir. Gerçek projelerde anahtarın kaynak kod yerine ortam değişkeninde saklanması gerekir.

NocoDB: SQL veritabanına kullanıcı dostu yüz

NocoDB’nin yıldızlaştığı nokta, mevcut SQL veritabanlarını anlaşılır bir tablo arayüzüne dönüştürmesidir. PostgreSQL veya MySQL kullanan bir ekip, teknik olmayan çalışanlara doğrudan SQL öğretmeden veriye erişim sağlayabilir. Görünümler, ilişkiler, API erişimi ve rol tabanlı izinler operasyon araçları geliştirmeyi kolaylaştırır.

Hangisini seçmelisiniz?

Karar formülünü basitleştirirsek, seçim puanı $S$; kullanım kolaylığı $K$, veri ilişkisi ihtiyacı $R$ ve mevcut altyapıyla uyum $U$ üzerinden düşünülebilir:

Sadece birlikte hücre düzenlemek istiyorsanız EtherCalc yeterlidir. Kod yazmadan düzenli bir iş uygulaması kuracaksanız Baserow daha dengeli bir seçimdir. Halihazırda SQL veritabanınız varsa NocoDB en doğal köprüdür. Üçü de kendi sunucunuza kurulabildiği için veri kontrolü sağlar; ancak yedekleme, güncelleme ve erişim güvenliği sorumluluğunu da size bırakır. Yani özgürlük ücretsizdir, fakat sistem yöneticisi kahvesi bütçeye dahildir!

Önce temel teori: Arama motoru ne yapar?

Klasik bir arama motoru üç ana aşamadan oluşur:

1. Tarama: Botlar web sayfalarını ziyaret eder.
2. İndeksleme: Sayfalardaki kelimeler, bağlantılar ve meta veriler kaydedilir.
3. Sıralama: Kullanıcının sorgusuyla en alakalı belgeler seçilir.

Basitleştirilmiş bir alaka puanı şöyle düşünülebilir:

Burada $T(d,q)$ belgenin sorguyla metinsel uyumunu, $L(d)$ bağlantı otoritesini, $F(d)$ ise güncelliğini temsil eder. $\alpha$, $\beta$ ve $\gamma$ katsayıları sistemin nelere önem verdiğini belirler. Ancak incelediğimiz araçların hepsi bu zincirin tamamını kendisi gerçekleştirmez.

SearXNG: Arama motorlarının orkestra şefi

SearXNG, sorguyu yapılandırılmış biçimde Google, Bing, Brave, Wikipedia ve başka servislere göndererek sonuçları tek ekranda birleştiren bir meta arama motorudur. Kendisi tüm web’i taramaz; farklı kaynaklardan gelen sonuçları normalize eder ve sıralar.

Bu yaklaşım tek bir sağlayıcının bakış açısına bağlı kalmayı azaltır. Ayrıca kendi sunucunuza kurduğunuzda sorgu kayıtları ve çerez politikası üzerinde daha fazla denetim elde edersiniz. Yine de isteklerin hedef arama servislerine ulaştığını unutmamak gerekir; SearXNG sihirli görünmezlik pelerini değildir.

Docker ile hızlı bir deneme yapılabilir:

docker run -d --name searxng \
  -p 8080:8080 \
  searxng/searxng

Bu komut, SearXNG konteynerini çalıştırır ve arayüzü 8080 portundan erişilebilir hâle getirir. Gerçek kullanımda gizli anahtar, ters proxy, HTTPS ve hız sınırlaması ayrıca yapılandırılmalıdır.

YaCy: Her bilgisayar küçük bir kütüphaneci

YaCy, diğer ikisinden daha maceracıdır. Kendi web tarayıcısına ve indeksine sahiptir; ayrıca eşler arası ağ üzerinden başka YaCy düğümleriyle veri paylaşabilir. Böylece merkezî bir şirket yerine birçok katılımcının katkısıyla arama altyapısı oluşturulabilir.

YaCy özellikle intranet, akademik arşiv veya belirli sitelerden oluşan özel koleksiyonlar için ilgi çekicidir. Buna karşılık tüm web’de büyük ticari motorlarla aynı hız ve kaliteyi beklemek gerçekçi değildir. Özgürlük menüdeyse, yanında kaynak tüketimi de ikram edilir.

Whoogle: Google, fakat daha az süslemeli

Whoogle, Google sonuçları için çalışan bir vekil arayüzdür. JavaScript ağırlığını, reklamları ve bazı takip mekanizmalarını azaltmayı hedefler. Kullanımı kolaydır; fakat doğrudan Google’a bağımlı olduğu için istek engelleme, CAPTCHA veya HTML değişikliklerinden etkilenebilir.

docker run -d --name whoogle \
  -p 5000:5000 \
  benbusby/whoogle-search

Bu örnek servisi yerel 5000 portunda başlatır. Herkese açık örnek çalıştırmak yerine erişimi sınırlandırmak daha güvenlidir; aksi hâlde sunucunuz kısa sürede robotların ücretsiz taksisine dönüşebilir.

Hangisini seçmeli?

Çok kaynaklı ve özelleştirilebilir günlük arama için SearXNG, bağımsız indeksleme ve dağıtık deneyler için YaCy, sade Google sonuçları için Whoogle uygundur. En dengeli genel tercih çoğu kullanıcı açısından SearXNG’dir. Hangi aracı seçerseniz seçin HTTPS, güncel konteyner imajları, erişim kontrolü ve günlük politikası gibi güvenlik ayrıntılarını ihmal etmeyin. Mahremiyet yalnızca yazılım kurmakla değil, doğru yapılandırmakla kazanılır.

Kişisel portal ne işe yarar?

Portal sistemi, uygulamalarınızın kendisini barındırmaz; onlara ulaşabileceğiniz merkezi bir navigasyon katmanı oluşturur. Örneğin Jellyfin, Home Assistant, Grafana ve Portainer farklı adreslerde çalışırken portalınız tek bir URL üzerinden hepsine bağlantı sunar.

Bu yapıyı basitçe bir fonksiyon gibi düşünebiliriz:

Burada $S$ servis adlarını, $U$ ise ilgili URL’leri temsil eder. Portalın asıl değeri bağlantı sayısı arttıkça ortaya çıkar. Kullanıcının ezberlemesi gereken adres sayısı $n$ iken iyi tasarlanmış bir portal bu zihinsel yükü yaklaşık olarak tek giriş noktasına indirir:

Elbette portal güvenlik duvarı veya kimlik doğrulama sistemi değildir. İnternete açılacaksa HTTPS, ters vekil sunucu ve mümkünse Authelia ya da Authentik gibi bir erişim katmanı kullanılmalıdır.

Üç adayın karakteri

Heimdall: Gösterişli ve kullanışlı

Heimdall, uygulama kartlarını tarayıcı üzerinden eklemeyi kolaylaştırır. Bazı servisler için geliştirilmiş uygulama desteği sayesinde kartlarda ek bilgiler gösterilebilir. Dosya düzenlemek istemeyen, portalını aile üyelerine de kullandıracak kişiler için iyi bir seçimdir. Buna karşılık veritabanı ve uygulama çalışma zamanı nedeniyle Homer’dan daha fazla kaynak tüketir.

Homer: YAML seven minimaliste

Homer büyük ölçüde statik çalışır ve yapılandırmasını YAML dosyasından alır. Bu dosyayı Git deposunda saklayabilir, değişiklik geçmişini izleyebilir ve farklı sunuculara kolayca taşıyabilirsiniz.

---
title: Ev Laboratuvarım
services:
  - name: Medya
    items:
      - name: Jellyfin
        subtitle: Film ve diziler
        url: https://jellyfin.example.com
        icon: fas fa-play-circle

Bu yapılandırma bir Medya bölümü ve Jellyfin kartı oluşturur. Homer’ın sadeliği performans avantajıdır; ancak bağlantı eklemek için dosyayı düzenlemek, YAML girintilerine dikkat etmek gerekir. Tek bir hatalı boşluk küçük bir sabır sınavına dönüşebilir.

Flame: Docker ile yakın arkadaş

Flame, görsel yönetim paneliyle uygulama ve yer imi eklemeyi kolaylaştırır. En dikkat çekici taraflarından biri, uygun Docker etiketleri kullanıldığında çalışan konteynerleri portalda gösterebilmesidir.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    labels:
      - flame.type=application
      - flame.name=Uptime Kuma
      - flame.url=https://status.example.com

Etiketler, Flame’e konteynerin adını ve açılacak adresi bildirir. Böylece servis tanımı uygulamanın Docker Compose dosyasıyla birlikte yaşar; yeni kurulumlarda portal kartını ayrıca oluşturmanız gerekmez.

Hangisini seçmelisiniz?

Sadece hızlı, taşınabilir ve sürüm kontrolüne uygun bir ana sayfa istiyorsanız Homer öne çıkar. Zengin uygulama kartları ve tamamen görsel yönetim arıyorsanız Heimdall daha rahattır. Servislerinizi Docker Compose ile yönetiyor ve otomatik keşif fikrini seviyorsanız Flame oldukça pratiktir.

Seçiminiz ne olursa olsun portalı yalnızca iç ağda yayınlamak, düzenli yedek almak ve yönetim arayüzünü güçlü parolayla korumak önemlidir. Sonuçta dijital karargâhınızın kapısını açık bırakmak, anahtarı paspasın altına koymanın teknolojik karşılığıdır.

``

Temel veri modeli

Sistemin merkezinde turnuva, katılımcı, karşılaşma ve puan durumu kaydı bulunur. Katılımcı bir takım olabileceği gibi tekil bir sporcu da olabilir. Bu nedenle veri modelinde team yerine daha genel olan participant adını kullanmak sistemi farklı spor dallarına uyarlamayı kolaylaştırır.

Puan tablosunu kalıcı olarak saklamak yerine maç sonuçlarından yeniden hesaplamak çoğu zaman daha güvenlidir. Böylece bir skor düzeltildiğinde eski ve yeni değerlerin birbirine karışması önlenir. Performans gerekiyorsa hesaplanan tablo önbelleğe alınabilir.

Puan hesabının matematiği

Klasik futbol sisteminde galibiyet 3, beraberlik 1 ve mağlubiyet 0 puandır. Bir katılımcının toplam puanı şu şekilde ifade edilir:

Burada $G$ galibiyet, $B$ beraberlik, $M$ ise mağlubiyet sayısıdır. Genel averaj da

formülüyle hesaplanır. Ancak masa tenisi, badminton veya e-spor ligleri set oranı, harita farkı ya da doğrudan ikili averaj kullanabilir. Bu yüzden puan kurallarını kodun içine sabitlemek yerine turnuva ayarlarında tanımlamak iyi bir fikirdir.

Hesaplama motoru

Aşağıdaki TypeScript fonksiyonu, tamamlanmış maçlardan temel puan tablosu üretir. Fonksiyon saf tutulduğu için aynı girdi her zaman aynı çıktıyı verir; test etmek de oldukça kolaydır.

type Match = {
  homeId: string;
  awayId: string;
  homeScore: number;
  awayScore: number;
  status: "finished" | "scheduled";
};

type Row = {
  id: string;
  played: number;
  won: number;
  draw: number;
  lost: number;
  scored: number;
  conceded: number;
  points: number;
};

function calculateTable(ids: string[], matches: Match[]): Row[] {
  const rows = new Map(ids.map(id => [id, {
    id, played: 0, won: 0, draw: 0, lost: 0,
    scored: 0, conceded: 0, points: 0
  }]));

  for (const match of matches.filter(m => m.status === "finished")) {
    const home = rows.get(match.homeId)!;
    const away = rows.get(match.awayId)!;

    home.played++; away.played++;
    home.scored += match.homeScore;
    home.conceded += match.awayScore;
    away.scored += match.awayScore;
    away.conceded += match.homeScore;

    if (match.homeScore === match.awayScore) {
      home.draw++; away.draw++;
      home.points++; away.points++;
    } else {
      const winner = match.homeScore > match.awayScore ? home : away;
      const loser = winner === home ? away : home;
      winner.won++; winner.points += 3;
      loser.lost++;
    }
  }

  return [...rows.values()].sort((a, b) =>
    b.points - a.points ||
    (b.scored - b.conceded) - (a.scored - a.conceded) ||
    b.scored - a.scored
  );
}

Sıralama zinciri burada puan, averaj ve atılan skor biçimindedir. İkili averaj gerekiyorsa eşit puanlı katılımcılar belirlenmeli, yalnızca kendi aralarındaki maçlardan geçici bir mini tablo oluşturulmalıdır.

Fikstür ve operasyonel ayrıntılar

Tek devreli ligde $n$ katılımcı için toplam maç sayısı

olur. Çift devreli ligde bu değer ikiyle çarpılır. Round-robin fikstür için kullanılan çember yöntemi, katılımcıları her tur döndürerek herkesin birbiriyle karşılaşmasını sağlar. Katılımcı sayısı tekse hayali bir BYE eklenir ve onunla eşleşen taraf haftayı maç yapmadan geçirir.

Gerçek dünyada maç erteleme, hükmen sonuç, katılımcı çekilmesi ve yönetici düzeltmeleri unutulmamalıdır. Her skor değişikliğini kullanıcı, zaman ve eski değer bilgisiyle bir denetim günlüğüne kaydetmek tartışmaları azaltır. Sonuç girişini yetkilendirme, eşzamanlı güncellemelerde transaction kullanma ve hesaplama motorunu bolca birim testiyle sınama da sistemin görünmeyen savunma hattıdır. Böylece puan tablosu yalnızca şık değil, son düdüğe kadar güvenilir olur.