``

Açık veri nedir?

Açık veri; herkesin erişebildiği, kullanabildiği, değiştirebildiği ve uygun lisans koşullarıyla yeniden paylaşabildiği veridir. Bir Excel dosyasını belediyenin sitesine yüklemek başlangıç sayılabilir, ancak gerçek anlamda kullanılabilir veri için makine tarafından okunabilir formatlar gerekir.

Bir veri kümesinin faydasını basitçe şöyle düşünebiliriz:

Burada $E$ erişilebilirliği, $G$ güncelliği, $A$ ise anlaşılabilirliği temsil eder. Çarpanlardan biri sıfıra yaklaşırsa toplam fayda da düşer. Örneğin güncel olmayan otobüs konumları, teknik olarak erişilebilir olsa bile yolcuyu yanlış durağa koşturabilir!

Belediye API’si nasıl çalışır?

API, belediyenin veri sistemleri ile dışarıdaki uygulamalar arasında kontrollü bir köprü kurar. İstemci belirli bir adrese HTTP isteği gönderir; sunucu çoğunlukla JSON biçiminde yanıt verir. Örneğin /api/v1/otobusler adresi araç listesini, /api/v1/otobusler/34 adresi ise belirli bir aracı döndürebilir.

Arka planda tipik akış şu şekildedir:

1. Sensörler veya belediye birimleri ham veriyi üretir.
2. ETL süreci veriyi temizler, standartlaştırır ve doğrular.
3. Kişisel ya da hassas alanlar anonimleştirilir.
4. API katmanı yalnızca paylaşılması uygun alanları sunar.
5. Portal; açıklama, lisans, güncelleme tarihi ve örnek sorgular yayımlar.

Bir geliştirici, durak verisini Python ile şöyle kullanabilir:

import requests

url = 'https://veri.ornek.bel.tr/api/v1/duraklar'
params = {'ilce': 'merkez', 'limit': 10}

response = requests.get(url, params=params, timeout=10)
response.raise_for_status()

for durak in response.json()['results']:
    print(durak['ad'], durak['konum'])

Bu kod API’ye filtreli bir GET isteği gönderir, bağlantı hatalarını denetler ve dönen ilk on durağın adını ve konumunu yazdırır. Gerçek projelerde sayfalama, önbellekleme ve istek sınırı bilgileri de dikkate alınmalıdır.

Şeffaflık kadar mahremiyet de önemli

Her belediye verisi açılmamalıdır. Kişilerin adresleri, sağlık bilgileri, araç plakaları veya hareket geçmişleri doğrudan paylaşılırsa açık veri faydadan çok zarar üretebilir. Bu nedenle isim kaldırma tek başına yeterli değildir; farklı veri kümeleri birleştirildiğinde kişinin yeniden tanınması mümkün olabilir.

API anahtarları, hız sınırlama, anonimleştirme ve erişim kayıtları güvenliğin temel araçlarıdır. Ayrıca veri lisansı açıkça belirtilmelidir; “internette bulunuyor” ifadesi, verinin sınırsızca kullanılabileceği anlamına gelmez.

Vatandaş için gerçek değer

İyi tasarlanmış bir portal yalnızca dosya deposu değildir. Veri sözlüğü, sürüm bilgisi, API dokümantasyonu, hata bildirim kanalı ve örnek projeler sunar. Bunun sonucunda erişilebilir rota uygulamaları, mahalle bütçesi panoları, hava kalitesi uyarıları veya boş otopark haritaları geliştirilebilir.

Kısacası şehir verisi paylaşıldığında belediye tek üretici olmaktan çıkar; vatandaşlar da çözüm ortağına dönüşür. Doğru standartlar, güncel API’ler ve güçlü mahremiyet kuralları sayesinde açık veri, dijital şehrin vitrini değil çalışan motoru olabilir.

Bir odadaki beş farklı lambayı film izlemeye uygun hâle getirmek için her birini ayrı ayrı ayarladığınızı düşünün: tavan ışığını kıs, lambaderi mora çevir, LED şeridi yak… Akıllı aydınlatma sistemlerindeki scene, yani sahne yaklaşımı, bu küçük kumanda maratonunu tek komuta indirir. “Sinema” sahnesini çağırdığınızda bütün ışıklar önceden belirlenen renk, parlaklık ve geçiş sürelerine senkronize biçimde ulaşır.

``

Scene tam olarak nedir?

Scene, bir veya daha fazla cihazın hedef durumlarını saklayan mantıksal bir anlık görüntüdür. Bir sahne çalıştırıldığında sistem ilgili cihazlara açık/kapalı, parlaklık, renk sıcaklığı veya RGB değeri gibi komutlar gönderir.

Bir ışığın basitleştirilmiş durumu şöyle gösterilebilir:

Burada $p_i$ güç durumunu, $b_i$ parlaklığı, $(r_i,g_i,b_i’)$ renk bileşenlerini, $t_i$ ise geçiş süresini temsil eder. Bir sahne de $n$ adet ışığın durum kümesidir:

Yani scene komutu sihir değil; önceden tanımlanmış durumların topluca uygulanmasıdır. Yine de salon bir anda bilim kurgu filmine dönüşünce biraz sihirli görünebilir.

Senkronizasyon nasıl sağlanır?

Merkezî sistem önce sahne tanımını okur, ardından komutları ağ üzerinden ampullere veya köprüye iletir. Zigbee gibi ağlarda grup adresleme kullanılıyorsa tek yayın mesajı aynı gruptaki cihazlara ulaşabilir. Wi-Fi tabanlı sistemlerde ise komutlar çoğunlukla ayrı ayrı gönderilir.

Gerçek dünyada “aynı anda” ifadesi yaklaşık bir hedeftir. Cihaz $i$ için toplam gecikme şöyle modellenebilir:

Işıklar arasındaki fark $\Delta T = \max(T_i)-\min(T_i)$ küçüldükçe geçiş daha senkron görünür. Grup mesajları, yerel ağ kullanımı ve ortak geçiş süresi bu farkı azaltır. Bulut üzerinden çalışan çözümlerde internet gecikmesi, orkestraya geç kalan bir trompetçi ekleyebilir.

Home Assistant ile örnek sahne

Aşağıdaki YAML tanımı, üç ışığın hedef özelliklerini saklar. transition alanı değişimin iki saniyede yumuşak biçimde yapılmasını sağlar.

