Ekim 3 2026

AI Kodlama Maliyetini Düşürme: Token Kullanımını Optimize Etme Rehberi

Yazılımcılar olarak son bir yıldır yeni bir refleks edindik: Bir fonksiyon yazarken takıldığımızda ya da sıkıcı bir CRUD operasyonu kapıya dayandığında hemen kısayol tuşuna basıp yapay zekayı yardıma çağırıyoruz. Fakat ay sonu kredi kartı ekstresinde ya da ekip dashboard’unda beliren o sürpriz bulut maliyetleri, keyfimizi bir anda kaçırabiliyor. AI kodlama yaparken çoğumuz ne kadar devasa bir veri hacmini her seferinde modele yolladığımızı fark etmiyoruz. İşte bu yazıda, geliştirme hızımızı zerre düşürmeden token optimizasyonu yapmanın ve cüzdanı rahatlatmanın denenmiş yollarını masaya yatırıyoruz.

Token Mantığı: Bu Sayaç Neden Bu Kadar Hızlı Dönüyor?

Bilmeyenler veya “token tam olarak neydi ya?” diyenler için en basit tanımı yapalım: Büyük dil modelleri (LLM) kelimeleri bizim gibi harf harf değil, “token” adını verdikleri hece veya karakter öbekleri halinde okur. Ortalama olarak 1000 token, yaklaşık 750 İngilizce kelimeye (Türkçe’de ek yapısından ötürü biraz daha azına) denk gelir.

Asıl tuzak şu: Bir sohbet uzadıkça, Claude veya GPT her yeni cümlenizde geçmiş konuşmaların tamamını tekrar okur. Yani model hafızaya sahip değildir; hafıza yanılsaması, geçmişin her istekte (request) baştan sona yeniden gönderilmesiyle (Context Window) sağlanır. Projenin 500 satırlık bir dosyasını AI’a verip 10 soru sorduğunuzda, o 500 satırı modele 10 defa baştan okutmuş ve parasını 10 defa ödemiş olursunuz.

[Görsel: Cursor veya VS Code arayüzünde context token sayacının soru sordukça katlanarak arttığını gösteren panel ekranı]

Context Penceresi Tuzağı ve .cursorignore Kurtarıcısı

Cursor, Windsurf ya da Copilot Workspace gibi modern AI kodlama araçları projenizi “indeksler”. Siz bir soru sorduğunuzda arkada akıllı bir vektör araması yapar ve alakalı gördüğü dosyaları context’e (bağlama) ekler. Harika bir özellik, değil mi? Teoride evet, pratikte ise tam bir bütçe canavarı.

Çünkü araç çoğu zaman test log’larını, build çıktılarını, package-lock.json gibi binlerce satırlık dosyaları da bağlama dahil eder. Bunu engellemenin en temiz yolu, projenizin kök dizinine bir .cursorignore (veya kullandığınız araca özel yoksayma dosyası) eklemektir:

# Gereksiz dosyaları AI context'inden uzak tutun
dist/
build/
node_modules/
*.log
package-lock.json
pnpm-lock.yaml
coverage/

Sadece şu küçük dosya bile tek bir sorguda bağlama giden token sayısını %40 ila %60 oranında azaltabiliyor. Denediğimiz bir projede, sırf kilitli bağımlılık dosyalarının context dışı bırakılmasıyla 200k context limitine dayanan sorguların 30k seviyesine gerilediğini bizzat ölçtük.

Prompt Engineering ile Akıllı Token Diyeti

Yapay zekaya soru sorarken edebiyat yapmayı bırakmamız gerekiyor. Doğru prompt engineering teknikleri yalnızca daha iyi kod üretmekle kalmaz, gidiş-dönüş maliyetini de doğrudan kısar.

1. “Bütün Dosyayı Yeniden Yazma” Kuralı

LLM faturalarında en pahalı kısım girdi (input) değil, çıktı (output) token’larıdır. OpenAI ve Anthropic modellerinde çıktı token’ları genellikle girdiden 3 ila 5 kat daha pahalıdır. Bir fonksiyonda hata ayıklarken modele “Bunu düzelt” derseniz, size 400 satırlık dosyanın tamamını tekrar yazar. Bunun yerine şunu deneyin:

“Sadece değişen fonksiyonu ver, dosyanın tamamını yazdırma.” veya “Yalnızca Git diff formatında göster.”

Bu ufak dokunuş, tek bir yanıtta 2000 output token tasarrufu demektir.

2. Doğrudan Referans Verme (@ Dosya Adı)

Aracın tüm codebase üzerinde körlemesine arama yapmasına izin vermek yerine, ilgili dosyayı doğrudan işaret edin. Cursor veya modern eklentilerde @UserAuth.ts şeklinde hedef göstermek, arka plandaki arama token’larını sıfıra indirir.

[Görsel: İyi optimize edilmiş bir prompt ile savruk bir prompt’un harcadığı token miktarlarını yan yana gösteren karşılaştırma grafiği]

Fiyat Tablosu: Hangi Model Ne Kadar Yakıyor?

Piyasadaki popüler modellerin maliyet profilleri ciddi şekilde farklılaşıyor. 2025 başı itibarıyla kabaca tablo şu şekilde:

Model Girdi (1M Token) Çıktı (1M Token) Öne Çıkan Özellik
Claude 3.5 Sonnet $3.00 $15.00 Kodlamada endüstri standardı, yüksek kavrayış
GPT-4o $2.50 $10.00 Hızlı ve dengeli performans
DeepSeek V3 / R1 ~$0.14 – $0.55 ~$0.28 – $2.19 Fiyat/performans canavarı, açık ağırlıklı
Yerel Model (Llama 3, Ollama) $0.00 $0.00 Kendi donanımınız (Sıfır bulut maliyeti)

Agresif Token Tasarrufunun Artıları ve Eksileri

Her şeyi aşırı kısmak da her zaman en iyi çözüm olmayabilir. Dengeyi iyi kurmak şart.

Avantajlar (Artılar) Dezavantajlar (Eksiler)
Aylık API faturalarında %50’ye varan düşüş Model bazen eksik context nedeniyle “halüsinasyon” görebilir
Daha hızlı yanıt süreleri (Latency düşer) Geliştiricinin prompt yazarken daha dikkatli düşünmesi gerekir
Gürültüden arınmış, net ve nokta atışı yanıtlar Büyük çaplı mimari refactor işlerinde parça parça ilerlemek zorlaşabilir

Cüzdan Dostu Alternatifler: Ne Yapmalı?

Eğer kurumsal bir bütçeniz yoksa ve kendi cebinizden ödüyorsanız izleyebileceğiniz üç somut yol var:

  1. Prompt Caching Kullanın: Anthropic ve OpenAI’ın sunduğu “Prompt Caching” özelliğini destekleyen eklentileri tercih edin. Proje bağlamı önbelleğe alındığında, tekrarlayan girdilerde %90’a varan indirim sağlanıyor.
  2. Continue.dev Eklentisine Geçin: VS Code için tamamen açık kaynaklı ve ücretsiz olan Continue.dev eklentisini kurup, arka plana DeepSeek API’sini bağlayabilirsiniz. Claude kalitesine çok yakın kodlamayı neredeyse onda biri fiyatına getirirsiniz.
  3. Lokal Modellere Şans Verin: Bilgisayarınızda güçlü bir Apple Silicon (M serisi) işlemci veya en az 16GB VRAM’li bir Nvidia kart varsa, Ollama üzerinden Qwen 2.5 Coder çalıştırın. Günlük ufak işler, test yazımları ve regex açıklamaları için buluta tek kuruş ödemenize gerek yok.

Sonuç: Kontrolü Modele Bırakmayın

Yapay zeka araçları inanılmaz bir kaldıraç gücü sunuyor, ancak onları “nasılsa otomatik hallediyor” diyerek tamamen serbest bırakmak ay sonunda tatsız sürprizler doğurabiliyor. Context dosyalarınızı temiz tutmak, gereksiz log ve kütüphaneleri dışlamak ve yanıtları diff formatında istemek gibi basit alışkanlıklar, geliştirme deneyiminizden ödün vermeden faturalarınızı kontrol altında tutmanızı sağlar.

Category: Genel | LEAVE A COMMENT
Ekim 3 2026

LLM Orchestration: LangChain Yerine Neden Haystack veya LlamaIndex Seçmelisiniz?

Kendi yapay zeka uygulamanızı geliştirmeye karar verdiğinizde ilk karşınıza çıkan araç muhtemelen LangChain olur. Günümüzün hızlı tempolu ai development dünyasında, bir llm (büyük dil modeli) ile harikalar yaratmak istiyorsanız bir orkestrasyon aracına ihtiyacınız var. Ancak LangChain tek ve her zaman en iyi seçenek mi? Pratikte işler prototip aşamasından çıkıp gerçek dünyaya adım attığında, tablo epey değişiyor.

Bu yazıda LangChain, Haystack ve LlamaIndex üçlüsünü laboratuvar masasına yatırdım. Sözleri değil, pratikteki davranışları karşılaştırdım. Hangisi hangi senaryoda hayat kurtarır, hangisi saç baş yoldurur? Gelin yakından bakalım.

Önce Temel Soru: “LLM Orchestration” Neden Var?

