``

1. Temel fikir: Belgeyi değil, işi bölmek

Crowdsourcing, büyük bir görevi bağımsız katkılara ayırarak dağıtılmış insan emeğinden yararlanır. Buradaki çalışma birimi genellikle belgenin tamamı değil, sayfa veya satır bölgesidir. Küçük görevler katılım eşiğini düşürür; aşırı küçük görevler ise bağlamı kaybettirir. Bir kelimenin doğru okunuşu bazen önceki cümlede saklıdır.

Bu nedenle görev ekranı hedef satırı vurgularken komşu satırları da göstermelidir. Gönüllü, okunamayan karakteri işaretleyebilmeli ve tahminini kesin bilgi gibi sunmaya zorlanmamalıdır. Diplomatik transkripsiyon özgün yazımı korurken, normalleştirilmiş metin aramayı kolaylaştırır. Bunları ayrı alanlarda tutmak, geçmişi modern imlaya yanlışlıkla boyamayı önler.

2. Mimari: Her parçanın kendi sorumluluğu

Başlangıçta modüler bir monolit yeterlidir. Kullanıcı, görev, transkripsiyon ve inceleme modülleri belirgin sınırlara sahip olduğunda, gerektiğinde ayrı servislere taşınabilir. İlk günden mikroservis kurmak, tek mektubu okumak için küçük bir uzay üssü işletmeye benzeyebilir.

IIIF uyumlu görsel sunumu, büyük taramaların yalnızca gereken bölümlerini yüklemeyi kolaylaştırır. PostgreSQL ise görsel dosyalarını değil, dosya adreslerini ve ilgili kayıtları saklar.

3. Veri modeli ve görev yaşam döngüsü

Temel ilişkiler şöyle kurulabilir: koleksiyon belgeyi, belge sayfayı, sayfa koordinatlarla tanımlanmış bölgeleri içerir. Her transkripsiyon; bölge kimliği, katkıcı kimliği, metin, zaman ve sürüm numarası taşır. Onaylanan metin, katkı geçmişinden ayrı bir yayın kaydıdır.

Görevler bekliyor, düzenleniyor, incelemede ve yayımlandı durumlarından geçebilir. Düzenleme sırasında süreli rezervasyon kullanılır; tarayıcısını kapatan gönüllü görevi sonsuza kadar kilitlemez. Aynı bölgeye bağımsız okumalar atanacaksa rezervasyon bölgeye değil, ilgili görev atamasına uygulanır.

Eşzamanlı güncellemelerde iyimser kilitleme işe yarar: istemci mevcut sürümü gönderir, sunucu sürüm değişmişse üzerine yazmak yerine çatışma bildirir. Katkı kaydıyla kuyruk olayını aynı veritabanı işleminde yazan outbox deseni de kaybolan bildirimleri azaltır.

4. Uzlaşma: Çoğunluk her zaman haklı mı?

Aynı satırı bağımsız gönüllülere okutmak hataları yakalamaya yardımcı olur. Fakat herkes aynı yanıltıcı harfi yanlış okuyabilir. Dolayısıyla uzlaşma, doğruluğun kanıtı değil, inceleme önceliği belirleyen bir sinyaldir.

Bir aday metnin ağırlıklı desteğini şöyle hesaplayabiliriz:

Burada $w_u$ katkıcının ağırlığı, $I$ ise eşleşmede bir, diğer durumda sıfırdır. Başlangıçta eşit ağırlıklar kullanılabilir; sonradan doğrulanmış örneklerle kalibrasyon yapılır.

5. Python ile küçük bir uzlaşma çekirdeği

Aşağıdaki fonksiyon, aynı kullanıcının tekrar oy vermesini reddeder. Unicode normalizasyonu uygular; ancak tarihsel yazımı değiştirebilecek küçük harfe dönüştürme veya noktalama temizliği yapmaz.

from collections import defaultdict
from unicodedata import normalize


def consensus(votes):
    scores = defaultdict(float)
    users = set()
    for user_id, text, weight in votes:
        if user_id in users:
            raise ValueError('Tekrarlanan katkıcı')
        if not 0 < weight <= 1:
            raise ValueError('Geçersiz ağırlık')
        users.add(user_id)
        scores[normalize('NFC', text)] += weight

    if not scores:
        return None, 0.0, False

    candidate = max(scores, key=scores.get)
    support = scores[candidate] / sum(scores.values())
    ready = len(users) >= 3 and support >= 0.85
    return candidate, support, ready

Fonksiyon aday metni, destek oranını ve incelemeye hazır olma durumunu döndürür. Üç bağımsız katkı ve yüzde 85 destek, örnek politika değerleridir; olasılıksal doğruluk garantisi değildir. Ağırlıklar istemciden değil, sunucudaki güvenilir kayıtlardan alınmalıdır.

6. Yayına giden son kilometre

Katkıcıları birbirinin cevabını görmeden çalıştırmak bağımsızlığı güçlendirir. Yetkilendirme, hız sınırlama ve denetim kayıtları kötüye kullanımı azaltır. Tekrarlanan kuyruk mesajları için idempotent işçiler gerekir.

Son olarak TEI-XML gibi bir formatla dışa aktarım sunun; belirsizlikleri, alternatif okumaları ve kaynak koordinatlarını koruyun. Başarıyı yalnızca tamamlanan satır sayısıyla değil, uzmanların bulduğu hata oranı ve gönüllülerin devamlılığıyla ölçün. Böylece arşiv yalnızca dijitalleşmez; güvenilir, izlenebilir ve yeniden kullanılabilir hale gelir.

Telefonunuzda “Öde” düğmesine dokunuyorsunuz; birkaç saniye sonra yeşil bir onay beliriyor. Görünürde tek hareket, arka planda ise kimlik doğrulama, risk değerlendirmesi, banka iletişimi ve muhasebe kayıtlarından oluşan koordineli bir operasyon var. Üstelik internet bağlantınız tam o anda kesilebilir! Peki sistem, hem hızlı davranıp hem de paranızı yanlışlıkla iki kez göndermemeyi nasıl başarıyor?

``

Önce kavramları ayıralım

Bir ödeme, yalnızca veritabanındaki bakiyeyi azaltmak değildir. Kartlı işlemlerde yetkilendirme, tutarın kullanılabilirliğinin onaylanmasıdır; tahsilat ve mutabakat ise farklı aşamalardır. Kullanıcının gördüğü başarı mesajı, bankalar arasındaki nihai hesaplaşmanın tamamlandığı anlamına gelmeyebilir.

Temel tasarım hedefi, dağıtık bileşenler arasında para hareketinin anlamını korumaktır. Bunun için ödeme durumu açıkça modellenir: pending → authorized → captured; başarısızlık, iptal ve iade ayrı geçişlerdir. Her işlem bütün aşamalardan geçmez; örneğin uygulama içi cüzdan transferi farklı bir akış kullanabilir.