scene:
  - name: Sinema Modu
    entities:
      light.tavan:
        state: "off"
      light.lambader:
        state: "on"
        brightness: 65
        rgb_color: [90, 30, 140]
        transition: 2
      light.tv_seridi:
        state: "on"
        brightness: 110
        color_temp_kelvin: 3000
        transition: 2

Sahneyi bir otomasyondan, panelden veya sesli asistandan çağırabiliriz:

service: scene.turn_on
target:
  entity_id: scene.sinema_modu
data:
  transition: 2

İlk blok hangi durumun oluşturulacağını, ikinci blok ise bu durumun ne zaman uygulanacağını ifade eder. Bu ayrım önemlidir: Scene durum tarif eder; otomasyon ise tetikleyici ve koşullarla karar verir.

MQTT ile kendi denetleyicini yazmak

Özel bir IoT projesinde sahne, JSON olarak MQTT konusuna yayınlanabilir:

import json
import paho.mqtt.publish as publish

scene = {
    "group": "salon",
    "brightness": 35,
    "color": {"r": 80, "g": 20, "b": 130},
    "transition_ms": 2000
}

publish.single(
    "home/lights/scene",
    payload=json.dumps(scene),
    hostname="192.168.1.20"
)

Bu kod sahne verisini tek mesaj hâlinde yayımlar. Abone olan denetleyici mesajı ayrıştırıp ilgili ışıklara uygular. Üretim ortamında kimlik doğrulama, TLS, hata kontrolü ve çevrimdışı cihaz yönetimi de eklenmelidir.

Sağlam sahneler için ipuçları

• Cihazları işlevlerine göre gruplandırın.
• Bulut yerine mümkünse yerel kontrol kullanın.
• Tüm ışıklara ortak geçiş süresi verin.
• Erişilemeyen cihazlarda işlemi tamamen durdurmak yerine kalanları çalıştırın.
• Sahnenin mevcut ayarları mı kaydedeceğine, sabit değerler mi kullanacağına karar verin.

İyi tasarlanmış bir scene sistemi, karmaşık cihaz ayrıntılarını kullanıcıdan saklar. Kullanıcı yalnızca “Çalışma”, “Parti” veya “Uyku” der; arka plandaki yazılım ise ışık orkestrasının şefliğini üstlenir.

``

Önce katmanları ayıralım

Haberleşmenin iki temel sorusu vardır: “Veriyi nasıl taşıyoruz?” ve “Taşınan veri ne anlama geliyor?” Radyo teknolojisi ilk soruya, uygulama protokolü ikinci soruya yanıt verir. Ortak frekans kullanmak, ortak dili konuşmak anlamına gelmez; cihazların komutları, güvenlik kurallarını ve katılım süreçlerini de anlaması gerekir.

Zigbee ve Z-Wave kendi ağ ve uygulama yapılarını sunar. Matter ise IP üzerinde çalışan bir uygulama standardıdır; veriyi Thread, Wi-Fi veya Ethernet taşıyabilir. Bluetooth LE genellikle ilk kurulumda yardımcı olur, normal Matter haberleşmesinin taşıyıcısı değildir.

Örgü, yani mesh ağlarda mesajlar ara cihazlardan geçebilir. Her atlamanın bağımsız başarı olasılığı $p$ ise, $h$ atlamalı basitleştirilmiş bir yol için $P = p^h$ olur. Örneğin $0.99^3 = 0.970299$. Bu, yeniden denemeleri dışlayan öğretici bir modeldir; gerçek performansı yerleşim, parazit ve alternatif yollar belirler.

Zigbee: Kalabalık ve ekonomik mahalle

Zigbee, sensörlerden ampullere uzanan geniş ürün çeşitliliğiyle dikkat çeker. Koordinatör ağı oluşturur; yönlendirici cihazlar mesajları aktarır. Pilli uç cihazlar çoğunlukla uyuyarak enerji tasarrufu yapar ve başkalarının mesajlarını taşımaz. Şebekeden beslenen her cihazın yönlendirici olduğunu varsaymamak gerekir.

Dezavantajı, yaygın kullanılan 2,4 GHz bandını Wi-Fi ile paylaşmasıdır. Kanal planlaması önemlidir. Ayrıca “Zigbee destekli” etiketi, her cihazın her merkezde bütün özellikleriyle çalışacağını garanti etmez. Satın almadan önce merkezin uyumluluk listesini kontrol edin.

Z-Wave: Daha sakin frekansların komşusu

Z-Wave, bölgeye göre değişen sub-GHz frekanslarını kullanır. Avrupa ürünlerinde sıklıkla 868 MHz çevresi görülür; ABD ürünleri farklı bantlardadır. Bu yüzden yurt dışından alınan cihazın yerel denetleyiciyle ve mevzuatla uyumunu kontrol etmek şarttır.

Düşük frekans, benzer koşullarda yayılım açısından avantaj sağlayabilir; ancak beton duvarları sihirli biçimde ortadan kaldırmaz. Sertifikasyon birlikte çalışabilirliği destekler, yine de denetleyicinin özellik desteği önemlidir. Ayrıca Z-Wave Long Range, klasik mesh yaklaşımından farklı olarak yıldız topolojisi kullanır.

Matter: Ortak sözlük, farklı yollar

Matter’ın büyük vaadi, markalar arasındaki uygulama dilini standartlaştırmaktır. Desteklenen cihazlar Multi-Admin özelliğiyle birden fazla ekosisteme eklenebilir. Ancak uygulamaların sunduğu özellikler, cihaz türü desteği ve Matter sürümleri hâlâ kontrol edilmelidir.

Thread kullanan Matter cihazları, evin diğer IP ağlarına ulaşmak için bir Thread sınır yönlendiricisinden yararlanır. Matter denetleyicisi ise cihazın kurulumu ve yönetimiyle ilgilenir. Bu roller aynı üründe bulunabilir ama aynı şey değildir.

Eski Zigbee veya Z-Wave cihazları kendiliğinden Matter cihazına dönüşmez. Uyumlu bir köprü, yalnızca desteklediği cihaz türlerini ve özelliklerini Matter tarafına sunabilir.

Yazılım tarafında ortak komut modeli

