``

Ö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.

Ö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.

Üç araç, üç farklı görev

Bu teknolojiler aynı ekosistemde çalışabilse de birbirlerinin alternatifi değildir. OpenStreetMap (OSM) topluluk tarafından üretilen coğrafi verileri sağlar. Yollar, binalar, parklar ve ilgi noktaları bu veri tabanında tutulur. uMap, OSM tabanlı kişisel haritaları kod yazmadan hazırlamaya yarar. Leaflet ise web sayfasında etkileşimli harita oluşturabileceğimiz hafif bir JavaScript kütüphanesidir.

Kısacası OSM mutfaktaki malzemeler, uMap hazır yemek tezgâhı, Leaflet ise tarif üzerinde istediğimiz değişikliği yapabildiğimiz şef bıçağıdır.

Konum bilgisinin matematiği

Dünya üzerindeki bir nokta genellikle enlem ve boylam çiftiyle ifade edilir:

Burada $\varphi$ enlemi, $\lambda$ ise boylamı temsil eder. Enlem kuzey-güney, boylam doğu-batı konumunu belirtir. Leaflet koordinatları çoğunlukla [enlem, boylam] sırasıyla bekler. GeoJSON standardında ise sıra [boylam, enlem] biçimindedir. Bu küçük fark, işaretçinizin İstanbul yerine okyanusta yüzmesine neden olabilecek kadar önemlidir.

İki konum arasındaki kuş uçuşu mesafe, küresel Dünya yaklaşımında Haversine formülüyle hesaplanabilir:

$R$ yaklaşık $6371$ kilometredir. Yol mesafesi içinse yolların bağlantılarını içeren bir rota motoruna ihtiyaç duyulur; düz çizgi her zaman kullanılabilir bir cadde değildir.

Leaflet ile ilk etkileşimli harita

Önce sayfaya Leaflet CSS ve JavaScript dosyaları eklenmeli, ardından haritanın yerleşeceği elemana yükseklik verilmelidir. Aşağıdaki örnek İstanbul merkezli bir harita oluşturur:

<link rel="stylesheet" href="https://unpkg.com/leaflet/dist/leaflet.css">
<div id="map" style="height: 420px"></div>
<script src="https://unpkg.com/leaflet/dist/leaflet.js"></script>
<script>
  const map = L.map('map').setView([41.0082, 28.9784], 12);

  L.tileLayer('https://tile.openstreetmap.org/{z}/{x}/{y}.png', {
    maxZoom: 19,
    attribution: '&copy; OpenStreetMap katkıda bulunanlar'
  }).addTo(map);

  const marker = L.marker([41.0082, 28.9784]).addTo(map);
  marker.bindPopup('<strong>İstanbul</strong><br>Harita burada başlıyor!');

  map.on('click', event => {
    L.popup()
      .setLatLng(event.latlng)
      .setContent(`Konum: ${event.latlng.lat.toFixed(5)}, ${event.latlng.lng.toFixed(5)}`)
      .openOn(map);
  });
</script>

setView başlangıç merkezini ve yakınlaştırma seviyesini belirler. tileLayer, OSM karo görüntülerini haritaya taşır. Tıklama olayı ise kullanıcının seçtiği koordinatı gösterir. Gerçek projelerde herkese açık karo sunucularının kullanım politikasını incelemek, yoğun trafik için uygun bir sağlayıcı seçmek gerekir.

uMap ve veri paylaşımı

Kod yazmadan başlamak isteyenler uMap üzerinde işaretçiler, çizgiler ve bölgeler ekleyebilir. Hazırlanan katmanlar GeoJSON olarak dışa aktarılıp Leaflet uygulamasına alınabilir:

fetch('noktalar.geojson')
  .then(response => response.json())
  .then(data => L.geoJSON(data, {
    onEachFeature: (feature, layer) => {
      layer.bindPopup(feature.properties.name ?? 'İsimsiz nokta');
    }
  }).addTo(map));

Bu yaklaşımda içerik ekibi uMap ile veriyi düzenlerken geliştirici Leaflet arayüzünü yönetir. OSM veriyi, uMap kolay düzenlemeyi, Leaflet ise özgür programlamayı sağlar. Böylece küçük bir gezi rehberinden kapsamlı bir konum platformuna kadar büyüyebilen, açık ve esnek bir mimari kurulur.