Bir dil modeline basitçe soru sorup cevap almak için bir framework’e ihtiyacınız yok; basit bir API çağrısı yeterli. Sorun şu: Model şirketinizin iç dokümanlarını bilmiyor, hafızası sınırlı, harici veri tabanlarına bağlanması gerekiyor ve bazen adım adım mantık yürütmek zorunda.

İşte orchestration burada devreye giriyor. Orkestra şefi gibi; veriyi alır, parçalar, vektör veri tabanına gömer, doğru bağlamı LLM’e iletir ve nihai yanıtı kullanıcıya sunar. Bu sürece genel olarak RAG (Retrieval-Augmented Generation) diyoruz.

[Görsel: RAG mimarisinin veri kaynağından LLM yanıtına kadar olan adımlarını özetleyen sade bir akış şeması]

LangChain: İsviçre Çakısı Sendromu

LangChain, bu ekosistemin tartışmasız popüler çocuğu. Neredeyse her yeni çıkan aracı ilk gün destekler, topluluğu devasadır ve aklınıza gelebilecek her entegrasyona sahiptir.

Fakat bir sorun var: Aşırı soyutlama (over-abstraction).

Basit bir zincir (chain) kurmak harika hissettirir. Ancak üretim ortamında o zincirin ortasında bir hata aldığınızda, beş katman derinlikteki kütüphane kodlarının içinde kaybolursunuz. LangChain sık sık kırıcı güncellemeler (breaking changes) yapar. Üç ay önce yazdığınız kodun bugün çalışmama ihtimali hiç de az değil. Kısacası: Prototip çıkarmak için mükemmel, ama kurumsal ölçekte stabilite arıyorsanız riskli.

LlamaIndex: Verinizle Konuşmanın En Zarif Yolu

Eğer projenizin kalbinde veriyi doğru aramak ve bulmak yatıyorsa, LlamaIndex sahneye çıkmalı. Eskiden adı GPT Index olan bu araç, özellikle dokümanları parçalama, indeksleme ve sorgulama üzerine odaklanmış bir veri çatısıdır.

Gerçek Senaryo: 500 Sayfalık Finans Raporları

LangChain ile 500 sayfalık karmaşık tablolar ve dipnotlar içeren PDF dosyalarını sorgulamaya kalktığınızda, parçalama (chunking) mantığını baştan inşa etmeniz gerekir. LlamaIndex ise doğrudan bu problem için doğdu.

from llama_index.core import SimpleDirectoryReader, VectorStoreIndex

# Dokümanları oku ve otomatik indeksle
documents = SimpleDirectoryReader("raporlar").load_data()
index = VectorStoreIndex.from_documents(documents)

# Doğrudan akıllı sorgu motoruna çevir
query_engine = index.as_query_engine()
response = query_engine.query("2023 4. çeyrek operasyonel kârı ne kadar?")
print(response)

LlamaIndex, veriyi hiyerarşik olarak indeksler. Yani sorunuza yanıt ararken sadece en yakın metin bloğunu değil, dokümanın genel bağlamını da hesaba katar. “Gelişmiş RAG” yapacaksanız ilk durağınız burası olmalı.

Haystack: Kurumsal Dünyanın Sessiz Tankı

deepset tarafından geliştirilen Haystack, gösterişten uzak ama inanılmaz derecede sağlam bir framework. Haystack 2.0 ile birlikte baştan aşağı yenilenen boru hattı (pipeline) mimarisi, onu kurumsal projeler için açık ara en güvenli liman haline getirdi.

Haystack’in en büyük artısı: Grafik tabanlı, açık ve öngörülebilir olması. Bir pipeline kurduğunuzda hangi bileşenin (component) hangi girdiyi alıp hangi çıktıyı verdiğini tam olarak bilirsiniz. Sihirli siyah kutular yoktur; ne yazdıysanız o çalışır.

[Görsel: Haystack 2.0 pipeline arayüzünde bileşenlerin birbirine bağlanışını gösteren teknik ekran görüntüsü]

Neden Haystack?

  • Hata Ayıklama (Debugging) Kolaylığı: Hatanın nerede koptuğunu anında yakalarsınız.
  • Geleneksel Arama ile Hibrit Yaklaşım: Yalnızca vektör araması değil, Elasticsearch ve OpenSearch gibi BM25 tabanlı anahtar kelime aramalarıyla harmanlamada en olgun araçtır.
  • Üretim Odaklılık: Kod tabanı istikrarlıdır. Haftada bir tüm mimariyi değiştiren radikal kararlar almazlar.

Doğrudan Karşılaştırma

Hangisini ne zaman seçmeniz gerektiğine dair pratik bir özet tablosu hazırladım:

Özellik LangChain LlamaIndex Haystack
Ana Odak Genel amaçlı ajanlar ve prototipler Derinlemesine RAG ve veri işleme Üretime hazır arama ve kurumsal pipeline
Öğrenme Eğrisi Başlangıç kolay, uzmanlaşma kaotik Orta seviye Orta, mimarisi oldukça mantıklı
Stabilite Düşük (hızlı değişiyor) Orta – İyi Çok Yüksek
Topluluk & Eklenti Çok Geniş Geniş ve Hızla Büyüyor Daha niş ama odaklı kurumsal kitle

Fiyatlandırma ve Ücretsiz Alternatifler

Bahsettiğim üç framework’ün çekirdek kütüphaneleri de tamamen açık kaynaklı ve ücretsizdir (Apache 2.0 veya MIT lisanslarıyla dağıtılır). Kendi sunucunuzda tek kuruş ödemeden çalıştırabilirsiniz.

Maliyet yaratan kısım, bu yapıların üzerine kurulan bulut izleme ve veri yönetim araçlarıdır:

  • LangChain ekosistemi: Pipeline takibi için LangSmith kullanır (ücretsiz katmanı küçük projeler için yeterli, kurumsal için ücretli).
  • LlamaIndex ekosistemi: Kurumsal veri ayrıştırma için LlamaCloud ve LlamaParse sunar (günlük belirli sayfa sayısı ücretsiz, sonrasında kullandıkça öde).
  • Haystack ekosistemi: Bulut ortamında tam yönetilen hizmet için deepset Cloud adında kurumsal bir platforma sahiptir.

Tamamen yerel (on-premise) kalmak istiyorsanız; Ollama ile yerel LLM’leri çalıştırıp, vektör veri tabanı olarak Qdrant veya Chroma kullanarak sıfır maliyetle bu araçların tümünü deneyimleyebilirsiniz.

Sonuç: Hangisini Tercih Etmelisiniz?

Bir hackathon’daysanız ya da aklınıza gelen bir fikri hafta sonu hemen test etmek istiyorsanız, zengin entegrasyon havuzu nedeniyle LangChain hâlâ pratik bir kestirmedir.

Ancak derdiniz binlerce karmaşık PDF’i, tabloyu ya da SQL verisini LLM’e en doğru bağlamla yedirmekse hiç düşünmeden LlamaIndex tercih edin.

Eğer kurumsal bir yapıda, canlıya çıktığında patlamayacak, bakımı kolay, performansı izlenebilir bir arama veya soru-cevap sistemi inşa ediyorsanız adresiniz kesinlikle Haystack olmalıdır. AI dünyasında gösterişli olan değil, ayakta kalan kazanır.

Category: Genel | LEAVE A COMMENT
Ekim 2 2026

Ölçeklenen Altyapılarda Observability Maliyetini Yönetme: FinOps ve Sampling Stratejileri

Ay başında Datadog, New Relic veya AWS CloudWatch faturası geldiğinde dashboard’lardaki p99 gecikme grafiklerinden daha hızlı yükselen tek bir metrik vardır: Finans direktörünün nabzı. Modern bir DevOps mimarisinde mikroservislerin sayısı ve trafik hacmi arttıkça, observability altyapısının maliyeti çoğu zaman production ortamının compute maliyetini geride bırakır. Sistemin kör noktalarını kapatmak isterken bütçeyi tüketmek sürdürülebilir değil. Doğru bir FinOps yaklaşımı ve akıllı log yönetimi stratejileriyle, sistem görünürlüğünden ödün vermeden veri hacmini %60 ila %80 oranında düşürmek mümkün.

Fatura Neden Şişer? Görünmez Maliyet Kalemleri

Kıdemli mühendislerin sıkça düştüğü tuzak şudur: “Her şeyi loglayalım, OpenSearch veya Loki’ye basalım; lazım olursa grep’leriz.” Trafiğiniz saniyede 100 istek seviyesindeyken bu kabul edilebilir bir tembelliktir. Ancak saniyede 50.000 request aldığınız anda bu alışkanlık bir bütçe felaketine dönüşür.

Maliyeti patlatan üç ana faktör vardır:

  • Sağlık Kontrolleri (Health Checks): Kubernetes liveness/readiness probları ve ALB ping’leri log havuzunuzun %30’unu oluşturabilir. HTTP 200 GET /healthz satırının size hata anında hiçbir faydası yoktur.
  • Yüksek Kardinalite (High Cardinality): Metrik etiketlerine (label) user_id, order_id gibi sınırsız varyasyonu olan değerler eklemek, time-series veritabanınızın (Prometheus/Mimir) bellek tüketimini ve ingest maliyetini katlar.
  • Head-Based Sampling Hataları: Tracing verisinde rastgele %5 sampling aldığınızda, sistemdeki asıl yakalamak istediğiniz 500 hatalarının ve p99 outlier’larının da %95’ini çöpe atarsınız. Geriye sadece gürültü kalır.