Bir otomasyon uygulaması, cihazın protokolünü her iş kuralına taşımak yerine adaptör seçimini merkezileştirebilir. Aşağıdaki Python örneği gerçek radyo iletişimi yapmaz; komutun hangi entegrasyona yönlendirileceğini planlar:

from dataclasses import dataclass

@dataclass(frozen=True)
class Device:
    name: str
    protocol: str
    online: bool

ADAPTERS = {
    'zigbee': 'zigbee_gateway',
    'z-wave': 'zwave_controller',
    'matter': 'matter_controller',
}

def plan_command(device: Device, enabled: bool) -> dict:
    if not device.online:
        raise ConnectionError('Cihaz çevrimdışı')
    if device.protocol not in ADAPTERS:
        raise ValueError('Desteklenmeyen protokol')
    return {
        'adapter': ADAPTERS[device.protocol],
        'device': device.name,
        'action': 'set_power',
        'value': enabled,
    }

lamp = Device('salon_lambası', 'matter', True)
print(plan_command(lamp, True))

Gerçek adaptör, ortak set_power isteğini cihazın desteklediği komuta çevirir. Kimlik doğrulama, zaman aşımı, yeniden deneme ve durum doğrulaması ayrıca uygulanmalıdır. Böylece otomasyon mantığı, haberleşme ayrıntılarından bağımsız kalır.

Hangisini seçmeli?

Uygun fiyatlı sensör çeşitliliğinde Zigbee, bölgesel frekans avantajında Z-Wave, ekosistemler arası kullanımda Matter güçlü adaylardır. Yeni kurulumda yalnızca protokolü değil, gereken denetleyiciyi, çevrimdışı çalışma davranışını ve güncelleme politikasını da değerlendirin. Güvenli eşleştirme kullanın, yazılımı güncel tutun ve otomasyonlarınızı internet kesildiğinde sınayın. En akıllı ev, internet gidince ev olmayı unutmayan evdir.

C++ nesnelerini küçük bir atölyenin çalışanları gibi düşünün: İşe başlarken ekipmanlarını hazırlamaları, ayrılırken de masalarını toplamaları gerekir. Yapıcılar nesneyi kullanıma hazırlar; yıkıcılar ise nesnenin sorumluluğundaki kaynakların bırakılmasını sağlar. Bu ikiliyi anlamak, yalnızca bellek sızıntılarını önlemek değil, güvenilir sınıflar tasarlamak için de temel bir adımdır.

``

Önce teori: Bellek ile nesne aynı şey değildir

Bir nesne için depolama alanı ayrılması, o nesnenin doğru biçimde kurulmuş olması anlamına gelmez. Yapıcı, üyeleri başlatır ve sınıfın geçerli durum koşullarını oluşturur. Örneğin bir tamponun boyutu ile sahip olduğu depolama alanı birbiriyle uyumlu olmalıdır. Bu koşullara sınıf değişmezi, yani invariant denir.

Yıkıcı kaynakları temizler; nesnenin kendi depolama alanının bırakılması ise kullanılan depolama modeline bağlıdır. Dolayısıyla “yıkıcı belleği siler” ifadesi tek başına eksiktir.

Yapıcılar: Başlangıç ayarları önemlidir

Parametresiz çağrılabilen yapıcıya varsayılan yapıcı denir. Parametreli yapıcılar farklı başlangıç seçenekleri sunar. Bir yapıcının başka bir yapıcıyı çağırması ise delegasyon olarak adlandırılır; böylece aynı kurulum mantığını tekrar yazmazsınız.

Üyeleri yapıcı gövdesinde atamak yerine üye başlatma listesinde başlatmak genellikle daha doğrudur. Özellikle referans üyeler ve const üyeler burada başlatılmalıdır. Ayrıca üyeler, listede yazdığınız sırayla değil, sınıf içinde bildirildikleri sırayla başlatılır. Bu ayrıntı, başka bir üyeye bağlı başlangıç değerlerinde kritik önem taşır.

Uygulama: Kendi tamponunu yöneten sınıf

Aşağıdaki sınıf, tamsayı dizisini kurulum sırasında edinir ve yıkım sırasında bırakır. Ham işaretçi burada mekanizmayı görünür kılmak için kullanılıyor:

#include <cstddef>
#include <iostream>
#include <memory>

class Tampon {
    std::size_t boyut_;
    int* veri_;

public:
    Tampon() : Tampon(4) {}

    explicit Tampon(std::size_t boyut)
        : boyut_(boyut), veri_(new int[boyut]{}) {}

    Tampon(const Tampon&) = delete;
    Tampon& operator=(const Tampon&) = delete;

    ~Tampon() {
        delete[] veri_;
    }

    std::size_t boyut() const noexcept {
        return boyut_;
    }
};

int main() {
    Tampon yerel;
    auto dinamik = std::make_unique<Tampon>(8);
    std::cout << yerel.boyut() << '\n';
}

Tampon() dört elemanlık kuruluma yönlendirir. explicit, bir sayının istemeden Tampon nesnesine dönüştürülmesini engeller. Dizinin sonundaki {}, tamsayıları sıfırla başlatır. delete[], new[] ile edinilen diziyi doğru biçimde bırakır.

Kopyalama işlemleri özellikle kapatıldı: Varsayılan kopyalama iki nesnenin aynı adresi sahiplenmesine, ardından aynı belleğin iki kez bırakılmasına yol açabilirdi. Bu sınıf taşıma işlemleri de tanımlamadığından, sahipliğin nesneler arasında aktarılmasını desteklemez.

Yaşam süresi ve RAII

yerel, blok sona erdiğinde otomatik olarak yıkılır. dinamik ise bir std::unique_ptr tarafından sahiplenilir; akıllı işaretçi yıkılınca yönettiği Tampon da yıkılır ve depolama alanı bırakılır. Bu örnekte önce dinamik, ardından yerel temizlenir.

Bu yaklaşımın adı RAII: Kaynak edinimini nesne kurulmasına, kaynak bırakmayı nesne yıkımına bağlamak. Kaynak yalnızca bellek değildir; dosya, kilit veya bağlantı da olabilir.

Basit bir kaynak sayacıyla hedefi ifade edebiliriz:

Başlangıçta sahip olunan kaynak sayısı sıfırsa, nesnenin işi bittiğinde sonuç yine sıfır olmalıdır. Atölyeden çıkarken masada unutulan tornavida istemiyoruz!