Bir topluluk platformu kurmak, yalnızca kullanıcıların kayıt olabileceği bir sayfa hazırlamak değildir. Profil yönetimi, içerik üretimi, bildirimler, moderasyon, yetkilendirme ve kullanıcıların geri dönmesini sağlayan sosyal mekanikler birlikte düşünülmelidir. HumHub, BuddyPress ve Discourse bu problemi farklı açılardan çözer: biri sosyal ağ, biri WordPress eklentisi, diğeri ise modern forum yaklaşımını benimser.

``

Önce topluluk sisteminin mantığı

Bir üyelik sisteminin merkezinde kimlik, yetki ve etkileşim bulunur. Kimlik katmanı kullanıcının kim olduğunu; yetkilendirme katmanı hangi işlemleri yapabileceğini; etkileşim katmanı ise diğer üyelerle nasıl iletişim kuracağını belirler.

Basit bir topluluk veri modeli şöyle düşünülebilir:

Kullanıcı → Profil → Rol
Kullanıcı → İçerik → Yorum
Kullanıcı → Grup → Üyelik
İçerik → Bildirim → Kullanıcı

Topluluk sağlığını ölçmek için yalnızca kayıtlı kullanıcı sayısına bakmak yanıltıcıdır. Daha anlamlı bir ölçü, aktif kullanıcı oranıdır:

Örneğin 10.000 üyenin yalnızca 200’ü günlük olarak geri dönüyorsa aktiflik oranı yüzde 2’dir. Dolayısıyla yazılım seçerken özellik listesinden çok, hedeflenen etkileşim biçimine odaklanmak gerekir.

Üç platformun karakteri

HumHub

HumHub, Facebook benzeri akışların ve çalışma alanlarının önemli olduğu projelerde öne çıkar. Kullanıcılar profil oluşturabilir, alanlara katılabilir, gönderi paylaşabilir ve birbirlerini takip edebilir. Üniversite kulübü, şirket içi ağ veya kapalı meslek topluluğu için doğal bir seçimdir.

Modüler yapısı sayesinde takvim, görev ve dosya paylaşımı gibi yetenekler eklenebilir. Ancak tema ve modül ekosistemi WordPress kadar geniş değildir. Sunucu yönetimi konusunda temel Linux, PHP ve veritabanı bilgisi gerekir.

BuddyPress

BuddyPress bağımsız bir uygulama değil, WordPress’i topluluk sistemine dönüştüren bir eklentidir. Mevcut sitenizde blog, kurs, mağaza veya üyelik altyapısı varsa oldukça pratiktir. WooCommerce ve LMS eklentileriyle beraber kullanıldığında ücretli topluluklar kurulabilir.

WordPress kancaları üzerinden davranış eklemek mümkündür:

add_action('bp_init', function () {
    // BuddyPress yüklendikten sonra özel topluluk işlemlerini başlatır.
    if (is_user_logged_in()) {
        update_user_meta(get_current_user_id(), 'son_topluluk_girisi', time());
    }
});

Bu kod, giriş yapmış üyenin son topluluk ziyaretini kaydeder. Böylece geri dönüş oranı veya pasif üyeler analiz edilebilir. Bununla birlikte çok sayıda eklenti kullanmak performans, güvenlik ve uyumluluk sorunları doğurabilir.

Discourse

Discourse, klasik forumları daha akıcı hale getirir. Güven seviyeleri, güçlü moderasyon araçları, e-posta ile yanıt, rozetler ve gerçek zamanlı bildirimler hazır gelir. Teknik destek, açık kaynak proje veya soru-cevap odaklı topluluklar için başarılıdır.

Platformun güven sistemi, olumlu davranış sergileyen kullanıcılara zamanla daha fazla yetki verir. Bu yaklaşım moderasyon yükünü topluluğa dağıtır. Docker tabanlı önerilen kurulum güvenilir olsa da düşük kaynaklı paylaşımlı hosting paketlerine pek uygun değildir.

Hangisini seçmelisiniz?

Karar verirken toplam maliyeti $M = K + B + E$ biçiminde değerlendirebilirsiniz. Burada $K$ kurulum, $B$ bakım, $E$ ise eklenti ve entegrasyon gideridir. Yazılımların açık kaynak olması, işletmenin tamamen ücretsiz olacağı anlamına gelmez.