Log Yönetimi: Vector ile Edge Düzeyinde Filtreleme ve Dönüştürme

Logları merkezi sisteme göndermeden önce daemonset katmanında filtrelemek en ucuz ve en etkili çözümdür. Logstash veya Fluentd gibi JVM/Ruby tabanlı hantal çözümler yerine Rust ile yazılmış düşük ayak izli Vector bu iş için biçilmiş kaftandır.

Aşağıdaki Vector konfigürasyonunda üç kritik optimizasyon yapıyoruz: Başarılı health check’leri drop ediyoruz, hassas verileri tokenize ediyoruz ve kalan debug loglarını örnekliyoruz (sampling).

cat << 'EOF' > /etc/vector/vector.yaml
sources:
  kubernetes_logs:
    type: kubernetes_logs

transforms:
  filter_health_checks:
    type: filter
    inputs:
      - kubernetes_logs
    # HTTP 200 dönen healthz loglarını doğrudan çöpe at
    condition: '!includes(["/healthz", "/readyz", "/livez"], .message)'

  drop_noisy_debugs:
    type: filter
    inputs:
      - filter_health_checks
    # Log seviyesi DEBUG olanları %90 oranında sample et
    condition: |
      if .level == "debug" {
        random() < 0.1
      } else {
        true
      }

  sanitize_and_prune:
    type: remap
    inputs:
      - drop_noisy_debugs
    source: |
      # Gereksiz Kubernetes metadata alanlarını temizle
      del(.kubernetes.pod_labels)
      del(.kubernetes.pod_annotations)
      
      # Kredi kartı gibi hassas verileri maskele
      .message = replace(.message, r'[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}', "[REDACTED_CC]")

sinks:
  elasticsearch_out:
    type: elasticsearch
    inputs:
      - sanitize_and_prune
    endpoints:
      - "https://elasticsearch.internal:9200"
    mode: "bulk"
EOF

Neden böyle yaptık? Kubernetes metadata’sındaki pod annotation’ları production’da devasa JSON payload’ları üretir. Bunları edge katmanında del() fonksiyonu ile silmek, taşınan ve indekslenen veri boyutunu anında %25 azaltır.

Tracing Verisinde Tail-Based Sampling Stratejisi

Geleneksel distributed tracing araçları trace’in başlangıcında karar verir (Head-based sampling). Bir istek geldiğinde yazı tura atılır: %1 seçilirse tüm akış kaydedilir. Fakat istek sırasında bir mikroservis patlarsa ve siz o isteği sample etmediyseniz, elinizde hiçbir şey kalmaz.

Tail-based sampling, isteğin tamamlanmasını bekler. İstek hata aldıysa veya belirlenen latency eşiğini aştıysa trace’i %100 saklar; sorunsuz HTTP 200 yanıtlarını ise agresif bir şekilde eler.

Bunu OpenTelemetry (OTel) Collector katmanında şu şekilde konfigüre ediyoruz:

cat << 'EOF' > /etc/otelcol/config.yaml
receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  tail_sampling:
    decision_wait: 10s
    num_traces: 10000
    expected_new_traces_per_sec: 2000
    policies:
      # 1. Kural: Status code ERROR olan tüm trace'leri eksiksiz tut
      - name: drop_errors_policy
        type: status_code
        status_code: { status_codes: [ ERROR ] }

      # 2. Kural: Süresi 1.5 saniyeyi aşan tüm yavaş istekleri yakala
      - name: latency_policy
        type: latency
        latency: { threshold_ms: 1500 }

      # 3. Kural: Kalan normal akıştan sadece %1 örnek al
      - name: probabilistic_policy
        type: probabilistic
        probabilistic: { sampling_percentage: 1.0 }

exporters:
  otlp/backend:
    endpoint: "tempo.monitoring.svc.cluster.local:4317"
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [tail_sampling]
      exporters: [otlp/backend]
EOF

Bu konfigürasyonda OTel Collector, trace parçalarını decision_wait: 10s süresince bellekte tutar. Span ağacı tamamlandığında kuralları yukarıdan aşağıya değerlendirir. İstisna veya lag varsa diskte saklanır; yoksa veri hacmi anında %99 bastırılır.

Metriklerin Sessiz Katili: Kardinaliteyi Düşürme (Metric Relabeling)

Datadog veya Prometheus faturalarında metrik maliyetlerinin patlamasının temel nedeni “Custom Metrics” ve time-series patlamalarıdır. Bir metriğin kaç time-series ürettiğini şu formülle hesaplarız:

Total Time Series = (Değer_Sayısı_Label_A) * (Değer_Sayısı_Label_B) * (Değer_Sayısı_Label_C)

Eğer bir yazılımcı HTTP istek metriğine user_id veya rastgele UUID’ler içeren path eklediyse, o metrik saniyeler içinde 500.000 time-series üreterek bellek limitlerini vurur. Prometheus scrape konfigürasyonunda metric_relabel_configs kullanarak bu etiketleri ingest anında silmelisiniz:

scrape_configs:
  - job_name: 'api-gateway'
    kubernetes_sd_configs:
      - role: pod
    metric_relabel_configs:
      # Belirli yüksek kardinaliteli dinamik labelları drop et
      - action: labeldrop
        regex: '(user_id|client_ip|session_token)'
      
      # REST URL path'lerindeki UUID'leri regex ile normalize et
      - source_labels: [__name__, path]
        regex: 'http_requests_total;/api/v1/orders/[a-f0-9\-]+'
        target_label: path
        replacement: '/api/v1/orders/:id'

Yukarıdaki işlem yapılmadığında /api/v1/orders/a1b2-c3d4 ve /api/v1/orders/e5f6-g7h8 iki ayrı metrik olarak depolanır. Regex normalizasyonu sayesinde her iki istek de /api/v1/orders/:id altında birleşir; metrik tekilleşir ve time-series sayısı tek hanelere iner.

Veri Yaşam Döngüsü: Tiering ve Soğuk Depolama

SRE ekiplerinin yaptığı analizler, log sorgularının %92’sinin son 48 saat içinde yazılan verilere yapıldığını gösteriyor. 30 gün önceki bir INFO logunu pahalı NVMe disklerde tutmak safi kaynak israfıdır.

Loki veya Elasticsearch kullanırken iki katmanlı (hot/cold) saklama stratejisi kurgulayın:

  • Hot Tier (0-7 Gün): Hızlı sorgulama için NVMe diskler veya SSD blok depolama. Tam indeksleme açık.
  • Warm/Cold Tier (7-30 Gün): İndeksleri küçültülmüş, read-only modda çalışan uygun maliyetli HDD veya S3/GCS object storage katmanı.
  • Deep Archive (30+ Gün): Yalnızca regülasyon (KVKK/GDPR/PCI-DSS) gereği tutulması gereken veriler için S3 Glacier / GCS Archive lifecycle kuralları. İndeks yok, yalnızca ham gzip blokları.

Özet: FinOps Mühendisliği Bir Süreçtir

Observability sistemlerini optimize etmek, kör uçuş yapmak anlamına gelmez. Tam aksine, doğru sinyali yakalayıp gürültüyü (noise) elimine etmektir. Edge katmanında Vector ile gürültüyü kesin, APM tarafında tail-based sampling ile hatalara odaklanın ve scraping aşamasında kardinaliteyi regex ile dizginleyin. Bu üç adımı attığınızda, faturanız düşerken platformunuzun asıl sorunları tespit etme kabiliyeti katlanarak artacaktır.

Category: Genel | LEAVE A COMMENT
Ekim 1 2026

Slow Travel ve Verimlilik: 1 Aylık ‘Workation’ Lokasyonu Nasıl Seçilir?

Dizüstü bilgisayarını sırt çantasına atıp her üç günde bir şehir değiştiren o meşhur dijital göçebelerin Instagram filtrelerine aldanmayın. Bir kafenin sallanan masasında, şarj aletinin kablosu yetişmediği için iki büklüm çalışırken aynı zamanda arka planda “mutlaka görülmesi gereken 10 yer” listesini tüketmeye çabalamak bir özgürlük değil, sadece yeni nesil bir tükenmişlik sendromudur. İşte bu noktada workation kavramı, slow travel yani yavaş seyahat felsefesiyle kesiştiğinde gerçek bir yaşam tarzı haline geliyor. Bir şehri fethetmeye değil, o şehirde geçici bir hayat kurmaya gittiğinizde hem işler tıkırında gidiyor hem de banka hesabınız nefes alıyor.

Peki, haritayı önünüze açtığınızda o “mükemmel bir ayı” geçireceğiniz yeri nasıl seçeceksiniz? Salt Instagram estetiğine kapılmadan, hem üretken kalıp hem de yerel bir mahalleli gibi yaşamanın püf noktalarını konuşalım.

Hızlı İnternet Yetmez: Ergonomi ve Işık Tuzağı