İstisnalar ve güvenli tasarım

Yapıcı istisna fırlatırsa nesne tamamen kurulmuş sayılmaz; o nesnenin yıkıcısı çağrılmaz. Ancak başarıyla kurulmuş üyeler ve taban sınıflar temizlenir. Bu yüzden kaynakları akıllı işaretçi veya standart kapsayıcı üyelerde tutmak, yarım kalan kurulumlarda da güvenlik sağlar.

Yıkıcılardan istisna kaçırmaktan kaçının: Özellikle başka bir istisna nedeniyle yığın çözülürken bu durum std::terminate ile programı sonlandırabilir. Taban sınıf işaretçisi üzerinden türetilmiş nesneleri silecekseniz, taban yıkıcısını virtual yapın.

Gerçek projelerde bu tampon için çoğunlukla std::vector<int> tercih edilir. Böylece özel yıkıcı ve sahiplik kodu yazmadan Rule of Zero yaklaşımına ulaşılır. En iyi temizlik kodu, çoğu zaman güvenilir bir üyeye devrettiğiniz koddur.

``

Önce kavramları yerine oturtalım

Diegetik arayüz, oyunun kurmaca dünyasında gerçekten var olan bilgi sunumudur. Karakterin okuyabildiği bir bileklik ekranı veya zırhındaki durum göstergesi buna örnektir. Diegetik olmayan arayüz ise doğrudan oyuncuya seslenir: Ekranın köşesinde duran klasik can barını karakteriniz görmez.

Buradaki ayrım yalnızca iki boyutlu ve üç boyutlu olmak değildir. Düşmanın üzerinde süzülen bir can barı, sahnenin içinde çizilse bile kurmaca dünyada karşılığı yoksa otomatik olarak diegetik sayılmaz. Böyle göstergeler çoğunlukla mekânsal arayüz olarak değerlendirilir. Asıl soru şudur: Bu bilgi kaynağı, hikâyenin evreninde mevcut mu?

Bu sınıflar bir kalite sıralaması değildir. Diegetik tasarım her zaman daha sürükleyici, klasik HUD ise her zaman daha anlaşılır olmak zorunda değildir. Uygulama ve bağlam belirleyicidir.

Oyuncunun dikkat bütçesi

Oyuncu çatışma sırasında düşmanı, çevreyi ve kaynaklarını aynı anda izler. Can bilgisini almak için bileğini kaldırması gerekiyorsa, bilgiye erişmek başlı başına bir eyleme dönüşür. Bu, korku oyununda gerilim yaratabilir; hızlı bir rekabetçi oyunda ise gereksiz sürtünme oluşturabilir.

Bu maliyeti düşünmek için basit bir model kullanabiliriz:

Burada göstergeyi bulmak, anlamak ve karar vermek ayrı aşamalardır. Bu denklem evrensel bir ölçüm yasası değil, tasarım sorularını düzenleyen bir çerçevedir. Göstergeyi dünyaya yerleştirmek ilk iki süreyi artırıyorsa, kazandığınız atmosferin bu maliyeti karşılayıp karşılamadığını test etmelisiniz.

Unity: Aynı sağlık, iki farklı sunum

Aşağıdaki örnek, tek sağlık değerini hem ekran üzerindeki bir Image bileşenine hem de kıyafetteki uyarı lambasını temsil eden bir Light bileşenine aktarır. HUD nesnesini ekran uzayındaki Canvas içine yerleştirin; Image Type ayarını Filled yapın. Lambayı ise karakterin ekipmanına bağlayın.

using UnityEngine;
using UnityEngine.UI;

public class HealthFeedback : MonoBehaviour
{
    [SerializeField] private Image hudBar;
    [SerializeField] private Light suitLight;
    [SerializeField] private float maxHealth = 100f;
    private float health;

    private void Awake()
    {
        maxHealth = Mathf.Max(1f, maxHealth);
        health = maxHealth;
        Refresh();
    }

    public void TakeDamage(float amount)
    {
        health = Mathf.Clamp(
            health - Mathf.Max(0f, amount), 0f, maxHealth);
        Refresh();
    }

    private void Refresh()
    {
        float ratio = health / maxHealth;
        if (hudBar != null)
            hudBar.fillAmount = ratio;
        if (suitLight != null)
            suitLight.intensity = Mathf.Lerp(0.2f, 2f, ratio);
    }
}

Sağlık oranı $r = H/H_{max}$ ile normalize edilir. TakeDamage, negatif hasarı engeller ve sağlığı geçerli aralıkta tutar. Refresh, aynı veriyi iki görsel kanala dönüştürür. Büyük projelerde sağlık modeliyle sunum bileşenlerini ayırmak daha uygundur; burada bağlantıyı görünür tutmak için birlikte gösteriyoruz. Lambanın ayrıca görünür bir gövdesi ve anlaşılır bir kurmaca gerekçesi olmalıdır.

Hangisini seçmeli?

Seçimi yalnızca estetik tercihle yapmayın. Oyunun temposu, bilginin önemi ve oyuncunun görsel koşulları birlikte değerlendirilmelidir. Diegetik bir lambanın parlaklığı, aydınlık sahnelerde kolayca kaybolabilir. Kritik bilgiyi yalnızca renkle anlatmak da erişilebilirlik sorunları yaratır.

İki sürümü aynı görevde deneyin. Oyuncuların düşük sağlığı fark etme süresini, kaçırdığı uyarıları ve öznel sürükleyicilik değerlendirmelerini karşılaştırın. Kamera hareketi, ekran boyutu ve ışık koşullarını da değiştirin. Böylece yalnızca güzel görünen değil, farklı koşullarda işleyen bir tasarım seçersiniz.

Sonuçta iyi arayüz, kendini gizleyen arayüz değildir. Oyuncuya doğru bilgiyi doğru anda veren arayüzdür. Bazen bu bilgi bilekte yaşar; bazen ekranın köşesinde. Can barının adresinden çok, oyuncunun onu gerektiğinde bulabilmesi önemlidir.

``

API: Finans dünyasının ortak sözleşmesi

API, bir yazılımın başka bir yazılıma sunduğu programlama arayüzüdür. Bankacılıkta bu arayüz; hesapları listelemek, işlem geçmişini okumak veya ödeme başlatmak gibi yetenekler sunabilir.