Özetle sosyal akış ve gruplar için HumHub, WordPress ekosistemi için BuddyPress, uzun ömürlü tartışmalar için Discourse daha uygundur. En iyi platform, en çok özelliğe sahip olan değil; üyelerin neden geri geleceği sorusuna en net cevabı verendir.

``

Sohbet arayüzü gerçekte ne yapar?

Bir yapay zekâ sohbet arayüzü yalnızca renkli mesaj balonlarından ibaret değildir. Kullanıcının mesajını alır, konuşma geçmişini düzenler, uygun model sağlayıcısına istek gönderir ve yanıtı çoğunlukla akış hâlinde ekrana taşır. Temel akış şöyle özetlenebilir:

Dil modellerinde bağlam penceresi sınırlıdır. Arayüz, önceki mesajları modele tekrar gönderdiği için yaklaşık toplam kullanım şu şekilde düşünülebilir:

Buradaki $T$, token sayısını temsil eder. Sohbet uzadıkça geçmiş büyür; maliyet ve bellek ihtiyacı artar. İyi bir arayüz bu nedenle konuşma yönetimi, model seçimi, belge yükleme, kullanıcı yetkilendirme ve geçmiş arama gibi görevleri de üstlenir.

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

Open WebUI: Yerel model meraklısı

Open WebUI özellikle Ollama ile iyi anlaşır. Bilgisayarınızda Llama, Qwen veya Mistral çalıştırıyorsanız birkaç dakika içinde tarayıcı tabanlı bir sohbet ekranı kurabilirsiniz. Model yönetimi, kullanıcı hesapları, belge tabanlı soru-cevap ve OpenAI uyumlu bağlantılar sunması önemli avantajlarıdır.

Aşağıdaki komut, arayüzü Docker üzerinden çalıştırır ve Ollama servisine bağlanmasını sağlar:

docker run -d \
  -p 3000:8080 \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  ghcr.io/open-webui/open-webui:main

-v seçeneği sohbetlerin ve ayarların kalıcı olmasını sağlar. Kurulumdan sonra arayüze http://localhost:3000 adresinden erişilir.

LibreChat: Modeller arasında İsviçre çakısı

LibreChat, birden fazla ticari ve açık model sağlayıcısını aynı panelde toplamak isteyenlere hitap eder. Kullanıcı yönetimi, hazır istemler, eklentiler, dosya etkileşimi ve farklı asistan yapılandırmaları bakımından zengindir. Bunun bedeli, Open WebUI’ye kıyasla daha fazla servis ve çevre değişkeniyle uğraşmaktır.

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

Bu komutlar projeyi indirir, örnek yapılandırmayı oluşturur ve gerekli bileşenleri başlatır. API anahtarları kullanılmadan önce .env dosyasına eklenmelidir; dosya kesinlikle Git deposuna gönderilmemelidir.

Chatbot UI: Özelleştirme isteyen geliştirici

Chatbot UI, sade yapısı ve modern web teknolojileri sayesinde kendi yapay zekâ ürününü şekillendirmek isteyen geliştiriciler için çekicidir. Tasarımı değiştirmek, yeni iş akışları eklemek veya arayüzü mevcut bir ürüne uyarlamak görece rahattır. Buna karşılık bazı gelişmiş yönetim ve RAG özelliklerini sizin tamamlamanız gerekebilir.

Hangisini seçmelisiniz?

Yerel modellerle hızlıca başlamak ve veriyi kendi cihazınızda tutmak istiyorsanız Open WebUI en rahat seçimdir. Çok sayıda sağlayıcıyı, kullanıcıyı ve gelişmiş özelliği tek merkezde yönetmek istiyorsanız LibreChat öne çıkar. Arayüzü çatallayıp kendi markanıza ve iş mantığınıza göre dönüştürmek istiyorsanız Chatbot UI daha uygun bir temel sunar.

Kısacası tek bir mutlak kazanan yoktur: Open WebUI pratik laboratuvar, LibreChat kapsamlı kontrol merkezi, Chatbot UI ise geliştirilebilir bir tuval gibidir. Seçimi ekran görüntülerine göre değil; kullanacağınız modeller, gizlilik beklentiniz ve bakım kapasiteniz üzerinden yapmak en sağlıklı yaklaşımdır.