Çoğu uzaktan çalışan gezginin ilk baktığı şey Speedtest ekran görüntüsüdür. Elbette 50 Mbps altındaki bir bağlantı Zoom toplantılarında yüzünüzü dondurur, kabul. Ancak kimse size o 100 Mbps fiber internetin, beli iki günde mahveden tahta bir tabure ve sehpa yüksekliğindeki bir masayla sunulduğunu söylemez. Bir ay boyunca haftada en az 30-40 saat mesai yapacağınızı unutmayın. Bel ağrısıyla boğuştuğunuz bir Barselona sabahı, inanın Kadıköy’deki ofis masanızı özletir.

Ev kiralarken fotoğraflara bir emlak müfettişi gibi yaklaşmanız şart. Çalışma masasının arkasında priz var mı? Doğal ışık ekrana dik mi vuruyor, yoksa ferah bir yan açıdan mı geliyor? Mutfak masasını çalışma alanı olarak gösteren ilanlara mesafeli durun; çünkü o sandalyeler bir saatlik akşam yemeği için tasarlanmıştır, tüm gün kod yazmak ya da rapor hazırlamak için değil.

İpucu: Rezervasyon yapmadan önce ev sahibine standart “İnternet hızlı mı?” sorusu yerine, “Rica etsem modemin yanında değil, çalışma masasından bir hız testi yapıp ekran görüntüsünü atabilir misiniz? Bir de sandalyenin sırt desteği var mı?” diye sorun. Bu soruya özenle yanıt veren ev sahipleri, genellikle konaklamanız boyunca da çözüm odaklı olur.

Bütçe Matematiği: Aylık Kalmanın Gücü

Seyahatte en büyük gider kalemi her zaman barınmadır. İşin içine slow travel girdiğinde ise ekonomi kuralları sizin lehinize işlemeye başlar. Airbnb ya da Flatio gibi platformlarda 28 gün ve üzeri aramalar yaptığınızda devreye giren %30 ile %50 arasındaki aylık indirimler, günlük fiyatı astronomik olan daireleri birdenbire makul bir seviyeye çeker.

Örneğin, Lizbon’un turist kaynayan merkezinde geceliği 90 Euro olan bir stüdyo daireye 2.700 Euro vermek akıl kârı değildir. Ancak merkezden trenle 20 dakika uzaklıktaki Carcavelos ya da Oeiras gibi banliyölere kaydığınızda, aylık bütçeniz 1.100 – 1.400 Euro bandına geriler. Üstelik sabahları okyanus kıyısında koşup, yerel pazardan haftalık 30-40 Euro’ya taze balık ve sebze alabileceğiniz bir düzene geçersiniz. Bulgaristan’ın Bansko kasabası kışın kayak merkezi olsa da bahar ve yaz aylarında aylık 350-500 Euro bandındaki stüdyolarıyla Avrupa’nın en bütçe dostu çalışma merkezlerinden birine dönüşür. Uçak biletine harcayacağınız parayı, orada geçireceğiniz bir ayın toplam giderlerine yaydığınızda, günlük maliyetiniz evinizdeki sabit giderlerden çok daha ucuza gelebilir.

Topluluk Olmadan Seyahat Yalnızlaştırır

Yalnız seyahat etmenin en romantik anlatılarında bile atlanan bir detay var: Yabancı bir ülkede, bütün gün ekrana bakıp akşam tek başınıza süpermarketten aldığınız sandviçi yemek bir süre sonra boğucu gelir. Bir lokasyonu “yaşanabilir” kılan en temel unsur, orada sizin gibi düşünen insanların varlığıdır. Bu yüzden gideceğiniz bölgede aktif bir coworking space veya yerel toplulukların buluştuğu kafeler olup olmadığını önceden tarayın.

Selanik’i ele alalım. Atina kadar kaotik değildir, yürünebilir bir şehirdir ve yerel halk inanılmaz sıcaktır. Şehir merkezindeki küçük ortak çalışma alanları aylık 120-160 Euro civarındadır. Buraya vereceğiniz para bir gider değil, yatırımdır. Çünkü yan masanızda oturan freelance bir tasarımcıyla içtiğiniz bir fincan freddo espresso, sizi o şehrin turist rotalarından çıkarıp yerlilerin bildiği saklı tavernalara götürür. İnsan bağları, verimliliğin en büyük tetikleyicisidir.

İpucu: Seyahatinizden iki hafta önce gideceğiniz şehrin dijital göçebe Facebook gruplarına veya Slack/Discord kanallarına dahil olun. “Nerede kalınır?” klişesi yerine “Haftada bir voleybol oynayan ya da akşam koşusuna çıkan bir grup var mı?” diye sorun. Gerçek topluluğa böyle ulaşırsınız.

Ritmi Yakalamak: 4 Saatlik Zaman Dilimi Kuralı

Eğer müşterileriniz veya ekibiniz Türkiye’de ya da Avrupa’daysa, kendinizi Bali’ye veya Tayland’a atmak kağıt üzerinde harika görünür. Fakat gece yarısı müşteri toplantısına girmek, sabahın köründe çalışıp öğleden sonrayı sersem gibi geçirmek üretkenliği baltalar. Workation yaparken zaman dilimi farkını en fazla 3-4 saatte tutmak altın kuraldır.

Kendi gününüzü bloklara bölün. Sabah 08:00 ile 12:00 arasını derin çalışmaya (deep work) ayırın. Öğle saatlerinde yerel bir fırından aldığınız börekle parkta 45 dakika geçirin, esnafla iki kelime sohbet edin. Kalan mesaiyi ikindiye kadar tamamlayıp laptop kapağını kapattığınızda, önünüzde keşfedecek koca bir akşam kalır. İşte yavaş seyahatin vaadi budur: Turist gibi koşturmazsınız, o sokakların ritmine karışırsınız.

Sonuçta mesele sadece başka bir coğrafyada çalışmak değil. Mesele, sabah uyandığınızda kahvenizi koyup pencereden baktığınız o yeni sokağın, zihninize daha önce hiç uğramamış taze fikirler fısıldamasını sağlamaktır.

Category: Genel | LEAVE A COMMENT
Eylül 27 2026

Yazılım Geliştirmede ‘Stage-Gated’ Disiplin: LLM Çıktılarını Kontrol Altına Alın

Modern yazılım geliştirme dünyasında artık hemen hepimiz bir LLM (Büyük Dil Modeli) ile yan yana kod yazıyoruz. İster Cursor kullanın ister Claude veya Copilot; yapay zekanın birkaç saniyede yüzlerce satır kod üretmesi büyüleyici bir his. Ancak dürüst olalım: O üretilen kodların arkasında bazen var olmayan kütüphane bağımlılıkları, sinsi mantık hataları ve ciddi güvenlik açıkları saklanıyor. Hızlı yazıyoruz ama arkamızı toplamaya çalışırken daha çok yoruluyoruz. İşte bu noktada modern yazılıma eski ama çok sağlam bir disiplin geri dönüyor: Stage-Gated yaklaşımı.

Bu yazıda, geleneksel mühendislikten ödünç aldığımız bu “aşamalı kapı” sistemini yapay zeka destekli bir pipeline içine nasıl entegre edebileceğimizi, bizzat kurup test ettiğim bir senaryo üzerinden anlatıyorum. Amacımız yapay zekayı yavaşlatmak değil; yapay zeka güvenliği standartlarından taviz vermeden kodu üretime (production) taşımak.

Şelale (Waterfall) Mezardan mı Çıktı? “Stage-Gated” Nedir?

Eski usul Waterfall (Şelale) metodolojisini hatırlarsınız: Bir faz bitmeden diğeri başlamaz, arada kalın onay kapıları bulunur. Çevik (Agile) dünyada bundan nefret ettik çünkü hızı kesiyordu. Fakat işin içine modeller ve tahmin edilemez çıktılar girince dengeler değişti.

Stage-Gated mekanizması, üretilen bir çıktının bir sonraki aşamaya geçebilmesi için belirli kriterleri (“kapıları”) geçmek zorunda olduğu bir filtreleme modelidir. Bir LLM’e “Bana şu API servisini yaz” dediğinizde kodu doğrudan ana dala (main branch) göndermezsiniz. Kod, tanımladığınız kapılardan sırayla geçer; herhangi bir kapıda takılırsa ya LLM’e düzeltmesi için geri fırlatılır ya da doğrudan reddedilir.

[Görsel: Bir LLM kod üretim pipeline’ının 4 aşamalı kapıdan (Sözdizimi, Güvenlik, Test, İnsan Onayı) geçişini gösteren şematik diyagram]

Test Masası: 4 Kapılı Bir Pipeline Mimarisi

Teoriyi bir kenara bırakıp işi pratiğe dökelim. Deneme amacıyla yerel ortamımda FastAPI ile basit bir servis geliştiren bir akış kurdum. Modeli (Claude 3.5 Sonnet) bir komut satırı aracıyla tetikledim ve kodu şu 4 kapıdan geçirdim:

Kapı 1: Sözdizimi (Syntax) ve Tip Kontrolü

LLM’ler bazen parantezleri unutur, bazen var olmayan metodları çağırır. İlk kapımız en ucuz ve en hızlı olanı: AST (Soyut Sözdizim Ağacı) kontrolü ve mypy tip denetimi. Modelin çıktısı bu aşamada Python tarafından derlenemiyorsa sonraki aşamaya geçiş izni verilmez.

Kapı 2: Statik Güvenlik Analizi (SAST)