Bir isteğin saniyelik yolculuğu

1. API katmanı, erişim belirtecini doğrular; tutar, para birimi ve alıcı gibi alanları denetler. Kimliği doğrulanmış olmak, her hesaptan ödeme yapabilmek demek değildir: yetki kontrolü ayrıca gerekir.
2. Ödeme servisi, isteği benzersiz bir anahtarla kaydeder. Böylece yeniden denemeler aynı işlemle ilişkilendirilir.
3. Risk motoru, cihaz geçmişi, işlem sıklığı ve alışılmadık tutarlar gibi sinyalleri değerlendirir. Gerektiğinde ek doğrulama ister.
4. Sağlayıcı adaptörü, banka veya ödeme kuruluşuyla konuşur. Zaman aşımı, kesin başarısızlık sayılmaz; karşı taraf işlemi kabul etmiş olabilir.
5. Durum makinesi, yanıtı veya doğrulanmış webhook bildirimini işler. Mobil uygulama güncel durumu sorgulayabilir ya da bildirim alabilir.

Toplam gecikmeyi kabaca $L = L_{ağ} + L_{risk} + L_{sağlayıcı} + L_{kayıt}$ şeklinde düşünebiliriz. Bağımsız kontroller paralelleştirilebilir; ancak güvenlik kontrolleri sırf hız uğruna atlanamaz.

Paranın hafızası: çift taraflı defter

Muhasebe defteri, yalnızca güncel bakiyeyi değil, bakiyeyi oluşturan hareketleri saklar. Çift taraflı kayıtta her hareketin karşılığı bulunur. Aynı para birimindeki dengeli bir muhasebe işlemi için:

Burada $e_i$, işaretli kayıt tutarıdır. Ücretler de ayrı hesaplarla dengelenir. Para, kayan noktalı sayılarla değil, kuruş gibi en küçük birimin tamsayı karşılığıyla veya uygun sabit hassasiyetli türlerle tutulmalıdır. Farklı para birimleri doğrudan toplanmaz; kur dönüşümü ayrıca modellenir.

Çift tıklamaya dayanıklı işlem başlatma

Aşağıdaki Python örneği, PostgreSQL ve Psycopg kullanarak ödeme kaydıyla iş kuyruğu kaydını aynı yerel transaction içinde oluşturur. Örnek yalnızca TRY işlemlerini varsayar; tutar ve alıcı doğrulaması önceden yapılmıştır. payments.id otomatik üretilir ve (user_id, idem_key) üzerinde benzersiz kısıt bulunur.

def baslat(conn, user_id, key, amount, target):
    with conn.transaction():
        row = conn.execute(
            "INSERT INTO payments "
            "(user_id, idem_key, amount_minor, target_id, status) "
            "VALUES (%s, %s, %s, %s, 'pending') "
            "ON CONFLICT (user_id, idem_key) DO NOTHING RETURNING id",
            (user_id, key, amount, target)
        ).fetchone()
        if row:
            conn.execute(
                "INSERT INTO outbox (payment_id, event_type) "
                "VALUES (%s, 'payment_requested')", (row[0],)
            )
            return row[0], "pending"
        old = conn.execute(
            "SELECT id, amount_minor, target_id, status FROM payments "
            "WHERE user_id = %s AND idem_key = %s", (user_id, key)
        ).fetchone()
        if old[1:3] != (amount, target):
            raise ValueError("Anahtar farklı bir istekle kullanılmış")
        return old[0], old[3]

Outbox deseni, kaydedilmiş ödemenin gönderim işinin kaybolmasını önler. Çalışan süreç olayı tekrar gönderebileceğinden tüketici ve sağlayıcı çağrısı da idempotent olmalıdır. Yerel transaction, bankayı kapsayan küresel bir transaction değildir.

Güvenlik ve toparlanma

TLS, tokenizasyon, sır yönetimi ve hassas verilerin loglardan çıkarılması temel önlemlerdir. Webhook imzası doğrulanmalı, tekrar gönderimleri ayıklanmalıdır. Periyodik mutabakat, eksik bildirimleri ve tutarsız kayıtları yakalar.

Sonuç: hızlı ödeme, her şeyi tek seferde bitirmek değil; belirsizlikleri güvenle yönetmektir. Yeşil tikin arkasındaki gerçek kahramanlar, sağlam kayıtlar ve kontrollü yeniden denemelerdir.

``

Blokların arkasındaki düşünme biçimi

Algoritma, bir hedefe ulaşmak için tanımlanan, sıralı ve yeterince açık adımlar bütünüdür. “Karakteri kazandır” bir hedef belirtir; fakat nasıl kazanacağını açıklamaz. “Yıldızı bul, üzerine tıkla, puanı artır; beş puanda oyunu bitir” ise uygulanabilir bir yol tarif eder.

Algoritmik düşünme; problemi küçük parçalara ayırmayı, tekrarları fark etmeyi, koşullara göre karar vermeyi ve çözümü sınamayı içerir. Scratch, bu soyut kavramlara görülebilen sonuçlar kazandırır. Yanlış sıraya yerleştirilen bir blok, karakterin beklenmedik davranışıyla hemen kendini belli eder.

Bu eşleştirmeler, çocuğun yeni kavramı bildiği bir deneyime bağlamasını sağlar. Bilgisayarın “niyetimizi” değil, verdiğimiz talimatları uyguladığını anlamak da önemli bir keşiftir.

Görsel araçlar neyi kolaylaştırır?

Blokların şekilleri, hangi parçaların birleşebileceğini gösterir. Böylece birçok sözdizimi hatası daha oluşmadan engellenir. Çocuk, parantez aramak yerine “Bu koşul neden gerçekleşmedi?” sorusuna odaklanabilir.

Yine de görsellik, programın mutlaka doğru olduğu anlamına gelmez. Yanlış koşullar, sonsuz döngüler ve hatalı değişken güncellemeleri bloklarla da mümkündür. Bu nedenle araç, düşünmenin yerine geçmez; düşünmeyi görünür hale getirir.

Seçim yaparken yalnızca yaşa değil; okuma becerisine, ilgi alanına ve kullanılacak cihazlara da bakmak gerekir.

Mini proje: Beş yıldızı yakala!

Scratch’te bir yıldız kuklası ve puan değişkeni oluşturalım. Oyuncu yıldızın üzerine tıkladıkça puan kazansın; yıldız başka bir konuma taşınsın. Beş puana ulaşınca oyun sona ersin.

Aşağıdaki örnek, Scratch bloklarının akışını anlatan sözde koddur; metin olarak doğrudan çalıştırılmaz. Yıldız kuklasının betiği şöyle kurulabilir:

Yeşil bayrak tıklandığında:
    puanı 0 yap
    puan = 5 olana kadar tekrarla:
        x: rastgele(-200, 200)
        y: rastgele(-140, 140) konumuna git
        fare basılı VE fare imlecine değiyor olana kadar bekle
        puanı 1 artır
        fare basılı değil olana kadar bekle
    "Tebrikler, kazandın!" de

Burada başlangıç olayı, değişken, döngü ve birleşik koşul aynı projede buluşur. Fare düğmesinin bırakılmasını beklemek özellikle önemlidir: Tek bir uzun basışın birden fazla tıklama gibi değerlendirilmesini önler.

Puan güncellemesini matematikle de ifade edebiliriz:

Başlangıçta $P=0$ olduğunda, beş başarılı yakalamadan sonra $P=5$ olur. Böylece çocuk, değişkenin yalnızca bir kutu olmadığını; programın ilerleyişini temsil eden bir durum bilgisi olduğunu görür.

Öğretirken cevaptan çok soruya odaklanın

Önce çocuktan akışı kâğıda çizmesini isteyin. Ardından “Hangi adımlar tekrar ediyor?”, “Oyunu bitiren koşul hangisi?” ve “Puanı sıfırlamazsak ne olur?” sorularıyla tasarımını açıklamasına yardımcı olun. Blokları yetişkinin yerleştirmesi yerine, çocuğun karar vermesine alan açın.

Test aşamasında yalnızca başarılı tıklamaları denemeyin. Boş alana tıklamak, fareyi basılı tutmak ve oyunu yeniden başlatmak da değerlidir. Hata bulmak başarısızlık değil, algoritmanın eksik varsayımlarını keşfetmektir. Küçük değişiklikler yapıp sonucu gözlemlemek, rastgele blok değiştirmekten daha öğreticidir.

Metin tabanlı kodlamaya köprü

Bloklarla öğrenilen koşullar, döngüler ve değişkenler Python veya JavaScript’te de bulunur; değişen şey çoğunlukla ifade biçimidir. Bununla birlikte, aktarım kendiliğinden gerçekleşmeyebilir. Aynı algoritmanın iki ortamda karşılaştırılması, kavramların yeni sözdizimiyle ilişkilendirilmesini kolaylaştırır.

Son hedef, mümkün olduğunca erken metin yazdırmak değildir. Çocuğun çözümünü açıklayabilmesi, hatasını araştırabilmesi ve farklı bir probleme uyarlayabilmesidir. Dans eden kedi eğlenceli başlangıçtır; asıl başarı, onun neden dans ettiğini anlatabilen küçük programcıdır.

``

Dijital ikiz, süslü bir şema değildir

Tedarik ağını bir yönlü çizge olarak düşünebiliriz: düğümler tedarikçileri, depoları ve müşterileri; kenarlar malzeme akışlarını temsil eder. Her bağlantının kapasitesi, taşıma süresi ve maliyeti vardır. Stoklar, siparişler ve teslimatlar ise zamanla değişen durum değişkenleridir.

Klasik simülasyon belirli varsayımlarla çalışır. Dijital ikiz, gerçek sistemden gelen verilerle güncellenerek bu varsayımları mevcut operasyonla ilişkilendirir. Yani yalnızca harita değil, hareket eden bir haritadır.

Depodaki akışın temel denklemi şöyledir:

Burada $I_t$ stok, $A_t$ gelen ürün, $X_t$ karşılanan taleptir. Bekleyen siparişleri $B_t$, yeni talebi $D_t$ ile gösterirsek, teslimat miktarı $X_t=\min(I_t+A_t,B_t+D_t)$ olur. Böylece ürün yokken hayali teslimat yapmayız!

Önce veriyi, sonra felaketi hazırlayın

ERP sisteminden stokları ve açık siparişleri; depo sisteminden kabul hareketlerini; taşıma sisteminden teslimat sürelerini alın. Ürün kodlarını, zaman damgalarını ve ölçü birimlerini eşleştirin. Koli ile adedi karıştıran bir ikiz, gerçeğin değil yanlış hesabın kopyasıdır.

Sonrasında normal koşullardaki çıktıları geçmiş operasyonlarla karşılaştırın. Model gerçek teslimat performansını açıklayamıyorsa, kriz tahminlerine güvenmek için henüz erkendir.

Python ile küçük bir kriz laboratuvarı

Aşağıdaki örnekte iki tedarikçi, bir depo ve müşteri talebi bulunuyor. Günlük adımlarla çalışan model, on günlük kesintiyi ve alternatif tedarikçi kapasitesini karşılaştırıyor.

from collections import defaultdict
from random import Random


def simulate(crisis=False, backup=25):
    rng = Random(42)
    arrivals = defaultdict(int)
    stock, backlog = 240, 0
    total_demand, total_served = 0, 0

    for day in range(30):
        stock += arrivals.pop(day, 0)
        demand = max(0, round(rng.gauss(80, 5)))
        served = min(stock, backlog + demand)
        stock -= served
        backlog += demand - served
        total_demand += demand
        total_served += served

        capacity_a = 0 if crisis and 8 <= day < 18 else 70
        # Stok ve yoldaki ürünleri hedefe tamamla.
        needed = max(
            0, 240 + backlog - stock - sum(arrivals.values())
        )
        for capacity, lead_time in [(capacity_a, 2), (backup, 5)]:
            order = min(needed, capacity)
            arrivals[day + lead_time] += order
            needed -= order

    return {
        "fill_rate": round(total_served / total_demand, 3),
        "ending_backlog": backlog,
    }


print("Normal:", simulate())
print("Kesinti:", simulate(crisis=True))
print("Alternatif:", simulate(crisis=True, backup=60))

arrivals, gelecekte ulaşacak sevkiyatları tutar; siparişler anında ışınlanmaz. backlog, karşılanamayan talebi sonraki güne taşır. Aynı rastgele tohum, üç çalıştırmada aynı talep dizisini üretir: böylece farkları talep şansından değil, senaryodan kaynaklanan etkiler üzerinden karşılaştırabiliriz. Alternatif kapasite, bu örnekte bütün dönem boyunca kullanılabilir.

Hangi senaryoları karşılaştırmalı?

Kod ilk üç senaryoyu çalıştırır; talep şoku için talep parametresini değiştirebilirsiniz. Buradaki fill_rate, dönem içindeki toplam teslimatın toplam talebe oranıdır; zamanında teslimat oranı değildir. Ayrıca maliyet hesaplanmadığından, yüksek kapasitenin ekonomik olarak en iyi seçenek olduğu söylenemez.

Güvenilir karar için sınırlarınızı bilin

Tek koşu yerine çok sayıda tohumla deney yapın; her tohumda politikaları aynı talep dizisiyle karşılaştırın. Ortalama sonuçla birlikte kötü durum yüzdeliklerini de raporlayın. Taşıma gecikmeleri, ortak tedarikçi bağımlılıkları ve kapasite sözleşmeleri sonuçları değiştirebilir.