Buradaki temel fikir sözleşmedir: Hangi adrese istek gönderileceği, hangi alanların beklendiği, kimlerin erişebileceği ve hataların nasıl bildirileceği önceden tanımlanır. API, bankanın veritabanına açılan sınırsız bir kapı değil, yetkileri sınırlandırılmış bir servis girişidir.

REST tabanlı sistemlerde HTTP yöntemleri yaygındır: GET veri okumak, POST ise ödeme talebi gibi yeni bir işlem oluşturmak için kullanılabilir. JSON, taşınan verinin sık kullanılan formatıdır; ancak bütün bankalar aynı uç noktaları veya alan isimlerini kullanmaz.

Bir isteğin banka yolculuğu

Bir açık bankacılık uygulamasının hesap bilgilerini okuduğunu düşünelim:

1. İzin: Kullanıcı, hangi hesaplara ve verilere erişilebileceğini onaylar. Bu onay belirli bir süreyle sınırlandırılabilir.
2. Yetkilendirme: Uygulama, uygun akış üzerinden bir erişim belirteci alır. OAuth 2.0 burada sık kullanılan bir yetkilendirme çerçevesidir.
3. İstek: Uygulama, erişim belirtecini ekleyerek bankanın API’sine HTTPS üzerinden bağlanır.
4. Kontrol: Banka; uygulamanın yetkisini, iznin geçerliliğini ve istenen işlemin kapsamını denetler.
5. Yanıt: Banka, sözleşmeye uygun veriyi veya bir hata yanıtını döndürür.

OAuth 2.0, tek başına her durumda kullanıcı kimliğini doğrulayan bir protokol değildir. Kimlik doğrulama ile yetkilendirme ilişkili, fakat farklı kavramlardır. Ayrıca uygulamanın kullanıcıdan internet bankacılığı şifresini toplaması bu modelin gereği değildir.

Anlık yanıt, tamamlanmış işlem demek değildir

Toplam yanıt süresini kabaca $T = T_a + T_k + T_i$ şeklinde düşünebiliriz. Burada $T_a$ ağ gecikmesini, $T_k$ güvenlik kontrollerini, $T_i$ ise işlem süresini temsil eder. Fakat bu süre yalnızca isteğin yanıtlanmasını anlatır; paranın kesin olarak alıcıya geçtiğini değil!

Bunlar rakip değil, tamamlayıcı yöntemlerdir. Örneğin 202 Accepted, isteğin işlenmek üzere kabul edildiğini belirtir; ödeme başarısı garantisi vermez. Kesin durum, sorgulama uç noktasından veya doğrulanmış bir webhook üzerinden öğrenilebilir.

Python ile örnek ödeme isteği

Aşağıdaki örnek, requests kütüphanesiyle temsili bir API’ye ödeme talebi gönderir. Alanlar sağlayıcıya göre değişir; API_ROOT gerçek para hareketi olmayan test ortamına ayarlanmalıdır.

import os
import requests

payment_key = os.environ["PAYMENT_KEY"]
response = requests.post(
    f'{os.environ["API_ROOT"]}/payments',
    headers={
        "Authorization": f'Bearer {os.environ["ACCESS_TOKEN"]}',
        "Idempotency-Key": payment_key,
    },
    json={
        "amount_minor": 1250,
        "currency": "TRY",
        "recipient_ref": "beneficiary_42",
    },
    timeout=(3, 10),
)
response.raise_for_status()
print(response.json()["status"])

Bu örnekte tutar, sözleşme gereği kuruş cinsindendir: 1250 kuruş, 12,50 TL eder. Tamsayı kullanımı, kayan noktalı sayıların hassasiyet sorunlarını önlemeye yardımcı olur. Bağlantı ve okuma zaman aşımı ayrı tanımlanmıştır; kod HTTP hatasında istisna üretir. Üretimde bu hatalar ayrıca ele alınmalıdır.

Idempotency anahtarı, sağlayıcı destekliyorsa, aynı mantıksal talebin tekrarında ikinci bir ödeme oluşmasını önlemeye yardımcı olur. Anahtar işlemle birlikte kalıcı saklanmalı, tekrar denemelerinde değiştirilmemelidir. Sağlayıcının saklama süresi ve tekrar davranışı mutlaka incelenmelidir.

Güvenlik ve belirsizlikle yaşamak

HTTPS aktarımı korur; bazı entegrasyonlarda karşılıklı TLS ile uygulamanın sertifikası da doğrulanır. Erişim belirteçleri ve hesap bilgileri günlüklere gelişigüzel yazılmamalıdır. Webhook’larda sağlayıcının imza doğrulaması uygulanmalı, tekrar oynatılan veya yinelenen bildirimler hesaba katılmalıdır.

En kritik senaryo şudur: Banka ödemeyi kabul eder, fakat yanıt ağda kaybolur. Zaman aşımı, başarısız ödeme anlamına gelmez. Körlemesine yeni ödeme oluşturmak yerine mevcut işlem sorgulanmalı ve belgelenmiş tekrar mekanizması kullanılmalıdır. Hız sınırı yanıtlarında da sağlayıcının bekleme talimatlarına uyulmalıdır.

Son olarak mutabakat, uygulamanızdaki kayıtlarla bankanın kayıtlarını karşılaştırır. Çünkü sağlam fintech entegrasyonu yalnızca konuşabilen değil; yanlış anlayınca durabilen, tekrarları yönetebilen ve gün sonunda hesabını verebilen yazılımdır.

``

İsim silmek neden yetmez?

Bir kayıttan ad, telefon ve kimlik numarasını kaldırmak, o kaydı otomatik olarak anonim yapmaz. Yaş, posta kodu ve hastaneye başvuru tarihi gibi dolaylı tanımlayıcılar, başka kaynaklarla eşleştirildiğinde kişiyi yeniden ortaya çıkarabilir. Nadir hastalıklar bu riski özellikle artırır.

Örneğin, küçük bir ilçede yaşayan 97 yaşındaki tek kişinin kayıtlarında isim bulunmasa bile kimliği tahmin edilebilir. Dolayısıyla takma kimlik kullanmak ile anonimlik aynı şey değildir. Takma kimlikli kayıtlar, bağlantı anahtarı veya yardımcı bilgiler üzerinden kişilere bağlanabilir.