Model, istemeden de olsa SQL Injection açığı üretmiş olabilir mi? Ya da hardcoded bir API anahtarı bırakmış mı? Bu kapıda açık kaynaklı statik analiz araçları (örneğin Semgrep veya Bandit) devreye girer. Güvenlik açığı tespit edilirse pipeline kırılır.

# Semgrep ile yerel pipeline kontrolü çalıştırma
semgrep scan --config auto --error ./generated_code/

Kapı 3: Otomatik Birim Testleri ve “Self-Healing”

İşte en sevdiğim bölüm. Eğer kod ilk iki kapıyı geçtiyse, önceden tanımlanmış test senaryoları (Pytest) çalıştırılır. Test başarısız olursa, test hata raporu otomatik olarak tekrar LLM’e gönderilir: “Kodun şu testten geçmedi, hata mesajı bu. Kodu tekrar düzenle.” Buna sektörde self-healing (kendi kendini onarma) döngüsü deniyor. En fazla 3 deneme hakkı tanıyoruz.

Kapı 4: İnsan Gözü (Human-in-the-Loop)

Bütün testlerden geçen kod bir Pull Request (PR) olarak açılır. Son kapı daima bir insandır. Ancak bu aşamaya gelen kod zaten sözdizimi, güvenlik ve temel iş kuralları açısından elendiği için inceleyen mühendisin harcadığı süre dakikalar yerine saniyelere iner.

[Görsel: GitHub Actions üzerinde çalışan Semgrep ve Pytest adımlarının yeşil tik aldığı, insan onayı bekleyen PR ekran görüntüsü]

Gerçek Bir Deney: SQL Injection Girişimi Kapıya Takılınca

Pipeline’ı test etmek için Claude’a bilerek hafif yönlendirici bir prompt verdim: “Kullanıcı ID’sine göre kullanıcı bilgilerini getiren ham SQL sorgulu bir fonksiyon yaz.”

Model, f-string kullanarak sorguyu birleştiren tipik bir güvensiz kod bloğu oluşturdu. Süreç şöyle işledi:

  • Kapı 1 (Syntax): Kod geçerli Python sözdizimine sahipti. Geçti.
  • Kapı 2 (Semgrep): Kırmızı alarm! python.lang.security.audit.sqli kuralı tetiklendi. Parametreli sorgu kullanılmadığı için kod derhal durduruldu.
  • Geri Besleme: Pipeline, Semgrep hata çıktısını prompt’a ekleyip modeli uyardı.
  • Sonuç: İkinci denemede model kodu SQLAlchemy ORM parametreli sorgusuyla düzeltti ve Kapı 2’den başarıyla geçti.

Artılar ve Eksiler: Bu Zahmete Değer mi?

Her güvenlik katmanı beraberinde bir sürtünme getirir. Karar vermenizi kolaylaştırmak için gözlemlerimi özetledim:

Avantajlar Dezavantajlar
Halüsinasyon kaynaklı bağımlılık ve hatalar sisteme sızamaz. CI/CD süreçleri biraz daha uzun sürer (ortalama +40-90 saniye).
Yapay zeka güvenliği şirket politikaları seviyesinde garantiye alınır. LLM API maliyetleri (tekrar denemeler yüzünden) %15-20 artabilir.
Kıdemsiz geliştiricilerin fark edemediği açıklar erken yakalanır. İlk kurulum ve doğru kural setlerini yazmak teknik efor ister.

Hangi Araçları Kullanabilirsiniz? (Fiyat ve Alternatifler)

Bu yapıyı kurmak için servet harcamanıza gerek yok. Açık kaynak dünyasında harika ücretsiz seçenekler mevcut:

  • Guardrails AI (Ücretsiz / Açık Kaynak): LLM çıktılarını belirli Pydantic şemalarına ve regex/güvenlik kurallarına zorlamak için biçilmiş kaftan. Kendi sunucunuzda tamamen ücretsiz çalıştırabilirsiniz.
  • Semgrep (Freemium): Statik kod analizi için sektör standardı haline geldi. Açık kaynak versiyonu CLI üzerinden yerelde veya GitHub Actions içinde tamamen ücretsizdir. Ekip yönetimi sunan Semgrep Cloud ise aylık kullanıcı başı yaklaşık $40 civarından başlar.
  • NeMo Guardrails (NVIDIA – Ücretsiz): Özellikle diyalog ve mantık akışlarını kısıtlamak isteyenler için geliştirilmiş güçlü bir açık kaynak kütüphane.
  • SonarQube Community Edition (Ücretsiz): Kod kalitesini ve teknik borcu ölçmek için kendi sunucunuza kurabileceğiniz ücretsiz alternatif.

Son Söz

Yapay zekanın kod yazma hızına hayran olmamak elde değil. Ancak kontrolsüz hız, teknik borç dağları ve güvenlik kabusları yaratır. Stage-gated yaklaşımı, Agile pratikleri yavaşlatmak için değil; yapay zekayı sorumsuz bir stajyerden güvenilir bir takım arkadaşına dönüştürmek için ihtiyacımız olan emniyet kemeridir. Henüz denemediyseniz, en azından bir GitHub Action içine basit bir linter + Semgrep kapısı koyarak ilk adımı atmanızı şiddetle tavsiye ederim.

Category: Genel | LEAVE A COMMENT
Eylül 27 2026

Geliştirici Mutfağı: Kan Şekerini Dengeleyen ve Brain Fog’u Engelleyen 15 Dakikalık Atıştırmalık

Saat öğleden sonra üç civarı. Ekranda çözülmeyi bekleyen can sıkıcı bir bug var ama kafanızın içi yoğun bir sis bulutu: Selam brain fog. Çekmecedeki gofret paketine uzanıp hızlı bir şeker patlaması aramak çok cezbedici görünse de, bu hamle kan şekerinizi hızla fırlatıp yarım saat sonra sizi derin bir zihinsel çöküşe (crash) sürükler. Oysa bilişsel verimlilik ve uzun vadeli zihinsel sağlık için ihtiyacınız olan şey basit: Doğru bir nutrition stratejisi ve gerçek bir brain food alternatifi olan pratik bir yemek çözümü.

Bugün mutfakta saatler harcamadan, kodunuz derlenirken hazırlayabileceğiniz “Tahinli ve Kakaolu Odak Topları” yapıyoruz. Pişirme yok, bulaşık derdi minimum.

Porsiyon: 10-12 adet (Yaklaşık 3 porsiyon)
Hazırlık Süresi: 10 dakika
Pişirme Süresi: 0 dakika

Neden Bu Kombinasyon? (Sisi Dağıtan Bilim)

Basit karbonhidratlar beyninize hızlı bir ödül verir ama bedelini ani odak kaybıyla ödetir. Bu tarifte yulafın sunduğu kompleks lifler glukozun kana yavaş karışmasını sağlar. Tahin ve fıstık ezmesindeki sağlıklı yağlar nöronlar arası iletişimi desteklerken, ham kakaodaki flavanoller beyne giden kan akışını artırır. Deniz tuzu ise ekran başında unuttuğunuz elektrolit dengesini yerine koyar.

Malzemeler

  • İnce öğütülmüş yulaf ezmesi: 1 su bardağı (Kompleks karbonhidrat tabanı)
  • Doğal fıstık ezmesi veya tahin: 3 yemek kaşığı (Şekersiz, katkısız)
  • Ham kakao: 1.5 yemek kaşığı (Antioksidan ve dopamin desteği)
  • Chia tohumu: 1 yemek kaşığı (Omega-3 ve lif kaynağı)
  • Akçaağaç şurubu veya ham bal: 1.5 yemek kaşığı (Düşük glisemik indeksli tatlandırıcı)
  • İri çekim deniz tuzu: Küçük bir çimdik
  • Sıcak su veya badem sütü: 1-2 yemek kaşığı (Kıvamı bağlamak için gerekirse)

Evde Yoksa Ne Kullanabilirsiniz? (Alternatifler)

Mutfakta mutlak kurallar yoktur, refactoring serbesttir:

  • Fıstık ezmesi yerine fındık ya da badem ezmesi kullanabilirsiniz. Fıstık alerjiniz varsa sadece tahinle ilerleyin; tahinin susamdan gelen hafif buruk lezzeti kakaoyla harika uyum sağlar.
  • Chia tohumu yerine öğütülmüş keten tohumu koyabilirsiniz.
  • Elinizde ham kakao yoksa normal kakao da iş görür; ancak ham (raw) kakaonun polifenol oranı zihinsel uyanıklık için her zaman daha etkilidir.

Adım Adım Hazırlanışı

  1. Kuru malzemeleri harmanlayın: Geniş bir kasede yulaf ezmesi, ham kakao, chia tohumu ve deniz tuzunu bir kaşıkla karıştırın.
  2. Islak malzemeleri ekleyin: Karışımın ortasını hafifçe açıp fıstık ezmesini (veya tahini) ve balı ekleyin. Spatula veya çatalla ezerek birbirine yedirin.
  3. Kıvamı test edin: Karışımı elinizle sıkın. Birbirine tutunuyorsa tamamdır. Fazla kuru ve ufalanıyorsa, 1 yemek kaşığı ılık su veya süt ekleyip yoğurur gibi toparlayın.
  4. Porsiyonlayın ve yuvarlayın: Karışımdan ceviz büyüklüğünde parçalar koparıp avucunuzda sıkıca yuvarlayarak toplar haline getirin.
  5. Soğutun (Opsiyonel ama tavsiye edilir): Vaktiniz varsa buzdolabında 10 dakika dinlendirin. Vaktiniz yoksa doğrudan klavye başına geri dönebilirsiniz.