Bu kod, veri bağlantısı olmayan basitleştirilmiş bir senaryo simülatörüdür. Gerçek dijital ikize dönüşmesi için operasyonel verilerle beslenmesi, doğrulanması ve güncel tutulması gerekir. İyi bir ikiz kahin değildir: kriz toplantısına sezgilerin yanında ölçülebilir kanıt getirir.

Bir molekülün içinde yürümek, elektrik alanını görünür çizgilerle incelemek veya bir kuvvetin cismi nasıl hızlandırdığını bizzat denemek… Sanal gerçeklik, ders kitabındaki soyut kavramları etkileşimli deneylere dönüştürebilir. Ancak etkili eğitim, öğrenciye yalnızca gözlük taktırmak değildir; doğru soruları, anlaşılır modelleri ve anlamlı geri bildirimleri aynı ortamda buluşturmaktır. Kısacası hedef, gösterişli bir dijital lunapark değil, düşünmeyi destekleyen bir laboratuvardır. ``

Deneyim neden öğrenmeyi destekler?

Sanal gerçekliğin temel avantajı, öğrencinin bir sistemi farklı açılardan gözlemleyebilmesi ve değişkenlerine müdahale edebilmesidir. Uzamsal ilişkiler, özellikle anatomi, mekanik ve geometrik dönüşümler gibi konularda önemlidir. Öğrenci yalnızca açıklamayı okumaz; nesneyi döndürür, parçaları karşılaştırır ve yaptığı değişikliğin sonucunu görür.

Bu yaklaşım, deneyimsel öğrenmenin döngüsüyle uyumludur: deneyim yaşa, gözlemini değerlendir, bir açıklama oluştur ve açıklamanı yeni deneyle sınayarak geliştir. Örneğin öğrenci önce ağır cismin daha yavaş hızlanacağını tahmin eder, ardından aynı kuvveti farklı kütlelere uygular. Öğretmenin görevi, deneyimin hangi kavramı gösterdiğini görünür kılmaktır.

Yine de sürükleyicilik, otomatik olarak öğrenme anlamına gelmez. Gereksiz animasyonlar, karmaşık menüler ve sürekli bildirimler bilişsel yükü artırabilir. Tasarımda temel soru şudur: Bu unsur kavramı açıklıyor mu, yoksa yalnızca dikkat mi çekiyor?

Bir fizik kavramını yaşanabilir hâle getirmek

Newton’un ikinci yasasını ele alalım:

Burada $F$ net kuvveti, $m$ kütleyi, $a$ ise ivmeyi ifade eder. Sanal laboratuvarda öğrenci kuvveti sabit tutup kütleyi artırdığında ivmenin azaldığını gözlemleyebilir. Böylece formül, rastgele harflerden oluşan bir şifre olmaktan çıkar.

Deneyi önce sadeleştirmek yararlıdır: yerçekimi, sürtünme ve çarpışmalar devre dışı bırakılır. Sabit kuvvet altında hız değişimi de şu ilişkiyle tahmin edilir:

Bu sadeleştirmelerin öğrenciye açıkça belirtilmesi gerekir. Aksi hâlde simülasyonun kuralları, gerçek dünyanın eksiksiz kuralları sanılabilir. Temel ilişki anlaşıldıktan sonra sürtünme eklenerek modelin kapsamı genişletilebilir.

Hangi araç, hangi öğrenme amacı?

Bu seçenekler rakip olmak zorunda değildir. Kısa bir açıklama, masaüstü alıştırma ve VR deneyi aynı öğrenme akışında birbirini tamamlayabilir. Özellikle üç boyutlu inceleme gerekmiyorsa, daha basit bir araç daha iyi seçim olabilir.

Unity ile kontrollü bir deney kurmak

Aşağıdaki Unity 6 örneği, bir cisme sürekli yatay kuvvet uygular. Öğrenci arayüzdeki kaydırıcılarla kuvveti ve kütleyi değiştirir; sıfırlama düğmesi deneyi başlangıç durumuna döndürür.

using UnityEngine;

[RequireComponent(typeof(Rigidbody))]
public class ForceExperiment : MonoBehaviour
{
    private Rigidbody body;
    private Vector3 origin;
    private float forceN;

    void Awake()
    {
        body = GetComponent<Rigidbody>();
        origin = body.position;
        body.useGravity = false;
        body.linearDamping = 0f;
    }

    public void SetForce(float value) =>
        forceN = Mathf.Clamp(value, 0f, 20f);

    public void SetMass(float value) =>
        body.mass = Mathf.Clamp(value, 0.2f, 10f);

    void FixedUpdate() =>
        body.AddForce(Vector3.right * forceN, ForceMode.Force);

    public void ResetTrial()
    {
        forceN = 0f;
        body.position = origin;
        body.linearVelocity = Vector3.zero;
        body.angularVelocity = Vector3.zero;
    }
}

FixedUpdate, kuvvet uygulamasını fizik güncellemeleriyle eşleştirir. ForceMode.Force, kütleyi hesaba katar; sınırlandırılmış değerler ise kontrolsüz denemeleri azaltır. XR Interaction Toolkit ile hazırlanmış etkileşimli arayüz, bu metotlara bağlanabilir. Çarpışmasız bir deney alanı kullanın; ölçümleri aynı süre boyunca alarak karşılaştırın.

Başarıyı gözlüğün içinde değil, öğrenmede ölçün

Öğrenciden deney öncesinde tahmin, sonrasında gerekçe isteyin. Ardından farklı kütle ve kuvvet değerleriyle yeni bir problem verin. Başarı ölçütü, nesneyi hareket ettirmek değil; ilişkiyi açıklamak ve yeni duruma aktarabilmektir. Deneyden hemen sonraki başarıyı, daha sonraki bir hatırlama göreviyle tamamlamak da yararlıdır.

Konfor için kısa oturumlar, mola seçenekleri ve ani kamera hareketlerinden kaçınma önemlidir. VR kullanamayan öğrenciler için masaüstü alternatif sunun. Hareket ve performans kayıtlarında yalnızca gerekli verileri toplayın.

En iyi sürükleyici eğitim ortamı, öğrenciyi etkileyen değil, ona açıklama kurduran ortamdır. Gözlük çıkarıldığında geriye yalnızca “çok havalıydı” değil, “neden böyle olduğunu artık biliyorum” kalmalıdır.

``

Temel fikir: Son teslimatı önce yükle

Kamyonun yalnızca arka kapısından boşaltıldığını, paletlerin tek sıra halinde durduğunu ve üst üste konmadığını düşünelim. Rota $A \rightarrow B \rightarrow C$ ise doğal yükleme sırası $C \rightarrow B \rightarrow A$ olur. Böylece ilk müşterinin paleti kapıya en yakın konumda bulunur.