Diferansiyel mahremiyetin matematiksel fikri

Diferansiyel mahremiyet, genellikle satırları anonimleştirmekten ziyade yayımlanan istatistikleri veya model çıktılarını korur. Amaç, tek bir hastanın araştırmaya katılıp katılmamasının sonuçları fazla değiştirmemesidir.

Bir hastanın eklenmesi veya çıkarılmasıyla farklılaşan iki veri kümesine $D$ ve $D’$ diyelim. Rastgeleleştirilmiş mekanizma $M$, herhangi bir çıktı kümesi $S$ için şu koşulu sağlamalıdır:

Burada $\varepsilon$ mahremiyet kaybını kontrol eder: küçük değer daha güçlü koruma, genellikle daha fazla gürültü demektir. $\delta$ ise eşitsizliğe eklenen küçük bir olasılık payıdır; doğrudan yeniden kimliklendirme ihtimali olarak okunmamalıdır. Laplace mekanizması uygun koşullarda $\delta=0$ sağlar.

Önemli ayrıntı: Koruma birimi hasta olmalıdır. Aynı hastanın yirmi muayenesini bağımsız kişiler gibi sayarsanız, kayıt düzeyindeki güvence hasta düzeyindeki güvenceye dönüşmez.

Gürültü rastgele, miktarı hesaplı

Bir sorgunun duyarlılığı $\Delta f$, tek hastanın değişmesiyle sonucun değişebileceği en büyük miktardır. Her hasta sayıma en fazla bir katkı yapıyorsa, ekleme/çıkarma komşuluğunda sayımın duyarlılığı $1$ olur.

Laplace mekanizması şu çıktıyı üretir:

$\varepsilon=0.5$ için gürültü ölçeği $2$, $\varepsilon=0.1$ için $10$ olur. Yani mahremiyet düğmesini çevirdikçe istatistik biraz daha bulanıklaşır. Bu, gelişigüzel veri bozmak değil; etkisi hesaplanan bir tasarım tercihidir.

Python ile korumalı hasta sayımı

Aşağıdaki eğitim örneğinde her Boolean değer, farklı bir hastanın hipertansiyon durumunu temsil eder. Gerçek sistemde tekrarlanan ziyaretler önce hasta düzeyinde birleştirilmelidir. Kod yalnızca gürültülü toplamı döndürür; gerçek toplam yayımlanmaz.

import numpy as np


def ozel_sayim(hasta_bayraklari, epsilon=0.5):
    if not np.isfinite(epsilon) or epsilon <= 0:
        raise ValueError("Epsilon pozitif ve sonlu olmalı.")
    if not all(type(x) is bool for x in hasta_bayraklari):
        raise ValueError("Her hasta için bir Boolean gerekli.")

    gercek_toplam = sum(hasta_bayraklari)
    duyarlilik = 1.0
    rng = np.random.default_rng()
    gurultu = rng.laplace(0.0, duyarlilik / epsilon)
    return max(0, int(round(gercek_toplam + gurultu)))


# Tamamen sentetik: 1.000 hasta, 240 pozitif durum.
ornek = [True] * 240 + [False] * 760
print(ozel_sayim(ornek))

Negatif sonuçları sıfıra çekmek ve yuvarlamak, yalnızca korumalı çıktıya uygulanan son işlemedir; ek mahremiyet kaybı yaratmaz. Ancak sonucu yanlılaştırabilir. NumPy örneği üretim garantisi değildir: güvenli rastgelelik, kayan nokta davranışı ve mekanizma doğruluğu için OpenDP gibi denetlenmiş araçlar değerlendirilmelidir.

Mahremiyet bütçesi sınırsız değildir

Aynı hastalar üzerinde tekrar tekrar sorgu yayımlamak bilgi biriktirir. Temel bileşim kuralında toplam bütçe $\varepsilon_{toplam}\le\sum_i\varepsilon_i$ şeklinde izlenebilir. Sonuçları tekrar üreterek ortalamasını almak, gürültüyü azaltırken mahremiyet maliyetini artırır.

Bu nedenle sorgu onayı, bütçe kaydı ve erişim denetimi birlikte tasarlanmalıdır. Ortalama gibi sorgularda katkı sınırları ayrıca belirlenmelidir; sınırsız ölçüm değerleri uygun duyarlılık hesabını bozar. Küçük hasta gruplarında gürültünün göreli etkisi büyüdüğünden, klinik yorumlar belirsizlikle sunulmalıdır.

Diferansiyel mahremiyet, ham veriyi şifrelemenin veya KVKK yükümlülüklerinin yerine geçmez. Sağlam yaklaşım; veri minimizasyonu, güvenli saklama ve kontrollü yayımlamayı birleştirir. Böylece araştırma ilerlerken hastanın mahremiyeti, sonradan eklenen bir aksesuar değil, sistemin temel tasarım ilkesi olur.

``

Önce hedefi ve molekülü tanıyalım

İlaç adayının bağlandığı moleküle hedef, aday küçük moleküle ise çoğunlukla ligand denir. Protein üzerindeki bağlanma cebi; geometrisi, elektrik yükleri ve suyla ilişkisi nedeniyle bazı ligandları diğerlerinden daha iyi karşılar. Buradaki mesele yalnızca anahtarın kilide sığması değildir: Kilit esner, anahtar döner ve aradaki su molekülleri pazarlığa katılır.

Önce deneysel veya tahmini bir protein yapısı hazırlanır. Eksik atomlar, protonlanma durumları, önemli su molekülleri ve gerekiyorsa metal iyonları değerlendirilir. Ligandın üç boyutlu geometrisi ve yükleri hazırlanır. Yanlış protonlanma, hesaplamanın sonucunu değiştirebilir; bilgisayar, yanlış hazırlanmış girdiyi büyük bir özgüvenle işlemekten çekinmez.

İlk eleme: Moleküler kenetlenme

Moleküler kenetlenme, yani docking, ligandın bağlanma cebindeki olası yerleşimlerini araştırır. Arama algoritması konum, yönelim ve dönebilen bağları değiştirir; puanlama fonksiyonu ise temasları değerlendirir. Hidrojen bağları, hidrofobik etkileşimler ve sterik çakışmalar bu değerlendirmede rol oynar.