Püf Noktası

Bu tarifin sihirli dokunuşu deniz tuzudur. Tuzu kesinlikle atlamayın; tatlı-tuzlu kontrastı sadece lezzeti katlamakla kalmaz, kan basıncını dengeleyerek öğleden sonra gelen o rehavet hissini kırmaya yardımcı olur. Ayrıca bu topları hava almayan bir kapta buzdolabında 7 güne kadar saklayabilirsiniz. Pazar akşamı 10 dakikada yapın, hafta boyunca ‘Ne atıştırsam?’ stresini aradan çıkarın.

Category: Genel | LEAVE A COMMENT
Eylül 26 2026

Geliştiriciler İçin Tech Neck ve Göz Yorgunluğu: Fizyolojik Çözümler

O meşhur “flow state” anını hepimiz biliriz: Kod akıyor, testler yeşile dönüyor, Spotify arkada en sevdiğin lo-fi listesini çalıyor… Ta ki sandalyeden kalkmaya çalışıp boynundan sırtına inen o keskin sızıyı hissedene kadar. Masa başı çalışanlar, özellikle de geliştiriciler için tech-neck sendromu ve kronik göz yorgunluğu artık mesleğin fıtratından sayılmaya başlandı. Oysa vücudumuz, saatlerce çift monitör karşısında bir karides gibi kıvrılmak üzere evrimleşmedi.

Bugün hem boyun omurlarını rahatlatacak hem de ekranın arkasında unuttuğun gözlerini tazeleyecek pratik, bilimsel ve günlük 10 dakikanı alacak bir kurtarma planı hazırlıyoruz. Hazırsan, sandalyede dikleş ve okumaya devam et.

Kafan Neden Bu Kadar Ağır? (Tech Neck Fizyolojisi)

İnsan kafası dik bir duruşta yaklaşık 4,5 – 5,5 kilogram ağırlığındadır. Yani boyun kasların normal şartlarda ortalama bir bowling topunu dengede tutmakla görevlidir. Ancak ekranı daha iyi görmek için başını öne doğru her eğdiğinde, omurgaya binen yük katlanarak artar.

Omurga cerrahisi üzerine yapılan araştırmalar gösteriyor ki, başını sadece 45 derece öne eğdiğinde boyun omurlarına binen yük yaklaşık 22 kilograma, 60 dereceye çıktığında ise 27 kilograma fırlıyor. Yani gün boyu kod yazarken farkında olmadan boynunda 8 yaşında bir çocuğu taşıyorsun. Bu durum zamanla servikal disklerde aşınmaya, kronik kas spazmlarına ve nihayetinde boyun fıtığına kapı aralıyor.

Monitörler ve Yanan Kornealar: Göz Sağlığı (Eye Health) Neden Çöküyor?

Göz kuruluğu ve baş ağrısı da bu paketin bonus hediyesi. Normal bir insan dakikada ortalama 15 ila 20 kez göz kırpar. Bu hareket, gözün yüzeyini gözyaşı tabakasıyla kaplayarak korur ve net görmeyi sağlar.

Fakat bir ekrana odaklandığımızda göz kırpma sıklığımız yarı yarıya, bazen dakikada 5-7 sefere kadar düşüyor. Üzerine bir de monitörlerden yayılan mavi ışık, düşük kontrast ve yanlış aydınlatma eklenince; gün sonunda gözlerin yanması, odaklanma güçlüğü ve migren benzeri ağrılar kaçınılmaz hale geliyor.

Önemli Uyarı: Kollarında, parmaklarında uyuşma, karıncalanma veya güç kaybı hissediyorsan ya da gözlerinde ani görme kayıpları/ışık çakmaları oluyorsa egzersizleri bir kenara bırakıp vakit kaybetmeden bir uzmana veya nöroloğa/göz doktoruna danışmalısın.

10 Dakikalık Developer Wellness Kurtarma Protokolü

Haftada bir gün spora gidip iki saat ağırlık kaldırmak, haftanın geri kalan 40 saatinin omurgaya verdiği hasarı sıfırlamaz. Bize gereken şey: Mikro dozda tutarlılık. İşte çalışma masanın başında her gün uygulayabileceğin 10 dakikalık posture ve yenilenme rutini:

1. Boyun ve Üst Sırt İçin “Reset” (5 Dakika)

  • Chin Tucks (Çene Gömme): Sırtını dik tut. Başını arkaya doğru, sanki birisi sana kötü bir şey söylemiş de geri çekiliyormuşsun gibi kaydır (evet, o komik çift çene görüntüsü doğru yolda olduğunu gösterir). 5 saniye bekle, bırak. 10 tekrar yap. Bu hareket, zayıflayan derin boyun fleksörlerini güçlendirir.
  • Doorway Stretch (Kapı Eşiği Esnemesi): Ayağa kalk, bir kapı eşiğinde kollarını 90 derece bükerek eşiğe daya ve göğsünü öne doğru hafifçe it. Gün boyu klavyeye uzanmaktan kısalan pektoral (göğüs) kaslarını açarak omuzlarını geriye almanı sağlar. 30 saniye boyunca derin nefes alarak bekle.
  • Scapular Retraction (Kürek Kemiği Sıkıştırma): Omuzlarını kulaklarından uzaklaştır, kürek kemiklerinin arasında bir kalem varmış gibi onları birbirine doğru sık. 5 saniye tut, 10 kez tekrarla.

2. Gözleri Yeniden Başlat (2 Dakika)

  • 20-20-20 Kuralı: Her 20 dakikada bir, en az 20 fit (yaklaşık 6 metre) uzaktaki bir nesneye 20 saniye boyunca bak. Bu, gözün içindeki odaklanma kaslarını (siliyer kaslar) gevşetir.
  • Palming (Avuç İçi Terapisi): Ellerini birbirine sürtüp ısıt. Gözlerini kapat ve avuç içlerini göz çukurlarının üzerine baskı yapmadan kapat. Tamamen karanlıkta 1 dakika derin nefes al. Göz kaslarının ve sinir sisteminin anında sakinleştiğini hissedeceksin.

3. Alt Sırt ve Kalça Aktivasyonu (3 Dakika)

  • Seated Pelvic Tilt: Sandalyende dikleş. Belini önce içeri doğru çukurlaştır, ardından arkaya doğru yuvarlayarak kamburlaştır. Bu dalgalanma hareketi, saatlerce durağan kalan omurilik sıvısının ve kanın diskler arasında dolaşmasını sağlar. 15 tekrar yeterli.

Çalışma Alanını Hack’lemek: Temel Ergonomics

Egzersizler harika ama ortamı düzeltmezsen sürekli başa sararsın. Çalışma alanını ergonomics kurallarına göre ayarlamak sandığından çok daha basit:

Monitörünün üst kenarı tam olarak göz hizanda olmalı. Ekrana bakarken kafanı aşağı eğmek zorunda kalıyorsan, altına birkaç kalın kitap veya bir monitör standı koy. Dirseklerin ve dizlerin masa/sandalye temasında yaklaşık 90 derecelik açıyı korumalı, ayak tabanların yere tam basmalı.

Unutma: Mükemmel bir oturuş pozisyonu yoktur; en iyi duruş, bir sonraki duruşundur. Vücudun hareketsiz kaldıkça paslanır. Pomodoro aralarına bu mikro molaları ekle; hem yazdığın kodun kalitesi artsın hem de günün sonunda başı dimdik duran bir geliştirici ol.

Category: Genel | LEAVE A COMMENT
Eylül 26 2026

Mutfakta ‘Lean Manufacturing’: 30 Dakikada 3 Günlük Sağlıklı Yemek

Toyota’nın fabrikalarında parça bekleme süresini sıfıra indiren o meşhur üretim felsefesini hiç akşam saat 8’de, karnınız guruldarken buzdolabının önünde çaresizce durduğunuz o anla bağdaştırdınız mı? Evet, meal prep yapmaktan bahsediyorum ama öyle pazar gününün 5 saatini feda ettiğiniz türden değil. Doğru bir mutfak yönetimi ve endüstriyel verimlilik teknikleriyle, sağlıklı beslenme rutini oluşturmak aslında sadece 30 dakikanızı alır.

Mutfaktaki en büyük “israf” (Japonların deyimiyle Muda) bulaşık, gereksiz hareketler ve çürüyen sebzelerdir. Bugün tek bir fırın tepsisi ve paralel iş akışıyla 3 günlük nefis bir baz hazırlıyoruz.

Genel Bilgiler

Porsiyon: 3 Öğünlük
Hazırlık Süresi: 10 Dakika
Pişirme Süresi: 20 Dakika

Gerekli Malzemeler: Esnek ve Modüler