Bu düzen, yazılımdaki LIFO, yani son giren ilk çıkar mantığına benzer. Ancak yan kapılar, farklı boyutlar, kırılgan ürünler ve aks yükleri devreye girdiğinde ters sıralama tek başına yeterli değildir. Artık yalnızca liste çevirmiyoruz; kısıtlar altında çözüm arıyoruz.

Problemi matematiksel olarak kurmak

Her palet için teslimat sırasını $d_i$, ağırlığı $w_i$, yerleşim konumunu $p_i$ ile gösterelim. Eş boyutlu paletlerde konumlar $0,\ldots,n-1$ olsun; sıfır kamyonun en derin noktasını, son konum arka kapıyı temsil etsin.

Erişilebilirlik kuralımız:

Yani daha geç teslim edilecek palet daha içeride bulunmalıdır. Ayrıca her palet farklı bir konuma atanır ve toplam ağırlık kapasiteyi aşmaz:

Aynı müşteriye giden paletler arasında ise serbestlik vardır. Optimizasyon bu serbestliği kullanarak ağırlık dağılımını iyileştirebilir. Basitleştirilmiş hedefimiz, yükün ağırlık merkezini kasanın geometrik merkezine yaklaştırmaktır:

Buradaki $2p_i+1$, palet merkezinin ikiyle ölçeklenmiş koordinatıdır. Böylece kesirli konumlar yerine tamsayılarla çalışabiliriz. Gerçek araçta ideal merkez, aks konumları ve izin verilen aks yüklerine göre belirlenmelidir.

Python ile küçük bir optimizasyon modeli

Aşağıdaki örnek, OR-Tools CP-SAT kullanır. Kurulum için pip install ortools yeterlidir. Beş eş boy paletimiz vardır; teslimat numarası büyüdükçe müşteri rotada daha sonra ziyaret edilir. Toplam ağırlığın araç kapasitesine uygun olduğu önceden kontrol edilmiş kabul edilir.

from ortools.sat.python import cp_model

# Kimlik, teslimat sırası, ağırlık (kg)
pallets = [('C1', 3, 120), ('C2', 3, 80),
           ('B1', 2, 100), ('A1', 1, 110), ('A2', 1, 90)]
n = len(pallets)
W = sum(item[2] for item in pallets)
model = cp_model.CpModel()
p = [model.new_int_var(0, n - 1, f'p{i}') for i in range(n)]
model.add_all_different(p)

for i in range(n):
    for j in range(n):
        if pallets[i][1] > pallets[j][1]:
            model.add(p[i] < p[j])

moment = sum(pallets[i][2] * (2 * p[i] + 1) for i in range(n))
error = model.new_int_var(0, W * (2 * n - 1), 'sapma')
model.add_abs_equality(error, moment - n * W)
model.minimize(error)

solver = cp_model.CpSolver()
solver.parameters.max_time_in_seconds = 5
status = solver.solve(model)
if status in (cp_model.OPTIMAL, cp_model.FEASIBLE):
    order = sorted(range(n), key=lambda i: solver.value(p[i]))
    print('Yükleme:', [pallets[i][0] for i in order])
    print('Durum:', solver.status_name(status))

Kod, önce paletlere benzersiz konumlar atar. Ardından teslimat önceliklerini zorunlu kılar ve merkez sapmasını küçültür. Çıktı, derinden kapıya doğru yerleşimi gösterir; bu basitleştirilmiş düzende aynı sıra yükleme sırasıdır. FEASIBLE, uygulanabilir çözüm bulunduğunu; OPTIMAL, en iyi çözümün kanıtlandığını belirtir. Süre sınırı, optimum garantisi değildir.

Gerçek depoya geçerken

Modelimiz erişilebilirliği kesin kısıt olarak ele aldığı için yeniden elleçlemeye izin vermez. Gerçekte bazı durumlarda bir paleti geçici olarak indirmek kabul edilebilir; bunun işçilik ve gecikme maliyeti amaç fonksiyonuna eklenebilir.

Üretim ortamında ayrıca şu ayrıntılar gerekir:

• Geometri: Palet boyutları, yönleri ve kapı açıklığı kontrol edilmelidir.
• Güvenlik: Aks yükleri, yük sabitleme ve istif dayanımı zorunlu kısıtlardır.
• Operasyon: Forklift erişimi ve depo hazırlama sırası hesaba katılmalıdır.

Sonuç olarak sabit rota ve basit erişim koşullarında ters sıralama iyi bir başlangıçtır. Kombinatorik optimizasyonun asıl değeri, birden fazla uygulanabilir yerleşim arasından operasyonel açıdan daha iyi olanı seçmesidir. Hedef yalnızca kamyonu doldurmak değil, her durakta doğru yükü güvenle ve zahmetsizce indirebilmektir.

``

RAM neden güçlü bir delil kaynağıdır?

İşletim sistemi, süreçlerin kodunu ve verilerini sanal adres alanlarında tutar. Sayfa tabloları, bu sanal adreslerin fiziksel bellekteki karşılıklarını belirler. Analiz araçları yalnızca okunabilir metin aramaz; işletim sisteminin veri yapılarını yorumlayarak süreçleri, bellek bölgelerini ve diğer nesneleri yeniden oluşturur.

Bu ayrım önemlidir: Diskte bulunmayan bir zararlı bile çalışan kodunu bellekte tutmak zorundadır. Ancak bellek imajı her şeyi kapsamayabilir. Diske taşınmış sayfalar, eksik yakalama veya korumalı bölgeler görünürlüğü azaltabilir.

Bazı rootkit’ler süreç kayıtlarını işletim sisteminin normal listelerinden çıkarır. Bu yaklaşım, DKOM, yani çekirdek nesnelerinin doğrudan değiştirilmesi olarak bilinir. Dolayısıyla tek bir süreç listesine güvenmek, saklambaç oyununda yalnızca kapının arkasına bakmaya benzer.

Önce fotoğrafı çek, sonra incele

İlk hedef, yetkili olduğunuz sistemden güvenilir bir bellek imajı almaktır. Windows ortamında WinPmem, Linux tarafında uygun çekirdek desteğiyle LiME kullanılabilir. Araç seçimi; işletim sistemi sürümüne, güvenlik özelliklerine ve kurumun prosedürlerine bağlıdır.

Mümkünse sistemi kapatmadan yakalama yapın; kapanış uçucu verileri kaybettirir. Bununla birlikte, yakalama aracı da RAM’i değiştirir. Bu nedenle kullanılan araç, sürüm, zaman ve yapılan işlemler kaydedilmelidir. Bellek toplama, tamamen iz bırakmayan bir işlem değildir.

İmajın SHA-256 özetini alın, özgün dosyayı koruyun ve çalışma kopyasını inceleyin. Hash, dosyanın sonradan değişip değişmediğini denetler; yakalamanın eksiksiz olduğunu kanıtlamaz. RAM parola ve kişisel veri içerebildiğinden erişimi sınırlandırın.