Docking, binlerce adayı hızla daraltabilir. Fakat verdiği skor, ölçülmüş bağlanma afinitesi veya kesin bir serbest enerji değildir. Farklı yazılımların skorlarını doğrudan aynı terazide tartmak da güvenilir olmaz.

Hareket başlasın: Moleküler dinamik

Moleküler dinamikte atomlar, bir kuvvet alanının tanımladığı potansiyel enerjiye göre hareket eder. Bağların gerilmesi, açıların değişmesi, elektrostatik ve van der Waals etkileşimleri birlikte hesaplanır. Kuvvet, enerjinin konuma göre değişiminden elde edilir:

Newton denklemleri küçük zaman adımlarıyla çözülür. Böylece tek bir görüntü yerine bir yörünge oluşur. Protein nefes alır gibi kıpırdar; ligand bazı temasları kaybederken yenilerini kurabilir. Termostat, sistemin sıcaklığını hedef değer çevresinde tutmaya yardımcı olur.

Aşağıdaki OpenMM örneği, önceden hazırlanmış, su ve iyon içeren periyodik bir AMBER kompleksini çalıştırır. Protein ve ligandın uyumlu kuvvet alanı parametreleri dosyalarda bulunmalıdır; kod parametre üretmez.

from openmm import LangevinMiddleIntegrator
from openmm.app import (
    AmberPrmtopFile, AmberInpcrdFile, Simulation,
    PME, HBonds, DCDReporter
)
from openmm.unit import kelvin, picosecond, nanometer

prmtop = AmberPrmtopFile("complex.prmtop")
inpcrd = AmberInpcrdFile("complex.inpcrd")
system = prmtop.createSystem(
    nonbondedMethod=PME,
    nonbondedCutoff=1.0 * nanometer,
    constraints=HBonds
)
integrator = LangevinMiddleIntegrator(
    300 * kelvin, 1 / picosecond, 0.002 * picosecond
)
sim = Simulation(prmtop.topology, system, integrator)
sim.context.setPositions(inpcrd.positions)
sim.context.setPeriodicBoxVectors(*inpcrd.boxVectors)
sim.minimizeEnergy()
sim.context.setVelocitiesToTemperature(300 * kelvin)
sim.step(10000)
sim.reporters.append(DCDReporter("trajectory.dcd", 1000))
sim.step(250000)

Enerji minimizasyonu kötü temasları azaltır; ardından kısa bir ön dengeleme yapılır. Son bölüm, iki femtosaniyelik adımlarla 0,5 nanosaniyelik yörünge üretir. Bu yalnızca teknik bir başlangıçtır; güvenilir analiz için daha kapsamlı dengeleme, daha uzun koşular ve bağımsız tekrarlar gerekir.

Yörüngeden karar çıkarmak

Ligandın yer değiştirmesi, hidrojen bağlarının devamlılığı ve cebin şekil değişimleri incelenebilir. Ancak düşük RMSD, tek başına güçlü bağlanmanın kanıtı değildir. Ayrıca proteinin genel hareketini ayırmadan hesaplanan ligand RMSD değerleri yanıltıcı olabilir.

Bağlanma termodinamiği için standart serbest enerji önemlidir:

Burada $K_d$ ayrışma sabiti, $C^\circ$ standart derişimdir. Daha küçük $K_d$, daha elverişli bağlanmaya karşılık gelir. Benzer adayların farklarını inceleyen FEP gibi yöntemler güçlüdür; fakat yeterli örnekleme ve belirsizlik analizi şarttır.

Son söz laboratuvarın

İyi bağlanmak, mutlaka iyi ilaç olmak değildir. Adayın proteini gerçekten baskılayıp baskılamadığı, başka hedeflere bağlanması, hücreye erişmesi, metabolizması ve toksisitesi ayrıca değerlendirilir. Simülasyon sonuçları biyokimyasal, hücresel ve gerektiğinde ileri deneylerle doğrulanmalıdır.

En verimli yaklaşım, docking ile elemek, dinamikle davranışı incelemek ve uygun adaylarda serbest enerji hesaplarına ilerlemektir. Parametreleri, yazılım sürümlerini ve tekrar koşullarını kaydetmek de sonuçları yeniden üretilebilir kılar. Bilgisayar burada sihirli ilaç makinesi değil; yanlış adaylara harcanan emeği azaltan, doğru deneyleri tasarlamaya yardımcı olan meraklı bir araştırma ortağıdır.

``

Markowitz modelinin temel fikri

Harry Markowitz tarafından geliştirilen modern portföy teorisi, yatırım araçlarını yalnızca tek tek değerlendirmez. Varlıkların birbirleriyle nasıl hareket ettiğini de hesaba katar. Çünkü iki riskli varlık, fiyatları farklı yönlerde hareket ediyorsa birlikte daha dengeli bir portföy oluşturabilir.

Bir portföyde $n$ adet varlık bulunduğunu düşünelim. Her varlığa ayrılan oranı $w_i$ ile gösterirsek ağırlıkların toplamı genellikle şöyle sınırlandırılır:

Açığa satışa izin verilmiyorsa ayrıca $w_i \geq 0$ koşulu uygulanır. Portföyün beklenen getirisi:

Portföy riski, yani varyansı ise kovaryans matrisi kullanılarak hesaplanır:

Burada $\boldsymbol{\mu}$ beklenen getiriler vektörü, $\Sigma$ kovaryans matrisi ve $\mathbf{w}$ portföy ağırlıklarıdır. Standart sapma için varyansın karekökü alınır.

Python ile minimum varyanslı portföy

Aşağıdaki örnekte yıllık beklenen getirileri ve kovaryans matrisini doğrudan tanımlıyoruz. Gerçek projelerde bunlar günlük fiyat verilerinden hesaplanabilir.

import numpy as np
from scipy.optimize import minimize

returns = np.array([0.12, 0.18, 0.10, 0.15])

covariance = np.array([
    [0.040, 0.010, 0.008, 0.012],
    [0.010, 0.090, 0.006, 0.020],
    [0.008, 0.006, 0.025, 0.009],
    [0.012, 0.020, 0.009, 0.060]
])

asset_count = len(returns)
initial_weights = np.ones(asset_count) / asset_count

def portfolio_variance(weights):
    return weights.T @ covariance @ weights