Buradaki amacımız tek bir ana pişirme ile 3 farklı lezzet yakalamak. Evde ne varsa ona göre modifiye edebilirsiniz:

  • Protein tabanı: 500 gr tavuk göğsü (Alternatif: Küp doğranmış sert tofu veya 2 kutu süzülmüş haşlanmış nohut)
  • Sebze matrisi: 1 baş brokoli, 2 adet kapya biber, 1 adet kırmızı soğan (Alternatif: Kabak, mantar veya havuç)
  • Kompleks karbonhidrat: 1 su bardağı kinoa veya kuskus (Alternatif: Karabuğday ya da esmer pirinç)
  • Lezzet bağlayıcılar: 3 yemek kaşığı zeytinyağı, 1 tatlı kaşığı toz kırmızı biber, 1 çay kaşığı sarımsak tozu, tuz, karabiber
  • Hızlı sos: 2 yemek kaşığı tahin, yarım limonun suyu, 2 yemek kaşığı ılık su

30 Dakikalık ‘Sprint’ Hazırlık Adımları

  1. Hattı Başlatın (Pre-heat): Fırını 200°C’ye getirin. Kettle’da su kaynatın. Kinoa veya kuskusu küçük bir tencereye alın, üzerine sıcak suyu ve tuzu ekleyip kapağını kapatın; o kendi kendine demlensin.
  2. Tek Bıçak, Tek Tahta (Mise en place): Tahtaya önce sebzeleri alın, iri parçalar halinde doğrayın. Bıçağı yıkamadan hemen ardından tavukları lokmalık küpler halinde kesin. Çapraz bulaşmayı önlemek için sebze-protein sırasını asla şaşırmayın.
  3. Tepsi Bölümleme (Batching): Büyük bir fırın tepsisine yağlı kâğıt serin. Sol tarafa tavukları, sağ tarafa sebzeleri yayın. Üzerlerine zeytinyağı ve baharatları gezdirip elinizle hızlıca harmanlayın. Tepsiyi fırına sürün ve 20 dakikalık sayacı başlatın.
  4. Montaj ve Saklama: Fırın çalışırken tahin, limon ve ılık suyu küçük bir kavanozda çalkalayarak sosunuzu yapın. 3 adet saklama kabı çıkarın. Pişen kinoayı tabana paylaştırın. Fırından çıkan fırınlanmış sebze ve proteini kaplara eşitçe bölüştürün.

Püf Noktası: 3 Gün Aynı Şeyi Yememe Sanatı

Kimse üç gün üst üste birebir aynı tadı almak istemez; motivasyonu kıran şey tam olarak budur. Hazırladığınız baz aynı kalsa da kimliğini küçük dokunuşlarla değiştirin:

1. Gün: Hazırladığınız tahin sosu gezdirip ılık tüketin.
2. Gün: Kaba biraz soya sosu ve susam ekleyip Asya esintili bir bowl’a dönüştürün.
3. Gün: İçeriği bir lavaşın içine sarıp, biraz taze yeşillikle hızlı bir dürüme çevirin.

Mutfakta Sıfır İsraf: Just-in-Time Yaklaşımı

Buzdolabında unutulan sebzeler paranızın doğrudan çöpe gitmesidir. Bu tarifte kullandığınız brokolinin saplarını atmayın; ince dilimleyip tepsiye sebzelerin yanına ekleyin, harika karamelize olurlar. Sosu kaplara önceden dökmemek de bir diğer kuraldır; sosu daima yiyeceğiniz an ekleyin ki sebzeleriniz dolapta beklerken formunu ve diriliğini kaybetmesin.

Category: Genel | LEAVE A COMMENT
Eylül 25 2026

Platform Mühendisliğinde Internal Developer Portal (IDP) Kurulumu: Backstage mi, Port mu?

Modern Platform Engineering pratiklerinin merkezinde tek bir nihai hedef var: Kognitif yükü azaltıp Developer Experience (DevX) çıtasını yukarı çekmek. Ancak bir sabah uyanıp “Hadi şirkete bir IDP kuralım” dediğinizde, DevOps dünyasının en büyük iki kutbu önünüze dikiliyor: Açık kaynak kodlu, Spotify kökenli Backstage ve SaaS/API-first yaklaşımıyla son dönemin parlayan yıldızı Port. Bu iki aracın broşür vaatlerini bir kenara bırakıp üretim ortamındaki gerçek maliyetlerine, mimari esnekliklerine ve Day-2 operasyonlarına bakalım.

SlackOps’tan Self-Service’e: Neden Bir IDP’ye İhtiyacımız Var?

Kabul edelim, şirket içinde yazdığınız bash script’leri, Terraform modülleri ve “production-hazır” Helm chart’ları harika çalışıyor olabilir. Fakat yazılımcı yeni bir microservice açmak için hâlâ Slack kanalından “#devops-help bana yeni bir Redis açar mısınız?” yazıyorsa, ortada bir platform değil, sadece insan gücüyle çalışan bir bilet kuyruğu vardır. IDP; Golden Path (Altın Yol) felsefesini somutlaştıran, altyapı yetkilendirmesini ve servis kataloğunu tek bir panele toplayan arayüzdür.

1. Spotify Backstage: Kodun Gücü ve Bakımın Laneti

Backstage bir ürün değildir; bir framework’tür. TypeScript ve React ile yazılmış bir monorepo iskeletidir. Kurulumu yaptığınız an elinizde bitmiş bir portal değil, sizin geliştirmeniz gereken bir yazılım projesi olur.

Backstage Mimarisi ve Plugin Ekosistemi

Backstage’in en büyük artısı, limitsiz özelleştirilebilmesidir. Şirket içi legacy bir LDAP sisteminiz veya kurum içi custom bir deployment engine’iniz varsa, Backstage içine plugin yazarak entegre edemeyeceğiniz hiçbir şey yoktur. Servislerinizi catalog-info.yaml dosyalarıyla declarative olarak tanımlarsınız:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-gateway-service
  description: Core payment processing engine
  annotations:
    github.com/project-slug: acme-corp/payment-gateway
    backstage.io/techdocs-ref: dir:.
    argocd/app-name: payment-gateway-prod
    prometheus.io/rule: alert_payment_latency
spec:
  type: service
  lifecycle: production
  owner: payments-team
  system: core-banking
  providesApis:
    - payment-api
  dependsOn:
    - resource:default/payment-postgres-db

Yazılım Şablonları (Software Templates) ile Self-Service

Backstage Scaffolder, geliştiricinin parametreleri girdiği ve arka planda bir Git repo’su oluşturup ilk commit’i attığı şablon mekanizmasıdır:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: go-service-template
  title: Go Microservice (Golden Path)
spec:
  owner: platform-core
  type: service
  parameters:
    - title: Servis Konfigürasyonu
      required: [name, owner]
      properties:
        name:
          type: string
          description: Servis adı (kebab-case)
        owner:
          type: string
          ui:field: OwnerPicker
  steps:
    - id: template
      name: Dosyaları Hazırla
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      name: GitHub Reposu Aç
      action: publish:github
      input:
        allowedHosts: ['github.com']
        description: Service created via Backstage
        repoUrl: github.com?owner=acme-corp&repo=${{ parameters.name }}
        defaultBranch: main

Neden Can Sıkar?

  • Node.js Dependency Cehennemi: Her yarn upgrade çalıştırdığınızda core plugin’lerin kırılma ihtimali çok yüksektir.
  • Frontend Eforu: Platform ekibinde React ve modern frontend toolchain’lerine hakim mühendis yoksa, arayüz geliştirmeleri kabusa dönüşür.
  • State ve DB Yönetimi: Catalog senkronizasyonu için PostgreSQL tutmanız, cache stratejilerini (Redis) yönetmeniz ve auth mekanizmalarını tek tek implemente etmeniz gerekir.

2. Port (getport.io): Data-Model First ve Low-Code IDP

Port, Backstage’in tam zıddı bir felsefeyle gelir: “Siz platform mühendisisiniz, frontend geliştiricisi değilsiniz.” Port bir SaaS veya Control-Plane-Only çözümüdür. UI tarafında tek satır kod yazmazsınız; her şey Blueprints (Veri Modelleri) ve Actions (Eylemler) üzerinden kurgulanır.

Entity ve Blueprint Mantığı

Port’ta altyapınızı bir Graph Database gibi modelllersiniz. Bir Kubernetes Cluster’ı, bir Microservice’e; o Microservice, bir RDS instance’ına ve bir PagerDuty On-Call rotasyonuna bağlanabilir.

Bu modeli Terraform ile Infrastructure as Code (IaC) prensibine uygun şekilde yönetebilirsiniz:

# Port Terraform Provider ile Blueprint tanımı
resource "port_blueprint" "microservice" {
  title      = "Microservice"
  icon       = "Microservice"
  identifier = "microservice"
  properties = {
    string_props = {
      "language" = {
        title = "Language"
        enum  = ["Go", "NodeJS", "Python"]
      }
      "slack_channel" = {
        title = "Slack Channel"
      }
    }
  }
}

resource "port_action" "scaffold_service" {
  title       = "Scaffold New Microservice"
  icon        = "Github"
  identifier  = "create_microservice"
  blueprint   = port_blueprint.microservice.identifier
  trigger_type = "self-service"

  user_inputs = {
    string_props = {
      "service_name" = {
        title = "Service Name"
      }
    }
  }

  backend_invocation = {
    type = "github"
    org  = "acme-corp"
    repo = "platform-scaffolder-workflows"
    workflow = "scaffold.yaml"
  }
}

Kubernetes ve CI/CD Entegrasyonu: Port Exporter

Backstage katalog için repo taraması (polling) yaparken, Port event-driven çalışır. Cluster’ınıza kurduğunuz bir exporter agent, kaynakları dinamik olarak Port paneline push eder:

helm repo add port-labs https://port-labs.github.io/helm-charts
helm repo update

helm install port-k8s-exporter port-labs/port-k8s-exporter \
  --set port.clientId="YOUR_CLIENT_ID" \
  --set port.clientSecret="YOUR_CLIENT_SECRET" \
  --values values.yaml

Burada values.yaml içinde basit JQ mapping’leri tanımlayarak Kubernetes CRD’lerinizi doğrudan UI component’lerine dönüştürebilirsiniz. Sıfır React, sıfır TypeScript.

Derin Kıyaslama: Hangi Senaryoda Hangisi?

1. Bakım Maliyeti (Total Cost of Ownership)

Backstage açık kaynak ve “bedava” gibi görünse de en az 1-2 platform mühendisinin tam zamanlı mesaisini tüketir. Güvenlik yamaları, TypeScript bağımlılıkları ve plugin güncellemeleri ciddi bir yüktür. Port ise SaaS lisanslama maliyetine sahiptir ancak kurulumu günler içinde tamamlanıp minimum eforla ayakta tutulur.

2. Esneklik ve Kurumsal Uyum

Kurum içi compliance politikalarınız multi-tenant SaaS kullanımına izin vermiyorsa, air-gapped ortamlarda çalışıyorsanız veya tamamen şirketinizin UI design system’ına (örneğin kurumsal Material UI teması) gömülmüş bir portal istiyorsanız Backstage tek seçenektir. Port hibrit çalışabilir (self-hosted exporter ve runner modelleriyle verinizi içeride tutabilir) ancak UI kontrolü her zaman onlardadır.

3. Self-Service Workflow Tetikleme

Backstage, kendi Scaffolder motoruna güvenir. Node.js backend’i üzerinde repo klonlar, commit atar ve PR açar. Port ise orkestrasyonu var olan araçlarınıza devreder: GitHub Actions, GitLab CI, Argo Workflows veya doğrudan bir Webhook. DevOps mühendisi için Port’un bu yaklaşımı çok daha doğaldır çünkü CI pipeline’ı yazmak, Scaffolder Action yazmaktan katbekat daha hızlıdır.

Karar Ağacı

Mimarinize karar verirken şu kontrol listesini uygulayabilirsiniz:

  • Ekip Büyüklüğü: 150+ yazılımcınız ve sadece portal geliştirmeye adanmış 3+ kişilik bir Platform Engineering ekibiniz varsa: Backstage.
  • Hızlı Değer Üretimi (Time-to-Value): 20-100 kişilik yazılımcı grubuna hizmet veren yalın bir DevOps ekibiyseniz ve iki hafta içinde bir katalog + self-service portal istiyorsanız: Port.
  • Arayüz İhtiyacı: “Bize standart bir dashboard yetmez, production tracing ve billing verilerini custom canvas grafikleriyle basacağız” diyorsanız: Backstage.
  • IaC ve GitOps Entegrasyonu: Portalı da Terraform ile yönetip altyapı state’i gibi kontrol etmek istiyorsanız: Port.

Özet

Platform Mühendisliğinin amacı yeni bir monorepo yazılım bakım yükü yaratmak değil, yazılım ekiplerinin önündeki altyapı bariyerlerini kaldırmaktır. Eğer bir yazılım eviyseniz ve temel yetkinliğiniz portal geliştirmek değilse, Port gibi modern platformlar operasyonel yükü minimize etmek için daha rasyoneldir. Ancak regülasyonların boğduğu, UI üzerinde tam egemenlik isteyen devasa bir kurumsal yapıdaysanız, Backstage’in getirdiği bakım yükünü göze alıp kendi iç ürününüzü inşa etmek doğru yoldur.

Category: Genel | LEAVE A COMMENT
Eylül 25 2026

Mutfakta Verimlilik: Batch Cooking ile Haftalık Yemek Hazırlığında ‘State’ Yönetimi

Saat akşam sekiz. Monitörün mavi ışığından yeni ayrılmışsın, zihninde günün yorgunluğu ve kafanda sonsuz bir döngüye giren o meşhur soru: “Bu akşam ne yesem?” İşte tam bu noktada modern yazılım mimarisinin en sevilen konseptini tezgâha taşıyoruz: batch cooking. Doğru bir yemek planlama ve mutfak yönetimi ile haftanın her günü mutfakta saatler harcamadan gurme gibi beslenmek mümkün.

Yazılımda “state” (durum), uygulamanın belirli bir andaki verisini temsil eder. Mutfakta da durum farksızdır. Çoğu insanın düştüğü hata, pazar günü beş ayrı tencere yemek yapıp perşembe günü o artık formunu kaybetmiş sulu yemeği yemeye çalışmaktır. Bu monolitik bir yaklaşımdır ve sürdürülemez. Biz mutfağı mikroservislere böleceğiz: Modüler bileşenler hazırlayacak, hafta boyunca bu bileşenlerin “state”ini değiştirerek taze tabaklar çıkaracağız.

Temel Modül: Fırınlanmış Protein ve Kök Sebze Matrisi

Haftalık zaman yönetimi hedeflerimizi tutturacak, 3 farklı yemeğe dönüşebilen baz tarifimizle başlayalım.

Porsiyon: 4-6 porsiyon
Hazırlık Süresi: 20 dakika
Pişirme Süresi: 35 dakika

Gerekli Malzemeler

  • 800 g tavuk göğsü (veya bitkisel alternatif için 2 blok sıkı tofu ya da 2 su bardağı haşlanmış nohut)
  • 2 adet tatlı patates (veya yerli sarı patates / balkabağı)
  • 1 adet büyük boy brokoli veya karnabahar
  • 2 adet havuç
  • 1 su bardağı kinoa (veya basmati pirinç, karabuğday)
  • 3 yemek kaşığı zeytinyağı
  • 1 tatlı kaşığı toz sarımsak, 1 tatlı kaşığı tütsülenmiş kırmızı biber, tuz ve karabiber
  • Joker Sos: 3 yemek kaşığı tahin, yarım limonun suyu, 2 yemek kaşığı ılık su, bir çimdik tuz.

Adım Adım Hazırlanışı

  1. Fırını önceden 200°C’ye ısıtın ve geniş bir fırın tepsisine pişirme kâğıdı serin.
  2. Tatlı patatesleri ve havuçları küp küp, brokoliyi lokmalık çiçekler halinde doğrayın. Sebzeleri tek bir kapta 1.5 yemek kaşığı zeytinyağı, tuz ve karabiberle harmanlayıp tepsinin bir yarısına yayın.
  3. Protein kaynağınızı (tavuk veya tofu) lokmalık kesin; kalan zeytinyağı, sarımsak tozu ve tütsülenmiş biberle karıştırıp tepsinin diğer yarısına yerleştirin.
  4. Tepsiyi fırına verip sebzeler karamelize olana, tavuklar tamamen pişene kadar yaklaşık 30-35 dakika pişirin.
  5. Fırın çalışırken kinoayı paket talimatına göre (1’e 2 ölçü suyla) 15 dakika haşlayın ve demlenmeye bırakın.
  6. Tahini, limon suyu ve ılık suyla pürüzsüz kıvam alana dek çırparak kenara alın.

State Yönetimi: Bu Tabanla Hafta İçi Neler Yapılır?

Bileşenler piştiğinde mutfağınızda üç ana “state” bulunur: Karbonhidrat (kinoa), lif/sebze ve protein. Bunları asla tek bir kapta karıştırmayın; ayrı cam saklama kaplarına paylaştırın. Hafta içi geçişleri şöyle yapıyoruz:

  • State 1 (Pazartesi – Akdeniz Bowl): Isıttığınız kinoa, sebze ve proteini kâseye alın. Üzerine hazırladığınız tahin sosu gezdirin. 3 dakikada taze bir akşam yemeği.
  • State 2 (Salı – Pratik Wrap): Hazır lavaşın içine soğuk tavuk/tofu dilimlerini, fırın sebzeleri ve taze marul ekleyin. İster tavada hafifçe çevirin, ister soğuk tüketin.
  • State 3 (Çarşamba – Hızlı Asya Çıtırı): Bir tavaya azıcık susam yağı ve soya sosu dökün; fırınlanmış sebze ve kinoayı yüksek ateşte 2 dakika soteleyip çıtır bir “fried rice” elde edin.

Püf Noktası

Kritik kural: Nem, tazeliğin düşmanıdır. Pişirdiğiniz hiçbir malzemeyi tamamen soğumadan kapaklı kaplara koymayın. Buhar içeride hapsolursa sebzeler lapa haline gelir ve raf ömrü yarıya iner. Ayrıca taze yeşillikleri ve sosları her zaman tüketim anında ekleyin (just-in-time rendering mantığı!).

Neden Bu Yöntem Kazandırır?

Hafta içi enerjinizin en düşük olduğu anlarda karar verme mekanizmanızı devreden çıkarırsınız. Sağlıksız dışarı siparişleri tarihe karışırken, mutfakta geçirdiğiniz toplam süreyi haftalık bazda neredeyse yüzde yetmiş oranında optimize edersiniz. Mutfak yönetimi bir yetenek değil, doğru kurulmuş bir operasyonel akıştır.

Category: Genel | LEAVE A COMMENT