Volatility 3 ile ilk tarama

Volatility 3, bellek imajından işletim sistemi yapılarını çıkaran bir analiz çatısıdır. Aşağıdaki Bash betiği, araç deposundaki vol.py dosyasının bulunduğu dizinde çalıştırılır. İlk argüman çalışma kopyasının yoludur; raporlar ayrı dosyalara yazılır.

#!/usr/bin/env bash
set -euo pipefail
image="${1:?Kullanım: bash incele.sh bellek.raw}"
out="rapor-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$out"
sha256sum "$image" > "$out/imaj.sha256"
plugins=(windows.info windows.pslist windows.psscan
         windows.pstree windows.cmdline windows.netscan)
for plugin in "${plugins[@]}"; do
  python3 vol.py -f "$image" "$plugin" \
    > "$out/${plugin}.txt"
done

windows.info, imajın yorumlanmasına ilişkin temel bilgileri verir. pslist normal süreç listesini, psscan ise bellekteki süreç nesnelerini tarar. pstree ebeveyn ilişkilerini, cmdline komut satırlarını, netscan ağ nesnelerini gösterir. Betik hata durumunda durur; başarısız eklentinin çıktısını tamamlanmış rapor sanmayın.

Eklenti desteği, semboller ve imaj uyumluluğu sonucu etkiler. Kullanılabilir seçenekleri python3 vol.py -h ile kontrol edin. Boş çıktı her zaman “tehdit yok” anlamına gelmez.

Gizlenmeyi çapraz bulgularla yakalamak

Asıl güç, farklı kaynakları karşılaştırmaktır. Tek bir anormallik alarm zili olabilir; mahkeme kararı değildir.

Kod enjeksiyonunda saldırgan, başka bir sürecin adres alanına kod yerleştirebilir. Malfind türü eklentiler şüpheli yürütülebilir bölgeleri işaretlemeye yardımcı olur; kesin zararlı sınıflandırması yapmaz. Ayrıca her enjeksiyon yazılabilir-yürütülebilir sayfa bırakmaz.

Örneğin bir tarayıcıdaki yürütülebilir özel bellek bölgesi tek başına şaşırtıcı değildir. Aynı bölgede şüpheli kod, beklenmedik komut satırı ve açıklanamayan bağlantı birlikte görülüyorsa inceleme önceliği yükselir.

Bulgudan sonuca: Kanıt zincirini kurmak

Örnek bir önceliklendirme puanı şöyle tanımlanabilir:

Burada $H$ süreç listesi tutarsızlığını, $I$ enjeksiyon belirtisini, $N$ şüpheli ağ etkinliğini, $P$ beklenmedik ebeveyn ilişkisini temsil eden ikili göstergelerdir. Ağırlıklar tamamen örnektir; bu puan bir olasılık hesabı veya doğrulanmış tespit modeli değildir.

Yüksek puanlı süreçlerde ilgili bellek bölgelerini dışa aktarın; dizgiler, kod yapısı ve bilinen göstergeler üzerinden inceleyin. Ardından bulguları disk dosyaları, olay günlükleri ve ağ kayıtlarıyla ilişkilendirin.

Raporda PID’leri, zamanları, kullanılan komutları, dosya özetlerini ve alternatif açıklamaları belirtin. Bellek adli analizinin başarısı, “gizli zararlıyı buldum!” demekten çok, başka bir analistin aynı kanıtlarla aynı sonuca ulaşabilmesidir.

``

Frekans neden değişir?

Türkiye gibi 50 Hz kullanan senkron şebekelerde frekans, üretim ve tüketim dengesinin önemli bir göstergesidir. Tüketim üretimi aşarsa senkron makinelerin dönme enerjisi azalır ve frekans düşer. Üretim fazlaysa tersi gerçekleşir. Ancak frekansın normal görünmesi, her hattın güvenli yükte olduğu anlamına gelmez; bölgesel darboğazlar ayrıca izlenmelidir.

Basitleştirilmiş toplu sistem modeli şöyledir:

Burada $H$ eşdeğer atalet sabiti, $f_0$ nominal frekans, $\Delta p_g$ üretim değişimi ve $\Delta p_l$ tüketim değişimidir. Güçler ortak bir bazda birim değer olarak ifade edilir; $D$, frekansa bağlı yük tepkisini temsil eder.

Bu denklem kritik bir gerçeği anlatır: Yazılım enerji yaratmaz. Ölçümden hareketle santralleri, bataryaları veya esnek yükleri yönlendirir. İlk anda fiziksel atalet zaman kazandırır; kontrol algoritmaları bu zamanı değerlendirmek zorundadır.

Tek kontrolör değil, katmanlı savunma

Şebeke dengelemesini, taşan lavaboya verilen tepkiler gibi düşünün: önce akışı yavaşlatırsınız, sonra seviyeyi düzeltirsiniz, ardından tesisatın çalışma planını değiştirirsiniz.

Bu süreler sistem tasarımına göre değişir. Birincil kontrolde yaygın yaklaşım droop, yani frekans düştükçe güç artırma davranışıdır:

Birincil kontrol genellikle frekansı tam hedefe getirmez. İkincil kontrol, kalıcı hatayı gidermek için integral etkisinden yararlanır. Birden fazla kontrol bölgesinde yalnızca frekansa bakılmaz; planlanan ve gerçekleşen bağlantı hattı alışverişleri de hesaba katılır. Bu birleşik göstergeye alan kontrol hatası, yani ACE denir.

Python ile sınırlı bir PI kontrolör

Aşağıdaki örnek, tek bölgenin frekansını izleyen öğretici bir PI kontrolörüdür. Üretim komutunu hesaplarken güç kapasitesini ve rampa hızını sınırlar. Gerçek bir AGC sisteminin tüm haberleşme, rezerv paylaşımı ve güvenlik işlevlerini içermez.

def komut(frekans, dt, durum, temel=100.0):
    if dt <= 0:
        raise ValueError("dt pozitif olmalı")

    hata = 50.0 - frekans
    ham = temel + 40.0 * hata + durum["integral"]

    # Kapasite: 0–200 MW; rampa: 5 MW/s
    hedef = max(0.0, min(200.0, ham))
    adim = 5.0 * dt
    guc = max(durum["guc"] - adim,
              min(durum["guc"] + adim, hedef))

    # Anti-windup: uygulanamayan komutu geri besle
    durum["integral"] += (
        8.0 * hata + 0.5 * (guc - ham)
    ) * dt
    durum["guc"] = guc
    return guc

 durum = {"integral": 0.0, "guc": 100.0}

Örneği çalıştırırken son satırın başındaki boşluğu kaldırarak başlangıç durumunu tanımlayın; ardından komut(49.90, 1.0, durum) çağrısını yapın. İlk komut 104 MW olur: 0,10 Hz eksik frekans, oransal terim üzerinden 4 MW artış ister.