constraints = [
    {'type': 'eq', 'fun': lambda w: np.sum(w) - 1}
]

bounds = [(0, 1)] * asset_count

result = minimize(
    portfolio_variance,
    initial_weights,
    method='SLSQP',
    bounds=bounds,
    constraints=constraints
)

weights = result.x
portfolio_return = weights @ returns
portfolio_risk = np.sqrt(portfolio_variance(weights))

print('Ağırlıklar:', np.round(weights, 3))
print('Beklenen getiri:', round(portfolio_return, 3))
print('Risk:', round(portfolio_risk, 3))

portfolio_variance fonksiyonu optimizasyonun küçültmeye çalıştığı hedefi temsil eder. constraints, sermayenin tamamının kullanılmasını; bounds ise hiçbir varlığın negatif ağırlık almamasını sağlar. SLSQP algoritması, eşitlik ve sınır koşulları içeren bu tür problemlerde oldukça kullanışlıdır.

Hedef getiri ve etkin sınır

Minimum varyanslı portföy güvenlidir; ancak beklenen getirisi yatırımcı için yetersiz kalabilir. Örneğin en az %14 getiri istiyorsak ikinci bir koşul ekleyebiliriz:

target_return = 0.14
constraints.append({
    'type': 'eq',
    'fun': lambda w: w @ returns - target_return
})

result = minimize(
    portfolio_variance,
    initial_weights,
    method='SLSQP',
    bounds=bounds,
    constraints=constraints
)

Farklı hedef getiriler için optimizasyonu tekrarladığımızda etkin sınır ortaya çıkar. Bu eğri üzerindeki her portföy, aynı getiri seviyesindeki alternatiflerden daha düşük riske sahiptir.

Markowitz modeli güçlüdür ama kusursuz değildir: geçmiş getirilerin geleceği temsil ettiği, korelasyonların sabit kaldığı ve işlem maliyetlerinin önemsiz olduğu varsayılır. Bu nedenle sonuçları kesin reçete değil, karar destek aracı olarak görmek gerekir. Sağlam veri, periyodik yeniden dengeleme ve ağırlık sınırları eklendiğinde model, portföyünüz için matematik bilen bir yardımcı pilota dönüşebilir.

``

Problem aslında nedir?

Kanser hücreleri sağlıklı hücrelerden çekirdek büyüklüğü, şekil düzensizliği, kromatin yoğunluğu ve hücre bölünme hızı gibi özelliklerle ayrılabilir. Ancak boyama yöntemi, mikroskop ışığı ve doku türü değiştikçe görüntünün görünümü de değişir. Dolayısıyla bilgisayar yalnızca “koyu renkli olan kanserdir” gibi basit bir kuralla güvenilir sonuç üretemez.

Tipik bir sistem dört aşamadan oluşur:

1. Görüntünün renk ve gürültü bakımından düzeltilmesi
2. Hücre veya çekirdeklerin bölütlenmesi
3. Her hücreden açıklayıcı özelliklerin çıkarılması
4. Hücrenin normal ya da anormal olarak sınıflandırılması

Hücreyi matematikle anlatmak

Bir hücrenin alanı $A$, çevresi $P$ ile gösterilsin. Şeklin ne kadar dairesel olduğunu ölçmek için şu değer kullanılabilir:

Kusursuz bir dairede $C$ değeri 1’e yaklaşır. Girintili çıkıntılı hücrelerde ise küçülür. Bunun yanında çekirdeğin ortalama parlaklığı, renk dağılımı ve komşularına göre büyüklüğü de modele verilebilir.

Sınıflandırıcı çoğu zaman $p(y=1\mid x)$, yani özellikleri $x$ olan hücrenin anormal olma olasılığını hesaplar. Olasılık belirlenen eşiği aşarsa hücre şüpheli kabul edilir. Eşiği düşürmek daha fazla şüpheli hücre yakalar; fakat yanlış alarm sayısını da artırır.

Basit bir prototip

Aşağıdaki Python örneği, gri tonlamalı görüntüde koyu çekirdekleri ayırır, küçük gürültüleri temizler ve büyük hücre adaylarını işaretler. Bu kod klinik tanı sistemi değil, temel görüntü işleme mantığını gösteren bir başlangıçtır.

import cv2

image = cv2.imread("hucreler.png")
gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)

# Gürültüyü azaltarak eşikleme sonucunu daha kararlı yapar.
blurred = cv2.GaussianBlur(gray, (5, 5), 0)

# Otsu yöntemi uygun eşik değerini görüntüden otomatik hesaplar.
_, mask = cv2.threshold(
    blurred, 0, 255,
    cv2.THRESH_BINARY_INV + cv2.THRESH_OTSU
)

contours, _ = cv2.findContours(
    mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE
)

for contour in contours:
    area = cv2.contourArea(contour)
    if area > 250:  # Örnek amaçlı şüpheli büyüklük sınırı
        x, y, w, h = cv2.boundingRect(contour)
        cv2.rectangle(image, (x, y), (x + w, y + h), (0, 0, 255), 2)

cv2.imwrite("isaretli_hucreler.png", image)

Gerçek dokularda hücreler üst üste binebilir. Böyle durumlarda watershed algoritması veya piksel düzeyinde öğrenen U-Net gibi derin öğrenme modelleri daha başarılıdır. Yine de derin modeller daha fazla etiketli veri, güçlü donanım ve dikkatli doğrulama gerektirir.

Başarıyı doğru ölçmek

Kanser taramasında yalnızca doğruluk değerine bakmak yanıltıcıdır. Bin hücrenin yalnızca onu anormalse, her hücreye “normal” diyen model yüzde 99 doğruluk elde eder ama hiçbir vakayı bulamaz.

Veriler hasta bazında ayrılmalıdır; aynı hastaya ait benzer görüntülerin hem eğitim hem test kümesine girmesi veri sızıntısına yol açar. Ayrıca farklı laboratuvarlardan alınan örneklerle harici doğrulama yapılmalıdır.

Sonuç olarak bilgisayar, patoloğun yerini alan sihirli bir doktor değil; yorucu tarama işini hızlandıran dikkatli bir asistandır. Güvenilir bir sistem için kaliteli etiketler, açıklanabilir sonuçlar, mahremiyet koruması ve uzman denetimi vazgeçilmezdir.