Oransal kazancın birimi MW/Hz, integral kazancının birimi MW/(Hz·s) olarak düşünülebilir. İntegral terimi geçmiş hatayı biriktirir. Anti-windup, kapasite veya rampa sınırları yüzünden uygulanamayan isteğin integrali aşırı büyütmesini önler. Buradaki kazançlar örnektir; saha ayarı değildir.

Algoritmayı sahaya hazırlamak

İyi bir dengeleme yazılımı yalnızca doğru formülü kullanmaz. Zaman damgalarını doğrular, bozuk ölçümleri ayıklar ve haberleşme gecikmelerini hesaba katar. Gürültüyü filtrelemek yararlıdır; fakat aşırı filtreleme müdahaleyi geciktirir. Hız ile güvenilirlik arasında gerçek bir mühendislik pazarlığı vardır.

Komutlar kaynakların fiziksel sınırlarına uymalıdır. Bataryanın doluluk oranı, türbinin rampa kapasitesi ve kullanılabilir rezerv miktarı sürekli izlenir. Ekonomik optimizasyon daha ucuz kaynakları seçebilir; ancak hat akış limitleri ve güvenlik koşulları maliyetten önce gelir.

Üretime geçmeden önce yük sıçramaları, kaynak kayıpları, ölçüm kesintileri ve gecikmeler simülasyonda denenmelidir. Başarı yalnızca frekansı düzeltmek değildir: bunu salınım üretmeden, rezervleri tüketmeden ve ekipmanı zorlamadan yapmaktır. Şebekenin iyi yazılımı, en gösterişli kod değil, en sakin çalışan koddur.

``

Önce riski ölçülebilir hale getirin

“Tedarikçi riskli mi?” sorusu fazla geniştir. Bunun yerine hedefi şöyle tanımlayabiliriz: Önümüzdeki 90 gün içinde, planlanan teslimatlardan en az biri yedi günden fazla gecikecek mi? Böylece her tedarikçi ve değerlendirme tarihi için bir gözlem oluştururuz.

Bu olay gerçekleşirse etiket $y=1$, gerçekleşmezse $y=0$ olur. Gelecek dönemde teslimatı bulunmayan tedarikçiler bu hedef açısından ayrıca ele alınmalıdır; sipariş verilmemesi, güvenilirlik kanıtı değildir. Kalite problemi veya iflas gibi farklı riskler de farklı etiketlerle modellenmelidir. Tek bir puana her şeyi doldurmak, çorbaya tatlı eklemek gibidir.

Geçmişi özelliklere dönüştürmek

Model, ham sipariş listesinden çok anlamlı özetlerle çalışır. Örneğin son 180 gündeki gecikme oranı, teslimat sürelerinin standart sapması ve kapasite kullanımı davranış örüntülerini görünür kılar.

Temel kural şudur: Tahmin gününde bilinmeyen hiçbir bilgi modele giremez. Gelecekteki gecikmeden sonra güncellenen bir performans puanını kullanmak veri sızıntısıdır. Sonuçlar harika görünür, gerçek hayatta ise modelin sihri kaybolur.

Model aslında ne öğrenir?

Lojistik regresyon, özellikleri ağırlıklı olarak birleştirir: $z=b+\sum_i w_i x_i$. Ardından $p=1/(1+e^{-z})$ dönüşümüyle sıfır ile bir arasında bir skor üretir. Bu skorun amaçlanan yorumu, tanımladığımız olayın gerçekleşme olasılığıdır.

Ağaç tabanlı gradyan artırma modelleri daha karmaşık etkileşimleri yakalayabilir. Örneğin yüksek kapasite kullanımı yalnızca belirli ürün gruplarında güçlü bir uyarı olabilir. Yine de basit, açıklanabilir bir başlangıç modeli karşılaştırma yapmak için değerlidir.

Python ile zaman duyarlı başlangıç

Aşağıdaki örnek, önceden hazırlanmış haftalık özellik tablosunu kullanır. Eksikleri tamamlar, kategorileri kodlar ve geçmiş gözlemlerle lojistik regresyon eğitir.

import pandas as pd
from sklearn.compose import ColumnTransformer
from sklearn.impute import SimpleImputer
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import average_precision_score, recall_score
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import OneHotEncoder, StandardScaler

df = pd.read_csv("tedarikci_haftalik.csv")
df["tarih"] = pd.to_datetime(df["tarih"])
cutoff = pd.Timestamp("2025-01-01")

num = ["gecikme_orani_180g", "teslimat_std_180g", "kapasite_kullanimi"]
cat = ["ulke", "urun_grubu"]
features = num + cat

train = df[df["tarih"] < cutoff - pd.Timedelta(days=90)]
test = df[(df["tarih"] >= cutoff) &
          (df["tarih"] < cutoff + pd.Timedelta(days=90))]

prep = ColumnTransformer([
    ("num", make_pipeline(SimpleImputer(strategy="median"),
                         StandardScaler()), num),
    ("cat", make_pipeline(SimpleImputer(strategy="most_frequent"),
                         OneHotEncoder(handle_unknown="ignore")), cat)
])
model = make_pipeline(prep, LogisticRegression(max_iter=1000))
model.fit(train[features], train["gecikme_90g"])
p = model.predict_proba(test[features])[:, 1]
print("AP:", average_precision_score(test["gecikme_90g"], p))
print("Recall:", recall_score(test["gecikme_90g"], p >= 0.30))

Aradaki 90 günlük boşluk, eğitim etiketlerinin test başlangıcından önce tamamlanmasını sağlar. Test etiketlerinin de değerlendirme anında olgunlaşmış olması gerekir. Ön işleme yalnızca eğitim verisinde öğrenilir. Buradaki 0,30 eşiği örnektir; gerçek eşik ayrı, zaman sıralı doğrulama döneminde seçilmelidir.

Başarı, doğruluktan fazlasıdır

Riskli olaylar nadirse her tedarikçiye “sorunsuz” diyen model yüksek doğruluk gösterebilir. Bu yüzden ortalama kesinlik (AP), kesinlik ve duyarlılık birlikte incelenmelidir. Duyarlılık, gerçek risklerin ne kadarını yakaladığımızı; kesinlik, uyarıların ne kadarının isabetli olduğunu gösterir.

Olasılık kalibrasyonu da önemlidir: Yüzde 30 risk verilen gözlemlerin yaklaşık yüzde 30’unda olay gerçekleşmelidir. Basitleştirilmiş hata maliyetleriyle karar eşiği $t=C_{FP}/(C_{FP}+C_{FN})$ olabilir. Yanlış alarm maliyeti $C_{FP}$, kaçırılan risk maliyeti $C_{FN}$ büyüdükçe farklı kararlar doğurur. Bu hesap kalibre edilmiş olasılık gerektirir.

Tahmini operasyona bağlamak

Yüksek risk puanı otomatik tedarikçi eleme kararı olmamalıdır. Uyarı; ek denetim, güvenlik stoğu veya alternatif kaynak araştırmasını tetikleyebilir. Açıklamalar nedensellik kanıtı değildir; ülke gibi değişkenlerin haksız genellemelere dönüşmesi denetlenmelidir.

Son olarak veri kaymasını, uyarı isabetini ve gerçekleşen kayıpları düzenli izleyin. Modelin görevi geleceği kesin bilmek değil, satın alma ekibine daha erken ve daha ölçülü hareket etme fırsatı vermektir.

Yüzyıllar önce yıkılmış bir sarayın kapısından geçtiğinizi düşünün. Tavandaki bezemelere bakıyor, avludaki çeşmenin sesini duyuyorsunuz. Üstelik ortada gerçek bir saray yok! Sanal gerçeklik, kayıp tarihi yapıları dijital ortamda yeniden kurarak ziyaretçiyi pasif izleyiciden mekânın içinde dolaşan bir araştırmacıya dönüştürüyor. Peki bu zaman makinesinin kaputunun altında neler var?

``

Yeniden inşa mı, tarihsel tahmin mi?

Dijital rekonstrüksiyon, eski bir binanın güzel görünen kopyasını üretmekten fazlasıdır. Amaç, arkeolojik bulgular ve tarihsel belgeler üzerinden savunulabilir bir mekân modeli oluşturmaktır. Eski planlar, gravürler, fotoğraflar ve kazı raporları aynı bulmacanın farklı parçalarıdır.

Buradaki temel ayrım, kanıt ile yorum arasındadır. Bir duvarın konumu temelden biliniyor olabilir; çatının biçimi ise benzer dönem yapılarından çıkarılabilir. İkisini aynı kesinlikle sunmak, ziyaretçiye yanlış bir tarih anlatır. Bu nedenle modelin hangi bölümlerinin belgeli, hangilerinin varsayımsal olduğu açıkça gösterilmelidir.

Arşivden üç boyutlu dünyaya

Üretim hattını dört adımda düşünebiliriz:

1. Veriyi toplayın: Belgelerin tarihini, kaynağını ve ölçeğini kaydedin. Farklı dönemlere ait planları yanlışlıkla birleştirmeyin.
2. Geometriyi oluşturun: Mevcut kalıntıları fotogrametri veya lazer taramayla ölçün. Fotogrametri, örtüşen fotoğraflardaki ortak noktalar üzerinden yüzey geometrisini hesaplar; kayıp bölümleri tek başına geri getiremez.
3. Eksikleri yorumlayın: Blender gibi araçlarda duvarları, çatıyı ve bezemeleri modelleyin. Arkeolog ve mimarlık tarihçisiyle alternatifleri değerlendirin.
4. Deneyime aktarın: Modeli glTF gibi bir biçimde dışa aktararak Unity, Unreal Engine veya WebXR tabanlı bir uygulamada kullanın.

Modeli tek bir dosya olarak değil, kaynaklarla bağlantılı parçalardan oluşan bir veri kümesi olarak saklamak sonraki düzeltmeleri kolaylaştırır.

Gerçekçi görünmek yetmez, akıcı çalışmalı

VR başlığı, baş hareketlerine gecikmeden tepki vermelidir. Hedef yenileme hızı $f$ ise yaklaşık kare süresi bütçesi şöyle hesaplanır:

Örneğin $90$ Hz için yaklaşık $11{,}1$ milisaniye vardır. Bu bütçeye sahne çizimi ve uygulama işlemleri sığmalıdır. Çok ayrıntılı taş süslemeler bu nedenle yakında yüksek, uzakta düşük ayrıntıyla gösterilebilir. Buna LOD denir. Önceden hesaplanmış aydınlatma ve sıkıştırılmış dokular da performansa yardım eder. Ölçüm yapmadan optimizasyon ise biraz gözler kapalı restorasyona benzer!

WebXR ile küçük bir prototip

Aşağıdaki örnek, Three.js kullanarak tarihi yapı modelini yükler ve desteklenen cihazlarda VR oturumunu başlatan düğmeyi ekler. Kod, three paketinin kurulu olduğu Vite benzeri bir projede çalıştırılabilir. Modelin metre ölçeğinde ve başlangıç noktasının ziyaret edilebilir bir alanda olması beklenir.

import * as THREE from 'three';
import { VRButton } from 'three/addons/webxr/VRButton.js';
import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';

const scene = new THREE.Scene();
scene.background = new THREE.Color(0xdce5ed);
const camera = new THREE.PerspectiveCamera(
  70, innerWidth / innerHeight, 0.1, 500
);
camera.position.set(0, 1.6, 0);

const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(innerWidth, innerHeight);
renderer.xr.enabled = true;
document.body.appendChild(renderer.domElement);
document.body.appendChild(VRButton.createButton(renderer));

scene.add(new THREE.HemisphereLight(0xffffff, 0x665544, 2));
const loader = new GLTFLoader();
loader.load('/models/kayip-yapi.glb', ({ scene: model }) => {
  scene.add(model);
}, undefined, console.error);

renderer.setAnimationLoop(() => {
  renderer.render(scene, camera);
});

GLTFLoader geometriyi ve malzemeleri getirir; setAnimationLoop çizimi WebXR oturumuyla uyumlu yürütür. Bu, tamamlanmış bir müze uygulaması değil, başlangıç iskeletidir. Yürüme, ışınlanma, çarpışma denetimi ve bilgi panoları ayrıca geliştirilmelidir. WebXR için HTTPS veya yerel geliştirmede localhost gerekir; cihaz ve tarayıcı desteği de kontrol edilmelidir.

Ziyaretçiye yalnızca duvar göstermeyin

İyi deneyim, mimariyi günlük yaşamla ilişkilendirir: Bu avluyu kim kullanıyordu? Bu kapı neden dardı? Mekânsal ses ve kısa anlatılar, ayrıntıların anlamını görünür kılar.

Belirsiz bölümler açılıp kapatılabilen renk katmanlarıyla gösterilebilir. Böylece ziyaretçi hem yapıyı gezer hem de araştırmanın nasıl ilerlediğini görür. Renkler, açıklama metinleriyle desteklenmelidir; herkes renkleri aynı biçimde ayırt etmez.

Konfor için ışınlanarak hareket, oturarak kullanım ve kısa oturum seçenekleri sunun. Başlığa erişemeyenler için ekran üzerinden gezinme de sağlayın. Başarı, yalnızca etkileyici grafikler değildir: Ziyaretçinin tarihsel bilgiyi doğru anlaması, rahat hissetmesi ve merakla yeni sorular sormasıdır.