Hüseyin Küçük's hkucuk Blog RSS Feed

Şef Olmayan Müzisyen, Yapay Zeka Çağında Kaybolur

Thu, 02 Apr 2026 00:00:00 GMT

Yazılım geliştirme uzun yıllar boyunca büyük ölçüde kodlama ile özdeşleşti. Sprint planlamaları kodlama görevleri etrafında şekillendi, ekip büyüklükleri kod üretim kapasitesine göre hesaplandı, kariyer yolları çoğunlukla “daha iyi kod yazan mühendis” hedefiyle çizildi. Oysa yazılım geliştirme hiçbir zaman salt kodlamadan ibaret değildi. Analiz, mimari tasarım, test, devreye alma. Bunlar aynı döngünün eşit derecede kritik parçalarıydı.

Ama bunu söylemek kolaydı, kabul ettirmek zordu. Çünkü yıllarca kodlama, bu döngünün en görünür ve en ölçülebilir parçasıydı. Kaç satır yazıldı, kaç ticket kapandı, sprint velocity ne oldu. Sistemin geri kalanı; problemi doğru tanımlamak, mimariyi doğru kurmak, kısıtları baştan belirlemek, hep arka planda olan şeyler sayıldı.

“Programcı mı, mühendis mi?” diye sorardım. İkisi aynı şey değil. Hiçbir zaman olmadı.

Ben bu sektörde on yedi yıldır, yapay zeka bu kadar gündemde değilken, çok önce, her fırsatta aynı şeyi söyledim: Sadece kod yazan biri olmayın. İyi analiz yapın, analizinize uygun mimariyi tasarlayın, problemi doğru tanımlamadan önce klavyeye dokunmayın. Gerçek bir mühendis olun.

Kodlamanın hızlanması neyi değiştiriyor?

Yapay zeka destekli araçlarla birlikte kodlama süreleri dramatik biçimde kısalıyor. Eskiden bir ekibin haftalar harcadığı bir modülün iskeleti artık saatler içinde çıkabiliyor. Bu hız artışı, yazılım geliştirme döngüsünün geri kalan aşamalarını daha görünür, daha belirleyici kılıyor.

Şöyle düşünün: Bir bina inşa ediyorsunuz. Eskiden tuğla örme en uzun aşamaydı. Bir makine geldi ve tuğlaları sizin yerinize çok hızlı örüyor. Ama temel yanlış atılmışsa, statik hesaplar tutarsızsa, makine yanlış yere çok hızlı tuğla örüyor demektir. Hız, yönün yerini alamaz.

Gerçek hayattan örnek
Bir e-ticaret şirketinde yeni bir ödeme akışı geliştiriliyor. Ekip gereksinim analizini yüzeysel bırakıp hızlıca kodlamaya geçiyor, yapay zeka da bu süreci hızlandırıyor. Altı hafta sonra ortaya çıkan sistem çalışıyor ama yanlış problemi çözüyor. Kullanıcıların asıl sorunu ödeme adımı değil, sepet yönetimi ekranındaki karmaşa. Hız burada düşmanınız oldu, daha hızlı yanlış üretti.

Doğru analiz başta yapılsaydı, yapay zeka o doğru mimariyi de aynı hızda kodlayabilirdi. Sonuç hem doğru hem de hızlı olurdu.

Değer nereye kayıyor?

Yazılım ekonomisinde değer, kodlama kapasitesinden analiz ve mimari yetkinliğine doğru kayıyor. Bu kayış kademeli değil, yapısal. Daha az mühendisle daha fazla ürün çıkarmak artık mümkün. Ama bu “daha az mühendis” ifadesi yanıltıcı. Aslında daha az kod yazma görevi var, daha fazla doğru şeyi inşa etme sorumluluğu var.

Doğru problemi tanımlamak, doğru teknolojiyi seçmek, sistemin nasıl ölçekleneceğini, nerede kırılacağını, hangi kısıtlar altında çalışacağını baştan belirlemek, bunlar her zaman asıl işin özüydü. Fark şu ki, artık bu adımları atlamanın bedeli çok daha hızlı ve çok daha ağır biçimde ortaya çıkıyor.

Mimari kararın ağırlığı
Bir startup, erken aşamada veri mimarisini monolitik kurdu. İlk iki yıl sorun olmadı. Ancak kullanıcı sayısı belirli bir eşiği geçince sistem çöktü ve servis dönüşümü için altı aylık bir teknik borç temizleme süreci başladı. Bu süreçte ürün geliştirme tamamen durdu, iki kritik müşteri ayrıldı.

Başta otuz dakika ayrılıp “bu sistem 100 bin kullanıcıda nasıl davranır?” sorusu sorulsaydı, mimari farklı kurulur, o altı ay kazanılırdı. Yapay zeka kodu hızla yazmış olabilirdi ama yanlış kararı daha hızlı yazmak sorunu çözmez, büyütür.

Mühendis artık bir orkestra şefi

İşte bu noktada yeni bir rol ortaya çıkıyor ve bu rol, benim on yıllardır tanımlamaya çalıştığım “gerçek mühendis” kavramıyla büyük ölçüde örtüşüyor. Artık mühendis, kodu bizzat yazan kişi değil; yapay zekayı yönlendiren, koordine eden ve çıktılarını değerlendiren kişi. Bir orkestra şefi gibi.

Orkestra şefi keman çalmak zorunda değildir. Ama hangi partinin ne zaman gireceğini, seslerin birbiriyle nasıl uyum içinde çalacağını, nerede tempo değişeceğini, bütünün nasıl bir anlam taşıyacağını bilmek zorundadır. Yapay zeka güçlü bir enstrüman. Ama enstrüman şefin olmadığı yerde gürültü üretir.

ORKESTRATÖR OLARAK MÜHENDİS - YENİ İŞ AKIŞI

Problemi tanımla ve sınırla

Ne inşa edilecek, neden inşa edilecek, hangi kısıtlar geçerli? Bu adım tamamen insana ait.

Mimariyi kur, kararları ver

Hangi servis, hangi veri modeli, hangi teknoloji yığını? Büyük kararlar burada alınır. Yapay zeka alternatifleri değerlendirmede yardımcı olabilir ama kararı veren mühendistir.

Yapay zekayı yönlendir

Doğru bağlamı, doğru kısıtları, doğru çıktı formatını tanımla. Belirsiz prompt, belirsiz kod üretir. Bu aşama bir mühendislik disiplini gerektiriyor.

Çıktıyı değerlendir ve doğrula

Üretilen kodu kör kabul etme. Mimariyle tutarlı mı? Edge case'ler ele alınmış mı? Güvenlik açığı var mı? Bu değerlendirme derin teknik bilgi olmadan yapılamaz.

İterasyonu yönet

Yapay zekayla çalışmak doğrusal değil döngüsel. Hangi parçanın yeniden üretilmesi, hangi kararın revize edilmesi gerektiğini görmek orkestratörün asıl işidir.

Orkestrasyon farkı
İki senior mühendis aynı yapay zeka aracıyla çalışıyor. Biri araca "kullanıcı kimlik doğrulama sistemi yaz" diyor. Diğeri şunu söylüyor: "Çok kiracılı SaaS mimarisi için JWT tabanlı bir kimlik doğrulama sistemi tasarla. Her kiracının izolasyonu kritik, audit log zorunlu, ileride SSO entegrasyonu ekleneceğini varsay." İkinci mühendis daha değerli ve daha kullanılabilir bir çıktı alıyor. Aradaki fark kodlama becerisi değil, analiz ve mimari netliği.

İletişim artık bir mühendislik becerisi

Hem yapay zekayı yönlendirmek hem de organizasyon içinde değer üretmek için başka bir beceri çok daha kritik hale geliyor, iletişim. Ve bunu sunum yapmak veya mail yazmak gibi dar anlamda ele almıyorum.

Bir ihtiyacı gerçekten anlamak için doğru soruları sorabilmek, paydaşların söylediklerinin arkasındaki asıl problemi çıkarabilmek, kurduğunuz mimariyi teknik olmayan bir yöneticiye de teknik bir ekibe de net biçimde aktarabilmek ve yapay zekaya vereceğiniz bağlamı tam, eksiksiz ve doğru biçimde ifade edebilmek. Bunlar artık olsa iyi olur değil, mühendisliğin olmazsa olmaz parçaları.

İletişimin teknik sonucu
Bir ekip, müşteri taleplerini işleyen yeni bir iş akışı geliştiriyor. Ürün müdürü "bildirimleri daha akıllı yapalım" diyor. İletişim becerisi zayıf mühendis bunu anlık bildirim optimizasyonu olarak yorumluyor ve bir hafta çalışıyor. İletişim becerisi güçlü mühendis ise üç soru soruyor: "Hangi kullanıcı segmenti için? Hangi kanalda? Başarı kriteri ne?" ve ortaya tamamen farklı bir spesifikasyon çıkıyor. İki yaklaşım arasındaki fark teknik değil, analitik ve iletişimsel.

Uzun yılların gözlemi değişmedi

Kariyerini yalnızca kod yazmak üzerine kurmuş mühendisler bu dönüşümü sancılı hissedebilir. Bu his anlaşılır ama yanlış bir yere odaklanıyor. Tehdit, yapay zekadan gelmiyor. Tehdit, yıllarca ertelenen dönüşümü artık erteleyemeyeceğimiz gerçeğinden geliyor.

Sistematik düşünme, problem analizi, mimari tasarım ve bunları net biçimde ifade edebilme yetkinliğiniz varsa bu dönem sizin için bir tehdit değil, değerinizin nihayet hak ettiği yere yükseldiği bir dönem. Yapay zeka iyi mühendisleri daha da güçlü kılıyor. Kötü mühendisleri ise yanlışta daha da hızlı yapıyor.

Yapay zeka kod yazmayı öğrendi. Ama neyi, neden, nasıl inşa edeceğini bilmek ve bu bilgiyi bir araca aktarabilecek netlikte ifade etmek hâlâ insanın işi.

Orkestra şefi olmak için önce müziği derinlemesine anlamak gerekir. Sistemi kim tasarlayacak, yapay zekayı kim yönlendirecek, çıktıyı kim değerlendirecek? Analiz yapabilen, mimari düşünebilen, iletişim kurabilen ve tüm bunları orkestre edebilen mühendis.

Ben bunu çok uzun zamandır söylüyordum. Şimdi söylememe gerek yok, yapay zekanın kendisi kanıtlıyor.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Çipler, Tartışmalar ve Minsky: AI'nın Perde Arkası

Mon, 05 Jan 2026 00:00:00 GMT

Entelektüel Ambargo ve Donanımın İdeolojik Kökenleri

Bugün yapay zeka, silikon vadilerinden cebimizdeki en küçük devreye kadar dünyayı kuşatmış durumda. Ancak bu hegemonya, 1970’lerde yaşanan ve Yapay Zeka Kışı olarak adlandırılan karanlık bir duraklama döneminin küllerinden doğdu. Bir teknoloji stratejisti perspektifiyle bakıldığında, 1970’lerdeki bu çöküş sadece bir şanssızlık değil, Marvin Minsky ve Seymour Papert gibi devlerin başını çektiği bir tür entelektüel ambargo sonucuydu. Günümüzde teknik birer kısaltma olarak kanıksadığımız CPU, GPU ve TPU terimleri, aslında on yıllar süren bu fikir savaşlarının, fon kesintilerinin ve mimari dogmaların somutlaşmış birer ürünüdür. Modern yapay zekayı anlamak için, sadece bugünün işlem güçlerine değil, bu güçlerin neden yarım asır boyunca baskılandığına bakmamız gerekiyor.

Yapay Zekanın Darth Vader’ı: Marvin Minsky

Marvin Minsky, teknoloji tarihinde genellikle yapay zeka kışını başlatan adam olarak, hatta bir tür Şeytan figürü gibi anılır. Robert Hecht-Nielsen’ın deyimiyle Minsky’nin kariyeri Darth Vader’a benzer; önce nöral ağların en büyük öncülerinden biri olarak başlamış, sonra gücün karanlık tarafına (Sembolik AI) geçerek kendi yarattığı topluluğun en amansız düşmanı olmuştur. İronik olan şudur ki; Minsky, 1951 yılında dünyanın ilk nörobilgisayarı olan SNARC’ı inşa eden kişidir. Vakum tüplerinden oluşan bu makine hakkında Minsky şöyle der:

Bu çılgın rastgele tasarım sayesinde, nasıl inşa ederseniz edin çalışacağından neredeyse emindik… O zamanlar yirmi tüplü bir radyo bile sık sık bozulurdu; biz makinemizi hiçbir zaman tam olarak hata ayıklamadık ama bu önemli değildi. (Bernstein, 1981)

Ancak Minsky zamanla brüt kuvvet (brute force) olarak gördüğü rastgele ağlardan uzaklaştı. Onun Society of Mind (Zihin Toplumu) felsefesi, zekanın devasa ve homojen bir ağ yerine, binlerce uzmanlaşmış ajandan oluşması gerektiğini savunuyordu. 2006 yılındaki AI@50 konferansında Terry Sejnowski’nin “Siz nöral ağ kışından sorumlu olan şeytan mısınız?” sorusuna, önce ağların matematiksel sınırlamaları üzerine bir tirat atarak direnmiş, ardından tarihe geçecek o itirafı bağırmıştır: “Evet, ben şeytanım!”

XOR Problemi: Bir Küçük Mantık Kapısının Ardındaki Büyük Yanılgı

1960’ların sonunda nöral ağ araştırmalarını durduran olay, basit bir XOR (Özel VEYA) mantık kapısıydı. Yaygın bilinenin aksine Minsky ve Papert, 1969 tarihli Perceptrons kitabında çok katmanlı ağların (MLP) bu problemi çözemeyeceğini iddia etmediler; onlar sadece tek katmanlı ağların (perceptron) matematiksel sınırlarını kesin çizgilerle belirlediler. Asıl sorun teknik bir imkansızlık değil, epistemolojik bir boşluktu. 1960’lardaki Bağlantıcı (Connectionist) kampının önündeki engeller şunlardı:

Backpropagation Eksikliği: Çok katmanlı ağları eğitecek geriye yayılım algoritması henüz keşfedilmemiş veya ölçeklenememişti.
Türevlenebilir Fonksiyonlar: O dönemde 0-1 tipi basamak fonksiyonları kullanılıyordu; oysa gradient descent için türevlenebilir aktivasyon fonksiyonları gerekiyordu.
Minsky’nin Matematiksel Kesinlik Tutkusu: Minsky, teorik temeli olmayan teorisiz veri ile yapılan deneyleri küçümsüyor, matematiksel olarak ispatlanamayan hiçbir mimariye fon verilmesini istemiyordu.

Donanım Savaşları: Davulcular, Askerler ve Dallanma Maliyeti

Stratejik açıdan donanım, sadece bir araç değil; fikirlerin hayatta kalmasını sağlayan bir ekosistemdir. CPU, GPU ve TPU arasındaki farkı bir orkestra metaforuyla analiz edebiliriz:

CPU (Merkezi İşlem Birimi): İnanılmaz hızlı, her türlü karmaşık notayı çalabilen bir solo davulcu gibidir. En büyük yeteneği dallanma (branching - if/else) kapasitesidir. Bilgisayarın beyni olarak kalmasının sebebi, karmaşık karar mekanizmalarını yönetebilmesidir.
GPU (Grafik İşlem Birimi): Bir askeri yürüyüşteki yüzlerce davulcu gibidir. Tek bir davulcu (çekirdek) CPU kadar zeki değildir ancak hepsi aynı anda aynı vuruşu yapar (SIMD - Tek Talimat Çoklu Veri). GPU’larda dallanma (if-else) yapmak çok pahalıdır; bu yüzden koşulsuz aritmetik ve matris çarpımlarında (derin öğrenme gibi) devleşirler.
TPU (Tensör İşlem Birimi): Google tarafından sadece matris matematiği (tensörler) için tasarlanmış özel bir donanımdır. Dallanma yeteneği neredeyse hiç yoktur, ancak matris işlemlerini GPU’dan bile daha verimli yönetir.

Ölçeklenme Hipotezi: Brüt Kuvvetin Zaferi

Minsky ve Papert, nöral ağların asla büyük ölçekli problemleri çözemeyeceğini, homojen mimarilerin karmaşık dünyayı anlayamayacağını savundular. Papert’in epistemolojik çoğulculuk inancı, tüm bilgiyi aynı potada eriten tek tip (uniform) mimarilere karşı felsefi bir nefret beslemesine neden oluyordu. Onlara göre bu hegemonic bir evrenselcilikti.

Tarih, bu iki dâhiyi en çok küçümsedikleri noktada haksız çıkardı: Brüt Kuvvet. Minsky’nin teorisiz veri olarak görüp dışladığı yöntemler, bugünün Transformer modellerinin kalbini oluşturuyor. Modern AI, Minsky’nin öngördüğü gibi zarif sembolik kurallarla değil; devasa verinin ve hesaplama gücünün (compute) yarattığı istatistiksel baskıyla kazandı.

Makine Öğrenmesi mi, Derin Öğrenme mi?

Zekros Mühendislik kaynaklarına ve endüstriyel uygulama verilerine göre, her yapay zeka problemi bir GPU canavarı gerektirmez. Stratejik seçim, verinin doğasında gizlidir:

Özellik	Makine Öğrenmesi (ML)	Derin Öğrenme (DL)
Veri İhtiyacı	Daha az (Tablosal veriler)	Çok fazla (Görüntü, Ses, Metin)
Özellik Çıkarımı	İnsan eliyle (Feature Eng.)	Otomatik (Nöral Ağlarca)
İşlem Gücü	Orta (CPU genellikle yeterli)	Yüksek (GPU/TPU zorunlu)
Kullanım Alanı	Kredi riski, Spam filtreleme	Otonom araçlar, Chatbotlar

Stratejik Not: Model başarısını ölçerken sadece Accuracy (Doğruluk) yeterli değildir. Yanlış alarm maliyetinin yüksek olduğu endüstriyel otomasyonda Precision (Kesinlik), bir siber saldırıyı kaçırmamanın kritik olduğu güvenlikte ise Recall (Duyarlılık) metriği hayati önem taşır.

Sonuç: Zihin Toplumu Yaşıyor mu?

Yapay zeka tarihi, fikirlerin donanımla imtihanıdır. Minsky’nin 1960’larda ölçeklenemez dediği bağlantıcı modeller, bugün milyarlarca parametreyle dünyayı simüle ediyor. Ancak burada bir ironi daha gizli: Minsky’nin Society of Mind (Zihin Toplumu) fikri, belki de bugün devasa homojen ağların içinde, farklı görevlerde uzmanlaşmış nöron grupları (MoE - Mixture of Experts gibi) şeklinde gizlice hayat buluyor.

Kapanışta kendimize şu vakur soruyu sormalıyız: Yapay zeka, evrenin karmaşık sembolik kurallarını gerçekten kendi kendine mi öğreniyor, yoksa biz sadece devasa bir hesap makinesinin sunduğu istatistiksel yansımalara mı hayran kalıyoruz? Belki de Minsky haklıydı; belki de biz sadece uygulamalarla uğraşıyoruz ve gerçek genel zekanın kapısı hala kilitli bekliyor.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

QUIC Protokolü ve HTTP/3: Taşıma Katmanında Devrim ve Uygulama Rehberi

Sat, 04 Oct 2025 00:00:00 GMT

QUIC, UDP üzerinde çalışan, TLS 1.3 ile entegre, çok akışlı (multiplexed) ve göç edebilir (connection migration) bir taşıma protokolüdür. HTTP/3 doğrudan QUIC üzerinde çalışır. QUIC; TCP+TLS’in el sıkışma gecikmesini azaltır, HTTP/2’nin TCP-temelli head-of-line blocking sorununu ortadan kaldırır, adres doğrulama ve anti-amplification gibi güvenlik önlemlerini çekirdek tasarımına gömer ve uzantılarla düşük gecikimli uygulamalara kapı açar. Bu makalede QUIC’in motivasyonu, çalışma ilkeleri, kabiliyetleri, HTTP/3 ile ilişkisi, yönetilebilirlik ve ölçülebilirlik boyutu, avantaj/dezavantajları, TCP/HTTP2/SCTP gibi alternatiflerle karşılaştırması ve GoLang ile pratik kod örnekleri yer almaktadır.

1. Neden QUIC?

TCP + TLS + HTTP/2’nin bedeli:

El sıkışma gecikmesi: TCP üç yönlü el sıkışma + TLS el sıkışması tipik olarak 1–2 RTT gecikme ekler. QUIC, TLS 1.3’ü taşıma katına entegre ederek ilk bağlantıyı çoğu durumda tek RTT’de tamamlar; yeniden bağlantıda 0-RTT ile uygulama verisini hemen gönderebilir.
HOL Blocking: HTTP/2 birden fazla isteği tek bir TCP akışında çoklar; tek bir TCP segmentindeki kayıp, o TCP akışındaki tüm HTTP/2 akışlarını bekletir. QUIC’te her uygulama akışı (stream) bağımsızdır; tek akıştaki kayıp diğerlerini durdurmaz.
Orta nokta sertleşmesi (ossification): TCP’nin açık tel görüntüsü (wire image) ağ cihazlarının, yeni özellikleri zorlaştıran kestirimci davranışlar geliştirmesine yol açtı. QUIC; sürümlemenin kendisini ve sürüm-bağımsız invariyantları tanımlayarak değişime alan bırakır; ayrıca QUIC v2 neredeyse v1 ile aynı olup sadece “fiziksel görünüş” değişiklikleriyle ağdaki sertleşmeye karşı alıştırma yapar.

Operasyonel gereksinimler: Şifrelemenin varsayılan oluşu, bağlantı göçü, path doğrulaması, NAT yeniden bağlama dayanıklılığı ve genişletilebilirlik modern web ve mobil uygulamaların gereksinimlerini karşılar.

2. Mimari Öz: UDP Üzerinde Güvenli, Çok Akışlı, Sürümlemeli

QUIC, UDP üzerinde çalışan bir taşıma protokolüdür; paket başlıkları ve çerçevelemeyi kendi tanımlar, kayıp tespiti ve tıkanıklık kontrolü gibi TCP’de çekirdekte olan işlevleri kullanıcı alanına taşır. Bu mimari, protokol evrimini hızlandırır (güncelleme/deploy kolaylığı) ve Connection ID (CID) kullanımı sayesinde NAT arkasında veya IP/port değişimlerinde bağlantı göçünü mümkün kılar. CID’ler, akışları uçtan uca korurken orta noktalarda yük dengelemeyi de kolaylaştırır; tel görüntüsünde yalnızca gerekli minimum sinyaller görünür, geri kalanı şifrelenir.

TLS 1.3, QUIC’in içine entegredir; el sıkışma, kimlik doğrulama ve anahtar üretimi taşıma katmanının parçası olarak gerçekleşir. İlk kurulum genellikle 1-RTT’de tamamlanır; oturum yeniden başlatmada 0-RTT ile (yeniden oynatma riskleri gözetilerek) uygulama verisine erken başlanabilir. Sunucu, anti-amplification ve Retry gibi mekanizmalarla istemci adresini doğrular; uzun ömürlü oturumlarda anahtar güncelleme akışı gizliliği güçlendirir. Uygulama protokolleri, ALPN üzerinden QUIC üzerinde hangi protokolün (örn. h3) konuşulacağını ilan eder.

Veri taşıma akış (stream) soyutlamasıyla yapılır: çift yönlü veya tek yönlü akışlar, hem akış düzeyi hem de bağlantı düzeyi akış kontrolüne tabidir. Her akış bağımsız ilerlediğinden tek bir kayıp diğer akışları durdurmaz; bu, HTTP/2’nin TCP kaynaklı head-of-line blocking sorununu ortadan kaldırır. Güvenilir aktarım gerektiren içerikler akışlarla taşınırken, QUIC DATAGRAM çerçevesi güvenilmez ama şifreli ve tıkanıklık kontrolüne tabi en iyi çaba (best-effort) iletim sağlar; medya/telemetri gibi gecikmeye duyarlı uygulamalar için uygundur.

Paket düzeyinde QUIC, Initial, Handshake, 0-RTT ve 1-RTT gibi farklı paket türleri ve bunlara karşılık gelen ayrı paket numarası uzayları kullanır; her uzayın ACK’leri ve zamanlayıcıları bağımsızdır. Bu ayrım, el sıkışma/kriptografik aşamaların uygulama verisinden izolasyonunu sağlar ve kayıp tespitini sadeleştirir. Sürüm müzakeresi, uçların ortak QUIC sürümünü ek RTT ödemeden seçmesine izin verir; QUIC v2 ise esasen v1’in işlevsel eşleniği olup tel görünüşünü farklılaştırarak orta nokta sertleşmesine karşı çeşitlilik yaratır ve gelecekteki protokol evrimine alan açar.

UDP taşıyıcı, QUIC taşıma: QUIC, UDP datagramlarına kendi başlık ve çerçevelemelerini koyar; kayıp tespiti ve tıkanıklık kontrolü QUIC katmanındadır.
TLS 1.3 entegre: El sıkışma, kimlik doğrulama ve anahtar üretimi QUIC içinde gerçekleşir; 1-RTT (ilk kurulum), 0-RTT (yeniden başlatma) desteklenir.
Akışlar (Streams): İki yönlü/tek yönlü akışlar, akış ve bağlantı düzeyi akış kontrolü ile yönetilir. Bir akıştaki yeniden iletim diğer akışları bekletmez.
Paket türleri ve numara alanları: Initial, Handshake, 0-RTT ve 1-RTT paketleri; packet number space’leri ayrıdır.
Sürüm Müzakeresi ve QUIC v2: Uyumlu sürüm müzakeresi ile ekstra RTT ödenmeden tarafların ortak sürümü seçmeleri mümkün; QUIC v2 “görünüş” farklılıklarıyla çalışır.

3. Bağlantı Yaşam Döngüsü, Güvenlik ve Anti-Amplification

El sıkışma, QUIC’te TLS 1.3 ile bütünleşiktir: ilk bağlantı genellikle 1-RTT’de tamamlanır; yeniden bağlanmada 0-RTT “erken veri” ile uygulama yükünü el sıkışma bitmeden göndermeye izin verir. 0-RTT yalnızca önceki bir oturumdan alınan bilet/ticket ve parametrelerle mümkündür ve yeniden oynatma (replay) riskleri nedeniyle sunucu tarafında politika kısıtlarına tabidir (ör. idempotent GET dışındaki işlemleri reddetmek, kota koymak, belirli süre pencereleri uygulamak). El sıkışma sırasında ALPN ile üst protokol (ör. h3) seçilir; Handshake tamamlandığında 1-RTT anahtarları devreye girer ve veri akışı tam güvenli moda geçer.

Adres doğrulama ve anti-amplification ilkesi, yansıma/güçlendirme saldırılarına karşı çekirdek güvenlik önlemidir: sunucu, istemcinin adresi doğrulanana kadar aldığının en fazla 3 katı bayt gönderebilir. Adres doğrulaması iki şekilde yapılır: (i) daha önce doğrulanmış bir oturumda verilmiş NEW_TOKEN kullanımıyla sıfır ek gecikme; (ii) ilk kez bağlanan istemci için Retry paketi ile token temelli doğrulama (çoğu durumda +1 RTT maliyet). Bu aşamada büyük sertifika zincirleri veya gereksiz büyük ilk yanıtlar amplifikasyon sınırına takılabileceğinden, zinciri ve ilk veri boyutlarını optimize etmek pratikte önemlidir.

Bağlantı göçü (connection migration), Connection ID (CID)’ler sayesinde IP/port değiştiğinde dahi akışların sürmesini sağlar; mobil cihazın Wi-Fi → hücresel geçişinde uygulama kesilmez. Yeni yola geçildiğinde uç, PATH_CHALLENGE / PATH_RESPONSE ile yolun ulaşılabilirliğini doğrular; genellikle yeni yol için RTT/cwnd ölçümleri sıfırlanır ve güvenli başlangıç yapılır. NAT rebinding gibi kısa süreli uç değişimleri de bu mekanizmalarla tolere edilir. Hata durumunda, karşı tarafın sessizce yok olduğu senaryolarda Stateless Reset hızlı kapanmayı mümkün kılar; idle timeout ve draining durumları bağlantı yaşam döngüsünün diğer kapanış aşamalarıdır.

Uzun ömürlü akışlarda anahtar güncelleme (key update) periyodik olarak yapılabilir: uçlar, belirli miktar veri/packet sonrası yeni 1-RTT anahtarlarına geçerek kriptografik gizliliği güçlendirir ve olası anahtar sızması etkisini sınırlar. Standartlaştırma ekosisteminde Extended Key Update gibi öneriler, güncelleme davranışını daha incelikli hâle getirerek büyük veri akışlarında performans–güvenlik dengesini korumayı amaçlar. Böylece QUIC’in bağlantı yaşam döngüsü; hızlı el sıkışma, kontrollü amplifikasyon, yol doğrulaması ve düzenli anahtar yenilemeleri üzerinden hem güçlü güvenlik hem de pratik dayanıklılık sunar.

El sıkışma ve 0-RTT: İlk bağlantı genellikle 1-RTT’de tamamlanır; yeniden bağlanmada 0-RTT ile uygulama verisi el sıkışma tamamlanmadan gönderilebilir. 0-RTT’nin yeniden oynatma (replay) riskleri vardır; kimlik doğrulaması sonlamadan hassas işlem yapmayın.
Adres doğrulama ve anti-amplification limiti: Sunucu, istemci adresi doğrulanana kadar aldığı baytın en fazla 3 katı veri gönderebilir; bu, yansıma (reflection) ve güçlendirme saldırılarını sınırlar. Gerekirse Retry paketi ile token tabanlı doğrulama ister; bu ek RTT getirebilir.
Bağlantı göçü ve path doğrulaması: Bağlantı kimlikleri (CIDs) sayesinde IP/port değişse de akışlar devam eder; yeni yol PATH_CHALLENGE/RESPONSE ile doğrulanır.
Anahtar güncelleme: Uzun ömürlü bağlantılar için anahtar güncellemesi ve yeni “Extended Key Update” taslakları gündemdedir.

4. Kayıp Tespiti ve Tıkanıklık Kontrolü (RFC 9002)

QUIC’in kayıp tespiti, TCP’deki klasik RTO yaklaşımını modernize ederek Probe Timeout (PTO), ACK aralıkları (ACK ranges) ve gecikmeli ACK (ACK delay) kavramlarını bir araya getirir. Her paket ayrı bir packet number space (Initial/Handshake/1-RTT) içinde izlenir; böylece el sıkışma aşamasındaki belirsizlikler uygulama verisinden izole edilir. Alıcı, Selective ACK’e benzer biçimde hangi paket aralıklarını gördüğünü bildirir ve ölçtüğü ACK gecikmesini de raporlar; gönderen bu bilgiyi RTT kestirimi ve zamanlayıcılarını ayarlamak için kullanır. PTO, “zamanında yanıt gelmedi, ağ sessiz olabilir” sinyalidir; gönderene ek prob (araştırma) paketleri yollatır ve böylece gereksiz tam zaman aşımı beklemeleri azaltılır.

Kayıp kararı iki ana sezgiye dayanır: paket-eşiği (daha yeni N paket onaylandıysa eskisi muhtemelen kayıptır) ve zaman-eşiği (tahmini RTT penceresi aşıldıysa kayıp varsayılır). Bu ikili yaklaşım, hem yeniden sıralanma (reordering) hem de değişken gecikim koşullarında yanlış kayıp saptamalarını sınırlamayı hedefler. Uzun süreli kötüleşmeler için QUIC, kalıcı tıkanıklık (persistent congestion) durumunu tanımlar: belirli bir süre (PTO tabanlı bir eşik) boyunca gönderilen tüm “ACK uyandırıcı” paketler kayıp sayılırsa, tıkanıklığın ciddi olduğu kabul edilip daha agresif çakışma azaltma uygulanır.

Tıkanıklık kontrolü pluggable tasarlanmıştır; RFC 9002 algoritma seçimini dikte etmez, ancak pencereli algoritmalar için rehber metrikleri (örn. bytes-in-flight, pacing) ve başlangıç davranışlarını çizer. Pratikte başlangıç congestion window yaklaşık 10 paket mertebesindedir ve gönderenin pacing yapması (ani patlamaları önlemek için aralıklı gönderim) tavsiye edilir. Kaybın sinyali (ya da ECN işaretleri) alındığında yavaş başlatma dışına çıkılır ve congestion avoidance evresine geçilir; pencere büyümesi yavaşlatılır veya düşürülür. Bu sayede QUIC; yüksek bant genişlikli, yüksek gecikimli hatlarda dahi gereksiz dalgalanmayı sınırlarken iyi hatlarda hızla “açılabilir”.

Algoritma tarafında NewReno ve CUBIC en yaygın uygulanımlardır; BBR gibi akış-temelli yaklaşımlar da kullanıcı alanında rahatça denenebilir. Ayrıca QUIC, ağ destekliyorsa ECN sinyallerini tıkanıklık göstergesi olarak kullanabilir; bu, yalnızca kayba güvenmekten daha nazik bir tepkisellik sağlar. Uygulama açısından bakarsak: gecikmeye duyarlı medya/oyun trafiği için QUIC DATAGRAM + pacing iyi sonuç verirken; güvenilir aktarım gereken dosya/HTTP içerikleri akış (stream) üzerinde, seçilen tıkanıklık kontrolüyle tahmin edilebilir ve kararlı bir performans elde eder.

5. HTTP/3: QUIC Üzerinde HTTP

HTTP/3, HTTP semantiğini doğrudan QUIC akışlarına yerleştirir: her istek–yanıt çifti tek bir çift yönlü akış üzerinde taşınır; akışlar birbirinden bağımsız ilerlediği için tek bir kayıp ya da yeniden iletim diğer istekleri bekletmez. HTTP/3 ayrıca denetim (control) akışları kullanır: SETTINGS, GOAWAY ve benzeri çerçeveler bu tek yönlü kontrol akışlarında taşınır; istek akışlarının üzerine karışmaz. Bu yapı, HTTP/2’de TCP’nin tek bayt akışına bindirilmiş çoklamanın tetiklediği TCP kaynaklı head-of-line blocking sorununu kökten kaldırır.

Başlık sıkıştırması HTTP/3’te QPACK ile yapılır. QPACK, HTTP/2’deki HPACK’in “tek TCP akışında dinamik tablo güncellemesi → global HOL” problemine karşı tasarlanmıştır. Dinamik tablo güncellemeleri ve başlık başvuruları, ayrı encoder/decoder tek yönlü akışlarında mübadele edilir; istek akışları bu akışlardan bağımsız ilerler. Aynı zamanda “gerekli ekleme sayısı” gibi kısıtlayıcı işaretler sayesinde alıcı, henüz görmediği bir dinamik tablo girdisine takılıp bloklanmaz; pratikte yüksek kayıp ve yeniden sıralama içeren mobil ağlarda dahi başlık kod çözme akış bazında ilerler.

Önceliklendirme ve akış kontrolü, QUIC’in doğal yetenekleriyle birleşir. Uygulama; büyük gövdeli indirmeleri düşük, etkileşimli istekleri yüksek öncelikli işaretleyebilir; QUIC’in stream-level ve connection-level akış kontrolü, adil ve tahmin edilebilir kaynak kullanımını sağlar. Güvenilir veri (HEADERS/DATA) akışlar üzerinden giderken, HTTP Datagrams (H3 DATAGRAM) seçeneği, QUIC’in güvenilmez ama şifreli DATAGRAM çerçevesine bağlanır; medya, oyun telemetrisi veya tünelleme (ör. MASQUE/WebTransport tabanlı senaryolar) gibi kayıp-toleranslı trafiğe düşük gecikim sunar.

Dağıtım tarafında HTTP/3, Alt-Svc ile uçlara ilan edilerek kademeli benimsenir; istemci, aynı origin için h2/h1’e gerektiğinde geri dönebilir. QUIC’in 0-RTT özelliği, idempotent GET gibi güvenli işlemlerde el sıkışma tamamlanmadan isteğe başlama olanağı verir (yeniden oynatma riskleri nedeniyle sunucu politikalarıyla sınırlandırılır). “Server push” yeteneği standartta bulunsa da pratikte tarayıcı desteği ve kullanım kalıpları sınırlıdır; çoğu dağıtım, 103 Early Hints ve preload gibi mekanizmalarla benzer kazanımları elde eder. Böylece HTTP/3; bağımsız akışlar, QPACK ve QUIC’in modern taşıma özellikleriyle, web trafiğini daha tepki-hızlı, kararlı ve güçlü ağlarda ölçeklenir hale getirir.

6. Ölçülebilirlik ve Yönetilebilirlik: Spin Bit, Invariants

QUIC’in tel görüntüsü (wire image) büyük ölçüde şifrelenir; bu nedenle ara cihazların (NAT, yönlendirici, ölçüm kutuları) paket içeriklerinden ayrıntılı bilgi çıkarması amaçlı olarak zorlaştırılmıştır. Buna karşılık, protokolün invariants olarak adlandırılan ve sürümler arasında değişmeyecek şekilde tanımlanan bazı alanları (örn. “long/short header” ayrımı, sürüm alanının konumu, bağlantı kimliklerinin varlığı) görünür bırakılır. Bu sayede ağlar, bağlantı kimliği (CID) üzerinden yük dengeleme ya da akış yapışkanlığı gibi temel işlemleri, uçtan uca şifrelemeyi bozmayacak biçimde gerçekleştirebilir; aynı zamanda protokol evrimini engelleyen “orta nokta sertleşmesi”nin önüne geçilir.

Spin bit, uçların her RTT’de bir kez bit değerini “çevirerek” (toggle) gönderdiği, yalnızca yaklaşık RTT kestirimi için tasarlanmış, isteğe bağlı bir görünen alandır. Bir gözlem noktası, ardışık paketlerdeki bit değişimlerini izleyerek uçtan uca veya yön başına gecikim hakkında kaba bir tahmin yapabilir. Ancak spin bit, aktif veri akışı yokken, yoğun paket yeniden sıralaması/kaybı altında ya da bağlantı göçü sonrasında güvenilir ölçüm vermez; bant genişliği, kayıp oranı, uygulama seviyesi gecikim gibi metrikleri doğrudan vermez. Bu nedenle gizlilik ve parmak izi çıkarma risklerini azaltmak için uygulamalar spin bit’i örnekleme (sampling) ile açıp kapatabilir veya belirli oranlarda tamamen devre dışı bırakabilir.

Yönetilebilirlik açısından RFC 9312, pasif ölçümün sınırlı kaldığı ortamlarda uç iş birliğine dayalı yöntemleri önerir: örneğin qlog ile ayrıntılı olay kaydı, uçların sağladığı sayaç/metrik arabirimleri, ECN sayaçlarının raporlanması ve kontrol kanallarında asgari görünür sinyallerin korunması. Operasyon ekipleri için pratik hedef; “paket içeriğini görmeden” bile RTT eğilimleri, tıkanıklık belirtileri ve ulaşılabilirlik sorunları hakkında yeterli gözlem elde etmek, bunu da gizlilik ilkeleriyle dengede tutmaktır. Ayrıca CID rotasyonu ve bağlantı göçü gibi QUIC özelliklerinin, pasif korelasyonu zorlaştıracağı unutulmamalıdır; yük dengeleyicilerde CID tabanlı eşlemenin doğru yapılandırılması yönetimsel istikrar için kritik önemdedir.

Saha pratiği olarak: (i) Spin bit’i yalnızca tanılama/sorun giderme dönemlerinde veya istatistiksel örnekleme ile açmak; (ii) Kalıcı telemetri için qlog ve uç metrikleri gibi iş birliği gerektiren yöntemleri tercih etmek; (iii) Ölçümlerin yol değişimi, NAT yeniden bağlama ve farklı RTT’li çoklu erişim senaryolarında anlamını yitirebileceğini hesaba katmak önerilir. Böylece QUIC, hem gizliliği önceleyen tasarımını korur hem de işletmecilere yeterli gözlemlenebilirlik sağlayacak, sınırlı ama işe yarar araçlar sunar.

7. QUIC’in Avantajları

Düşük el sıkışma gecikmesi: 1-RTT kurulum, 0-RTT yeniden başlatma.
Akış bazında HOL Blocking yok: HTTP/3’te tek akıştaki kayıp diğer akışları durdurmaz.
Bağlantı göçü: Mobil senaryolarda IP/port değişse de bağlantı sürer.
Genişletilebilirlik: DATAGRAM, sürüm müzakeresi, QUIC v2.
Güvenlik varsayılan: TLS 1.3 zorunlu; anahtar güncelleme, anti-amplification, adres doğrulama.

8. Zorluklar ve Dezavantajlar

UDP engelleri / QoS: Bazı ağlar UDP’yi sınırlayabilir; firewall/NAT zaman aşımı ve MTU konuları dikkat ister.
Operasyonel görünürlük: Şifreli tel görüntüsü tanılama/ölçüm araçlarını zorlar; spin bit isteğe bağlıdır.
CPU maliyeti: Kullanıcı alanı tıkanıklık kontrolü ve AEAD şifreleme CPU’yu artırabilir; ancak modern uygulamalarda maliyet/performans dengesi genellikle olumludur.
Anti-amplification ve sertifika boyutu: 3× limiti ve büyük sertifika zincirleri ilk RTT’yi uzatabilir; zinciri optimize etmek önemlidir.

9. Diğer Protokollerle Karşılaştırma

TCP + TLS + HTTP/2: Geniş dağıtım olgunluğu yüksek; fakat HOL Blocking, yavaş başlatma ve çok akışı tek bytestream üzerinde taşımanın bedeli var. QUIC/HTTP/3 bu sınırlamaları hedefler.
SCTP (+ DTLS): Akış kavramı QUIC’e benzer; ancak dağıtım ve orta nokta uyumluluğu TCP kadar yaygın değildir. QUIC, UDP üzerinden, tarayıcı desteği ve HTTP/3 ile pratikte daha geniş ekosistem buldu.
MPTCP: Çok yol desteğini TCP düzeyinde sunar; QUIC’te bağlantı göçü yerleşik, multipath QUIC ise aktif standartlaşma alanıdır (taslak).

10. Go ile QUIC: quic-go ile “Ham” QUIC ve HTTP/3

Aşağıdaki örnekler quic-go API’sına uygundur. HTTP/3 için quic-go/http3 paketindeki ListenAndServeQUIC ve http3.Transport kullanılır. QUIC DATAGRAM API’sı EnableDatagram, SendDatagram ve ReceiveDatagram ile etkinleştirilir.

Not: Örnekler yerel geliştirme içindir. Sertifika üretimi için openssl veya mkcert ile server.crt/server.key hazırlayınız. Yerel denemede istemcide TLS doğrulamasını basitleştirmek için InsecureSkipVerify kullanılmıştır; production’da kullanmayınız.

10.1. Minimal QUIC Echo Sunucu (Streams)

/ go.mod
// module example.com/quic-echo
// go 1.22
// require github.com/quic-go/quic-go v0.55.0

// server.go
package main

import (
	"context"
	"crypto/tls"
	"fmt"
	"io"
	"log"
	"os"
	"os/signal"
	"syscall"

	"github.com/quic-go/quic-go"
)

func main() {
	// Load TLS certificate and key. For local testing, generate a self-signed cert.
	tlsConf, err := tlsConfig("server.crt", "server.key")
	if err != nil {
		log.Fatalf("failed to load TLS config: %v", err)
	}

	// Enable QUIC DATAGRAMs (optional) and allow 0-RTT resumption (server-side).
	quicConf := &quic.Config{
		EnableDatagram: true,
		Allow0RTT:      true,
	}

	addr := "localhost:4242"
	ln, err := quic.ListenAddr(addr, tlsConf, quicConf)
	if err != nil {
		log.Fatalf("listen failed: %v", err)
	}
	log.Printf("QUIC echo server listening on %s", addr)

	// Graceful shutdown on Ctrl+C.
	ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
	defer stop()

	go func() {
		<-ctx.Done()
		ln.Close() // closes the listener (accepted connections remain until closed)
	}()

	for {
		conn, err := ln.Accept(context.Background())
		if err != nil {
			if ctx.Err() != nil {
				log.Printf("shutting down listener...")
				return
			}
			log.Printf("accept error: %v", err)
			continue
		}
		log.Printf("accepted new QUIC connection from %s", conn.RemoteAddr())
		go handleConn(conn)
	}
}

func handleConn(conn quic.Connection) {
	defer conn.CloseWithError(0, "bye")

	// Optionally check whether DATAGRAMs were negotiated.
	cs := conn.ConnectionState()
	log.Printf("0-RTT used? %v, DATAGRAM supported? %v", cs.Used0RTT, cs.SupportsDatagrams)

	// Accept streams in a loop. Each stream is independent.
	for {
		str, err := conn.AcceptStream(context.Background())
		if err != nil {
			log.Printf("accept stream: %v", err)
			return
		}
		go echo(str)
	}
}

func echo(s quic.Stream) {
	defer s.Close()
	buf := make([]byte, 32*1024)
	for {
		n, err := s.Read(buf)
		if n > 0 {
			// Echo back the same payload.
			if _, werr := s.Write(buf[:n]); werr != nil {
				log.Printf("write error: %v", werr)
				return
			}
		}
		if err == io.EOF {
			return
		}
		if err != nil {
			log.Printf("read error: %v", err)
			return
		}
	}
}

func tlsConfig(certFile, keyFile string) (*tls.Config, error) {
	cert, err := tls.LoadX509KeyPair(certFile, keyFile)
	if err != nil {
		return nil, err
	}
	// Configure ALPN for your application if needed (e.g., "hq-interop").
	return &tls.Config{
		Certificates: []tls.Certificate{cert},
		// NextProtos can be customized. For raw-QUIC apps, pick an ALPN token.
		NextProtos: []string{"hq-example"},
	}, nil
}

// client.go
package main

import (
	"context"
	"crypto/tls"
	"fmt"
	"io"
	"log"
	"time"

	"github.com/quic-go/quic-go"
)

func main() {
	// WARNING: InsecureSkipVerify is ONLY for local testing!
	tlsConf := &tls.Config{
		InsecureSkipVerify: true,
		NextProtos:         []string{"hq-example"},
	}

	quicConf := &quic.Config{
		EnableDatagram: true,
	}

	ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
	defer cancel()

	addr := "localhost:4242"
	conn, err := quic.DialAddr(ctx, addr, tlsConf, quicConf)
	if err != nil {
		log.Fatalf("dial failed: %v", err)
	}
	defer conn.CloseWithError(0, "client done")

	// Open a bidirectional stream and send a message.
	stream, err := conn.OpenStream()
	if err != nil {
		log.Fatalf("open stream: %v", err)
	}
	defer stream.Close()

	msg := []byte("hello over QUIC streams")
	if _, err := stream.Write(msg); err != nil {
		log.Fatalf("write: %v", err)
	}

	// Read echo.
	reply := make([]byte, len(msg))
	if _, err := io.ReadFull(stream, reply); err != nil {
		log.Fatalf("read: %v", err)
	}
	fmt.Printf("echo reply: %q\n", string(reply))

	// Optionally try a DATAGRAM (best-effort, not retransmitted).
	if err := conn.SendDatagram([]byte("ping-dgram")); err == nil {
		// ReceiveDatagram blocks; in real apps, run this in a goroutine.
		ctx2, cancel2 := context.WithTimeout(context.Background(), time.Second)
		defer cancel2()
		if dg, err := conn.ReceiveDatagram(ctx2); err == nil {
			fmt.Printf("received datagram: %q\n", string(dg))
		}
	}
}

EnableDatagram ile RFC 9221 DATAGRAM uzantısı müzakere edilir (karşı taraf da desteklemeli). SendDatagram/ReceiveDatagram ile gönderilen veriler şifreli ve tıkanıklık kontrolüne tabi, ancak yeniden iletilmez.

10.2. Minimal HTTP/3 Sunucu ve İstemci

Sunucu:

// go.mod
// module example.com/h3
// go 1.22
// require github.com/quic-go/quic-go v0.55.0

package main

import (
	"crypto/tls"
	"fmt"
	"log"
	"net/http"

	"github.com/quic-go/quic-go"
	"github.com/quic-go/quic-go/http3"
)

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) {
		// You can detect 0-RTT by checking r.TLS.HandshakeComplete (server might have accepted request early).
		if r.TLS != nil && !r.TLS.HandshakeComplete {
			w.Header().Set("x-served-in-0rtt", "true")
		}
		fmt.Fprintln(w, "Hello over HTTP/3")
	})

	server := &http3.Server{
		Handler: mux,
		Addr:    ":4433",
		// Configure ALPN to "h3" and set QUIC options.
		TLSConfig:  http3.ConfigureTLSConfig(&tls.Config{Certificates: loadCert()}),
		QUICConfig: &quic.Config{EnableDatagram: true, Allow0RTT: true},
	}
	log.Printf("HTTP/3 server on https://localhost:4433/hello")
	log.Fatal(server.ListenAndServe())
}

func loadCert() []tls.Certificate {
	cert, err := tls.LoadX509KeyPair("server.crt", "server.key")
	if err != nil {
		panic(err)
	}
	return []tls.Certificate{cert}
}

İstemci:

package main

import (
	"crypto/tls"
	"fmt"
	"io"
	"log"
	"net/http"

	"github.com/quic-go/quic-go/http3"
)

func main() {
	// http3.Transport implements http.RoundTripper for HTTP/3.
	tr := &http3.Transport{
		TLSClientConfig: &tls.Config{
			InsecureSkipVerify: true,                // For local testing only
			NextProtos:         []string{http3.NextProtoH3}, // Set ALPN to "h3"
		},
	}
	defer tr.Close()

	c := &http.Client{Transport: tr}
	resp, err := c.Get("https://localhost:4433/hello")
	if err != nil {
		log.Fatal(err)
	}
	defer resp.Body.Close()
	b, _ := io.ReadAll(resp.Body)
	fmt.Printf("status=%s body=%q\n", resp.Status, string(b))
}

ListenAndServeQUIC / http3.Server ve istemci tarafında http3.Transport resmi dokümantasyonda bu şekilde kullanılır; TLSConfig için sunucuda http3.ConfigureTLSConfig kullanmak doğru ALPN’yi (h3) otomatik yerleştirir.

11. Uygulama İpuçları ve En İyi Pratikler

Sertifika zinciri boyutunu optimize edin: Anti-amplification nedeniyle ilk cevap boyutu 3× sınırına tabidir; büyük zincirler ek RTT doğurabilir.
ALPN ve QUIC sürüm desteği: HTTP/3 için h3 ALPN’si; sürüm müzakeresi için RFC 9368 desteği.
Datagram vs. Stream seçimi: Kayba toleranslı, düşük gecikim odaklı telemetri/oyun/medya için DATAGRAM; güvenilirlik şartsa stream.
Bağlantı göçü testleri: NAT rebinding / arayüz değişimlerini (Wi-Fi→LTE) sahada test edin; path doğrulaması ve CID rotasyonu önemlidir.
Gözlemlenebilirlik: qlog etkinleştirin; ops ekipleri için RFC 9312 rehberini izleyin.

El sıkışma uçuşunu küçük tutmak üretimde fark yaratır. Sertifika zincirini mümkün olduğunca kısaltın: gereksiz ara sertifikaları atın, aynı CA’nın birden çok zincirinden yalnızca en kısa olanı gönderin, OCSP stapling ve (mümkünse) TLS certificate compression kullanın. Büyük RSA zincirleri yerine eşdeğer güvenlikte ECDSA tercih etmek tipik olarak byte sayısını ciddi azaltır. Bu iyileştirmeler, sunucunun istemci doğrulanana kadar yalnızca aldığı baytın 3 katını gönderebildiği anti-amplification rejiminde ekstra RTT ödenmesini önler. İlk temasın hafiflemesi için session resumption, NEW_TOKEN dağıtımı ve Retry gereksinimini minimize eden topolojiler de pratikte etkilidir.

Protokol pazarlığı tarafında ALPN ve sürüm desteği uyumlu ilerlemeli. HTTP için h3’ü ilan ederken, istemcinin ve ara cihazların olgunluğu nedeniyle h2 geri dönüş yolunu açık tutun. Taşıma katında uyumlu sürüm müzakeresi desteği ve QUIC v1 + v2’yi birlikte sunmak, orta nokta sertleşmesine karşı dayanıklılığı artırır. Bu esnada yük dengeleyicilerin Connection ID (CID) temelli eşlemesi tutarlı olmalı; farklı uçlarda aynı origin için aynı TLS/QUIC parametreleri (idle timeout, max datagram size, TLS grupları) taşınmazsa sürüm/ALPN pazarlıklarında sürpriz uyumsuzluklar doğar.

Uygulama veri taşımasını doğru taşıma soyutlaması ile eşleyin: Stream’ler güvenilir, sıralı (ve gerektiğinde akış-bazlı akış kontrolüyle) içerikler için idealdir; tipik HTTP gövdeleri, API yanıtları, dosya parçaları burada taşınmalı. DATAGRAM, yeniden iletilmeyen ama şifreli ve tıkanıklık kontrolüne tabi “en iyi çaba” trafiğe uygundur: oyun telemetrisi, düşük gecikimli denetim mesajları, bazı medya/tünelleme senaryoları. Eğer uygulamanız DATAGRAM üzerinde “biraz güvenilirlik” istiyorsa, bunu uygulama katında hafif onaylama/yeniden gönderme ile yapın; aksi halde gereksinimleriniz aslında stream’e işaret ediyordur. Her iki durumda da MTU farkındalığına dikkat edin (DPLPMTUD varsa etkinleştirin); parçalanma, jitter ve kaybı büyütür.

Bağlantı göçü ve NAT rebinding sahada mutlaka test edilmeli. Cihazların Wi-Fi↔LTE geçişlerinde PATH_CHALLENGE/RESPONSE’un devreye girip akışların kesintisiz sürdüğünü, yeni yolda pencere/RTT’nin güvenli biçimde yeniden öğrenildiğini doğrulayın; düzenli CID rotasyonu yapılandırmasını ve yük dengeleyiciyle uyumunu kontrol edin. Gözlemlenebilirlik için üretimde qlog’u örnekleme (sampling) ile açın; PTO sayısı, 0-RTT kabul oranı, handshake başarısı, ortalama/percentile RTT, kayıp ve ECN/CE oranları gibi metrikleri izleyin. Sorun giderirken spin bit’i geçici ve sınırlı oranlarda kullanın; kalıcı telemetriyi ise qlog ve uç-taraf metrik arayüzleriyle sağlayın. Bu pratiklerle QUIC dağıtımınız hem hızlı açılır hem de operasyonel olarak öngörülebilir kalır.

QUIC, modern internet uygulamalarının beklentilerine uygun düşük gecikmeli, güvenli ve esnek bir taşıma katmanı sunar. HTTP/3’ün başarısı, QUIC’in akış izolasyonu, 0-RTT, bağlantı göçü ve genişletilebilirlik tasarımlarıyla yakından ilişkilidir. Operasyonel tarafta şifreli tel görüntüsü yeni ölçüm pratiklerini gerektirirken, standarta eklenen spin bit ve yönetilebilirlik rehberleri bu boşluğu doldurmaya çalışır. QUIC v2 ve sürüm müzakeresi, uzun vadede ossification’ı kırmayı hedefler. Uygulama geliştiricisi için quic-go gibi olgun kütüphanelerle ham QUIC ve HTTP/3 uygulamak artık oldukça erişilebilir durumdadır.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Raft Algoritması: Dağıtık Sistemlerde Basit ve Güvenilir Konsensus

Fri, 02 May 2025 00:00:00 GMT

Dağıtık sistemler, modern yazılım mimarisinin temelini oluşturur. Ancak birden fazla sunucunun aynı anda çalışması, veri tutarlılığını ve sistemin hata toleransını sağlamak gibi karmaşık zorlukları da beraberinde getirir. Bu zorlukların merkezinde “konsensus” problemi yatar: bir grup sunucunun, ağ kesintileri veya sunucu arızaları gibi aksaklıklara rağmen tek bir değer veya eylem üzerinde anlaşmaya varması. Bu makale, dağıtık sistemlerde konsensus sağlamak için tasarlanmış, basitliği ve güvenilirliğiyle öne çıkan Raft algoritmasını derinlemesine inceleyecektir.

Paxos Neden Karmaşıktı?

Raft’tan önce, dağıtık konsensus için fiili standart Paxos algoritmasıydı. Leslie Lamport tarafından 1970’lerde tanımlanan Paxos, teorik olarak sağlam ve hataya dayanıklı bir çözüm sunuyordu. Ancak, Paxos’un en büyük eleştirisi, anlaşılmasının ve doğru bir şekilde uygulanmasının son derece zor olmasıydı. Karmaşıklığı, geliştiricilerin onu benimsemesini ve genişletmesini engelliyordu, bu da alternatif arayışlarını tetikledi.

Raft’ın Temel Prensipleri ve Tasarım Felsefesi

Diego Ongaro ve John Ousterhout tarafından 2013 yılında tanıtılan Raft, Paxos’a daha anlaşılır bir alternatif olarak tasarlandı. Raft’ın birincil hedefi, mantığı ayırarak ve sunucuların tutarsız olabileceği yolları azaltarak anlaşılabilirliği artırmaktı.

Raft, “çoğaltılmış durum makineleri” (replicated state machines) kavramı üzerine kuruludur. Temel fikir, ayrı sunucuların belirli bir “şey” üzerinde, özellikle de bir log üzerinde anlaşmasını sağlamaktır. Bu log, sistemin durumunu değiştiren komutların bir kaydıdır. Tüm sunucular aynı komut dizisini aynı sırayla uyguladığında, hepsi aynı duruma ulaşır ve sistem tutarlı kalır.

Raft, konsensus problemini üç bağımsız alt probleme ayırarak bu anlaşılabilirliği sağlar:

Lider Seçimi (Leader Election): Mevcut liderin başarısız olması durumunda yeni bir liderin nasıl seçileceği.
Log Çoğaltma (Log Replication): Liderin istemci isteklerini nasıl kabul edeceği ve bunları diğer sunuculara nasıl çoğaltacağı.
Güvenlik (Safety): Sistemin hiçbir zaman tutarsız bir duruma düşmemesini sağlayan mekanizmalar.

Raft, bu alt problemlerin her birini açık ve ayrı kurallarla ele alarak, Paxos’un aksine “lider tabanlı” bir yaklaşım benimser. Kümede yalnızca bir lider seçilir ve bu lider, log çoğaltmayı yönetmekten tamamen sorumludur.

Raft’ın Bileşenleri ve Durumları

Raft kümesindeki her sunucu, herhangi bir zamanda üç durumdan birinde bulunur:

Lider (Leader): İstemci isteklerini kabul eden, log girişlerini yöneten ve bunları takipçilere çoğaltan merkezi otoritedir. Normal çalışmada kümede tam olarak bir lider bulunur.
Takipçi (Follower): Liderin log girişlerini çoğaltan ve liderden gelen isteklere yanıt veren pasif düğümlerdir.
Aday (Candidate): Liderin belirli bir süre içinde yanıt vermemesi durumunda liderlik için aday olan düğümlerdir.

Terimler (Terms)

Raft, zamanı “terimler” adı verilen ardışık tam sayılarla numaralandırılmış mantıksal zaman aralıklarına böler. Her terim bir seçimle başlar. Bir lider seçildiğinde, terim sona erene veya lider başarısız olana kadar sorumlu kalır. Terim numaraları, düğümlerin güncel bilgileri senkronize etmesine, çakışmaları çözmesine ve seçimleri koordine etmesine yardımcı olur.

RPC’ler (Remote Procedure Calls)

Raft, iletişim için iki ana Uzak Prosedür Çağrısı (RPC) türüne dayanır:

RequestVotes RPC: Adaylar tarafından seçimler sırasında diğer düğümlerden oy istemek için kullanılır.
AppendEntries RPC: Lider tarafından log girişlerini çoğaltmak ve takipçilere “kalp atışları” (heartbeat) göndermek için kullanılır. Kalp atışları, liderin varlığını düzenli olarak takipçilere bildirmesini sağlar.

Lider Seçimi

Tüm sunucular başlangıçta takipçi olarak başlar. Lider, takipçilere düzenli olarak kalp atışı mesajları göndererek yetkisini sürdürür. Her takipçinin, liderden kalp atışı beklediği bir zaman aşımı (genellikle 150 ila 300 ms arasında rastgele seçilir) vardır.

Eğer bir takipçi, zaman aşımı süresi içinde liderden bir kalp atışı almazsa, liderin başarısız olduğunu varsayar ve durumunu adaya değiştirir. Aday, mevcut terimini artırır, kendisine oy verir ve diğer tüm sunuculara RequestVote RPC’leri göndererek bir seçim başlatır.

Bir adayın seçimi kazanması için, kümedeki sunucuların çoğunluğundan aynı terim için oy alması gerekir. Çoğunluk kuralı, belirli bir terim için en fazla bir adayın seçimi kazanmasını sağlar. Her sunucu, belirli bir terimde en fazla bir adaya oy verir.

Seçimlerin üç olası sonucu vardır:

Lider Olma: Aday, kümenin çoğunluğundan oy alırsa lider olur ve yetkisini tesis etmek ve yeni seçimleri önlemek için tüm diğer sunuculara kalp atışı mesajları göndermeye başlar.
Takipçi Olma: Aday, yeni terimde başka bir sunucudan AppendEntries RPC’si (kalp atışı) alırsa, bu, başka bir liderin seçildiğini gösterir ve aday takipçi durumuna geri döner.
Sonuçsuz Kalma: Oylama bir bölünmeyle sonuçlanırsa (hiçbir aday çoğunluk oyu alamazsa), aday aday durumunda kalır, bir süre uyur (yine rastgele bir zaman aşımı) ve yeni bir oylama turu başlatır. Rastgele seçim zaman aşımları, bölünmüş oyların nadir olmasını ve hızlı bir şekilde çözülmesini sağlar.

Go ile Lider Seçimi Örneği (Basitleştirilmiş)

Aşağıdaki Go kodu, Raft sunucu durumlarını, log girişini ve RPC mesajlarını tanımlar. Lider seçim sürecini simüle eden basitleştirilmiş bir RequestVote RPC işleyicisini de içerir.

package main

import (
	"fmt"
	"math/rand"
	"sync"
	"time"
)

// ServerState represents the possible states of a Raft server.
type ServerState int

const (
	Follower ServerState = iota
	Candidate
	Leader
)

// LogEntry represents a single entry in the Raft log.
type LogEntry struct {
	Term    int    // Term when this entry was created
	Index   int    // Index of this entry in the log
	Command string // Command to be applied
}

// RequestVoteArgs represents the arguments for a RequestVote RPC.
type RequestVoteArgs struct {
	Term         int // Candidate's term
	CandidateID  int // Candidate's ID
	LastLogIndex int // Index of candidate's last log entry
	LastLogTerm  int // Term of candidate's last log entry
}

// RequestVoteReply represents the reply for a RequestVote RPC.
type RequestVoteReply struct {
	Term        int  // Current term of the receiver
	VoteGranted bool // Whether the candidate received vote
}

// AppendEntriesArgs represents the arguments for an AppendEntries RPC.
type AppendEntriesArgs struct {
	Term         int        // Leader's term
	LeaderID     int        // Leader's ID
	PrevLogIndex int        // Index of log entry immediately preceding new ones
	PrevLogTerm  int        // Term of PrevLogIndex entry
	Entries      []LogEntry // Log entries to store (empty for heartbeat)
	LeaderCommit int        // Leader's commitIndex
}

// AppendEntriesReply represents the reply for an AppendEntries RPC.
type AppendEntriesReply struct {
	Term    int  // Current term of the receiver
	Success bool // True if follower contained entry matching PrevLogIndex and PrevLogTerm
}

// RaftServer represents a single server implementing the Raft algorithm.
type RaftServer struct {
	ID          int
	State       ServerState
	CurrentTerm int
	VotedFor    int // CandidateID that received vote in current term

	Log []LogEntry // Replicated log

	CommitIndex int // Index of highest log entry known to be committed
	LastApplied int // Index of highest log entry applied to state machine

	// Volatile state for leaders
	NextIndex  []int // For each follower, index of the next log entry to send to that follower
	MatchIndex []int // For each follower, index of the highest log entry replicated on follower

	// For timeouts and communication
	ElectionTimeout time.Duration
	HeartbeatTimer  *time.Timer
	ElectionTimer   *time.Timer
	mu              sync.Mutex   // Mutex to protect server state
	peers           []*RaftServer // Other servers in the cluster (direct reference for simplicity)
}

// NewRaftServer creates a new Raft server.
func NewRaftServer(id int, peers []*RaftServer) *RaftServer {
	r := &RaftServer{
		ID:              id,
		State:           Follower,
		CurrentTerm:     0,
		VotedFor:        -1, // No vote yet
		Log:             []LogEntry{{Term: 0, Index: 0, Command: "init"}}, // Initial entry
		CommitIndex:     0,
		LastApplied:     0,
		ElectionTimeout: time.Duration(150+rand.Intn(150)) * time.Millisecond, // 150-300ms
		peers:           peers,
	}
	r.ElectionTimer = time.AfterFunc(r.ElectionTimeout, func() { r.startElection() })
	return r
}

// RequestVote processes a RequestVote RPC.
func (r *RaftServer) RequestVote(args RequestVoteArgs, reply *RequestVoteReply) {
	r.mu.Lock()
	defer r.mu.Unlock()

	reply.Term = r.CurrentTerm
	reply.VoteGranted = false

	// If candidate's term is older, reject vote.
	if args.Term < r.CurrentTerm {
		fmt.Printf("Server %d: Candidate %d's term (%d) is older than mine (%d). Vote rejected.\n", r.ID, args.CandidateID, args.Term, r.CurrentTerm)
		return
	}

	// If candidate's term is newer, update own term and become follower.
	if args.Term > r.CurrentTerm {
		r.CurrentTerm = args.Term
		r.State = Follower
		r.VotedFor = -1 // No vote yet in new term
		r.resetElectionTimer()
		fmt.Printf("Server %d: Candidate %d's term (%d) is newer than mine (%d). Became follower.\n", r.ID, args.CandidateID, args.Term, r.CurrentTerm)
	}

	// If haven't voted in this term (VotedFor is -1) or already voted for candidate,
	// and candidate's log is at least as up-to-date as mine, grant vote.
	if (r.VotedFor == -1 || r.VotedFor == args.CandidateID) && r.isLogUpToDate(args.LastLogIndex, args.LastLogTerm) {
		r.VotedFor = args.CandidateID
		reply.VoteGranted = true
		r.resetElectionTimer() // Reset timer after voting
		fmt.Printf("Server %d: Voted for candidate %d. (Term: %d)\n", r.ID, args.CandidateID, r.CurrentTerm)
	} else {
		fmt.Printf("Server %d: Did not vote for candidate %d. (VotedFor: %d, LogUpToDate: %t)\n", r.ID, args.CandidateID, r.VotedFor, r.isLogUpToDate(args.LastLogIndex, args.LastLogTerm))
	}
}

// isLogUpToDate checks if the candidate's log is at least as up-to-date as the receiver's log.
func (r *RaftServer) isLogUpToDate(candidateLastLogIndex int, candidateLastLogTerm int) bool {
	lastLogEntry := r.Log[len(r.Log)-1]
	if candidateLastLogTerm > lastLogEntry.Term {
		return true
	}
	if candidateLastLogTerm == lastLogEntry.Term && candidateLastLogIndex >= lastLogEntry.Index {
		return true
	}
	return false
}

// startElection simulates a server starting a leader election.
func (r *RaftServer) startElection() {
	r.mu.Lock()
	r.State = Candidate
	r.CurrentTerm++
	r.VotedFor = r.ID // Vote for self
	fmt.Printf("Server %d: Leader election started. New term: %d\n", r.ID, r.CurrentTerm)
	r.resetElectionTimer() // Reset election timer

	votesReceived := 1 // Our own vote
	lastLogEntry := r.Log[len(r.Log)-1]
	args := RequestVoteArgs{
		Term:         r.CurrentTerm,
		CandidateID:  r.ID,
		LastLogIndex: lastLogEntry.Index,
		LastLogTerm:  lastLogEntry.Term,
	}
	r.mu.Unlock()

	// Send vote requests to other servers
	for _, peer := range r.peers {
		if peer.ID == r.ID {
			continue
		}
		go func(p *RaftServer) {
			var reply RequestVoteReply
			// Direct RPC call for simplicity, would be over network in real-world
			p.RequestVote(args, &reply)

			r.mu.Lock()
			defer r.mu.Unlock()

			if r.State != Candidate || r.CurrentTerm != args.Term {
				// State changed or term changed, this vote is invalid.
				return
			}

			if reply.Term > r.CurrentTerm {
				// Discovered a newer term, become follower.
				r.CurrentTerm = reply.Term
				r.State = Follower
				r.VotedFor = -1
				r.resetElectionTimer()
				fmt.Printf("Server %d: Discovered newer term (%d), became follower.\n", r.ID, reply.Term)
				return
			}

			if reply.VoteGranted {
				votesReceived++
				fmt.Printf("Server %d: Received vote from candidate %d. Total votes: %d\n", r.ID, p.ID, votesReceived)
				if votesReceived > len(r.peers)/2 {
					// Received majority votes, become leader.
					r.State = Leader
					if r.HeartbeatTimer != nil {
						r.HeartbeatTimer.Stop() // Stop any previous heartbeat timer
					}
					r.HeartbeatTimer = time.AfterFunc(50*time.Millisecond, func() { r.sendHeartbeats() }) // Start heartbeats
					fmt.Printf("Server %d: Leader elected! (Term: %d)\n", r.ID, r.CurrentTerm)
					r.resetElectionTimer() // Reset timer as leader
					// Initialize nextIndex and matchIndex
					r.NextIndex = make([]int, len(r.peers))
					r.MatchIndex = make([]int, len(r.peers))
					for i := range r.peers {
						r.NextIndex[i] = len(r.Log)
						r.MatchIndex[i] = 0
					}
					return
				}
			}
		}(peer)
	}
}

// resetElectionTimer resets the election timer.
func (r *RaftServer) resetElectionTimer() {
	if r.ElectionTimer != nil {
		r.ElectionTimer.Stop()
	}
	r.ElectionTimer = time.AfterFunc(r.ElectionTimeout, func() { r.startElection() })
}

// sendHeartbeats simulates the leader sending heartbeats to followers.
func (r *RaftServer) sendHeartbeats() {
	r.mu.Lock()
	defer r.mu.Unlock()

	if r.State != Leader {
		return
	}

	fmt.Printf("Leader %d: Sending heartbeats (Term: %d).\n", r.ID, r.CurrentTerm)
	for i, peer := range r.peers {
		if peer.ID == r.ID {
			continue
		}
		go func(peerIndex int, p *RaftServer) {
			var reply AppendEntriesReply
			args := AppendEntriesArgs{
				Term:     r.CurrentTerm,
				LeaderID: r.ID,
				// Log entries are empty for heartbeats
				PrevLogIndex: len(r.Log) - 1,
				PrevLogTerm:  r.Log[len(r.Log)-1].Term,
				LeaderCommit: r.CommitIndex,
			}
			// If there are new entries to send
			if len(r.Log) > r.NextIndex[peerIndex] {
				args.Entries = r.Log[r.NextIndex[peerIndex]:]
				args.PrevLogIndex = r.NextIndex[peerIndex] - 1
				args.PrevLogTerm = r.Log[r.NextIndex[peerIndex]-1].Term
			}

			p.AppendEntries(args, &reply)

			r.mu.Lock()
			defer r.mu.Unlock()

			if r.State != Leader || r.CurrentTerm != args.Term {
				return // State changed or term changed
			}

			if reply.Term > r.CurrentTerm {
				r.CurrentTerm = reply.Term
				r.State = Follower
				r.VotedFor = -1
				r.resetElectionTimer()
				fmt.Printf("Leader %d: Discovered newer term (%d), became follower.\n", r.ID, reply.Term)
				return
			}

			if reply.Success {
				// Update nextIndex and matchIndex for this follower
				if len(args.Entries) > 0 {
					r.NextIndex[peerIndex] = args.PrevLogIndex + len(args.Entries) + 1
					r.MatchIndex[peerIndex] = r.NextIndex[peerIndex] - 1
				}
				// Check for commitment
				r.checkCommit()
			} else {
				// Decrement nextIndex and retry AppendEntries
				if r.NextIndex[peerIndex] > 1 {
					r.NextIndex[peerIndex]--
					fmt.Printf("Leader %d: AppendEntries failed for server %d. Decrementing nextIndex to %d.\n", r.ID, p.ID, r.NextIndex[peerIndex])
				}
				// Optionally, retry sending entries immediately
			}
		}(i, peer)
	}
	r.HeartbeatTimer = time.AfterFunc(50*time.Millisecond, func() { r.sendHeartbeats() }) // Regular heartbeats
}

// checkCommit attempts to advance the commitIndex based on replicated log entries.
func (r *RaftServer) checkCommit() {
	N := r.CommitIndex
	for i := len(r.Log) - 1; i > r.CommitIndex; i-- {
		if r.Log[i].Term == r.CurrentTerm {
			count := 1 // Count for self
			for j := range r.peers {
				if r.MatchIndex[j] >= i {
					count++
				}
			}
			if count > len(r.peers)/2 {
				N = i
				break
			}
		}
	}
	if N > r.CommitIndex {
		r.CommitIndex = N
		r.applyLogEntries()
	}
}

// AppendEntries processes an AppendEntries RPC.
func (r *RaftServer) AppendEntries(args AppendEntriesArgs, reply *AppendEntriesReply) {
	r.mu.Lock()
	defer r.mu.Unlock()

	reply.Term = r.CurrentTerm
	reply.Success = false

	if args.Term < r.CurrentTerm {
		fmt.Printf("Server %d: Leader's term (%d) is older than mine (%d). AppendEntries rejected.\n", r.ID, args.Term, r.CurrentTerm)
		return // Leader's term is older
	}

	if args.Term > r.CurrentTerm {
		r.CurrentTerm = args.Term
		r.State = Follower
		r.VotedFor = -1
		fmt.Printf("Server %d: Discovered newer term (%d) from leader, became follower.\n", r.ID, args.Term)
	}

	r.resetElectionTimer() // Received message from leader, reset timer

	// Log consistency check
	if args.PrevLogIndex >= len(r.Log) || r.Log[args.PrevLogIndex].Term != args.PrevLogTerm {
		fmt.Printf("Server %d: Log inconsistency. PrevLogIndex: %d, PrevLogTerm: %d. My log: %v\n", r.ID, args.PrevLogIndex, args.PrevLogTerm, r.Log)
		return
	}

	// Delete conflicting entries and append new ones
	newEntriesStartIndex := args.PrevLogIndex + 1
	if len(args.Entries) > 0 { // Only truncate if new entries exist to append
		if len(r.Log) > newEntriesStartIndex {
			r.Log = r.Log[:newEntriesStartIndex] // Truncate conflicting or subsequent entries
		}
		r.Log = append(r.Log, args.Entries...)
	}
	reply.Success = true

	// Update leader's commit index
	if args.LeaderCommit > r.CommitIndex {
		r.CommitIndex = min(args.LeaderCommit, len(r.Log)-1)
		r.applyLogEntries()
	}
}

// applyLogEntries applies committed log entries to the state machine.
func (r *RaftServer) applyLogEntries() {
	for r.LastApplied < r.CommitIndex {
		r.LastApplied++
		fmt.Printf("Server %d: Log entry applied: %s (Index: %d, Term: %d)\n", r.ID, r.Log[r.LastApplied].Command, r.Log[r.LastApplied].Index, r.Log[r.LastApplied].Term)
		// Here would be the actual state machine application
	}
}

func min(a, b int) int {
	if a < b {
		return a
	}
	return b
}

func main() {
	rand.Seed(time.Now().UnixNano())

	// Create a cluster of 3 servers
	servers := make([]*RaftServer, 3)
	for i := 0; i < 3; i++ {
		servers[i] = NewRaftServer(i, servers)
	}

	fmt.Println("Raft cluster started. Servers are in follower state.")

	// Allow it to run for a while
	time.Sleep(5 * time.Second)

	// Simulate a client request to the leader
	// Normally, the client would find the leader and send to it.
	// Here, let's simply send to one server and expect the leader to process it.
	// (In real Raft, the client would retry until it finds the leader)
	fmt.Println("\nSending client request...")
	leaderFound := false
	for _, s := range servers {
		s.mu.Lock()
		if s.State == Leader {
			fmt.Printf("Leader %d found. Sending client request.\n", s.ID)
			newEntry := LogEntry{Term: s.CurrentTerm, Index: len(s.Log), Command: "SET x = 10"}
			s.Log = append(s.Log, newEntry)
			// Update nextIndex for all peers to include the new entry
			for i := range s.peers {
				if s.ID != s.peers[i].ID {
					s.NextIndex[i] = len(s.Log) // Set to the index after the newly added entry
				} else {
					s.MatchIndex[i] = len(s.Log) - 1 // Leader's own log is committed
				}
			}
			s.sendHeartbeats() // Trigger log replication
			leaderFound = true
		}
		s.mu.Unlock()
		if leaderFound {
			break
		}
	}
	if !leaderFound {
		fmt.Println("Leader not found, try again or increase election timeout.")
	}

	time.Sleep(5 * time.Second)
	fmt.Println("\nSimulation ended.")
}

Bu kod, Raft’ın temel mekanizmalarını gösterir:

RaftServer struct: Bir Raft sunucusunun durumunu ve logunu tutar.
RequestVoteArgs / RequestVoteReply: Seçim RPC’leri için veri yapıları.
AppendEntriesArgs / AppendEntriesReply: Log çoğaltma ve kalp atışı RPC’leri için veri yapıları.
startElection(): Bir sunucunun adaya dönüşmesini, oy istemesini ve lider olmaya çalışmasını simüle eder.
RequestVote(): Diğer sunuculardan gelen oy isteklerini işler.
sendHeartbeats(): Liderin düzenli kalp atışları göndermesini ve log çoğaltmayı tetiklemesini simüle eder.
AppendEntries(): Takipçilerin liderden gelen log girişlerini işlemesini ve log tutarlılığını sağlamasını simüle eder.

Log Çoğaltma

Bir lider seçildikten sonra, istemci isteklerini işlemeye başlar. Her veri değişikliği, Raft logunda yeni bir giriş olarak kaydedilir. Bu log girişi, lider tarafından kendi yerel loguna eklenir. Log girişi tipik olarak gerçekleştirilecek işlem hakkında bilgi içerir (örneğin, bir veritabanı yazma işlemi için anahtar-değer çiftleri).

Lider, log girişini kendi loguna ekledikten sonra, AppendEntries RPC’leri kullanarak bu log girişini takipçilere çoğaltır. Bu çoğaltma, tüm takipçilerin liderle aynı log girişleri dizisini almasını sağlar. Her takipçi, liderden aldığı log girişini kendi loguna ekler.

Bir log girişi, liderin çoğunluktaki takipçilerden log girişini çoğalttığına dair onay aldığında “taahhüt edilmiş” (committed) kabul edilir. Taahhüt edildikten sonra, lider ilgili işlemi kendi durum makinesine uygular ve istemciye yanıt verir. Lider, gelecekteki AppendEntries RPC’lerinde (kalp atışları dahil) taahhüt edilmiş girişleri diğer sunuculara bildirir, böylece takipçiler de bu girişleri kendi durum makinelerine uygulayabilir.

Raft, loglar arasında yüksek düzeyde tutarlılık sağlar ve bunu “Log Eşleştirme Özelliği” (Log Matching Property) ile garanti eder:

Farklı loglardaki iki giriş aynı dizine ve terime sahipse, aynı komutu depolarlar.
Farklı loglardaki iki giriş aynı dizine ve terime sahipse, loglar o girişe kadar tüm önceki girişlerde aynıdır.

Bu mekanizma sayesinde, bir lider iktidara geldiğinde log tutarlılığını sağlamak için özel bir eylemde bulunmasına gerek kalmaz. Normal çalışmaya başlar ve loglar, AppendEntries tutarlılık kontrolünün başarısızlıklarına yanıt olarak otomatik olarak yakınsar. Bir lider asla kendi logundaki girişleri üzerine yazmaz veya silmez.

Güvenlik Özellikleri

Raft, dağıtık sistemlerde tutarlılığı ve güvenilirliği sağlamak için bir dizi güvenlik özelliğini garanti eder:

Seçim Güvenliği (Election Safety): Her terim için en fazla bir lider seçilebilir. Bu, her sunucunun yalnızca bir oy vermesi ve iki farklı adayın aynı terim içinde çoğunlukları asla biriktirememesiyle sağlanır.
Lider Tamamlama (Leader Completeness): Yeni bir lider, önceki terimlerde taahhüt edilmiş tüm log girişlerini her zaman içerir. Bu, takipçilerin yalnızca kendi loglarından daha güncel olan bir adaya oy vermesiyle sağlanır.
Log Eşleştirme (Log Matching): Yukarıda açıklandığı gibi, eğer iki logda aynı dizine ve terime sahip bir giriş varsa, o noktaya kadar loglar tamamen aynıdır.
Durum Makinesi Güvenliği (State Machine Safety): Bir log girişi taahhüt edildikten sonra, değişmeyeceği garanti edilir. Bu, sistemin bütünlüğünü korur.
Kalıcı Depolama (Persistent Storage): Her sunucu, mevcut terim, en son verilen oy ve log gibi kritik bilgileri kalıcı depolamada (disk veya flash gibi) saklar. Bu veriler, bir çökmeden sonra kurtarılabilmelidir.
İstemci Etkileşimleri (Client Interactions): İstemciler yalnızca liderle etkileşime girer. Bir istemci başlangıçta herhangi bir sunucuya istek gönderebilir, ancak lider olmayan bir sunucu isteği reddeder ve en son lider hakkında bilgi döndürür. Lider bir istemci isteğini yürütürken çökerse, istemci istek başarılı olana kadar yeniden dener. Yinelenen komutların önlenmesi için, her komut benzersiz bir komut kimliğiyle eşleştirilir ve lider, yinelenen bir isteği algıladığında eski yanıtı yeniden yürütmeden gönderir.

Raft’ın Avantajları ve Sınırlamaları

Raft, dağıtık sistemlerde konsensus için güçlü bir çözüm sunarken, kendine özgü avantajları ve bazı sınırlamaları vardır:

Avantajlar

Anlaşılabilirlik ve Basitlik: Raft’ın birincil tasarım hedefi, Paxos gibi diğer konsensus algoritmalarına kıyasla daha anlaşılır ve uygulanması daha kolay olmaktır. Bu, geliştiricilerin onu benimsemesini ve kullanmasını kolaylaştırır.
Hata Toleransı: Raft, sunucu arızalarını etkili bir şekilde yönetebilir ve sistemin çalışır durumda kalmasını sağlayabilir. Kümenin çoğunluğu çalıştığı sürece sistem kullanılabilir kalır.
Güçlü Tutarlılık: Raft, tüm düğümlerin aynı durumu korumasını garanti ederek güçlü tutarlılık sağlar. Modülerlik: Raft, konsensus problemini lider seçimi, log çoğaltma ve güvenlik gibi ayrı alt problemlere ayırır, bu da onu anlamayı ve uygulamayı kolaylaştırır.

Sınırlamalar

Tek Lider Darboğazı: Lider, yoğun yük altında bir darboğaz haline gelebilir ve potansiyel olarak sistem performansını etkileyebilir. Tüm istemci istekleri liderden geçmek zorundadır.
Bizans Hata Toleransı Yok: Raft, Bizans olmayan hataları varsayar. Bu, kötü niyetli saldırılar veya düğümlerin düzensiz davranmasına neden olan yazılım hataları gibi keyfi hataları ele almadığı anlamına gelir.

Gelişmiş Konular

Küme Üyeliği Değişiklikleri

Raft, küme yapılandırmasındaki değişiklikleri, yani düğüm ekleme veya kaldırma işlemlerini yönetme protokolünü tanımlar. Raft, genellikle tek sunuculu değişikliklere izin verir, yani aynı anda yalnızca bir sunucu eklenebilir veya silinebilir. Bu, özel AppendEntries girişleri kullanılarak iletişim kurulan küme yapılandırma değişiklikleri aracılığıyla gerçekleştirilir. ScyllaDB gibi bazı uygulamalar, Raft’ı kullanarak eşzamanlı düğüm ekleme veya kaldırma işlemlerine izin veren “işlemsel topoloji değişiklikleri” üzerinde çalışmaktadır.

Anlık Görüntüler (Snapshots)

Raft, log boyutunu sınırlamak için periyodik anlık görüntü mekanizmasını kullanır. Anlık görüntüler, belirli bir zamandaki sistemin durumunun bir görüntüsünü yakalar ve bu duruma ulaşmak için kullanılan tüm önceki log girişlerinin kaldırılmasına izin verir. Bu işlem otomatik olarak ve kullanıcı müdahalesi olmadan sunucularda gerçekleştirilir. Anlık görüntüler, tüm yapılandırmaları, sırlar motorlarını, kimlik doğrulama yöntemlerini, politikaları, belirteçleri ve depolanan sırları yedekler.

Pre-Vote ve Liderlik Transferi

Orijinal Raft algoritmasının uzantıları, kullanılabilirliği ve performansı artırmak için geliştirilmiştir:

Pre-Vote: Bir üye kümeye yeniden katıldığında, zamanlamaya bağlı olarak zaten bir lider olmasına rağmen bir seçim tetikleyebilir. Bunu önlemek için, ön oylama önce diğer üyelerle kontrol eder. Gereksiz seçimi önlemek, kümenin kullanılabilirliğini artırır.
Liderlik Transferi: Düzenli bir şekilde kapanan bir lider, liderliği açıkça başka bir üyeye devredebilir. Bu, bir zaman aşımı beklemekten daha hızlı olabilir. Ayrıca, başka bir üye daha iyi bir lider olduğunda (örneğin, daha hızlı bir makinede olduğunda) bir lider istifa edebilir.

Gerçek Dünya Uygulamaları

Raft algoritması, basitliği ve sağlamlığı nedeniyle birçok popüler dağıtık sistemde yaygın olarak benimsenmiştir:

etcd: Kubernetes’in temel bir bileşenidir ve dağıtık sistemlerin çalışmaya devam etmesi için ihtiyaç duyduğu kritik bilgileri (yapılandırma verileri, durum verileri ve meta veriler) tutmak ve yönetmek için kullanılan açık kaynaklı bir dağıtık anahtar-değer deposudur. etcd, tüm düğümler arasında veri deposu tutarlılığını sağlamak için Raft konsensus algoritması üzerine kurulmuştur.
Consul: Dağıtık sistemler için bir hizmet ağ çözümü olup, Raft algoritmasına dayalı dağıtık bir anahtar-değer deposu içerir. Hizmet kayıtlarının durumunu korumak için Raft’a güvenir.
ScyllaDB: Yüksek verim ve öngörülebilir düşük gecikme süresi gerektiren veri yoğun uygulamalar için tasarlanmış bir NoSQL veritabanıdır. ScyllaDB, tutarlı işlemler gerçekleştirmek ve yönetilebilirliği ve tutarlılığı önemli ölçüde artırmak için Raft’ı uygulamaktadır.
TiKV: Dağıtık bir veritabanı olan TiKV, hata toleransı için verileri birden çok kopya arasında senkronize etmek için Raft’ı kullanır.

Raft algoritması, dağıtık sistemlerde konsensus problemini çözmek için zarif ve pratik bir yaklaşım sunar. Paxos’un karmaşıklığına bir yanıt olarak tasarlanmış olması, onu geliştiriciler için daha erişilebilir ve anlaşılır hale getirmiştir. Lider seçimi, log çoğaltma ve güvenlik gibi temel bileşenlere ayrılmış yapısı, güçlü tutarlılık ve hata toleransı garantileriyle birleştiğinde, Raft’ı etcd, Consul ve ScyllaDB gibi modern dağıtık sistemlerin temel taşı haline getirmiştir. Raft, basitliği ve güvenilirliği dengeleyerek, günümüzün karmaşık ve dinamik bilişim ortamlarında sağlam ve ölçeklenebilir uygulamalar oluşturmak için vazgeçilmez bir araç olmaya devam etmektedir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Havacılık Tarihindeki Kilometre Taşları: Wright Kardeşlerden Modern Jetlere

Tue, 08 Apr 2025 00:00:00 GMT

Binlerce yıl boyunca, insanlar gökyüzünde zahmetsizce süzülen kuşlara imrenerek baktılar. Mitolojik İkarus’tan Leonardo da Vinci’nin uçan makine çizimlerine kadar, gökleri fethetme arzusu insan tarihinde sürekli bir hayal olarak kaldı. Ancak bu kadim özlem, 20. yüzyılın başlarında nihayet gerçeğe dönüştü.

Wright Kardeşler ve Havacılığın Doğuşu

17 Aralık 1903’te, Kuzey Carolina’nın Kitty Hawk bölgesindeki rüzgârlı kumlarda, Orville Wright ilk motorlu, kontrollü ve sürdürülebilir ağır hava aracı uçuşunu gerçekleştirirken, kardeşi Wilbur da yanında koşuyordu. Wright Flyer adlı uçakları, mütevazı bir şekilde 12 saniye havada kalarak 120 fit (yaklaşık 37 metre) yol kat etti. Kısa olmasına rağmen, bu başarı Ohio’nun Dayton şehrinden gelen bisiklet tamircilerinin yıllarca süren metodolojik araştırma ve deneylerinin sonucuydu.

Wright kardeşleri öncüllerinden ayıran şey, uçuşun üç temel zorluğunu çözmeye yönelik sistematik yaklaşımlarıydı: kaldırma kuvveti, itme gücü ve kontrol. Onların atılımı, üç eksenli kontrol sistemini geliştirmeleri sayesinde oldu; bu, pilotun uçağı etkili bir şekilde yönlendirmesini ve dengesini korumasını sağlıyordu. Kanat bükülmesi (kanatçıkların öncüsü) ve dümen hareketleri aracılığıyla pilotun yuvarlanma, yunuslama ve sapma hareketlerini kontrol etmesine olanak tanıyan bu yenilik, bugün hâlâ uçak kontrol sistemlerinin temelini oluşturmaktadır.

İlk uçuşlarını takip eden yıllarda, kardeşler tasarımlarını geliştirerek uçuş sürelerini ve mesafelerini kademeli olarak uzattılar. 1905 yılına gelindiğinde, Wright Flyer III 30 dakikadan fazla havada kalabilir ve karmaşık manevralar gerçekleştirebilir hale gelmişti, bu da pratik hava yolculuğunun mümkün olduğunu gösteriyordu.

I. Dünya Savaşı: Havacılık Olgunlaşıyor

1914’te I. Dünya Savaşı’nın patlak vermesiyle uçak tasarımı ve kabiliyetinde hızlı bir ilerleme yaşandı. Öncelikle keşif amaçlı kullanılan narin makineler, savaşın sonuna doğru özelleşmiş savaş uçaklarına dönüştü. Çatışma süresince avcı uçakları, bombardıman uçakları ve yer saldırı uçakları ortaya çıktı. Anthony Fokker gibi havacılık öncüleri, makineli tüfeklerin pervanelere çarpmadan pervane yayı boyunca ateş etmesine olanak tanıyan senkronizasyon dişlisini geliştirdi. Manfred von Richthofen (“Kırmızı Baron”) ve Eddie Rickenbacker gibi efsanevi hava aslrı, hava muharebeleri kamuoyunun hayal gücünü ele geçirirken tanınmış isimler haline geldi.

1918’de savaşın sonunda, uçak hızları iki katından fazla artarak 130 mil/saat (yaklaşık 210 km/saat) üzerine çıkmış, tavan yükseklikleri 20.000 fit (yaklaşık 6.100 metre) üzerine çıkmış ve uçuş süreleri birkaç saate uzamıştı. Metal, yapısal bileşenlerde ahşabın yerini almaya başlamış ve uçak motorları önemli ölçüde daha güçlü ve güvenilir hale gelmişti.

Havacılığın Altın Çağı (1919-1939)

Savaşlar arası dönem, havacılığın askeri bir gereklilikten ticari bir girişime ve popüler bir gösteriye dönüşümüne tanık oldu. Fazla askeri uçaklar, 1918’de Amerika Birleşik Devletleri’nde başlayan hava postası servisi dahil olmak üzere sivil kullanımlara yeniden tahsis edildi.

Charles Lindbergh’in 1927’de “Spirit of St. Louis” ile gerçekleştirdiği solo transatlantik uçuş dünyayı büyüledi ve uzun mesafeli hava yolculuğunun olanaklarını gösterdi. New York’tan Paris’e yaptığı 33 saatlik yolculuk, 25.000 dolarlık Orteig Ödülü’nü kazandı ve bir nesil havacıyı ve uçak tasarımcısını esinlendirdi. 1932’de Atlantik’i tek başına uçan ilk kadın olan Amelia Earhart, dönemin macera ruhunu simgeledi ve havacılıkta neyin mümkün olduğunun sınırlarını zorladı. 1937’de dünya çevresinde bir uçuş denemesi sırasında ortadan kaybolması, havacılık tarihinin en büyük gizemlerinden biri olmaya devam ediyor.

Aynı zamanda, ticari hava yolculuğu da şekillenmeye başladı. 1919’da Almanya’nın Deutsche Luft Hansa (daha sonra Lufthansa) ve Hollanda’nın KLM havayolları kuruldu, ardından 1924’te Imperial Airways (British Airways’in öncüsü) geldi. Amerika Birleşik Devletleri’nde, Pan American World Airways, Juan Trippe’nin liderliğinde öncü bir uluslararası taşıyıcı olarak ortaya çıktı.

Uçak tasarımı bu dönemde önemli ölçüde gelişti. 1925’te tanıtılan Ford Trimotor, ilk tamamen metal yolcu uçaklarından biriydi. 1933’te tanıtılan Boeing 247, tamamen metal yarı monokok yapı, içeri çekilebilir iniş takımı ve otomatik pilot dahil olmak üzere yenilikler içeriyordu. 1935’te ilk kez uçan Douglas DC-3, hız, menzil, kapasite ve güvenilirlik kombinasyonu ile hava taşımacılığında devrim yarattı ve hava yolculuğunu devlet sübvansiyonları olmadan kârlı hale getirdi.

II. Dünya Savaşı: Jet Çağı Yaklaşıyor

II. Dünya Savaşı (1939-1945), havacılık teknolojisinde bir başka büyük sıçramaya yol açtı. Uçak üretimi eşi görülmemiş seviyelere yükseldi; sadece Amerika Birleşik Devletleri çatışma süresince 300.000’den fazla uçak üretti.

Supermarine Spitfire, North American P-51 Mustang ve Boeing B-17 Flying Fortress gibi ikonik uçaklar, Müttefik hava gücünün sembolleri haline geldi. Savaş, uçakların olumsuz hava koşullarının üzerinde uçmasına olanak tanıyan basınçlı kabinlerin ve navigasyon ile hava savunmasında devrim yaratan radarın tanıtılmasına tanık oldu.

Belki de en önemlisi, çatışma jet itişinin gelişmesini hızlandırdı. 1939’da Alman mühendis Hans von Ohain, dünyanın ilk pratik jet uçağı olan Heinkel He 178’in motorunu tasarladı. İngiltere’de, Frank Whittle’ın paralel çalışması, 1941’de ilk kez uçan Gloster E.28/39’a yol açtı.

Savaşın sonunda, operasyonel jet avcı uçakları arasında Almanya’nın Messerschmitt Me 262’si ve İngiltere’nin Gloster Meteor’u vardı. 600 mil/saate (yaklaşık 965 km/saat) yaklaşan hızlara ulaşabilen bu uçaklar, yaklaşan jet çağının habercisiydi.

Jet Devrimi ve Modern Çağın Başlangıcı

1952’de British Overseas Airways Corporation (BOAC), dünyanın ilk ticari jet yolcu uçağı olan de Havilland Comet’i tanıttı. Birkaç feci kazaya yol açan erken yapısal sorunlara rağmen, Comet jet seyahat çağına öncülük etti.

1958’de tanıtılan Boeing 707 ve kısa bir süre sonra gelen Douglas DC-8, jet yolcu uçakları için standart konfigürasyonu belirledi: geriye süpürülmüş kanatlar, kanatların altına ve önüne asılı motorlar ve dairesel kesitli basınçlı gövde. Bu uçaklar seyahat sürelerini önemli ölçüde azalttı ve kıtalararası seyahati milyonlarca kişiye erişilebilir hale getirdi.

1960’lar uzay yarışına ve ay inişlerine tanık oldu, ancak ticari havacılıkta da muazzam ilerlemeler yaşandı. 1969’da ilk kez uçan Boeing 747, eşi görülmemiş boyutu ve kapasitesi ile uzun mesafeli seyahatlerde devrim yarattı. “Jumbo Jet” lakaplı bu uçak, ilk konfigürasyonlarında 366 yolcu taşıyabiliyordu ve uluslararası hava yolculuğunun demokratikleşmesine yardımcı oldu.

Bu arada, 1968’de İngiliz-Fransız ortak yapımı Concorde havalandı ve 1976’da ticari hizmete girdi. Mach 2.04’lük (saatte 1.350 milin üzerinde) seyir hızlarına ulaşabilen Concorde, transatlantik seyahat sürelerini sadece üç saatin üzerine indirdi. Teknolojik harika statüsüne rağmen, yüksek işletme maliyetleri ve çevresel kaygılar yaygın olarak benimsenmesini sınırladı ve hizmet 2003 yılında sona erdi.

Askeri Havacılık: Engelleri Aşmak

Askeri havacılık, savaş sonrası dönem boyunca sınırları zorlamaya devam etti. 1947’de Chuck Yeager, Bell X-1 ile ses bariyerini aşarak 43.000 fit (yaklaşık 13.100 metre) yükseklikte Mach 1.06’ya (700 mil/saat veya 1.126 km/saat) ulaştı. 1960’lara gelindiğinde, SR-71 Blackbird gibi uçaklar rutin olarak ses hızının üç katında uçuyor, 80.000 fitin (yaklaşık 24.400 metre) üzerindeki yüksekliklere çıkıyordu.

İngiliz Harrier “Jump Jet” ile örneklenen dikey kalkış ve iniş (VTOL) uçaklarının geliştirilmesi, yeni taktik olanaklar sundu. 1983’te ilk kez operasyonel olarak kullanılan F-117 Nighthawk ile modern stealth teknolojisi, uçak radar izlerini önemli ölçüde azaltarak hava savaşını temelden değiştirdi.

Günümüzün F-22 Raptor ve F-35 Lightning II gibi beşinci nesil savaş uçakları, tartışmalı ortamlarda hava üstünlüğünü korumak için stealth teknolojisini gelişmiş aviyonikler, süperkruz kabiliyeti (son yakıcılar olmadan süpersonik uçuş) ve yüksek entegre bilgisayar sistemleriyle birleştiriyor.

Modern Ticari Havacılık Manzarası

Ticari havacılık endüstrisi, dünyanın neredeyse her köşesini birbirine bağlayan küresel bir ağa dönüşmüştür. Boeing 787 Dreamliner ve Airbus A350 gibi modern yolcu uçakları, kompozit malzemeler ve gelişmiş aerodinamik kullanarak, binlerce mil uzunluğundaki rotalarda eşi görülmemiş yakıt verimliliği ve yolcu konforu sunuyor.

2007’de dünyanın en büyük yolcu uçağı olarak tanıtılan Airbus A380, tek sınıflı bir konfigürasyonda 853 yolcu taşıyabilir. Değişen pazar talepleri nedeniyle üretimi 2021’de sona erse de (daha küçük, daha verimli çift motorlu uçaklara doğru bir yönelim), A380 merkez-çevre rota tasarım felsefesinin zirvesini temsil ediyor.

Amerika Birleşik Devletleri’nde Southwest Airlines ve Avrupa’da easyJet ve Ryanair tarafından öncülük edilen düşük maliyetli taşıyıcılar, hava yolculuğunun ekonomisini dönüştürerek dünya çapında milyarlarca insana erişilebilir hale getirdi. 2019’da, COVID-19 pandemisinden önce, küresel havayolları yaklaşık 4,5 milyar yolcu taşıdı.

Jetlerin Ötesinde: Havacılığın Geleceği

Havacılığın geleceğine baktığımızda, sektörü yeniden şekillendirebilecek birkaç trend ortaya çıkıyor:

1. Sürdürülebilir Havacılık: İklim değişikliği konusundaki endişeler, sürdürülebilir havacılık yakıtları, elektrikli itme sistemleri ve hidrojen gücü araştırmalarını yönlendiriyor. Eviation gibi şirketler tamamen elektrikli yolcu uçakları geliştirirken, büyük üreticiler 2030’lar ve sonrası için hidrojen enerjili ticari yolcu uçaklarını araştırıyor.

2. Kentsel Hava Hareketliliği: Joby Aviation, Lilium ve Archer gibi şirketler, kentsel merkezler içinde ve arasında hava taksisi olarak hizmet vermesi amaçlanan elektrikli dikey kalkış ve iniş (eVTOL) uçakları geliştiriyor, bu da kentsel ulaşımda devrim yaratma potansiyeline sahip.

3. Süpersonik Rönesans: Concorde’un emekliliğinden sonra, Boom Supersonic gibi şirketler, daha ekonomik ve çevre dostu tasarımlarla ticari süpersonik seyahati canlandırmak için çalışıyor. Boom’un Overture modeli, 2020’lerin sonlarında yolcuları Mach 1.7 (yaklaşık 1.300 mil/saat veya 2.092 km/saat) hızında taşımayı hedefliyor.

4. Otonom Uçuş: Uçuş kontrollerinde artan otomasyon, sonunda azaltılmış mürettebat gereksinimlerine ve hatta pilotsuz ticari uçaklara yol açabilir, ancak önemli düzenleyici ve kamu kabul engelleri bulunmaktadır.

5. Uzay Turizmi: Virgin Galactic ve Blue Origin gibi şirketler, uzayın sınırına ulaşan yörünge altı deneyimler sunarak havacılık ile uzay uçuşu arasındaki çizgiyi bulanıklaştırıyor ve yüksek irtifa seyahatinde yeni bir sınır açma potansiyeline sahip.

Sonuç: Bir Yüzyıllık Dönüşüm

Bir asırdan biraz fazla bir sürede, havacılık Wright kardeşlerin 12 saniyelik sıçramasından, yüzlerce yolcuyu neredeyse ses hızında basınçlı konforla taşıyan rutin transatlantik uçuşlara evrildi. Modern uçaklar, uçuş öncülerine bilim kurgu gibi görünecek malzemeler ve teknolojiler içeriyor.

Bu dikkate değer dönüşüm, insan toplumunu temelden değiştirdi; mesafeleri kısalttı, kültürleri birbirine bağladı ve gerçek bir küresel topluluk yarattı. İklim değişikliği ve kaynak kısıtlamaları da dahil olmak üzere 21. yüzyılın zorluklarıyla karşı karşıyayken, havacılık evrilmeye, dünyamızı birbirine bağlamadaki çok önemli rolünü sürdürürken değişen teknolojik, ekonomik ve çevresel gerçeklere uyum sağlamaya devam ediyor.

Havacılık hikayesi, özünde insan yaratıcılığının ve azminin bir kanıtıdır; yerçekiminin sınırlamalarını kabul etmeyi reddeden ve gökyüzüne zarifçe tırmanırken hayranlık uyandırmaya devam eden makineler yaratan vizyonerlerin ve mühendislerin bir kroniğidir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

CAP Teoremi: Dağıtık Sistemlerde Temel Kısıtlamalar

Sun, 06 Apr 2025 00:00:00 GMT

CAP teoremi, dağıtık sistem tasarımındaki en etkili prensiplerden biri olarak, mühendislerin dayanıklı ve ölçeklenebilir uygulamalar oluştururken karşılaştıkları temel kısıtlamaları ifade eder. İlk olarak Eric Brewer tarafından 2000 yılında öne sürülen ve daha sonra Seth Gilbert ve Nancy Lynch tarafından 2002 yılında matematiksel olarak kanıtlanan [1] bu teorem, dağıtık veri sistemlerinin aynı anda şu üç garantiden en fazla ikisini sağlayabileceğini belirtir: Tutarlılık (Consistency), Erişilebilirlik (Availability) ve Bölünme Toleransı (Partition tolerance).

Bu makale, CAP teoreminin teorik temellerini, pratik etkilerini ve modern dağıtık sistemlerin bu çerçevede nasıl stratejik ödünleşmeler yaptığını incelemektedir. Dağıtık sistemlerle çalışan profesyonel mühendisler için, bu kısıtlamaları anlamak, iş gereksinimlerine ve teknik gerçeklere uygun bilinçli mimari kararlar almak için esastır.

Üç Garantiyi Anlamak

Tutarlılık (Consistency - C)

Tutarlılık, dağıtık bir sistemdeki tüm düğümlerin aynı zamanda aynı verileri görmesini sağlar. Kesin tutarlı sistemlerde, herhangi bir okuma işlemi, hangi düğümün isteği aldığına bakılmaksızın en son yazma işleminin değerini döndürür. Bu özellik, veriler yazıldıktan ve onaylandıktan sonra, tüm sonraki okumaların bu yazma işlemini yansıtacağını garanti eder.

Resmi olarak, tutarlılık doğrusallık (linearizability) anlamına gelir - işlemler, operasyonların gerçek zamanlı sıralamasına uyan sıralı bir düzende yürütülüyor gibi görünür [2].

Erişilebilirlik (Availability - A)

Erişilebilirlik, arızalı olmayan her düğüme yapılan her isteğin, yanıtın en güncel verileri içerdiği garantisi olmadan bir yanıt aldığı anlamına gelir. Erişilebilir bir sistem, bazı bileşenler başarısız olsa bile hizmetin çalışır durumda kalmasını sağlar ve tüm istemci isteklerine yanıt verir.

Matematiksel olarak, erişilebilirlik, her isteğin sonunda bir yanıt alacağı anlamına gelir (canlılık özelliği), ancak yanıt en son durumu yansıtmayabilir [3].

Bölünme Toleransı (Partition Tolerance - P)

Bölünme toleransı, bir sistemin ağ bölünmeleri - bazı düğümlerin diğerleriyle iletişim kurmasını engelleyen ağ arızaları - olmasına rağmen çalışmaya devam etme yeteneğini ifade eder. Bölünmüş bir ağda, bir bölümdeki düğümlerden gönderilen mesajlar diğer bölümlerdeki düğümlere ulaşamaz.

Bölünme toleransı, gerçek dünya dağıtık sistemlerinde isteğe bağlı değildir; ağ arızaları kaçınılmaz olarak meydana gelecektir. Gilbert ve Lynch’in kanıtı, bölünme toleransı gerektiriyorsak, tutarlılık ve erişilebilirlik arasında seçim yapmamız gerektiğini gösteriyor [1].

Teorem: Üçünden İkisini Seçin

CAP teoreminin temel içgörüsü, bir ağ bölünmesi meydana geldiğinde, dağıtık bir sistemin ya tutarlılıktan ya da erişilebilirlikten vazgeçmesi gerektiğidir:

1. CP Sistemleri (Tutarlı ve Bölünme Toleranslı): Bu sistemler, erişilebilirliğe göre tutarlılığa öncelik verir. Bir bölünme meydana geldiğinde, tutarlılığı korumak için bazı düğümler erişilemez hale gelir.

2. AP Sistemleri (Erişilebilir ve Bölünme Toleranslı): Bu sistemler, tutarlılığa göre erişilebilirliğe öncelik verir. Bir bölünme sırasında, tüm düğümler erişilebilir kalır, ancak eski veya tutarsız veriler döndürebilir.

3. CA Sistemleri (Tutarlı ve Erişilebilir): Bu sistemler bölünmelere tolerans gösteremez. Pratikte, gerçek CA sistemleri yalnızca dağıtık olmayan ortamlarda var olabilir, çünkü dağıtık ortamlarda ağ bölünmeleri kaçınılmazdır.

Matematiksel Kanıt Sezgisi

Gilbert ve Lynch’in matematiksel kanıtı [1], tutarlılık, erişilebilirlik ve bölünme toleransını aynı anda elde etmenin imkansızlığını basit bir senaryo kullanarak gösterir: İki düğümlü (A ve B) ve v değeriyle tutarlı bir durumda başlayan dağıtık bir sistem düşünün. Bir ağ bölünmesi meydana gelir ve A’yı B’den izole eder. Bir istemci, A düğümüne yeni bir v’ değeri yazar. Ardından, farklı bir istemci B düğümünden okur.

Bu senaryoda:

Sistem tutarlılığa öncelik veriyorsa, B düğümü bir değer döndüremez (erişilemez) çünkü en son durumu doğrulayamaz.
Sistem erişilebilirliğe öncelik veriyorsa, B düğümü A düğümündaki güncellenmiş v’ değeriyle tutarsız olan v değerini döndürmelidir.

Bu, bir bölünme sırasında çözülemez bir ikilem yaratır: ya yanıt vermeyi reddederek erişilebilirlikten vazgeçin, ya da potansiyel olarak eski veri döndürerek tutarlılıktan vazgeçin.

Modern Sistemlerde Pratik Örnekler

CP Sistem Örneği: Güçlü Tutarlılık ile Redis Cluster

Redis Cluster, aşağıdaki yapılandırma kullanılarak tutarlılığa erişilebilirlikten daha fazla öncelik verecek şekilde yapılandırılabilir:

import (
    "context"
    "github.com/go-redis/redis/v8"
)

func setupConsistentRedisCluster() *redis.ClusterClient {
    rdb := redis.NewClusterClient(&redis.ClusterOptions{
        Addrs:    []string{":7000", ":7001", ":7002"},
        // Require acknowledgment from majority of nodes
        ReadOnly: false,
        // Wait for data to be replicated to majority of nodes
        RouteByLatency: false,
    })
    
    // Test connection
    ctx := context.Background()
    if err := rdb.Ping(ctx).Err(); err != nil {
        panic(err)
    }
    
    return rdb
}

Bu yapılandırmada, bir ağ bölünmesi meydana geldiğinde, yalnızca düğümlerin çoğunluğunu içeren bölüm çalışır durumda kalır. Azınlık bölümü erişilemez hale gelir, tutarlılığı korumak için erişilebilirlikten fedakarlık yapar.

AP Sistem Örneği: Nihai Olarak Tutarlı Okumalarla DynamoDB

Amazon DynamoDB, erişilebilirliğe anında tutarlılık yerine öncelik veren, nihai olarak tutarlı okumalar için bir seçenek sunar:

const AWS = require('aws-sdk');
const dynamoDB = new AWS.DynamoDB.DocumentClient();

// Eventually consistent read (default)
async function fetchDataWithEventualConsistency(key) {
    const params = {
        TableName: 'MyTable',
        Key: { 'id': key },
        // ConsistentRead: false is the default (eventually consistent)
    };
    
    try {
        const result = await dynamoDB.get(params).promise();
        return result.Item;
    } catch (error) {
        console.error("Error fetching data:", error);
        throw error;
    }
}

Bu yapılandırmayla DynamoDB, bölünmeler sırasında okuma hizmeti vermeye devam edecek ancak bölünme iyileşip çoğaltma yetişene kadar eski veriler döndürebilir.

CRDT Tabanlı Sistemler: CAP Ödünleşmeleri Arasında Gezinme

Çatışmasız Çoğaltılabilir Veri Türleri (Conflict-free Replicated Data Types - CRDTs), CAP ödünleşmelerini ele almak için yenilikçi bir yaklaşım sunar:

// Simplified example of a G-Counter (Grow-only Counter) CRDT in Go
type GCounter struct {
    Counts map[string]int // Node ID -> Count
    NodeID string
}

func NewGCounter(nodeID string) *GCounter {
    return &GCounter{
        Counts: make(map[string]int),
        NodeID: nodeID,
    }
}

func (c *GCounter) Increment() {
    c.Counts[c.NodeID]++
}

func (c *GCounter) Value() int {
    total := 0
    for _, count := range c.Counts {
        total += count
    }
    return total
}

// Merge function for eventual consistency
func (c *GCounter) Merge(other *GCounter) {
    for nodeID, count := range other.Counts {
        if existingCount, exists := c.Counts[nodeID]; !exists || count > existingCount {
            c.Counts[nodeID] = count
        }
    }
}

Bu G-Counter gibi CRDT’ler, bölünmeler iyileştiğinde çatışmaları otomatik olarak çözmek için tasarlanmış veri yapıları kullanarak, bölünmeler sırasında erişilebilirliği korurken nihai tutarlılık sağlar [4].

Sistem Tasarımı için Pratik Hususlar

İş Gereksinimlerini Analiz Etme

Dağıtık sistemler tasarlarken, öncelikle spesifik gereksinimlerinizi analiz edin:

1. Veri Tutarlılığı Gereksinimleri: Uygulamanızın güçlü tutarlılık (örn. finansal işlemler) gerektirip gerektirmediğini veya nihai tutarlılığı (örn. sosyal medya beğenileri) tolere edip edemeyeceğini belirleyin.

2. Erişilebilirlik Gereksinimleri: Uygulamanız için kabul edilebilir kesinti süresini değerlendirin. Kritik öneme sahip sistemler, anında tutarlılık yerine erişilebilirliğe öncelik verebilir.

3. Ağ Ortamı: Altyapınızda ağ bölünmelerinin olasılığını ve sıklığını dikkate alın.

Pratik Ödünleşmeleri Uygulama

Modern sistemler genellikle ağ koşullarına göre uyarlanan nüanslı yaklaşımlar uygular:

Ayarlanabilir Tutarlılık

Birçok sistem, mühendislerin işlem türlerine göre tutarlılık ve erişilebilirlik arasında denge kurmasına olanak tanıyan ayarlanabilir tutarlılık seviyeleri sunar:

// MongoDB example with different write and read concerns
const { MongoClient } = require('mongodb');

async function performOperationsWithDifferentConsistencyLevels() {
    const client = new MongoClient('mongodb://localhost:27017');
    await client.connect();
    const db = client.db('mydb');
    const collection = db.collection('documents');
    
    // Write with strong consistency (majority write concern)
    await collection.insertOne(
        { item: 'example', value: 42 },
        { writeConcern: { w: 'majority', wtimeout: 5000 } }
    );
    
    // Read with eventual consistency (primary read preference)
    const result = await collection.findOne(
        { item: 'example' },
        { readPreference: 'primary' }
    );
    
    await client.close();
    return result;
}

Devre Kesiciler ve Yedek Planlar

Bölünmeleri tespit etmek ve davranışı buna göre ayarlamak için devre kesiciler uygulayın:

package main

import (
    "context"
    "errors"
    "time"
    
    "github.com/sony/gobreaker"
)

type DataStore struct {
    ConsistentStore StronglyConsistentDB
    AvailableStore EventuallyConsistentCache
    circuitBreaker *gobreaker.CircuitBreaker
}

func NewDataStore() *DataStore {
    cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
        Name:        "database-circuit",
        MaxRequests: 5,
        Timeout:     10 * time.Second,
        ReadyToTrip: func(counts gobreaker.Counts) bool {
            failureRatio := float64(counts.TotalFailures) / float64(counts.Requests)
            return counts.Requests >= 10 && failureRatio >= 0.5
        },
    })
    
    return &DataStore{
        // initialize stores...
        circuitBreaker: cb,
    }
}

func (ds *DataStore) GetData(ctx context.Context, key string) (interface{}, error) {
    // Try strongly consistent store with circuit breaker
    result, err := ds.circuitBreaker.Execute(func() (interface{}, error) {
        return ds.ConsistentStore.Get(ctx, key)
    })
    
    if err != nil {
        // Circuit open or consistent store failed
        // Fall back to eventually consistent store
        return ds.AvailableStore.Get(ctx, key)
    }
    
    return result, nil
}

Bu model, sistemlerin mevcut ağ koşullarına bağlı olarak CP ve AP modları arasında dinamik olarak geçiş yapmasına olanak tanır.

CAP Teoreminin Ötesinde

PACELC Uzantısı

PACELC teoremi, hem bölünmeler sırasında hem de normal çalışma durumunda sistem davranışını ele alarak CAP’i genişletir [5]:

PA/EL: Bir Bölünme meydana gelirse, Erişilebilirlik ve tutarlılık (Latency) arasında seçim yapın; Aksi takdirde (normal çalışmada), tutarlılık ve Latency arasında seçim yapın.

Bu uzantı, bölünmeler yokluğunda bile, dağıtık sistemlerin tutarlılık ve gecikme arasında temel bir ödünleşmeyle karşı karşıya olduğunu kabul eder.

Tutarlılık Modelleri Spektrumu

Tutarlılığı ikili olarak görmek yerine, modern sistemler bir spektrum boyunca çeşitli tutarlılık modelleri uygular:

1. Güçlü Tutarlılık: Doğrusallık, sıralı tutarlılık

2. Nedensel Tutarlılık: Nedensel olarak ilişkili işlemler tüm gözlemcilere aynı sırada görünür

3. Nihai Tutarlılık: Tüm çoğaltmalar sonunda aynı duruma yakınsar

// Redis example with different consistency models
const Redis = require('ioredis');

// Strong consistency with synchronous replication
const strongConsistentRedis = new Redis.Cluster([
    { host: 'redis-node1', port: 6379 },
    { host: 'redis-node2', port: 6379 },
], {
    scaleReads: 'master', // Only read from master node
    waitCommand: true     // Wait for commands to complete
});

// Eventual consistency with asynchronous replication
const eventuallyConsistentRedis = new Redis.Cluster([
    { host: 'redis-node1', port: 6379 },
    { host: 'redis-node2', port: 6379 },
], {
    scaleReads: 'all',    // Read from any node
    enableOfflineQueue: true
});

CAP teoremi, dağıtık sistem mühendislerinin kabul etmesi ve yönetmesi gereken temel kısıtlamalar sunar. Bu kısıtlamalar sınırlamalar olarak görülmek yerine, belirli uygulama gereksinimlerine dayalı bilinçli ödünleşmeler yapmak için bir çerçeve olarak anlaşılmalıdır.

Modern dağıtık sistemler giderek değişen ağ koşullarına ve veri erişim modellerine uyum sağlayan sofistike stratejiler uygulamaktadır. İş gereksinimlerini dikkatle analiz ederek ve CAP teoreminin teorik temellerini anlayarak, mühendisler spesifik kullanım durumları için tutarlılık, erişilebilirlik ve bölünme toleransı arasında optimal dengeyi sağlayan sistemler tasarlayabilirler.

Kaynaklar

[1] Gilbert, S., & Lynch, N. (2002). Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News, 33(2), 51-59.

[2] Herlihy, M. P., & Wing, J. M. (1990). Linearizability: A correctness condition for concurrent objects. ACM Transactions on Programming Languages and Systems, 12(3), 463-492.

[3] Bailis, P., & Ghodsi, A. (2013). Eventual consistency today: Limitations, extensions, and beyond. Communications of the ACM, 56(5), 55-63.

[4] Shapiro, M., Preguiça, N., Baquero, C., & Zawirski, M. (2011). Conflict-free replicated data types. In Symposium on Self-Stabilizing Systems (pp. 386-400). Springer.

[5] Abadi, D. (2012). Consistency tradeoffs in modern distributed database system design: CAP is only part of the story. Computer, 45(2), 37-42.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Mekanik Saatlerdeki Mühendislik Harikaları: Zamanın İzinde

Mon, 24 Mar 2025 00:00:00 GMT

Mekanik Saatçiliğin Kökleri

İlk mekanik saatler, genellikle kiliselere veya şehir kulelerine monte edilen büyük, ağır yapılardı. Bu erken dönem saatler, ağırlık tahrikli sistemlere dayanıyordu ve bir maşa ve çark denge mekanizması kullanarak zaman tutuyordu. Bu mekanizma, sonraki yüzyıllarda icat edilen daha hassas sistemlerle karşılaştırıldığında oldukça ilkeldi, ancak o dönem için devrim niteliğindeydi.

Yayın İcadı ve Taşınabilir Saatler

yüzyılın sonlarına doğru, mekanik saatlerde devrim yaratan önemli bir gelişme yaşandı: yay mekanizmasının icadı. Saat yapımcıları, ağırlıklar yerine yay gücünü kullanmaya başladılar, bu da saatlerin önemli ölçüde küçültülmesine ve taşınabilir hale gelmesine olanak sağladı. Sarmal bir yay, kasnak etrafına sarılır ve kademeli olarak serbest bırakılırken enerji sağlardı.

İlk taşınabilir saatler, 16. yüzyılın başlarında ortaya çıktı ve yaklaşık bir elma büyüklüğündeydi. Bu erken dönem cep saatleri tambur saatler olarak biliniyordu ve genellikle varlıklı aristokratlar ve tüccarlar tarafından sahip olunabilecek lüks eşyalardı. Zaman içinde saatler daha küçük, daha hassas ve daha erişilebilir hale geldi.

Pendulum Saatleri ve Huygens’in Katkısı

Mekanik saatçilikte bir diğer önemli kilometre taşı, Christiaan Huygens tarafından 1656’da pendulum saatinin icat edilmesiydi. Galileo Galilei’nin pendulum çalışmalarından esinlenen Huygens, pendulumun sabit salınımını zaman tutma mekanizması olarak kullanarak önceki mekanik saatlerden çok daha hassas bir saat geliştirdi.

Pendulum saatleri, dakikadaki hata miktarını dakikadan saniyeye düşürerek zaman ölçüm doğruluğunda büyük bir iyileşme sağladı. Bu gelişme, özellikle deniz navigasyonu için kritik öneme sahipti, çünkü denizciler boylam hesaplamaları için hassas zaman ölçümüne ihtiyaç duyuyorlardı.

Escapement Mekanizması: Mekanik Saatlerin Kalbi

Mekanik bir saatin en önemli bileşenlerinden biri escapement mekanizmasıdır. Bu dahiyane sistem, güç kaynağından (ağırlık veya yay) gelen enerjiyi kontrollü bir şekilde serbest bırakarak saatin düzenli bir ritimde çalışmasını sağlar.

Tarih boyunca, çeşitli escapement tasarımları geliştirilmiştir, her biri zaman ölçüm doğruluğunu iyileştirmeyi amaçlamıştır:

Verge Escapement - En eski türlerden biri, 14. yüzyıldan itibaren kullanıldı
Anchor Escapement - 1657’de Robert Hooke tarafından icat edildi, pendulum saatlerini daha verimli hale getirdi
Deadbeat Escapement - 1675’te George Graham tarafından geliştirildi, daha hassas zaman ölçümü sağladı
Detent Escapement - Deniz kronometrelerinde yaygın olarak kullanıldı
Lever Escapement - Modern mekanik kol saatlerinin çoğunda hâlâ kullanılan bir tasarım

Her bir escapement tasarımı, saatin doğruluk, güvenilirlik ve verimlilik özelliklerini artırmak için geliştirilmiştir.

Deniz Kronometreleri ve John Harrison’ın Başarısı

yüzyılda, mekanik saatçilikte belki de en önemli ilerlemelerden biri John Harrison tarafından gerçekleştirildi. İngiliz marangoz ve saat yapımcısı, denizcilerin boylam hesaplamalarında kullanabilecekleri yeterince hassas bir zaman ölçüm aracı yaratma zorluğunu aşmak için yaşamını adadı.

Yıllarca süren çalışmalardan sonra Harrison, denizde çalışabilen ve günde sadece birkaç saniye hata yapan ilk güvenilir deniz kronometresini geliştirdi. Onun H4 kronometresi, sıcaklık değişimleri, nem ve gemi hareketinden etkilenmeden doğru zaman tutabilen bir başyapıttı.

Harrison’ın başarısı, sadece deniz navigasyonunu dönüştürmekle kalmadı, aynı zamanda hassas mekanik saatçiliğin gelişimi için de yeni bir standart belirledi. Onun inovasyonları, modern saat yapımının temelini oluşturan birçok teknik çözümü içeriyordu.

Komplikasyonlar: Mekanik Ustalığın Zirvesi

Mekanik saatçiliğin en büyüleyici yönlerinden biri, komplikasyonlar olarak bilinen ek işlevlerdir. Bu karmaşık mekanizmalar, saatin temel zaman gösterme işlevinin ötesine geçerek, saatçilik zanaatının gerçek teknik ustalık gösterileri haline gelir.

Yaygın komplikasyonlar arasında şunlar bulunur:

Kronograf - Bir kronometre işlevi, kısa zaman aralıklarını ölçmek için kullanılır
Perpetual Calendar - Ayın farklı uzunluklarını ve artık yılları otomatik olarak ayarlayan takvim
Moon Phase Display - Ayın geçerli evresini gösteren mekanizma
Tourbillon - Yerçekiminin etkilerini telafi etmek için tasarlanmış dönen kafes
Minute Repeater - Düğmeye basıldığında saati çalan kompleks bir mekanizma
Equation of Time - Gerçek güneş zamanı ile ortalama güneş zamanı arasındaki farkı gösteren gösterge

En karmaşık mekanik saatler, binlerce özenle işlenmiş ve monte edilmiş parçadan oluşan ve yıllar süren çalışma gerektiren gerçek mühendislik mucizeleridir.

İsviçre Saatçiliği: Mükemmelliğin Simgesi

İsviçre saatçiliği, mekanik saatlerle neredeyse eş anlamlı hale gelmiştir ve bu durum tesadüf değildir. 16. yüzyılda, İsviçre’nin Cenevre kentinde Kalvinist reformlar, mücevher yapımını yasakladı, birçok zanaatkâr becerilerini saat yapımına yönlendirdi. Bu, İsviçre’nin saatçilik endüstrisine temel oluşturdu.

Jura dağları boyunca uzanan bu saat yapım geleneği, yüzyıllar içinde gelişti ve mükemmelleşti. İsviçreli saat yapımcıları, kış aylarında çiftçilerin ek gelir kaynağı olarak başlayan bir sistemde, son derece özelleşmiş bir “établissage” (montaj) sistemi geliştirdiler.

Bugün, Patek Philippe, Audemars Piguet, Vacheron Constantin ve Rolex gibi İsviçre markaları, mekanik saatçiliğin zirvesini temsil etmektedir. Bu markalar, geleneksel zanaatkârlığı modern teknoloji ve yenilikle birleştirerek olağanüstü zaman ölçerler üretmeye devam etmektedir.

Otomatik Kurma Mekanizmaları

yüzyılın sonlarına doğru, otomatik kurma mekanizmaları mekanik saatlerde önemli bir yenilik haline geldi. Abraham-Louis Perrelet ve Hubert Sarton gibi mucitler, saati manüel olarak kurma ihtiyacını ortadan kaldıran sistemler geliştirdiler.

Modern otomatik saatlerin çoğu, “rotor” olarak bilinen bir ağırlığın kullanıcının doğal el hareketleriyle dönmesine dayanan bir mekanizma kullanır. Bu dönme hareketi, saatin ana yayını kuran bir dizi dişliye aktarılır, böylece saat sürekli olarak çalışmaya devam edebilir.

Bu inovasyon, mekanik saatlerin kullanışlılığını büyük ölçüde artırdı ve günümüzde lüks mekanik kol saatlerinin standart bir özelliği haline geldi.

Modern Mekanik Saatçilik ve Yeniden Canlanma

Dijital ve kuvars saatlerin 1970’lerde yaygınlaşması, İsviçre saat endüstrisini büyük bir krize sürükledi. Ancak, 1980’lerin sonlarından itibaren, mekanik saatlere olan ilgi yeniden canlandı. Bu rönesans, zamanı ölçmenin yanı sıra, mühendislik mükemmelliği ve geleneksel zanaatkârlık örnekleri olarak mekanik saatlerin takdir edilmesine dayanıyordu.

Günümüzde, mekanik saatçilik hem geleneğe saygı gösteriyor hem de sınırları zorlayan yenilikler getiriyor. Modern malzemeler ve üretim teknikleri, silikon parçalar, yeni metal alaşımları ve gelişmiş yüzey işlemleri ile geleneksel saatçilik zanaatı, doğruluk ve güvenilirliği daha da artırıyor.

Aynı zamanda, bağımsız saat yapımcıları olarak bilinen küçük atölyeler ve bireysel ustalar, sıradışı ve yenilikçi tasarımlarıyla mekanik saatçiliğin sınırlarını zorluyorlar.

Koleksiyonerlik ve Mekanik Saatlerin Değeri

Günümüzde, yüksek kaliteli mekanik saatler sadece zaman ölçüm aracı olarak değil, aynı zamanda değerli koleksiyon parçaları olarak da işlev görmektedir. Özellikle vintage veya antika mekanik saatler, saatçilik tarihi ve mühendislik ustalığının somut örnekleri olarak yüksek değer taşımaktadır.

Müzayedelerde rekor fiyatlara satılan saatler, örneğin Patek Philippe ve Rolex gibi prestijli markaların nadir örnekleri, bu mekanik harikaların sadece geçici moda ürünleri değil, nesiller boyunca değerini koruyabilen miras parçaları olduğunu göstermektedir.

Mekanik saat koleksiyonerliği, hem tarihsel hem de teknik anlayış gerektiren sofistike bir uğraş haline gelmiştir. Koleksiyoncular, belirli modellerin nadir varyantlarını, önemli komplikasyonları veya ilginç tarihi öneme sahip parçaları ararlar.

Mekanik Saatlerdeki Zanaatkârlık ve Sanatsal Değer

Mekanik saatlerin mühendislik harikaları olmanın ötesinde, aynı zamanda olağanüstü zanaatkârlık ve sanat eserleri olduğunu belirtmek önemlidir. Saat kadranlarındaki ince guilloche desenleri, el oyması köprüler ve plakaları, ve zarif ısıl mavileştirilmiş vidalar, saatçilik zanaatının estetik boyutunu vurgular.

Lüks mekanik saatlerin yapımında, her bir bileşen genellikle el ile cilalanır, süslenir ve monte edilir. Bu süreç, saat başına yüzlerce hatta binlerce saat alabilir ve nesiller boyunca aktarılan beceriler gerektirir.

Yüksek saatçilik (Haute Horlogerie) olarak bilinen bu seviyede, işlevsellik ve estetik mükemmel bir şekilde birleşir. Bu saatler, aynı zamanda işleyen sanat eserleri, tasarım örnekleri ve insan yaratıcılığının ifadeleri olarak değerlendirilir.

Mekanik Saatlerin Geleceği

Dijital çağda ve atomik saatlerin nanosaniye hassasiyetiyle zaman tutabildiği bir dünyada, mekanik saatlerin varlığını sürdürmesi ve hatta gelişmeye devam etmesi dikkat çekicidir. Bu, tamamen mekanik, insan yapımı bir cihazın dayanıklılığı ve büyüsüne dair bir kanıttır.

Gelecekte, geleneksel zanaatkârlık ile ileri teknoloji arasındaki entegrasyon muhtemelen artacaktır. Yeni malzemeler, bilgisayar destekli tasarım ve hassas üretim teknikleri, mekanik saatlerin performansını ve güvenilirliğini daha da artıracaktır.

Aynı zamanda, artan dijitalleşme ve hızla değişen tüketim kültürü karşısında, mekanik saatler, zamansız değer ve kalıcılık sembolü olarak konumlarını güçlendirebilir. Bir mekanik saat, doğru bakımla nesiller boyu çalışabilir - dijital cihazların çoğunun kısa ömrüyle çarpıcı bir tezat oluşturur.

Bugün’ün dünyasında, mekanik bir saat sadece bir zaman ölçüm aracı değil, aynı zamanda teknik mükemmellik, tarihsel süreklilik ve insan yaratıcılığı konusunda bir beyandır.

Sonuç

Mekanik saatler, yüzyıllar boyunca gelişen ve mükemmelleşen olağanüstü mühendislik harikaları olmaya devam etmektedir. Basit ağırlık tahrikli mekanizmalardan, bugünün mikroskopik toleranslarla işlenmiş karmaşık saatlerine kadar, saatçilik sanatı ve bilimi, insan zekasının ve yaratıcılığının en iyi örneklerinden biri olmuştur.

Bu mekanik şaheserler, sadece zamanı ölçmekle kalmaz, aynı zamanda insanlığın hassas mekanik sistemlere hakim olma ve zamanın kendisini evcilleştirme çabasını da temsil ederler. Küçük bir alanda yüzlerce hareketli parçanın mükemmel uyum içinde çalışması, insan başarısının ne kadar etkileyici olabileceğinin bir hatırlatıcısıdır.

Dijital çağda bile, mekanik saatlerin devam eden popülaritesi ve değeri, bu hassas makinelerin salt işlevselliğin ötesine geçen bir anlamı olduğunu göstermektedir. Bir mekanik saat, zamansız bir işçilik, yenilik ve mühendislik mükemmelliği eseridir - teknolojinin hızla ilerlediği bir dünyada, geçmişle olan bağlantımızı koruyan ve kutlayan bir nesne.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Uçaklar Nasıl Uçar? Kaldırma Kuvvetinin Fiziksel Açıklaması

Wed, 12 Mar 2025 00:00:00 GMT

Uçakların gökyüzünde süzülmesi, yerçekimine meydan okuması çoğumuz için büyüleyici bir manzaradır. Peki uçaklar gerçekten nasıl uçar? Bir uçağı havada tutan kaldırma kuvveti (lift) nasıl oluşur?

Pek çoğumuz okullarda ya da popüler bilim kaynaklarında uçağın kanadının üstünden akan havanın, altından akan havadan daha hızlı aktığı ve Bernoulli ilkesine göre basınç farkından dolayı uçakların yükseldiğini öğrendik. Ancak durum gerçekte bu kadar basit değil.

Bu makalede David Anderson ve Scott Eberhardt’ın kapsamlı açıklamaları üzerinden kaldırma kuvvetinin gerçek fiziksel yapısını inceleyeceğiz.

(David Anderson ve Scott Eberhardt’ın “How Airplanes Fly: A Physical Description of Lift” makalesinden faydalanılarak hazırlanmıştır.)

1. Uçuşun Geleneksel Açıklaması ve Sorunları

Birçok kitapta ve derste uçuşun temel prensibi olarak şu ifade edilir:

“Kanadın üst kısmından geçen hava, alt kısımdan geçen havaya göre daha hızlı hareket eder. Bernoulli prensibine göre hız arttığında basınç azalır. Böylece üst tarafta düşük, alt tarafta yüksek basınç oluşur ve uçak havaya kalkar.”

Fakat Anderson ve Eberhardt’a göre bu yaygın açıklama eksik ve yanıltıcıdır. Bu açıklama iki büyük sorunu içinde barındırır:

Yanlış Yorumlanan Bernoulli İlkesi: Kanadın üst kısmının uzunluğunun daha fazla olması, havanın üst taraftan daha hızlı geçmeye zorlandığını anlatmaz. Bu fiziksel gerçeklere uymayan bir basitleştirmedir.
Newton’un Yasalarının İhmal Edilmesi: Geleneksel anlatımda hava akışının kanadı aşağı ittiği gerçeği göz ardı edilir.

2. Kaldırma Kuvvetinin Fiziksel Temeli: Newton’un Yasaları

Anderson ve Eberhardt, kaldırma kuvvetinin açıklamasında asıl temel fiziksel prensip olarak Newton’un üçüncü yasasını (Etki-Tepki) öne sürer:

Kanat, havayı aşağıya doğru yönlendirir.
Buna karşılık olarak hava, kanadı yukarı doğru iter.
Bu karşılıklı etkileşim, uçakların yükselmesini sağlayan kaldırma kuvvetini oluşturur.

Başka bir ifadeyle, uçaklar havayı aşağı doğru ittiği ölçüde yükselir. Bu prensip aslında uçakların neden daha yüksek bir açıyla (angle of attack) kalkış yaptığını da açıklar. Açı büyüdükçe hava aşağı daha çok itilir, bu da kaldırma kuvvetini arttırır.

3. Bernoulli İlkesi Tamamen Yanlış mı?

Bernoulli ilkesi kaldırma kuvvetinde rol oynayan gerçek bir fizik yasasıdır. Ancak tek başına kaldırma kuvvetini açıklamaya yetmez. Aslında Bernoulli ilkesi, Newton’un üçüncü yasası ile birlikte ele alınmalıdır.

Kanadın üst kısmında hava gerçekten de daha hızlı akar. Ancak bu hız farkı, kanadın şekli nedeniyle değil, hava akımının kanat yüzeyine yapışma eğilimi (Koanda etkisi) nedeniyle ortaya çıkar.
Böylece kanat yüzeyinde hava aşağı doğru kıvrılarak bir dolaşım (circulation) oluşur. Bu da üst kısımda düşük basınç bölgesini yaratır. İşte Bernoulli ilkesi bu dolaşım nedeniyle düşük basınç oluşmasını açıklar.

Anderson ve Eberhardt’ın da belirttiği gibi, kaldırma kuvveti, Bernoulli prensibinin Newton mekaniğiyle birleşimi sayesinde daha doğru anlaşılır.

4. Koanda Etkisi ve Dolaşımın Rolü

Birçok kişi Koanda etkisini ilk kez duymuş olabilir. Koanda etkisi basitçe, akışkanların (hava dahil) yüzeylere yapışarak hareket etme eğilimidir. Bu etki, kanadın üst yüzeyindeki hava akımının kanada yapışarak aşağı doğru kıvrılmasına neden olur.

Bu kıvrılma ve dolaşım, havanın aşağı itilmesi anlamına gelir ve Newton’un üçüncü yasası devreye girer.
Ayrıca dolaşım (circulation), kanat çevresinde süreklilik gösteren hava akımını temsil eder ve kaldırma kuvvetinin temelinde yer alan basınç farklarını yaratır.

5. Sonuç: Kaldırma Kuvvetini Nasıl Anlamalıyız?

Bu blog yazısında ve Anderson ile Eberhardt’ın makalesinde gösterildiği gibi kaldırma kuvvetini doğru anlamak için sadece basit okul açıklamalarına değil, daha geniş bir fiziksel bağlama ihtiyacımız var. Kaldırma kuvveti:

Newton’un üçüncü yasasına göre oluşur: Hava aşağı, uçak yukarı.
Bernoulli ilkesi tek başına değil, Koanda etkisi ve dolaşım ile birlikte rol oynar.
Geleneksel açıklamalar sadece yüzeysel bir fikir verir ve çoğu zaman yanıltıcıdır.

Bu doğrulara dayanarak uçuşun fiziğini anlamak, havacılığa dair yanlış bilgilerin önüne geçecek ve daha sağlam bilimsel temellere dayanan bir öğrenme sağlayacaktır.

Kaynaklar

http://www.aviation-history.com/theory/lift.htm

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Havaalanı Pistlerinin Numaralandırılma Mantığı

Mon, 10 Mar 2025 00:00:00 GMT

Hava taşımacılığı, modern toplumların olmazsa olmaz unsurlarından biri haline gelmiştir. Dünyada her gün binlerce uçak iniş ve kalkış yaparken, havaalanları bu operasyonların güvenli ve etkili şekilde gerçekleşebilmesi için hassas bir düzen içinde tasarlanmıştır. Bu düzenin en temel öğelerinden biri, havaalanı pistlerinin isimlendirilmesi ve pist başı ile sonlarında yer alan rakamlardır. Bu makalede, havacılıkta son derece kritik olan pist numaralarının anlamı, kullanımı ve isimlendirilme sisteminin detayları kapsamlı bir şekilde incelenecektir.

Pist Numaralarının Temel Mantığı

Havaalanlarındaki pistlerin başında ve sonunda yer alan rakamlar, pistlerin yönlerini ifade etmek üzere belirlenmiştir. Pist numaraları rastgele değildir; her rakam pistin manyetik kuzeye göre olan yönüne karşılık gelir. Dünya üzerindeki her pist, manyetik kuzeye göre hizalanmıştır ve bu hizalanış açısı, pist numarasını belirler.

Örneğin, bir pistin başındaki numara 09 ise bu pist, manyetik kuzey ile yaptığı yaklaşık 90 derecelik açıyı belirtir. Dolayısıyla uçak pistin bu tarafından inişe geçtiğinde, uçağın burnu yaklaşık olarak doğuya (90° manyetik yön) bakıyor olacaktır. Eğer pist numarası 27 ise, bu pistin tam karşı ucu olduğu ve manyetik kuzeye göre 270 dereceyi işaret ettiği anlaşılır; uçak bu durumda batıya doğru (270° manyetik yön) iniş veya kalkış gerçekleştirir.

Numaralandırma Sisteminin Detayları ve Özel Durumlar

Pist numaralandırma sistemi temel olarak, manyetik pusula yönlerini esas alır ve aşağıdaki kuralları içerir:

1. Pist Numaralarının Hesaplanması

Pist numarası belirlenirken, manyetik yön 10’a bölünür ve en yakın tam sayıya yuvarlanır. Örneğin: • Manyetik yönü 183° olan bir pist, 18 olarak numaralandırılır. • Manyetik yönü 187° olan bir pist ise 19 numarasını alır (186°’dan itibaren yukarı doğru yuvarlama yapılır).

2. İki Uçlu Numaralandırma

Her pistin iki yönü olduğundan dolayı, pist numaraları her zaman birbirine zıt (180 derece farkla) olacaktır. Bu nedenle pistin bir ucu 03 ise diğer ucu 21 olacaktır (03 → 30°; 21 → 210°). Başka bir örnekle, bir pistin numaraları 04 ve 22 ise, bu pistin bir yönü 40°, karşı yönü ise 220°’yi ifade etmektedir.

3. Çift veya Üçlü Pist Durumları (Sol, Orta, Sağ)

Büyük havaalanlarında birden fazla paralel pist bulunabilir. Bu durumda pist numarasına ek olarak harf kullanılır: • “L” (Left/Sol) • “C” (Center/Orta) • “R” (Right/Sağ)

Örneğin İstanbul Havalimanı’nda paralel pistler 17L, 17C ve 17R olarak isimlendirilmiştir. Buradaki rakamlar pistlerin güney (170°) yönlü olduğunu ve “sol-orta-sağ” şeklinde sıralandığını gösterir. Paralel pistlerin varlığı, hava trafiğini yönetmede çok büyük kolaylık ve güvenlik sağlamaktadır.

4. Zaman İçinde Değişen Manyetik Yön ve Pistlerin Yeniden Numaralandırılması

Havaalanlarındaki pist numaraları, dünya üzerindeki manyetik kuzey referans alınarak belirlenir. Ancak dünyamızdaki manyetik kutupların sabit olmadığı ve zaman içerisinde sürekli hareket ettiği bilinmektedir. Bu durum, pistlerin ilk olarak belirlendiği andaki manyetik yön ile yıllar içinde oluşan manyetik yön arasında farklılıkların meydana gelmesine neden olur. Bu sebeple pist numaralarının zaman zaman yeniden gözden geçirilerek güncellenmesi gerekebilir.

Dünya’nın manyetik kuzey kutbu, jeolojik ve manyetik aktiviteler nedeniyle sürekli olarak hareket halindedir. Bu hareket, genellikle yılda birkaç kilometre ile birkaç on kilometre arasında değişebilen bir oranda gerçekleşir. Bu kayma sonucunda, bir havaalanındaki pistin gerçek manyetik yönü, ilk numaralandırmanın yapıldığı zamana göre birkaç derecelik sapma yaşayabilir. Başlangıçta örneğin 180 dereceye (18 numaralı piste) hizalanmış bir pist, manyetik kuzeyin hareket etmesiyle yıllar içinde 184 ya da 185 dereceye kayabilir. Bu durum, pist numarasının yeniden belirlenmesini zorunlu hale getirir.

Uluslararası standartlara göre, eğer pistin manyetik yönü mevcut numaralandırmasından 5 derece ya da daha fazla bir sapma gösterirse, pist numaralarının güncellenmesi gerekmektedir. Bu durum, pilotların navigasyon sistemleri ve pusulalarıyla pistin numaralarının uyumlu kalmasını sağlayarak uçuş emniyetini koruma amaçlıdır. 5 derecelik fark, bir pilotun pist yaklaşma safhasında pistten sapmasına ve inişte sorunlar yaşamasına sebep olabilecek kritik bir eşiktir.

Bu tür değişikliklerin somut örneklerinden biri, ABD’de bulunan Florida’daki Tampa Uluslararası Havalimanı’nda 2011 yılında yaşanmıştır. Havalimanındaki pistlerin manyetik yönlerinde oluşan belirgin sapmalar sebebiyle tüm pistlerin numaraları değiştirilmiş ve yenilenmiştir. Benzer şekilde, Kanada’da bulunan Calgary Uluslararası Havalimanı ve diğer birçok havaalanında da, manyetik kuzeydeki değişimlerden dolayı pist numaralarında düzenlemelere gidilmiştir.

Bu güncellemeler basit gibi görünse de, gerçekte büyük lojistik operasyonları içerir. Çünkü pist numaralarının güncellenmesi, havaalanının pist tabelalarının, navigasyon haritalarının, pilotların uçuş planlarının ve hava trafik kontrolörlerinin kullandığı tüm dokümantasyonun değiştirilmesini gerektirir. Aynı zamanda, uluslararası yayınlanan uçuş haritaları (jeppesen chart’ları gibi) ve elektronik navigasyon sistemleri üzerinde de güncellemeler yapılması zorunludur. Bu işlemler havacılık otoriteleri tarafından titizlikle koordine edilir ve genellikle önceden duyurularak havacılık sektörünün tüm paydaşlarına bildirilir.

Pist Numaralarının Kullanımının Önemi ve Güvenlik Açısından Rolü

Pist numaraları pilotlar, hava trafik kontrolörleri (ATC) ve havaalanı operasyon ekipleri için kritik öneme sahiptir. Çünkü pist numaraları, uçakların kalkış ve iniş rotalarını, özellikle de pist yaklaşmalarını belirleyen en temel referanslardır. Uçuşun en kritik aşamaları olan iniş ve kalkış sırasında hata riskini azaltmak ve operasyonel karışıklığı önlemek adına pist numaralarının net, doğru ve güncel olması zorunludur.

Ayrıca, pist numaraları meteorolojik raporlamada (METAR), uçuş planlarında ve hava trafik kontrol talimatlarında doğrudan referans olarak kullanılır. Pilotlar, özellikle düşük görüş koşullarında (sis, yoğun yağmur, kar, vs.) pist numaralarını radar ve navigasyon cihazları üzerinden görerek, doğru hizalanma ve inişi sağlarlar.

Yanlış Kullanımlar ve Riskler

Havacılık sektöründe, havaalanlarının pist başlarında ve sonlarında yer alan rakamların doğru kullanımı son derece kritiktir. Bu rakamlar uçuş operasyonlarının temel referans noktaları olduğundan, yanlış anlaşılmaları veya yanlış kullanımları ciddi kazalara ve tehlikeli durumlara yol açabilir.

Özellikle büyük ve yoğun trafiğe sahip havaalanlarında, birden fazla paralel pist bulunduğunda, pist numaralarının yanında kullanılan ek harflerin (L-Sol, C-Orta, R-Sağ) net bir şekilde anlaşılması çok önemlidir. Örneğin, bir pilotun ya da hava trafik kontrolörünün “26L” yerine “26R” pist numarasını yanlışlıkla kullanması, iniş veya kalkış esnasında farklı pistlerde bulunan diğer uçaklarla çarpışma riskini doğurabilir. Havacılık tarihinde bu tür durumların yanlış pist seçimi nedeniyle kazaya dönüşmüş örnekleri bulunmaktadır.

Ayrıca, pist numaralarının yanlış iletişimi veya yanlış okunması düşük görüş koşullarında (sis, yağmur, kar, gece şartları) daha büyük tehlike arz eder. Görüş mesafesinin sınırlı olduğu bu durumlarda, pilotlar pist numaralarını fiziksel olarak görmekte zorlanabilir ve tamamen hava trafik kontrolörlerinin verdiği bilgilere ve navigasyon cihazlarına bağımlı kalırlar. Bu noktada iletişimdeki küçük bir hata bile pilotun hatalı bir piste iniş yapmasına veya yanlış hizalanmasına neden olarak uçuş güvenliğini tehlikeye atabilir.

Bir başka kritik risk, hava trafik kontrolörü ve pilot arasındaki radyo iletişimi sırasında rakamların yanlış anlaşılması veya yanlış söylenmesidir. Radyo frekansında oluşabilecek parazitler veya yoğun trafik durumlarında hızlı konuşmalar nedeniyle pist numaralarının karıştırılması sıkça karşılaşılan bir sorundur. Bu tür durumlar, pilotun beklenmedik manevralar yapmasına veya pist ihlallerine yol açabilir, bu da son derece tehlikeli durumların oluşmasına neden olabilir.

Bu risklerin minimize edilmesi için havacılık otoriteleri ve uluslararası kuruluşlar (ICAO, FAA, EASA gibi), standart iletişim prosedürleri geliştirmiştir. Bu prosedürler doğrultusunda pilotların ve hava trafik kontrolörlerinin kullandığı terminoloji standartlaştırılmıştır. Örneğin, rakamların her zaman tek tek söylenmesi (örneğin “18” pist numarası “bir sekiz” şeklinde ifade edilir) ve talimatların tekrar edilmesi zorunludur. Ayrıca, pist numaralarının yazılı ve dijital tüm kaynaklarda güncel tutulması, pilotlara eğitim verilmesi ve düzenli tatbikatlar yapılması da kritik öneme sahiptir.

Havaalanlarında pist numaraları basit birer sayıdan çok daha fazlasıdır. Her numara, havacılık güvenliği, uçuş operasyonlarının yönetimi ve havaalanı altyapısının kullanımı için kritik öneme sahiptir. Manyetik yönü esas alan ve global çapta standartlaştırılmış olan bu numaralandırma sistemi sayesinde pilotlar ve hava trafik kontrolörleri arasında net ve güvenilir bir iletişim sağlanmaktadır. Bu sistemin doğru ve güncel tutulması, havacılıkta emniyetli operasyonlar için vazgeçilmezdir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Fransa Bisiklet Turu: Bir Tutkunun Öyküsü

Sun, 02 Mar 2025 00:00:00 GMT

Bisiklete aşık insanların takvimlerinde işaretlediği bir tarih vardır: Temmuz ayı. Bu tarih geldiğinde, Fransa’nın küçük kasabalarından büyük şehirlerine uzanan, kilometrelerce yola yayılan renkli bir heyecan başlar. Fransa Bisiklet Turu—ya da dünyaca bilinen adıyla “Tour de France”—sporun ötesine geçen, insan ruhunun dayanıklılığını ve hayata olan bağlılığını simgeleyen bir hikâyedir.

Bir Hayalin Başlangıcı: Sararmış Gazete Sayfalarından Dünyaya

Fransa Bisiklet Turu, bugün dünyanın en büyük spor etkinliklerinden biri olarak görülse de, başlangıcı aslında çok daha mütevazı ve insani bir hikâyeye dayanıyor. Bu hikâye, 1903 yılında Fransa’nın o dönemde popüler gazetesi olan L’Auto’nun editörü Henri Desgrange’ın, satışlarını artırmak amacıyla yaratıcı bir fikir arayışıyla başladı.

O yıllarda gazeteler arasındaki rekabet yoğundu ve tiraj artırmak için farklı yollar deneniyordu. Desgrange, gazetesini farklı kılmak ve okuyucuların ilgisini çekmek adına cesur bir karar verdi: Fransa’nın dört bir yanını dolaşan, dayanıklılığı ve insan iradesini ölçen, hiç görülmemiş zorlukta bir bisiklet yarışını düzenlemek. Ancak bu sıradan bir yarış olmayacaktı. Paris’te başlayıp, Lyon, Marsilya, Toulouse, Bordeaux ve Nantes gibi büyük şehirlerden geçerek tekrar Paris’e dönen yaklaşık 2400 kilometrelik dev bir rota belirledi.

O dönemin şartları göz önüne alındığında, bu karar büyük bir risk içeriyordu. Henüz modern yol altyapısı yoktu. Bisiklet teknolojisi oldukça ilkeldi; bisikletler ağır, yollar bozuk ve uzun mesafeler neredeyse imkânsız görünüyordu. Desgrange’ın fikrine ilk başta kimse inanmadı. İnsanlar bunu çılgınca buldu; hatta başarısızlıkla sonuçlanacağına kesin gözüyle bakıldı. Ama işte tam da burada insanoğlunun cesareti devreye girdi: o dönemin bisikletçileri bu zorlu mücadeleye katılmak için gönüllü oldu.

İlk tur, 1 Temmuz 1903 tarihinde Paris’ten başladı. Yarışçıların üzerinde basit kıyafetler vardı; bazıları şapka takıyor, çoğunun üzerinde yedek parça ve tamir araçları bulunan çantalar bulunuyordu. Yol boyunca onları destekleyecek teknik ekip yoktu. Yarışçılar kendi sorunlarıyla baş başaydı. Lastik patladığında, zincir koptuğunda ya da bisikletleri arızalandığında, bunu kendi başlarına çözmek zorundaydılar.

Günler süren bu yarışta, zaman zaman gece karanlığında, gaz lambalarının ve yol kenarlarında bekleyen meraklı izleyicilerin ışığında yollarına devam etmek zorundaydılar. İlk yarış o kadar zorluydu ki, 60 yarışçıdan ancak 21’i parkuru tamamlayabildi. Yarışı tamamlayan ilk isim Maurice Garin oldu ve Fransa tarihine geçti. Ancak Garin sadece yarışı kazanmakla kalmadı, aynı zamanda insanlığın azmini, mücadele ruhunu ve sınırları zorlama cesaretini temsil etti.

İlginçtir ki, yarışın başarısı, gazeteyi de büyük bir tiraj artışına taşıdı. Gazete satışları beklenenden çok daha yüksek rakamlara ulaştı ve Desgrange’ın hayali sadece sportif değil, ticari anlamda da başarılı oldu. Ancak asıl önemlisi, bu yarış insanları bir araya getirdi. Yarış güzergâhındaki her kasaba, her köy, yola çıkarak bisikletçileri karşıladı. Evlerinden yiyecek, içecek getirenler oldu, yarışçıların geçişini coşkuyla kutlayan topluluklar oluştu. Böylece Fransa Bisiklet Turu, toplumun ortak heyecanının ve birliğinin simgesi hâline geldi.

Sararmış gazete sayfalarında başlayan bu hikâye, zaman içinde büyük bir tutkuya dönüştü. Bisiklet sporu, insanların kalplerinde yer edindi. Fransa Bisiklet Turu’nun başlangıcı, insanın kendi sınırlarını aşma arzusunun, dayanışmanın ve cesaretin hikâyesiydi. Bugün, dünyanın her yerinden milyonlarca insanın izlediği bu dev organizasyon, aslında o ilk yarışın mücadeleci ruhunu ve insanoğlunun sınırsız hayal gücünü temsil etmeye devam ediyor.

İnsanlık, Cesaret ve Azim

Fransa Bisiklet Turu’nun arkasında gizli olan, bazen kamera objektiflerine takılmayan, ama kalplere dokunan öyle hikâyeler vardır ki, bu yarışa anlamını asıl onlar kazandırır. Bu hikâyeler cesaretin, dayanıklılığın ve insan ruhunun azminin öyküsüdür. Her yıl Temmuz ayında yaşanan mücadele, yalnızca fiziksel dayanıklılığın sınırlarını zorlamakla kalmaz, aynı zamanda yarışanların kalplerinde derin bir iç hesaplaşmaya dönüşür.

Bisikletçiler, pedal çevirmeye başladıkları anda kendileriyle uzun ve acımasız bir yarışa girişirler. Her bir pedal çevirişinde kendilerine meydan okurlar. Bisiklet sürmek, aslında hayatın simgesidir; bazen dik yokuşlar, bazen virajlar, bazen ise umulmadık inişler sunar. Ancak Fransa Bisiklet Turu’nu bu kadar eşsiz kılan şey, bisikletçilerin, hayatta olduğu gibi, her zorluk karşısında daha da güçlenerek yollarına devam etme kararlılığıdır.

Düşünün ki, bisikletçiler Alp Dağları’nın ürkütücü dikliğine ulaştıklarında, bacaklarının ağrısıyla mücadele ederken zihinsel olarak da çok farklı bir sınav verirler. Bazen kendilerine şu soruları sordukları olur: “Burada ne işim var? Devam etmeli miyim?” Ancak her seferinde kalplerindeki o derin motivasyonu bulurlar. Çünkü yarışçılar bilir ki, asıl zafer, bedenlerinden çok ruhlarında gerçekleşir.

Bazen bu mücadele öyle yoğunlaşır ki, insanın dayanıklılığını ve cesaretini yeniden tanımlamak gerekir. 2016 yılında yarışan İngiliz bisikletçi Chris Froome’un yaşadığı o dramatik sahneyi unutmak mümkün mü? Froome, Mont Ventoux’nun zorlu yokuşlarında yaşadığı kaza sonrasında bisikleti kullanılamaz hale gelince, hiç tereddüt etmeden koşarak zirveye doğru ilerlemeye başlamıştı. O an, yalnızca yarışın kuralları ya da sporcunun kararlılığından fazlasını ifade ediyordu; bu, insan ruhunun asla pes etmediğini, cesaretin ve azmin her zaman kazanacağını simgeliyordu.

Bisikletçilerin bu tür mücadelelerine tanık olan seyirciler de onlardan ilham alır. Yol kenarında bekleyenler, bisikletçilere sadece tezahürat etmezler, aynı zamanda onların duygusal mücadelesine ortak olurlar. İniş çıkışlı hayatlarının bir parçasını da o bisikletçilerde bulurlar. Çünkü bisikletçiler pedal çevirdikçe, aslında insanların hayatla kurdukları mücadeleyi ve hiç bitmeyen umutlarını simgelerler. Yaşlısından gencine, her izleyici, yarışçıların bu kararlılığı karşısında kendi hayat mücadelesinden parçalar bulur.

Fransa Bisiklet Turu’nu kazanmak elbette büyük bir onurdur, ancak birçok bisikletçi için esas mesele kazanmak değildir. Esas mesele, insanlığın içindeki o yenilmez ruhu göstermektir. İşte tam da burada, yarışın gerçek anlamı ortaya çıkar: hiçbir fiziksel engel, insanın içindeki irade ve tutkunun önünde duramaz.

Her pedal darbesinde, her tırmanışta ve her finiş çizgisinde tekrarlanan bir mesaj vardır: İnsan ruhunun gücü, insanın bedeninden çok daha büyüktür. Cesaretin, dayanıklılığın ve azmin sınırları yoktur. Fransa Bisiklet Turu, insanlığın bitmeyen mücadele ruhunun, tutkusunun ve azminin muhteşem bir kutlamasıdır.

Ve yarış sona erdiğinde, geriye sadece sonuç tablosundaki isimler değil; yarışanların, onları destekleyen insanların ve hatta dünyanın dört bir yanında izleyen milyonların kalplerinde, insanlığın cesaretine ve dayanıklılığına dair unutulmaz bir iz kalır. İşte bu, Fransa Bisiklet Turu’nun insana ve yaşama verdiği en büyük armağandır.

Turun Kalbindeki İnsanlar

Fransa Bisiklet Turu’nun ruhu yalnızca bisikletçilerden değil, onlara kilometreler boyunca eşlik eden, yollar boyunca dizilen milyonlarca insandan oluşur. Bu insanların hikâyeleri, turun gerçek duygusal kalbini oluşturur. Her yıl, Fransa’nın küçük köylerinden, tarihi şehirlerine kadar uzanan yollar boyunca toplanan bu insanlar, turun belki de görünmez ama en değerli kahramanlarıdır.

Günler öncesinden başlayarak, yarış güzergâhındaki köylerde ve kasabalarda tatlı bir telaş başlar. İnsanlar yarış günü geldiğinde, evlerinin önüne sandalyelerini çıkarır, sofralarını hazırlar ve geçecek bisikletçileri bekler. Yarıştan saatler önce yol kenarında bir araya gelen aileler, çocuklar, gençler ve yaşlılar bir festival havasında sohbet eder, şarkılar söyler, heyecanla bisikletçilerin gelmesini beklerler. Bu bekleyiş bile başlı başına unutulmaz bir deneyimdir.

Özellikle Fransa’nın küçük kasabalarında, bu yarış gerçek anlamda bir bayramdır. Köyün yaşlıları, gençlerin hazırladığı pankartları taşır, çocuklar ise hayran oldukları bisikletçilerin formalarını giymiş, ellerinde bayraklar ve balonlarla, gözleri parlayarak yolları gözetler. Yol kenarında saatlerce bekleyen bu insanların gözlerinde, heyecan, sabır ve umut dolu bekleyiş iç içe geçer.

Bisikletçiler geçerken, seyircilerin yüzlerindeki ifade paha biçilemezdir. Birkaç saniyelik bu an, sanki sonsuza dek hatırlanacakmış gibi insanların hafızasına kazınır. Kimi zaman bu an, bisikletçilerden birinin seyircilerin uzattığı su şişesini kabul ettiği, küçük bir çocuğa el salladığı ya da yaşlı bir teyzeyle kısa bir göz teması kurduğu küçük, insani anlardır. Ama işte bu küçücük anlar, seyirciler için ömür boyu unutulmaz anılara dönüşür.

Fransa Bisiklet Turu’nda seyircilerle yarışçılar arasında sessiz bir anlaşma vardır; yarışçılar onlardan güç alır, seyirciler de bisikletçilerin o büyük azminden ilham alırlar. Yolların kenarında saatlerce bekleyen bu insanlar, bisikletçilerin taşıdığı insanüstü mücadele ruhuna ortak olur. Özellikle zorlu dağ etaplarında, yorgunluktan tükenmiş bisikletçilerin isimlerini bağırarak onları motive eden seyirciler, aslında yarışçıların fiziksel gücünden çok kalplerine hitap ederler. İşte bu anlarda, bisikletçilerle seyirciler arasındaki bağ, sadece saniyeler içinde kalplerden kalplere ulaşır.

Bu insanlar arasında, hikâyeleriyle unutulmaz olan pek çok kişi vardır. Her yıl Mont Ventoux’nun zirvesinde, yarışçıları geleneksel kıyafetleriyle karşılayan yaşlı çift, Alp Dağları’nın eteklerinde sabahın erken saatlerinde evlerinde yaptıkları kekleri dağıtan kadınlar, küçük bir köyde yarışın geçtiği tek caddenin kenarına yerleşen ve yarışçılara limonata uzatan çocuklar… Bu insanlar Fransa Bisiklet Turu’nun gerçek kahramanlarıdır ve onların samimiyeti, turun ruhunu her yıl yeniden yaratır.

Turun kalbindeki insanlar, aslında yarışın anlamını çok iyi kavramıştır: bisikletçiler zafer peşinde koşarken, seyirciler onlardan umut, cesaret ve yaşam enerjisi toplar. Bu karşılıklı paylaşım, turun aslında sadece bir bisiklet yarışı değil, insanların birbiriyle ve hayatla bağlarını güçlendirdiği ortak bir hikâye olduğunun en büyük kanıtıdır.

Ve Fransa Bisiklet Turu sona erdiğinde, bisikletçiler kürsüye çıkarken alkışlar sadece onları değil, bu muhteşem öykünün gerçek yaratıcıları olan, kilometreler boyunca onların yanında duran, umutlarıyla ve sevgileriyle onlara destek olan bu görünmez kahramanları da selamlar.

Çünkü Fransa Bisiklet Turu’nun gerçek güzelliği, bisikletlerin hızında değil, yol kenarında toplanan insanların kalplerinde saklıdır.

Bisikletin Ötesinde Bir Anlam

Fransa Bisiklet Turu’nu sadece bir spor organizasyonu olarak görmek büyük bir eksiklik olur. Çünkü bisiklet, bu yarışta pedal çevirmekten, hızdan ve güçten çok daha fazlasını ifade eder. Bisiklet, hayatı, insanlığı, doğaya saygıyı ve sürdürülebilir geleceği simgeleyen bir metafordur aslında.

Bisikletin doğuşu, endüstriyel çağın hızlı ve karmaşık dünyasında insanları tekrar sade ve huzurlu bir yaşama davet eder gibidir. Pedal çevirirken hissedilen rüzgarın özgürleştirici etkisi, hareket etmenin en sade ve en insani halini hatırlatır bizlere. İşte Fransa Bisiklet Turu da bu sadeliğin, bu insaniyetin dev bir kutlamasıdır.

Bu yarış, şehirleri, ülkeleri ve kültürleri birbirine bağlar. Yarış boyunca bisikletçiler, Fransa’nın eşsiz doğal güzelliklerinden, tarihi köylerinden ve kasabalarından geçerken aslında dünyaya önemli bir mesaj verirler: doğanın güzelliğine sahip çıkmak ve onu korumak, insanlığın en önemli görevlerinden biridir. Bu anlamda Fransa Bisiklet Turu, insanlara doğa ve çevreyle barışık bir yaşamın mümkün olduğunu gösterir. Pedal gücüyle çalışan bu iki tekerlekli mucize, doğaya zarar vermeden, çevreye saygılı şekilde ulaşımın ve hareketin mümkün olduğunun sembolü haline gelir.

Bisiklet aynı zamanda insan sağlığına ve yaşam kalitesine dair çok güçlü bir mesaj taşır. Turu izleyen milyonlarca insan, bisikletçilerin dayanıklılığı ve fiziksel gücünden etkilenerek bisiklete yönelir. İnsanlar, bisiklet kullanımının bireysel sağlıklarına katkısını gördükçe, hayatlarını daha sağlıklı ve aktif hale getirmenin mümkün olduğunu anlar. Bisikletin günlük yaşamda kullanımı, trafik sorunlarına çözüm sunar, şehirleri insan merkezli hale getirir ve toplumsal yaşamın kalitesini yükseltir.

Fransa Bisiklet Turu, bisikletin bu sosyal yönünü çok güçlü bir şekilde vurgular. Yarış boyunca şehirlerde yaşanan büyük coşku, toplumsal birliğin, paylaşmanın ve birlikte hareket etmenin ne kadar değerli olduğunu gösterir. Bisikletin insanları bir araya getirme gücü, farklı sosyal kesimleri aynı yolda buluşturur. Yarış, zengin-fakir, genç-yaşlı ayırt etmeksizin herkese hitap eder ve böylece toplumsal dayanışmanın simgesi haline gelir.

Ayrıca bisiklet yarışı, insanın kişisel sınırlarını zorlamasını, kendi potansiyelini keşfetmesini simgeler. Tur boyunca pedal çeviren her bisikletçi, kendi içinde büyük bir mücadele verir. Bu mücadele, izleyicilere yaşamda karşılaşılan güçlüklerin üstesinden gelmenin mümkün olduğunu gösterir. Bisikletçiler, fiziksel engellerin yanı sıra zihinsel engelleri de aşarlar ve bu yönüyle hayatın zorluklarına karşı nasıl direnç gösterileceğinin, cesaretle mücadele etmenin önemini anlatırlar.

Tarih boyunca Fransa Bisiklet Turu, bisikletin temsil ettiği bu değerlerle milyonlarca insana ilham verdi. İkinci Dünya Savaşı’nın ardından yarışın yeniden başlaması, bisikletin umudun simgesi olduğunu ve savaşın karanlığından çıkmak isteyen insanların kalplerindeki yaşam sevgisini canlandırdığını gösterdi. Bugün bile, bisikletçiler pedal çevirdikçe, insanlığın daha iyi bir geleceğe duyduğu inancı yenilerler.

Turun sonu geldiğinde, bisikletçiler madalyalarını alır ve sahneden çekilir, ancak geride kalan şey çok daha büyüktür. Yarışın ardından, bisikletin bu derin anlamı insanların kalplerinde yaşar. Belki de bu yüzden Fransa Bisiklet Turu sadece sporun değil, aynı zamanda insanlık değerlerinin, doğaya ve yaşama saygının ve sürdürülebilir bir geleceğe dair umutların en büyük temsilcilerinden biridir.

Bisiklet, Fransa Bisiklet Turu’nda artık bir araçtan çok daha fazlasıdır. O, insanlığın ortak değerlerinin, doğanın güzelliğinin, yaşam sevincinin ve birlik olmanın sembolüdür. Bu yüzden her pedal darbesinde, bisikletin ötesinde, hayatın ta kendisini buluruz.

Tarihte İz Bırakan Anlar

Fransa Bisiklet Turu’nun tarihi, yalnızca bisikletçilerin mücadelesinden ibaret değildir; aynı zamanda unutulmaz anların, insan hikâyelerinin, sevinç ve hayal kırıklıklarının birleşiminden oluşan destansı bir öyküdür. Yüz yılı aşkın bir zamandır, turun her anı tarihin sayfalarında iz bırakan dramatik sahnelerle doludur.

İlk Yarış ve Efsanenin Doğuşu (1903): 1903 yılında gerçekleşen ilk Fransa Bisiklet Turu, tarihin dönüm noktalarından biridir. 1 Temmuz günü Paris’ten yola çıkan bisikletçiler, günler süren, zor şartlarla dolu bir mücadeleyi başlattılar. Yarışın ilk şampiyonu Maurice Garin, tarihe adını kazırken, aslında sadece bir sporcu değil, insan azminin de ilk sembollerinden biri oldu. Yarışın başarısı, sonraki yıllarda katlanarak artan bir tutkunun başlangıcını temsil ediyordu.
Eugène Christophe ve Kırık Çatalın Hikâyesi (1913): 1913 yılında, Eugène Christophe bisikletinin çatalının kırılmasıyla unutulmaz bir hikâye yarattı. Christophe, yarışı bırakmak yerine, bisikletini sırtına aldı ve tamirci bulana kadar kilometrelerce yürüdü. Tamirhanede kendi elleriyle bisikletini onaran Christophe, yarışı kazanamasa da cesaretin, kararlılığın ve mücadelenin sembolü olarak Fransa tarihine geçti.
Savaşların Gölgesinde Bisiklet Tutkusu (1947): İkinci Dünya Savaşı nedeniyle Fransa Bisiklet Turu 1940-1946 arasında gerçekleşmedi. Savaş sonrası, 1947 yılında turun yeniden başlaması, sadece sportif değil, aynı zamanda sosyal ve duygusal bir zaferdi. İnsanlar yaralarını bisiklet yarışıyla sarmaya çalıştılar ve yarış, umudun, yeniden doğuşun sembolü oldu.
Eddy Merckx ve Rakipsiz Yıllar (1969-1974): Belçikalı bisikletçi Eddy Merckx, 1969-1974 yılları arasında adını tur tarihine altın harflerle yazdırdı. “Yamyam” lakaplı Merckx, bitmek bilmeyen hırsı ve enerjisiyle tam beş kez Fransa Bisiklet Turu’nu kazandı. Onun dominasyonu, bisiklet tarihinin en etkileyici dönemlerinden biri olarak kabul edilir. Merckx sadece yarışları değil, seyircilerin kalbini de kazanmıştı.
Bernard Hinault’nun Kararlılığı (1985): Bernard Hinault, 1985 yılındaki turun en zorlu etaplarından birinde geçirdiği ciddi bir kazaya rağmen yarışı bırakmayı reddetti. Yüzünde kan ve acı ifadesiyle pedal çevirmeye devam eden Hinault, yarışı bitirdiğinde, kazanamasa da yarış tarihinin en büyük kahramanlarından biri oldu. Bu an, insan iradesinin ve dayanıklılığın unutulmaz bir simgesiydi.
Greg LeMond ve 8 Saniyelik Zafer (1989): 1989’da Fransa Bisiklet Turu tarihinin en dramatik finişlerinden biri yaşandı. Amerikalı bisikletçi Greg LeMond, son etapta Laurent Fignon’u sadece 8 saniyelik bir farkla geçerek tarihin en küçük farkıyla turu kazandı. Bu, Fransa Bisiklet Turu’nun unutulmaz anlarından biri olarak, hâlâ bisiklet tutkunlarının hafızalarında canlılığını koruyor.
Lance Armstrong ve Yıkılan Bir Efsane (1999-2005): Lance Armstrong’un hikâyesi, bisiklet tarihinin en karmaşık ve dramatik anlarından biridir. Kanserle verdiği mücadeleyi kazanarak peş peşe 7 kez tur şampiyonu olan Armstrong, yıllar sonra doping yaptığı gerekçesiyle tüm unvanlarını kaybetti. Armstrong’un hikâyesi, bisiklet sporunda zafer ve trajedinin ne kadar yakın olabileceğinin simgesidir.
Chris Froome ve Mont Ventoux (2016): Chris Froome’un 2016’da Mont Ventoux etabındaki inanılmaz kazası, bisiklet tarihinin unutulmaz sahnelerinden biridir. Froome, kaza sonucu bisikleti kırılınca, yarışa koşarak devam etti ve herkesi şaşırtan, yürekleri titreten bir azim gösterdi. Bu sahne, asla pes etmeyen bir sporcunun sembolü hâline geldi.
Sloven Genç Yıldız: Tadej Pogačar (2020): 2020 yılında Tadej Pogačar, henüz 21 yaşındayken Fransa Bisiklet Turu’nu kazanarak tarihe geçti. Genç Sloven bisikletçi, son günkü zaman yarışında gösterdiği olağanüstü performansla yarışı son anda lehine çevirdi. Bu zafer, genç yeteneklerin tur tarihinde yeni sayfa açabileceğinin göstergesi oldu.
Jonas Vingegaard ve Danimarka’nın Gururu (2022-2023): 2022 ve 2023 yıllarında arka arkaya Fransa Bisiklet Turu’nu kazanan Danimarkalı bisikletçi Jonas Vingegaard, bisiklet tarihine güçlü bir giriş yaptı. Özellikle dağ etaplarında gösterdiği performansla tur izleyicilerini etkileyen Vingegaard, bisiklet sporunun heyecanını yeniden canlandırdı ve gelecek yıllar için yeni bir rekabet döneminin başladığını müjdeledi.

Fransa Bisiklet Turu’nun tarihi bu unutulmaz anlarla örülüdür. Bu olaylar, yalnızca sporda değil, insanlık tarihinde de iz bırakmıştır. Bu anlar, insanların mücadele gücünü, dayanıklılığını ve tutkusunu simgeler. Ve bu yüzden Fransa Bisiklet Turu, sadece bir yarış değil, tarih boyunca unutulmayacak hikâyelerin yaşandığı bir efsanedir.

Turun Bugün Bize Öğrettikleri

Fransa Bisiklet Turu, yalnızca profesyonel sporcuların katıldığı bir yarış olmanın çok ötesinde, her yıl milyonlarca insana yaşama dair önemli dersler veren bir hayat okuludur aslında. Bu tur, pedal çevirenlerin ve onları izleyenlerin hayatına anlam katan, insana kendi hikâyesini yeniden yazdıran bir yolculuktur. Bugün geriye dönüp baktığımızda, Fransa Bisiklet Turu’nun bizlere öğrettiği çok kıymetli dersler vardır.

Asıl Yarış Başkalarıyla Değil, Kendimizle Olandır

Fransa Bisiklet Turu, her bisikletçinin önce kendiyle verdiği bir mücadeledir. Zirvelere tırmanırken, bedensel sınırları zorlanırken, bisikletçiler rakiplerinden önce kendi zihinsel engelleriyle yarışırlar. Bu yarış bize, hayatımızdaki en büyük engellerin dışarıda değil, içimizde olduğunu öğretir. Yarışçıların yokuşları aşma kararlılığı, kendi korkularımızı, şüphelerimizi ve içimizdeki direnci aşmamız gerektiğini bize gösterir. Turu izlerken anlarız ki, en büyük rakibimiz aslında içimizdeki o “pes et” diyen sestir ve bunu aşmanın yolu kararlı bir iradeye sahip olmaktır.

Mücadele Vazgeçmemektir

Fransa Bisiklet Turu’nun en çarpıcı mesajlarından biri, mücadele ruhunun asla bitmemesi gerektiğidir. Yarışçılar düşer, sakatlanır, bisikletleri bozulur ama her defasında yeniden kalkıp pedala basmaya devam ederler. İşte bu sahneler, hayatımızda karşılaştığımız zorluklar karşısında bizi yeniden ayağa kalkmaya teşvik eder. Mücadelenin gerçek anlamının, düşmemekte değil, düştükten sonra tekrar ayağa kalkıp devam etmekte olduğunu bize hatırlatır. Fransa Bisiklet Turu, umudun ve yeniden başlama cesaretinin en güçlü simgelerinden biridir.

Başarı Emek ve Sabır Gerektirir

Turu izlerken, başarıya ulaşmanın hiçbir zaman kolay olmadığını anlarız. Yarışı kazanan isimler, yıllarca süren yoğun antrenmanların, fedakârlıkların ve emeklerin sonucunda zirveye çıkarlar. Bisikletçiler, bazen yıllarca zafer kazanamaz, ancak sabırla ve azimle çalışmaya devam ederler. Tur, bize sabrın değerini, emek verilmeden büyük zaferlerin mümkün olmadığını öğretir. Başarının bir gecede gelmediğini, başarının ardında uzun yılların sessiz, fedakâr emeğinin yattığını fark ederiz.

Takım Olmanın Gücü

Fransa Bisiklet Turu, görünürde bireysel bir spor olsa da aslında büyük bir takım çalışmasının ürünüdür. Bisikletçiler birbirlerinin önünü açar, takım arkadaşlarını destekleyerek rüzgârın etkisini azaltır, güçlerini paylaşırlar. İşte bu dayanışma, takım olmanın hayatımızdaki önemini gösterir. Bize yalnızca birlikte hareket ettiğimizde güçlü olduğumuzu hatırlatır. Tur boyunca bisikletçilerin dayanışmasını izlerken, hayatımızdaki sorunları çözmek için birbirimize destek olmamız gerektiğini anlarız.

Hayatta Her Zorluk Geçicidir

Bisikletçiler dağları tırmanırken, acının ve yorgunluğun zirvesini yaşarlar. Ancak her zirveden sonra inişlerin, her zorluktan sonra rahatlamanın geleceğini de bilirler. Fransa Bisiklet Turu, bize hayatın da böyle olduğunu anlatır: Hiçbir acı sonsuza dek sürmez. Hayatta karşılaştığımız zorlukların geçici olduğunu, sabır ve dayanıklılıkla, mutlaka bir çıkış yolu bulabileceğimizi hatırlatır. Bu düşünce, zorlu anlarımızda bize umut verir, geleceğe daha güvenle bakmamızı sağlar.

Doğaya ve Yaşama Saygı

Fransa Bisiklet Turu’nun belki de günümüzdeki en önemli mesajı doğaya ve çevreye duyduğumuz saygıyı hatırlatmasıdır. Bisiklet, doğayla dost, çevreye zarar vermeyen sürdürülebilir bir yaşamın sembolüdür. Bu yarış sayesinde, doğaya ve çevremize daha iyi davranmak, onu korumak ve gelecek nesillere temiz bir dünya bırakmak konusunda bilinçleniriz. Bisiklet yarışının temsil ettiği yaşam biçimi, gezegenimizi koruma sorumluluğumuzun simgesidir.

Hayallerin Peşinden Gitmek

Son olarak Fransa Bisiklet Turu, hayallerimizin peşinden gitmenin ne kadar kıymetli olduğunu hatırlatır bizlere. Yarışa katılan her bisikletçi, aslında kendi hayalinin peşinden koşar. Bu yarış bize gösterir ki, büyük hayaller kurmak, onları gerçekleştirme arzusu taşımak hayatın anlamını oluşturur. Bisikletçiler pedal çevirdikçe biz de kendi hayallerimize daha sıkı sarılırız. Her pedal darbesi, her zorluk, her başarı ve her başarısızlık, bize hayal kurmaktan ve o hayallere ulaşmak için çalışmaktan vazgeçmememizi öğretir.

Fransa Bisiklet Turu’nun öğrettikleri, bisiklet yarışlarının çok ötesindedir. Bu tur, insanlığın ortak değerlerinin, cesaretin, dayanıklılığın ve umudun eşsiz bir kutlamasıdır. Bu yüzden pedallar her çevrildiğinde, insanlar sadece bisiklet yarışını değil, yaşamın kendisini izlerler. Çünkü hayatın anlamı, aslında Fransa Bisiklet Turu’nda saklıdır.

Fransa Bisiklet Turu, bisiklet yarışının çok ötesinde, insanlığın tutku, cesaret, azim ve dayanışma hikâyelerini içinde barındıran eşsiz bir yolculuktur. Tarihin sararmış gazete sayfalarından başlayıp milyonların kalbine ulaşan bu yarış, hem bisikletçilere hem de onları izleyen insanlara hayatta vazgeçmemeyi, sabretmeyi, hayallerin peşinden koşmayı ve doğaya saygı duymayı öğretir. Yüz yılı aşkın süredir devam eden bu muhteşem tur, bizlere yalnızca şampiyonları değil, daha önemlisi insan ruhunun sınırsız gücünü ve umudu hatırlatmaya devam ediyor. İşte tam da bu yüzden Fransa Bisiklet Turu, insanların kalbinde daima özel ve anlamlı bir yere sahip olmaya devam edecek.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Chandy-Lamport Algoritması: Dağıtık Sistemlerde Küresel Durum Nasıl Görüntülenir?

Sun, 23 Feb 2025 00:00:00 GMT

Dağıtık sistemler, birden fazla bağımsız sürecin veya düğümün (node) ortak bir amaç doğrultusunda işbirliği yaptığı sistemlerdir. Modern teknoloji dünyasında mikroservis mimarilerinden, bulut (cloud) altyapılarına kadar pek çok alanda yaygın bir şekilde kullanılmaktadırlar.

Küresel durum (global state), bir dağıtık sistemi oluşturan tüm süreçlerin ve bu süreçler arasındaki iletişim kanallarının o andaki durumlarının birleşimidir.
Dağıtık bir sistemde küresel durumun belirlenmesi; hata tespiti, checkpointing, hata toleransı ve işlem koordinasyonu gibi konularda kritik bir rol oynar.

Fakat burada büyük bir sorun vardır: Dağıtık sistemlerde, tek bir küresel saat (global clock) veya tüm düğümleri aynı anda “donduran” bir mekanizma bulunmadığından, “O an” kavramı her düğüm için farklı olabilir. Bu durum tutarlı bir küresel durumun yakalanmasını zorlaştırır. Chandy-Lamport Algoritması bu sorunu çözmek için geliştirilmiş klasik bir metottur.

Dağıtık Sistemlerde Küresel Durum Kavramı

Dağıtık bir sistemde:

Süreçler (Processes): Her biri bağımsız çalışan genellikle bir işlemci, bir çekirdek veya bir program parçası.
İletişim Kanalları (Channels): Süreçler arasındaki mesaj iletim yolları. Bu kanalların kendine özgü gecikmeleri veya sıralama sorunları olabilir.

Bir süreç yerel durum (local state) olarak adlandırılan kendi belleği, kaydedilmiş değişkenleri, veri yapılarını vs. saklar. Küresel durum tüm süreçlerin yerel durumlarının ve süreçler arası kanallarda bulunan mesajların birleşiminden oluşur.

Chandy-Lamport Algoritması’nın Tarihçesi ve Önemi

Chandy-Lamport Algoritması, K. Mani Chandy ve Leslie Lamport tarafından 1985 yılında yayımlanan “Distributed Snapshots: Determining Global States of Distributed Systems” başlıklı makalede tanıtılmıştır. Bu makale dağıtık sistemlerde tutarlı snapshot (anlık görüntü) alma problemine getirdiği çözüm ile literatürde çığır açmıştır.

Algoritma, o zamandan bu yana:

Checkpointing: Dağıtık sistemin o andaki durumunu kaydedip, bir hata sonrası bu duruma geri dönme.
Hata tespiti: Örneğin “hangi süreçler çalışıyor, hangileri çalışmıyor” gibi durumların gözlemlenmesi.
Deadlock tespiti ve analizi: Bazı süreçler kaynak bekleyerek sıkıştığında küresel durumun analizi gerekir.

gibi birçok alanda temel bir çerçeve sunmuştur.

Algoritmanın Temel İlkeleri

Chandy-Lamport Algoritması şu basit ama etkili fikre dayanır:

Marker (İşaretleyici) Kullanımı: Bir süreç anlık görüntü (snapshot) başlatmaya karar verdiğinde, kendi durumunu kaydeder ve diğer süreçlere özel bir marker mesajı gönderir.
Koordinasyon: Marker mesajı alan süreçler, eğer bu marker’ı ilk kez görüyorsa, kendi durumlarını da kaydedip marker’ı başkalarına yollar.
Kanal Durumu Kaydı: Her süreç marker mesajından önce ve sonra gelen mesajları takip ederek kanal durumunu tutarlı şekilde belirler.

Bu sayede tüm süreçler zamansal olarak ayrık ancak mantıksal olarak tutarlı bir snapshot elde edebilirler.

Algoritmanın Adımları

Chandy-Lamport Algoritması üç temel aşamadan oluşur:

Snapshot (Anlık Görüntü) Başlatma
- Bir süreç (örneğin P_1), kendi yerel durumunu kaydeder.
- Tüm komşu süreçlere birer marker mesajı gönderir.
Marker Mesajının Alınması
- Başka bir süreç (ör. P_2), eğer bu algoritmayı ilk kez başlatıyorsa:
  - Kendi yerel durumunu kaydeder.
  - Tüm komşularına marker mesajı gönderir.
  - Marker mesajı gelmeden önce alınan mesajları ilgili kanalın parçası olarak kaydeder.
- Eğer süreç zaten bir snapshot başlatmışsa ve marker mesajını ikinci kez görüyorsa, bu marker sadece kanal durumunu tamamlamak için kullanılır.
Kanal Durumunu Kaydetme
- Bir kanalın durumu, marker mesajı geldiği andan itibaren veya marker’ı gönderdikten hemen sonraki mesaj trafiği ile ilişkilendirilir.
- Böylece, kanalın o anki içeriği (gelen ama henüz işlenmemiş mesajlar) kaydedilmiş olur.

Kanal (Channel) Durumlarının Kaydedilmesi

Kanal durumu bir sürecin marker mesajını gönderdikten (veya aldıktan) sonra kanal üzerinden geçen mesajlarla ilişkilendirilir. Daha kesin olmak gerekirse:

Bir süreç marker’ı kaydedip gönderene kadar kanal durumu kendi içinde “tamamlanmamış” kabul edilir.
Marker mesajı alındıktan sonra başka bir süreç, bu kanaldan gelen mesajları biriktirmeye başlar. O mesajlar snapshot’ın parçası haline gelir.

Özellikle marker mesajı almadan önce gelen mesajlar, kanal durumunun kaydedilmesine dahil olmaz. Çünkü o mesajlar zaten o kanalın önceki snapshot ile ilişkilendirilmiş ya da sürecin yerel durumuna dahil edilmiştir.

Ayrıntılı Bir Örnek Senaryo

Üç süreçten oluşan (P_1, P_2, P_3) bir dağıtık sistem düşünelim. Her bir sürecin birbiriyle etkileşimi şu şekilde olsun:

P_1 ↔ P_2
P_2 ↔ P_3
P_1 ↔ P_3

Yani, tam bağlı (fully connected) bir topolojiye sahibiz.

Snapshot Başlatma (P_1)
- P_1 kendi durumunu kaydeder. Diyelim ki P_1’in “belleğindeki değer: x=10”, “işlem sayısı: 3” olsun.
- P_1, P_2 ve P_3‘e marker mesajları gönderir.
Marker Mesajını P_2 Alır
- Eğer P_2 daha önce marker mesajı almadıysa (ilk defa alıyor):
- P_2 kendi durumunu kaydeder. (Örneğin: y=20, işlemler=5)
- P_2, hem P_1 hem P_3‘e marker mesajı gönderir. (Aslında P_1’e de gönderir ancak P_1 marker’a sahip olduğu için sadece kanal durumunu tamamlar.)
Marker Mesajını P_3 Alır
- Aynı mantıkla, P_3 kendi durumunu kaydeder. (z=15, işlemler=7)
- P_3, diğer iki sürece marker gönderir.
Kanal Durumlarının Kaydedilmesi
- P_2, P_3’ten marker gelmeden önce P_3’e bazı mesajlar göndermiş olabilir. Eğer bu mesajlar marker’dan önce çıktı ve marker’dan sonra teslim alındıysa, bu mesajlar “giden ama henüz işlenmemiş” bir duruma düşebilir. Dolayısıyla kanal durumuna dahil edilir.

Bu adımların tamamlanmasıyla üç sürecin de yerel durumları ve aralarındaki kanallarda “bekleyen” mesajlar kaydedilerek tam, tutarlı bir snapshot oluşturulur.

GoLang ile Kod Örneği

Aşağıda Chandy-Lamport algoritmasının basitleştirilmiş bir simülasyonunu kodlamaya çalışacağız. Örnek üç süreç (goroutine) arasında mesaj alışverişini ve bir marker mesajını nasıl işlediklerini göstermektedir.

Lütfen dikkat: Aşağıdaki kod tam bir üretim kodu değildir, daha çok eğitici bir amaç taşır. Dağıtık sistemlerde gerçek mesajlaşma genellikle ağ üzerinden gerçekleşir; burada, Go’nun chan (channel) mekanizması ile bir benzetim (simulation) yapıyoruz.

package main

import (
    "fmt"
    "sync"
    "time"
)

// We will define a simple structure to hold the state of each process
type Process struct {
    id            int
    localState    int
    hasRecorded   bool
    markerChannel chan bool
    messageChan   chan int
    wg            *sync.WaitGroup
}

// Global wait group for all processes
var wg sync.WaitGroup

func main() {
    // Create 3 processes
    process1 := Process{
        id:            1,
        localState:    10,
        hasRecorded:   false,
        markerChannel: make(chan bool, 1),
        messageChan:   make(chan int, 10),
        wg:            &wg,
    }
    process2 := Process{
        id:            2,
        localState:    20,
        hasRecorded:   false,
        markerChannel: make(chan bool, 1),
        messageChan:   make(chan int, 10),
        wg:            &wg,
    }
    process3 := Process{
        id:            3,
        localState:    30,
        hasRecorded:   false,
        markerChannel: make(chan bool, 1),
        messageChan:   make(chan int, 10),
        wg:            &wg,
    }

    // We will use one channel to simulate message passing between each pair
    // But for clarity, let's just consider processes sending messages to each other in a ring or fully connected scenario
    // Here, we simulate a fully connected pattern in a simplistic manner

    wg.Add(3)
    go process1.run(&process2, &process3)
    go process2.run(&process1, &process3)
    go process3.run(&process1, &process2)

    // Start the system for a bit, then initiate a snapshot from process1
    time.Sleep(2 * time.Second)

    fmt.Println("=== Starting Snapshot from Process 1 ===")
    process1.markerChannel <- true // send a marker to process1

    // Wait for all processes to finish
    wg.Wait()
}

// run is the main loop for each process
func (p *Process) run(p2, p3 *Process) {
    defer p.wg.Done()

    // Start a ticker that sends a message to p2 and p3 every 500ms
    ticker := time.NewTicker(500 * time.Millisecond)

    for {
        select {
        case <-ticker.C:
            // Send a random message (here, just localState) to p2 and p3
            p2.messageChan <- p.localState
            p3.messageChan <- p.localState
            fmt.Printf("Process %d sends message with content %d\n", p.id, p.localState)

        case marker := <-p.markerChannel:
            // If marker is received, handle the snapshot logic
            if marker {
                if !p.hasRecorded {
                    p.takeSnapshot()
                    // Send marker to other processes
                    p2.markerChannel <- true
                    p3.markerChannel <- true
                } else {
                    // If already recorded, do nothing special
                    // except acknowledging we received a marker
                    fmt.Printf("Process %d already recorded a snapshot\n", p.id)
                }
            }

        case msg := <-p.messageChan:
            // We receive a normal message
            fmt.Printf("Process %d receives message with content %d\n", p.id, msg)
            // If we haven't recorded yet, this message belongs to the channel state
            if !p.hasRecorded {
                fmt.Printf("Process %d: This message is stored as part of the channel state for snapshot.\n", p.id)
            }

        // We add a timeout or some condition to exit
        case <-time.After(5 * time.Second):
            fmt.Printf("Process %d shutting down.\n", p.id)
            return
        }
    }
}

// takeSnapshot simulates recording the local state
func (p *Process) takeSnapshot() {
    p.hasRecorded = true
    fmt.Printf("Process %d is recording local state: %d\n", p.id, p.localState)
    // In a real scenario, we would also store the channel states here
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Process 2 sends message with content 20
Process 1 receives message with content 20
Process 1: This message is stored as part of the channel state for snapshot.
Process 1 sends message with content 10
Process 3 receives message with content 20
Process 3: This message is stored as part of the channel state for snapshot.
Process 3 sends message with content 30
Process 3 receives message with content 10
Process 3: This message is stored as part of the channel state for snapshot.
Process 2 receives message with content 10
Process 2: This message is stored as part of the channel state for snapshot.
Process 2 receives message with content 30
Process 2: This message is stored as part of the channel state for snapshot.
Process 1 receives message with content 30
Process 1: This message is stored as part of the channel state for snapshot.
Process 1 sends message with content 10
Process 1 receives message with content 30
Process 1: This message is stored as part of the channel state for snapshot.
Process 1 receives message with content 20
Process 3 sends message with content 30
Process 3 receives message with content 10
Process 3: This message is stored as part of the channel state for snapshot.
Process 3 receives message with content 20
Process 3: This message is stored as part of the channel state for snapshot.
Process 1: This message is stored as part of the channel state for snapshot.
Process 2 sends message with content 20
Process 2 receives message with content 10
..........

Programın çalışır haline şuradan erişilebilir.

Bu örnek tüm Chandy-Lamport sürecinin basitleştirilmiş bir versiyonudur. Gerçek dünyada ağ gecikmeleri, yeniden iletim, hata durumları gibi karmaşık konular eklenir ve ele alınır.

Gerçek Dünya Uygulamaları

Dağıtık Veritabanlarında Checkpointing
- Önemli veritabanları zaman zaman anlık görüntüler alarak veri bütünlüğünü korurlar. Böylece bir hata olması durumunda sistem bu kayda geri dönebilir.
Hata Tespiti ve Kurtarma
- Dağıtık sistemler sürekli çevrimiçi olmayı hedeflediğinden, belirli zamanlarda alınan snapshot’lar sayesinde hangi süreçlerin çalıştığı, hangi kanallarda mesajların takılıp kaldığı gibi durumlar kolayca tespit edilir.
Dağıtık Sistemlerde Tutarlılık Kontrolü
- Örneğin blockchain gibi çoğaltılmış defter (ledger) yapıları, dönemsel olarak küresel durum bilgisine ihtiyaç duyarlar.
IoT ve Mikroservis Mimarisi
- Sensör verilerinin toplanması veya çok sayıda mikroservisin iletişimi sırasında, sistemin belirli bir anlık durumunu analiz etmek için snapshot’lar alınır.

Sık Karşılaşılan Sorular ve Yanıtları

Soru 1: Algoritma eşzamanlı (synchronous) veya eşzamanlı olmayan (asynchronous) ağlarda çalışır mı? Yanıt: Chandy-Lamport Algoritması, eşzamanlı olmayan (asynchronous) sistemlerde de çalışabilir. Hatta bu algoritmanın güzelliği iletişim gecikmelerinin belirsiz olduğu ortamlarda bile tutarlı snapshot alınmasını garanti etmesidir.

Soru 2: Marker mesajının kendisi bir durumu nasıl temsil ediyor? Yanıt: Marker mesajı “Bu kanalda snapshot başlıyor” anlamını taşır. Her süreç marker mesajını aldığında (eğer ilk kez görüyorsa) kendi yerel durumunu kaydeder ve süreci başlatır.

Soru 3: Tüm süreçler snapshot’ı tamamlayana kadar sistemi durdurmamız gerekir mi? Yanıt: Hayır. Chandy-Lamport Algoritması dağıtık çalışır ve süreçlerin normal çalışmasını engellemez. Süreçler snapshot alırken mesaj göndermeye ve almaya devam edebilir.

Soru 4: Diğer snapshot algoritmalarıyla farkı nedir? Yanıt: Chandy-Lamport marker kullanımıyla basit, genişletilebilir ve tutarlı snapshot alır. Başka algoritmalar da vardır (örneğin Mattern’ın renkli marker algoritması) ancak çoğu Chandy-Lamport fikrinden esinlenmiştir.

Chandy-Lamport Algoritması dağıtık sistemlerdeki küresel durum (global state) problemini ustalıkla çözen, marker-passing (işaretleyici iletme) temelli bir yöntemdir. Esas başarısı herhangi bir merkezi denetleyici kullanmadan, süreçlerin birbirlerini bloke etmeden, tutarlı bir snapshot yaratmaya olanak sağlamasıdır.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Byzantine Generals Problemi: Dağıtık Sistemlerde Hata Toleransı

Wed, 08 Jan 2025 00:00:00 GMT

Dağıtık sistemler günümüzün en kritik teknolojik yapı taşlarından biridir. Veritabanları, blok zincir ağları (blockchain), çok katmanlı kurumsal yazılım mimarileri, bulut bilişim altyapıları ve daha pek çok alanda, farklı fiziksel veya sanal düğümlerin (nodes) birlikte çalışması esasına dayanan sistemler kullanırız. Ancak bu sistemlerde iletişim kopuklukları, donanım hataları, kötü niyetli saldırılar veya yazılım hataları gibi pek çok sorun ortaya çıkabilir. Bu sorunlar dağıtık sistemin genel işleyişini ve güvenilirliğini doğrudan etkiler.

Dağıtık bir sistemin tasarımında cevaplanması gereken en önemli sorulardan biri “Sistem bileşenlerinin bir kısmı arızalansa veya kasıtlı olarak kötü niyetli davransa bile sistem nasıl doğru çalışabilir?” sorusudur. Bu sorunun en klasik ve çarpıcı örneği, Leslie Lamport, Robert Shostak ve Marshall Pease tarafından 1982’de ortaya konan ve literatüre “Byzantine Generals Problem” (Bizans Generalleri Problemi) olarak geçen problem tanımıdır.

Byzantine Generals Problemi Nedir?

Byzantine Generals Problemi, özünde güvenilmez iletişim kanalları ve potansiyel olarak kötü niyetli katılımcıların bulunduğu bir dağıtık sistemde uzlaşmaya (konsensüs) varmanın zorluğunu anlatan mecazi bir hikâye üzerinden sunulur. Problemin ana fikri şöyle özetlenebilir:

Bizans İmparatorluğu’nda farklı ordu birliklerine komuta eden generaller vardır.
Bu generaller farklı konumlarda konuşlanmıştır ve ortak bir hedefe (örneğin bir kaleye) saldırı düzenlemek veya geri çekilmek gibi bir strateji kararı almak zorundadırlar.
Generallerin saldırı veya geri çekilme kararı ortak olmalıdır; eğer bazıları saldırırken bazıları geri çekilirse ordu parçalanacak ve büyük bir yenilgi yaşanacaktır.
Generaller sadece haberci (mesaj taşıyan elçi) aracılığıyla birbirleriyle iletişim kurabilmektedir.
Haberci yolda yakalanıp mesajı değiştirebilir veya herhangi bir general kasıtlı olarak yanlış bilgi yayabilir (kötü niyetli olabilir).

Bu senaryoda “Her bir general, çoğunluk kararını doğru olarak öğrenerek aynı sonuca varabilir mi?” sorusu, çözülmesi gereken temel meseledir. Eğer sistemde bir veya daha fazla hilekâr/kötü niyetli general varsa, bu generaller yanlış mesaj göndererek sistemin uzlaşmaya varmasını engellemeye çalışabilir. Byzantine Generals Problemi işte bu “herhangi bir sayıda hatalı veya kötü niyetli düğüme karşı sistemdeki doğru (dürüst) düğümlerin ortak bir karara varması nasıl sağlanır?” sorusunu temsil eder.

Sorunun Tarihçesi ve Önemi

Byzantine Generals Problemi, ilk olarak 1982 yılında Leslie Lamport, Robert Shostak ve Marshall Pease tarafından “The Byzantine Generals Problem” başlıklı makalede detaylı şekilde açıklanmıştır. Dağıtık sistemler ve hata toleransı konularında bir dönüm noktasıdır. O döneme kadar “hata toleransı” çoğunlukla “düğüm çökerse ne olur?” sorusuna odaklanıyordu (örneğin bir sunucu aniden kapanırsa). Ancak kötü niyetli davranışlar da dahil olmak üzere daha karmaşık hata biçimlerini ele almak için yeni bir bakış açısı lazımdı. Bu problem, özellikle şu kritik noktalarda önemlidir:

Güvenli Dağıtık Hesaplama: Finansal sistemler, askeri sistemler, kritik altyapılar gibi ortamlarda güvenlik ve doğruluk (correctness) esastır.
Blok Zincir Teknolojisi: Bitcoin gibi blok zincirlerde, ağ katılımcılarının (madenciler, doğrulayıcılar) dürüst olup olmadığı belirsizdir. Byzantine hata toleransını sağlamak, blok zincirlerin devamlılığında temel bir gerekliliktir.
Bulut Bilişim ve Mikro Hizmet Mimarisi: Birçok farklı sunucunun ve hizmetin birbiriyle iletişim halinde olduğu bulut ortamlarında, söz konusu düğümlerin bir kısmı ağ veya yazılım sorunları yaşayabilir.
Dağıtık Veritabanları: Bir veritabanı kümesi üzerinde farklı kopyalara (replica) sahip düğümler, doğru bir çoğunluk kararı (konsensüs) üretmek zorundadır.

Hata Türleri ve Byzantine Hatalar

Dağıtık sistemlerdeki olası hata türlerini kabaca ikiye ayırabiliriz:

Çökme (Crash) veya Pasif Hatalar: Bir düğüm tamamen çalışmayı bırakır, mesaj göndermez veya yanıt vermez. Diğer tüm dürüst düğümler “Bu düğüm yok hükmündedir, dikkate almayalım” diyerek bir strateji geliştirebilir.
Byzantine (Aktif ve Kötü Niyetli) Hatalar: Düğüm çalışmayı bırakmak yerine kötü niyetli davranışlar (mesajları değiştirmek, çelişkili mesajlar göndermek, mesajları gereksiz yere çoğaltmak vb.) veya beklenmedik arızalar (yanlış hesaplama sonucu yanlış veri yollamak, iletişim kanalını kasıtlı olarak sabote etmek vb.) sergiler.

Byzantine hatalar klasik çökme hatalarına göre çok daha tehlikelidir. Çünkü kötü niyetli veya arızalı düğüm, sadece tek bir davranış biçiminde sabit kalmak zorunda değildir; sistemin işleyişine kasıtlı zarar vermek adına çeşitli yöntemler deneyebilir. Bu da konsensüs protokolleri tasarlarken son derece karmaşık önlemler alınmasını gerektirir.

Byzantine Generals Problemi’nin Resmi Tanımı

Sorunu biraz daha resmi hale getirelim:

Sistemde 𝑛 tane düğüm (node) olsun.
Bu düğümlerden bazıları Byzantine davranışlar sergileyebilir (kötü niyetli, arızalı, tutarsız vb.).
Her düğüm, belirli bir mesaj (örneğin, “Saldır”, “Saldırma” veya “0” / “1” gibi) değeriyle başlar.
Amaç mümkünse tüm dürüst düğümlerin aynı ortak değerde (örneğin “Saldır”) uzlaşmasıdır.
Dürüst düğümler protokole sadık kalırken, Byzantine düğümler herhangi bir kural tanımadan hareket edebilir.

Bu uzlaşmayı sağlamak, özellikle 𝑛 düğümün en azından 𝑓 tanesi Byzantine (kötü niyetli) olabilirken nasıl gerçekleşecektir? Problemin çözüm koşulları, aşağıdaki şartları karşılamak zorundadır:

Bütünlük (Integrity): Eğer bir dürüst düğümün karar mesajı 𝑣 ise, diğer tüm dürüst düğümler de 𝑣 üzerinde uzlaşmalıdır.
Konsensüs (Agreement): Bütün dürüst düğümlerin çıktısı (kararı) aynıdır.
Geçerlilik (Validity): Eğer girdide geçerli bir mesaj değeri varsa, sistem bu mesaj değerinden uzaklaşmadan bir karar vermelidir. (Örneğin hiçbir kötü niyetli düğüm yoksa, bütün dürüst düğümler kendi girdilerinde bir uzlaşmaya varabilmelidir.)

Teorik olarak kanıtlanmıştır ki, senkron bir ağda 𝑓 adet Byzantine hata toleransı sağlamak için en az 3f+1 düğüm gereklidir. Bu pek çok konsensüs protokolünün tasarımı için temel bir referans noktasıdır.

Dağıtık Sistemlerde Hata Toleransı

Byzantine Generals Problemi’nden yola çıkarak dağıtık sistemlerde hata toleransı (fault tolerance) kavramını daha iyi anlayabiliriz. Hata toleransı sistemin bir kısmı arızalansa veya kasıtlı olarak sabote edilmeye çalışılsa bile, sistemin genel olarak doğru sonuçlar üretebilmesini ifade eder.

Gereksinimler

Fazladan Kaynak (Redundancy): Dağıtık sistemler tek bir hata noktasından (single point of failure) kaçınmak için aynı görevi birden fazla düğüme dağıtır. Böylece bir düğümün çökmesi veya yalan söylemesi diğer dürüst düğümlerin doğru bilgiyi korumasını sağlar.
Güvenli İletişim Kanalları: Kriptografik yöntemler mesaj bütünlüğü ve kimlik doğrulama (authentication) gibi teknikler mesaj manipülasyonunu zorlaştırır.
Konsensüs Protokolü: Düğümlerin çoğunluk oyu ile veya başka matematiksel mekanizmalarla ortak bir karara varması gerekir.

Crash Fault Tolerance vs. Byzantine Fault Tolerance

Crash Fault Tolerance (CFT): Yalnızca düğümlerin çökmesini ve mesaj yollamamasını (veya gecikmeli mesaj yollamasını) ele alır.
Byzantine Fault Tolerance (BFT): Düğümlerin kasıtlı olarak yanıltıcı veya tutarsız mesajlar gönderebileceği durumu ele alır. Bu nedenle BFT mekanizmaları CFT’den daha karmaşık ve maliyetlidir.

Byzantine Hata Toleransını Sağlamaya Yönelik Yaklaşımlar

1. Klasik Algoritmalar

Byzantine Generals Problem makalesinde, senkron bir model altında, n≥3f+1 koşuluyla belirli bir iletişim turu sayısında (round) uzlaşmaya varan algoritmalar önerilmiştir. Ancak bu algoritmalar pratikte çok maliyetli (ağ trafiği ve hesaplama yükü bakımından) olabilmektedir.

Örneğin orijinal “Oral Message” (OM) ve “Signed Message” (SM) protokolleri; hatalı düğümlerin (generallerin) yarattığı etkiyi kısıtlamak için genele yayılmış mesaj kopyalarını, imzaları, doğrulayıcı listelerini vb. içerir. Her bir adımda mesajlar çoğaltılır ve dağıtılır, böylece bir genel inanç (global belief) oluşturulur.

2. Practical Byzantine Fault Tolerance (PBFT)

1999 yılında Miguel Castro ve Barbara Liskov tarafından önerilen PBFT (Practical Byzantine Fault Tolerance) protokolü, dağıtık sistemler dünyasında oldukça büyük bir etki yarattı. Çünkü PBFT kısmen “pratik” bir çözüm olmayı hedefliyordu; yani gerçekçi bir ağ modelinde (kısmen senkron) düşük gecikmeyle çalışacak bir protokol geliştirme amacı güdüyordu.

İşleyiş Özet: *İstemci (Client), bir isteği (örneğin, bir işlem, bir veri güncellemesi) sisteme yollar. *Primary (Lider) Düğüm isteği alır ve diğer replikalara dağıtır. *Replikalar, liderin ilettiği isteğin geçerli olduğuna dair bir “pre-prepare” ve “prepare” aşamalarını yürütür, bir nevi oy birliği (çoğunluk) sağlanır. *Yeterli çoğunluk sağlandığında, “commit” aşamasına geçilir ve işlem doğrulanır. *Sonuç, istemciye geri döner.
Byzantine Hata Toleransı: PBFT 𝑛 toplam düğüm sayısı içinde en fazla 𝑓 Byzantine hataya tolerans gösterir. Bu protokol için de n≥3f+1 koşulu aranır.

PBFT ve türevleri günümüzde pek çok izinli (permissioned) blok zincirinde, kurumsal veri paylaşım sistemlerinde ve hata toleransının kritik olduğu diğer uygulamalarda kullanılmaktadır.

3. Raft, Paxos ve BFT Türevleri

Paxos ve Raft, aslında çökme hatalarına (CFT) dayanıklı konsensüs protokolleridir. Yani Byzantine hatalara karşı direkt olarak güvence sağlamazlar. Fakat farklı eklemeler ve güçlendirilmiş sürümleriyle BFT-Paxos gibi yaklaşımlar ortaya çıkmıştır.
Tendermint (bir blok zincir konsensüs mekanizması), PBFT’ye benzer bir BFT yaklaşımı kullanarak hız ve yüksek doğrulama garantisi sağlar.
Honey Badger BFT gibi yeni nesil protokoller kısmen senkron veya asenkron ağlarda bile BFT konsensüsü sağlamaya odaklanır.

Örnekler ve Uygulama Alanları

1. Blok Zincirler

Bitcoin: Doğrudan PBFT kullanmaz bunun yerine Proof-of-Work (PoW) mekanizmasına dayanarak bir nevi “ekonomik” BFT sağlamaya çalışır. Saldırganlar %51 oranında madencilik gücünü ele geçirirse ağı manipüle edebilir.
Ethereum: Başlangıçta PoW üzerineydi ancak Ethereum 2.0 geçişiyle birlikte Proof-of-Stake (PoS) ve içerisinde BFT prensiplerini barındıran Casper gibi protokollere yönelmiştir.
Hyperledger Fabric: İzinli (permissioned) bir blok zinciri platformu olup PBFT gibi Bizans hata toleransına sahip konsensüs mekanizmalarına olanak tanır.

2. Dağıtık Veritabanları ve Kurumsal Sistemler

Büyük kurumsal veri merkezleri, yüksek mevcudiyet (availability) ve tutarlılık (consistency) sağlamak amacıyla farklı replikasyon stratejileri kullanır. Bazıları çökme hatası toleransıyla yetinirken, güvenliğin üst düzeyde kritik olduğu (örneğin finans, savunma, sağlık) ortamlarda BFT çözümleri tercih edilebilir.

Örneğin, Google Spanner, CFT tabanlı bir sistemdir ancak çok yüksek doğruluk ve süreklilik gerektiren bir yapıdadır. Gerektiğinde kriptografik imza ve veri bütünlüğü doğrulama teknikleriyle Byzantine davranışları da kısmen engelleyebilir.

3. Askerî ve Uzay Uygulamaları

NASA gibi kurumlar uzay araçlarının ve roketlerin kontrol sistemlerinde farklı bileşenlerin birbirinden bağımsız çalışıp veri doğrulaması yapabilmesini önemser. Örneğin çok kritik bir sistemde aynı sensör verisi farklı bilgisayarlar tarafından işlenir ve bunlar arasında bir çeşit oylama mekanizması (aynı Paxos veya PBFT benzeri bir yaklaşım) çalıştırılabilir.
Askerî ortamlarda, düşman tarafından gönderilen sahte komutlar veya yanlış istihbarat bilgileri, Byzantine hatalara benzerdir. Dolayısıyla merkezi emir-komuta zincirlerinde verinin bütünlüğünü sağlamak, bu problemin gerçek hayattaki bir yansımasıdır.

4. IoT (Nesnelerin İnterneti)

Akıllı şehirler, sağlık sensörleri, üretim hatları gibi IoT cihazlarının oluşturduğu ağlarda, cihazların bir kısmının saldırıya uğraması veya arızalanması olasıdır. Bazı IoT platformları hafifletilmiş (lightweight) BFT mekanizmalarına ihtiyaç duyar.

Ayrıntılı Bir Senaryo Örneği

Bu senaryoda bir şehirdeki akıllı trafik ışıkları sistemini düşünelim:

Düğümler: Şehrin farklı kavşaklarındaki kontrol üniteleri (trafik ışıkları), merkezi yönetim sunucuları ve bölgesel yönetim cihazları.
Konsensüs İhtiyacı: Belli saatlerde trafik yoğunluğunu dengelemek için belirli bir yeşil ışık süresi kararı alınması gerekiyor. Örneğin kavşaklar arası yeşil ışık süreleri senkronize olmalı ki trafik akışı optimize edilsin.
Olası Byzantine Hata:
- Bir trafik ışığı kontrol ünitesi, yanlış rapor veriyor veya hiç veri göndermiyor.
- Kötü niyetli bir saldırgan, ağda paketleri değiştirerek gerçek verileri manipüle ediyor.
- Bir yönetim cihazı, kasıtlı olarak farklı kavşaklara çelişkili talimatlar yolluyor.
Çözüm Yaklaşımı:
- Her kontrol ünitesi diğer tüm ünitelere (veya bir çoğunluk alt kümesine) sensör verilerini dijital imza ile birlikte gönderir.
- PBFT benzeri bir algoritma, bu verileri toplayıp bir “çoğunluk kararı” ile bir sonraki sinyalizasyon süresini belirler.
- Eğer bazı ünitelerden veya sunuculardan tutarsız veriler geliyorsa, bunlar çoğunluk tarafından tespit edilir (imza takibi, veri geçerlilik kontrolü) ve görmezden gelinir.
- Sonuçta saldırıya uğrayan veya arızalanan bir üniteye rağmen sistemin tamamı doğru ayarlama yapabilir.

Bu senaryo, karmaşık olsa da gerçek hayatta geniş çaplı IoT projelerinde veya akıllı trafik sistemlerinde karşımıza çıkabilecek tipik bir Byzantine hata toleransı problemine örnek olarak gösterilebilir.

Golang ile Basit Bir “Byzantine” Örneği

Aşağıdaki kodda şu bileşenler yer almaktadır:

Node (Düğüm): Her düğümün bir kimliği (ID), sahip olduğu “öneri” (örneğin “Saldır” veya “Çekil”), bir “Byzantine (kötü niyetli) olma” durumu ve gelen mesajları sakladığı bir dizisi vardır.
Broadcast (Yayın): Düğümler birbirlerine mesaj gönderir. Byzantine (kötü niyetli) olan düğüm, gelen istek doğrultusunda manipüle edilmiş veya farklı mesajlar gönderebilir.
Consensus (Konsensüs Arayışı): En basit haliyle, her dürüst düğüm, aldığı mesajların çoğunluğunu dikkate alarak kendi kararını günceller.

Önemli Not: Bu kod örneği, gerçek bir PBFT ya da BFT algoritmasının “tam” implementasyonu değildir. Amaç, kavramları ve potansiyel manipülasyonları gösterecek bir mini-senaryo sunmaktır. Üretim (production) ortamında, kriptografik imzalar, iletişim protokolleri, zamanlayıcı (timeout) mekanizmaları, hata tespiti gibi çok daha karmaşık yapılar gerekir.

package main

import (
    "fmt"
    "math/rand"
    "time"
)

// Message represents a simple structure that one node sends to another node.
type Message struct {
    From    int    // ID of the sender
    Content string // Proposal ("Attack" or "Retreat")
}

// Node represents a general (node) in the system.
type Node struct {
    ID            int
    Proposal      string   // This node's initial proposal
    IsByzantine   bool     // Is this node malicious?
    ReceivedMsgs  []Message
    FinalDecision string   // Final decision after consensus
}

// Broadcast allows each node to send messages to other nodes.
// Byzantine behavior is simplified to "manipulate the message" here.
func (n *Node) Broadcast(nodes []*Node) {
    for _, other := range nodes {
        if other.ID == n.ID {
            continue // Skip sending a message to itself
        }

        // The message content to be sent
        msgContent := n.Proposal

        // If this node is Byzantine, it may manipulate the message
        if n.IsByzantine {
            // For example, with a random probability, flip the message
            // (Attack -> Retreat, Retreat -> Attack)
            if rand.Float64() < 0.5 {
                if msgContent == "Attack" {
                    msgContent = "Retreat"
                } else {
                    msgContent = "Attack"
                }
            }
        }

        // "Send" the message to the other node
        other.Receive(Message{
            From:    n.ID,
            Content: msgContent,
        })
    }
}

// Receive stores incoming messages from other nodes.
func (n *Node) Receive(msg Message) {
    n.ReceivedMsgs = append(n.ReceivedMsgs, msg)
}

// Decide makes a final decision based on all received messages.
// It simply checks which proposal is in the majority (Attack or Retreat)
// and updates its own decision accordingly.
func (n *Node) Decide() {
    attackCount := 0
    retreatCount := 0

    for _, msg := range n.ReceivedMsgs {
        if msg.Content == "Attack" {
            attackCount++
        } else if msg.Content == "Retreat" {
            retreatCount++
        }
    }

    // Also consider the node's own initial proposal in the count
    if n.Proposal == "Attack" {
        attackCount++
    } else {
        retreatCount++
    }

    // The final decision is assigned based on the majority
    if attackCount > retreatCount {
        n.FinalDecision = "Attack"
    } else if retreatCount > attackCount {
        n.FinalDecision = "Retreat"
    } else {
        // In case of a tie, keep its original proposal
        n.FinalDecision = n.Proposal
    }
}

// NewNode is a helper function to create a new Node.
func NewNode(id int, proposal string, isByzantine bool) *Node {
    return &Node{
        ID:          id,
        Proposal:    proposal,
        IsByzantine: isByzantine,
    }
}

func main() {
    rand.Seed(time.Now().UnixNano())

    // Example scenario:
    // Let's create a total of 5 nodes. One of them will be Byzantine.
    // Each node will initially propose either "Attack" or "Retreat".
    nodes := []*Node{
        NewNode(0, "Attack",  false),
        NewNode(1, "Attack",  false),
        NewNode(2, "Retreat", false),
        NewNode(3, "Attack",  true),  // Malicious (Byzantine)
        NewNode(4, "Retreat", false),
    }

    // Round 1: Each node broadcasts its current proposal to others
    for _, node := range nodes {
        node.Broadcast(nodes)
    }

    // Round 2 (Optional): If you want multiple rounds, you could
    // update each node’s Proposal based on received messages
    // and broadcast again. In this simple example, we do just one round.

    // Now each node decides based on the messages it received
    for _, node := range nodes {
        node.Decide()
    }

    // Print results
    fmt.Println("=== Final Decisions ===")
    for _, node := range nodes {
        fmt.Printf("Node %d [Byzantine=%v] | Initial Proposal: %s | Final Decision: %s\n",
            node.ID, node.IsByzantine, node.Proposal, node.FinalDecision)
    }
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

=== Final Decisions ===
Node 0 [Byzantine=false] | Initial Proposal: Attack  | Final Decision: Attack
Node 1 [Byzantine=false] | Initial Proposal: Attack  | Final Decision: Attack
Node 2 [Byzantine=false] | Initial Proposal: Retreat | Final Decision: Attack
Node 3 [Byzantine=true]  | Initial Proposal: Attack  | Final Decision: Retreat
Node 4 [Byzantine=false] | Initial Proposal: Retreat | Final Decision: Attack

Burada 5 düğümün 3’ünün nihai kararı “Attack”, 1 tanesi “Retreat” şeklinde; hatta Byzantine düğümün kendisi bile gelen mesajların çoğunluğundan (ve kendi manipüle ettiği mesajlardan) etkilenerek ters bir sonuca varmış olabilir.

Programın çalışır haline şuradan erişilebilir.

Not: Gerçek bir BFT protokolünde, imzalar ve tutarlı mesaj yayılımı (consistent broadcast) mekanizmaları kullanılarak, düğümlerin farklı node’lara farklı mesajlar göndermesi engellenmeye (veya yakalanmaya) çalışılır. Burada ise konuyu basitçe göstermek için “herkese aynı mesaj” varsayımına kısmi bir manipülasyon ekledik.

Performans ve Maliyet

Byzantine hatalara karşı koruma sağlamak her zaman ilave bir hesaplama, iletişim ve yönetim maliyeti demektir. Protokoller bir işlemi onaylamak için birden fazla tur (round) mesaj alışverişi gerektirebilir. Ayrıca imza doğrulama gibi kriptografik işlemler ek yük getirir. Bu nedenle tasarımcılar sistemin gereksinimlerine göre şu soruları göz önünde bulundurur:

Kaç düğüm çalıştırılacak?
Beklenen saldırı veya arıza oranı nedir?
Gerçek zamanlı bir sistem mi, gecikmeye (latency) ne kadar tolerans var?
Donanım kaynakları ve bant genişliği yeterli mi?

Büyük boyutlu (örneğin yüzlerce, binlerce) düğümde BFT sağlamak halen zorlayıcı olabilir. Bu yüzden pratikte daha küçük, izinli ağlarda (konsorsiyum blok zincirleri, kurumsal veri merkezleri vb.) BFT protokolleri daha fazla görülür.

Gelecek Eğilimleri

Dağıtık sistemlerin her geçen gün daha da önem kazandığı çağımızda, Byzantine Generals Problemi ve BFT protokolleri gelecekte de kritik rol oynamayı sürdürecektir. Özellikle şu alanlarda yoğun araştırma ve geliştirme çalışmaları devam etmektedir:

Asenkron BFT Protokolleri: Tamamen asenkron ağlarda (gecikme sınırı yok, mesaj sıralaması muğlak) BFT sağlamak daha da zordur. Bu konuda Honey Badger BFT gibi yeni yaklaşımlar öne çıkıyor.
Zero-Knowledge ve Kriptografik Gelişmeler: Düğümlerin veriyi ifşa etmeden doğrulamaya katkı sağlayacağı, gizlilik odaklı BFT protokolleri geliştirilmektedir.
Quantum Dirençli İmza Şemaları: Gelecekte kuantum bilgisayarların gelişmesiyle mevcut kriptografik imza şemalarının kırılabilir hale gelmesi olasılığı var. BFT protokolleri de kuantum dirençli imza yöntemlerine ihtiyaç duyabilir.
Enerji Verimliliği ve Yeşil Bilişim: Blok zincir ve dağıtık konsensüs protokollerinin yoğun enerji tüketimi eleştiri konusu. Daha verimli BFT mekanizmaları ve Proof-of-Stake tarzı protokoller geliştirilmeye devam ediyor.

Byzantine Generals Problemi, dağıtık sistemlerde hata toleransı ve özellikle kötü niyetli veya arızalı düğümlere karşı alınacak önlemler noktasında temel referans niteliğindedir. Bu problem sayesinde sistem tasarımcıları ve araştırmacılar, “en kötü” senaryolara rağmen doğru çalışabilen protokoller üzerinde çalışmış ve ortaya PBFT, Tendermint, Honey Badger BFT gibi güçlü çözümler çıkmıştır.

Günümüzün blok zincir teknolojilerinden kurumsal veri merkezlerine, IoT ağlarından askerî sistemlere kadar pek çok alanda “çok sayıdaki düğümün aynı zamanda doğru karar vermesi” gerektiği durumlar vardır. Bu noktada Byzantine Generals Problemi, “dağıtık mutabakat nasıl sağlanır?” sorusuna teorik ve pratik çerçevede yanıt sunan en önemli rehberlerden biri olmaya devam etmektedir.

Özetle dağıtık sistemlerde Byzantine hata toleransı elde etmek kolay değildir; ek maliyet, komplekslik ve titiz bir protokol tasarımı gerektirir. Ancak, bu zorluklar aşıldığında elde edilen kazanç (yüksek güvenlik, doğruluk, kesintisiz çalışma) kritik öneme sahip projelerde vazgeçilmezdir. Bu nedenle, önümüzdeki yıllarda da Byzantine Generals Problemi ve BFT protokollerinin gelişimini yakından takip etmek, dağıtık sistemlerin geleceğini şekillendirmede kilit rol oynayacaktır.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

PAXOS Algoritması: Dağıtık Sistemlerde Konsensus Sağlama

Sun, 05 Jan 2025 00:00:00 GMT

Dağıtık sistemlerde birden fazla düğüm (node) arasında karar birliğine varmak (konsensus) zor bir problemdir. PAXOS algoritması, dağıtık sistemlerde güvenilir bir şekilde konsensus sağlamak için geliştirilmiş, akademik dünyada oldukça kabul görmüş bir protokoldür. Leslie Lamport tarafından 1990’larda tanıtılmış olan bu algoritma özellikle hata toleransının kritik olduğu sistemlerde kullanılır.

1. Dağıtık Sistemlerde Konsensusun Önemi

Dağıtık sistemler farklı coğrafi konumlarda veya farklı fiziksel makinelere yayılan bileşenlerden oluşan sistemlerdir.

Örnek: Mikro hizmet mimarisi, büyük veri işleme kümeleri, veritabanı replikasyonu gibi pek çok senaryoda dağıtık yaklaşımlar kullanılmaktadır. Konsensus (consensus) dağıtık bir sistemdeki node’ların (düğümlerin), belirli bir değerin veya durumun üzerinde ortak bir karara varma sürecini ifade eder.

Örnek: Aynı verinin birçok kopyası (replicas) varsa bunların tutarlı olması için bir karara varmak gerekir. Sorun: Ağ hataları, gecikmeler ve node hataları bu süreci karmaşıklaştırır. Özetle, dağıtık sistemlerdeki en kritik problemlerden biri, farklı node’ların aynı zamanda tek bir gerçeğe (ground truth) ulaşmasını sağlamaktır.

2. Paxos Nedir?

Paxos, dağıtık sistemlerde fault-tolerant bir şekilde ortak bir karara varmak için Leslie Lamport tarafından önerilmiş bir konsensus algoritmasıdır. 1990’ların sonunda ortaya atılan bu fikir, günümüzün modern dağıtık sistemlerinde hâlâ geçerliliğini korur ve benzeri algoritmaların çoğunun temelini oluşturur.

Amaç: Sistem içindeki çoğunluk (majority) node’un aynı değeri kabul etmesini sağlamak. Önemli Not: Paxos asenkron ağ modelinde (network’teki mesajların gecikmesi bilinemez) çalışmaya uygun bir şekilde tasarlanmıştır ve “Bir değer kabul edilirse, onu garanti altına al” mantığı üzerine kurulur.

3. Temel Bileşenler ve Roller

Paxos’ta üç temel rol vardır:

Proposer (Önerici)
- Yeni bir değer önermekten sorumludur.
- Sistemde bir veya birden fazla Proposer olabilir.
Acceptor (Kabul Edici)
- Önerileri kabul veya reddetme kararı veren node’lardır.
- Bir öneriyi kabul ederse, o önerinin değerini diğer node’lara aktarır.
Learner (Öğrenici)
- Kabul edilen değeri öğrenmekle yükümlüdür.
- Tipik olarak sistemin geri kalanına son kararın ne olduğunu bildirmekle görevlidir.

Gerçek hayatta bazı node’lar aynı anda hem Proposer hem Acceptor hem de Learner rollerini üstlenebilir. Ancak algoritmanın mantığı anlaşılır olması için bu roller kavramsal olarak ayrılmıştır.

4. Paxos Algoritmasının Adımları

Paxos süreci kabaca iki (bazı modellerde üç) temel fazdan oluşur. Literatürde bu fazlar genelde Prepare ve Accept olarak geçer. Kabul edilen değer tüm Learner’lara bildirildiği aşama da Learn olarak adlandırılır.

4.1 Faz 1: Prepare (Hazırlık)

Öneri Numarası (Proposal Number):
- Her Proposer benzersiz ve monoton artan bir öneri numarası seçer (örnek: 1, 2, 3…).
- Öneri numarasının benzersiz olması önemlidir; genelde node_id + timestamp gibi stratejilerle üretilir.
Prepare Mesajı:
- Proposer “prepare(n)” mesajını, bir çoğunluk (majority) kümedeki Acceptor’lara gönderir. Burada n öneri numarasıdır.
Promise (Söz Verme):
- Eğer bir Acceptor daha önce bir öneri numarası m ≥ n ile bir söz (promise) vermediyse, Proposer’a bir “promise” mesajı yollar. Bu “Bundan daha düşük numaralı başka hiçbir öneriyi kabul etmeyeceğim” anlamına gelir.
- Ayrıca Acceptor daha önce kabul ettiği en yüksek öneri numarasına (eğer varsa) ait değeri Proposer’a bildirir.

Amaç: Proposer yeterli sayıda Acceptor’dan “promise” cevabı alarak, bundan sonraki adımda sunacağı değerin çoğunluk tarafından dikkate alındığından emin olur.

4.2 Faz 2: Accept (Kabul)

Değer Belirleme:
- Proposer Faz 1’de Acceptor’lardan aldığı yanıtları inceler.
- Eğer Acceptor’lar daha önce belirli bir değer içeren bir öneriyi kabul etmişse, Proposer bu değeri en yüksek öneri numarasına sahip olan değeri seçerek tekrar önermek durumundadır.
- Eğer hiçbir Acceptor’dan önce kabul edilmiş bir değer bilgisi gelmezse, Proposer kendi önerdiği değeri sunabilir.
Accept Mesajı:
- Proposer “accept(n, v)” (öneri numarası n, değer v) şeklinde bir mesajı aynı çoğunluk kümesine (Acceptor’lara) gönderir.
Kabul (Accept):
- Acceptor eğer “promise” gönderdiği n numaralı öneriden daha yüksek numaralı bir öneriye “promise” vermediyse, bu değeri kabul eder ve kabul ettiğini Proposer’a (ve/veya Learner’lara) iletir.

Amaç: Faz 2 sonucunda, çoğunluk en az bir kere aynı değeri kabul etmiş olur. Bir değeri çoğunluk kabul ettiğinde, o değer Paxos tarafından seçilmiş (chosen) sayılır.

4.3 Faz 3: Learn (Öğrenme)

Kabul edilen (chosen) değer, Learner’lara dağıtılır.
Learner’lar Acceptor’lardan gelen “accepted” mesajına dayanarak sonucun ne olduğunu öğrenir.
Sistemin geri kalanı da bu değer üzerinde mutabık kalmış olur.

5. Paxos’un Özellikleri

Paxos, iki kritik özelliği hedefler:

Safety (Güvenlik)
- Aynı tur içinde veya farklı turlarda olsun, iki farklı değerin aynı anda seçilmesini önler.
- Bir değer seçildiyse sistemde o değerin yerine geçecek bir başka değerin seçilmesi mümkün değildir.
Liveness (Canlılık)
- Sistem yeterince istikrarlı (stable) durumda olduğunda, önerilen değerlerin bir süre sonra mutlaka seçilmesini garanti altına alır.
- Ancak ağda kalıcı bölünmeler (network partition) veya çok sık tekrar eden hatalar varsa liveness gecikebilir.

Paxos’un güvenlik özelliği, “aynı anda iki farklı değeri seçmeme” şeklinde garanti sunarken; liveness özelliği, “eninde sonunda bir değer seçilmesi”ni garanti eder.

6. Multi-Paxos ve Gelişmiş Versiyonlar

Tek bir değer üzerinde konsensus sağlamak yerine, bir dizi değer veya bir komut dizisi üzerinde anlaşılıyor olabilir. Örneğin; bir dağıtık veritabanında sıralı bir dizi komutun (insert, update, delete) sırasını belirlemek isteyebilirsiniz.

Multi-Paxos:
- Aynı node’lar tekrar tekrar Paxos çalıştırmak yerine, lider (leader) olarak adlandırılan sabit bir Proposer atanır ve bir dizi değeri sırayla kabul ettirmeye çalışır.
- Bu sayede her turda yeni bir lider seçme işlemi yapılmaz, performans artar.
Raft, Zab vb.:
- Paxos’tan esinlenen diğer konsensus algoritmaları da “lider seçimi”, “log replikasyonu” gibi benzer adımlarla yüksek performans ve basitlik sunmaya çalışır.

7. Paxos’un Avantajları ve Dezavantajları

Avantajları:

Temel Teorik Dayanak: Literatürde en çok incelenen ve ispatlanmış konsensus algoritmalarından biri olması.
Güvenlik Garantisi: Asenkron ağ ortamlarında bile tutarlı sonuçlar vermesi.
Esneklik: Birçok senaryoya ve farklı uygulama mimarilerine uyarlanabilir.

Dezavantajları:

Uygulama Karmaşıklığı: Paxos akademik makalelerde net olsa da uygulamada kodlamak ve yönetmek zordur.
Fazlar Arasındaki Mesaj Trafiği: Faz 1 ve Faz 2 mesajlaşmalarının maliyeti yüksektir. Özellikle yüksek performans gereken sistemlerde dikkatli tasarım ister.
Liderlik Seçimi Gerekebilir: Multi-Paxos’ta lider seçimi ve liderin başarısız olması gibi ek yönetim ve hata toleransı katmanları tasarlamak gerekir.

8. Gerçek Hayat Uygulamaları

Google Chubby: Google’ın dahili dağıtık kilit sistemi, Paxos temelli bir mekanizma kullanır.
Microsoft Azure: Dağıtık veritabanı ve blob saklama altyapısında benzer algoritmalara başvurulur.
Temel Veritabanı Replikasyonu: Büyük ölçekli, yüksek erişilebilirlik gerektiren kritik sistemlerde sıklıkla Paxos ya da benzer konsensus algoritmalarından yararlanılır.

Günümüzde Paxos’un sadeleştirilmiş ve üretim ortamlarında daha kolay yönetilebilen varyantları (örn. Raft) daha popüler hale gelmiş olsa da, Paxos’un teorik altyapısı hâlâ pek çok konsensus algoritmasının temelini oluşturmaktadır.

Paxos Algoritması dağıtık sistemlerde konsensus sağlamak için en önde gelen klasik çözümlerden biridir. Ağ gecikmeleri, node arızaları ve asenkron iletişim gibi zorluklara rağmen çoğunluğun ortak bir değeri kabul etmesini garanti altına alır.

Güvenlik (Safety) ve Canlılık (Liveness) garantisi sunar.
Multi-Paxos gibi geliştirilmiş sürümleri, pratik kullanımda birden fazla değeri sırayla kabul etmede yaygın olarak kullanılır.
Tasarım ve uygulama açısından karmaşık olduğu için, pratikte Raft gibi daha anlaşılır alternatifler de tercih edilir.

Yine de Paxos, dağıtık konsensus denince akla ilk gelen ve farklı algoritmaların atası sayılan çok önemli bir paradigmadır. Özellikle yüksek erişilebilirlik ve tutarlılık gerektiren sistemlerde, Paxos benzeri mekanizmalar inşa etmek kaçınılmaz bir gereksinim haline gelmiştir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Go'da Concurrency: Channels, Goroutines ve Senkronizasyon Mekanizmaları

Sat, 23 Nov 2024 00:00:00 GMT

Go (Golang), Google tarafından 2007 yılında tasarlanmaya başlayan ve 2009’da açık kaynak olarak yayınlanan, özellikle yüksek performanslı ve ölçeklenebilir yazılımlar geliştirmeye odaklanmış modern bir programlama dilidir. Basit ve anlaşılır sözdizimi sayesinde hem deneyimli hem de yeni başlayan geliştiriciler tarafından kolayca öğrenilebilir. Aynı zamanda, hafif ve hızlı bir şekilde derlenebilen bir dil olduğu için C benzeri bir performans elde edilebilir.

Go’nun en güçlü özelliklerinden biri de dil seviyesinde gömülü olarak gelen concurrency (eşzamanlılık) desteğidir. Concurrency kavramı, modern uygulamalarda yüksek verimlilik ve ölçeklenebilirlik sağlamak açısından kritik öneme sahiptir. Go’da concurrency kullanımını mümkün kılan temel yapı taşı olan goroutine’ler, geleneksel iş parçacıklarına (thread) göre çok daha hafif ve kolay yönetilebilir bir yaklaşım sunar. Ayrıca, eşzamanlı çalışan parçaların kendi aralarındaki iletişim ve senkronizasyonunu basitleştirmek için channel gibi mekanizmalar sağlanır. Bu sayede, paylaşımlı veri yönetimi yerine “iletişim kurarak paylaşım” yaklaşımına dayanan güvenilir ve temiz bir tasarım uygulanabilir.

1. Concurrency Nedir? Parallelism ile Farkları

Öncelikle sıkça karıştırılan iki terimi ayırt etmekte fayda var: concurrency ve parallelism.

Concurrency (Eşzamanlılık): Bir programın birden fazla işi aynı zaman aralığında ilerletebilme (interleaving) yeteneğidir. İşler birbiri ardına kısa zaman dilimlerinde parçalar halinde çalıştırılır ve bu şekilde kullanıcıya aynı anda birden fazla işin yürütüldüğü hissi verilir. İşletim sistemi çekirdeği veya dilin çalışma zamanı (runtime), hangi işin ne zaman çalıştırılacağına (schedule) karar verir.
Parallelism (Paralellik): Fiziksel olarak aynı anda birden fazla işin yürütülmesidir. Örneğin çok çekirdekli bir CPU’da, birden fazla çekirdek aynı anda farklı işlemler üzerinde çalışabilir.

Go concurrency’i çok kolay bir şekilde kullanılabilir hale getirir ancak bu concurrency özelliği aynı makinede her zaman “paralel” çalışacağı anlamına gelmez. Go runtime, hangi goroutine’in hangi çekirdekte veya ne zaman çalıştırılacağını belirler. Doğru şekilde konfigüre edildiğinde ve çok çekirdekli bir işlemci üzerinde çalıştığında, Go kodunuz hem concurrency hem de parallelism sağlayabilir.

2. Goroutine Nedir?

Go’da concurrency’nin temel yapı taşı goroutine’lerdir. Goroutine, Go runtime içinde çalışan hafif (lightweight) bir iş parçacığı olarak düşünülebilir. Go’da bir goroutine başlatmak oldukça basittir. Herhangi bir fonksiyonun başına go anahtar kelimesi getirerek o fonksiyonu ayrı bir goroutine’de çalıştırabilirsiniz.

package main

import (
    "fmt"
    "time"
)

func helloWorld() {
    fmt.Println("Hello World!")
}

func main() {
    // Run the helloWorld function in a new goroutine
    go helloWorld()

    // Let's wait a bit in the main goroutine so that the other goroutine can run as well.
    time.Sleep(time.Second)
    fmt.Println("The main goroutine has ended.")
}

Yukarıdaki örnekte helloWorld() fonksiyonunu go helloWorld() ifadesiyle çağırdığımızda, bu fonksiyon ana goroutine’den bağımsız bir şekilde çalışmaya başlar. Ana goroutine sona erer ermez, program sonlanacağı için diğer goroutine’in de çalışmasına imkân kalmaz. Bu nedenle, küçük de olsa bir time.Sleep() ekleyerek diğer goroutine’in sonuç üretmesini bekliyoruz.

Önemli Not: Gerçek projelerde bekleme için time.Sleep() kullanmak yerine, genellikle senkronizasyon mekanizmalarından biri olan sync.WaitGroup veya benzer yapıları kullanmak daha doğru bir yaklaşımdır.

3. Channel’lar (Kanallar)

Channel, Go’da goroutine’ler arasında veri aktarımını güvenli ve senkronize bir şekilde yapmaya yarayan veri yapılarıdır. Channel’ların en büyük avantajı, paylaşılan değişkenler kullanarak kilit (lock) yönetimi yapmak yerine, verinin kendisini goroutine’ler arasında transfer etmeye olanak vermesidir. Bu yaklaşım “paylaşma yerine iletişim” (communicating by sharing vs. sharing by communicating) felsefesinin güzel bir örneğidir.

3.1 Kanal Oluşturma ve Veri Gönderme/Alma

Bir kanal aşağıdaki gibi oluşturulur:

ch := make(chan int) // Creates a channel of type int (unbuffered channel)

Veri gönderimi ve alımı <- operatörü ile gerçekleştirilir:

Gönderim: ch <- x
Alım: y := <-ch

Örnek bir kullanım:

package main

import (
    "fmt"
)

func main() {
    ch := make(chan string)

    go func() {
        // Sending data
        ch <- "Data from Goroutine"
    }()

    // Receiving data
    data := <-ch
    fmt.Println(data)
}

Yukarıdaki örnekte, isimlendirilmemiş (anonymous) bir fonksiyonu goroutine olarak çalıştırıyoruz ve bu fonksiyon, ch kanalına bir string gönderiyor. Ana goroutine ise bu string’i data := <-ch ifadesiyle okuyor.

3.2 Buffered Channels

Standart olarak oluşturulan channel’lar “unbuffered” (tamponlanmamış) olarak adlandırılır ve gönderici ile alıcının aynı anda işlemi gerçekleştirmesini bekler. Yani kanalın her gönderimi bir alıcı tarafından okunana kadar bloklanır.

Eğer belirli bir kapasiteye sahip bir kanal oluşturursanız, bu bir “buffered channel” olur. Bu kanal belirli sayıda mesajı okuyucu olmadan da tutabilir.

ch := make(chan int, 5) // A buffered channel with a capacity of 5

Bu durumda ch kanalına en fazla 5 adet int değerini alıcı beklemese bile gönderebilirsiniz. Ancak 6. gönderim, kapasite dolduğu için, bir değer alana kadar bloklanacaktır.

3.3 Kanalın Kapatılması (close)

Kanalı close(ch) fonksiyonu ile kapatabilirsiniz. Kapatılan bir kanala tekrar veri gönderilmeye çalışılırsa “panic” oluşur. Kapalı kanaldan veri okumaya devam edebilirsiniz, ancak okunabilecek veri kalmadığında “zero value” (int için 0, string için "" vb.) dönecektir.

package main

import (
    "fmt"
)

func main() {
    ch := make(chan int, 3)
    ch <- 10
    ch <- 20
    close(ch)

    // Since the channel is closed, we can continue to read data, 
	// but as soon as we try to write, a panic occurs.
    for val := range ch {
        fmt.Println(val)
    }
}

Yukarıdaki örnekte range ifadesi kapatılmış kanaldaki mevcut tüm değerleri okur, yeni veri olmadığında döngüyü sonlandırır.

4. Senkronizasyon Mekanizmaları

Concurrency ile ilgilenirken birden fazla goroutine’in aynı kaynağa erişmesi, paylaşımlı bir veriyi güncellemesi veya okuması gerekebilir. Bu durumlarda veri bütünlüğünü (data consistency) korumak için senkronizasyon yöntemlerine ihtiyaç duyarız.

4.1 `sync.WaitGroup`

Birden fazla goroutine’in tamamlanmasını beklemek için kullanılan en temel yapı sync.WaitGroup‘dır. Aşağıdaki örnekte, üç farklı fonksiyonu üç ayrı goroutine’de çalıştırıyoruz ve hepsinin bitmesini WaitGroup kullanarak bekliyoruz:

package main

import (
    "fmt"
    "sync"
    "time"
)

func doWork(num int, wg *sync.WaitGroup) {
    defer wg.Done() // When the function finishes, the counter is decremented by calling Done().
    fmt.Printf("Goroutine %d started\n", num)
    time.Sleep(time.Millisecond * 500) // For example, let's wait 500 ms
    fmt.Printf("Goroutine %d finished\n", num)
}

func main() {
    var wg sync.WaitGroup
    toplamGoroutine := 3
    wg.Add(toplamGoroutine) // We are waiting for 3 goroutines

    for i := 1; i <= toplamGoroutine; i++ {
        go doWork(i, &wg)
    }

    // Waits until all goroutines are finished
    wg.Wait()

    fmt.Println("All goroutines completed")
}

Yukarıda:

wg.Add(n) ile bekleyeceğimiz goroutine sayısını belirtiyoruz.
Her goroutine’in içinde defer wg.Done() diyerek, goroutine’in işi bittiğinde WaitGroup sayacını 1 azaltmasını sağlıyoruz.
wg.Wait() ifadesi, tüm goroutine’lerin (add ile eklenen) tamamlanmasını bekler.

4.2 `sync.Mutex` ve `sync.RWMutex`

Paylaşımlı veriye aynı anda erişildiği durumlarda veri tutarlılığı sağlamak için sync.Mutex (mutual exclusion lock) kullanılır. Bir “mutex” aynı anda yalnızca bir goroutine’in paylaşımlı kaynağa erişmesine izin verir.

package main

import (
    "fmt"
    "sync"
)

type SafeCounter struct {
    mu    sync.Mutex
    count int
}

func (sc *SafeCounter) Increment() {
    sc.mu.Lock()
    defer sc.mu.Unlock()
    sc.count++
}

func (sc *SafeCounter) Value() int {
    sc.mu.Lock()
    defer sc.mu.Unlock()
    return sc.count
}

func main() {
    var wg sync.WaitGroup
    sc := SafeCounter{}

    goroutineCount := 5
    wg.Add(goroutineCount)

    for i := 0; i < goroutineCount; i++ {
        go func() {
            defer wg.Done()
            for j := 0; j < 1000; j++ {
                sc.Increment()
            }
        }()
    }

    wg.Wait()
    fmt.Println("Total:", sc.Value())
}

Increment() ve Value() metodlarında Lock() ve Unlock() ile verilere tek seferde sadece bir goroutine’in erişmesini sağlıyoruz. Böylece veri tutarlılığı korunuyor.
RWMutex, okuma-yazma kilidi (read-write lock) olup, birden çok okuyucu goroutine’e aynı anda izin verir ancak bir yazıcı girince sadece yazıcıya izin verir. Böylece genellikle ağırlıklı olarak okuma işlemlerinin yapıldığı durumlarda performans kazandırır.

4.3 `sync.Once`

Bazen belirli bir fonksiyonun veya işlemin program boyunca yalnızca bir kez çalışmasını isteyebilirsiniz. Bu durum için sync.Once yapısı kullanılır. Özellikle konfigürasyon, cache inicializasyonu gibi işlemler sadece bir kez yapılmak isteniyorsa oldukça faydalıdır.

package main

import (
    "fmt"
    "sync"
)

var once sync.Once

func initConfig() {
    fmt.Println("The configuration is started.")
}

func main() {
    var wg sync.WaitGroup
    wg.Add(3)

    for i := 0; i < 3; i++ {
        go func(id int) {
            defer wg.Done()
            once.Do(initConfig)
            fmt.Printf("Goroutine %d is running.\n", id)
        }(i)
    }

    wg.Wait()
}

Bu örnekte initConfig() fonksiyonu kaç tane goroutine çağırırsa çağırsın yalnızca bir kez çalıştırılacaktır.

5. Concurrency’de Dikkat Edilmesi Gerekenler

Data Race (Veri Yarışı): Birden fazla goroutine aynı değişkeni aynı anda okuyup yazmaya çalışırsa veri yarışı oluşur. Bu durumda beklenmedik sonuçlar alabilirsiniz. go run -race main.go komutu ile Go programınızda veri yarışı test edebilirsiniz.
Kilitlerin Unutulması: Mutex kullanırken kilidi açmayı (unlock) unutursanız, diğer goroutine’ler sonsuza kadar bekleyebilir. Bu nedenle defer mu.Unlock() gibi yaklaşımlar önerilir.
Ölçeklenebilirlik: Goroutine’ler çok hafif olsa da, aşırı sayıda goroutine kullanımı sistem kaynaklarının tükenmesine neden olabilir. Milyonlarca goroutine başlatmak teoride mümkün olsa da pratikte göz önünde bulundurulması gereken bellek ve işlemci limitleri vardır.
Kapanmamış Kanallar: Özellikle uzun ömürlü servislerde, kanal kullanımını dikkatli yönetmek gerekir. İhtiyaç kalmayan kanallar doğru zamanda kapatılmazsa bekleyen goroutine’ler bloklanabilir veya “goroutine leak” (sızıntı) yaşanabilir.
Zamanlama ve Yarış Koşulları: Concurrency, karmaşıklığı artırır. Kodun hangi sırayla çalışacağını tam olarak kestirmek güçtür. Bu nedenle test stratejileri, logging ve bellek izleme (profiling) önemlidir.

6. Örnek: İşleyiciler (Worker) ve Kanal Tabanlı Sıra

Aşağıda, 10 adet işi işlemesi için 3 adet “worker” (işleyici) goroutine başlatan, işleri bir kanaldan okuyan ve işleyen örnek bir kod bulunuyor:

package main

import (
    "fmt"
    "sync"
    "time"
)

// Task represents an item or job to be processed
type Task struct {
    ID int
}

// worker function processes tasks from the channel
func worker(id int, taskChan <-chan Task, wg *sync.WaitGroup) {
    defer wg.Done()
    for task := range taskChan {
        fmt.Printf("Worker %d is processing task %d...\n", id, task.ID)
        // Simulate some work
        time.Sleep(time.Millisecond * 100)
        fmt.Printf("Worker %d has completed task %d.\n", id, task.ID)
    }
}

func main() {
    taskCount := 10
    workerCount := 3

    // Create a channel to send tasks
    taskChan := make(chan Task, taskCount)

    // A WaitGroup will ensure that all tasks and workers finish
    var wg sync.WaitGroup

    // Start 3 workers
    for i := 1; i <= workerCount; i++ {
        wg.Add(1)
        go worker(i, taskChan, &wg)
    }

    // Send 10 tasks to the channel
    for i := 1; i <= taskCount; i++ {
        taskChan <- Task{ID: i}
    }

    // Close the channel once all tasks have been sent
    close(taskChan)

    // Wait for all workers to finish
    wg.Wait()
    fmt.Println("All tasks have been processed, the program is now terminating.")
}

worker fonksiyonu kendisine gelen taskChan‘dan görevleri alarak (range ile) işliyor. Kanal kapatıldığında range döngüsü sonlanıyor ve fonksiyon çıkıyor. Ana fonksiyonda wg.Add(1) yaparak 3 worker başlatılıyor. Her worker tamamlandığında wg.Done() çağırıyor. Görevler tamamlandığında, program sonlanıyor.

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Worker 3 is processing task 1...
Worker 1 is processing task 2...
Worker 2 is processing task 3...
Worker 2 has completed task 3.
Worker 2 is processing task 4...
Worker 3 has completed task 1.
Worker 3 is processing task 5...
Worker 1 has completed task 2.
Worker 1 is processing task 6...
Worker 1 has completed task 6.
Worker 1 is processing task 7...
Worker 2 has completed task 4.
Worker 2 is processing task 8...
Worker 3 has completed task 5.
Worker 3 is processing task 9...
Worker 2 has completed task 8.
Worker 2 is processing task 10...
Worker 3 has completed task 9.
Worker 1 has completed task 7.
Worker 2 has completed task 10.
All tasks have been processed, the program is now terminating.

Programın çalışır haline şuradan erişilebilir.

Bu yaklaşım, “worker pool” (işleyici havuzu) olarak bilinir ve genellikle büyük miktarda işi, belirli sayıda eşzamanlı çalışan işleyici ile paylaşmak için idealdir. Böylece kaynak kullanımını düzenler ve performans ile ölçeklenebilirlik sağlar.

Go basitlik ve verimlilik odaklı bir dil olarak concurrency konusunu dil seviyesinde mükemmel şekilde desteklemektedir.

Goroutine‘ler, sistem iş parçacıklarına (thread) göre çok daha hafif ve kolay yönetilebilir yapılardır.
Channel‘lar, veriyi paylaşmak yerine mesajlaşma paradigmasını benimser ve goroutine’ler arası iletişimi güvenli hale getirir.
sync paketi (WaitGroup, Mutex, RWMutex, Once gibi yapılar) concurrency senaryolarında yaygın kullanılan senkronizasyon mekanizmalarını içerir.

Bu araçları doğru ve bilinçli kullanarak, yüksek performanslı ve ölçeklenebilir Go uygulamaları geliştirebilirsiniz. Ancak concurrency, beraberinde karmaşıklığı da getirir. Veri yarışı (race condition), kilitlenme (deadlock) gibi sorunlar çıkmaması için kodunuzu dikkatle tasarlamalı, test etmeli ve gerekli profil (profiling) araçlarını kullanmalısınız.

Unutmayın: Concurrency doğru kullanıldığında çok güçlü bir araçtır; yanlış kullanıldığında ise hataları takip etmesi ve gidermesi zor bir kabusa dönüşebilir. Go’nun basit concurrency modeli ve zengin standard kütüphanesi, bu yolda büyük kolaylıklar sunuyor.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

CRDT'ler (Conflict-free Replicated Data Types): Dağıtık Sistemlerde Veri Tutarlılığı

Tue, 15 Oct 2024 00:00:00 GMT

Dağıtık sistemler günümüzde giderek daha fazla popüler hâle gelmiştir. Mikroservis mimarileri, veri merkezleri arası replikasyonlar, coğrafi olarak dağıtık veri tabanları, çoklu erişim noktalarına sahip uygulamalar ve benzeri senaryolar, veri tutarlılığının sağlanmasını oldukça karmaşık bir hâle getirir. Verinin aynı anda birden fazla lokasyonda bulunması, güncellenmesi veya okunması sırasında çatışmalar (conflicts) ortaya çıkabilir. İşte bu noktada CRDT (Conflict-free Replicated Data Types) kavramı devreye girer.

CRDT’ler, dağıtık ortamda veri kopyaları (replica) arasında sonunda güçlü tutarlılık (Strong Eventual Consistency) sağlamayı amaçlayan özel veri yapılarıdır. Bu tür veri yapılarını kullanarak, kopyalar arasında tutarlılığın sağlanması için sürekli bir senkronizasyon veya pahalı bir küresel kilit (global lock) mekanizmasına başvurulmaksızın, veri güncellemelerinin bir şekilde deterministik olarak birleştirilmesi (merge) mümkün olmaktadır.

1. CRDT Nedir ve Özellikleri

CRDT (Conflict-free Replicated Data Type), bir veri tipinin dağıtık ortamlarda tutarsızlıklar yaşanmadan replikasyonunun yapılabilmesi için tasarlanmış bir türüdür. Geleneksel yöntemlerde farklı kopyalardaki değişikliklerin bir araya getirilmesi, çatışmaların (conflicts) çözümü esnasında karmaşık algoritmalar veya ek bir koordinasyon gerektirir. CRDT’ler ise bu çatışmaları en aza indirebilecek (veya tamamen ortadan kaldırabilecek) şekilde tasarlanmışlardır.

Temel Özellikler

Idempotent Operasyonlar: CRDT’lerdeki birleşme (merge) fonksiyonları sıklıkla idempotent olarak tasarlanır. Yani aynı güncelleme birden fazla kez uygulanırsa aynı sonuca ulaşılır.
Commutativity (Değişme Özelliği): Operasyonlar farklı sırayla uygulanırsa da nihai durum aynı kalır.
Monotonik Büyüme: Bazı CRDT türlerinde (özellikle state-based CRDT’lerde) veri yapısı her zaman büyüyormuş gibi görülür. Güncellemeler eklemeler veya işaretlemeler şeklinde yapılır, ancak bu daha sonra farklı bir formülasyonla “çıkarmalara” (removals) da izin verir (örn: OR-Set).
Güçlü Sonunda Tutarlılık (Strong Eventual Consistency): Belirli bir zaman diliminde, tüm kopyalar birbirlerinden güncellemeleri alıp birleştirdiklerinde, nihai durumda hepsi aynı veriye ulaşırlar.

CRDT’lerin sağladığı bu özellikler, dağıtık sistemlerin en büyük zorluklarından biri olan tutarlılık problemini hafifletmeyi amaçlar. Özellikle CAP Teoremi gereği, bir sistemi hem yüksek erişilebilirlik (availability) hem de bölünme toleransı (partition tolerance) yüksek biçimde tasarlamak istersek, tutarlılık sorunlarına ayrı bir özen göstermemiz gerekir. CRDT’ler, “eventual consistency” yaklaşımı içinde çatışma çözümünü basitleştirerek bu soruna kısmi ama etkili bir çözüm sunar.

2. CRDT Türleri

CRDT’ler genel olarak Operation-based ve State-based olmak üzere iki temel kategoride incelenir. Ayrıca Delta-based denilen bir yaklaşım da vardır.

2.1. Operation-based (Op-based) CRDT’ler

Op-based CRDT’lerde, gerçekleşen her bir değişiklik (örneğin bir sayının artırılması, bir elemana ekleme yapılması) “operation log” benzeri bir sistem aracılığıyla diğer replikalara gönderilir. Bu replikalar gelen güncellemeyi uygular ve kendi durumlarını güncel tutarlar.

Örnek: GCounter (Grow-only Counter), PN-Counter (Positive-Negative Counter).

2.2. State-based (Convergent) CRDT’ler

State-based CRDT’lerde, her replikada bir “durum” (state) tutulur. Farklı replikalar zaman zaman birbirlerinin durumunu kopyalar (gossip mekanizması gibi) ve durumu birleştirir (merge). Bu birleşme işlemi idempotent, değişmeli (commutative) ve birleşmeli (associative) olduğundan, sıralama farkı gözetmeksizin aynı nihai duruma ulaşılabilir.”

Örnek: OR-Set (Observed-Removed Set), MV-Register (Multi-Value Register).

2.3. Delta-based CRDT’ler

Delta-based CRDT’ler, state-based yaklaşımın daha verimli hâlidir. Tam durumu göndermek yerine, sadece “delta” denilen özet (küçük bir parça) paylaşılır. Böylece bant genişliği ve senkronizasyon maliyeti azalır. Büyük veri setlerinde oldukça kullanışlıdır.

2.4. Bazı Popüler CRDT Örnekleri

G-Counter: Yalnızca artırım (increment) işlemlerini destekleyen bir sayaçtır.
PN-Counter: Hem artırım hem de eksiltme (decrement) işlemlerini destekler.
OR-Set (Observed-Removed Set): Eleman ekleme ve çıkarma operasyonlarını destekleyen bir küme yapısıdır. Aynı elemanın farklı zamanlardaki eklenme/çıkarılma bilgisini tutmak için ek metadata içerir.
LWW-Register (Last-Write-Wins Register): Son yazılan değerin baskın geldiği bir kayıt yapısıdır. Bir tür “en son değiştiren kazanır” (last-writer-wins) mantığı kullanır.
MV-Register (Multi-Value Register): Aynı anda farklı replikalarda farklı değerler yazıldığında birden fazla değeri tutar ve uygulamanın bu değerler arasındaki seçimi yapmasına izin verir.
RGA (Replicated Growable Array): Metin düzenleme veya doküman paylaşımı gibi senaryolarda kullanılır.

3. CRDT’lerin Kullanım Alanları ve Avantajları

Veri Tabanları ve Data Stores: Riak gibi bazı veritabanları CRDT kavramlarını benimsemiş veya kısmen kullanmıştır. Redis gibi bellek içi veri yapısı kullanan teknoloji stack’lerinde de CRDT kütüphaneleri bulunmaktadır.
Gerçek Zamanlı İşbirliği Uygulamaları: Google Docs benzeri uygulamalarda aynı dokümanı birden fazla kişi eş zamanlı olarak düzenler. CRDT’ler, bu senaryolarda çatışmaların çözümlenmesini kolaylaştırabilir.
Oyun Sunucuları ve Multiplayer Senaryolar: Oyuncuların hareketleri, skor tablosu, envanter bilgileri gibi gerçek zamanlı güncellemelerin yapıldığı ortamlarda CRDT’ler kullanılabilir.
Dağıtık Cache Sistemleri: Coğrafi olarak dağınık bölgelerde cache tutmak ve senkronize etmek için CRDT’ler, yüksek performans ve veri bütünlüğü sunar.

3.1. Avantajlar

Basit Çatışma Çözümü: CRDT’ler, tasarımları gereği çatışmaları minimize eder veya tamamen ortadan kaldırır.
Eventual Consistency: CRDT’ler, CAP Teoremi bağlamında erişilebilirlik (availability) ve bölünme toleransını (partition tolerance) öne çıkarmak isteyen sistemlerde tutarlılığı “eventually” düzeyinde sağlar.
Kolay Geliştirilebilirlik: CRDT yapıları bir kez anlaşıldığında, uygulamada karmaşık çatışma çözümü algoritmaları yazmaya gerek kalmaz.
Idempotent ve Commutative Operasyonlar: Dağıtık sistemlerde mesaj kaybı, tekrar iletimi veya farklı sıralama gibi durumlar yaşandığında, CRDT’ler aynı veriyi tekrarlayarak veya farklı sıralarla işleme almaktan etkilenmez.

3.2. Dezavantajlar

Ek Metadata: CRDT’ler genellikle ek metadata tutar. Bu, bellek kullanımı açısından ek yük oluşturabilir.
Her Türlü Operasyonu Kapsamaz: CRDT modelleri, tüm veri yapısı türleri veya tüm uygulama ihtiyaçları için en uygun çözüm olmayabilir.
İşlemin “Son Hali” Anlamı Değişebilir: Eventual consistency doğası gereği, veri durumunun “anlık” hâli sistem genelinde tutarlı olmayabilir. Zamanla tutarlı hâle gelir.

4. Örnek CRDT Uygulaması

Aşağıdaki örnekte, dağıtık ortamda G-Counter (sadece artım yapan sayaç) mantığını Go diliyle basit bir şekilde göstereceğiz. Bu sayaç, her bir replikada artan değerleri tutar ve replikalar arasındaki değerler birleştirilerek (merge) toplam sonuca ulaşır.

Not: Bu kod örneği tümüyle “production-grade” düzeyde bir CRDT olmayıp, konsepti açıklamaya yöneliktir.

package main

import (
    "fmt"
    "sync"
)

// GCounter represents a simple grow-only counter CRDT.
type GCounter struct {
    // internal slice holds the counters for each replica
    values []int
    mu     sync.Mutex
}

// NewGCounter initializes a GCounter with a given number of replicas.
func NewGCounter(numReplicas int) *GCounter {
    return &GCounter{
        values: make([]int, numReplicas),
    }
}

// Increment increments the counter for the given replica ID.
func (c *GCounter) Increment(replicaID int) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.values[replicaID]++
}

// Value returns the total count by summing all replica counters.
func (c *GCounter) Value() int {
    c.mu.Lock()
    defer c.mu.Unlock()

    total := 0
    for _, v := range c.values {
        total += v
    }
    return total
}

// Merge merges another GCounter into the current one. 
// It takes the maximum value for each replica index.
func (c *GCounter) Merge(other *GCounter) {
    c.mu.Lock()
    defer c.mu.Unlock()

    // We assume both counters have the same length.
    for i := 0; i < len(c.values); i++ {
        if other.values[i] > c.values[i] {
            c.values[i] = other.values[i]
        }
    }
}

func main() {
    // Suppose we have 3 replicas in the system
    gc1 := NewGCounter(3)
    gc2 := NewGCounter(3)
    gc3 := NewGCounter(3)

    // Replica 1 increments its local counter
    gc1.Increment(0) // increment by replicaID = 0
    gc1.Increment(0)
    gc1.Increment(0)

    // Replica 2 increments its local counter
    gc2.Increment(1) // increment by replicaID = 1
    gc2.Increment(1)

    // Replica 3 increments its local counter
    gc3.Increment(2) // increment by replicaID = 2
    gc3.Increment(2)
    gc3.Increment(2)
    gc3.Increment(2)

    // Let's merge them to simulate synchronization
    gc1.Merge(gc2)
    gc1.Merge(gc3)

    // Now all replicas would eventually do the same merges:
    gc2.Merge(gc1)
    gc3.Merge(gc1)

    // The total value of any merged replica should be:
    // gc1 replica: 3 increments (by replica 0)
    // gc2 replica: 2 increments (by replica 1)
    // gc3 replica: 4 increments (by replica 2)
    // => total = 3 + 2 + 4 = 9
    fmt.Println("Final merged value at gc1:", gc1.Value())
    fmt.Println("Final merged value at gc2:", gc2.Value())
    fmt.Println("Final merged value at gc3:", gc3.Value())
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Final merged value at gc1: 9
Final merged value at gc2: 9
Final merged value at gc3: 9

Programın çalışır haline şuradan erişilebilir.

GCounter Yapısı (Struct): values dizisi her bir replikanın kendi lokal sayacını tutar.
Increment: Belirtilen replicaID’nin sayacını artırır.
Value: Tüm replikaların sayacını toplayarak o anki toplam değeri döndürür.
Merge: İki GCounter’ı birleştirir. Aynı index (replicaID) için maksimum değeri alır. Böylece kimsenin yaptığı artış kaybolmaz. Bu, “grow-only” mantığına dayanır.

Gerçek bir sistemde bu değerlerin ağ üzerinden diğer replikalara taşınması, gossip protokolleri veya bir mesajlaşma sistemiyle yapılabilir. Ayrıca, replikalarda belirli aralıklarla gelen güncellemeler birleştirilebilir.

CRDT’ler (Conflict-free Replicated Data Types), günümüz dağıtık sistemlerinde sık sık karşılaşılan veri tutarlılığı ve çatışma (conflict) problemlerine etkin çözümler sunarlar. Geleneksel dağıtık veri yapılarına göre daha fazla metadata gerektirmelerine rağmen, güçlü sonunda tutarlılık (Strong Eventual Consistency) sağlamada önemli bir kavramdır.

CRDT yaklaşımı, mikroservisler, gerçek zamanlı işbirliği (collaborative editing) ortamları ve veri tutarlılığının kritik olduğu birçok senaryoda sıklıkla karşımıza çıkmaktadır. Uygulama gereksinimlerinize uygun CRDT yapısını seçerek, dağıtık ortamdaki veri tutarlılığı sorunlarını büyük oranda yönetilebilir bir seviyeye çekebilirsiniz. Özellikle artan kullanıcı sayısı, veri merkezi sayısı ve coğrafi dağıtım gibi karmaşık problemlerin yaşandığı ortamlarda CRDT’lerin sağladığı kolaylıklar son derece değerlidir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

UNIX: Modern İşletim Sistemlerinin Temeli

Mon, 19 Aug 2024 00:00:00 GMT

Bilgisayar dünyasında bazı teknolojiler zamanla unutulsa da bazıları kök salıp diğer birçok yeniliğin temelini oluşturur. UNIX işletim sistemi işte tam da bu kategoriye girer. Dennis M. Ritchie ve Ken Thompson tarafından 1970’lerin başında geliştirilen UNIX, bugün modern işletim sistemlerinin birçoğunun temelini oluşturan devrim niteliğinde bir yazılımdır.

UNIX’in Doğuşu: Basitlikten Güce

UNIX, başlangıçta Bell Labs’de küçük bir ekip tarafından mütevazı bir zaman paylaşımı sistemi olarak geliştirildi. Ritchie ve Thompson’un öncelikli amacı, kullanıcıların bilgisayar kaynaklarını verimli bir şekilde paylaşmalarını sağlamak ve aynı anda birden çok işlemi yönetebilen bir sistem oluşturmaktı. UNIX’in başarısının arkasındaki en büyük etkenlerden biri sistemin tasarım felsefesiydi: Basitlik, modülerlik ve taşınabilirlik.

Tasarım Felsefesi: Kapsamlı Bir Minimalizm

UNIX’in tasarım felsefesi, sistemi hem kullanıcılar hem de geliştiriciler için mümkün olduğunca sade tutmaktı. Sistem her bir bileşenin yalnızca tek bir işi yapmasına ancak bunu en iyi şekilde yapmasına dayanıyordu. Bu felsefe UNIX’in temel araçlarının ve komutlarının her biri için geçerlidir. Örneğin; grep, find ve cat gibi UNIX komutları kendi başlarına küçük görevleri yerine getirirler ancak bu komutlar bir araya getirilerek son derece karmaşık işlemler gerçekleştirilebilir.

Bu modüler yaklaşım UNIX’i diğer işletim sistemlerinden ayırdı. Kullanıcılar kendi ihtiyaçlarına göre sistemi özelleştirebilir, yeni araçlar geliştirebilir ve bunları mevcut sistemle sorunsuz bir şekilde entegre edebilirlerdi. Bu esneklik UNIX’in popülaritesinin hızla artmasına neden oldu.

Dosya Sistemi: Her Şeyin Dosya Olduğu Bir Dünya

UNIX dosya sistemini bir hiyerarşi içinde organize ederek, kullanıcıların ve süreçlerin dosyalarla etkileşimini son derece kolaylaştırdı. UNIX dünyasında hemen her şey bir dosya olarak kabul edilir: Veriler, cihazlar, süreçler ve hatta ağ bağlantıları. Bu yaklaşım sistemin kullanımını ve genişletilmesini son derece kolay hale getirdi.

Bu hiyerarşik dosya sistemi yapısı kullanıcıların ve uygulamaların dosyaları ve dizinleri mantıksal bir şekilde düzenlemesine olanak tanıdı. Bu düzenleme şekli modern işletim sistemlerinde hala yaygın olarak kullanılmaktadır ve UNIX’in bu alandaki öncülüğünü gösterir.

Süreç Yönetimi: Zaman Paylaşımından Çoklu Görevlere

UNIX’in en dikkat çekici özelliklerinden biri süreç yönetimindeki yenilikleridir. UNIX çoklu görev (multitasking) ve zaman paylaşımı gibi kavramları etkili bir şekilde uygulayarak birden fazla kullanıcının aynı anda sistemi kullanabilmesini sağladı. Bu süreç yönetimi bilgisayar kaynaklarının verimli kullanımını mümkün kıldı ve UNIX’in performansını zirveye taşıdı.

Süreçlerin hafifliği ve yönetim kolaylığı, UNIX’in çok kullanıcıyı desteklemesini ve aynı anda birçok işlemi yerine getirebilmesini sağladı. Bu özellikler UNIX’in zamanla birçok farklı platformda kullanılabilmesini mümkün kıldı.

UNIX ve C Dili: Taşınabilirliğin Gücü

UNIX’in gelişimi aynı zamanda C programlama diliyle yakından ilişkilidir. UNIX’in büyük bir kısmı C diliyle yazıldı ve bu sayede sistemin farklı donanım platformlarına taşınması kolaylaştı. Bu taşınabilirlik UNIX’in yayılmasını hızlandırdı ve farklı bilgisayar sistemlerinde standart bir işletim sistemi haline gelmesini sağladı.

C dili ve UNIX birbiriyle adeta iç içe geçmiş iki teknoloji olarak bilgisayar dünyasında önemli bir yer edindi. UNIX’in taşınabilirliği sayesinde bu işletim sistemi sadece Bell Labs’in sınırları içinde kalmadı; üniversitelerde, araştırma kurumlarında ve hatta ticari ortamlarda da yaygın olarak kullanılmaya başlandı.

Sonuç: UNIX’in Mirası

“The UNIX Time-Sharing System” makalesi, sadece UNIX’in teknik detaylarını sunmakla kalmaz, aynı zamanda bilgisayar biliminde devrim niteliğindeki bu sistemin etkilerini de gözler önüne serer. UNIX’in basitlik ve taşınabilirlik ilkeleri, modern işletim sistemlerinin tasarımında temel rol oynamış ve bugünün teknoloji dünyasında bile geçerliliğini korumuştur.

UNIX’in mirası Linux, macOS ve hatta Windows’un çeşitli unsurlarında yaşamaya devam ediyor. Geliştiriciler ve teknoloji meraklıları için UNIX sadece bir işletim sistemi değil, aynı zamanda bir tasarım felsefesi ve bir düşünme biçimidir. Bu nedenle UNIX’i anlamak, modern bilgisayar biliminin kökenlerine bir yolculuk yapmaktır.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

OSI Modeli: Derinlemesine Bir İnceleme

Sat, 08 Jun 2024 00:00:00 GMT

Ağ iletişimi ve bilgi teknolojileri alanında, farklı sistemlerin birbirleriyle uyum içinde çalışabilmesi için ortak bir çerçeveye ihtiyaç duyulmaktadır. Bu bağlamda OSI (Open Systems Interconnection) Modeli, çeşitli ağ ve iletişim protokollerinin nasıl çalıştığını ve nasıl birbiriyle etkileşime girdiğini anlamak için kullanılan temel bir kavramsal modeldir. OSI Modeli, Uluslararası Standardizasyon Örgütü (ISO) tarafından geliştirilmiş ve 1984 yılında yayınlanmıştır.

OSI Modeli yedi katmandan oluşur ve her katman belirli bir ağ fonksiyonunu temsil eder. Bu katmanlar donanım ve yazılım bileşenlerinin birbirleriyle nasıl etkileşime girdiğini açıklar ve ağ iletişimini daha iyi yönetmek için bir referans noktası sağlar.

Modern İnternet OSI’ye değil, daha basit olan TCP/IP modeline dayanmaktadır. Ancak OSI 7 katmanlı modeli, ağların nasıl çalıştığını görselleştirmeye ve iletmeye yardımcı olduğu ve ağ sorunlarını izole etmeye ve gidermeye yardımcı olduğundan hala yaygın olarak kullanılmaktadır. Günümüzde OSI modeli öncelikle bilgisayar uzmanlarına bilgisayar ağlarının temellerini öğretmek için bir referans modeli olarak kullanılmaktadır.

1. Fiziksel Katman (Physical Layer)

Fiziksel Katman, OSI Modeli’nin en alt katmanıdır ve fiziksel iletişim ortamının özelliklerini tanımlar. Bu katman veri iletiminin fiziksel yönlerini ele alır ve kablolar, konektörler, elektriksel sinyaller, optik sinyaller gibi fiziksel bileşenlerle ilgilenir. Fiziksel Katman’ın temel görevleri şunlardır:

- Fiziksel Ortamın Seçimi: Veri iletimi için kullanılacak ortamın belirlenmesi (örneğin, bakır kablolar, fiber optik kablolar, radyo dalgaları).

- Sinyal İletimi: Dijital verilerin analog sinyallere dönüştürülmesi ve bu sinyallerin fiziksel ortam üzerinden iletilmesi.

- Bağlantı Uçları: Cihazların fiziksel bağlantı noktalarının (portlar) yönetimi ve tanımlanması.

- Kablo Bağlantıları: Kabloların ve konektörlerin fiziksel yapılandırılması ve yönetimi.

Örnek protokoller: IEEE 1394, DSL, ISDN

2. Veri Bağlantı Katmanı (Data Link Layer)

Veri Bağlantı Katmanı, veri iletiminin güvenilir bir şekilde gerçekleşmesini sağlar ve fiziksel katmanın sunduğu hizmetleri kullanarak çerçeve (frame) adı verilen veri birimlerinin iletimini gerçekleştirir. Bu katmanın temel görevleri şunlardır:

- Çerçeveleme (Framing) Verilerin çerçeveler halinde paketlenmesi.

- Hata Kontrolü: İletim sırasında meydana gelebilecek hataların tespiti ve düzeltilmesi (örneğin, CRC - Düzeltme Kodları).

- Akış Kontrolü: Verilerin alıcı ve verici arasında dengeli bir şekilde iletilmesini sağlama.

- MAC Adresi Yönetimi: Fiziksel adresleme ile veri paketlerinin doğru hedefe yönlendirilmesi.

Veri Bağlantı Katmanı, ayrıca iki alt katmana ayrılabilir:

-MAC (Media Access Control) Alt Katmanı: Veri iletim ortamına erişimi kontrol eder ve çerçevelerin fiziksel adresleme işlevini yürütür.

-LLC (Logical Link Control) Alt Katmanı: Hata kontrolü ve akış kontrolü işlevlerini yönetir.

Örnek protokoller: SLIP, PPP

3. Ağ Katmanı (Network Layer)

Ağ Katmanı, veri paketlerinin ağlar arasında yönlendirilmesi ve iletilmesi ile ilgilenir. Bu katman kaynak ve hedef cihazlar arasında en uygun yolun seçilmesi ve veri paketlerinin bu yol üzerinden iletilmesini sağlar. Ağ Katmanı’nın temel görevleri şunlardır:

- Yönlendirme (Routing): Veri paketlerinin kaynak ve hedef arasında en uygun yoldan iletilmesi.

- Mantıksal Adresleme: IP adresleri gibi mantıksal adreslerin kullanımı ve yönetimi.

- Paketleme (Packetizing): Verilerin paketler halinde düzenlenmesi.

- Trafik Kontrolü: Ağ trafiğinin yönetimi ve veri iletim yollarının optimize edilmesi.

Örnek protokoller: IP, ARP, RARP, BOOTP, ICMP

4. Taşıma Katmanı (Transport Layer)

Taşıma Katmanı, uçtan uca veri iletimini sağlar ve verilerin doğru bir şekilde iletilmesi için güvenilirlik, hata kontrolü ve akış kontrolü gibi işlevleri yerine getirir. Bu katmanın temel görevleri şunlardır:

- Bağlantı Kontrolü: Uç cihazlar arasında bağlantı kurulması, yönetilmesi ve sonlandırılması.

- Hata Kontrolü: Verilerin bütünlüğünün sağlanması ve iletim hatalarının düzeltilmesi.

- Akış Kontrolü: Verilerin dengeli bir şekilde iletilmesi ve tampon taşmalarının önlenmesi.

- Segmentasyon ve Yeniden Birleştirme: Büyük veri bloklarının daha küçük segmentlere bölünmesi ve alıcıda yeniden birleştirilmesi.

Örnek protokoller: TCP, UDP

5. Oturum Katmanı (Session Layer)

Oturum Katmanı, iki cihaz arasındaki iletişim oturumlarını yönetir. Bu katman oturumların kurulması, yönetilmesi ve sonlandırılması ile ilgilenir. Oturum Katmanı’nın temel görevleri şunlardır:

- Oturum Kurulumu ve Yönetimi: İki cihaz arasında iletişim oturumlarının başlatılması ve yönetilmesi.

- Senkronizasyon: Verilerin doğru sırayla iletilmesi için senkronizasyon noktalarının belirlenmesi.

- Oturum Kontrolü: Oturumların devamlılığının sağlanması ve gerektiğinde yeniden başlatılması.

Örnek protokoller: NFS, RPC, X WİNDOWS SYSTEM, APPLE TALK SESSİON PROTOCOL

6. Sunum Katmanı (Presentation Layer)

Sunum Katmanı, verilerin uygulama katmanında anlaşılabilir hale getirilmesi için gereken işlemleri gerçekleştirir. Bu katman veri biçimlendirme, şifreleme ve sıkıştırma gibi işlemlerden sorumludur. Sunum Katmanı’nın temel görevleri şunlardır:

- Veri Biçimlendirme: Farklı veri formatlarının (örneğin, ASCII, EBCDIC, JPEG) dönüştürülmesi.

- Şifreleme: Verilerin güvenliğini sağlamak için şifreleme işlemleri.

- Sıkıştırma: Veri boyutunu küçültmek için sıkıştırma işlemleri.

Örnek protokoller: GIF, JPEG, TIFF, EBCDIC, ASCII

7. Uygulama Katmanı (Application Layer)

Uygulama Katmanı, kullanıcıların ve uygulamaların ağ hizmetlerine doğrudan erişim sağladığı katmandır. Bu katman çeşitli ağ hizmetleri ve protokoller aracılığıyla uygulamalar arasında veri alışverişini gerçekleştirir. Uygulama Katmanı’nın temel görevleri şunlardır:

- Ağ Hizmetleri: E-posta, dosya transferi, uzaktan erişim gibi ağ hizmetlerinin sağlanması.

- Uygulama Protokolleri: HTTP, FTP, SMTP gibi protokoller aracılığıyla veri iletimi.

- Kullanıcı Arayüzleri: Kullanıcıların ağ hizmetlerine erişim sağladığı arayüzlerin yönetimi.

Örnek protokoller: SSH, Telnet, FTP, DNS, HTTP

OSI Modelinin Önemi

OSI (Open Systems Interconnection) Modeli, bilgi teknolojileri alanında birçok önemli rol oynamaktadır. İşte bu modelin bazı temel avantajları ve detayları:

Standartlaşma

OSI Modeli, farklı üreticiler tarafından geliştirilen sistemlerin ve protokollerin birlikte çalışabilirliğini sağlar. Bu, ağ cihazlarının ve yazılımlarının evrensel olarak uyumlu olmasına olanak tanır. Örneğin, bir üretici tarafından geliştirilen bir yönlendirici, başka bir üretici tarafından geliştirilen bir anahtar ile sorunsuz bir şekilde iletişim kurabilir. Bu standartlaşma, pazarın genişlemesini ve daha yenilikçi çözümler geliştirilmesini teşvik eder.

Eğitim

OSI Modeli, ağ iletişimi konularının anlaşılmasını ve öğretilmesini kolaylaştırır. Modelin yedi katmanlı yapısı, karmaşık ağ süreçlerinin daha basit ve anlaşılır parçalara ayrılmasını sağlar. Bu, öğrencilere ve yeni başlayanlara ağ teknolojilerini anlamada büyük kolaylık sağlar. Örneğin, fiziksel katmandan uygulama katmanına kadar olan her bir katman, belirli işlevlere ve görevlere odaklanır, böylece eğitim materyallerinin ve ders planlarının yapılandırılmasını basitleştirir.

Sorun Giderme

Ağ sorunlarının belirlenmesi ve çözülmesi sürecinde yapılandırılmış bir yaklaşım sunar. OSI Modeli, ağ sorunlarını belirli katmanlar üzerinden izole ederek çözme olanağı tanır. Bu, ağ yöneticilerinin ve teknisyenlerinin sorunun kaynağını hızlı ve etkili bir şekilde tespit etmelerine yardımcı olur. Örneğin, bir bağlantı sorunu yaşandığında, sorun fiziksel katmandan mı yoksa daha üst katmanlardan mı kaynaklandığını belirlemek için sistematik bir yaklaşım benimsenir.

Geliştirme

Yeni ağ protokollerinin ve teknolojilerinin geliştirilmesi için bir referans çerçevesi sağlar. OSI Modeli, yeni teknolojilerin ve protokollerin mevcut sistemlerle uyumlu olmasını sağlayacak bir yapı sunar. Bu, geliştiricilerin ve mühendislerin, yenilikçi çözümler üretirken belirli standartlara uyum sağlamalarını kolaylaştırır. Örneğin, yeni bir iletişim protokolü geliştirildiğinde, bu protokolün OSI Modeli’nin belirli katmanlarına nasıl uyum sağlayacağı ve diğer protokollerle nasıl etkileşime gireceği belirlenir.

Katmanlar Arası Bağımsızlık

OSI Modeli, her bir katmanın belirli bir işlevi yerine getirmesini sağlar ve bu katmanların birbirinden bağımsız çalışmasına olanak tanır. Bu bağımsızlık, bir katmanda yapılan değişikliklerin diğer katmanları etkilememesini sağlar. Örneğin, veri bağlantı katmanında yapılan bir iyileştirme, uygulama katmanındaki işlemleri etkilemez, bu da esneklik ve sürdürülebilirlik sağlar.

Evrensel Kabul

OSI Modeli, dünya çapında kabul görmüş bir standart olarak, küresel ağ iletişiminin temeli olarak hizmet eder. Bu evrensel kabul, farklı ülkeler ve organizasyonlar arasında uyumlu ve sorunsuz iletişim kurulmasını sağlar. Örneğin, uluslararası bir şirket, farklı ülkelerdeki şubeleri arasında güvenilir ve uyumlu bir ağ altyapısı kurabilir.

OSI Modeli, ağ iletişimi ve bilgi teknolojileri dünyasında hayati bir rol oynamaktadır. Yedi katmandan oluşan bu model, veri iletiminin her aşamasını detaylı bir şekilde açıklar ve ağ bileşenlerinin birlikte nasıl çalıştığını anlamamıza yardımcı olur. OSI Modeli sayesinde ağ sorunları daha hızlı ve etkili bir şekilde çözülebilir, yeni teknolojiler geliştirilebilir ve ağ iletişimi daha güvenilir hale getirilebilir. Bu nedenle OSI Modeli, ağ uzmanları ve bilgi teknolojileri profesyonelleri için vazgeçilmez bir araçtır.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

MoSCoW Önceliklendirmesi Nedir?

Wed, 05 Jun 2024 00:00:00 GMT

MoSCoW, yazılım projelerinde ve diğer proje yönetimi süreçlerinde öncelikleri belirlemek için kullanılan bir metodolojidir. Bu yöntem projenin gereksinimlerini ve özelliklerini sınıflandırarak hangi öğelerin öncelikli olduğunu netleştirmeye yardımcı olur. MoSCoW yöntemi dört ana kategoriden oluşur: Must have (Olmazsa Olmaz), Should have (Olmalı), Could have (Olabilir) ve Won’t have (Olmayacak). Bu kategoriler projenin başarıya ulaşması için gerekli olan gereksinimlerin önem derecesine göre sıralanmasına olanak tanır.

MoSCoW Yönteminin Kategorileri

1. Must have (Olmazsa Olmaz): Bu kategoride yer alan gereksinimler, projenin tamamlanabilmesi için mutlak surette karşılanması gereken öğelerdir. Bu gereksinimler karşılanmadığı takdirde, projenin teslim edilemeyeceği veya beklenen işlevselliği yerine getiremeyeceği kabul edilir.

2. Should have (Olmalı): Bu gereksinimler önemli olup, projenin başarısını artıran ve kullanılabilirliğini yükselten özelliklerdir. Must have gereksinimlerinin ardından gelmekle birlikte, zaman veya kaynak sıkıntısı yaşanmadıkça projeye dahil edilmelidirler.

3. Could have (Olabilir): Bu kategoride yer alan gereksinimler, projenin genel performansını veya kullanıcı deneyimini iyileştiren ancak zorunlu olmayan özelliklerdir. Eğer zaman ve kaynak izin verirse, projeye dahil edilebilirler.

4. Won’t have (Olmayacak): Bu gereksinimler mevcut proje döngüsünde ele alınmayacak olan ancak gelecekteki versiyonlarda veya projelerde değerlendirilebilecek özelliklerdir. Bu kategori, proje kapsamını daraltmak ve öncelikleri netleştirmek için kullanılır.

Yazılım Mühendisliğinde MoSCoW Örnekleri

Bir yazılım projesinde MoSCoW metodolojisinin nasıl uygulanabileceğini açıklamak için bir örnek üzerinden ilerleyelim. Diyelim ki bir e-ticaret platformu geliştiriyorsunuz.

Must Have

1. Kullanıcı Kaydı ve Giriş Sistemi: Kullanıcıların platforma kayıt olabilmesi ve giriş yapabilmesi temel bir gereksinimdir. Bu özellik olmadan, kullanıcılar alışveriş yapamaz ve sistem kullanılabilir olmaz.

2. Ürün Kataloğu ve Arama Fonksiyonu: Kullanıcılar, ürünleri görüntüleyebilmek ve arama yaparak istedikleri ürünlere ulaşabilmek zorundadır. Bu özellik, alışveriş deneyiminin temelini oluşturur.

3. Sepet ve Ödeme Sistemi: Kullanıcıların seçtikleri ürünleri sepete ekleyip güvenli bir şekilde ödeme yapabilmesi, e-ticaret platformunun olmazsa olmazıdır.

Should Have

1. Ürün İncelemeleri ve Puanlama Sistemi: Kullanıcıların ürünler hakkında inceleme yazabilmesi ve puanlama yapabilmesi, satın alma kararlarını etkileyen önemli bir özellik olup, kullanıcı memnuniyetini artırır.

2. Sipariş Takip Sistemi: Kullanıcılar, verdikleri siparişlerin durumunu takip edebilmelidir. Bu özellik, müşteri deneyimini iyileştiren önemli bir unsurdur.

Could Have

1. Kişisel Öneri Sistemi: Kullanıcıların alışveriş geçmişine ve ilgi alanlarına göre ürün önerileri almak, deneyimi zenginleştiren bir özellik olup, satışları artırabilir.

2. Sosyal Medya Entegrasyonu: Kullanıcıların, ürünleri sosyal medya hesaplarında paylaşabilmesi veya sosyal medya ile giriş yapabilmesi, kullanıcı etkileşimini artırabilir.

Won’t Have

1. Sanal Deneme Kabini: Kullanıcıların kıyafetleri sanal olarak üzerlerinde denemelerini sağlayan bir özellik, ileri seviyede teknoloji ve kaynak gerektirebilir. Bu özellik, mevcut proje döngüsünde planlanmayabilir ancak gelecekte değerlendirilebilir.

2. Blockchain Tabanlı Ödeme Sistemleri: Alternatif ödeme yöntemleri olarak blockchain teknolojisinin entegrasyonu, mevcut projenin kapsamı dışında kalabilir ve gelecekteki versiyonlar için düşünülebilir.

MoSCoW Yönteminin Avantajları

1. Önceliklerin Netleşmesi: Gereksinimlerin önem sırasına göre kategorize edilmesi, ekiplerin en kritik öğelere odaklanmasını sağlar.

2. Esneklik: Projenin ilerleme aşamasında zaman ve kaynak yönetimine esneklik kazandırır, böylece gereksinimlerin karşılanma sırası değişebilir.

3. Kaynak Yönetimi: Zaman, para ve insan kaynakları gibi sınırlı kaynakların etkin bir şekilde kullanılmasına yardımcı olur.

4. Kapsam Yönetimi: Proje kapsamının net bir şekilde tanımlanmasına ve gereksiz özelliklerin eklenmemesine olanak tanır.

Sonuç

MoSCoW yöntemi, yazılım projelerinde gereksinimlerin ve özelliklerin önceliklendirilmesi sürecinde etkili bir araçtır. Projenin başarısı için kritik olan öğeleri belirlemek, ekiplerin doğru yönlendirilmesi ve kaynakların verimli kullanılması açısından büyük önem taşır. Bu metodoloji projelerin zamanında ve bütçe dahilinde tamamlanmasına yardımcı olurken, aynı zamanda kullanıcı memnuniyetini de artırır. E-ticaret platformu örneğinde olduğu gibi, MoSCoW yöntemi her tür yazılım projesine uygulanabilir ve projelerin daha başarılı olmasını sağlayabilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Event Sourcing

Sun, 02 Jun 2024 00:00:00 GMT

Event sourcing, veri yönetimi ve sistem tasarımında kullanılan modern ve etkili bir desendir. Geleneksel veri yönetimi yaklaşımlarından önemli ölçüde farklılık gösterir. Geleneksel yöntemlerde veriler genellikle son durumlarıyla saklanır; yani bir nesnenin güncel durumu doğrudan veri tabanında tutulur ve herhangi bir değişiklik yapıldığında bu son durum güncellenir. Ancak event sourcing yaklaşımında veriler bir dizi olay (event) olarak saklanır. Her olay sistemde gerçekleşen bir değişikliği veya eylemi temsil eder. Bu olaylar kronolojik bir sırayla kaydedilir ve saklanır.

Event sourcing’in temel ilkesi, bir nesnenin mevcut durumunu doğrudan saklamak yerine, bu durumu belirleyen tüm olayların bir listesini saklamaktır. Bir nesnenin durumu, bu olayların sıralı bir şekilde yeniden oynatılması (replay) ile yeniden oluşturulur. Bu sayede herhangi bir anda bir nesnenin geçmişteki herhangi bir durumuna erişmek veya belirli bir zaman dilimindeki değişiklikleri izlemek mümkün hale gelir.

Bu yaklaşımın birçok avantajı vardır. İlk olarak, veri tutarlılığı sağlanır çünkü her değişiklik bir olay olarak kaydedilir ve bu olaylar sıralı bir şekilde işlenir. İkinci olarak, sistem izlemesi ve hata toleransı artar; çünkü sistemde meydana gelen tüm değişiklikler olaylar üzerinden izlenebilir ve gerektiğinde geri alınabilir. Üçüncü olarak, denetlenebilirlik ve şeffaflık sağlanır; çünkü tüm olaylar kaydedildiğinden dolayı, sistemin nasıl ve neden bu duruma geldiği detaylı bir şekilde incelenebilir.

Event sourcing ayrıca, özellikle dağıtık sistemlerde, veri senkronizasyonu ve tutarlılığı konularında da büyük avantajlar sunar. Her olay merkezi bir olay günlüğüne kaydedilir ve bu olaylar farklı bileşenler arasında paylaşılabilir. Bu sayede sistemin farklı parçaları arasında tutarlı bir veri durumu sağlanabilir. Ayrıca event sourcing, CQRS (Command Query Responsibility Segregation) gibi diğer modern mimari desenlerle birlikte kullanıldığında, sistemin performansını ve ölçeklenebilirliğini artırabilir.

Event sourcing, modern yazılım mimarilerinde önemli bir rol oynayan, güçlü ve esnek bir veri yönetim yaklaşımıdır. Veri tutarlılığı, sistem izlemesi, hata toleransı ve denetlenebilirlik gibi avantajları sayesinde, özellikle karmaşık ve büyük ölçekli sistemlerde tercih edilen bir yöntemdir.

Temel Kavramlar

Event (Olay): Sistem içerisinde gerçekleşen her türlü değişiklik bir olay olarak kaydedilir. Örneğin, bir kullanıcının kaydedilmesi, bir ürünün eklenmesi veya bir siparişin tamamlanması bir olaydır.
Event Store: Olayların kalıcı olarak saklandığı yerdir. Geleneksel veritabanlarından farklı olarak, burada sadece olaylar saklanır.
Aggregate: Bir dizi olayı temsil eden ve bu olayları işleyerek bir durumu (state) oluşturan yapı.
Command (Komut): Sistem tarafından gerçekleştirilecek işlemleri tanımlar. Örneğin, “Sipariş Ver” bir komuttur.
Projection (Projeksiyon): Olaylardan durumu oluşturur ve bu durumu farklı veri modellerine dönüştürür.

Event Sourcing’in Avantajları

Denetlenebilirlik: Geçmişte ne olduğunu anlamak için tüm olaylar kaydedilir. Böylece, sistemin nasıl bu duruma geldiği izlenebilir.
Esneklik: Yeni veri modelleri oluşturmak veya mevcutları değiştirmek daha kolaydır. Projeksiyonlar sayesinde veriyi farklı şekillerde sunabilirsiniz.
Gerçek Zamanlı İşleme: Olaylar anında işlenebilir ve sistemin diğer parçalarına iletilebilir.

Event Sourcing ile Geleneksel Veri Yönetimi Arasındaki Fark

Geleneksel veri yönetimi, genellikle bir veritabanı modeline doğrudan erişim sağlayarak çalışır ve bu model üzerinde yapılan güncellemeleri anında uygular. Bu yaklaşımda, veritabanı tabloları belirli bir anlık durumun yansımasıdır ve her veri güncellemesi, önceki durumun üzerine yazılarak gerçekleştirilir. Bu yöntem veri tutarlılığını sağlamak ve veri işlemlerini basit ve hızlı bir şekilde gerçekleştirmek için yaygın olarak kullanılır. Ancak geçmişe dönük değişikliklerin izlenmesi veya belirli bir zaman dilimindeki verinin yeniden oluşturulması gerektiğinde bazı zorluklar ortaya çıkabilir.

Event sourcing ise tamamen farklı bir yaklaşım sunar. Bu modelde veri yönetimi, gerçekleştirilen her değişikliği bağımsız bir olay (event) olarak kaydeder. Her olay sistemde gerçekleşen bir işlemi veya değişikliği temsil eder ve olaylar kronolojik sırayla kaydedilir. Bu olaylar daha sonra verinin o andaki durumunu yeniden oluşturmak için kullanılabilir. Böylece sistemin belirli bir zamandaki durumunu yeniden oluşturmak sadece ilgili olayları yeniden işlemekle mümkündür. Bu yaklaşım verinin değişim sürecini tam olarak izlemeyi sağlar ve geçmişe dönük analizler yapmak, hata ayıklamak veya belirli bir zamana geri dönmek için büyük avantajlar sunar. Ayrıca event sourcing, mikro hizmet mimarileri ve dağıtık sistemler için de uyumlu bir model olup, ölçeklenebilirlik ve esneklik açısından da önemli faydalar sağlar.

Bu iki yaklaşım arasındaki temel fark, geleneksel veri yönetiminin mevcut durumu korurken, event sourcing’in verinin evrimini ve değişim sürecini korumasıdır. Geleneksel modelde, anlık durumu kaydetmek ön plandayken, event sourcing’de her değişiklik adım adım kaydedilir ve bu sayede verinin tüm geçmişi detaylı bir şekilde izlenebilir.

Golang ve Redis ile Event Sourcing Örneği

Golang ve Redis kullanarak basit bir event sourcing uygulaması yapalım. Bu örnekte bir sipariş yönetim sistemi oluşturacağız. Kullanıcılar sipariş verecek ve bu siparişler olaylar olarak kaydedilecek.

Adım 1: Proje Kurulumu

Öncelikle, gerekli bağımlılıkları yükleyelim:

go mod init event-sourcing-example
go get github.com/go-redis/redis/v8

Adım 2: Redis Bağlantısı

package main

import (
    "context"
    "github.com/go-redis/redis/v8"
    "log"
)

var ctx = context.Background()

func main() {
    rdb := redis.NewClient(&redis.Options{
        Addr: "localhost:6379",
    })

    _, err := rdb.Ping(ctx).Result()
    if err != nil {
        log.Fatalf("Could not connect to Redis: %v", err)
    }

    log.Println("Connected to Redis")
}

Adım 3: Event Yapısı

Olayları temsil eden bir yapı tanımlayalım:

package main

import "time"

type Event struct {
    EventType string
    Data      interface{}
    Timestamp time.Time
}

type OrderCreated struct {
    OrderID string
    UserID  string
    Amount  float64
}

Adım 4: Olay Kaydetme ve Yükleme

Olayları Redis’e kaydedecek ve yükleyecek fonksiyonları yazalım:

package main

import (
    "encoding/json"
    "fmt"
    "github.com/go-redis/redis/v8"
    "log"
    "time"
)

func SaveEvent(rdb *redis.Client, event Event) error {
    key := fmt.Sprintf("events:%s", event.EventType)
    data, err := json.Marshal(event)
    if err != nil {
        return err
    }
    return rdb.RPush(ctx, key, data).Err()
}

func LoadEvents(rdb *redis.Client, eventType string) ([]Event, error) {
    key := fmt.Sprintf("events:%s", eventType)
    data, err := rdb.LRange(ctx, key, 0, -1).Result()
    if err != nil {
        return nil, err
    }

    var events []Event
    for _, d := range data {
        var event Event
        if err := json.Unmarshal([]byte(d), &event); err != nil {
            return nil, err
        }
        events = append(events, event)
    }
    return events, nil
}

Adım 5: Komut ve Projeksiyonlar

Sipariş oluşturma komutunu ve projeksiyonu yazalım:

package main

import (
    "log"
    "time"
)

func CreateOrder(rdb *redis.Client, orderID, userID string, amount float64) error {
    event := Event{
        EventType: "OrderCreated",
        Data: OrderCreated{
            OrderID: orderID,
            UserID:  userID,
            Amount:  amount,
        },
        Timestamp: time.Now(),
    }
    return SaveEvent(rdb, event)
}

func GetOrderSummary(rdb *redis.Client) {
    events, err := LoadEvents(rdb, "OrderCreated")
    if err != nil {
        log.Fatalf("Could not load events: %v", err)
    }

    for _, event := range events {
        order := event.Data.(map[string]interface{})
        log.Printf("Order ID: %s, User ID: %s, Amount: %v", order["OrderID"], order["UserID"], order["Amount"])
    }
}

Adım 6: Uygulamayı Çalıştırma

Son olarak, ana fonksiyonda sipariş oluşturup özetini alalım:

package main

func main() {
    rdb := redis.NewClient(&redis.Options{
        Addr: "localhost:6379",
    })

    _, err := rdb.Ping(ctx).Result()
    if err != nil {
        log.Fatalf("Could not connect to Redis: %v", err)
    }

    CreateOrder(rdb, "1", "user1", 99.99)
    CreateOrder(rdb, "2", "user2", 49.99)

    GetOrderSummary(rdb)
}

Bu kod, Redis’e bağlanarak iki sipariş oluşturur ve ardından bu siparişlerin özetini ekrana yazdırır.

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Order ID: 1, User ID: user1, Amount: 99.99
Order ID: 2, User ID: user2, Amount: 49.99

Event sourcing, veri yönetimi ve sistem tasarımında güçlü bir desendir. Golang ve Redis kullanarak basit bir event sourcing uygulaması oluşturduk. Bu yaklaşımın avantajlarını, olayların nasıl saklandığını ve yüklendiğini gördük. Event sourcing ile ilgili daha ileri konular arasında olay işleme, dağıtık sistemler ve mikro servis mimarileri bulunmaktadır. Bu temel örnek, event sourcing’i anlamanıza ve uygulamanıza yardımcı olacaktır.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Banker Algoritması: Deadlock Önleme Algoritması

Wed, 27 Mar 2024 00:00:00 GMT

Banker Algoritması, işletim sistemlerinde kullanılan ve deadlock (kilitlenme) olasılığını azaltmaya yardımcı olan bir algoritmadır. Deadlock birbirlerine ihtiyaç duyan işlemlerin veya kaynakların birbirini beklemesi sonucunda oluşan ve sistemde ilerleme engelleyen bir durumdur. Banker Algoritması bu tür kilitlenmeleri önlemek için tasarlanmıştır ve özellikle kaynak yönetimi gerektiren sistemlerde kullanılır.

Banker Algoritması bir sistemdeki kaynakları ve bu kaynakların işlemler tarafından talep edilen miktarlarını izler. Herhangi bir zamanda sistemdeki toplam kaynak miktarı bilinir. Algoritma her işlem için talep edilen kaynak miktarını takip eder ve işlemlerin belirli kaynakları ne kadar süreyle veya miktarlarda talep edebileceğini sınırlar. Bu sınırlar sistemdeki mevcut kaynakların talep edilen kaynak miktarını karşılayabilecek durumda olmasını sağlar.

Çalışma Adımları

Banker Algoritması’nın çalışma adımları şu şekildedir:

Başlangıçta sistemdeki toplam kaynak miktarı ve her işlemin talep edebileceği maksimum kaynak miktarı belirlenir.
Bir işlem kaynakları talep etmek için Banker Algoritması’na başvurduğunda, sistemdeki mevcut kaynak miktarıyla işlemin talep ettiği kaynak miktarı karşılaştırılır.
Eğer sistemdeki mevcut kaynaklar, işlemin talep ettiği kaynakları karşılayabiliyorsa, işlem çalıştırılır ve kaynaklar işlem tarafından kullanılır. Aksi takdirde işlem bekleme moduna alınır.
Bir işlem kaynakları serbest bıraktığında, serbest bırakılan kaynaklar diğer işlemlerin kullanımına açılır.
Sistemde herhangi bir zaman işlemler için gerekli minimum kaynak miktarı hesaplanır. Bu hesaplama sonucunda, sistemdeki kaynakların kullanımı optimize edilir ve deadlock riski azaltılır.

Algoritma Karmaşıklığı

Banker Algoritması’nın zaman karmaşıklığı O(n^2) veya daha azdır, burada n sistemdeki işlem sayısını temsil eder.

Kullanım Alanları

Banker Algoritması özellikle çoklu işlemci sistemlerinde ve dağıtık sistemlerde kullanılır. Örneğin çoklu kullanıcılı işletim sistemlerinde, aynı anda birden fazla kullanıcı tarafından kaynak talebinde bulunulabilir. Banker Algoritması, bu talepleri yönetir ve kaynakları etkin bir şekilde dağıtarak sistemdeki performansı optimize eder.

Bir diğer örnek ise veritabanı yönetim sistemleridir. Birden fazla kullanıcı veritabanı kaynaklarına ihtiyaç duyabilir ve bu kaynakların etkin bir şekilde yönetilmesi gerekir. Banker Algoritması, veritabanı sistemlerinde deadlock riskini azaltmak için kullanılabilir.

GoLang’de Banker Algoritması uygulaması:

package main

import "fmt"

// Function to check if the system is in a safe state
func isSafe(processes [][]int, avail []int, need [][]int, finish []bool) bool {
    work := make([]int, len(avail))
    copy(work, avail)

    for count := 0; count < len(processes); count++ {
        found := false
        for p := 0; p < len(processes); p++ {
            if !finish[p] {
                canAllocate := true
                for r := 0; r < len(avail); r++ {
                    if need[p][r] > work[r] {
                        canAllocate = false
                        break
                    }
                }
                if canAllocate {
                    for r := 0; r < len(avail); r++ {
                        work[r] += processes[p][r]
                    }
                    finish[p] = true
                    found = true
                }
            }
        }
        if !found {
            return false
        }
    }
    return true
}

func main() {
    // Example data
    processes := [][]int{{0, 1, 0}, {2, 0, 0}, {3, 0, 2}, {2, 1, 1}, {0, 0, 2}}
    avail := []int{3, 3, 2}
    max := [][]int{{7, 5, 3}, {3, 2, 2}, {9, 0, 2}, {2, 2, 2}, {4, 3, 3}}

    // Calculate need matrix
    need := make([][]int, len(processes))
    for i := range need {
        need[i] = make([]int, len(avail))
        for j := range need[i] {
            need[i][j] = max[i][j] - processes[i][j]
        }
    }

    // Initialize finish array
    finish := make([]bool, len(processes))

    // Check if system is in a safe state
    safe := isSafe(processes, avail, need, finish)

    // Print result
    if safe {
        fmt.Println("Safe state")
    } else {
        fmt.Println("Unsafe state")
    }
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Safe state or Unsafe state

Programın çalışır haline şuradan erişilebilir.

Banker Algoritması deadlock olasılığını azaltmaya yardımcı olan önemli bir algoritmadır. Ancak her zaman işe yarar olmayabilir ve bazı durumlarda sistem performansını etkileyebilir. Bu nedenle kullanılacağı sistem ve koşullar dikkatlice değerlendirilmelidir. Ayrıca algoritmanın karmaşıklığı ve uygulanabilirliği göz önünde bulundurulmalıdır.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Borůvka'nın Algoritması: Minimum Kapsayan Ağaçları Bulmak İçin Etkili Bir Yöntem

Wed, 20 Mar 2024 00:00:00 GMT

Borůvka’nın algoritması, minimum kapsayan ağaçları bulmak için kullanılan etkili bir graf algoritmasıdır. Graf teorisinde önemli bir yere sahip olan bu algoritma, bir graf içindeki en küçük ağırlıklı kenarları seçerek ve bu kenarları birleştirerek minimum kapsayan ağaçları oluşturur. Temel prensibi graf içindeki her bir düğümü kapsayan ağaçlara ayırmak ve ardından bu ağaçları birleştirerek birbirine bağlamaktır.

Algoritmanın işleyişi oldukça basittir ancak etkilidir. İlk adımda, her bir düğüm bir minimum kapsayan ağacın kökü olarak kabul edilir. Daha sonra graf içindeki en düşük ağırlıklı kenarlar seçilir ve bu kenarlar kullanılarak minimum kapsayan ağaçlar oluşturulur. Bu süreç graf içindeki minimum kapsayan ağaç sayısı azaldıkça tekrarlanır.

Borůvka’nın algoritmasının verimliliği grafın büyüklüğüne bağlı olarak değişkenlik gösterebilir. Özellikle büyük ve yoğun graf yapıları için daha hızlı sonuçlar elde edilebilirken, daha küçük ve seyrek graf yapıları için daha uzun sürebilir. Ancak paralel hesaplama olanaklarından faydalanılarak algoritmanın performansı artırılabilir.

Bu algoritmanın avantajlarından biri paralel hesaplama için uygun olmasıdır. Adımların bağımsız olarak yürütülebilmesi, paralel işlemcilerde verimliliği artırabilir. Ayrıca, minimum kapsayan ağaçları bulma problemlerinde geniş bir uygulama alanı bulunmaktadır. İletişim ağlarının oluşturulması, elektrik şebekelerinin planlanması gibi alanlarda minimum kapsayan ağaçlar önemli bir rol oynamaktadır.

Borůvka’nın algoritması, minimum kapsayan ağaçları bulma problemlerinde etkili bir çözüm sunar. Graf teorisindeki önemli bir araç olarak kabul edilir ve çeşitli uygulama alanlarında kullanılmaktadır. Ancak grafın büyüklüğüne ve yapısına bağlı olarak algoritmanın verimliliği değişebilir.

Algoritmanın Çalışma Prensibi

Borůvka’nın algoritması, aşağıdaki adımları takip eder:

Başlangıç Adımı: Köklerin Belirlenmesi
- Algoritma başlangıcında, her düğüm kendine ait bir minimum kapsayan ağacın kökü olarak kabul edilir.
- Grafın her bir düğümü, kendi kendine bir ağacın kökü olarak işaretlenir.
Kenar Seçme Adımı: En Küçük Ağırlıklı Kenarların Belirlenmesi
- Graf içindeki her ağacın kökünden dışa doğru giden kenarlardan en küçük ağırlıklı olanları belirlenir.
- Her ağacın kökünden, o ağaca bağlı olan kenarlardan en küçük ağırlığa sahip olanı seçilir.
Kenarları Birleştirme Adımı: Ağaçların Birleştirilmesi
- Belirlenen en küçük ağırlıklı kenarlar kullanılarak minimum kapsayan ağaçlar birleştirilir.
- Seçilen her kenar, iki farklı ağacı birleştirerek daha büyük bir ağaç oluşturur.
Tekrarlama Adımı: Yeniden Değerlendirme
- Eğer graf içinde birden fazla minimum kapsayan ağaç varsa, bu adımlar tekrarlanır.
- Yeniden değerlendirme adımında, her bir ağaç kökünden en küçük ağırlıklı kenarlar seçilerek ve ağaçlar birleştirilerek işlem devam ettirilir.
Bitiş Adımı: Minimum Kapsayan Ağaçların Oluşumu
- Graf içinde sadece bir minimum kapsayan ağaç kaldığında veya belirlenen bir kriter karşılandığında algoritma sonlanır.
- Algoritma sonucunda, graf içindeki en küçük ağırlıklı kenarlar kullanılarak minimum kapsayan ağaçlar oluşturulur.
- Bu adımlar sonucunda graf içindeki minimum kapsayan ağaçlar tamamlanmış olur.

Algoritma Karmaşıklığı

Borůvka’nın algoritmasının karmaşıklığı, genellikle O(E log V) olarak ifade edilir, burada E, kenar sayısı ve V, düğüm sayısıdır. Ancak, grafın yoğunluğuna ve yapısal özelliklerine bağlı olarak bu karmaşıklık değişebilir.

Önemli Bilgiler

Borůvka’nın algoritması, paralel hesaplama için uygundur çünkü adımlar bağımsız olarak yürütülebilir.
Bu algoritma, ağaç tabanlı ağ yapısı gerektiren problemlerde yaygın olarak kullanılır.
Borůvka’nın algoritması, belirli koşullar altında diğer minimum kapsayan ağaç algoritmalarından daha hızlı olabilir.

Borůvka’nın algoritması, minimum kapsayan ağaçları bulmak için etkili bir yöntem olmasının yanı sıra, graf teorisine olan katkılarıyla da bilinir. Karmaşıklığı ve performans avantajları, çeşitli problemlerde kullanılmasını sağlar.

GoLang’de Borůvka’nın Algoritması uygulaması:

package main

import (
	"fmt"
	"sort"
)

type Edge struct {
	src, dest, weight int
}

type Graph struct {
	V, E int
	edge []Edge
}

func createGraph(V, E int) *Graph {
	graph := &Graph{V: V, E: E}
	graph.edge = make([]Edge, E)
	return graph
}

func find(parent []int, i int) int {
	if parent[i] == -1 {
		return i
	}
	return find(parent, parent[i])
}

func union(parent []int, x, y int) {
	xset := find(parent, x)
	yset := find(parent, y)
	parent[xset] = yset
}

func boruvkaMST(graph *Graph) {
	V, E := graph.V, graph.E
	parent := make([]int, V)
	for i := range parent {
		parent[i] = -1
	}
	cheapest := make([]int, V)
	for i := range cheapest {
		cheapest[i] = -1
	}

	numTrees := V
	minimumCost := 0
	for numTrees > 1 {
		for i := range cheapest {
			cheapest[i] = -1
		}

		for i := 0; i < E; i++ {
			set1 := find(parent, graph.edge[i].src)
			set2 := find(parent, graph.edge[i].dest)

			if set1 != set2 {
				if cheapest[set1] == -1 || graph.edge[cheapest[set1]].weight > graph.edge[i].weight {
					cheapest[set1] = i
				}
				if cheapest[set2] == -1 || graph.edge[cheapest[set2]].weight > graph.edge[i].weight {
					cheapest[set2] = i
				}
			}
		}

		for i := 0; i < V; i++ {
			if cheapest[i] != -1 {
				set1 := find(parent, graph.edge[cheapest[i]].src)
				set2 := find(parent, graph.edge[cheapest[i]].dest)

				if set1 != set2 {
					minimumCost += graph.edge[cheapest[i]].weight
					fmt.Printf("Edge %d-%d included in MST\n", graph.edge[cheapest[i]].src, graph.edge[cheapest[i]].dest)
					union(parent, set1, set2)
					numTrees--
				}
			}
		}
	}
	fmt.Printf("Minimum Cost Spanning Tree: %d\n", minimumCost)
}

func main() {
	V, E := 4, 5
	graph := createGraph(V, E)

	graph.edge[0] = Edge{src: 0, dest: 1, weight: 10}
	graph.edge[1] = Edge{src: 0, dest: 2, weight: 6}
	graph.edge[2] = Edge{src: 0, dest: 3, weight: 5}
	graph.edge[3] = Edge{src: 1, dest: 3, weight: 15}
	graph.edge[4] = Edge{src: 2, dest: 3, weight: 4}

	boruvkaMST(graph)
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Edge 0-3 included in MST
Edge 0-1 included in MST
Edge 2-3 included in MST
Minimum Cost Spanning Tree: 19

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Ford-Fulkerson Algoritması: Maksimum Akış Bulma

Sun, 10 Mar 2024 00:00:00 GMT

Ford-Fulkerson algoritması, ağ teorisinde önemli bir yere sahip olan ve bir ağdaki maksimum akışı belirlemeyi amaçlayan bir graf algoritmasıdır. Akış ağlarındaki bir kaynaktan bir hedefe ulaşan en büyük akışı bulmak için kullanılır. Algoritma bu maksimum akışı bulmak için artan yolları keşfeder ve bu yollar boyunca akışı artırır.

Algoritmanın başlangıç noktası, maksimum akışın sıfır olduğu varsayımıdır. Başlangıçta ağdaki hiçbir akış yoktur ve algoritma bu akışı kademeli olarak artırarak maksimum akışı bulmaya çalışır. Her artış adımında, bir artan yol bulunur ve bu yol boyunca akış artırılır. Bu artan yol, kaynaktan hedefe ulaşan bir yol olup, bu yol boyunca akış artırılabilir. Ford-Fulkerson algoritması, genellikle genişletilmiş Derinlik Öncelikli Arama (DFS) algoritması ile uygulanır. Bu algoritma, ağdaki her bir düğümü ziyaret ederek artan yolları bulur ve akışı artırmak için kullanılır. Algoritmanın karmaşıklığı ağ yapısına ve maksimum akışın boyutuna bağlı olarak değişir. Ancak genellikle zaman karmaşıklığı, ağdaki kenar sayısına ve maksimum akışın büyüklüğüne bağlı olarak ifade edilir.

Nasıl Çalışır?

Başlangıçta maksimum akış sıfır olarak varsayılır.
Artan yollar bulunmaya çalışılır. Artan yol kaynaktan hedefe bir yol olup, bu yol boyunca akış artırılabilir.
Bir artan yol bulunduğunda, bu yol boyunca akış artırılır.
Akış artırılamadığı sürece yani artan yol bulunamadığı durumda, algoritma sona erer.

Çalışma Adımları

Başlangıç Durumu ve Başlangıç Noktası Belirleme:
Ford-Fulkerson algoritması, bir ağdaki maksimum akışı bulmayı amaçlar. Bu süreçte ilk adım, ağın başlangıç durumunu ve başlangıç noktasını belirlemektir. Başlangıç noktası, genellikle ağın kaynağıdır ve akışın başladığı yerdir.
Artan Yolların Bulunması:
Algoritmanın ana işleyişini oluşturan adımlardan biri, artan yolların keşfedilmesidir. Bu adımda, başlangıç noktasından hedef noktaya kadar olan potansiyel artan yollar aranır. Genellikle, genişletilmiş Derinlik Öncelikli Arama (DFS) veya Genişlik Öncelikli Arama (BFS) gibi graf gezme algoritmaları kullanılarak bu artan yollar bulunur.
Artan Yolların Belirlenmesi ve Analizi:
Bulunan artan yollar üzerinde analiz yapılır. Her bir artan yolun kapasitesi belirlenir ve bu kapasiteler arasından en düşük olanı seçilir. Bu, akışın artırılacağı miktarı belirlemek için kullanılır.
Akışın Artırılması:
En zayıf bağlantının kapasitesi kadar akış artırılır. Bu, belirlenen artan yol boyunca akışın güncellenmesi anlamına gelir. Akış, başlangıç noktasından hedef noktaya doğru ilerlerken artırılır.
Yeniden Düzenleme ve Yeniden Değerlendirme:
Akışın artırılmasıyla birlikte, ağdaki kapasiteler güncellenir ve artık kullanılamayan yollar işaretlenir. Bu adımda, akışın güncellenmesi sonucunda ağın yeniden düzenlenmesi ve akışın yeniden değerlendirilmesi gerekebilir.
Tekrarlama ve Sonlandırma:
Artan yolların bulunması, akışın artırılması ve ağın güncellenmesi adımları tekrarlanır. Bu işlem, artık artan yol bulunamadığı ve akış artırılamadığı zaman sona erer. Algoritma, maksimum akış bulunduğunda veya akış artırılamadığında sonlanır.

Algoritma Karmaşıklığı

Ford-Fulkerson algoritmasının karmaşıklığı, genellikle ağ yapısına ve maksimum akış boyutuna bağlıdır. En kötü durumda, zaman karmaşıklığı O(Ef) olabilir. Burada E ağdaki kenar sayısını ve f maksimum akışı temsil eder.

Kullanım Alanları

Ağ akışı yönetimi
Taşıma ve lojistik sistemleri
Telekomünikasyon ağları
Veri iletimi ve ağ optimizasyonu

GoLang’de Ford-Fulkerson Algoritması uygulaması:

package main

import "fmt"

// FordFulkerson is the implementation of Ford-Fulkerson algorithm
func FordFulkerson(graph [][]int, source, sink int) int {
	maxFlow := 0
	parent := make([]int, len(graph))

	for {
		flow := bfs(graph, source, sink, parent)
		if flow == 0 {
			break
		}
		maxFlow += flow

		// Update the residual capacities of the edges and reverse edges along the path
		v := sink
		for v != source {
			u := parent[v]
			graph[u][v] -= flow
			graph[v][u] += flow
			v = u
		}
	}
	return maxFlow
}

// Breadth First Search to find augmenting path
func bfs(graph [][]int, source, sink int, parent []int) int {
	visited := make([]bool, len(graph))
	queue := []int{source}
	visited[source] = true
	parent[source] = -1

	for len(queue) > 0 {
		u := queue[0]
		queue = queue[1:]

		for v, capacity := range graph[u] {
			if !visited[v] && capacity > 0 {
				queue = append(queue, v)
				parent[v] = u
				visited[v] = true
			}
		}
	}
	if visited[sink] {
		pathFlow := 1 << 32
		v := sink
		for v != source {
			u := parent[v]
			pathFlow = min(pathFlow, graph[u][v])
			v = u
		}
		return pathFlow
	}
	return 0
}

// Helper function to find minimum of two integers
func min(a, b int) int {
	if a < b {
		return a
	}
	return b
}

func main() {
	graph := [][]int{
		{0, 16, 13, 0, 0, 0},
		{0, 0, 10, 12, 0, 0},
		{0, 4, 0, 0, 14, 0},
		{0, 0, 9, 0, 0, 20},
		{0, 0, 0, 7, 0, 4},
		{0, 0, 0, 0, 0, 0},
	}

	source, sink := 0, 5
	maxFlow := FordFulkerson(graph, source, sink)
	fmt.Println("Maximum Flow:", maxFlow)
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Maximum Flow: 23

Programın çalışır haline şuradan erişilebilir.

Ford-Fulkerson algoritması, bir ağdaki maksimum akışı bulmak için yaygın olarak kullanılan etkili bir algoritmadır. Graf teorisinde önemli bir yere sahiptir ve birçok farklı alanda uygulanabilir. Bu algoritmanın anlaşılması ve uygulanması, ağ optimizasyonu, taşıma ve lojistik problemleri gibi çeşitli alanlarda önemli katkılar sağlayabilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Elipsoidal Mesafe Algoritması: Hassas Coğrafi Mesafe Hesaplama

Fri, 09 Feb 2024 00:00:00 GMT

Coğrafi mesafe hesaplamaları, dünya yüzeyinin karmaşıklığını ve eğriliğini dikkate alarak noktalar arasındaki mesafeyi doğru bir şekilde hesaplamak için önemlidir. Bu tür hassas hesaplamalar için Lambert’ın ellipsoidal mesafe algoritması sıklıkla tercih edilir. Lambert’ın algoritması, dünya yüzeyinin elipsoidal şeklini hesaba katarak iki nokta arasındaki mesafeyi hesaplar. Bu algoritma coğrafi bilgi sistemleri (GIS), harita projeleri, navigasyon yazılımları ve uzay teknolojileri gibi birçok alanda kullanılır.

Lambert’ın ellipsoidal mesafe algoritması, iki nokta arasındaki mesafeyi ve yönü hesaplamak için matematiksel formüller kullanır. Bu formüller dünya yüzeyinin eğrisini ve elipsoid şeklini dikkate alarak mesafeyi daha doğru bir şekilde hesaplar. Algoritmanın karmaşıklığı genellikle sabittir ve hesaplanan mesafe çeşitli uygulamalarda kullanılabilir. Örneğin, Google Haritalar ve ArcGIS gibi popüler haritalama platformları bu algoritmayı mesafe hesaplamalarında kullanabilir. Ayrıca, gemi ve uçak rotalarının planlanması, arazi haritalama ve jeodezi çalışmaları gibi alanlarda da kullanımı yaygındır.

Çalışma Adımları

Noktaların Koordinatlarının Alınması:
İki noktanın enlem ve boylam koordinatları alınır. Bu koordinatlar genellikle derece cinsinden ifade edilir ve ardından radyan cinsine dönüştürülür.
Meridyen Çemberleri Arası Uzaklığın Hesaplanması:
İki noktanın meridyen çemberleri arasındaki uzaklık hesaplanır. Bu iki noktanın boylam farkının mutlak değerini almakla başlar.
Azimut Açılarının Hesaplanması:
İki noktanın azimut açıları hesaplanır. Bu iki noktanın koordinatlarından türetilir ve genellikle trigonometrik formüller kullanılarak hesaplanır.
Mesafenin Hesaplanması:
Belirli bir elipsoid modeline göre iki nokta arasındaki mesafe hesaplanır. Bu Vincenty formülü gibi karmaşık matematiksel formüller kullanılarak gerçekleştirilir. Bu formüller dünya yüzeyinin eğrisini ve elipsoid şeklini dikkate alarak daha doğru sonuçlar sağlar.
Sonuçların Dönüştürülmesi:
Elde edilen mesafe istenilen formatta sunulmak üzere gerekirse dönüştürülür. Örneğin mesafe metre cinsinden hesaplanmış olabilir ancak kilometre cinsine dönüştürülerek kullanıcıya sunulabilir.

Algoritma Karmaşıklığı

Lambert’ın ellipsoidal mesafe algoritmasının karmaşıklığı genellikle O(1) veya sabittir. Bu algoritmanın girdi boyutundan bağımsız olarak sabit bir zaman alması anlamına gelir. Ancak bazı hesaplama adımları sabit olmayabilir, özellikle noktalar arasındaki azimut açılarının hesaplanması gibi.

Kullanım Alanları

Lambert’ın algoritması coğrafi bilgi sistemleri (GIS), harita projeleri, navigasyon yazılımları ve uzay teknolojileri gibi çeşitli alanlarda kullanılır.

GoLang’de Elipsoidal Mesafe Algoritması uygulaması:

package main

import (
    "fmt"
    "math"
)

const (
    a = 6378137.0      // semi-major axis (in meters)
    f = 1 / 298.257223563 // flattening
    b = a * (1 - f)    // semi-minor axis (in meters)
)

func main() {
    lat1 := 40.7128  // latitude of New York City
    lon1 := -74.0060 // longitude of New York City
    lat2 := 34.0522  // latitude of Los Angeles
    lon2 := -118.2437 // longitude of Los Angeles

    distance := calculateDistance(lat1, lon1, lat2, lon2)
    fmt.Printf("Distance between New York City and Los Angeles: %.2f km\n", distance/1000)
}

func calculateDistance(lat1, lon1, lat2, lon2 float64) float64 {
    phi1 := toRadians(lat1)
    lambda1 := toRadians(lon1)
    phi2 := toRadians(lat2)
    lambda2 := toRadians(lon2)

    deltaLambda := math.Abs(lambda1 - lambda2)
    sigma := math.Atan(math.Sqrt(math.Pow(math.Cos(phi2)*math.Sin(deltaLambda), 2) +
        math.Pow(math.Cos(phi1)*math.Sin(phi2)-math.Sin(phi1)*math.Cos(phi2)*math.Cos(deltaLambda), 2)) /
        (math.Sin(phi1)*math.Sin(phi2) + math.Cos(phi1)*math.Cos(phi2)*math.Cos(deltaLambda)))

    alpha := math.Atan2(math.Cos(phi1)*math.Sin(phi2)-math.Sin(phi1)*math.Cos(phi2)*math.Cos(deltaLambda),
        math.Sin(deltaLambda)*math.Cos(phi2))

    if alpha < 0 {
        alpha += 2 * math.Pi
    }

    u2 := math.Pow(math.Cos(alpha), 2) * ((math.Pow(a, 2) - math.Pow(b, 2)) / math.Pow(b, 2))
    A := 1 + (u2 / 16384) * (4096 + u2 * (-768 + u2 * (320 - 175 * u2)))
    B := (u2 / 1024) * (256 + u2 * (-128 + u2 * (74 - 47 * u2)))
    deltaSigma := B * math.Sin(sigma) * (math.Cos(2 * sigma) + (B / 4) * (math.Cos(sigma) * (-1 + 2 * math.Pow(math.Cos(2 * sigma), 2)) -
        (B / 6) * math.Cos(4 * sigma) * (-3 + 4 * math.Pow(math.Sin(sigma), 2)) * (-3 + 4 * math.Pow(math.Cos(2 * sigma), 2))))

    s := b * A * (sigma - deltaSigma)

    return s
}

func toRadians(degrees float64) float64 {
    return degrees * (math.Pi / 180)
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Distance between New York City and Los Angeles: 3931.50 km

Programın çalışır haline şuradan erişilebilir.

Algoritma, dünya yüzeyinin eğriliğini ve elipsoid şeklini dikkate alarak mesafe hesaplamalarını gerçekleştirir. İki nokta arasındaki mesafeyi hesaplarken Vincenty formülü gibi matematiksel formülleri kullanır. Bu formüller dünya yüzeyinin eğrisini daha doğru bir şekilde hesaplamak için çeşitli trigonometrik ve geometrik hesaplamaları içerir.

Kullanım alanları arasında coğrafi bilgi sistemleri (GIS), harita projeleri, navigasyon yazılımları ve uzay teknolojileri bulunur. Örneğin; gemilerin ve uçakların rotalarını planlarken, arazi haritalama ve jeodezi çalışmalarında bu algoritma kullanılabilir. Ayrıca coğrafi mesafelerin doğru bir şekilde hesaplanması gereken herhangi bir alanda bu algoritma değerlidir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

C4 Modeli ile Yazılım Mimarisi

Tue, 02 Jan 2024 00:00:00 GMT

Yazılım geliştirme sürecinde, bir projenin karmaşıklığını anlamak, tasarım kararlarını iletmek ve ekip içinde etkili iletişimi sağlamak başarılı bir projenin temel unsurlarıdır. Bu noktada yazılım mimarisini anlamak ve görselleştirmek, proje paydaşları arasında ortak bir anlayış oluşturmanın kritik bir adımıdır. C4 Modeli, yazılım mimarisini basitleştirmek ve görselleştirmek için güçlü bir araç olarak ön plana çıkmaktadır.

C4 Modeli Nedir?

C4 Modeli, yazılım mimarisini dört temel düzeyde açıklamak için tasarlanmış bir metodolojidir: Context, Containers, Components, ve Code. Bu düzeyler, yazılım sistemini anlamak ve tasarlamak için farklı perspektifler sunar, böylece proje paydaşları arasında ortak bir dil oluşturulabilir.

Context Düzeyi

Context Düzeyi, yazılım sisteminin dış dünyasıyla olan ilişkilerini ayrıntılı bir şekilde açıklar. Bu düzey projenin genel amaçlarını belirlemeye ve sistemin çevresindeki faktörleri anlamaya odaklanır. Bu aşamada, projenin amaçları ve kapsamı net bir şekilde belirlenir. Yazılım sistemi, hangi sorunları çözmeyi amaçlıyor? Hangi ihtiyaçlara yanıt veriyor? Bu soruların cevapları sistemin geliştirme sürecinde belirleyici olacaktır.

Paydaşlar, Context Düzeyi içinde özel bir öneme sahiptir. Bu, kullanıcılar, müşteriler, projenin finansal destekçileri gibi sistemle etkileşime girecek olan herkesi içerir. Paydaşların beklentileri projenin başarısını büyük ölçüde etkiler, bu nedenle bu aşamada bu beklentilerin anlaşılması ve belgelenmesi kritiktir. Bu düzeyde sistemle etkileşimde bulunan diğer yazılım sistemleri, mevcut regulasyonlar ve dış dünyanın genel yapısı da göz önüne alınır. Bu faktörler sistemin gereksinimlerini ve tasarımını doğrudan etkileyebilir.

Context Düzeyi, yazılım sisteminin genel amacını belirleyerek, dış dünyayla olan ilişkilerini haritalayarak, projenin başlangıcında bir rehber oluşturur. Bu aşama projenin genel hedeflerini netleştirmek ve paydaşların beklentilerini anlamak için hayati bir öneme sahiptir. Başarılı bir mimari tasarım sürecinin temel taşlarından biri olan Context Düzeyi, proje ekibine ortak bir vizyon sağlamak için kullanılır ve projenin geri kalanında takip edilecek olan yolu belirler.

Hedef Kitlesi: Yazılım geliştirme ekibinin içindeki ve dışındaki teknik ve teknik olmayan herkes.

Containers Düzeyi

Containers düzey, projenin teknik yönünü belirlemekte ve sistemin nasıl çalışacağını görsel bir harita üzerinde ortaya koymaktadır. Sunucular, veritabanları, mesaj kuyrukları gibi temel bileşenlerin, yani “konteyner”ların bu düzeyde detaylı bir şekilde tasarlanması, sisteminin temel altyapısını oluşturur.

Containers Düzeyi fiziksel altyapıyı ve sistemde kullanılacak teknolojileri belirleme amacı güder. Hangi sunucuların kullanılacağı, veritabanı yönetim sistemi seçimleri, mesajlaşma protokolleri gibi detaylar bu düzeyde açıklığa kavuşturulur. Bu, proje ekibine, sistemin teknik gereksinimlerini ve çalışma prensiplerini net bir şekilde iletmek için kullanılır. Ayrıca bu düzeyde, projenin dağıtım stratejisi de belirlenir. Sistem bulut tabanlı bir altyapı üzerine mi kurulacak, yoksa yerel sunucular üzerinde mi çalışacak gibi soruların yanıtları Containers Düzeyi içinde şekillenir. Containers Düzeyi aynı zamanda sistemin güvenlik önlemlerini ve performans gereksinimlerini belirlemede de kritik bir rol oynar. Bu düzeyde yapılan kararlar projenin başarı kriterlerini doğrudan etkiler.

Containers Düzeyi, yazılım sisteminin çalışma ortamını belirleyerek, projenin teknik yönünü yönlendirir. Bu aşama sistemin temel altyapısını oluşturmak ve fiziksel dünyadaki kaynakları etkili bir şekilde kullanmak adına kritik bir rol oynar. Projeyi ileriye taşıyan temel kararların alındığı bu düzey, sistemin güçlü ve sağlam bir temel üzerine inşa edilmesini sağlar.

Hedef Kitlesi: Yazılım geliştirme ekibinin içindeki ve dışındaki teknik kişiler; yazılım mimarları, geliştiriciler ve operasyon/destek personeli dahil.

Components Düzeyi

Bu düzey, yazılım sisteminin ana bileşenlerini tanımlar. Modüller, sınıflar, fonksiyonlar gibi temel yapı taşları Components Düzeyi içinde detaylı bir şekilde incelenir. Bu düzey, projenin kod yapısını oluşturan temel bileşenlerin ne olduğunu belirleyerek geliştiricilere rehberlik eder.

Components Düzeyi aynı zamanda farklı bileşenler arasındaki ilişkileri ortaya koymak adına kullanılır. Hangi bileşenlerin birbirleriyle etkileşimde bulunacağı, hangi bileşenlerin diğerlerine bağımlı olduğu gibi konular bu düzeyde belirlenir. Bu, sistemin genel işleyişini anlamak ve tasarlamak açısından önemlidir. Bu düzey aynı zamanda, yazılımın genel tasarım prensiplerini belirlemede de kritik bir rol oynar. Her bir bileşenin sorumlulukları, arayüzleri ve işlevselliği bu aşamada belirlenir. Bu, geliştiricilerin belirlenen tasarım hedeflerine uygun bir şekilde kod yazmalarını sağlar.

Components Düzeyi, yazılımın işlevsel yapısını detaylı bir şekilde inceleyerek sistemin genel işleyişini belirler. Projedeki kod yapısının temelini oluşturan bu düzey, yazılım geliştirme ekibine, sistemdeki temel bileşenleri anlama ve birbirleriyle nasıl etkileşimde bulunduklarını anlama konusunda rehberlik eder.

Hedef Kitlesi: Yazılım mimarları ve geliştiricileri.

Code Düzeyi

Yazılım geliştirme sürecinin en alt düzeyinde yer alan “Code Düzeyi”, yazılım sisteminin gerçek kodunu ve bu kodun nasıl çalıştığını detaylı bir şekilde açıklar. Bu düzey, geliştiricilerin yazılımın iç yapısını anlamalarını sağlar ve projenin başarılı bir şekilde geliştirilmesine rehberlik eder. Bu aşama yazılımın koduna odaklanır ve sistemdeki her bir bileşenin nasıl uygulandığını, hangi programlama dilleri ve tekniklerin kullanıldığını inceler. Geliştiriciler için kritik bir öneme sahip olan Code Düzeyi, kodun doğru bir şekilde yazılması ve sürdürülebilir bir yapı oluşturulması için temel bilgileri sağlar.

Code Düzeyi, sistemin içindeki farklı bileşenler arasındaki etkileşimleri detaylı bir şekilde ortaya koyar. Her bir fonksiyonun, sınıfın veya modülün işlevselliği ve bu işlevselliğin diğer bileşenlerle olan entegrasyonu bu aşamada incelenir. Bu, geliştiricilere sistemin nasıl çalıştığını ve farklı bileşenlerin birbirleriyle nasıl etkileşimde bulunduğunu anlama imkanı tanır. Ayrıca Code Düzeyi, yazılımın performansı, güvenliği ve sürdürülebilirliği gibi konuları da kapsar. Bu düzeyde yapılan kararlar yazılımın güvenilirliğini artırmaya ve gelecekteki değişikliklere uyum sağlamaya yöneliktir.

Sonuç olarak, Code Düzeyi, yazılım sisteminin en derin noktasına inerek kodun iç yapısını açıklar. Bu düzey, geliştiricilere projedeki kodun nasıl yazılması gerektiği, hangi tasarım prensiplerine uyulması gerektiği konusunda rehberlik eder ve yazılımın uzun vadeli başarısını sağlamak adına temel bilgileri sunar.

Hedef Kitlesi: Yazılım mimarları ve geliştiricileri.

C4 Modeli’nin Avantajları

Yazılım geliştirme sürecinde mimari tasarımın etkili bir şekilde yönetilmesi ve paydaşlar arasında ortak bir anlayışın oluşturulması, projenin başarısı için kritik bir faktördür. C4 Modeli, yazılım mimarisini görselleştirmek ve iletişimi güçlendirmek adına kullanılan bir metodoloji olarak ön plana çıkarken bir dizi avantaj sunar.

1. İletişimi Kolaylaştırma

C4 Modeli, farklı paydaşlar arasında ortak bir dil oluşturarak iletişimi kolaylaştırır. Yazılım geliştirme sürecinde yer alan tasarım kararlarını ve mimari kavramları anlamak, proje ekibinin yanı sıra yöneticiler, müşteriler ve diğer paydaşlar arasındaki etkileşimi güçlendirir. Bu sayede proje sürecinde ortaya çıkabilecek anlaşmazlıkların önüne geçilir.

2. Karmaşıklığı Yönetme

C4 Modeli, yazılım sisteminin farklı düzeylerde görselleştirilmesi sayesinde karmaşıklığı yönetilebilir bir seviyeye indirir. Context, Containers, Components, ve Code düzeyleri, sistemi genel bir bakıştan başlayarak giderek daha fazla detay ekleyerek görselleştirme imkanı tanır. Bu da projedeki karmaşıklığı anlamak ve yönetmek adına güçlü bir araç sağlar.

3. Tasarım Kararlarını Belirtme

Her bir düzeyi ile C4 Modeli, tasarım kararlarını belirleme konusunda rehberlik eder. Context düzeyinde genel amaçlar ve ilişkiler belirlenirken, Containers düzeyinde teknoloji seçimleri ve dağıtım stratejileri ele alınır. Components düzeyi, yazılımın işlevsel yapısını belirlerken, Code düzeyi yazılımın gerçek kodunu detaylı bir şekilde açıklar. Bu proje ekibine tutarlı bir tasarım ve geliştirme süreci sağlamak adına önemlidir.

4. Dinamik Değişiklere Uyum Sağlama

C4 Modeli, sistemin evrimi ve değişikliklere uyum sağlama yeteneği konusunda avantaj sağlar. Her bir düzeyde yapılan belirlemeler, projenin gelecekteki değişikliklere rahatça adapte olabilmesini sağlar. Bu da yazılımın sürdürülebilirliğini artırır ve projenin yaşam döngüsü boyunca esnekliği sağlar.

5. Yazılımın Güvenliği ve Performansını Artırma

C4 Modeli, yazılımın güvenliği ve performansını artırmak adına tasarım kararlarını belirleme konusunda etkilidir. Her bir düzeyde yapılan analizler, güvenlik önlemleri, performans gereksinimleri ve sürdürülebilir tasarım prensipleri konusunda rehberlik eder. Bu, yazılımın uzun vadeli başarısını güvence altına alır.

Sonuç

Yazılım geliştirme sürecinde başarılı bir şekilde ilerlemek, etkili bir mimari tasarımın yanı sıra proje paydaşları arasında güçlü bir iletişim ve ortak bir anlayışın oluşturulmasını gerektirir. C4 Modeli, bu ihtiyaçları karşılamak adına sağladığı avantajlarla birlikte, yazılım mimarisini yönetme ve görselleştirme konusunda güçlü bir araç olarak öne çıkıyor.

Bu metodolojinin sunduğu avantajlar, projenin başarısına önemli katkılarda bulunur. İletişimi kolaylaştırma özelliği, farklı paydaşlar arasında ortak bir dil oluşturarak proje ekibinin tutarlı bir vizyon etrafında birleşmesini sağlar. Bu da projede koordinasyonu ve işbirliğini artırır.

C4 Modeli’nin karmaşıklığı yönetme yeteneği, yazılım sisteminin farklı düzeylerde görselleştirilmesi sayesinde mümkün olur. Context, Containers, Components ve Code düzeyleri, sistemi genel bir bakıştan başlayarak giderek daha fazla detay ekleyerek anlamamıza imkan tanır. Bu da projenin karmaşık yapılarını anlamak ve yönetmek açısından güçlü bir temel oluşturur.

Tasarım kararlarını belirleme konusundaki etkisi, her bir düzeyin belirli bir yönüyle ilgilenmesi ve bu sayede sistemin genel tasarımının tutarlılığını sağlamasıdır. Her bir düzeyde belirlenen prensipler, sistemin işlevselliği, güvenliği ve performansı üzerinde doğrudan bir etkiye sahiptir. Bu da yazılımın uzun vadeli başarısını güvence altına alır.

C4 Modeli’nin dinamik değişikliklere uyum sağlama yeteneği, projenin evrimi ve değişen ihtiyaçlara hızlı bir şekilde adapte olabilme esnekliği sağlar. Her bir düzeyde yapılan belirlemeler projenin gelecekteki değişikliklere rahatça uyum sağlamasını mümkün kılar.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Aho-Corasick Algoritması: Çoklu Anahtar Kelime Arama Tekniği

Mon, 11 Sep 2023 00:00:00 GMT

Metin işleme ve metin madenciliği disiplinlerinde, belirli anahtar kelimeleri metin içinde hızlı ve etkili bir biçimde tespit etme gerekliliği sıklıkla karşılaşılan bir zorunluluktur. Bu bağlamda, Aho-Corasick algoritması, bu tür metin işleme görevleri için geliştirilmiş güçlü bir algoritma olarak öne çıkar.

Metin madenciliği, metin içeriğinin detaylı bir analizini yapmayı ve özellikle büyük metin koleksiyonlarında belirli örüntüleri, kelimeleri veya terimleri tespit etmeyi amaçlayan bir veri madenciliği disiplinidir. Bu bağlamda, büyük metin kümesi üzerinde belirli anahtar kelimeleri tespit etmek, metin madenciliği uygulamalarının önemli bir bileşenidir. Bu tür görevler için, Aho-Corasick algoritması metin içerisinde aynı anda birden fazla anahtar kelimeyi arayıp bulma işleminde etkili bir yaklaşım sunmaktadır.

Trie Veri Yapısı

Aho-Corasick algoritmasının temel yapısı Trie (ağaç) veri yapısına dayanmaktadır. Trie, metin işleme alanında etkili bir biçimde kullanılan bir veri yapısıdır. Kelimeleri veya karakter dizilerini temsil etmek için tasarlanmış olan Trie, metin içinde bu kelimeleri hızlı bir şekilde tespit etme amacıyla kullanılır. Trie yapısındaki her bir düğüm, bir karakteri veya kelimenin bir parçasını sembolize eder ve bir kelimenin sonunu işaretler. Bu özelliği sayesinde, Trie yapısı metin içindeki kelimeleri hiyerarşik bir şekilde organize eder ve arama işlemini optimize eder.

Aho-Corasick Algoritması Nasıl Çalışır?

Aho-Corasick algoritması, metin içindeki anahtar kelimeleri bulma görevini gerçekleştirirken Trie veri yapısını kullanır. Bu algoritma, anahtar kelimelerin Trie’deki yollarını oluşturur ve bu yolları gezerek metin içindeki anahtar kelimeleri bulur. Ayrıca, başarısız geçişleri (fail transitions) hesaplayarak arama süresini optimize eder.

1. Trie Yapısının Oluşturulması

İlk adım, metin içinde aranacak anahtar kelimelerin Trie veri yapısına eklenmesidir. Her bir anahtar kelime, Trie’deki bir yol olarak temsil edilir. Örnek bir Trie yapısı oluşturmak için şu adımları takip ederiz:

Trie veri yapısının kök düğümünü oluştur.
Anahtar kelimeleri sırayla Trie’ye eklerken her karakter için bir düğüm oluştururuz ve bu düğümü Trie’deki ilgili düğüme bağlarız.

2. Başarısız Geçişlerin Hesaplanması

Başarısız geçişler (fail transitions), metin içinde aranacak anahtar kelimelerin Trie yapısında hızlı bir şekilde gezilmesini sağlar. Her düğümün bir “fail_state” (başarısız geçiş) bağlantısı vardır ve bu bağlantılar Trie’deki başarısız geçişleri yönlendirir. Başarısız geçişler hesaplanırken şu adımlar takip edilir:

Kök düğümünün tüm çocukları için fail_state bağlantıları başlangıçta kök düğüme yönlendirilir.
BFS (breadth-first search) algoritması kullanılarak Trie yapısı üzerinde gezilir ve her düğüm için fail_state bağlantıları hesaplanır. Bu bağlantılar, başarısız geçişlerin doğru bir şekilde yönlendirilmesini sağlar.

3. Metin İçinde Anahtar Kelimelerin Aranması

Metin içinde anahtar kelimeleri aramak için Trie yapısını kullanırız. Metin üzerinde gezinirken her karakter için şu adımları izleriz:

Mevcut durumu (state) Trie yapısındaki kök düğüm olarak başlatırız.
Mevcut karakteri alırız ve bu karakteri Trie’de bir sonraki durumu (state) bulmak için kullanırız.
Eğer bir sonraki durum (state) yoksa veya anahtar kelimenin sonu değilse, fail_state bağlantılarını takip ederiz.
Anahtar kelimenin sonu bulunursa, bu kelimenin pozisyonunu kaydederiz.

Aşağıda, Aho-Corasick algoritmasının basit bir pseudocode örneği verilmiştir:

function AhoCorasick(text, keywords):
    create Trie from keywords
    set fail transitions in Trie
    result = empty dictionary
    
    state = root of Trie
    for i = 0 to len(text) - 1:
        while state is not found in Trie and state is not root:
            state = state.fail_state
        
        state = find_next_state(state, text[i])
        
        if state is None:
            state = root of Trie
        
        for output in state.outputs:
            if output not in result:
                result[output] = empty list
            result[output].append(i - len(output) + 1)
    
    return result

Bu pseudocode, Aho-Corasick algoritmasının ana mantığını ve işleyişini göstermektedir. Algoritma, metin içindeki anahtar kelimeleri hızlı bir şekilde bulmak için Trie yapısını kullanır ve başarısız geçişlerin hesaplanmasıyla performansını optimize eder.

GoLang’de Aho-Corasick uygulaması:

package main

import (
	"fmt"
)

type TrieNode struct {
	children    map[rune]*TrieNode
	fail        *TrieNode
	isEndOfWord bool
	keyword     string
}

type AhoCorasick struct {
	root *TrieNode
}

func newTrieNode() *TrieNode {
	return &TrieNode{
		children: make(map[rune]*TrieNode),
		fail:     nil,
	}
}

func NewAhoCorasick(keywords []string) *AhoCorasick {
	root := newTrieNode()
	ac := &AhoCorasick{root: root}

	for _, keyword := range keywords {
		ac.insert(keyword)
	}

	ac.setFailTransitions()

	return ac
}

func (ac *AhoCorasick) insert(keyword string) {
	node := ac.root
	for _, char := range keyword {
		if _, found := node.children[char]; !found {
			node.children[char] = newTrieNode()
		}
		node = node.children[char]
	}
	node.isEndOfWord = true
	node.keyword = keyword
}

func (ac *AhoCorasick) setFailTransitions() {
	queue := make([]*TrieNode, 0)
	root := ac.root

	for _, child := range root.children {
		child.fail = root
		queue = append(queue, child)
	}

	for len(queue) > 0 {
		node := queue[0]
		queue = queue[1:]

		for char, child := range node.children {
			failNode := node.fail

			for failNode != root && failNode.children[char] == nil {
				failNode = failNode.fail
			}

			if nextNode, found := failNode.children[char]; found {
				child.fail = nextNode
			} else {
				child.fail = root
			}

			queue = append(queue, child)
		}
	}
}

func (ac *AhoCorasick) Search(text string) map[string][]int {
	result := make(map[string][]int)
	node := ac.root

	for i, char := range text {
		for node != ac.root && node.children[char] == nil {
			node = node.fail
		}

		if nextNode, found := node.children[char]; found {
			node = nextNode
		} else {
			node = ac.root
		}

		if node.isEndOfWord {
			if _, exists := result[node.keyword]; !exists {
				result[node.keyword] = []int{}
			}
			result[node.keyword] = append(result[node.keyword], i-len(node.keyword)+1)
		}
	}

	return result
}

func main() {
	keywords := []string{"what", "hat", "ver", "er"}
	text := "whatever, err ... , wherever"

	ac := NewAhoCorasick(keywords)
	results := ac.Search(text)

	fmt.Println(results)
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

map[er:[10 22] ver:[5 25] what:[0]]

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Levenshtein Mesafesi Nedir, Nasıl Hesaplanır?

Sat, 02 Sep 2023 00:00:00 GMT

Levenshtein Mesafesi, metin veya dizgeler arasındaki benzerliği veya farklılığı ölçmenin temel bir yöntemidir ve genellikle bilgisayar bilimleri, doğal dil işleme ve genetik analiz gibi birçok farklı alanın yanı sıra günlük hayatta da yaygın olarak kullanılır. Bu metrik, iki dizge arasındaki karakterlerin kaç kez değiştirilmesi, eklenmesi veya çıkarılması gerektiğini belirleyerek bu dizgelerin ne kadar benzer veya farklı olduğunu nicel olarak ifade eder. Bu nedenle Levenshtein Mesafesi, veri madenciliği, otomatik düzeltme sistemleri, yazılı metin karşılaştırmaları ve hatta genetik dizilim analizinde önemli bir rol oynamaktadır. İlerleyen bölümlerde, Levenshtein Mesafesi’nin nasıl hesaplandığını ayrıntılı bir şekilde inceleyeceğiz ve bu metriği anlamanıza yardımcı olacak örnekler sunacağız.

Levenshtein Mesafesi Nedir?

Levenshtein Mesafesi, metin veya dizgeler arasındaki benzerlik veya farklılık ölçümünü belirlemek amacıyla kullanılan bir metrik veya algoritmadır. Bu metrik, iki dizge arasındaki karakterlerin nasıl değiştirildiğini, eklenip çıkarıldığını belirleyerek bu iki dizgenin birbirine ne kadar benzediğini nicel olarak ifade eder. İki dizge arasındaki farkın veya benzerliğin ölçülmesinde oldukça kullanışlıdır ve birçok uygulama alanında kendini gösterir.

Levenshtein Mesafesi, ilk olarak 1965 yılında Sovyet bilgisayar bilimcisi Vladimir Levenshtein tarafından tanıtılmıştır. Bu nedenle bu metrik, onun adını taşır. Levenshtein, bu metriği yazım hatalarını düzeltme işlemlerini analiz etmek amacıyla geliştirdi, ancak daha sonra birçok farklı alanda kullanım potansiyeli keşfedildi.

Bu mesafe hesaplanırken, iki dizge arasındaki karakter diziliminin nasıl değiştirildiğini, eklendiğini veya çıkarıldığını gözlemlemek esastır. Her bir karakter dizgesi birbirine dönüştürülmeye çalışıldığında ne kadar çok düzenleme işlemi gerekiyorsa, Levenshtein Mesafesi de o kadar büyük olur. Yani, iki dizge arasındaki mesafe, bu düzenleme işlemlerinin sayısını temsil eder.

Levenshtein Mesafesi’nin temel amacı, iki dizge arasındaki farklılığı nicel olarak ifade ederek metin benzerliği analizi, yazım denetimi, veri eşleme, genetik dizilim karşılaştırmaları ve daha birçok alanda kullanım olanağı sunmaktır. Özellikle doğal dil işleme uygulamalarında ve veri analizi projelerinde sıkça kullanılır. Bu algoritma, metin madenciliği ve veri işleme alanlarında önemli bir araçtır ve çok sayıda kullanım senaryosu sunar. İlerleyen bölümlerde, Levenshtein Mesafesi’nin nasıl hesaplandığını ve uygulama örneklerini daha ayrıntılı bir şekilde inceleyeceğiz.

Levenshtein Mesafesi Nasıl Hesaplanır?

Levenshtein Mesafesi, dinamik programlama yöntemiyle hesaplanır. Temel fikir, iki dizgeyi karşılaştırarak ve her bir karakterin eşleşme durumunu izleyerek bir matris oluşturmaktır.

Hesaplama adımları şunlardır:

Adım 1: İlk Matrisi Oluşturma

İlk olarak, iki dizgeyi karşılaştırmak için bir matris oluşturuyoruz. Matrisin satırları birinci dizgeyi, sütunları ise ikinci dizgeyi temsil eder. Matrisin boyutları, her iki dizgenin uzunluğuna göre belirlenir. Matrisin ilk satırı ve ilk sütunu sıfır değerleri ile başlar. Bu matris, Levenshtein Mesafesi hesaplamasının temelini oluşturur.

Örnek:

  |   | M | I | N | E
-----------------------
  | 0 | 1 | 2 | 3 | 4
-----------------------
H | 1 |   |   |   |  
-----------------------
O | 2 |   |   |   |  
-----------------------
U | 3 |   |   |   |  
-----------------------
S | 4 |   |   |   |

Adım 2: Matrisi Doldurma

Matrisin oluşturulmasının ardından, her bir hücrenin değerini hesaplamaya başlarız. Her hücre, iki karşılaştırılan karakterin eşleşme durumuna göre değer alır. İki karakter aynı ise, o hücrenin değeri sol üst köşedeki hücrenin değeridir. Eğer karakterler eşleşmiyorsa, o hücrenin değeri sol, üst ve sol üst köşedeki hücrelerin en küçüğüne bir eklemesi yapılmasıyla belirlenir.

Matematiksel olarak, iki karakter arasındaki mesafe (D) şu şekilde hesaplanır:

D(i, j) = 0, eğer string1[i] = string2[j]
D(i, j) = min(D(i-1, j), D(i, j-1), D(i-1, j-1)) + 1, eğer string1[i] ≠ string2[j]

Burada, i ve j, iki dizgeyi karşılaştırmada kullanılan indeksleri temsil eder.

Örnek:

  |   | M | I | N | E
-----------------------
  | 0 | 1 | 2 | 3 | 4
-----------------------
H | 1 | 1 | 2 | 3 | 4
-----------------------
O | 2 | 2 | 2 | 3 | 4
-----------------------
U | 3 | 3 | 3 | 3 | 4
-----------------------
S | 4 | 4 | 4 | 4 | 4

Adım 3: Levenshtein Mesafesini Bulma

Matrisin sağ alt köşesindeki değer, Levenshtein Mesafesi’ni temsil eder. Bu değer, iki dizge arasındaki minimum düzenleme işlemi sayısını ifade eder. İki dizge arasındaki benzerlik veya farklılığı ölçmek istediğinizde, bu değeri kullanabilirsiniz.

Matematiksel olarak, Levenshtein Mesafesi (L) şu şekilde hesaplanır:

L = D(m, n)

Burada, m ve n, sırasıyla birinci ve ikinci dizgenin uzunluğunu temsil eder.r

Örnek:

Levenshtein Mesafesi = 4

Levenshtein Mesafesi’nin hesaplanma süreci bu adımları izler ve sonuç olarak iki dizge arasındaki benzerlik veya farklılığı nicel olarak ifade eder.

Levenshtein Mesafesi hesaplama işlemi, karakter dizgelerini karşılaştırmanın ve düzenleme işlemlerini belirlemenin güçlü bir yolunu sunar. Bu nedenle yazım denetimi, metin benzerliği analizi, veri eşleme ve genetik dizilim karşılaştırmaları gibi birçok farklı uygulama alanında yaygın olarak kullanılır.

GoLang’de Levenshtein Mesafesi uygulaması:

package main

import (
	"fmt"
)

func Min(a, b, c int) int {
	if a <= b && a <= c {
		return a
	} else if b <= a && b <= c {
		return b
	} else {
		return c
	}
}

func LevenshteinDistance(str1, str2 string) int {
	m := len(str1)
	n := len(str2)

	matrix := make([][]int, m+1)
	for i := range matrix {
		matrix[i] = make([]int, n+1)
	}

	for i := 0; i <= m; i++ {
		matrix[i][0] = i
	}
	for j := 0; j <= n; j++ {
		matrix[0][j] = j
	}

	for i := 1; i <= m; i++ {
		for j := 1; j <= n; j++ {
			cost := 0
			if str1[i-1] != str2[j-1] {
				cost = 1
			}
			matrix[i][j] = Min(
				matrix[i-1][j]+1,
				matrix[i][j-1]+1,
				matrix[i-1][j-1]+cost,
			)
		}
	}

	return matrix[m][n]
}

func main() {
	str1 := "hors"
	str2 := "rose"

	distance := LevenshteinDistance(str1, str2)

	fmt.Printf("Levenshtein Distance between '%s' and '%s': %d\n", str1, str2, distance)
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Levenshtein Distance between 'hors' and 'rose': 3

Çıktı, “hors” ve “rose” dizgeleri arasındaki Levenshtein Mesafesi’ni (Levenshtein Distance) gösterir ve sonucun 2 olduğunu belirtir. Bu, iki dizge arasında en az 2 düzenleme işlemi gerektiği anlamına gelir.

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Yazılım Entropisi: Karmaşıklığın ve Bozulmanın Birleşimi

Thu, 17 Aug 2023 00:00:00 GMT

Yazılım geliştirme, günümüzün hızla dijitalleşen dünyasında kritik bir öneme sahiptir. Ancak yazılım projelerinin yaşam döngüsü boyunca karşılaştığı zorluklar ve sorunlar, yazılımın zaman içinde nasıl bozulabileceğini ve karmaşıklığın nasıl artabileceğini göstermektedir. Yazılım entropisi, yazılımın karmaşıklığının ve bozulmasının artışına işaret eden bir terimdir. Bu kavramın arkasındaki temel prensipleri ve etkileri irdeleyerek, yazılım projelerinin neden zamanla karmaşıklık ve bozulma eğiliminde olduğunu anlamaya çalışacağız.

Yazılım Entropisinin Tanımı

Yazılım entropisi kavramı, termodinamikten türetilmiş bir terim olarak, yazılım geliştirme süreçlerinde meydana gelen düzensizlik, karmaşıklık ve bozulma eğilimini ifade eder. Termodinamikte entropi, bir sistemin düzensizlik derecesini ve enerjinin dağılımını ölçen bir terimdir. Sistem ne kadar düzenli ve düşük enerjili ise entropi düşüktür ancak düzensizlik ve enerji dağılımı arttıkça entropi yükselir. Yazılım entropisi bu termodinamik prensipleriyle paralellik gösterir. Yazılımın başlangıçta belirlenen tasarımlar ve hedeflere uygun olarak oluşturulsa da, zaman içinde çeşitli faktörler nedeniyle karmaşıklığı artar ve bozulma eğilimi gösterir.

Termodinamikte entropi, bir sistemin düzensizlik seviyesini belirlerken; yazılım entropisi, yazılım projelerinin zaman içinde karmaşıklığının ve bozulmasının artma eğilimini tanımlar. Yazılım projeleri, genellikle belirli bir amacı veya işlevi yerine getirmek için kodlanır. Ancak bu süreç boyunca değişen gereksinimler, eklenen yeni özellikler, bakım eksiklikleri ve teknik borç gibi etkenler, yazılımın karmaşıklığını artırabilir. İşte termodinamik entropisinin yazılım entropisiyle olan ilişkisi burada devreye girer. Termodinamik entropi, düzensizlik ve enerji dağılımının artışını ifade ederken, yazılım entropisi de yazılımın zaman içinde düzensizleşmesi, karmaşıklığının ve hatalarının artması olarak görülebilir.

Bu bağlamda, termodinamik entropi ile yazılım entropisi arasındaki ilişki, karmaşıklık ve düzensizliğin artması sonucu sistemlerin daha düşük verimlilik, güvenilmezlik ve bozulma eğilimi gösterme eğilimini içerir. Yazılım projeleri de başlangıçta iyi tasarlanmış olsa da, değişen gereksinimler ve sürekli gelişen doğası nedeniyle zamanla düzensizleşebilir, bakım eksiklikleri ve teknik borçlar birikerek entropiyi artırabilir.

Yazılım Entropisinin Nedenleri

Değişen Gereksinimler: Yazılım projeleri genellikle kullanıcı gereksinimlerine cevap vermek için başlar. Ancak, gereksinimler zaman içinde değişebilir ve bu değişiklikler yazılımın tasarımını ve kodunu etkileyebilir. Yeni özellikler eklemek veya mevcut olanları değiştirmek karmaşıklığı artırabilir.
Teknik Borç: Proje hızını artırmak veya kısa vadeli çözümler bulmak amacıyla alınan teknik kısayollar, ileride daha fazla karmaşıklık yaratabilir. Bu tür teknik borçlar zamanla ödenmediğinde, yazılımın genel kalitesi düşebilir.
Dokümantasyon Eksikliği: İyi bir dokümantasyon olmadan, yeni geliştiricilerin projeye katılması veya mevcut kodun anlaşılması zorlaşabilir. Bu da yanlış anlamalara ve hatalı değişikliklere yol açabilir.
Ekip Değişiklikleri: Yazılım projelerinde ekip üyelerinin değişmesi kaçınılmazdır. Ancak, yeni geliştiricilerin mevcut kodu anlaması zaman alabilir ve hatalara yol açabilir.

Yazılım Entropisinin Sonuçları

Yazılım entropisi, yazılım projelerinin zaman içinde karmaşıklığının ve bozulmasının artması sonucu ortaya çıkar. Bu artışın projeye olan etkileri oldukça çeşitli ve genellikle olumsuz yönde olabilir. Aşağıda, yazılım entropisinin ortaya çıkardığı bazı önemli sonuçları bulabiliriz:

Bakım Güçlüğü: Yazılım projeleri karmaşıklaştıkça ve bozulma eğilimi gösterdikçe, projenin bakımı daha zor hale gelir. Hataların tespiti ve düzeltilmesi uzun sürebilir çünkü artan karmaşıklık, sorunların kaynağını bulmayı güçleştirebilir.
Esneklik Azalması: Yazılım projelerinin karmaşıklığı arttıkça, yeni özellikler eklemek veya mevcut olanları değiştirmek daha zor olabilir. Bu, projenin esnekliğini azaltır ve rekabetçi bir ortamda gelişime engel olabilir.
Güvenilirlik Azalması: Karmaşık ve bozulmuş bir yazılım projesi, hataların ve hatalı davranışların daha sık görülmesine neden olabilir. Bu, kullanıcıların güvenini zedeler ve ürünün veya hizmetin itibarını olumsuz etkiler.
Performans Düşüşü: Yazılım entropisi, gereksiz kod parçalarının birikmesi, düzensiz yapılar ve yavaş işleyen algoritmalar gibi etkenlerle performans düşüşüne yol açabilir. Bu da yazılımın genel performansını olumsuz etkiler.
Büyüme Engellemesi: Yazılım projelerinde artan karmaşıklık ve bozulma, projenin büyümesini sınırlayabilir. Yeni özellikler eklemek veya daha fazla kullanıcıya hizmet vermek istendiğinde, mevcut yapının sınırlamaları nedeniyle zorluklar ortaya çıkabilir.
Maliyet Artışı: Yazılım entropisi, bakım süreçlerinin zorlaşması, hataların daha fazla düzeltilmesi ve performans sorunlarının giderilmesi gibi faktörler nedeniyle maliyetleri artırabilir. Gereksiz zaman ve kaynak harcamalarıyla sonuçlanabilir.

Challenger Faciası ve Yazılım Entropisi

Challenger faciası, 28 Ocak 1986 tarihinde gerçekleşen ve Uzay Mekiği Challenger’ın fırlatılması sırasında yaşanan trajik bir olaydır. Bu facia, Uzay Mekiği’nin patlaması sonucu 7 astronotun hayatını kaybetmesine yol açtı. Bu trajedi, bir dizi mühendislik, yönetim ve iletişim hatasının sonucuydu. Challenger faciasının ardında yatan nedenler ve yazılım entropisi arasında birçok benzerlik ve paralellik bulunmaktadır.

Challenger faciasında, mühendislik hataları, iletişim eksikliği ve hızlı gelişim baskısı nedeniyle trajik bir olay yaşanmıştır. Bu olayda, önceden belirlenmiş tasarımlar ve riskler göz ardı edilerek uzun vadeli sürdürülebilirlik yerine kısa vadeli hedeflere odaklanılmıştır. Yazılım entropisi de benzer şekilde, yazılım projelerinin zaman içinde karmaşıklığının ve hatalarının artmasına neden olan faktörlerle ortaya çıkar. Değişen gereksinimler, teknik borç, iletişim eksikliği ve hızlı gelişim baskısı gibi etkenler yazılımın karmaşıklığını artırabilir. Her iki durumda da düzenli bakım, iyi iletişim, etkili dokümantasyon ve teknik borç yönetimi gibi stratejiler, olumsuz sonuçları minimize etmek ve projenin sürdürülebilirliğini sağlamak açısından önemlidir.

Yazılım Entropisini Yönetme Yolları

Yazılım entropisinin olumsuz etkilerini minimize etmek ve yazılım projelerini sürdürülebilir kılmak için bazı yönetim stratejileri benimsenmelidir:

Sürekli Bakım ve Temizlik: Yazılımın düzenli bakımı ve gereksiz kod parçalarının temizlenmesi, entropiyi azaltabilir. Teknik borçların ödenmesi, kodun güncel ve anlaşılır kalmasına yardımcı olur.
Tasarım İyi Uygulamaları: Başlangıçta iyi bir tasarım yapmak, ileride karmaşıklığı azaltabilir. Modüler bir yaklaşım benimsemek ve kodun ayrı işlevlere bölünmesi, entropiyi kontrol altında tutabilir.
Dokümantasyon ve İletişim: İyi bir dokümantasyon ve iletişim, projeye yeni katılan geliştiricilerin işleri hızla anlamasına yardımcı olur. Bu, hataların azaltılmasına ve yazılımın sürdürülebilirliğine katkı sağlar.
Otomatik Testler ve Sürekli Entegrasyon: Otomatik testlerin kullanılması, hataların daha hızlı tespit edilmesini sağlar. Sürekli entegrasyon, yazılımın sürekli olarak test edilip entegre edilmesini kolaylaştırarak kaliteyi artırabilir.
Teknik Borç Yönetimi: Teknik borçların sürekli takip edilmesi ve ödenmesi, entropiyi azaltır. Kısa vadeli kazanımlar yerine uzun vadeli sürdürülebilirlik gözetilmelidir.

Yazılım entropisi, yazılım projelerinin karmaşıklığının ve bozulmasının artmasına işaret eder. Bu artışın sonuçları, bakım güçlüğü, esneklik azalması, güvenilirlik kaybı, performans düşüşü, büyüme engellemesi ve maliyet artışı gibi olumsuz etkilerle kendini gösterebilir. Ancak, sürekli bakım, iyi tasarım uygulamaları, etkili dokümantasyon, otomatik testler ve teknik borç yönetimi gibi stratejiler benimsenerek entropi kontrol altına alınabilir ve yazılım projelerinin sürdürülebilirliği sağlanabilir. Bu nedenle, yazılım geliştiricilerinin entropiye karşı bilinçli ve sürekli bir çaba içinde olmaları önemlidir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Bellman–Ford Algoritması

Sat, 12 Aug 2023 00:00:00 GMT

Bellman-Ford algoritması, ağırlıklı (weighted) graf içindeki en kısa yol problemini çözmek için kullanılan bir algoritmadır. En kısa yol problemi, bir başlangıç noktasından hedef noktaya en kısa yolun bulunması problemidir. Bellman-Ford algoritması, olası tüm yol kombinasyonlarını inceleyerek en kısa yolu bulur. Bu algoritma negatif ağırlıklı kenarlara sahip graf gibi durumları da ele alabilir, bu nedenle Dijkstra algoritmasından farklı olarak daha genel bir kullanıma sahiptir.

Bellman-Ford algoritmasının çalışma prensibi şu şekildedir:

Başlangıç noktasına uzaklıkları sonsuz, kendisine olan uzaklığı ise 0 olarak ayarla.
Tüm kenarları ve ağırlıkları gözden geçir ve her bir kenar için başlangıç noktasından gidilen bir yolun, hedef noktaya olan uzaklığını güncelle.
Bu işlemi toplam düğüm sayısı - 1 defa tekrarla. N defa yapılmasının sebebi, en kısa yolun en fazla N-1 kenardan geçebileceği gerçeğidir. N defadan sonra hala daha kısa yollar güncellenebiliyorsa, bu grafın negatif ağırlıklı döngüye sahip olduğunu gösterir.

Dijkstra algoritması, pozitif ağırlıklı graf veya kenarlarda en kısa yolu bulmak için hızlı bir şekilde çalışan bir algoritmadır. Her adımda en küçük uzaklığa sahip düğüm seçilerek işlem yapar. Diğer yandan, Bellman-Ford algoritması negatif veya pozitif ağırlıklı graf ve kenarlarda kullanılabilir ve daha genel bir kullanıma sahiptir. Tüm kenarları ve ağırlıkları adım adım gözden geçirerek en kısa yolu bulur, ancak her adımda tüm kenarları incelediği için daha fazla zaman gerektirebilir. Bu nedenle Dijkstra genellikle daha hızlı çalışırken, Bellman-Ford algoritması daha geniş bir problem yelpazesini ele alabilir ve negatif ağırlıklı graf veya kenarları da işleyebilir.

Karmaşıklık

Worst-case performance O(|V||E|)
Best-case performance O(|E|)
Worst-case space complexity O(|V|)

GoLang’de Bellman–Ford Algoritması uygulaması:

package main

import (
	"fmt"
	"math"
)

type Edge struct {
	Source int
	Target int
	Weight int
}

func BellmanFord(edges []Edge, vertexCount int, start int) ([]int, []int) {
	distances := make([]int, vertexCount)
	predecessors := make([]int, vertexCount)

	for i := range distances {
		distances[i] = math.MaxInt32
	}
	distances[start] = 0

	for i := 1; i < vertexCount; i++ {
		for _, edge := range edges {
			if distances[edge.Source]+edge.Weight < distances[edge.Target] {
				distances[edge.Target] = distances[edge.Source] + edge.Weight
				predecessors[edge.Target] = edge.Source
			}
		}
	}

	for _, edge := range edges {
		if distances[edge.Source]+edge.Weight < distances[edge.Target] {
			fmt.Println("Negative cycle detected. Bellman-Ford algorithm cannot be applied.")
			return nil, nil
		}
	}

	return distances, predecessors
}

func main() {
	vertexCount := 5
	edges := []Edge{
		{0, 1, 2},
		{0, 2, 4},
		{1, 2, 1},
		{1, 3, 7},
		{2, 4, 3},
		{3, 4, 1},
	}

	startNode := 0
	distances, predecessors := BellmanFord(edges, vertexCount, startNode)

	if distances != nil {
		fmt.Println("Shortest distances from node", startNode)
		for i, distance := range distances {
			fmt.Printf("Node %d: Distance %d, Path: ", i, distance)
			path := []int{}
			for at := i; at != startNode; at = predecessors[at] {
				path = append([]int{at}, path...)
			}
			path = append([]int{startNode}, path...)
			fmt.Println(path)
		}
	}
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Shortest distances from node 0
Node 0: Distance 0, Path: [0]
Node 1: Distance 2, Path: [0 1]
Node 2: Distance 3, Path: [0 1 2]
Node 3: Distance 9, Path: [0 1 2 4 3]
Node 4: Distance 6, Path: [0 1 2 4]

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Bogo Sort - Saçma Sıralama

Fri, 28 Jul 2023 00:00:00 GMT

Bogo Sort (Saçma sıralam veya Permutation Sort olarak da bilinir), sıralanması gereken bir diziyi rastgele permütasyonlar oluşturarak doğru sıralama bulunana kadar karşılaştırmalar yaparak sıralamaya çalışan, son derece etkisiz ve rastgele bir sıralama algoritmasıdır. Bogo Sort, şaka amaçlı bir algoritma olarak ortaya çıkmıştır ve pratik kullanım için uygun değildir.

Çalışma Mantığı ve Algoritma Adımları:

Bogo Sort’un çalışma mantığı oldukça basittir, ancak etkisiz bir şekilde çalışır:

Rastgele bir permütasyon oluşturulur.
Dizinin sıralı olup olmadığı kontrol edilir.
Eğer dizi sıralı değilse, adım 1’e geri dönülür ve yeni bir rastgele permütasyon oluşturulur.
Dizi sıralı olduğunda algoritma sonlanır.

Artı Yönleri:

Eğlenceli ve ilginç bir algoritma olarak görülebilir.
Herhangi bir dizi üzerinde çalışabilir, çünkü sıralı olup olmadığı umursanmaz.

Eksi Yönleri:

Bogo Sort, rastgele permütasyonlar oluşturduğu için son derece verimsizdir. Neredeyse her adımda diziyi doğru sıralamak için gerekli olan adımların sayısı ortalama ve en kötü durumlarda astronomik olabilir.
Pratik kullanım için uygun değildir. Dizinin boyutu arttıkça algoritmanın çalışma süresi hızla artar.
İyi bir zaman ve hafıza karmaşıklığına sahip değildir.

Zaman ve Algoritma Karmaşıklığı Karşılaştırması:

Bogo Sort’un ortalama ve en kötü durum zaman karmaşıklığı oldukça yüksektir. Ortalama durumda n! kadar adım gerekebilir. En iyi durumda bile O(n) zaman karmaşıklığı sağlayamaz.

Diğer sıralama algoritmaları, genellikle daha etkili ve pratik sonuçlar sunar:

Bubble Sort, Selection Sort gibi temel sıralama algoritmaları en azından O(n^2) zaman karmaşıklığına sahiptir, ancak Bogo Sort’un hızından daha iyidirler.
Merge Sort, Quick Sort gibi daha verimli algoritmalar O(n log n) zaman karmaşıklığına sahiptirler ve daha büyük dizilerde bile hızlı sonuçlar sağlarlar.
Bazı özel durumlar için optimize edilmiş algoritmalar, daha hızlı sonuçlar elde etmek için kullanılabilir (örneğin, Counting Sort veya Radix Sort gibi).

Genel olarak, Bogo Sort daha çok eğlence veya eğitim amaçlı bir algoritma olarak görülmektedir ve gerçek dünya uygulamalarında tercih edilen bir sıralama algoritması değildir.

GoLang’de Bogo Sort uygulaması:

package main

import (
	"fmt"
	"math/rand"
	"sort"
	"time"
)

func isSorted(arr []int) bool {
	n := len(arr)
	for i := 1; i < n; i++ {
		if arr[i] < arr[i-1] {
			return false
		}
	}
	return true
}

func shuffle(arr []int) {
	n := len(arr)
	rand.Seed(time.Now().UnixNano())
	for i := n - 1; i > 0; i-- {
		j := rand.Intn(i + 1)
		arr[i], arr[j] = arr[j], arr[i]
	}
}

func bogoSort(arr []int) {
	for !isSorted(arr) {
		shuffle(arr)
	}
}

func main() {
	arr := []int{4, 2, 7, 1, 9, 3, 5}
	fmt.Println("Original Array:", arr)

	bogoSort(arr)
	fmt.Println("Sorted Array:", arr)

	// Checking with built-in sorting for verification
	sortedArr := []int{4, 2, 7, 1, 9, 3, 5}
	sort.Ints(sortedArr)
	fmt.Println("Sorted Array (using built-in sort):", sortedArr)
}

Bu örnekte, bogoSort fonksiyonu Bogo Sort algoritmasını uygular. isSorted fonksiyonu bir dizinin sıralı olup olmadığını kontrol eder. shuffle fonksiyonu diziyi karıştırır. Ana main fonksiyonda bir dizi oluşturulur, bu dizi önce Bogo Sort ile sıralanır, sonra doğrulama için Go’nun yerleşik sıralama fonksiyonu kullanılarak sıralanır.

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Original Array: [4 2 7 1 9 3 5]
Sorted Array: [1 2 3 4 5 7 9]
Sorted Array (using built-in sort): [1 2 3 4 5 7 9]

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Interpolation Arama Algoritması

Wed, 12 Jul 2023 00:00:00 GMT

Interpolation Arama, sıralı bir dizide hızlı bir şekilde arama yapmak için kullanılan bir arama algoritmasıdır. Bu algoritma, binary search gibi sıralı dizilerde çalışırken, aranan değeri bulmak için tahmini bir konum belirlemeye dayanır.

İki temel koşula dayalıdır:

Dizi sıralı olmalıdır.
Dizideki elemanlar arasındaki farklar tahmin edilebilir ve düzensiz olmamalıdır.

Interpolation Search Nasıl Çalışır?

Interpolation search algoritması, aranan değerin tahmini konumunu hesaplamak için bir formül kullanır. Bu formül genellikle aşağıdaki gibidir:

position = low + ((value - arr[low]) / (arr[high] - arr[low])) * (high - low)

Burada:

arr[] => öğelerin aranması gereken dizi.
low => başlangıç dizini indeksini temsil eder.
high => bitiş dizini indeksini temsil eder.
value => aranan değeri temsil eder.

Algoritma şu adımları izler:

Başlangıçta low ve high değerleri, dizinin başlangıç ve bitiş indekslerini temsil eder.
Tahmini konumu hesaplamak için yukarıdaki formül kullanılır.
Eğer tahmini değer aranan değere eşitse, arama başarılıdır ve tahmini konum döndürülür.
Eğer tahmini değer aranan değerden küçükse, arama sağ tarafta devam eder, yani low değeri güncellenir.
Eğer tahmini değer aranan değerden büyükse, arama sol tarafta devam eder, yani high değeri güncellenir.
Bu işlem, aranan değer bulunana veya low değeri high değerinden büyük olana kadar devam eder.

Diğer Bazı Arama Algoritmalarıyla Karşılaştırma

Linear Search: Linear search algoritması, sıralı olmayan veya sıralı olsa bile sıralı olduğu bilgisi kullanılmayan dizilerde kullanılır. Her elemanı sırayla kontrol eder. Interpolation search, daha hızlı bir alternatif sunar çünkü tahmini konumu kullanarak elemanları hızla yaklaştırabilir. Karmaşıklığı O(n)‘dir.
Binary Search: Binary search, her adımda dizinin ortasındaki elemanı kontrol eder. Interpolation search, elemanlar arasındaki tahmini farkları kullanarak daha hızlı bir tahmin yapar. Ancak düzensiz aralıklara sahip dizilerde performansı düşebilir. Karmaşıklığı O(log n)‘dir.
Jump Search: Jump search, bir aralığı atlama adımlarıyla tarar. Jump search’ün adımları sabitken, interpolation search adımları tahmini konumun farkına göre değişir. Karmaşıklığı O(√ n)‘dir.

Interpolation search, dizinin düzgün bir şekilde dağıldığı durumlarda binary search’ten daha hızlı olabilir. Ancak dizi elemanları arasındaki farklar büyük ve düzensizse, algoritma doğru tahminler yapamayabilir ve hatta binary search’ten daha yavaş olabilir.

Karmaşıklık

Time: O(log(log(n))

GoLang’de Interpolation Search Algoritması uygulaması:

package main

import (
	"fmt"
)

func interpolationSearch(arr []int, target int) int {
	low := 0
	high := len(arr) - 1

	for low <= high && target >= arr[low] && target <= arr[high] {
		if low == high {
			if arr[low] == target {
				return low
			}
			return -1
		}

		pos := low + ((target - arr[low]) * (high - low)) / (arr[high] - arr[low])

		if arr[pos] == target {
			return pos
		}

		if arr[pos] < target {
			low = pos + 1
		} else {
			high = pos - 1
		}
	}

	return -1
}

func main() {
	arr := []int{1, 3, 5, 7, 9, 11, 13, 15, 17, 19}
	target := 11

	index := interpolationSearch(arr, target)
	if index != -1 {
		fmt.Printf("Aranan değer %d indeksinde bulundu.\n", index)
	} else {
		fmt.Println("Aranan değer bulunamadı.")
	}
}

Bu örnek, verilen bir sıralı dizi üzerinde Interpolation Search algoritmasını uygular. interpolationSearch fonksiyonu, dizi ve hedef değeri alır ve hedef değerin dizideki indeksini döndürür. Eğer hedef değer bulunamazsa -1 döner. Bu örnekte, aranan değer 11 ve verilen dizi [1, 3, 5, 7, 9, 11, 13, 15, 17, 19] şeklindedir.

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Aranan değer 5 indeksinde bulundu.

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Haversine Mesafesi: Coğrafi Noktalar Arası Mesafe Hesaplama

Tue, 27 Jun 2023 00:00:00 GMT

Coğrafi bilgi işlem, modern teknoloji ve veri işleme yöntemlerinin gelişmesiyle büyük bir ivme kazanmış, coğrafi veri ve konum tabanlı hizmetlerin giderek artan bir öneme sahip olduğu bir alandır. Coğrafi veriler, günümüzde birçok sektörde kritik bir rol oynamaktadır; coğrafi konum bilgileri, sadece harita uygulamalarında değil, aynı zamanda hava taşımacılığı, yolculuk planlaması, doğal afet tahmini, çevresel izleme, sağlık hizmetleri, coğrafi bilgi sistemleri (GIS) ve daha birçok alanda kullanılmaktadır.

Bu coğrafi verilerle çalışırken, iki nokta arasındaki mesafeyi hesaplama ihtiyacı ortaya çıkar. Ancak Dünya’nın gerçekte yuvarlak bir şekle sahip olduğunu düşündüğümüzde, bu hesaplama daha karmaşık hale gelir. İşte bu noktada Haversine mesafesi devreye girer. Haversine mesafesi, yüzey eğriliğini dikkate alarak, iki coğrafi konum arasındaki doğrudan mesafeyi hesaplayan bir matematiksel yöntemdir. Bu yöntem, Dünya’nın yüzeyinin eğriliğini ve yuvarlaklığını hesaba katarak, iki nokta arasındaki mesafeyi daha hassas bir şekilde belirlememize olanak tanır. Bu nedenle, coğrafi bilgi işlemde ve konum tabanlı hizmetlerde temel bir araç olarak kabul edilir.

Haversine Mesafesinin Önemi

Haversine mesafesi, coğrafi konum tabanlı uygulamalarda ve hizalama işlemlerinde kullanıldığında önemlidir. İşte Haversine mesafesinin neden önemli olduğuna dair bazı nedenler:

Gerçek Dünya Uygulamaları: Haversine mesafesi, coğrafi konum tabanlı uygulamalarda gerçek dünya mesafelerini hesaplarken kullanılır. Bu tür uygulamalar, konum tabanlı hizmetler, seyahat planlaması, hava yolu taşımacılığı, denizcilik, jeodezi ve daha pek çok alanda kullanılır.
Doğruluk ve Hassasiyet: Haversine mesafesi, Dünya’nın yuvarlak bir şekle sahip olduğunu dikkate alarak hesaplama yapar. Bu, iki nokta arasındaki mesafenin doğru ve hassas bir şekilde hesaplanmasını sağlar. Basit doğru çizgi hesaplamalarının aksine, Dünya’nın yüzeyindeki eğriliği göz önüne alır.
Harita Hizalaması: Harita hizalaması, coğrafi verileri harita üzerine yerleştirme işlemidir. Haversine mesafesi, bu verilerin düzlem üzerinde doğru bir şekilde hizalanmasına yardımcı olur.

Haversine Mesafesi Nasıl Hesaplanır?

Haversine mesafesi hesaplamak için aşağıdaki adımları izlersiniz:

İki noktanın enlem (latitude) ve boylam (longitude) koordinatlarını derece cinsinden alın.
Derece cinsinden verilen koordinatları radyan cinsine çevirin. Bu, enlem ve boylamı radian birimlerine dönüştürmek için aşağıdaki formülleri kullanarak yapılır:
- Enlem (Latitude) Radyanı = Enlem (Latitude) Derecesi x (π / 180)
- Boylam (Longitude) Radyanı = Boylam (Longitude) Derecesi x (π / 180)
Haversine formülünü kullanarak iki nokta arasındaki mesafeyi hesaplayın:
- Δlat = Enlem2 - Enlem1
- Δlon = Boylam2 - Boylam1
- a = sin²(Δlat/2) + cos(Enlem1) * cos(Enlem2) * sin²(Δlon/2)
- c = 2 * atan2(√a, √(1-a))
- Mesafe = R * c
- Burada, R Dünya’nın yarıçapıdır (ortalama olarak yaklaşık 6,371 km) ve atan2, arctangent işlemidir.
Hesaplanan mesafe, iki nokta arasındaki yüzey üzerindeki en kısa mesafeyi ifade eder.

Haversine mesafesi, coğrafi konum tabanlı uygulamalarda ve harita hizalamasında kullanılan önemli bir matematiksel yöntemdir. Bu yöntem, Dünya’nın yuvarlak bir şekle sahip olduğunu dikkate alarak iki nokta arasındaki gerçek mesafeyi hassas bir şekilde hesaplamamıza yardımcı olur. Bu nedenle, coğrafi veri işleme ve konum tabanlı hizmetler alanında temel bir araçtır.

GoLang’de Haversine Mesafesi uygulaması:

package main

import (
	"fmt"
	"math"
)

const earthRadius = 6371 // Average radius of the Earth (in kilometers)

func haversine(lat1, lon1, lat2, lon2 float64) float64 {
	// Convert degrees to radians
	lat1 = lat1 * math.Pi / 180
	lon1 = lon1 * math.Pi / 180
	lat2 = lat2 * math.Pi / 180
	lon2 = lon2 * math.Pi / 180

	// Apply the Haversine formula
	dlat := lat2 - lat1
	dlon := lon2 - lon1
	a := math.Sin(dlat/2)*math.Sin(dlat/2) + math.Cos(lat1)*math.Cos(lat2)*math.Sin(dlon/2)*math.Sin(dlon/2)
	c := 2 * math.Atan2(math.Sqrt(a), math.Sqrt(1-a))
	distance := earthRadius * c

	return distance
}

func main() {
	// Calculate the distance between two points
	lat1 := 40.7128 // Latitude of New York
	lon1 := -74.0060 // Longitude of New York
	lat2 := 34.0522 // Latitude of Los Angeles
	lon2 := -118.2437 // Longitude of Los Angeles

	result := haversine(lat1, lon1, lat2, lon2)
	fmt.Printf("Distance between New York and Los Angeles: %.2f km\n", result)
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Distance between New York and Los Angeles: 3935.75 km

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Bloom Filtresi [Veri Yapıları]

Wed, 14 Jun 2023 00:00:00 GMT

Bloom Filtresi, veri yapıları içinde sıklıkla kullanılan ve özellikle veri arama işlemlerini hızlandırmak için kullanılan oluşturulabilir bir olasılık tabanlı veri yapısıdır. Bu veri yapısı, elemanların varlık durumunu (var olma veya yok olma) hızlı bir şekilde ve düşük bellek kullanımı ile kontrol etmek için kullanılır.

Bloom Filtresi, 1970 yılında Burton Howard Bloom tarafından ortaya atılmıştır ve özellikle büyük veri kümeleri üzerinde etkili bir şekilde çalışır. Bloom Filtresi, yanıtın “kesin olmaması” durumunda kullanılır, yani belirli bir elemanın kümede kesinlikle bulunduğunu veya bulunmadığını belirtmek yerine, olasılıkla bulunduğunu ifade eder. Bu nedenle, Bloom Filtresi hızlı ve hafif olmasının yanı sıra, yanıtın olasılığını kabul edilebilir bir hata marjı ile sağlayabilir.

Bloom Filter, probabilistik (olasılıksal) bir veri yapısıdır. Bir öğenin bir kümede olup olmadığını kontrol etmek için kullanılır. Bu, diğer veri yapıları kullanılarak da elde edilebilir. Ancak, Bloom filtresi bunu verimli bir şekilde yapar.

Algoritma

Boş bir Bloom Filtresi, tümü 0 olarak ayarlanmış m bitlik bir bit dizisidir. Ayrıca, her biri bir m dizisi konumuna bazı set elemanını eşleyen veya karmaşıklaştıran k farklı hash fonksiyonu tanımlanmalıdır. Bu, uniform bir rastgele dağılım oluşturur. Genellikle k, m’den çok daha küçük bir sabittir ve eklenen elemanların sayısına orantılıdır; k’nın ve m’nin orantılı sabiti, filtrenin amaçlanan yanlış pozitif oranına göre belirlenir.

Aşağıda {x, y, z} kümesini temsil eden bir Bloom Filtresi örneğini görebiliriz. Renkli oklar, her set elemanının bit dizisinde eşleştirildiği konumları gösterir. W elemanı {x, y, z} kümesinde bulunmamaktadır, çünkü 0 içeren bir bit-dizi konumuna karmaşıklaştırılmıştır. Bu şekil için m = 18 ve k = 3’tür.

Bloom Filtresi, bir dizi k-bit uzunluğunda bir bit dizisi ve birkaç hash fonksiyonundan oluşur. İşleyişi şu şekildedir:

Önceden belirlenmiş k adet boş bit içeren bir dizi oluşturulur.
Eklenecek bir eleman geldiğinde, bu eleman için k adet farklı hash fonksiyonu kullanılır. Her hash fonksiyonu elemanın bir pozisyonunu döndürür.
Elde edilen bu pozisyonlar, bit dizisindeki ilgili pozisyonlara işaretlenir (1 değeri verilir).
Arama yapmak istediğimizde, aynı hash fonksiyonları kullanarak elemanın k pozisyonunu elde ederiz. Eğer bu pozisyonlardaki bitlerin tamamı 1 ise, elemanın muhtemelen veri kümesinde olduğu sonucuna varırız. Ancak, eğer en az bir pozisyonda 0 varsa, elemanın veri kümesinde kesinlikle olmadığı sonucuna varırız.

Bloom Filtresi Operasyonları

1. Ekleme (Insertion)

Bu işlem veri kümesine yeni bir elemanın eklenmesini ifade eder. Bu işlem, veri kümesine eleman eklemek için Bloom Filtresi’ni güncellemenin yollarından biridir.

Ekleme işlemi, şu adımlarla gerçekleştirilir:

Veri kümesine eklemek istediğimiz bir eleman (örneğin, eleman X) belirlenir.
Eleman X için Bloom Filtresi’nin içinde bulunan k farklı hash fonksiyonu kullanılır.
Her bir hash fonksiyonu eleman X’in m bitlik Bloom Filtresi içindeki k farklı pozisyonlarını belirler.
Belirlenen bu pozisyonlardaki bitler 1 olarak işaretlenir (set edilir).
Bloom Filtresi, eleman X’i içeren veri kümesini temsil etmek üzere güncellenmiş olur.

Bu adımlar, elemanın olası pozisyonlarına işaretlenmesi sayesinde Bloom Filtresi’nin belirli bir elemanın varlığını belirleme yeteneğini sağlar. Ancak unutulmamalıdır ki Bloom Filtresi, eleman ekledikçe yanlış pozitif olasılığının artacağı bir özelliğe sahiptir. Bu nedenle, yanıtların kesin olmaması ve yanlış pozitif sonuçlarının olasılığı kabul edilebilir olduğu durumlarda kullanılması önemlidir.

2. Arama (Search)

Arama işlemi, bir elemanın Bloom Filtresi’nde var olup olmadığını sorgulamak için kullanılır. Bloom Filtresi, bir elemanın var olma ihtimalini yüksek hızda belirlemek için tasarlanmıştır, ancak yanıtların kesin olmaması kabul edilebilir. Yani, bir elemanın filtrenin içinde kesinlikle bulunup bulunmadığını söylemek yerine, muhtemelen var olduğunu veya kesinlikle olmadığını ifade eder.

Arama işlemi, şu adımlarla gerçekleştirilir:

Aramak istediğimiz elemanın (örneğin, eleman Y) varlığını kontrol etmek için Bloom Filtresi’nin içinde bulunan k farklı hash fonksiyonu kullanılır.
Her bir hash fonksiyonu, eleman Y’in Bloom Filtresi içindeki k farklı pozisyonlarını belirler.
Belirlenen bu pozisyonlardaki bitlerin değerleri kontrol edilir. Eğer tüm pozisyonlardaki bitler 1 ise, eleman Y’ın muhtemelen filtrenin içinde olduğu sonucuna varılır. Ancak, en az bir pozisyondaki bit 0 ise, eleman Y’ın kesinlikle filtrenin içinde olmadığı sonucuna varılır.

Sorgulama işlemi, hızlı ve düşük bellek kullanımı sayesinde büyük veri kümeleri üzerinde etkili bir şekilde çalışır. Ancak, yanıtların kesin olmaması ve yanlış pozitif sonuçların (false positive) olasılığı göz önünde bulundurulmalıdır.

False Positives

False Positive (Yanlış Pozitif) kavramı, Bloom Filtresi’nde bir elemanın filtrenin içinde olmadığı halde, sorgulama işlemi sonucunda var olduğu yanıtının verilmesini ifade eder. Yani, aslında veri kümesinde bulunmayan bir elemanın, Bloom Filtresi sorgusunda olumlu sonuç vermesidir.

Bu yanıltıcı pozitif sonuçlar, özellikle Bloom Filtresi’nin boyutu (m), hash fonksiyonu sayısı (k) ve veri kümesi boyutu arasındaki ilişki nedeniyle oluşur. Filtrenin boyutu (m) ve kullanılan hash fonksiyonları sayısı (k), Bloom Filtresi’nin yanıltıcı pozitif olasılığını etkiler. Yanıltıcı pozitif oranı, filtrenin dolum oranı ve hash fonksiyonlarının dağılımıyla ilişkilidir.

Yanıltıcı pozitif sonuçlar, uygulamanın türüne ve hassasiyet gereksinimlerine bağlı olarak kabul edilebilir olabilir veya olmayabilir. Örneğin, bir veri kümesinde bulunmayan bir elemanın yanlışlıkla filtrede var olduğu belirlenirse, bu durumun uygulama için ciddi sonuçları olabilir. Bu nedenle, Bloom Filtresi kullanılırken yanıltıcı pozitif olasılığının tolerans düzeyi ve uygulama senaryosuna uygunluğu dikkate alınmalıdır.

Yanıltıcı pozitif olasılığını düşürmek için, daha büyük bir Bloom Filtresi kullanmak, daha fazla hash fonksiyonu kullanmak veya veri kümesinin boyutunu optimize etmek gibi yöntemler uygulanabilir. Ancak, bu tür düzeltmeler genellikle Bloom Filtresi’nin bellek ve işlemci kullanımını artırabilir. Dolayısıyla, yanıltıcı pozitif olasılığını düşürmek ve yanıltıcı pozitiflerin kabul edilemez olduğu durumlarda, diğer veri yapıları veya filtreleme yöntemleri tercih edilmelidir.

GoLang’de Bloom Filtresi uygulaması:

package main

import (
	"fmt"
	"hash/fnv"
)

type BloomFilter struct {
	bitArray []bool
	hashFunc []func(string) uint32
}

func NewBloomFilter(size int, numHashFunc int) *BloomFilter {
	bitArray := make([]bool, size)
	hashFunc := make([]func(string) uint32, numHashFunc)

	for i := 0; i < numHashFunc; i++ {
		hashFunc[i] = createHashFunc(i, size)
	}

	return &BloomFilter{
		bitArray: bitArray,
		hashFunc: hashFunc,
	}
}

func (bf *BloomFilter) Add(item string) {
	for _, hf := range bf.hashFunc {
		index := hf(item) % uint32(len(bf.bitArray))
		bf.bitArray[index] = true
	}
}

func (bf *BloomFilter) Contains(item string) bool {
	for _, hf := range bf.hashFunc {
		index := hf(item) % uint32(len(bf.bitArray))
		if !bf.bitArray[index] {
			return false
		}
	}
	return true
}

func createHashFunc(seed int, size int) func(string) uint32 {
	return func(data string) uint32 {
		hash := fnv.New32a()
		hash.Write([]byte(data))
		return uint32(seed) + hash.Sum32()%uint32(size)
	}
}

func main() {
	filter := NewBloomFilter(20, 3)

	// Elemanları filtreye ekleme
	filter.Add("apple")
	filter.Add("banana")
	filter.Add("orange")

	// Elemanların filtreye ait olup olmadığını sorgulama
	fmt.Println(filter.Contains("apple"))  // true
	fmt.Println(filter.Contains("banana")) // true
	fmt.Println(filter.Contains("orange")) // true
	fmt.Println(filter.Contains("grape"))  // false (yanlış pozitif)
	fmt.Println(filter.Contains("cherry")) // false (yanlış pozitif)
}

Bu kod örneğinde, basit bir Bloom Filtresi implementasyonu yapılmıştır. NewBloomFilter fonksiyonu ile Bloom Filtresi oluşturulurken, filtre boyutu (size) ve kullanılacak hash fonksiyonu sayısı (numHashFunc) belirtilmektedir. Add fonksiyonu ile elemanlar filtre içine eklenir ve Contains fonksiyonu ile elemanlar filtrenin içinde olup olmadığı sorgulanır. createHashFunc fonksiyonu, hash fonksiyonlarını oluşturmak için kullanılır ve basit bir FNV (Fowler-Noll-Vo) hash algoritması kullanılmıştır.

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

true
true
true
false
true

Programın çalışır haline şuradan erişilebilir.

Kullanım Alanları

Bloom Filtresi, belirli özellikleri nedeniyle çeşitli kullanım alanlarında tercih edilen bir veri yapısıdır. Aşağıda, Bloom Filtresi’nin yaygın olarak kullanıldığı bazı alanlar bulunmaktadır:

Veri Tabanı ve Önbellek Yönetimi: Büyük veri tabanları üzerinde hızlı sorgulamalar yapmak için kullanılır. Özellikle veri tabanında bulunan veya henüz oluşturulmamış olası sorgulamaları hızlandırmak için Bloom Filtresi, veritabanının daha az yüklenmesini sağlar. Aynı şekilde, önbellek yönetiminde de sık kullanılır.
Web Tarayıcılarında URL Geçmişi: Web tarayıcılarında, ziyaret edilen URL’leri veya web sayfalarını hafızada tutmak için Bloom Filtresi kullanılabilir. Bu, tarayıcıların ziyaret edilen sayfaları daha hızlı bir şekilde sorgulayabilmesine yardımcı olur.
Dağıtık Sistemler: Dağıtık sistemlerde, verilerin varlığını hızlı bir şekilde sorgulamak için kullanılır. Örneğin, dağıtık dosya sistemlerinde veya dağıtık anahtar-değer depolama sistemlerinde anahtarların varlığını kontrol etmek için Bloom Filtresi kullanılabilir.
Spam Filtreleme: E-posta veya mesaj uygulamalarında, spam e-postalarını veya spam mesajları hızlı bir şekilde filtrelemek için Bloom Filtresi kullanılabilir. Böylece, spam filtreleme işlemleri daha hızlı gerçekleştirilebilir.
Grafik ve Ağ Algoritmaları: Grafiklerde ve ağ algoritmalarında kullanılan belirli veri yapılarını hızlandırmak için Bloom Filtresi tercih edilebilir. Örneğin, grafik veri yapısındaki düğümlerin varlığını kontrol etmek veya ağdaki bağlantıları takip etmek için kullanılabilir.
Hafıza Verimliliği Gerektiren Uygulamalar: Bloom Filtresi, diğer veri yapılarına göre daha az bellek tüketir. Bu nedenle, hafıza verimliliğinin önemli olduğu uygulamalarda tercih edilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Knuth-Morris-Pratt (KMP) Algoritması

Fri, 21 Apr 2023 00:00:00 GMT

Knuth-Morris-Pratt (KMP) algoritması, bir metin içinde verilen bir deseni (pattern) arama amacıyla kullanılan etkili bir dize arama algoritmasıdır. Özellikle büyük metinlerde veya metin koleksiyonlarında hızlı bir şekilde desen aramak için tercih edilen bir algoritmadır. KMP algoritması, özellikle veri sıkıştırma, metin düzenleme, veritabanı sorgulamaları ve genel olarak metin işleme alanlarında kullanılır.

KMP algoritmasının temel prensibi, normalde yapılan tüm karşılaştırmaları bir araya getirerek desen ve metin arasındaki ilişkileri kullanmaktır. Bu sayede gereksiz karşılaştırmaları önler ve daha hızlı bir arama sağlar. KMP algoritması, çalışma zamanı bakımından kötü durumlarda bile lineer zaman karmaşıklığına (O(m + n)) sahip olabilir, burada “m” desenin uzunluğunu, “n” metnin uzunluğunu ifade eder.

KMP algoritmasının çalışma adımları şunlardır:

Deseni ve metni hazırla:
- Desen: Aranacak dizeyi temsil eder.
- Metin: Deseni içinde arayacağımız ana dizeyi temsil eder.
Prefix Fonksiyonunu Hesapla:
- Prefix fonksiyonu (veya başlangıç fonksiyonu), desen içindeki her bir pozisyona karşılık gelen en uzun önek (prefix) uzunluklarını hesaplar. Bu, desen içinde tekrar eden alt dizelerin tespit edilmesine yardımcı olur.
Deseni Metin Üzerinde Kaydırarak Arama:
- Deseni metin üzerinde sola doğru kaydırarak arama yapılır.
- Eşleşen karakterlerde kayma yapılırken, eşleşmeyen karakterlerde prefix fonksiyonundan gelen bilgiler kullanılarak ilerleme sağlanır. Bu, gereksiz karşılaştırmaların önüne geçer.

Bu adımlar sayesinde KMP algoritması, desen-metin eşleştirmelerini hızlı bir şekilde bulabilir ve performansı artırabilir. KMP algoritması, Brute Force (Kaba Kuvvet) yöntemine göre daha hızlıdır ve genellikle büyük veri kümesinde dize aramak gerektiğinde tercih edilen bir çözümdür.

Karmaşıklık

Time: O(|m| + |n|)
Space: O(|m|)

GoLang’de Knuth-Morris-Pratt Algoritması uygulaması:

package main

import (
	"fmt"
)

func computePrefixFunction(pattern string) []int {
	length := len(pattern)
	prefixFunc := make([]int, length)
	
	prefixLen := 0
	i := 1
	
	for i < length {
		if pattern[i] == pattern[prefixLen] {
			prefixLen++
			prefixFunc[i] = prefixLen
			i++
		} else {
			if prefixLen != 0 {
				prefixLen = prefixFunc[prefixLen-1]
			} else {
				prefixFunc[i] = 0
				i++
			}
		}
	}
	
	return prefixFunc
}

func kmpSearch(text, pattern string) []int {
	prefixFunc := computePrefixFunction(pattern)
	
	textLen := len(text)
	patternLen := len(pattern)
	
	i, j := 0, 0
	indices := []int{}
	
	for i < textLen {
		if pattern[j] == text[i] {
			i++
			j++
		}
		
		if j == patternLen {
			indices = append(indices, i-j)
			j = prefixFunc[j-1]
		} else if i < textLen && pattern[j] != text[i] {
			if j != 0 {
				j = prefixFunc[j-1]
			} else {
				i++
			}
		}
	}
	
	return indices
}

func main() {
	text := "ababcababcabcabc"
	pattern := "abcabc"
	
	indices := kmpSearch(text, pattern)
	
	if len(indices) == 0 {
		fmt.Println("Desen metinde bulunamadı.")
	} else {
		fmt.Println("Desen metinde bulundu, başlangıç indeksleri:", indices)
	}
}

Bu örnek, KMP algoritmasının temel mantığını Go dilinde uygulamaktadır. computePrefixFunction fonksiyonu, desen için önek fonksiyonunu hesaplar. kmpSearch fonksiyonu ise KMP algoritmasının desen arama işlemini gerçekleştirir. main fonksiyonunda ise örnek bir metin ve desen üzerinde algoritma çalıştırılmış ve sonuçları yazdırmıştır. Bu kodu kullanarak istediğiniz metin ve desende KMP algoritmasını deneyebilirsiniz.

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Desen metinde bulundu, başlangıç indeksleri: [7 10]

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Bremont Wright Flyer Saatinin Hikayesi ve Özellikleri

Wed, 05 Apr 2023 00:00:00 GMT

Tarihi Arka Plan

Bremont Wright Flyer Limited Edition saati, havacılık tarihinin en önemli olaylarından birine, Wright Kardeşler‘in 1903 yılında gerçekleştirdikleri ilk motorlu uçuşa saygı duruşunda bulunmak amacıyla tasarlanmıştır. Orville ve Wilbur Wright, 17 Aralık 1903’te Kuzey Carolina, Kitty Hawk’ta yaptıkları bu uçuşla, modern havacılığın temelini atmışlardır. Bu uçuş sadece 12 saniye sürmüş ve 120 feet mesafe kat etmiştir ancak bu insanlık tarihinde bir dönüm noktası olmuştur. Bu olağanüstü başarı, havacılığın gelişimini hızlandırmış ve dünya genelinde seyahatin dönüşümünde kritik bir rol oynamıştır.

Saatin Hikayesi

Bremont havacılık mirasını kutlamak ve Wright Kardeşler‘in bu önemli başarılarını onurlandırmak amacıyla, sınırlı sayıda üretilen Wright Flyer Limited Edition saatini tasarlamıştır. Bu özel saat, Wright Kardeşler’in ilk uçuşunda kullanılan orijinal Wright Flyer uçağının bir parçasını içermesiyle dikkat çekmektedir. Uçağın kanadından alınan orijinal bez parçası, saatin kadranında yer alarak ona eşsiz bir tarihsel değer katmaktadır. Bu saatin sadece bir zaman ölçme aracı değil, aynı zamanda havacılık tarihinin bir parçası olduğu anlamına gelir.

Saatin Özellikleri

Bremont Wright Flyer Limited Edition saati, yüksek kaliteli malzemeler ve üstün saat yapım teknikleri kullanılarak üretilmiştir. Saatin özellikleri şu şekildedir:

Kasa Çapı: 43 mm
Kasa Malzemesi: Paslanmaz çelik, 18k beyaz altın veya 18k roze altın seçenekleri
Kadran: Beyaz veya siyah kadran, Wright Flyer’ın kanadından alınan orijinal bez parçası içerir
Cam: Çift kubbeli safir kristal, yansıma önleyici kaplama
Kayış: El dikişli aligator derisi kayış, 18k beyaz altın veya 18k roze altın toka
Su Geçirmezlik: 100 metre (10 ATM)
Mekanizma: Bremont’un özel BE-10AE mekanizması, 50 saat güç rezervi
Sınırlı Üretim: Her biri numaralandırılmış 300 adet paslanmaz çelik, 100 adet beyaz altın ve 100 adet roze altın olmak üzere toplamda sadece 500 adet üretilmiştir

Bremont Wright Flyer Limited Edition saati sadece bir saat değil, aynı zamanda havacılık tarihinin önemli bir parçasını taşıyan bir koleksiyon eseridir. Wright Kardeşler’in ilk motorlu uçuşuna saygı duruşunda bulunan bu saat yüksek kaliteli işçiliği ve benzersiz tarihi değeri ile dikkat çekmektedir. Sınırlı sayıda üretilen bu özel saat, havacılık tutkunları ve saat koleksiyoncuları için eşsiz bir parçadır.

Kaynaklar

https://www.bremont.com/

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Yazılımcıların Bilmesi Gereken Prensipler

Mon, 23 Jan 2023 00:00:00 GMT

Yazılım geliştirme dünyası hızla ilerliyor ve bu hızlı ilerleyiş, geliştiricilerin daha fazla sayıda proje üzerinde çalışmasını gerektiriyor. Ancak, yazılım geliştirirken, belirli prensiplere uymak, kodun daha okunaklı, yeniden kullanılabilir ve bakımı yapılabilir olmasını sağlamak açısından son derece önemlidir.

Bu nedenle, yazılım geliştirme sürecinde sık kullanılan bazı prensipler mevcuttur. Bu makalede YAGNI, DRY, SOC, KISS, LOD ve SOLID prensiplerini inceleyeceğiz. Bu prensipler, yazılım geliştirme sürecinde takip edilmesi gereken en önemli prensiplerden bazılarıdır.

YAGNI

YAGNI prensibi, “You Ain’t Gonna Need It veya You Aren’t Gonna Need It” ifadesinin kısaltmasıdır ve Türkçe anlamı “Buna İhtiyacın Olmayacak” demektir. Yazılım geliştirme sürecinde bu prensip, gereksiz kod yazmaktan kaçınmanın önemini vurgular.

YAGNI prensibi, gelecekte belki kullanılabilecek özellikleri veya fonksiyonları şimdiden kodlamak yerine, sadece o anki ihtiyaçlara odaklanmayı önerir. Bu sayede, gereksiz kod yazarak zaman ve emek kaybı yaşanmasının önüne geçilir.

Bu prensip, kodun basit ve sade kalmasını sağlar. Bu da yazılımın daha kolay anlaşılabilir, test edilebilir ve bakımı yapılabilir hale gelmesini sağlar. Ayrıca, gereksiz kod yazımı yerine sadece ihtiyaç duyulan kod yazılarak kod kalitesi de arttırılmış olur.

Sonuç olarak, YAGNI prensibi, yazılım geliştirme sürecinde önemli bir prensiptir ve gereksiz kod yazmaktan kaçınarak, daha iyi ve sade bir kod yazımına yardımcı olur.

DRY

DRY prensibi, “Don’t Repeat Yourself” (Kendini Tekrarlama) ifadesinin kısaltmasıdır. Bu prensip, yazılım geliştirme sürecinde tekrarlanan kod bloklarından kaçınmanın önemini vurgular.

DRY prensibi, aynı kodun birden fazla yerde kullanılması yerine, bir fonksiyon ya da metot şeklinde yazılarak kodun yeniden kullanılabilirliğini artırır. Böylece, geliştiriciler aynı kodu tekrar tekrar yazmak yerine, daha önce yazdıkları kodu kullanarak zamandan tasarruf ederler.

DRY prensibi ayrıca kodun okunabilirliğini artırır. Tekrarlanan kod blokları, kodun okunmasını ve anlaşılmasını zorlaştırır. Kodda değişiklik yapmak gerektiğinde, tekrarlanan kodların değiştirilmesi gerekir ve bu da daha fazla zaman alır.

DRY prensibi, yazılım geliştirme sürecinde kodun sadeleştirilmesine yardımcı olur ve kod kalitesini artırır. Ancak, bu prensibin uygulanması, kodun yeniden kullanılabilirliğini artırırken aynı zamanda kodun doğru şekilde organize edilmesini ve bütünlüğünü korumasını gerektirir.

Sonuç olarak, DRY prensibi, yazılım geliştirme sürecinde tekrarlanan kod bloklarından kaçınmanın önemini vurgular ve kodun sadeleştirilmesine yardımcı olur. Bu prensip, kodun yeniden kullanılabilirliğini artırarak yazılım geliştirme sürecinde zaman ve emek tasarrufu sağlar.

SOC

SOC (Separation of Concerns), Türkçe’ye “Endişelerin Ayrıştırılması” olarak çevrilebilecek bir prensiptir. Yazılım geliştirme sürecinde bu prensip, farklı işlevleri olan parçaların birbirinden bağımsız olarak tasarlanmasını ve geliştirilmesini önerir.

Bu prensibe göre, bir yazılımın farklı işlevleri, kendi endişeleri ile ilgili bölümlerde düzenlenmelidir. Bir yazılımın belirli bir işlevi için geliştirilen kod blokları, sadece o işlevi yerine getirmekle ilgilenmelidir ve başka işlevleri etkilememelidir.

SOC prensibi, yazılımın daha modüler hale gelmesini sağlar. Modüler yazılım, farklı işlevleri olan parçaların birleştirilmesiyle oluşturulur. Bu sayede, her bir parça birbirinden bağımsız olarak geliştirilir ve test edilir. Bu da yazılımın daha güvenilir, okunaklı ve sürdürülebilir olmasını sağlar.

SOC prensibi ayrıca, yazılım geliştirme sürecinde yeniden kullanılabilirliği artırır. Modüler bir yaklaşım, farklı yazılım parçalarının başka projelerde veya farklı işlevlerde yeniden kullanılmasını kolaylaştırır.

Sonuç olarak, SOC prensibi, yazılımın farklı işlevleri için geliştirilen kod bloklarının birbirinden bağımsız olarak tasarlanmasını ve geliştirilmesini önerir. Bu prensip, yazılımın daha modüler hale gelmesini, daha güvenilir ve sürdürülebilir olmasını sağlar ve yazılım geliştirme sürecinde yeniden kullanılabilirliği artırır.

KISS

KISS, “Keep It Simple, Stupid veya Keep It Short and Simple” (Basit Tut, Aptal) kısaltmasının açılımıdır. Yazılım geliştirme sürecinde, bu prensip, bir tasarımın en basit haliyle tutulması gerektiğini vurgular.

KISS prensibi, yazılımın daha okunaklı, sürdürülebilir ve test edilebilir olmasını sağlar. Karmaşık tasarımlar, kodun anlaşılmasını zorlaştırır ve hataların tespit edilmesini ve giderilmesini güçleştirir.

KISS prensibi, yazılımın daha basit olmasını önerir, ancak bu, kodun işlevselliğinden ödün vermek anlamına gelmez. Tam tersine, KISS prensibi, işlevselliği ve kaliteyi artırmak için gereksiz karmaşıklıklardan kaçınmayı önerir.

KISS prensibinin uygulanması, kodun daha okunaklı hale gelmesini sağlar. Basit bir kod, geliştiricilerin kodu daha hızlı anlamasını ve değişiklik yapmasını sağlar. Ayrıca, basit bir kod, yeni geliştiricilerin projeye daha hızlı adapte olmasını sağlar.

KISS prensibi ayrıca, yazılımın daha sürdürülebilir hale gelmesini sağlar. Karmaşık kodlar, bakım ve güncelleme işlemlerini zorlaştırırken, basit kodlar daha az hata içerir ve daha kolay bakım yapılmasını sağlar.

Sonuç olarak, KISS prensibi, yazılımın en basit haliyle tutulmasını önerir. Bu prensip, yazılımın daha okunaklı, sürdürülebilir ve test edilebilir olmasını sağlar. Basit bir kod, yazılım geliştirme sürecinde hızlı ve kolay değişiklik yapılmasını sağlar ve daha az hata içerir.

LOD

LOD (Law of Demeter), yazılım geliştirme sürecinde, nesneler arasındaki bağımlılık seviyesini minimize etmeyi öneren bir prensiptir. LOD, ayrıca “Least Knowledge Principle” (En Az Bilgi Prensipleri) olarak da bilinir.

LOD prensibi, bir sınıfın diğer sınıflara mümkün olduğunca az bağımlı olması gerektiğini belirtir. Bir sınıfın sadece doğrudan bağımlı olduğu sınıflarla etkileşimde bulunması önerilir. Yani, bir sınıf, başka sınıfların başka sınıflarla olan ilişkilerinden haberdar olmamalıdır.

Bu prensibin temel amacı, yazılımın daha esnek ve yeniden kullanılabilir hale gelmesini sağlamaktır. Bir sınıfın diğer sınıflara sıkı sıkıya bağımlı olması durumunda, değişikliklerin yapılması ve yeniden kullanılabilirliğin sağlanması daha zor hale gelir.

LOD prensibi, yazılım geliştiricilerine sınıflar arasındaki bağımlılıkları azaltmak için birkaç yöntem önerir. Bunlar arasında, sınıfın diğer sınıflarla olan etkileşimini sınırlamak, sınıfın sadece kendi görevleri ile ilgili bilgiyi saklamak, ara katmanlar kullanmak ve gerekirse arayüzler kullanmak sayılabilir.

Sonuç olarak, LOD prensibi, yazılımın esnek, sürdürülebilir ve yeniden kullanılabilir olmasını sağlamak için, sınıflar arasındaki bağımlılık seviyesini minimize etmeyi önerir. Bu prensip, bir sınıfın sadece kendi görevleriyle ilgili bilgiyi saklamasını ve sadece doğrudan bağımlı olduğu sınıflarla etkileşimde bulunmasını önerir. Bu sayede, yazılım daha az hata içerecek ve daha kolay bakım yapılmasını sağlayacaktır.

SOLID

SOLID, yazılım mühendisliğinde kullanılan temel prensiplerin bir akronimididir. Bu prensipler, yazılımın daha esnek, sürdürülebilir, bakımı kolay, yeniden kullanılabilir ve genişletilebilir hale getirilmesini hedeflemektedir. İlk olarak, SOLID prensiplerini belirten Robert C. Martin (a.k.a. Uncle Bob) tarafından tanıtılmıştır.

SOLID prensipleri şunlardır:

S - Single Responsibility Principle (Tek Sorumluluk Prensibi)
O - Open/Closed Principle (Açık/Kapalı Prensibi)
L - Liskov Substitution Principle (Liskov Yerine Geçme Prensibi)
I - Interface Segregation Principle (Arayüz Ayrımı Prensibi)
D - Dependency Inversion Principle (Bağımlılık Tersine Çevirme Prensibi)

Bu prensipleri ayrı ayrı açıklayalım:

Tek Sorumluluk Prensibi (Single Responsibility Principle): Bir sınıfın sadece bir görevi veya sorumluluğu olmalıdır. Sınıfların, farklı sorumlulukları olan diğer sınıflarla karıştırılmadan, tek bir sorumluluğa sahip olması, kodun daha okunaklı, anlaşılır ve sürdürülebilir olmasını sağlar.
Açık/Kapalı Prensibi (Open/Closed Principle): Bir sınıf, değişime kapalı (closed) olmalı, ancak yeni işlevselliği eklemek için açık (open) olmalıdır. Yani, mevcut kodun değiştirilmesi gerektiğinde sınıfı değiştirmek yerine, yeni işlevselliği eklemek için genişletilebilir olmalıdır.
Liskov Yerine Geçme Prensibi (Liskov Substitution Principle): Herhangi bir alt sınıf, üst sınıfın yerine geçebilmelidir. Bu, alt sınıfların, üst sınıfın davranışlarını koruması gerektiği anlamına gelir. Bu prensibin uygulanması, kodun daha esnek hale gelmesine ve yeniden kullanılabilirliğinin artmasına yardımcı olur.
Arayüz Ayrımı Prensibi (Interface Segregation Principle): Bir arayüz, kullanmayacağımız özelliklere sahip olmamalıdır. Kullanılmayan özellikler, kodun gereksiz yere büyümesine ve karmaşık hale gelmesine neden olabilir. Bu nedenle, arayüzler, ihtiyaç duyulan işlevselliği kapsayacak şekilde tasarlanmalıdır.
Bağımlılık Tersine Çevirme Prensibi (Dependency Inversion Principle): Yüksek seviyeli sınıflar, düşük seviyeli sınıflara bağlı olmamalıdır. Bunun yerine, her iki sınıf da soyutlamalara (abstractions) bağımlı olmalıdır. Yüksek seviyeli sınıflar, düşük seviyeli sınıfların nasıl uygulandığından bağımsız olmalıdır. Bu, kodun daha az bağımlı, daha esnek ve yeniden kullanılabilir hale gelmesini sağlar.

SOLID prensiplerinin uygulanması, yazılım projelerinin daha sürdürülebilir, esnek ve genişletilebilir olmasına yardımcı olur. Bu prensipleri takip etmek, kod kalitesini artırır ve daha az bakım gerektiren, daha az hata veren, daha hızlı geliştirilen ve daha az maliyetli yazılım projeleri oluşturmanıza olanak tanır.

Bu makalede, yazılım geliştiricilerin sıkça duyacakları YAGNI, DRY, SOC, KISS, LOD ve SOLID prensiplerini ele aldık. Bu prensipler, kodun okunabilirliğini, yeniden kullanılabilirliğini, bakımını ve genişletilebilirliğini artırmak için tasarlanmıştır. Bu prensipleri takip etmek, yazılım projelerini daha sürdürülebilir, esnek ve genişletilebilir hale getirebilir.

SOLID prensipleri, kodun esnekliğini ve yeniden kullanılabilirliğini artırırken, DRY prensibi, kodun tekrarını önleyerek yazılım projelerinin bakımını kolaylaştırır. KISS prensibi, kodun okunabilirliğini artırırken, SOC prensibi, kodu modüler ve bağımsız hale getirerek yazılım projelerini daha sürdürülebilir hale getirir. LOD prensibi, kodun daha az bağımlı hale gelmesini sağlarken, YAGNI prensibi, gereksiz kodların yazılmasını önleyerek kodun daha temiz ve okunaklı hale gelmesine yardımcı olur.

Bu prensipleri uygulamak, yazılım geliştirme sürecinde daha verimli, daha hızlı ve daha maliyet-etkin olmamıza yardımcı olabilir. Yüksek kaliteli ve esnek bir yazılım ürünü oluşturmak istiyorsak, YAGNI, DRY, SOC, KISS, LOD ve SOLID prensiplerini dikkate almamız önemlidir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Omega Speedmaster Professional Chronograph

Fri, 06 Jan 2023 00:00:00 GMT

Tarihi Arka Plan

Omega Speedmaster ilk kez 1957 yılında piyasaya sürüldü. Aslen motor sporları için tasarlanmış olan bu saat, hız ve dayanıklılık temaları etrafında şekillendi. Ancak onun gerçek ünü ve ikonlaşması, uzay araştırmaları ve özellikle Apollo görevleriyle oldu. NASA astronotların kullanımı için çeşitli saatleri test ederken, Omega Speedmaster Professional (Ref. ST105.012) 1965 yılında seçildi. Saat ekstrem sıcaklıklar, vakum koşulları, nem, şok ve diğer zorlu koşullara karşı dayanıklılığını kanıtladı.

Ay’a Yolculuk ve Önemi

Omega Speedmaster Professional 20 Temmuz 1969’da gerçekleşen Apollo 11 görevi sırasında Ay yüzeyine inen ilk saat oldu. Neil Armstrong ve Buzz Aldrin’in kolunda taşıdığı bu saat “Moonwatch” olarak anılmaya başladı. Omega Speedmaster bu tarihi anla özdeşleşerek insanlık tarihinin en önemli keşiflerinden birine tanıklık etti. NASA tarafından resmi olarak onaylanmış tek saat olan Speedmaster, sonraki Apollo görevlerinde ve birçok uzay yürüyüşünde de kullanıldı.

Teknolojik Özellikler

Omega Speedmaster Professional Chronograph, mekanik ve teknik mükemmeliyetiyle bilinir. İşte bu saatin öne çıkan bazı özellikleri:

- Hareket (Kalibre 1861 ve 3861): Speedmaster Professional, Omega’nın ünlü mekanik el kurmalı kalibre 1861 ile donatılmıştır. Kalibre 1861, Apollo görevlerinde kullanılan kalibre 321’in evrimidir. Yeni modellerde kalibre 3861 kullanılmaktadır, bu kalibre Co-Axial mekanizması ve METAS sertifikası ile dikkat çeker.

- Kronograf Fonksiyonu: Saatin kronograf fonksiyonu dakikaları ve saatleri ölçebilme kapasitesine sahiptir. Üç alt kadran saniye, dakika ve saat ölçümlerini gösterir.

- Tasarım: Speedmaster’ın klasik tasarımı siyah kadran ve beyaz indekslerle sade ama işlevsel bir görünüm sunar. 42mm paslanmaz çelik kasası ve hesalite (plastik) kristali, uzay görevleri sırasında yaşanan basınç farklılıklarına dayanıklıdır.

- Dayanıklılık: Saat ekstrem koşullarda bile güvenilir performans sunar. NASA’nın testlerinden başarıyla geçen bu saat şoklara, yüksek ve düşük sıcaklıklara, vakum ve nem koşullarına karşı dayanıklıdır.

- Su Geçirmezlik: Omega Speedmaster Professional 50 metreye kadar suya dayanıklıdır, bu da onu günlük kullanımda suya karşı korunaklı kılar.

Speedmaster sadece bir saat değil, aynı zamanda bir semboldür. İnsanlığın sınırlarını zorlayarak Ay’a ulaşmasında bir yol arkadaşı olmuş ve zamanın ötesinde bir ikon haline gelmiştir. Bu saat birçok koleksiyoncu için paha biçilmez bir değere sahiptir ve saat tutkunlarının vazgeçilmez parçalarından biridir.

Kaynaklar

https://www.omegawatches.com/en-us/

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

SOLID - Dependency Inversion Principle

Sun, 04 Sep 2022 00:00:00 GMT

Dependency Inversion Prensibi (DIP), nesne yönelimli programlama (OOP) prensiplerinden biridir. DIP, yazılım geliştirme sürecinde, birbirine bağımlı sınıfların oluştuğu ve bu sınıfların birbiriyle sıkı bir şekilde ilişkili olduğu durumlarda, bu bağımlılıkların tersine çevrilmesini ve bağımlılıkların daha az sıkı hale getirilmesini önerir. Bu prensip, sınıfların daha az bağımlı hale getirilmesini ve böylece daha esnek ve yeniden kullanılabilir hale gelmesini sağlar.

DIP, aynı zamanda SOLID prensiplerinin “D” harfini ifade eder. Prensipte, bir üst seviyedeki modül, alt seviyedeki modüle doğrudan bağımlı olmamalıdır. Bunun yerine, üst seviyedeki modül, alt seviyedeki modüle bağımlılığı tersine çevirmeli ve bu modüller arasında bir arayüz sağlamalıdır. Bu sayede, alt seviyedeki modüllerin uygulaması değişse bile üst seviyedeki modülün değiştirilmesi gerekmez.

DIP, kodun bakımı ve test edilebilirliği açısından da önemlidir. Bağımlılıkların tersine çevrilmesi, bir sınıfın değiştirilmesi gerektiğinde, diğer sınıfların etkilenmemesini sağlar. Bu, kodun yeniden kullanılabilirliğini artırır ve bakım maliyetlerini azaltır.

PHP’de, Dependency Inversion prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

interface EmailSenderInterface {
    public function sendEmail($to, $subject, $message);
}

class EmailSender implements EmailSenderInterface {
    public function sendEmail($to, $subject, $message) {
        // ... e-posta gönderme işlemi ...
    }
}

class Customer {
    private $emailSender;
    
    public function __construct(EmailSenderInterface $emailSender) {
        $this->emailSender = $emailSender;
    }
    
    public function placeOrder() {
        // ... müşteri siparişi işleme koyma kodu ...
        
        // e-posta gönderme işlemi
        $this->emailSender->sendEmail($this->email, 'Sipariş Onayı', 'Siparişiniz başarıyla alındı.');
    }
}

$emailSender = new EmailSender();
$customer = new Customer($emailSender);
$customer->placeOrder();

Yukarıdaki örnekte, Customer sınıfı, EmailSenderInterface arayüzüne bağımlı hale getirildi. EmailSender sınıfı da EmailSenderInterface arayüzünü uyguladığından, EmailSender sınıfı Customer sınıfı tarafından kullanılabilir hale gelir.

Bu şekilde, müşteri sınıfımızın doğrudan bir sınıfa bağımlı olması yerine, bir arayüze bağımlı olması sağlanmıştır. Böylece, farklı bir e-posta gönderme servisi kullanmak istesek bile, sadece yeni bir sınıf oluşturup EmailSenderInterface arayüzünü uygulamak yeterli olacaktır. Bu şekilde, müşteri sınıfını değiştirmeden yeni bir e-posta gönderme servisi kullanabiliriz.

Aşağıdaki PHP kodu ise Dependency Inversion prensibini ihlal eden bir sınıf örneğidir.

class Customer {
    private $emailSender;
    
    public function __construct() {
        $this->emailSender = new EmailSender();
    }
    
    public function placeOrder() {
        // ... müşteri siparişi işleme koyma kodu ...
        
        // e-posta gönderme işlemi
        $this->emailSender->sendEmail($this->email, 'Sipariş Onayı', 'Siparişiniz başarıyla alındı.');
    }
}

class EmailSender {
    public function sendEmail($to, $subject, $message) {
        // ... e-posta gönderme işlemi ...
    }
}

$customer = new Customer();
$customer->placeOrder();

Yukarıdaki örnekte, Customer sınıfı doğrudan EmailSender sınıfına bağımlıdır. Bu, Customer sınıfının esnekliğini azaltır, çünkü müşteri sınıfı, yalnızca EmailSender sınıfını kullanarak e-posta göndermek zorundadır.

Bunun yerine, Customer sınıfı EmailSenderInterface arayüzüne bağımlı hale getirilmeli ve EmailSender sınıfı da bu arayüzü uygulamalıdır. Böylece, müşteri sınıfı daha esnek hale gelir ve farklı e-posta gönderme servisleri kullanılabileceği için daha kolay bir şekilde değiştirilebilir hale gelir.

GoLang’de Dependency Inversion prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

type EmailSenderInterface interface {
    SendEmail(to string, subject string, message string)
}

type EmailSender struct {}

func (e EmailSender) SendEmail(to string, subject string, message string) {
    // ... e-posta gönderme işlemi ...
}

type Customer struct {
    EmailSender EmailSenderInterface
    Email string
}

func (c Customer) PlaceOrder() {
    // ... müşteri siparişi işleme koyma kodu ...
    
    // e-posta gönderme işlemi
    c.EmailSender.SendEmail(c.Email, "Sipariş Onayı", "Siparişiniz başarıyla alındı.")
}

func main() {
    emailSender := EmailSender{}
    customer := Customer{EmailSender: emailSender, Email: "example@example.com"}
    customer.PlaceOrder()
}

Yukarıdaki örnekte, Customer sınıfı, EmailSenderInterface arayüzüne bağımlı hale getirilmiştir. EmailSender sınıfı da EmailSenderInterface arayüzünü uyguladığından, EmailSender sınıfı Customer sınıfı tarafından kullanılabilir hale gelir.

PHP örneğine benzer şekilde, aşağıdaki GoLang kodu da Dependency Inversion prensibini ihlal eden bir örnektir.

type Customer struct {
    EmailSender EmailSender
    Email string
}

func (c Customer) PlaceOrder() {
    // ... müşteri siparişi işleme koyma kodu ...
    
    // e-posta gönderme işlemi
    c.EmailSender.SendEmail(c.Email, "Sipariş Onayı", "Siparişiniz başarıyla alındı.")
}

type EmailSender struct {}

func (e EmailSender) SendEmail(to string, subject string, message string) {
    // ... e-posta gönderme işlemi ...
}

func main() {
    emailSender := EmailSender{}
    customer := Customer{EmailSender: emailSender, Email: "example@example.com"}
    customer.PlaceOrder()
}

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Transposition Şifrelemesi: Harf Pozisyonlarını Değiştirerek Gizlilik Sağlama Sanatı

Thu, 14 Jul 2022 00:00:00 GMT

Kriptografi iletişimde gizliliği korumak amacıyla kullanılan özel bir alandır. Bu disiplin, bilgilerin güvende kalmasını sağlamak için tasarlanmış yöntemleri içerir ve genellikle hassas verilerin yetkisiz erişimden korunmasını hedefler. Kriptografi, birçok farklı şifreleme yöntemini içerir ve bu yöntemler, bilgi güvenliğini artırmak ve gizliliği korumak için geniş bir yelpazede kullanılır. Bu şifreleme teknikleri, mesajların sadece yetkili kişiler tarafından anlaşılabilir olmasını sağlayarak iletişimin güvenliğini artırır ve gizliliği sağlar.

Transposition Şifrelemesi Nedir?

Transposition şifrelemesi, metindeki harf pozisyonlarını belirli bir düzeni takip ederek yer değiştirerek metni şifreleyen oldukça ilginç bir kriptografi yöntemidir. Temel prensip, metindeki harf sıralamalarını değiştirerek şifrelenmiş bir metin oluşturmaktır. Bu değişiklikler, metni orijinal halinden farklı bir hale getirir ve iletişimi daha güvenli hale getirir.

Bu şifreleme türü, tarihsel olarak askeri ve diplomatik iletişimde kullanılmıştır. Düşmanların mesajları anlamasını zorlaştırmak için harf pozisyonlarının belirli bir anahtarla değiştirilmesi, iletişimin güvenliğini artırır. Ancak, bu yöntem günümüzde daha karmaşık ve güçlü şifreleme teknikleri tarafından yerini almıştır.

Transposition’in Amaçları Nelerdir?

Gizlilik Sağlama: Transposition şifrelemesi, iletişimin gizliliğini sağlama amacı taşır. Mesajlar şifrelendiğinde, sadece doğru anahtara sahip kişilerin mesajı çözmesi mümkün olur.
Bilgi Koruma: Transposition şifrelemesi, hassas bilgilerin yetkisiz erişimden korunmasına yardımcı olur. Özellikle askeri ve diplomatik iletişimde, düşmanların mesajları kolayca çözmesini engellemek için kullanılır.

Transposition Şifrelemesinin Türleri

Transposition şifrelemesi, farklı türleri içeren geniş bir kategoriye sahiptir. İşte bazı temel Transposition şifreleme türleri:

ROUTE Cipher (ROT): Bu tür, metni bir düzlemde belirli bir yolu takip ederek şifreler. Metin belirli bir yönde dolaştırılarak şifrelenir ve çözülür. Saat yönü veya ters yönde dolaşma şeklinde çeşitleri bulunur.
Rail Fence Cipher: Bu şifreleme türünde, metin bir çit gibi düşünülür ve harfler çit panellerine sırayla yerleştirilir. Şifreli metin, çit panelleri boyunca sırayla alınarak elde edilir.
Columnar Transposition Cipher: Bu yöntemde, metin bir matrise yerleştirilir ve metin sütunları belirli bir sıra veya anahtarla yer değiştirilir. Şifre çözme işlemi, sütunları doğru sıraya yerleştirerek yapılır.

Transposition Şifrelemesi Hangi Alanlarda Kullanılır?

Transposition şifrelemesi tarihsel olarak askeri ve diplomatik iletişimde kullanılmıştır. Ancak, modern kriptografi standartlarına göre genellikle güvenli değildir, çünkü basit anahtarlarla kırılabilir. Bu nedenle günümüzde daha güçlü ve karmaşık şifreleme yöntemleri tercih edilmektedir.

Transposition şifrelemesi, iletişimde gizlilik sağlamak için kullanılan eski bir kriptografi yöntemidir. Harf pozisyonlarının değiştirilmesi ile çalışır ve birçok farklı türe sahiptir. Ancak, modern kriptografi ihtiyaçlarına cevap vermek için daha güçlü şifreleme yöntemleri geliştirilmiştir.

GoLang’de Transposition Şifrelemesi (Columnar Transposition) uygulaması:

package main

import (
	"fmt"
	"math"
	"strings"
)

func encryptMessage(key int, message string) string {
	cipherText := make([]string, key)

	for col := 0; col < key; col++ {
		pointer := col
		for pointer < len(message) {
			cipherText[col] += string(message[pointer])
			pointer += key
		}
	}

	return strings.Join(cipherText, "")
}

func decryptMessage(key int, message string) string {
	numCols := int(math.Ceil(float64(len(message)) / float64(key)))
	numRows := key
	numShadedBoxes := (numCols * numRows) - len(message)
	plainText := make([]string, numCols)

	col, row := 0, 0

	for _, symbol := range message {
		plainText[col] += string(symbol)
		col++

		if (col == numCols) || (col == numCols-1 && row >= numRows-numShadedBoxes) {
			col = 0
			row++
		}
	}

	return strings.Join(plainText, "")
}

func main() {

	message := "TopSecret"
	key := 3

	encryptedText := encryptMessage(key, message)
	fmt.Printf("Encrypted Message: %s\n", encryptedText)

	decryptedText := decryptMessage(key, encryptedText)
	fmt.Printf("Decrypted Message: %s\n", decryptedText)
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Encrypted Message: TSroeepct
Decrypted Message: TopSecret

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

SOLID - Interface Segregation Principle

Wed, 25 May 2022 00:00:00 GMT

“Interface Segregation Principle” (ISG) veya “Ara Yüz Ayrımı Prensibi”, yazılım tasarımında kullanılan bir prensiptir. Bu prensibe göre, bir arayüzün mümkün olduğunca özelleştirilmiş olması gerektiği ve arayüzlerin sadece kullanılan özelliklerini içermesi gerektiği söylenir. ISG, kullanılmayan veya gereksiz özelliklerin bulunmadığı, yalnızca ihtiyaç duyulan özelliklerin bulunduğu arayüzler oluşturarak yazılımın esnekliğini arttırmayı amaçlar.

Bu prensip, yazılım tasarımındaki bağımlılıkları azaltmak için kullanılır. Bir arayüzde çok fazla özellik varsa, bu özelliklerin kullanılmadığı yerlerde bile gereksiz kod karmaşıklığı oluşturabilir. Bunun yanı sıra, bu özelliklerin biri değiştiğinde, bu değişiklik arayüzü kullanan tüm sınıfları etkileyebilir. ISG, bu sorunları önlemek için her arayüzün mümkün olduğunca özelleştirilmiş olması ve yalnızca ihtiyaç duyulan özellikleri içermesi gerektiğini söyler.

Bu prensibin avantajları arasında yazılımın daha esnek, bakımının daha kolay ve değişikliklerin daha az maliyetli olması sayılabilir. Ayrıca yazılımın daha anlaşılır ve daha az karmaşık hale gelmesi de mümkündür.

ISG, özellikle büyük yazılım projelerinde kullanışlıdır. Bu projelerde, farklı geliştiriciler farklı modülleri yazabilirler. Bu modüller, birbirleriyle iletişim kurmak için arayüzleri kullanırlar. ISG, arayüzlerin küçük, özelleştirilmiş ve bağımsız olmasını sağlayarak, bu modüllerin birbirinden bağımsız olarak geliştirilmesine olanak tanır.

Sonuç olarak, ISG, yazılım tasarımında kullanılan önemli bir prensiptir. Bu prensip, yazılımın esnekliğini arttırır, bakımını kolaylaştırır ve değişikliklerin maliyetini azaltır. Ayrıca, büyük yazılım projelerinde farklı geliştiricilerin birbirinden bağımsız olarak çalışmasını kolaylaştırır.

PHP’de, Interface Segregation prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

interface PaymentInterface {
    public function processPayment();
    public function refundPayment();
    public function holdPayment();
}

class CreditCardPayment implements PaymentInterface {
    public function processPayment() {
        // Kredi kartı ödeme işlemi gerçekleştirme kodu
    }
    public function refundPayment() {
        // Kredi kartı geri ödeme işlemi gerçekleştirme kodu
    }
    public function holdPayment() {
        // Kredi kartı ödeme tutma işlemi gerçekleştirme kodu
    }
}

class PaypalPayment implements PaymentInterface {
    public function processPayment() {
        // PayPal ödeme işlemi gerçekleştirme kodu
    }
    public function refundPayment() {
        // PayPal geri ödeme işlemi gerçekleştirme kodu
    }
    public function holdPayment() {
        // PayPal ödeme tutma işlemi gerçekleştirme kodu
    }
}

Yukarıdaki kod örneğinde, PaymentInterface adlı bir arayüz tanımlanmıştır ve bu arabirim “processPayment”, “refundPayment” ve “holdPayment” adlı üç method içerir. CreditCardPayment ve PaypalPayment adlı sınıflar, PaymentInterface arabirimini uygulayarak bu yöntemleri kullanabilir.

Bu şekilde, PaymentInterface sadece ihtiyacımız olan üç methodu içerir ve bu methodlar yalnızca bu arayüzü kullanan sınıflar tarafından kullanılır. Bu, arayüzün gereksiz yöntemler içermediği anlamına gelir ve bu da arabirimlerin özelleştirilmiş ve ihtiyaç duyulan yöntemleri içerecek şekilde tasarlanmasına olanak tanır.

Aşağıdaki PHP kodu ise Interface Segregation prensibini ihlal eden bir sınıf örneğidir.

interface PaymentInterface {
    public function processPayment();
    public function refundPayment();
    public function holdPayment();
    public function verifyPayment();
    public function processRefund();
    public function notifyUser();
}

class CreditCardPayment implements PaymentInterface {
    public function processPayment() {
        // Kredi kartı ödeme işlemi gerçekleştirme kodu
    }
    public function refundPayment() {
        // Kredi kartı geri ödeme işlemi gerçekleştirme kodu
    }
    public function holdPayment() {
        // Kredi kartı ödeme tutma işlemi gerçekleştirme kodu
    }
    public function verifyPayment() {
        // Ödeme doğrulama kodu
    }
    public function processRefund() {
        // Geri ödeme işlemi gerçekleştirme kodu
    }
    public function notifyUser() {
        // Kullanıcıya bildirim gönderme kodu
    }
}

Yukarıdaki örnekte, PaymentInterface adlı bir arayüz tanımlanmıştır ve bu arayüz “processPayment”, “refundPayment”, “holdPayment”, “verifyPayment”, “processRefund” ve “notifyUser” adlı altı method içerir.

Ancak CreditCardPayment sınıfı yalnızca “processPayment”, “refundPayment” ve “holdPayment” yöntemlerini kullanırken, PaymentInterface arabirimi de diğer üç yöntemi içermektedir. Bu arayüzün gereksiz yöntemler içerdiği anlamına gelir ve bu gereksiz kod karmaşasına neden olabilir ve gelecekteki değişiklikler için kod değişikliğinin daha zor olmasına neden olabilir.

GoLang’de Interface Segregation prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

package main

import "fmt"

type Payment interface {
    processPayment()
    refundPayment()
    holdPayment()
}

type CreditCardPayment struct{}

func (cc *CreditCardPayment) processPayment() {
    fmt.Println("Kredi kartı ödeme işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) refundPayment() {
    fmt.Println("Kredi kartı geri ödeme işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) holdPayment() {
    fmt.Println("Kredi kartı ödeme tutma işlemi gerçekleştirme kodu")
}

type PaypalPayment struct{}

func (pp *PaypalPayment) processPayment() {
    fmt.Println("PayPal ödeme işlemi gerçekleştirme kodu")
}

func (pp *PaypalPayment) refundPayment() {
    fmt.Println("PayPal geri ödeme işlemi gerçekleştirme kodu")
}

func (pp *PaypalPayment) holdPayment() {
    fmt.Println("PayPal ödeme tutma işlemi gerçekleştirme kodu")
}

Yukarıdaki örnekte Payment adlı bir arayüz tanımlanmıştır ve bu arayüz “processPayment”, “refundPayment” ve “holdPayment” adlı üç yöntem içermektedir. CreditCardPayment ve PaypalPayment adlı sınıflar, Payment arayüzünü uygulayarak bu yöntemleri kullanabilir.

Bu şekilde Payment arabirimi yalnızca ihtiyacımız olan üç yöntemi içerir ve bu yöntemler yalnızca bu arabirimi kullanan sınıflar tarafından kullanılır. Bu, arayüzün gereksiz yöntemler içermediği anlamına gelir ve bu da arabirimlerin özelleştirilmiş ve ihtiyaç duyulan yöntemleri içerecek şekilde tasarlanmasına olanak tanır.

PHP örneğine benzer şekilde, aşağıdaki GoLang kodu da Interface Segregation prensibini ihlal eden bir örnektir.

package main

import "fmt"

type Payment interface {
    processPayment()
    refundPayment()
    holdPayment()
    verifyPayment()
    processRefund()
    notifyUser()
}

type CreditCardPayment struct{}

func (cc *CreditCardPayment) processPayment() {
    fmt.Println("Kredi kartı ödeme işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) refundPayment() {
    fmt.Println("Kredi kartı geri ödeme işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) holdPayment() {
    fmt.Println("Kredi kartı ödeme tutma işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) verifyPayment() {
    fmt.Println("Ödeme doğrulama kodu")
}

func (cc *CreditCardPayment) processRefund() {
    fmt.Println("Geri ödeme işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) notifyUser() {
    fmt.Println("Kullanıcıya bildirim gönderme kodu")
}

Yukarıdaki örnekte Payment adlı bir arayz tanımlanmıştır ve bu arayüz “processPayment”, “refundPayment”, “holdPayment”, “verifyPayment”, “processRefund” ve “notifyUser” adlı altı methodları içermektedir.

Ancak,CreditCardPayment sınıfı yalnızca “processPayment”, “refundPayment” ve “holdPayment” yöntemlerini kullanırken, Payment arabirimi de diğer üç yöntemi içermektedir. Bu, arayüzün gereksiz yöntemler içerdiği anlamına gelir ve bu, gereksiz kod karmaşasına neden olabilir ve gelecekteki değişiklikler için kod değişikliğinin daha zor olmasına neden olabilir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Dijkstra’nın Tek Kaynaklı En Kısa Yol Algoritması

Thu, 14 Apr 2022 00:00:00 GMT

Dijkstra’nın tek kaynaklı en kısa yol algoritması, bir graf üzerinde bir başlangıç noktasından diğer tüm noktalara olabilecek en kısa yolları bulmaya yönelik bir algoritmadır. Bu algoritma belli bir süre içinde tüm noktalar arasında en kısa yolu bulmak için kullanılır.

Algoritmanın çalışma prensibi şu şekildedir:

Başlangıç noktasının mesafesi 0 olarak belirlenir ve diğer tüm noktaların mesafesi INF (yani sonsuz) olarak ayarlanır.
Graf üzerindeki tüm noktalar dolaşılır ve mesafesi olmayan (INF) en kısa nokta bulunur. Bu nokta ziyaret edilir ve mesafesi güncellenir.
Ziyaret edilen noktanın bağlı olduğu diğer noktaların mesafeleri de güncellenir. Örneğin eğer ziyaret edilen noktanın mesafesi X ise ve bu noktaya bağlı bir diğer noktaya Y mesafesi var ise bu diğer noktanın mesafesi X+Y olur.
Bu adım tekrar edilir ve en kısa mesafesi olmayan nokta ziyaret edilir ve mesafesi güncellenir. Bu adım tüm noktalar ziyaret edilene kadar devam eder.

Algoritma böylece tüm noktalar arasındaki en kısa yolu bulur.

Dijkstra algoritmasının önemli bir zayıf yönü bulunmaktadır, negatif ağırlıklı çizgileri işlemez. Dijkstra algoritması, ağırlıklı çizgilerin ağırlıklarının negatif olmadığını varsayar. Bu nedenle negatif ağırlıklı çizgileri işlemez ve doğru sonuçlar vermez.

GoLang’de algoritmanın kodu şu şekildedir:

package main

import "fmt"

const INF = int(^uint(0) >> 1)

type Graph [][]int

func dijkstra(g Graph, source int) []int {
	distances := make([]int, len(g))
	for i := range distances {
		distances[i] = INF
	}
	distances[source] = 0

	visited := make([]bool, len(g))

	for i := 0; i < len(g); i++ {
		minDistance := INF
		var minNode int
		for j := range g {
			if !visited[j] && distances[j] < minDistance {
				minDistance = distances[j]
				minNode = j
			}
		}
		visited[minNode] = true

		for j, cost := range g[minNode] {
			if cost != 0 {
				if minDistance+cost < distances[j] {
					distances[j] = minDistance + cost
				}
			}
		}
	}

	return distances
}

func main() {
	g := Graph{
		{0, 3, 0, 2, 0},
		{3, 0, 5, 0, 6},
		{0, 5, 0, 4, 0},
		{2, 0, 4, 0, 1},
		{0, 6, 0, 1, 0},
	}
	distances := dijkstra(g, 0)
	fmt.Println(distances)
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

> go run main.go                   
[0 3 6 2 3]

PHP’de algoritmanın kodu şu şekildedir:

<?php

const INF = PHP_INT_MAX;

$graph = [
    [0, 3, 0, 2, 0],
    [3, 0, 5, 0, 6],
    [0, 5, 0, 4, 0],
    [2, 0, 4, 0, 1],
    [0, 6, 0, 1, 0],
];

$source = 0;
$distances = array_fill(0, count($graph), INF);
$distances[$source] = 0;

$visited = array_fill(0, count($graph), false);

for ($i = 0; $i < count($graph); $i++) {
    $minDistance = INF;
    $minNode = -1;
    for ($j = 0; $j < count($graph); $j++) {
        if (!$visited[$j] && $distances[$j] < $minDistance) {
            $minDistance = $distances[$j];
            $minNode = $j;
        }
    }
    $visited[$minNode] = true;

    for ($j = 0; $j < count($graph); $j++) {
        if ($graph[$minNode][$j] != 0) {
            if ($minDistance + $graph[$minNode][$j] < $distances[$j]) {
                $distances[$j] = $minDistance + $graph[$minNode][$j];
            }
        }
    }
}

print_r($distances);

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

GoLang'de Mutable ve Immutable Veri Tipleri

Fri, 14 Jan 2022 00:00:00 GMT

Mutable Veri Tipleri

Golang dilinde mutable veri tipleri değiştirilebilir ve değiştirilmesine izin verilen veriler için kullanılır. Bu veri tipleri, verilerin daha dinamik bir şekilde manipüle edilebilmesini sağlar ve programların esnekliğini arttırır.

Mutable (değişebilir) veri tipleri, programı başlatma sırasında atanan belleğin herhangi bir parçasını yeniden tahsis (reallocating) etmeden değiştirilebilen bir veri türüdür. Basit bir ifadeyle, bir değişken, kendisini yeni bir bellek alanına yeniden tahsis etmeden değeri değiştirilebiliyorsa değişkendir (mutable).

Mutable veri tipinde bir bellek adresinde bulunan değer değiştirilebilir. Bu değişkenin değerini değiştirmek için herhangi bir belleği yeniden tahsis etmemiz veya bir değişkenin işaretçisini başka bir adresi gösterecek şekilde değiştirmemiz gerekmediği anlamına gelir.

someNumber := 15
// someNumber değeri 15'dir ve bir hafıza adreslerinde depolanır. Örnek: 0x12212

someNumber = 18
// Veri tipi değişebilir ise, hafıza adresindeki değeri doğrudan değiştirebiliriz.
// someNumber değişkeninin işaret ettiği hafıza adresi değişmedi.

fmt.Println(someNumber)  // 18

Golang’de birkaç değiştirilebilir veri türü vardır:

Array
Slice
Map
Channels

Immutable Veri Tipleri

Golang dilinde immutable veri tipleri değiştirilemez ve değiştirilmemesi gereken veriler için kullanılır. Bu veri tipleri, programların güvenilirliğini ve anlaşılırlığını arttırmak için kullanılır çünkü değiştirilemezler ve bu nedenle programın çalışma şeklinin anlaşılması kolaylaşır.

Immutable (değişmez) veri tipi yeni bir bellek tahsis edilmeden değiştirilemeyen bir veri türüdür. Bu nedenle Immutable veri türü, bir değişkenin değerinde değişiklik yapmak için belleği yeniden tahsis etmelidir. Değişken büyük bir değer kümesi tutuyorsa bu bir dezavantaj olabilir çünkü değerde küçük bir değişiklik için çok fazla bellek yeniden tahsisi gerektirecektir.

Immutable veri tipleri ayrıca değişkenin işaret ettiği bellek adresindeki değeri değiştiremeyeceğiniz ancak bir değişkenin içeriğini değiştirmek için değişkenin farklı bir bellek konumuna işaret etmesini sağlayabileceğiniz anlamına da gelir.

city := "Ankara"
// "Ankara" değeri bir bellek konumunda depolanır. Örnek: 0x12212

city = "New York"
// "New York" değeri, 0x85574 gibi farklı bir bellek konumunda yer alacaktır.

// city değişkeninin işaret ettiği hafıza adresi değiştirilir, hafıza adresinin değeri değil.

Golang’de birkaç değiştirilebilir veri türü vardır.

String
Boolean, Int, Float
Pointers
Interfaces

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

SOLID - Liskov Substitution Principle

Mon, 15 Nov 2021 00:00:00 GMT

Liskov Substitution Prensibi (LSP), Barbara Liskov tarafından geliştirilen bir kalıtım prensibi olup, bu prensip, bir sınıfın kalıtım ağacındaki bir alt sınıfın yerine, yüksek seviye bir sınıfın kullanılmasının mümkün olmasını sağlar. Bu prensibe göre, alt sınıfların, yüksek seviye sınıfların yerine kullanılabilmeleri için alt sınıfların aynı özellik ve davranışlara sahip olabilmeleri gerekir.

Alt sınıflardan oluşan nesnelerin, üst sınıfın nesneleri ile yer değiştirdikleri zaman, aynı davranışı sergilemesi gerekmektedir.

PHP’de, Liskov Substitution prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

<?php
// Parent sınıfı
class Vehicle {
  protected $model;

  public function setModel($model) {
    $this->model = $model;
  }
}

// Child sınıfı
class Car extends Vehicle {
  public function getModel() {
    return "The model of this car is: " . $this->model;
  }
}

// Child sınıfı
class Bicycle extends Vehicle {
  public function getModel() {
    return "The model of this bicycle is: " . $this->model;
  }
}

// Parent sınıfının yerine kullanılabilecek bir child sınıfı
class ElectricCar extends Car {
  public function getModel() {
    return "This car is electric. " . parent::getModel();
  }
}

// Örnek oluşturma
$electricCar = new ElectricCar();
$electricCar->setModel("Tesla Model 3");

echo $electricCar->getModel(); // "This car is electric. The model of this car is: Tesla Model 3"

Bu örnekte, Vehicle sınıfı bir parent sınıf olup, Car ve Bicycle sınıfları ise bu sınıfın child sınıflarıdır. ElectricCar sınıfı ise Car sınıfının bir alt sınıfıdır. ElectricCar sınıfı, Vehicle sınıfının yerine geçebilir ve bu nedenle Vehicle sınıfına ait herhangi bir kodu ElectricCar sınıfına uygulayabiliriz. Bu Liskov Substitution prensibinin temelini oluşturur.

Aşağıdaki PHP kodu ise Liskov Substitution prensibini ihlal eden bir sınıf örneğidir.

<?php
// Parent sınıfı
class Vehicle {
  protected $model;

  public function setModel($model) {
    $this->model = $model;
  }
}

// Child sınıfı
class Car extends Vehicle {
  public function getModel() {
    return "The model of this car is: " . $this->model;
  }
}

// Child sınıfı
class Bicycle extends Vehicle {
  public function getModel() {
    return "The model of this bicycle is: " . $this->model;
  }
}

// Parent sınıfının yerine kullanılamayacak bir child sınıfı
class ElectricCar extends Car {
  private $batteryType;

  public function __construct($batteryType) {
    $this->batteryType = $batteryType;
  }

  public function getModel() {
    return "This electric car uses a " . $this->batteryType . " battery. " . parent::getModel();
  }
}

// Örnek oluşturma
$electricCar = new ElectricCar("lithium-ion");
$electricCar->setModel("Tesla Model 3");

echo $electricCar->getModel(); // "This electric car uses a lithium-ion battery. The model of this car is: Tesla Model 3"

// Hata: Vehicle sınıfının yerine ElectricCar sınıfı kullanılamaz
$vehicle = new Vehicle();
$vehicle = $electricCar; // Hata: "Cannot assign an ElectricCar instance to a Vehicle variable"

Bu örnekte, ElectricCar sınıfı Car sınıfının bir alt sınıfıdır ve Vehicle sınıfının yerine geçebilir. Ancak, ElectricCar sınıfının bir batteryType özelliği vardır ve bu özellik, Vehicle sınıfında bulunmamaktadır. Bu nedenle Vehicle sınıfının yerine ElectricCar sınıfını kullanılamaz. Bu Liskov Substitution prensibinin ihlal edildiğini gösterir.

GoLang’de Liskov Substitution prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

package main

import "fmt"

// Parent interface
type Vehicle interface {
  SetModel(model string)
}

// Child struct
type Car struct {
  model string
}

func (c *Car) SetModel(model string) {
  c.model = model
}

func (c *Car) GetModel() string {
  return fmt.Sprintf("The model of this car is: %s", c.model)
}

// Child struct
type Bicycle struct {
  model string
}

func (b *Bicycle) SetModel(model string) {
  b.model = model
}

func (b *Bicycle) GetModel() string {
  return fmt.Sprintf("The model of this bicycle is: %s", b.model)
}

// Parent interface'in yerine kullanılabilecek child struct
type ElectricCar struct {
  Car
}

func (e *ElectricCar) GetModel() string {
  return fmt.Sprintf("This car is electric. %s", e.Car.GetModel())
}

func main() {
  // Örnek oluşturma
  electricCar := ElectricCar{}
  electricCar.SetModel("Tesla Model 3")

  fmt.Println(electricCar.GetModel()) // "This car is electric. The model of this car is: Tesla Model 3"

  // Parent interface'in yerine ElectricCar struct'ı kullanılabilir
  var vehicle Vehicle = &electricCar
  fmt.Println(vehicle.GetModel()) // "This car is electric. The model of this car is: Tesla Model 3"
}

Bu örnekte Vehicle interface’i bir parent interface olup, Car ve Bicycle struct’ları bu interface’i implement eden child struct’lardır. ElectricCar struct’ı ise Car struct’ının bir alt struct’ıdır. ElectricCar struct’ı, Vehicle interface’inin yerine geçebilir ve bu nedenle Vehicle interface’ine ait herhangi bir kodu,ElectricCar struct’ına uygulayabiliriz.

PHP örneğine benzer şekilde, aşağıdaki GoLang kodu da Liskov Substitution prensibini ihlal eden bir örnektir.

package main

import "fmt"

// Parent interface
type Vehicle interface {
  SetModel(model string)
  GetModel() string
}

// Child struct
type Car struct {
  model string
}

func (c *Car) SetModel(model string) {
  c.model = model
}

func (c *Car) GetModel() string {
  return fmt.Sprintf("The model of this car is: %s", c.model)
}

// Child struct
type Bicycle struct {
  model string
}

func (b *Bicycle) SetModel(model string) {
  b.model = model
}

func (b *Bicycle) GetModel() string {
  return fmt.Sprintf("The model of this bicycle is: %s", b.model)
}

// Parent interface'in yerine kullanılamayacak child struct
type ElectricCar struct {
  Car
}

func (e *ElectricCar) GetModel() string {
  return fmt.Sprintf("This car is electric. %s", e.Car.GetModel())
}

// ElectricCar'ın yerine geçemeyecek bir metod
func (e *ElectricCar) Charge() {
  fmt.Println("Charging the electric car...")
}

func main() {
  // Örnek oluşturma
  electricCar := ElectricCar{}
  electricCar.SetModel("Tesla Model 3")

  fmt.Println(electricCar.GetModel()) // "This car is electric. The model of this car is: Tesla Model 3"

  // Hata: Vehicle interface'inin yerine ElectricCar struct'ı kullanılamaz
  var vehicle Vehicle = &electricCar // Hata: "ElectricCar does not implement Vehicle (missing Charge method)"
}

Bu örnekte de ElectricCar struct’ı Car struct’ının bir alt struct’ıdır ve Vehicle interface’inin yerine geçebilir. Ancak ElectricCar struct’ının bir Charge() metodu vardır ve bu metod Vehicle interface’inde bulunmamaktadır. Bu nedenle Vehicle interface’inin yerine ElectricCar struct’ı kullanılamayacaktır.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

GoLang'de Array ve Slice Arasındaki Farklar

Sat, 09 Oct 2021 00:00:00 GMT

Array

Array (dizi) veri tipi, bir dizi elemanın aynı veri tipinden olduğu, sabit uzunluklu bir veri yapısıdır. Arrayler tanımlanırken eleman sayısı ve her elemanın veri tipi belirtilir. Örneğin aşağıdaki kod bloğunda “int” veri tipinde bir array oluşturulmuştur ve bu arrayin elemanları 0 ile 9 arasında değişen 10 tane sayıdır:

package main

import "fmt"

func main() {
    var a [10]int
    for i := 0; i < 10; i++ {
        a[i] = i
    }
    fmt.Println(a)  // Output: [0 1 2 3 4 5 6 7 8 9]
}

Aşağıdaki örnekte ise array’e yeni bir veri eklenmeye çalışılmaktadır. Bu durumda çalışma zamanı hatası oluşacaktır.

package main

import "fmt"

func main() {
    a := [5]int{1, 2, 3, 4, 5}

    a[5] = 6  // This line will cause a runtime error

    fmt.Println(a)  // This line will not be executed
}

Hata:

invalid argument: index 5 out of bounds [0:5]

Slice

Slice (dilim) veri tipi ise arraylerden farklı olarak sabit uzunluklu olmayan, dinamik uzunluklu bir veri yapısıdır. Slice’lar tanımlanırken eleman sayısı belirtilmez.

Slice’lar daha esnek ve kullanışlı olmaları nedeniyle arraylerden daha sık kullanılır. Örneğin slice’lar üzerinde dinamik olarak eleman ekleyebilir, silebilir veya değiştirebiliriz.

Aşağıda bir slice oluşturma ve bu slice’a yeni bir eleman ekleme örneği görülmektedir.

package main

import "fmt"

func main() {
    // Create a slice with the shorthand syntax
    a := []int{1, 2, 3, 4, 5}

    // Add a new element to the slice
    a = append(a, 6)

    // Print the slice
    fmt.Println(a)  // Output: [1 2 3 4 5 6]
}

Ayrıca slice’ları bir array üzerinden oluşturduğumuzda, oluşturduğumuz slice ile orjinal array arasında bir bağlantı oluşur ve slice üzerinde yaptığımız değişiklikler orjinal array’e de yansır.

package main

import "fmt"

func main() {
    a := [10]int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
    b := a[0:3]
    b = append(b, 10)
    fmt.Println(a)  // Output: [0 1 2 3 4 5 6 7 8 9 10]
    fmt.Println(b)  // Output: [0 1 2 10]
}

Slice’ların bir diğer avantajı ise “make” fonksiyonu ile oluşturulabiliyor olmalarıdır. “make” fonksiyonu ile oluşturulan slice’lar, belirtilen eleman sayısı kadar yer ayırır ve slice’ın elemanları varsayılan değerleri alır. Örneğin, aşağıdaki kod bloğunda “int” veri tipinde bir slice oluşturulmuş ve bu slice’ın elemanları 0 değerini almıştır:

package main

import "fmt"

func main() {
    a := make([]int, 5)
    fmt.Println(a)  // Output: [0 0 0 0 0]
}

Slice’lar “make” fonksiyonu ile oluşturulurken 3. bir parametre de verilebilir ve bu parametre slice’ın “capacity” özelliğini belirler. Örneğin, aşağıdaki kod bloğunda “b” isimli slice’ı “make” fonksiyonu ile oluştururken “capacity” özelliğini 10 olarak belirttik:

package main

import "fmt"

func main() {
    // Create a slice with make function
    b := make([]int, 5, 10)  // Creates a slice with 5 elements and capacity 10
    b[0] = 1
    b[1] = 2
    b[2] = 3
    b[3] = 4
    b[4] = 5

    // Print the slice and its capacity
    fmt.Println(b)        // Output: [1 2 3 4 5]
    fmt.Println(len(b))   // Output: 5
    fmt.Println(cap(b))   // Output: 10
}

Bir slice’ın uzunluğu o anda dilimde bulunan öğelerin sayısı ifade ederken, kapasite ise slice’ın yeniden memory tahsis (reallocated) edilmeye ihtiyaç duymadan önce tutabileceği öğelerin sayısını ifade eder.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

SOLID - Open Closed Principle

Thu, 26 Aug 2021 00:00:00 GMT

Open-closed prensibi, bir sınıfın işlevselliğini genişletmek için değiştirilmemesi, ancak yeni işlevsellik eklemek için yeni sınıflar oluşturulması gerektiğini öngören bir programlama prensibidir. Bu prensip, programlarımızın daha esnek, bütünleşik ve bakımı daha kolay olmasını sağlar.

Örnek olarak, bir sınıfın bir alt sınıfı olabilmesi için, alt sınıfın yüksek sınıfın yapabildiklerini yapması gerekir. Ayrıca, alt sınıfın yüksek sınıfın yapabildiklerini yapmasının yanı sıra, kendi ek işlevselliğini de içermesi gerekir. Bu sayede, alt sınıf yüksek sınıfın yerine kullanılabilir ve aynı zamanda yüksek sınıfın yapabildiklerini aşarak kendi işlevselliğini de sunabilir.

PHP’de, Open-closed prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

interface Shape {
  public function calculateArea();
}

class Circle implements Shape {
  private $radius;

  public function __construct($radius) {
    $this->radius = $radius;
  }

  public function calculateArea() {
    return pi() * pow($this->radius, 2);
  }
}

class Rectangle implements Shape {
  private $width;
  private $height;

  public function __construct($width, $height) {
    $this->width = $width;
    $this->height = $height;
  }

  public function calculateArea() {
    return $this->width * $this->height;
  }
}

class AreaCalculator {
  private $shapes;

  public function __construct($shapes = array()) {
    $this->shapes = $shapes;
  }

  public function sum() {
    $area = 0;

    foreach ($this->shapes as $shape) {
      $area += $shape->calculateArea();
    }

    return $area;
  }
}

Bu kod örneğinde, Shape arayüzü bir şeklin alanını hesaplayabilecek bir metodu tanımlar. Circle ve Rectangle sınıfları bu arayüzü uygular ve calculateArea() metodunu kendi içlerinde tanımlar. Bu sayede, daha sonra farklı şekiller eklenmesi gerektiğinde bu sınıfları değiştirmeye gerek kalmaz, sadece Shape arayüzünü uygulayan yeni bir sınıf oluşturulur. AreaCalculator sınıfı da Shape nesnelerinin alanlarını toplamak için kullanılabilir.

Aşağıdaki PHP kodu ise Open-closed prensibini ihlal eden bir sınıf örneğidir.

interface Shape {
  public function calculateArea();
}

class Triangle {
  private $base;
  private $height;

  public function __construct($base, $height) {
    $this->base = $base;
    $this->height = $height;
  }
}

class Circle implements Shape {
  private $radius;

  public function __construct($radius) {
    $this->radius = $radius;
  }

  public function calculateArea() {
    return pi() * pow($this->radius, 2);
  }
}

class Rectangle implements Shape {
  private $width;
  private $height;

  public function __construct($width, $height) {
    $this->width = $width;
    $this->height = $height;
  }

  public function calculateArea() {
    return $this->width * $this->height;
  }
}

class AreaCalculator {
  private $shapes;

  public function __construct($shapes = array()) {
    $this->shapes = $shapes;
  }

  public function sum() {
    $area = 0;

    foreach ($this->shapes as $shape) {
      if ($shape instanceof Circle) {
        $area += return 0.5 * $shape->base * $shape->height;
      } else {
        $area += $shape->calculateArea();
      }
    }

    return $area;
  }
}

Bu kod örneğinde, Circle ve Rectangle sınıfları calculateArea() metodunu kendi içlerinde tanımlar, ancak bu metodlar sadece belirli bir şeklin alanını hesaplar. Eğer farklı bir şekil yukarıdaki gibi eklenirse Open-closed prensibi ihlal edilmiş olur. Triangle sınıfı Shape interface’ini implement etmemiş, kendi calculateArea() metodunu tanımlamamıştır. Bu durumda da AreaCalculator sınıfının sum() methoduna ekleme yapmak gerekmiştir. Bu da OCP’yi ihlal eder çünkü AreaCalculator sınıfı değiştirilmiştir.

GoLang’de, Open-closed prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

type Shape interface {
  CalculateArea() float64
}

type Circle struct {
  radius float64
}

func (c *Circle) CalculateArea() float64 {
  return math.Pi * math.Pow(c.radius, 2)
}

type Rectangle struct {
  width  float64
  height float64
}

func (r *Rectangle) CalculateArea() float64 {
  return r.width * r.height
}

type AreaCalculator struct {
  shapes []Shape
}

func (a *AreaCalculator) Sum() float64 {
  var area float64
  for _, shape := range a.shapes {
    area += shape.CalculateArea()
  }
  return area
}

Bu kod örneğinde, Shape tipi bir şeklin alanını hesaplayabilecek bir metodu tanımlar. Circle ve Rectangle tipleri bu tipi uygular ve CalculateArea() metodunu kendi içlerinde tanımlarlar. Bu sayede, daha sonra farklı şekiller eklenmesi gerektiğinde bu tipleri değiştirmeye gerek kalmaz, sadece Shape tipini uygulayan yeni bir tip oluşturulur. AreaCalculator tipi de Shape nesnelerinin alanlarını toplamak için kullanılabilir.

PHP örneğine benzer şekilde, aşağıdaki GoLang kodu da Open-closed prensibini ihlal eden bir örnektir.

type Circle struct {
  radius float64
}

func (c *Circle) CalculateArea() float64 {
  return math.Pi * math.Pow(c.radius, 2)
}

type Rectangle struct {
  width  float64
  height float64
}

func (r *Rectangle) CalculateArea() float64 {
  return r.width * r.height
}

type AreaCalculator struct {
  shapes []interface{}
}

func (a *AreaCalculator) Sum() float64 {
  var area float64
  for _, shape := range a.shapes {
    switch v := shape.(type) {
    case Circle:
      area += math.Pi * math.Pow(v.radius, 2)
    case Rectangle:
      area += v.width * v.height
    }
  }
  return area
}

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Tic-Tac-Toe Oyunu GoLang Implementasyonu

Wed, 23 Jun 2021 00:00:00 GMT

Tic-Tac-Toe (bazen X ve O olarak da bilinir), iki oyuncunun kendi sembollerini (X ve O) kullanarak, 3x3’lük tahtada bir satır, sütun veya diagonal çizmeye çalıştığı bir oyundur.

Oyuncular sırayla hamle yaparlar ve kendi sembollerini yatay, dikey ya da çağraz olarak sıralamaya çalışırlar. Sıralayabilen oyunu kazanır ya da oyun berabere sonuçlanır :)

GoLang’de tic-tak-toe oyununun konsol üzerinden iki kişi tarafından oynanmasını sağlayan kod aşağıdadır:

package main

import (
	"bufio"
	"fmt"
	"os"
	"strconv"
	"strings"
)

const (
	empty = " "
	x     = "X"
	o     = "O"
)

type game struct {
	board [][]string
}

// newGame oluşturulan bir game nesnesi döndürür.
func newGame() *game {
	g := &game{}
	g.board = make([][]string, 3)

	for i := range g.board {
		g.board[i] = make([]string, 3)
		for j := range g.board[i] {
			g.board[i][j] = empty
		}
	}

	return g
}

// playMove bir oyuncunun tahtada yapacağı hamleyi yapar.
func (g *game) playMove(x, y int, player string) error {

	if x < 0 || x > 2 || y < 0 || y > 2 {
		return fmt.Errorf("Invalid move")
	}

	if g.board[x][y] != empty {
		return fmt.Errorf("That space is already taken")
	}

	g.board[x][y] = player
	return nil
}

// drawBoard tahtayı çizmek için kullanılır.
func (g *game) drawBoard() {
	fmt.Println("  0 1 2")
	for i, row := range g.board {
		fmt.Printf("%d ", i)
		fmt.Println(strings.Join(row, "|"))
	}
}

// checkWin kazananın olup olmadığını kontrol eder.
func (g *game) checkWin() string {
	// Check rows
	for _, row := range g.board {
		if row[0] != empty && row[0] == row[1] && row[1] == row[2] {
			return row[0]
		}
	}

	// Check columns
	for i := 0; i < 3; i++ {
		if g.board[0][i] != empty && g.board[0][i] == g.board[1][i] && g.board[1][i] == g.board[2][i] {
			return g.board[0][i]
		}
	}

	// Check diagonals
	if g.board[0][0] != empty && g.board[0][0] == g.board[1][1] && g.board[1][1] == g.board[2][2] {
		return g.board[0][0]
	}

	if g.board[0][2] != empty && g.board[0][2] == g.board[1][1] && g.board[1][1] == g.board[2][0] {
		return g.board[0][2]
	}

	return empty
}

func main() {
	g := newGame()
	reader := bufio.NewReader(os.Stdin)

	fmt.Println("Welcome to Tic-Tac-Toe!")
	fmt.Println("Player 1 is X and Player 2 is O")
	fmt.Println("Enter your moves in the format 'x y' (without quotes)")

	for i := 0; i < 9; i++ {
		player := x

		if i%2 == 1 {
			player = o
		}

		fmt.Printf("Player %s's turn: ", player)
		text, _ := reader.ReadString('\n')
		text = strings.TrimSpace(text)
		parts := strings.Split(text, " ")

		if len(parts) != 2 {
			fmt.Println("Invalid input")
			i--
			continue
		}

		x, err := strconv.Atoi(parts[0])
		if err != nil {
			fmt.Println("Invalid input")
			i--
			continue
		}

		y, err := strconv.Atoi(parts[1])
		if err != nil {
			fmt.Println("Invalid input")
			i--
			continue
		}

		err = g.playMove(x, y, player)
		if err != nil {
			fmt.Println(err)
			i--
			continue
		}

		g.drawBoard()

		winner := g.checkWin()
		if winner != empty {
			fmt.Printf("Player %s wins!\n", winner)
			break
		}
	}

	if g.checkWin() == empty {
		fmt.Println("It's a draw!")
	}
}

Program çalıştırıldığında aşağıdaki gibi bir çıktı verecektir. Oyuncular hamlelerini yapmak için konsola koordinatları girerler. Örneğin, bir oyuncu (X) tahtadaki (0, 1) noktasına hamle yapmak isterse, “0 1” (boşluklu ve tırnaksız) şeklinde bir girdi yapar. Tahta güncellenir ve sıradaki oyuncu hamle yapmaya çalışır. Oyun devam eder ve eğer bir oyuncu üç sembolünü tahtada çizerek kazanırsa veya tüm kareler dolup oyun berabere biterse oyun sona erer.

Örnek oyun

> go run main.go                   
Welcome to Tic-Tac-Toe!
Player 1 is X and Player 2 is O
Enter your moves in the format 'x y' (without quotes)

Player X's turn: 0 1
  0 1 2
0  |X| 
1  | | 
2  | | 

Player O's turn: 1 1
  0 1 2
0  |X| 
1  |O| 
2  | | 

Player X's turn: 2 0
  0 1 2
0  |X| 
1  |O| 
2 X| | 

Player O's turn: 0 0
  0 1 2
0 O|X| 
1  |O| 
2 X| | 

Player X's turn: 2 1
  0 1 2
0 O|X| 
1  |O| 
2 X|X| 

Player O's turn: 2 2
  0 1 2
0 O|X| 
1  |O| 
2 X|X|O

Player O wins!

Kaynaklar

https://en.wikipedia.org/wiki/Tic-tac-toe

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

SOLID - Single-Responsibility Principle

Tue, 25 May 2021 00:00:00 GMT

Single-responsibility prensibi, bir sınıfın veya fonksiyonun sadece bir görevi olması gerektiğini öngören bir programlama prensibidir. Bu prensip, programlarımızın daha az hata olasılığına sahip, daha kolay anlaşılabilir ve bakımının daha kolay olmasını sağlar.

Eğer geliştirdiğimiz sınıf ya da fonksiyon birden fazla amaca hizmet ediyorsa, bu kurala aykırı bir geliştirme sürecinde olduğumuz anlamına geliyor. Bunu farkettiğimizde amaçlara uygun olarak parçalamanız gerekmektedir.

Örnek olarak, bir sınıfın sadece bir veritabanı erişim nesnesi olması gerektiğini düşünelim. Bu sınıfın sadece veritabanına erişim ile ilgili işlevsellikleri içermesi gerekir. Örneğin veritabanına kayıt ekleme, veritabanından veri okuma gibi. Bu sınıfın, veritabanına erişim dışındaki herhangi bir işlevselliği içermemesi gerekir.

PHP’de, Single-responsibility prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

<?php

// Sadece veritabanı erişim nesnesi olan bir sınıf
class Database {
  public function connect() {
    // Veritabanına bağlanma
  }

  public function insert() {
    // Veritabanına kayıt ekleme
  }

  public function select() {
    // Veritabanından veri okuma
  }
}

$db = new Database();
$db->connect();  // Veritabanına bağlanır
$db->insert();  // Veritabanına kayıt ekler
$db->select();  // Veritabanından veri okur

Bu örnekte, Database sınıfı sadece veritabanına erişim ile ilgili işlevsellik içermektedir ve diğer işlevsellikleri içermemektedir. Bu nedenle, Database sınıfı Single-responsibility prensibini uygulamaktadır.

Aşağıdaki PHP kodu ise Single-responsibility prensibini ihlal eden bir sınıf örneğidir.

<?php

// Veritabanı erişim ve veri işleme işlevselliğini içeren bir sınıf
class Database {
  public function connect() {
    // Veritabanına bağlanma
  }

  public function insert() {
    // Veritabanına kayıt ekleme
  }

  public function select() {
    // Veritabanından veri okuma
  }

  public function processData() {
    // Verileri işleme
  }
}

$db = new Database();
$db->connect();  // Veritabanına bağlanır
$db->insert();  // Veritabanına kayıt ekler
$db->select();  // Veritabanından veri okur
$db->processData();  // Verileri işler

Bu örnekte, Database sınıfı hem veritabanı erişim işlevselliğini hem de veri işleme işlevselliğini içermektedir. Bu nedenle, Database sınıfı Single-responsibility prensibini ihlal etmektedir.

GoLang’de Single-responsibility prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

// Sadece veritabanı erişim nesnesi olan bir sınıf
type Database struct {}

// Veritabanına erişim işlevselliği
func (d *Database) Connect() {
  // Veritabanına bağlanma
}

func (d *Database) Insert() {
  // Veritabanına kayıt ekleme
}

func (d *Database) Select() {
  // Veritabanından veri okuma
}

db := &Database{}
db.Connect()  // Veritabanına bağlanır
db.Insert()  // Veritabanına kayıt ekler
db.Select()  // Veritabanından veri okur

Bu örnekte de Database sınıfı sadece veritabanına erişim ile ilgili işlevsellik içermektedir ve diğer işlevsellikleri içermemektedir. Bu nedenle, Database sınıfı Single-responsibility principle’ını uygulamaktadır.

PHP örneğine benzer şekilde, aşağıdaki GoLang kodu da Single-responsibility prensibini ihlal eden bir örnektir.

// Veritabanı erişim ve veri işleme işlevselliğini içeren bir sınıf
type Database struct {}

// Veritabanına erişim işlevselliği
func (d *Database) Connect() {
  // Veritabanına bağlanma
}

func (d *Database) Insert() {
  // Veritabanına kayıt ekleme
}

func (d *Database) Select() {
  // Veritabanından veri okuma
}

// Veri işleme işlevselliği
func (d *Database) ProcessData() {
  // Verileri işleme
}

db := &Database{}
db.Connect()  // Veritabanına bağlanır
db.Insert()  // Veritabanına kayıt ekler
db.Select()  // Veritabanından veri okur
db.ProcessData()  // Verileri işler

Bu örnekte de Database sınıfı hem veritabanı erişim işlevselliğini hem de veri işleme işlevselliğini içermektedir. Bu nedenle, Database sınıfı Single-responsibility prensibini ihlal etmektedir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

VirtualHost'ta Reverse Proxy ve Basit Authentication

Thu, 11 Mar 2021 00:00:00 GMT

Bir web sunucusu kurarken, genellikle erişimi kısıtlamak istediğimiz bölümler vardır. Web uygulamaları genellikle kendi kimlik doğrulama ve yetkilendirme yöntemlerini sağlarlar ancak bazı durumlarda web sunucusunun kendisi aracılığıyla erişimi kısıtlamak isteyebiliriz.

Reverse Proxy ihtiyacımız ise web sunucusunda çalışan bir servisi dış dünyaya açmak istediğimizde karşımıza çıkmaktadır. Örneğin 3100 prtunda çalışan bir servisiniz var ve bu servise servis.example.com aracılığı ile erişmek istiyorsunuz. Bu durumda bir yönlendiriciye ihtiyacınız olacaktır.

Bu yazıda ben VirtualHost kullanan bir web sunucusunda Reverse Proxy işleminin nasıl yapılacağını ve şifre korumasının nasıl uygulanabileceğini göstereceğim.

Parola Dosyasını Oluşturma

Öncelikle erişim iznine sahip olacak kullanıcı adlarının ve şifrelerinin sisteme tanıtılması gerekmektedir. Bunun için htpasswd komutuna ihtiyacımız var.

Eğer htpasswd sisteminizde kurulu değilse aşağıdaki şekilde kurulumunu sağlayabilirsiniz. Ben yum paket yöneticisini kullanıyorum. Sisteminize uygun kurulumu kısa bir araştırma ile kolayca bulabilirsiniz.

yum provides \*bin/htpasswd
ya da
yum install httpd-tools

Komut sistemimizde olduğuna göre artık şifreleri oluşturabiliriz. Bunun için sistemimizin /etc/httpd dizininde .htpasswd adında gizli bir dosya oluşturacağız.

Henüz ilk defa htpasswd kullanacağımızdan dolayı belirtilen dosyayı oluşturmak için -c seçeneğini eklememiz gerekir. Dosya içinde yeni bir girdi oluşturmak için komutun sonunda bir kullanıcı adı (bu örnekte admin) belirtiyoruz:

sudo htpasswd -c /etc/httpd/.htpasswd admin

Bu komutu çalıştırdıktan sonra sistem sizden bir parola isteyecektir. Parolanızı iki defa girdikten sonra admin kullanıcısı için şifre tanımlanmış olacaktır.

Bundan sonra başka kullanıcı eklemek isterseniz -c komutunu kullanmanıza gerek yok.

sudo htpasswd /etc/httpd/.htpasswd another_user

Dosyanın içeriğini görüntülersek, her kayıt için kullanıcı adını ve şifrelenmiş parolayı görebiliriz:

cat /etc/httpd/.htpasswd

Output
admin:$apr1$lzxsIfXG$tmCvCfb49vpPFwKGVsuYz.
another_user:$apr1$p1E9MeAf$kiAhneUwr.MhAE2kKGYHK.

VirtualHost Basit Giriş Tanımlama

Şifre ile giriş ekleyecepğimiz virtualhost config dosyasını açalım. Benim örneğimde bu dosya /etc/httpd/conf/httpd.conf.

sudo nano /etc/httpd/conf/httpd.conf

Config dosyası içerisinde aşağıdaki gibi bir tanımlamanız olması gerekiyor.

<VirtualHost *:80>
    ServerName service.example.com
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Giriş kısıtlaması dizin bazında yapılmaktadır. Bunun için Directory ya da Location tanımlamalarını kullanmamız gerekmektedir.

<VirtualHost *:80>
    ServerName service.example.com
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    <Directory "/var/www/html">
        AuthType Basic
        AuthName "Restricted Content"
        AuthUserFile /etc/httpd/.htpasswd
        Require valid-user
    </Directory>
</VirtualHost>

Artık service.example.com adresine erişmek istendiğinde kullanıcı adı ve şifre girilmesi gerekecektir.

Reverse Proxy

Reverse Proxy eklemek için ProxyPass ve ProxyPassReverse alanları işimizi görecektir. Reverse Proxy ve Basic Authentication işlemlerini birlikte içeren config şu şekilde olacaktır.

<VirtualHost *:80>
    ServerName service.example.com
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    ProxyRequests Off
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    ProxyErrorOverride On
    ProxyPass   /   http://127.0.0.1:3100/
    ProxyPassReverse   /   http://127.0.0.1:3100/

    <Location />
        Authtype Basic
        Authname "Password Required"
        AuthUserFile /etc/httpd/.htpasswd
        Require valid-user
        Order allow,deny
        Allow from all
    </Location>
</VirtualHost>

Burada Directory’den farklı olarak Location kullanıldı. Dikkat edilmesi gerek bir nokta, ProxyPass ve ProxyPassReverse tanımlamalarındaki hedef url’in sonundaki / mutlaka koyulmalıdır. Yoksa doğru bir mapping yapılamayacaktır.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Zamanlarının Ötesinde Olan Bazı Fikirler

Wed, 27 Jan 2021 00:00:00 GMT

Jet motorlu aérotrains Fransa’da 1965 ile 1977 tarihleri arasında geliştirildi. Tren, benzeri görülmemiş hızlarda; basit, güçlendirilmiş beton bir yol üzerinde ve bir hava yastığı üzerinde ilerliyordu. Aslında tam olarak klavuz bir yolda ilerleyen hoverkraft (karada ve havada gidebilen taşıt)‘a benziyordu.

1960’larda Bell Labs, insanların telefonda konuşurken birbirlerine bakabilecekleri bir resimli telefon yarattı. Buradan anlıyoruz ki aslınad görüntülü görüşme o kadar da modern değilmiş :)

1990’larda, kullanıcıların fotoğraflara yalnızca saatleriyle tıklamalarını sağlayan Casio WQV-1 kol saati kamerası üretilmişti. Kalite o kadar iyi olmayabilir ancak konsept zamanının ötesindeymiş.

Çevrimiçi canlı oyun oynamaya başlamadan çok önce, 1990’larda kullanıcıların Kablo TV aracılığıyla birbirleriyle oyun oynamasına izin veren “Sega Kanalı” olarak bilinen bir video oyun yayın hizmeti vardı.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Mimari Desenler ile Tasarım Desenleri Arasındaki Fark Nedir?

Thu, 10 Dec 2020 00:00:00 GMT

Wikipedia’ya göre:

architectural pattern

is a general, reusable solution to a commonly occurring problem in software architecture within a given context. Architectural patterns are similar to software design pattern but have a broader scope.

“belirli bir bağlamda yazılım mimarisinde yaygın olarak ortaya çıkan bir soruna genel, yeniden kullanılabilir bir çözümdür. Mimari desenler, yazılım tasarım modeline benzer ancak daha geniş bir kapsama sahiptir.”

Bu yazıda, aşağıdaki 10 ortak mimari kalıbı, kullanımları, artı ve eksi yönlerini ele alarak açıklamaya çalışacağım.

“Layered pattern”
“Client-server pattern”
“Master-slave pattern”
“Pipe-filter pattern”
“Broker pattern”
“Peer-to-peer pattern”
“Event-bus pattern”
“Model-view-controller pattern”
“Blackboard pattern”
“Interpreter pattern”

1. Layered Pattern (tr: Katmanlı desen)

Bu desen, her biri belirli bir soyutlama düzeyinde olan alt görev gruplarına ayrıştırılabilen programları yapılandırmak için kullanılabilir. Her katman, bir sonraki üst katmana hizmet sağlar.

Bir sistemde genel olarak bulunan 4 katman şunlardır:

Presentation layer - Sunum katmanı (UI katmanı olarak da bilinir)
Application layer - Uygulama katmanı (hizmet katmanı olarak da bilinir)
Business logic layer - İş mantığı katmanı (etki alanı katmanı olarak da bilinir)
Data access layer - Veri erişim katmanı (kalıcılık katmanı olarak da bilinir)

Kullanım

E-posta, belge paylaşımı ve bankacılık gibi çevrimiçi uygulamalar.

2. Client-server Pattern (tr: İstemci-sunucu kalıbı)

Bu model iki kısımdan oluşur; bir sunucu ve birden çok istemci. Sunucu bileşeni, birden çok istemci bileşenine hizmet sağlayacaktır. İstemciler sunucudan hizmet talep eder ve sunucu bu istemcilere ilgili hizmetleri sağlar. Ayrıca, sunucu istemci isteklerini dinlemeye devam eder.

Kullanım

Desktop uygulamaları
E-ticaret web uygulamaları.

3. Master-Slave Pattern (tr: Efendi-Köle kalıbı)

Bu model iki kısımdan oluşur; master(efendi) ve slaves(köleler). Ana bileşen, işi özdeş ikincil bileşenler arasında dağıtır ve ikincil bileşenlerin döndürdüğü sonuçlardan nihai sonucu hesaplar.

Kullanım

Veritabanı replikalarında, ana veritabanı yetkili kaynak olarak kabul edilir ve ikincil veritabanları onunla senkronize edilir.
Bir bilgisayar sistemindeki bir veri yoluna bağlı çevre birimleri (ana ve bağımlı sürücüler).

4. Pipe-filter Pattern (tr: Boru filtre düzeni)

Bu model, bir veri akışı üreten ve işleyen sistemleri yapılandırmak için kullanılabilir. Her işlem adımı bir filtre bileşeninin içindedir. İşlenecek veriler borulardan geçirilir. Bu borular, arabelleğe alma veya senkronizasyon amacıyla kullanılabilir.

Kullanım

Derleyiciler. Ardışık filtreler, sözcük analizi, ayrıştırma, anlamsal analiz ve kod üretimi gerçekleştirir.
Biyoinformatikte iş akışları.

5. Broker Pattern (tr: Broker kalıbı)

Bu model, ayrıştırılmış bileşenlere sahip dağıtılmış sistemleri yapılandırmak için kullanılır. Bu bileşenler, uzaktan hizmet çağrılarıyla birbirleriyle etkileşim kurabilir. Bir broker bileşeni, bileşenler arasındaki iletişimin koordinasyonundan sorumludur.

Sunucular, yeteneklerini (hizmetleri ve özellikleri) bir brokera yayınlar. Müşteriler, aracıdan bir hizmet talep eder ve daha sonra aracı, istemciyi kayıt defterinden uygun bir hizmete yönlendirir.

Kullanım

“Apache ActiveMQ”, “Apache Kafka”, “RabbitMQ” ve “JBoss Messaging” gibi aracı mesaj yazılımları

6. Peer-to-Peer Pattern (tr: Eşler arası model)

Bu modelde, tek tek bileşenler eşler olarak bilinir. Eşler, diğer eşlerden hizmet talep eden bir istemci olarak ve diğer eşlere hizmet sağlayan bir sunucu olarak işlev görebilir. Bir eş, bir istemci veya bir sunucu veya her ikisi olarak hareket edebilir ve rolünü zamanla dinamik olarak değiştirebilir.

Kullanım

“Gnutella” ve “G2” gibi dosya paylaşım ağları
“P2PTV” ve “PDTP” gibi multimedya protokolleri.

7. Event-Bus Pattern (tr: Olay veriyolu düzeni)

Bu model öncelikle olaylarla ilgilenir ve 4 ana bileşeni vardır; olay kaynağı, olay dinleyicisi, kanal ve olay veriyolu. Kaynaklar, bir olay veri yolundaki belirli kanallara mesajlar yayınlar. Dinleyiciler belirli kanallara abone olurlar. Dinleyiciler, daha önce abone oldukları bir kanala yayınlanan mesajlardan haberdar edilirler.

Kullanım

Android development
Bildirim hizmetleri

8. Model-View-Controller Pattern (MVC =))

MVC kalıbı olarak da bilinen bu kalıp, etkileşimli bir uygulamayı şu şekilde 3 parçaya böler:

model: temel işlevleri ve verileri içerir
view: bilgileri kullanıcıya gösterir (birden fazla görünüm tanımlanabilir)
controller: kullanıcıdan gelen girdiyi yönetir

Bu, bilginin dahili temsillerini, bilginin kullanıcıya sunulma ve kullanıcıdan alınma yollarından ayırmak için yapılır. Bileşenleri ayırır ve verimli bir şekilde kod yeniden kullanımına izin verir.

Kullanım

Başlıca programlama dillerinde World Wide Web uygulamaları için mimariler
“Laravel” ve “Gin-Gonic” gibi çerçeveler

9. Blackboard Pattern (tr: Karatahta deseni)

Bu model, deterministik çözüm stratejilerinin bilinmediği problemler için yararlıdır. Yazı tahtası deseni 3 ana bileşenden oluşur.

blackboard: çözüm uzayındaki nesneleri içeren yapılandırılmış bir küresel bellek
knowledge source: kendi temsilcileriyle özel modüller
control component : modülleri seçer, yapılandırır ve yürütür

Tüm bileşenlerin tahtaya erişimi vardır. Bileşenler, tahtaya eklenen yeni veri nesneleri oluşturabilir. Bileşenler, tahtada belirli türde verileri arar ve bunları mevcut bilgi kaynağıyla örüntü eşleştirerek bulabilir.

Kullanım

Konuşma tanıma
Araç tanımlama ve izleme
Protein yapısı tanımlama
Sonar yorumlama sinyalleri

10. Interpreter Pattern (tr: Yorumlayıcı deseni)

Bu model, özel bir dilde yazılmış programları yorumlayan bir bileşen tasarlamak için kullanılır. Esas olarak, belirli bir dilde yazılmış cümleler veya ifadeler olarak bilinen program satırlarının nasıl değerlendirileceğini belirtir. Temel fikir, dilin her sembolü için bir sınıfa sahip olmaktır.

Kullanım

SQL gibi veritabanı sorgu dilleri
İletişim protokollerini tanımlamak için kullanılan diller

Mimari Desenlerin Karşılaştırılması

Aşağıda verilen tablo, her bir mimari modelin artılarını ve eksilerini özetlemektedir.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

İyi Yazılımcılar Hakkında 7 Çıkarım

Thu, 08 Oct 2020 00:00:00 GMT

Programlama bir sanattır. 10 yıldan uzun bir süredir sektörün içerisindeyim. Bu yıllar içerisinde başlangıç cümlemi haklı çıkartan çok fazla iyi yazılımcıyla birlikte çalıştım ve onlardan bir çok şey öğrendim.

İyi yazılımcılar, programlamayı çok kolay hale getirirler. Bir teknik mimarın söylediği şu sözü hep hatırlıyorum:

Yazılım geliştiricilerin rolü işleri kolaylaştırmaktır. Karmaşık sorunlara zahmetsiz çözümler sunmaları gerekir.

Yıllar boyunca, bahsettiğim bu iyi yazılımcılardan kariyer gelişimime yardımcı olan birkaç çıkarım yaptım. Aşağıda dilim döndüğünce bunları açıklamaya çalışacağım.

1. Çıktıya Değil, Sürece Odaklan

Genç yazılımcıların çoğu yazılımın çıktısına odaklanıyor. Fakat çıktının oluşturulması, sizin süreci anladığınız anlamına gelmemektedir.

Yazılım dünyasında her gün yeni zorluklarla karşılaşacaksınız. Bu zorlukları aşabilmenizde önceki deneyimleriniz çok önemli olacaktır. Bu yüzden süreci anlamanız çok önemlidir.

Çıktının ne olması gerektiğinden ziyade sorunun nasıl çözüleceğine odaklanmaya başlayın.

Bu size, uzun vadede daha iyi bir programcı olmanız için rehberlik edecektir.

2. Başkaları Tarafından Beslenmek Sizi Bir Yere Götürmez

Bir yazılımcı olarak kariyerime başladığım zamanlarda problemlerle karşılaştığım durumlardaki davranışlarımı hala hatırlıyorum. Kodun bir yerinde sıkışıp kaldığımda zaman zaman tecrübeli yazılımcılara sorular sorardım ama en çok yaptığım şey sorunlarla mücadele etmekti. Bir ekiple çalışıyorsanız, ekibinizdeki kişiler her zaman yardım etmek için orada olacaklardır ama sürekli yardım almak, her sorunu başkalarının yardımıyla çözmek öğretici olmaz. Sorunun içine dalmaya ve bir süre mücadele etmeye çalışmak her zaman öğretici olacaktır.

Bu çalışma disiplini, bir yazılımcı olarak kariyerimde ilerlememe çok yardımcı oldu. Kodda sıkışıp kaldığınızda kendinizi küçümsememelisiniz. Sorunla ilgili birilerinden yardım istemeden önce %200’ünüzü vermeye çalışmanız, yazılımcı olarak gelişmenize çok yardımcı olacaktır.

3. Önce Kendi Kodunuzu Anlayın

Daha önce de değindiğim gibi, yazılımcıların karmaşık sorunlara basit çözümler sunması gerekir. Başkalarını etkilemek için meşakkatli kod yazmaları gerekmez.

İnsanlar yazdıkları kodu birkaç gün veya ay sonra gördüklerinde genellikle neyi kodladıklarını unuturlar. Kendi yazdıkları bir kod parçasının ne yaptığını hatırlamakta zorlandıklarını düşünün. Aynı kodu başka biri anlamaya çalışırsa neler olur? :)

Kodun ne iş yaptığını anlatan yorumlarla birlikte basit ama etkili kodlar yazın. Yorumlar, bir kod parçasının uygulamada ne yaptığını hatırlamanıza yardımcı olacaktır. Gerektiğinde kısa ve faydalı yorumlar yazmaya çalışın.

İyi yazılımcılar, diğer yazılımcılar tarafından okunabilen basit ama etkili kodlar yazarlar.

4. Birden Fazla Çözüm Bulun

İyi yazılımcılar, bir soruna birden fazla çözüm bulana kadar araştırma yapmayı, düşünmeyi bırakmazlar. Her zaman bir sorunu çözmek için en az iki yol bulurlar.

Bu iyi bir süreçtir çünkü size “uzay-zaman karmaşıklığı”na ve diğer faktörlere dayalı olarak birden çok çözüm arasından seçim yapma imkanı sunar.

Bu yaklaşım, sorunu çözmek için farklı bakış açılarına sahip daha fazla çözüm bulmaya çalışırken mantıksal düşüncenizi geliştirir.

Birden fazla çözüm bulamasanız bile “Stack Overflow”, “CodeProject”, “Github” gibi sitelerde alternatif çözümler için araştırma yapmalısınız.

5. Kod Okuması Konusunda Bir Kitapserver gibi Davranın

“Yazmadan önce okuyun” yazılım geliştirme için doğru bir yaklaşımdır. Başkalarının yazdıkları kodları okumak size diğer her şeyden daha fazla fikir verir, çok şey öğretir.

İyi programcılar, kod incelemelerine makul süreler harcarlar. Bu birkaç şeyi toplamalarına yardımcı olur:

Kod hakkında daha fazla bilgi
Diğer yazılımcıların kodlama becerileri
Bir sorunu çözmek için farklı yaklaşımlar (çoklu çözümler)
Mantıksal düşünceyi geliştirme

Kod okuma, yazılımcılar için bir alışkanlık olmalıdır. Bu onların kariyerlerinde büyümelerine yardımcı olur.

6. Daha Sonra Geri Gel ve İyileştir

Yazılım geliştiricilik kariyerimin başlarında bu yöntem ile tanıştım. Tecrübeli bir yazılımcı arkadaşımın, çoktan bitmiş bir task ile ilgili kod değişikliği yaptığını gördüm.

Ona her şey yolunda giderken mantığı değiştirmenisinin nedenini sormuştum. İş yükü az olduğunda, halihazırda çözülmüş sorunlara daha iyi yaklaşımlar bulmaya çalışıyordu. Geçerli çözümden daha iyi bir çözüm bulursa, değişiklik isteği oluşturup güncelliyordu.

Bu uygulama, yazılımcı olarak gelişmesine çok yardımcı oldu. Ayrıca kodun optimize edilmesini de sağladı.

7. Yazılımcı Dünyası ve Yazılımcı Sürekli Güncellenir

İyi bir yazılımcının bence en önemli tanımlayıcı niteliği, sürekli bilgi arayışıdır. Yazılım, sürekli güncel kalmanız gereken zorlu bir kariyer yolculuğudur.

Yazılımcılar, kodları kadar iyidir. Geliştirdikleri yazılımlar gibi sürekli olarak güncel kalmaları gerekir.

İyi yazılımcılar, kendilerini güncel tutmak için teknik bloglar, YouTube kanalları veya kodlama forumları gibi birçok kaynağı kullanırlar.

Özet

Özetle, iyi yazılımcılar için temel çıkarımlar şunlardır:

Kodlama yapmak için acele etmeyin, önce süreci anlayın.
Başkalarından yardım istemeden önce bir süre mücadele edin.
Herkesin anlayabileceği basit ve etkili kodlar yazın.
Bir soruna birden fazla çözüm bulmaya çalışın.
Kod okumayı alışkanlık haline getirin.
Mümkünse önceden uyguladığınız çözümünüzü geliştirmeye çalışın.
Bir yazılımcı olarak teknolojik gelişmeler konusunda güncel kalın.

Bunlar, kariyerim boyunca gelişmeme yardımcı oldu. Umarım diğer yazılımcı arkadaşlarıma da yardımcı olurlar.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Morse Alfabesi: İletişimin İlk Dijital Dili

Thu, 03 Sep 2020 00:00:00 GMT

Morse alfabesi, insanların iletişimini kökten değiştiren ve dünya çapında bir devrim yaratan bir sistemdir. Bu alfabenin yaratılması, uzun mesafelerde hızlı ve güvenilir iletişim ihtiyacının doğmasıyla tetiklendi. Özellikle 19. yüzyılın başlarında, Amerika Birleşik Devletleri’nde demiryolları inşası ve denizcilik endüstrisinin büyümesi, haberleşme yöntemlerine olan talebi artırdı. Samuel Morse ve Alfred Vail, bu zorluğa cevap vermek için Morse alfabesini geliştirdi.

Morse alfabesi, kısa ve uzun sinyallerin kombinasyonlarıyla harf ve rakamları ifade eden basit bir sistemdir. Bu sinyaller, ilk başta telgraf telinden geçirilerek iletilirdi. Bu sayede, Amerika Birleşik Devletleri’nin batı kıyısından doğu kıyısına ve hatta okyanuslar arası hızlı iletişim mümkün hale geldi. Bu, ticaretin hızlanması, acil mesajların daha hızlı iletilebilmesi ve kaza sonucu yaralanan gemi mürettebatının acil yardım taleplerinin iletilmesi gibi bir dizi hayati önem taşıyan uygulamayı mümkün kıldı.

Morse alfabesi, telsiz iletişimin temelini oluşturdu ve daha sonra radyo iletişimi gibi modern teknolojilerin gelişimine ilham verdi. Aynı zamanda uluslararası bir dil olarak benimsendi ve birçok farklı kültür ve dil arasında iletişimi kolaylaştırdı. Günümüzde bile, denizcilik, havacılık ve amatör telsizciler gibi bazı alanlarda Morse kodu hala kullanılmaktadır.

Morse alfabesi, tarihin derinliklerinde bir iz bırakan ve iletişimin geleceğini şekillendiren önemli bir adımdır. Bu alfabenin basitlik ve etkililiği, iletişimin gücünü herkesin anlayabileceği bir düzeye getirdi ve modern iletişim teknolojilerinin temelini attı.

Morse Alfabesi Nedir?

Morse alfabesi, metin tabanlı iletişimi nokta ve çizgi gibi kısa ve uzun sinyallerle temsil eden bir kodlama sistemidir. Her harf ve rakam, benzersiz bir kombinasyonla ifade edilir. Morse kodunda kullanılan iki temel sembol şunlardır:

Nokta (.): Kısa bir sinyali temsil eder.
Çizgi (-): Uzun bir sinyali temsil eder. Bu temel sembollerin kullanımıyla, farklı karakterler ve sayılar kodlanabilir. Örneğin, “A” harfi “.-” şeklinde, “S” harfi ”…”, ve “5” rakamı ”…” şeklinde kodlanır.

Morse Alfabesinin Tarihi

Morse alfabesi, Amerikalı mucit Samuel Morse ve Alfred Vail tarafından 1830’ların sonlarında geliştirildi. Bu yeni iletişim yöntemi, uzun mesafelerde hızlı ve güvenilir iletişim sağladı ve özellikle telgraf sistemi için büyük bir adım oldu.

İlk olarak denizcilikte ve demiryolu iletişiminde kullanılan Morse alfabesi, daha sonra askeri iletişimde ve acil durum haberleşmesinde de yaygın olarak kullanıldı. Özellikle denizcilikte, gemiler arası ve gemi-kara iletişimi için hayati bir rol oynadı.

Morse Alfabesinin Kullanım Alanları

Morse alfabesi, tarihsel olarak birçok farklı alanda kullanıldı ve hala bazı özel uygulamalarda kullanılmaktadır. İşte bazı kullanım alanları:

Denizcilik ve Havacılık: Morse kodu, deniz fenerleri, gemiler ve uçaklar arası iletişimde kullanılır. Bu, acil durum sinyallerinin iletilmesinde kritik bir öneme sahiptir.
Askeri Kullanım: Morse alfabesi, askeri iletişimde ve istihbarat toplamada yaygın olarak kullanılmıştır. Düşmanın anlayamayacağı bir dil kullanmak önemlidir.
Amatör Telsizciler: Hala birçok amatör radyo telsizcisi, Morse kodunu öğrenir ve kullanır. Bu, dünya çapında iletişim kurmalarını sağlar.
Acil Durumlar: SOS sinyali olarak bilinen ”… --- …” dizisi, acil durumlar için uluslararası bir çağrıdır ve hala kullanılmaktadır.

Morse Kodlama Mantığı

Morse kodlama mantığı oldukça basittir. Her harf ve rakam, bir dizi nokta ve çizgi ile temsil edilir. İşte bazı örnekler:

“A” harfi “.-” şeklinde kodlanır.
“S” harfi ”…” şeklinde kodlanır.
“5” rakamı ”…” şeklinde kodlanır. İşaretler arasında bir kısa duraklama ve karakterler arasında bir uzun duraklama vardır. Bu duraklamalar, kodun parçalarını ayırmak için kullanılır.

Morse alfabesi, iletişim tarihinde bir dönüm noktasıdır. Basit ve etkili bir iletişim yöntemi olarak, uzun mesafelerde ve acil durumlarda hayat kurtarmıştır. Günümüzde hala kullanılan bu alfabenin tarihi ve mantığı, iletişim dünyasının gelişimini anlamamıza yardımcı olur.

Morse alfabesi, iletişimin özünde kodlama ve dekodlama süreçlerini temsil eden güçlü bir sembolizme sahiptir ve bu yönüyle bilim ve tarih alanlarında ilginç bir konu olarak dikkat çeker.

GoLang’de Morse Kod uygulaması:

package main

import (
	"fmt"
	"strings"
)

var morseCodeMap = map[string]string{
	"A": ".-", "B": "-...", "C": "-.-.", "D": "-..", "E": ".", "F": "..-.", "G": "--.",
	"H": "....", "I": "..", "J": ".---", "K": "-.-", "L": ".-..", "M": "--", "N": "-.",
	"O": "---", "P": ".--.", "Q": "--.-", "R": ".-.", "S": "...", "T": "-", "U": "..-",
	"V": "...-", "W": ".--", "X": "-..-", "Y": "-.--", "Z": "--..", "1": ".----",
	"2": "..---", "3": "...--", "4": "....-", "5": ".....", "6": "-....", "7": "--...",
	"8": "---..", "9": "----.", "0": "-----", "&": ".-...", "@": ".--.-.",
	":": "---...", ",": "--..--", ".": ".-.-.-", "'": ".----.", "\"": ".-..-.",
	"?": "..--..", "/": "-..-.", "=": "-...-", "+": ".-.-.", "-": "-....-",
	"(": "-.--.", ")": "-.--.-", "!": "-.-.--", " ": "/",
}

func encrypt(message string) string {
	message = strings.ToUpper(message)
	var morseCode []string
	for _, char := range message {
		if code, ok := morseCodeMap[string(char)]; ok {
			morseCode = append(morseCode, code)
		}
	}
	return strings.Join(morseCode, " ")
}

func decrypt(message string) string {
	var result string
	codeArray := strings.Split(message, " ")
	for _, code := range codeArray {
		for key, value := range morseCodeMap {
			if code == value {
				result += key
				break
			}
		}
	}
	return result
}

func main() {
	message := "Morse code here!"
	fmt.Println(message)
	encrypted := encrypt(message)
	fmt.Println(encrypted)
	decrypted := decrypt(encrypted)
	fmt.Println(decrypted)
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Morse code here!
-- --- .-. ... . / -.-. --- -.. . / .... . .-. . -.-.--
MORSE CODE HERE!

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

https://en.wikipedia.org/wiki/Morse_code

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Ortadoğu'da Petrol Olmasaydı ABD'nin Orada Olanlarla Herhangi Bir İlgisi Olur Muydu?

Fri, 14 Aug 2020 00:00:00 GMT

Cevap kesinlikle EVET.

ABD’nin İsrail’i neden bu kadar çok desteklediğini hiç merak ettiniz mi?

II.Dünya Savaşı’ndan sonra, ABD kendisini Sovyetler Birliği ile bir çatışma içinde buldu. III.Dünya Savaşı’nın patlak verebileceğine dair ciddi inanç taşıyanlar az değildi ve bu inançlar üzerine birçok plan hazırlandı.

Amerika Birleşik Devletleri bu savaşa hazırlık yapmak için Kuzey Atlantic Antlaşması Örgütü veya kısaca NATO olarak bilinen bir Avrupa savunma örgütünü kurdu. Bununla birlikte, nato’nun müslüman versiyonu diyebileceğimiz Orta doğu Antlaşması Örgütü ya da çoğu tarihçinin dediği gibi Bağdat Paktı da kuruldu.

Sovyetler Birliği’nin bir zamanlar Orta Doğu ile sınırı olduğunu aşağıdaki harita aracılığıyla görebiliriz:

Bundan dolayı ABD, Sovyetler Birliği ile bir savaş çıkarsa, iki yönden saldırı yapılabileceğine inanıyordu:

Avrupalılar Doğu Avrupaya saldırır.
Orta Doğulularda tıpkı Osmanlı İmparatorluğunun yaptığı gibi Kafkasya’ya saldırır.

III.Dünya Savaşı’nın başladığını hayal edin. İran, Irak ve Türk askerleri Kafkasya bölgesine hızla saldırırken, Pakistan ya onları destekler ya da bunun yerine Orta Asya’yı işgal ederek Sovyetleri 3 ayrı işgali savuşturmaya zorlayabilir.

İşte bu ABD’nin 1950’lerde Arap yanlısı bir dış politikası olmasının sebebidir.

İsrailli tarihçi Avi Shlaim’in belirttiği gibi aslında ABD İsrail’e düşmandı. Hatta İsrail’in, Ürdün’ün Yahudi yerleşimleri için ilhak edilmesi önerisini dahi reddetti ve İsrail’i 1956’da Fransa ve İngiltere ile birlikte Mısır’ı işgal ettiği için kınadı.

Bunun nedeni, ABD’nin Arapların Amerika’yı dostları olarak görmesinin hayati önem taşıdığını düşünmesidir çünkü ABD’nin o zaman ki çıkarları basitti:

Sovyetler Birliğini yenmek.

Araplar ırkçılık kriziyle ABD’nin elini bozdular

ABD, Fransa ve İngiltere gibi beyaz bir millettir. Bunun sonucunda, ABD’nin Arap Dünyasına erişimi neo-sömürgecilik olarak algılandı ve doğrudan bir düşmanlık ve şiddet dalgasını beraberinde getirdi.

ABD, Ürdün’ü Bağdat Paktı’na sokmak için bir girişim başlattığında, Ürdünlüler (özellikle Batı Şeria’daki Filistinliler), Kral ABD’yi açıkça eleştirene ve Bağdat Paktı’nı reddedene kadar protesto ettiler ve ayaklandılar.
Iraklılar, 1958’de 14 Temmuz Devrimi‘nde ABD’nin kuklası oldukları için kraliyet ailelerini öldürecek kadar ileri gittiler.

Irak Başbakanı Nuri Said bir zamanlar Amerika’nın Avrupa dışındaki en iyi arkadaşı olarak kabul ediliyordu. Iraklılar bu konuda ne düşündüklerini Said’i öldüresiye döverek ve cesedini yakarak gösterdiler.

Faslıların, Kralın ABD Ordusunun Krallığa girmesine izin vermesini protesto etmesinden sonra, ABD tarafından 1950’lerde bir müttefik olarak kabul edilen Fas bile, ABD’nin Nouasseur Hava Üssü‘nü terk etmesi gerektiğini bildirdi.

ABD ile İsrail uyumu, aşağıdaki koşullar dışındaki tüm koşullara uygun bir arkadaşlık olarak görüldü:

Fırsatçı (örneğin Suudi Arabistan ve BAE)
Suudi Arabistan’daki Çin drone fabrikası, ortadoğudaki ilk fabrika
Jeopolitik, Rusya ve BAE’yi Yakından Yönlendiriyor
Tarafsız (ör. ABD’yi hiçbir girişimde gerçekten desteklemeyen Fas)
Kesin Düşman (örneğin İran)
İran Müslümanları ABD hegemonyasından kurtulmak için bilim üretmeye çağırıyor

Bu, özellikle Arap dünyasının coğrafi konumu nedeniyle endişe vericidir.

Bu harita, Avrupa’nın hemen yanında, yani Arap dünyasında olan her şeyin Avrupa’yı etkileyeceği anlamına geliyor. Bu yüzden şunun gibi yorumlar korkunçtur:

Kaddafi: AB Libya’ya yılda 4 milyar ödemezse Avrupa ‘siyaha dönecek’

Düpedüz düşman bir Arap lider olan Kaddafi’nin, AB’ye Afrikalıları Avrupa’ya akın etmeye teşvik edeceğini ve yılda 4 milyar dolar almazsa Libya’yı fırlatma rampası olarak kullanmalarına izin vereceğini söylemesi, Birleşik Devletler için hiç de ideal bir durum değildir.

Bunun Libya petrolüyle bir ilgisi yoktur. Yalnızca ABD, tıpkı AB gibi, bu tür tehditleri büyük bir sorun olarak görüyor.

Dolayısıyla, Orta Doğu’da petrol olmasa bile, Amerika Birleşik Devletleri’nin yine de bir çıkarı mutlaka olacaktır.

Rusya’nın artık Orta Doğu ile bir sınırı olmasa da (bugün Ermenistan ve Azerbaycan bağımsızdır), yine de Rusya’nın Avrupa’yı tehdit edecek müttefiklerinin olmamasını sağlamaya yardımcı oluyor.
Hiçbir Arap liderin ister askeri olarak (“Yarın Yunanistan’ı işgal edeceğiz!”), İster terörizm (örneğin İslamcı grupları finanse etmek) veya sadece Avrupa’yı yasa dışı göçmenlerle doldurmakla tehdit ederek, Avrupa’yı tehdit etmemesine yardımcı oluyor.
Ayrıca tabii ki ekonomik kaynaklarda var :)

ABD Irak’ı Siemens Anlaşmasını GE Lehine Bozmaya İkna Etti

Irak’ın 15 milyar dolarlık bir elektrik santrali anlaşması vardı. ABD, “müttefiki” Irak’ı, bu enerji santrallerini inşa etmek için Alman Siemens şirketini değil, Amerikan şirketi General Electric’i kullanmaya “teşvik etti” (Evet teşvik ;)). Böylece 15 milyar dolarlık Arap parası bir Amerikan şirketini zenginleştirmek ve Amerikalı işçileri işe almak için kullanılabilecek.

Veya CNN’in dediği gibi: GE, Irak’ta çok ihtiyaç duyulan bir galibiyet elde etti

Evet. General Electric o Irak ihalesini “kazandı”.

İşte bu.

Son cümle: Petrol Amerikan çıkarları için pek çok insanın inandığı kadar önemli değil.

Referanslar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Öğrenme Neden Teknolojideki En Önemli Beceridir?

Thu, 06 Aug 2020 00:00:00 GMT

En sevdiğim meme-lerden bir tanesi “I have no idea what I’m doing (tr: ne yaptığım hakkında hiçbir fikrim yok)” köpeğidir. Bilim deneyi yapmaya çalışan Golden Retriever’dan daha güzel bir rol model olabilir mi? :) Ne yaptığı hakkında hiçbir fikri olmaması umurunda mı? Elbette değil. Ne olursa olsun deniyor.

Bu meme-yi seviyorum. Arada bu köpeğe bakıp “Sen ve ben köpek, yeni zor bir şeyle mücadele ediyoruz.” diye düşünürüm. Ve her zaman yeni zor BİR ŞEY karşımda duruyor olur.

Neden Öğrenme Hakkında Daha Fazla Konuşmuyoruz?

Teknoloji endüstrisi öğrenme hakkında çok fazla konuşmuyor. Bu çok garip bir durum çünkü öğrenmek bizim en önemli becerimiz. Onsuz başarılı olmamız imkansız. Teknoloji muazzam, bilmemiz gereken çok farklı -şey- var ve hepsi inanılmaz bir hızla sürekli olarak değişiyor. Her gün yeni bir framework, yeni bir mimari, yeni bir araç çıkıyor ya da değişikliğe uğruyor. Birdenbire, yeni bir isimde yepyeni teknolojiler karşımıza çıkıyor ve biz sürekli olarak şu düşünceyle boğuşuyoruz: “Acaba bir duyuruyu mu kaçırdım? Bu yeni -şey- nereden çıktı?”

Yazılım dünyasında güncel kalmak demek sürekli olarak öğrenmekte olduğumuz anlamına gelir. İşimizi öğrenme olmadan yapamayız. Fakat nedense bu konu hakkında fazla konuşmuyoruz.

Instagram Hayatlarımız

Bu bir sorun. Bildiğimiz -şeyleri- nasıl bildiğimizi açıklamadığımızda, bu bilgileri elde etmenin de ne kadar çok çalışma gerektirdiğini kabul etmemiş oluyoruz. Bu durum sektördeki yeni insanlar için gerçekçi olmayan beklentiler yaratıyor. Etrafınızdaki herkes sihirli bir şekilde bir sürü -şey- biliyor gibi göründüğünde ve siz o -şeyleri- bilmiyorsanız, yeterince iyi değilmiş gibi hissedebilirsiniz. Orada olmamanız gerekiyormuş gibi hissedebilirsiniz.

Muhtemelen çektikleri ilk resim değildir, di mi? Photo by Duc Viet Hoang on Unsplash.

Bu tıpkı herkesin hayatının zahmetsiz, mükemmel göründüğü Instagram Problemi gibi bir durum. Güzel duran bir fotoğraftan önceki düzensizliği, zahmeti, doğru fotoğrafı bulana kadar çekilen diğer 20 fotoğrafı görmüyoruz. İnsanların bilgilerini kullandıklarını görüyoruz fakat elde edilen bilgiyi göstermiyoruz. İnanılmaz derecede mantıksız dökümantasyonları, yanlış yolları, ilk korkunç prototipleri, yayınlanmadan önce haftalarca var olan fikirleri göremiyoruz.

Yeni insanlara öğrenmenin yavaş, sinir bozucu ve bazen zor olabileceğini ama bunun gerçekten “normal” olduğunu söylemiyoruz.

Öğrenme 1 numaralı beceriyse, muhtemelen 2. ise kalıcılıktır. Ve maalesef bazı şeyler zaman alır.

Bu Yüzden Yüksek Sesle “Öğrenmeliyiz”

Geçenlerde yaptığımız bir konuşmada kıdemli mühendislere sahip olabilmemiz için birisinin aptalca soruları sorması gerektiğini söyledim.

“Bir dakika, bu kelime ne anlama geliyor?”
“Bu konuyu, ben 5 yaşındaymışım gibi açıklayabilir misin?”
“Bunu neden yapıyoruz?”
“Hangi sorunu çözmeye çalışıyoruz?”
“Böyle bir şey zaten yok mu?”

Bazen toplantılarda yanıtını zaten bildiğim ve diğer insanların çoğunun bilmediğinden emin olduğum soruları sorarı. Daha tecrübeli kişilerin bu tarz soruları sorması her zaman daha az korkutucudur. :)

Öğrenmeyi Öğrenmek

Öğrenme başlı başına bir beceridir. Uygulama anında ve kendiniz için neyin işe yaradığını anladıkça daha iyi hale geldiğiniz bir şeydir.

Örneğin; bir konuyla ilgili, başlangıç için “en iyi” yeri bulmaya çalışarak, öğrendiğim yeni konunun en önemli yönlerini seçmeye çalışıyordum. Keyfi bir makale okuyarak başlamanın konuyla ilgili bir Wikipedia sayfasını okumak kadar iyi olacağını düşünerek, anlamadığım bir şey seçtim ve bu konu hakkında okumaya devam ettim. Bunu bir kaç saat yapmaya devam edersem, neyin önemli olduğu konusunda aklımda bir resim oluşacağından emindim.

“Herkesin söylediği gibi, X’deki bir monad, X’in endofunktörleri kategorisinde sadece bir monoiddir; ürün x, endofunktörlerin ve kimlik endofunktörü tarafından belirlenen birimin kompozisyonuyla değiştirilir. Anladım.” Photo by Hal Gatewood on Unsplash.

Çalıştığım konu sıkıcı ya da zor bir konuysa, onu ilgi çekici hale getirmek için az önce okuduğum her şeyi HEMEN kullanmam gerektiğini öğrendim (örneğin: bir blog yazısı ya da az önce öğrendiklerimi özetleyen bir blog yazısı yazmak gibi). Merak ettiğim, hakkında yazmak istediğim ya da birilerine öğretmek istediğim konularda okumak, araştırma yapmak için sonsuz bir sabra sahibim.

Kodlama alıştırmaları ve küçük projeler de aynı etkiye sahiptir. Teori sonsuza kadar öğrenilebilir fakat bilgiyi pekiştirmek ve kalıcı hale getirmek için onu bir projede kullanmak gibisi yoktur.

Her Şey Öğrenilebilir

Bence teknolojideki en önemli fark, her şeyin öğrenilebir olmasıdır. Gerçekten de her şeyin :) Bunlardan bazıları zor ve bilinmesi gereken çok fazla detay olabilir ama bunları öğrenmek sihirli bir dokunuşla mümkün olmaz. En kötü durumda, sadece biraz zaman alır.

Eğer tecrübesiz biriyseniz ve bilmediğiniz birçok şey varmış gibi geliyorsa kendinizi kötü hissetmeyin. Çünkü bu çok normal. Bilmeniz gereken çok -şey- var. Aşinalık zamanla oluşacak bir şey fakat bu da sonsuza kadar sürmeyecek. Yeni bir alana gireceksiniz ve tekrar ne yaptığınız konusunda hiçbir fikriniz olmayacak. Bir bilginin nasıl öğrenileceğini öğrenmeye devam ettiğiniz sürece yeni kavramlar her seferinde biraz daha hızlı anlaşılır olacaktır.

Eğer tecrübeli biriyseniz, lütfen öğrendiğinizi de gösterin. Kaynaklarınızı paylaşın, sorular sorun ve yeni bulduğunuz -şeyleri- insanlara anlatın. 1 numaralı becerinin öğrenmek olduğunu ve bunun çok zaman aldığını kabul edersek, sektörümüzü daha iyi bir hale getirebiliriz.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Shell Sort GoLang İmplementasyonu

Sat, 29 Feb 2020 00:00:00 GMT

Shell Sort(Kabuk Sıralama) temel olarak Insertion Sort(Araya Sokma Sıralaması)‘nın bir varyasyonudur. Insertion Sort’da bir eleman sadece yanındaki elemanlarla sırayla karşılaştırılır. Bundan dolayı bir elemanın bulunduğu pozisyona çok uzak bir noktaya gidebilmesi için birçok karşılaştırma yapılması gerekir. Shell Sort birbirine uzak elemanların önceden karşılaştırılmasına ve yer değiştirmesine izin vererek verim sağlamaya çalışır. Sıralamayı aynı dizi üzerinde yapar, Insertion Sort gibi fazladan yer ihtiyacı yoktur.

Shell Sort’un çalışma mantığını bir örnek üzerinden inceleyelim.

Sıralanacak dizimiz şu olsun:

6, 8, 9, 4, 5, 7, 9, 11, 12, 2, 1, 3

Shell Sort’ta ilk olarak gap’ler belirlenir. Gap denilen şey kaç tane sütün oluşturulacağının belirlenmesidir. Burada gap’in 4 olarak seçildiğini düşünelim.

6, 8, 9, 4, 
5, 7, 9, 11, 
12, 2, 1, 3

Gap’ler belirlendikten sonra her sütün kendi arasında sıralanır.

5, 2, 1, 3, 
6, 7, 9, 4, 
12, 8, 9, 11

Sıralama işleminden sonra tüm sütünlar bir araya getirilir.

5, 2, 1, 3, 6, 7, 9, 4, 12, 8, 9, 11

Yukarıdaki aşama tekrar uygulanır. Fakat bu defa gap bir öncekinin yarısı olarak seçilir. Gap = 4 / 2 = 2.

5, 2, 
1, 3, 
6, 7, 
9, 4, 
12, 8, 
9, 11

Sütünlar tekrar kendi arasında sıralanır:

1, 2, 
5, 3, 
6, 4, 
9, 7, 
9, 8, 
12, 11

Sütünlar tekrar bir araya getirilir:

1, 2, 5, 3, 6, 4, 9, 7, 9, 8, 12, 11

Son olarak yukarıdaki aşama 1’lik gap’ler ile tekrarlanır ve bu şekilde de sıralı diziye ulaşılmış olur.

1, 2, 3, 4, 5, 6, 7, 8, 9, 9, 11, 12

Yukarıdaki örneğin GoLang’de uygulanmış halini aşağıdan inceleyebilirsiniz.

package main

import (
	"fmt"
)

func main() {
	array := []int{6, 8, 9, 4, 5, 7, 9, 11, 12, 2, 1, 3}
	ShellSort(array)
	fmt.Println(array)
}

func ShellSort(array []int) {
	for gap := len(array) / 2; gap > 0; gap /= 2 {
		for i := gap; i < len(array); i++ {
			x := array[i]
			j := i
			for ; j >= gap && array[j-gap] > x; j -= gap {
				array[j] = array[j-gap]
			}
			array[j] = x
		}
	}
}

Kodun çalışır halini test etmek için => RUN

Shell Sort’un çalışma hızını test etmek için daha kapsamlı bir algoritma örneğini de aşağıdan incelenebilir.

shell.go

package main

import (
	"sort"
)

// https://en.wikipedia.org/wiki/Shellsort
func ShellSort(s sort.Interface) {

	delta := s.Len()

	for delta > 1 {
		delta = int(float32(delta) * 0.5)

		for i := delta; i < s.Len(); i++ {
			it := i
			var j int

			for j = i; (j >= delta) && (s.Less(it, j-delta)); j -= delta {
				if j == it {
					it = j - delta
				} else if (j - delta) == it {
					it = j
				}
				s.Swap(j, j-delta)
			}

			s.Swap(j, it)
		}
	}
}

shell_test.go

package main

import "testing"

func TestShellSort(t *testing.T) {
	s := NewRandom(20, 7)
	ShellSort(s)
}

func BenchmarkShellSort(b *testing.B) {
	BenchAlgorithm(b, ShellSort)
}

helper_test.go

package main

import (
	"fmt"
	"math/rand"
	"sort"
	"testing"
)

type SortType []uint

func (a SortType) Len() int           { return len(a) }
func (a SortType) Swap(i, j int)      { a[i], a[j] = a[j], a[i] }
func (a SortType) Less(i, j int) bool { return a[i] < a[j] }

func NewRandom(length uint, seed int64) SortType {
	s := rand.NewSource(seed)
	r := rand.New(s)
	st := New(length)

	r.Shuffle(len(st), func(i, j int) {
		st[i], st[j] = st[j], st[i]
	})

	return st
}

func New(length uint) SortType {
	s := make(SortType, length)

	for i := range s {
		s[i] = uint(i) + 1
	}

	return s
}

func NewReversed(length uint) SortType {
	s := make(SortType, length)

	for i := range s {
		s[i] = length - uint(i)
	}

	return s
}

func NewNearlySorted(length uint, seed int64, sparse uint) SortType {
	s := rand.NewSource(seed)
	r := rand.New(s)
	st := New(length)

	for i := 0; uint(i) < length; i++ {
		newIndex := uint(i + r.Intn(int(sparse)))

		if newIndex < length {
			st[i], st[newIndex] = st[newIndex], st[i]
		}
	}

	return st
}

func NewFewUnique(length uint, seed int64, groups uint) SortType {
	s := rand.NewSource(seed)
	r := rand.New(s)
	st := make(SortType, length)

	for i := uint(0); i < length; i += groups {
		for j := i; j < length; j++ {
			st[j] = i + 1
		}
	}

	r.Shuffle(len(st), func(i, j int) {
		st[i], st[j] = st[j], st[i]
	})

	return st
}

func NewOfType(t string, length uint, seed int64) SortType {
	switch t {
	case "random":
		return NewRandom(length, seed)
	case "nearlysorted":
		return NewNearlySorted(length, seed, length/8)
	case "reversed":
		return NewReversed(length)
	case "fewunique":
		return NewFewUnique(length, seed, (length/10)+1)
	}
	panic(fmt.Sprintf("Unknown type %v", t))
}

func BenchAlgorithm(b *testing.B, f func(sort.Interface)) {
	benchTypes := []string{
		"random",
		"nearlysorted",
		"reversed",
		"fewunique",
	}

	slicesLengths := []uint{10}

	for _, t := range benchTypes {
		b.Run(t, func(b *testing.B) {
			for _, n := range slicesLengths {
				b.Run(fmt.Sprintf("%v", n), func(b *testing.B) {
					b.StopTimer()
					for i := 0; i < b.N; i++ {
						slice := NewOfType(t, n, int64(int(n)*b.N))
						b.StartTimer()
						f(slice)
						b.StopTimer()
					}
				})
			}
		})
	}
}

Benchmark.go

BenchmarkShellSort/random/10-12                  3000000               538 ns/op
BenchmarkShellSort/random/25-12                  1000000              1294 ns/op
BenchmarkShellSort/random/50-12                   500000              3033 ns/op
BenchmarkShellSort/random/100-12                  200000              7600 ns/op
BenchmarkShellSort/random/200-12                  100000             24155 ns/op
BenchmarkShellSort/random/300-12                   50000             34732 ns/op
BenchmarkShellSort/random/600-12                   20000             84596 ns/op
BenchmarkShellSort/random/1000-12                  10000            151735 ns/op
BenchmarkShellSort/random/2000-12                   5000            371222 ns/op
BenchmarkShellSort/random/5000-12                   2000           1102749 ns/op
BenchmarkShellSort/nearlysorted/10-12            3000000               480 ns/op
BenchmarkShellSort/nearlysorted/25-12            2000000               999 ns/op
BenchmarkShellSort/nearlysorted/50-12             500000              2580 ns/op
BenchmarkShellSort/nearlysorted/100-12            300000              6373 ns/op
BenchmarkShellSort/nearlysorted/200-12            100000             16416 ns/op
BenchmarkShellSort/nearlysorted/300-12             50000             29462 ns/op
BenchmarkShellSort/nearlysorted/600-12             20000             68368 ns/op
BenchmarkShellSort/nearlysorted/1000-12            10000            130586 ns/op
BenchmarkShellSort/nearlysorted/2000-12             5000            303023 ns/op
BenchmarkShellSort/nearlysorted/5000-12             2000            939944 ns/op
BenchmarkShellSort/reversed/10-12                2000000               703 ns/op
BenchmarkShellSort/reversed/25-12                1000000              1253 ns/op
BenchmarkShellSort/reversed/50-12                 500000              2762 ns/op
BenchmarkShellSort/reversed/100-12                300000              5716 ns/op
BenchmarkShellSort/reversed/200-12                100000             13647 ns/op
BenchmarkShellSort/reversed/300-12                100000             22099 ns/op
BenchmarkShellSort/reversed/600-12                 30000             49397 ns/op
BenchmarkShellSort/reversed/1000-12                20000             87561 ns/op
BenchmarkShellSort/reversed/2000-12                10000            189891 ns/op
BenchmarkShellSort/reversed/5000-12                 3000            568537 ns/op
BenchmarkShellSort/fewunique/10-12               3000000               489 ns/op
BenchmarkShellSort/fewunique/25-12               1000000              1189 ns/op
BenchmarkShellSort/fewunique/50-12                500000              2693 ns/op
BenchmarkShellSort/fewunique/100-12               200000              6040 ns/op
BenchmarkShellSort/fewunique/200-12               100000             16905 ns/op
BenchmarkShellSort/fewunique/300-12                50000             24623 ns/op
BenchmarkShellSort/fewunique/600-12                20000             56229 ns/op
BenchmarkShellSort/fewunique/1000-12               20000            100739 ns/op
BenchmarkShellSort/fewunique/2000-12               10000            230638 ns/op
BenchmarkShellSort/fewunique/5000-12                2000            639915 ns/op

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

GoLang de İki Dizi Arasındaki Farkı Bulma

Wed, 29 Jan 2020 00:00:00 GMT

Elimizde iki adet dizi olduğu düşünelim. Bu iki diziden bir tanesinin elemanlarının diğer dizinin içerisinde olmayanlarını belirlemek istediğimizde, bu iki diziyi bir karşılaştırma işlemine sokmamız gerekiyor. Aşağıda bu işlemi GoLang programlamla dilinde yerine getiren örnek bir fonksiyon yer almaktadır.

Örnek diziler ve bu dizilerin karşılaştırması sonucunda elde edilmesi beklenen çıktı şu şekilde:

dizi1 := []int8{1, 2, 3, 4, 5}
dizi2 := []int8{3, 4, 5}

// sonuç
dizi1 / dizi2 => {1, 2}

GoLang de iki diziyi karşılaştırıp farkını bulan fonksiyon:

func difference(a, b []int8) []int8 {

    target := map[int8]bool{}
    for _, x := range b {
        target[x] = true
    }

    result := []int8{}
    for _, x := range a {
        if _, ok := target[x]; !ok {
            result = append(result, x)
        }
    }

    return result
}

İki dizinin farkını bulma işlemi:

func main() {
	
    array1 := []int8{1, 2, 3, 4, 5}
    array2 := []int8{3, 4, 5}

    result := difference(array1, array2)
    fmt.Println("array1 / array2 => ", result)
    // output: array1 / array2 =>  [1 2]

    result2 := difference(array2, array1)
    fmt.Println("array2 / array1 => ", result2)
    // output: array2 / array1 =>  []
}

Kodun çalışır halini test etmek için => RUN

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Turbojet, Turboprop ve Propellerjet Arasındaki Farklar

Wed, 27 Nov 2019 00:00:00 GMT

Turbojet, en basit jet motorudur. Giriş, sıkıştırma, yanma, türbin ve çıkış bölümlerinden oluşur. Diğer tüm jet moturu tipleri, bu motor türüne dayanmaktadır.

Bu nedenle en başta turbojet motorların çalışma şeklini anlamamız, turboprop ve propeller-jet motorların çalışma mantığını anlamamıza yardımcı olacaktır.

Turbojet motorlarında hava kompresör tarafından emilir ve hacmini düşürmek ve sıcaklığını arttırmak için sıkıştırılır. Ardından yüksek sıcaklık ve basınçtaki hava yakıtla karıştığı ve çok yüksek sıcaklıkta yandığı yanma odasına girer. Bu işlemin sonucunda elde edilen sıcak gazlar, kompresöre bir mil aracılığıyla bağlanan türbini döndürür.

Türbin, kompresörün istenen RPM’de dönmesini sağlamak amacıyla üretilen enerjinin yaklaşık %60’ını emer. Enerjinin geri kalan %40’ı, sıcak gazlar şeklinde motorun arka tarafından yüksek hızda dışarıya atılır. Newton’un III. Yasası her etki için aynı büyüklükte ve ters yönde bir tepki olduğunu söylemektedir. Bu kural hava motordan çıktığında işlemektedir. Yüksek hızlı gazlar geriye doğru hareket eder (hareket) ve motor ileri doğru hareket eder (reaksiyon).

Turbojet motorlu uçaklar yüksek hızda ve irtifada yakıt tasarrufluyken pervaneli uçaklar düşük veya orta hızda yakıt tasarrufludur. Bunun sebebi, pervanelerin belirli hızlardan sonra çok fazla sürükleme (drag forca) üretmesidir. Bu nedenle pervaneli uçaklar turbojetli uçaklar kadar hızlı uçamazlar.

Yüksek hızlı uçaklar, kısa kalkış ve iniş için uygun olmayan arka kanat tasarımına sahiptir. Tasarımları dolayısıyla yavaş uçaklar kısa pistlerde kalkış ve iniş yapabilirler. Bu nedenle onları turboprop-lar gibi daha çok yakıt verimliliği sağlayan motorlarla donatmak mantıklıdır.

Turboprop motorların mimarisi (yukarıda) oldukça basittir. Turbojet motorların önüne bir dişli kutusu ve pervane eklenerek turboprop motorlar elde edilebilir.

Pervaneli jet motorlarının mimarisine ve özelliklerine bakmadan önce turbofan motorlarından da bahsetmek gerekmektedir.

Turbojet motorlarının aksine, ön kısımdan giren havanın çoğu yanma odasından geçmez. Türbine bir mil aracılığıyla bağlanan büyük kanallı bir fan, motorun etrafındaki havayı hızlandırır. Bypass motorları olarak da bilinen turbofan motorları, turbojet motorlarına göre daha çok yakıt tasarrufu sağlarlar ve daha sessiz çalışırlar.

Temelde propeller jet motorları ve turboprop motorları aynı şeylerdir. Bir jet motoru, bir güç kontrol kolu veya PCL tarafından kontrol edilen bir pervaneyi döndürür.

Propeller jet motorları ilginç bir motor türüdür (yukarıda). Tasarımı bir turbofanın tam tersidir fakat by-pass oranı turbofanlardan oldukça yüksektir. Bu yüzden ultra yüksek by-pass motoru olarakta adlandırılırlar.

Ultra yüksek by-passlı bir motor, eşdeğer bir turbofan motorundan %25 daha az yakıt yakar. Jet motorları gibi yüksek hız ve yüksek irtifa için uygundur ancan iki nedenden dolayı ticari kullanım için uygun değildir:

İzin verilen gürültü standartlarını karşılamamak
Yalnızca kuyruğa monte edilebilmesi.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Uçakların Uçmasında Aerodinamik Kuvvetlerin Etkisi

Tue, 12 Nov 2019 00:00:00 GMT

Amatör olarak havacılık ile ilgileniyorum. Uçaklarda kullanılan teknolojilere, uçağın uçmak için hazırlanması sürecindeki işleyişe, insanların-kargoların uçağa ulaştırılması ve uçaktan çıkartılması süreçlerine hayranlık duyuyorum. “Uçmak insanlık için en önemli başarı mı?” tartışılabilecek bir konu ama uçmak için kanatlara sahip olmayan varlıklar olarak doğanın kurallarına meydan okuduğumuz kesin.

Bu yazı aerodinamik kuvvetleri ve uçakların nasıl uçtuğu ile ilgili. Havacılıkla hiç ilgimiz olmasa da aerodinamik kuvvetlerini okuyup uçakların nasıl hareket ettiğini anlamak hiç zor değil.

Uçakları düşündüğümüzde birçok insan en önemli elemanın motorlar olduğunu düşünür fakat bu doğru değildir. Bir uçağı havada tutan ve ağırlığını dengeleyen ana eleman kanatlardır. Planörleri, kağıt uçakları, kuşları düşündüğümüzde motorsuz bir şekilde uçma eyleminin gerçekleşebildiğini görebiliriz. Tabii bu motorlar gereksiz anlamına da gelmemektedir. :)

Aerodinamik kuvvetlerini anlayarak bir uçağın nasıl uçtuğunu kolayca anlayabiliriz. Aerodinamik; hareket eden katı kütlelerin havayla etkileşimini inceler. Basitçe; aerodinamik nesnelerin havada hareket etme şeklidir ve aerodinamik kuralları bir uçağın nasıl uçtuğunu açıklamaktadır. Havada hareket eden uçaklara etki eden 4 adet kuvvet vardır. Bunlar:

Lift (kaldırma)
Thrust (itme)
Drag (sürükleme)
Weight (ağırlık)'tır.

Ağırlık uçaklara etki eder ama bir aerodinamik kuvvet değildir.

Lift Force (Kaldırma Kuvveti)

Aşağıdaki şekilden de anlaşılacağı gibi lift (kaldırma) yukarı yönde etki eden aerodinamik kuvvettir. Lift, uçağın havada kalmasını sağlar. Yukarı yönlü bu kuvvet, uçağın ağırlığını dengeler ve lift (kaldırma)‘in weight (ağırlık)‘ten büyük olduğu durumda uçak yükselir. Peki lift nasıl oluşturulur. Tabii ki uçağın kanatlarının yardımıyla.

Yukarıdaki fotoğraf bir uçak kanadının şeklini göstermektedir. Uçak kanatlarının üstü kavisli, alt tarafları ise düzdür. Bu şekil havanın yukarıdan aşağıya doğru daha hızlı akmasını sağlar. Sonuç olarak da altta yüksek basınç, üst kısımda da alçak basınç oluşur. Bu basınç farkı kanadı ve ona bağlı uçağı yukarı hareket ettirir.

Thrust Force (İtme Kuvveti)

İtme gücü, uçağı ileri doğru iten jet motorları-pervaneler-roketler tarafından üretilen kuvvettir. Thrust (itme) drag (sürükleme)‘den yüksek olduğunda uçak ileri doğru hareket eder.

Thrust (itme) kuvvetinin oluşması motorların işlevinde saklıdır. Tüm motorlar, girişten (inlet) havayı alır ve kompresör ile sıkıştırır. Ardından türbin içerisindeki yanma odasında yakıtı kullanarak yakar ve enerji üretilir. Daha sonra yüksek basınçlı hava motorun arka tarafından yüksek hızda dışarı çıkartılır. Newton’un III. Yasası her etki için aynı büyüklükte ve ters yönde bir tepki olduğunu söylemektedir. Bu kural hava motordan çıktığında işlemektedir. Yüksek hızlı hava motordan çıktığında uçağı ileri doğru itmektedir.

Drag Force (Sürükleme Kuvveti)

Her harekette, kesinlikle bir miktar dirençli kuvvet vardır. Uçağın hareketine karşı çıkan kuvvette Drag (sürükleme) kuvvetidir. Bir nesnenin şekli sürükleme miktarını etkilemektedir. Dar yüzeyler genellikle geniş olanlardan daha az sürtünmeye sahiptir. Aynı şekilde yuvarlak yüzeyler de genellikle düz olanlardan daha az sürtünmeye sahiptir. Bir yüzeye çarpan hava miktarı arttığında drag(sürükleme)‘nin kuvveti de artacaktır.

Bu sebeplerle uçaklar maksimum lift (kaldırma) ve minimum drag (sürükleme) üretecek şekilde tasarlanırlar.

Weight Force (Ağırlık Kuvveti)

Ağırlık tüm kuvvetlerin en basiti ama en önemlisidir. Bu yüzden uçak yapı mühendisliğinin ana kuralı şudur: “Mümkün olduğu kadar hafif tasarla”.

Burada Kartopu Etkisi‘nden bahsedilebilir.

Bir uçağın ağırlığını azaltırsanız, uçmak için daha az miktarda kaldırma kuvveti gerekecektir. Daha düşük kaldırma ihtiyacı da kanat boyutunu küçültebileceğiniz anlamına gelir. Yine daha küçük motorlar daha az sürtünmeye sebep olur, bu nedenle daha küçük motorlarla üretilecek daha az itme kuvveti yeterli olur. Sonunda da daha küçük motorlar ve kanat boyutu, uçak ağırlığında daha da azalmaya yol açacaktır.

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Heap Sort ile Veri Sıralama Sanatı

Sun, 10 Nov 2019 00:00:00 GMT

Sıralama algoritmaları, bilgisayar bilimlerinin temel taşlarından birini oluşturur. Bilgisayarlar verilerle çalışırken, bu verileri düzenlemek ve sıralamak sıklıkla karşılaşılan bir gerekliliktir. Bu nedenle, sıralama algoritmaları bilgisayar bilimleri ve yazılım geliştirmenin vazgeçilmez bir parçasıdır. Veri sıralamasının birçok farklı alanda kullanıldığına tanık olabiliriz, örneğin veri tabanlarındaki kayıtların sıralanması, arama motorlarının sonuçlarının sıralanması, grafiklerin çizdirilmesi sırasında verilerin düzenlenmesi gibi birçok uygulama bu temel işlemi gerektirir. Bu yüzden bilim insanları ve yazılım geliştiricileri, veri sıralama işlemi için en verimli ve etkili yöntemleri geliştirmeye ve optimize etmeye çalışırlar. Bu amaçla birçok farklı sıralama algoritması tasarlanmış ve incelenmiştir.

Heap Sort Nedir?

Heap Sort, veri sıralama işlemi için kullanılan bir karşılaştırmalı sıralama algoritmasıdır. Bu algoritma, veriyi bir ağaç yapısı olan bir “heap” (yığın) kullanarak sıralar. Heap, bir ağaç yapısı olup her düğümün iki alt düğümü vardır. Bununla birlikte, Heap Sort’ta kullanılan heap, “maksimum heap” veya “minimum heap” olarak adlandırılır ve belirli bir özelliği korur: Her düğümün üst düğümden daha büyük (maksimum heap) veya daha küçük (minimum heap) olması gerekir.

Heap Sort, bu maksimum veya minimum heap yapısını kullanarak sıralama işlemini gerçekleştirir. İşlem sırasında, heap yapısı verilerin yeniden düzenlenmesi için kullanılır ve sonuç olarak sıralanmış bir veri dizisi elde edilir.

Heap Sort Nasıl Çalışır?

Heap Sort algoritması aşağıdaki adımları izler:

Başlangıçta Max Heap Oluşturma: İlk adım, veri dizisini bir maksimum heap yapısı haline getirmektir. Bu, diziyi baştan sona dolaşarak heap özelliğini sağlamak için “heapify” adı verilen bir işlemi içerir. Bu işlem, her düğümün üst düğümden daha büyük olduğundan emin olur.
Kök Düğümü ile Son Elemanı Değiştirme: Maksimum heap yapısının oluşturulmasının ardından, kök düğümü (en büyük eleman) ile son elemanın yerini değiştirilir. Bu, en büyük elemanın sıralanan bölümün sonuna taşınması anlamına gelir.
Heap Boyutunu Azaltma: Veri dizisinin sonundaki eleman artık sıralanmıştır, bu nedenle heap boyutunu bir azaltırız. Yani heap yapısının son elemanını çıkarırız.
Heapify İşlemi: Kök düğümünü tekrar heap özelliğini sağlayacak şekilde düzenlemek için “heapify” işlemi yapılır.
Tekrarlama: Adımlar 2-4, heap yapısı tamamen boşalana kadar tekrarlanır. Bu, veri dizisi tamamen sıralanana kadar devam eder.
Sonuç: Heap yapısı tamamen boşaldığında, veri dizisi sıralanmış olur ve işlem tamamlanır.

Aşağıda, Heap Sort algoritmasının basit bir pseudocode örneği verilmiştir:

procedure heapSort(arr):
    n = length(arr)

    for i from n/2 down to 1:
        heapify(arr, n, i)

    for i from n down to 2:
        swap(arr[1], arr[i])
        heapify(arr, i-1, 1)

procedure heapify(arr, n, i):
    largest = i
    leftChild = 2 * i
    rightChild = 2 * i + 1

    if leftChild <= n and arr[leftChild] > arr[largest]:
        largest = leftChild

    if rightChild <= n and arr[rightChild] > arr[largest]:
        largest = rightChild

    if largest != i:
        swap(arr[i], arr[largest])
        heapify(arr, n, largest)

Heap Sort’un Zaman ve Alan Karmaşıklığı

Heap Sort, en kötü durumda O(n log n) zaman karmaşıklığına sahiptir. Ayrıca, ekstra bir bellek gerektirmez, bu nedenle O(1) ekstra bellek karmaşıklığına sahiptir. Bu özellikleri nedeniyle Heap Sort, büyük veri setleri üzerinde etkili bir sıralama algoritmasıdır.

Kullanım Alanları

Heap Sort, genellikle yerleşik sıralama fonksiyonları kullanılamadığında veya sabit bellek kullanımı gerektiren uygulamalarda tercih edilir. Özellikle gömülü sistemlerde, işlemci kaynakları sınırlı olduğunda ve harici belleğin kullanılmasına izin verilmediğinde tercih edilen bir sıralama algoritmasıdır.

Heap Sort, etkili bir sıralama algoritmasıdır ve genellikle veri sıralamak için kullanılır. Max Heap yapısının kullanımı ve veri dizisinin sürekli olarak yeniden düzenlenmesi, bu algoritmanın veri sıralama işlemi için etkili bir yol olduğunu gösterir. Ancak, daha hızlı sıralama algoritmaları mevcut olduğunda ve ekstra bellek kullanımına izin verildiğinde, bu alternatifler tercih edilebilir.

Heap Sort, bilgisayar bilimlerinin temel konularından biridir ve sıralama algoritmaları hakkında daha fazla bilgi edinmek isteyenler için önemli bir başlangıç noktasıdır.

GoLang’de Heap Sort uygulaması:

package main

import "fmt"

func heapSort(arr []int) {
    n := len(arr)

    for i := n/2 - 1; i >= 0; i-- {
        heapify(arr, n, i)
    }

    for i := n - 1; i > 0; i-- {
        arr[0], arr[i] = arr[i], arr[0]
        heapify(arr, i, 0)
    }
}

func heapify(arr []int, n, i int) {
    largest := i
    leftChild := 2*i + 1
    rightChild := 2*i + 2

    if leftChild < n && arr[leftChild] > arr[largest] {
        largest = leftChild
    }

    if rightChild < n && arr[rightChild] > arr[largest] {
        largest = rightChild
    }

    if largest != i {
        arr[i], arr[largest] = arr[largest], arr[i]
        heapify(arr, n, largest)
    }
}

func main() {
    arr := []int{12, 11, 13, 5, 6, 7}
    fmt.Println("Unsorted Array:", arr)

    heapSort(arr)

    fmt.Println("Sorted Array:", arr)
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

Unsorted Array: [12 11 13 5 6 7]
Sorted Array: [5 6 7 11 12 13]

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

https://en.wikipedia.org/wiki/Heapsort

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Fibonacci Arama: Sıralı Dizilerde Etkili Bir Arama Yöntemi

Fri, 14 Jun 2019 00:00:00 GMT

Arama algoritmaları, bilgisayar bilimlerinin temel taşlarından birini oluşturur ve geniş bir uygulama yelpazesi bulunmaktadır. Veri işleme, veri tabanları, bilgisayar grafikleri ve daha birçok alanda, verileri düzenlemek ve hedeflenen bilgilere erişmek için arama algoritmalarına ihtiyaç duyulur. Bu makalede, geleneksel arama algoritmalarından farklı bir yaklaşım olan Fibonacci Search tekniği üzerinde bir inceleme yapacağız.

Fibonacci Search Nedir?

Fibonacci Search, sıralanmış bir dizi içinde bir öğenin konumunu belirlemek için Fibonacci sayılarını kullanır. Bu algoritma, veri koleksiyonunun belirli bir bölümünü ele alır ve bu bölümü alt dizilere bölerken Fibonacci sayılarına dayalı bir indeks hesaplaması yapar. Bu yaklaşım, veri koleksiyonu içindeki hedef öğeyi hızlı bir şekilde bulmak için kararlı ve etkili bir yol sunar.

Fibonacci Sayıları Nedir?

Fibonacci sayıları, her sayının kendisinden önceki iki sayının toplamı olduğu bir sayı dizisidir. Bu sayı dizisi şu şekildedir: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, … Fibonacci sayılarının özelliği, sayılar büyüdükçe birbirleriyle oranlarının yaklaşık olarak 1.61803 (altın oran) olduğudur.

Fibonacci Search Algoritması

Fibonacci Search algoritması aşağıdaki adımları izler:

Başlangıçta iki Fibonacci sayısı olan F(k-2) ve F(k-1) seçilir, böylece F(k-1) koleksiyonun boyutundan küçük ve F(k-2) koleksiyonun boyutundan büyük olur.
Şu andaki aralık arr[0..F(k)] içinde bir öğeyi aramak için k değeri hesaplanır.
arr[F(k-2)] ve arr[F(k-1)] arasında bir karşılaştırma yapılır.
- Eğer aranan öğe, arr[F(k-2)]‘den küçükse, arama aralığı arr[0..F(k-2)] olarak güncellenir ve işlem tekrarlanır.
- Eğer aranan öğe, arr[F(k-2)]‘den büyükse, arama aralığı arr[F(k-2)..F(k-1)] olarak güncellenir ve işlem tekrarlanır.
- Eğer aranan öğe, arr[F(k-2)] ile arr[F(k-1)] arasındaki öğeye eşitse, öğe bulunmuş olur.
Aranan öğe bulunana kadar veya arama aralığı boşalana kadar bu adımlar tekrarlanır.

Aşağıda, Fibonacci Search algoritmasının basit bir pseudocode örneği verilmiştir:

function FibonacciSearch(arr, x):
    n = length(arr)
    fibM = 0    // Fib(k-2)
    fibN = 1    // Fib(k-1)
    fibK = fibM + fibN

    while (fibK < n):
        fibM = fibN
        fibN = fibK
        fibK = fibM + fibN

    offset = -1

    while (fibK > 1):
        i = min(offset + fibM, n - 1)

        if (arr[i] < x):
            fibK = fibN
            fibN = fibM
            fibM = fibK - fibN
            offset = i

        else if (arr[i] > x):
            fibK = fibM
            fibN = fibN - fibM
            fibM = fibK - fibN

        else:
            return i  // Element found at index i

    if (fibN == 1 && arr[offset + 1] == x):
        return offset + 1  // Element found at index offset + 1

    return -1  // Element not found

Zaman ve Alan Karmaşıklığı

Fibonacci Search, ortalama durumda O(log n) zaman karmaşıklığına sahiptir. En kötü durumda da O(n) kadar iyi performans gösterir. Alan karmaşıklığı ise O(1) olarak kabul edilir.

Kullanım Alanları

Fibonacci Search, özellikle büyük sıralanmış koleksiyonlarda ve özellikle altın oranın belirli bir rol oynadığı alanlarda kullanılır. İdeal olarak, aranacak öğenin yerini yaklaşık olarak tahmin etmek ve bu nedenle aramayı optimize etmek istediğiniz durumlar için uygundur.

Fibonacci Search, geleneksel arama algoritmalarından farklı bir yaklaşım sunar ve sıralanmış veri koleksiyonlarında hızlı arama yapmak için kullanışlıdır. Fibonacci sayılarının özelliği, bu algoritmanın verimliliğini artırır. Ancak, veri koleksiyonlarının boyutu ve yapısı gibi faktörler algoritmanın performansını etkileyebilir, bu nedenle kullanmadan önce dikkatlice düşünülmesi gereken bir yöntemdir.

GoLang’de Fibonacci Search uygulaması:

package main

import (
	"fmt"
)

func FibonacciSearch(arr []int, x int) int {
	n := len(arr)
	fibM, fibN, fibK := 0, 1, 0

	for fibK < n {
		fibM, fibN = fibN, fibK
		fibK = fibM + fibN
	}

	offset := -1

	for fibK > 1 {
		i := min(offset+fibM, n-1)

		if arr[i] < x {
			fibK = fibN
			fibN = fibM
			fibM = fibK - fibN
			offset = i
		} else if arr[i] > x {
			fibK = fibM
			fibN = fibN - fibM
			fibM = fibK - fibN
		} else {
			return i
		}
	}

	if fibN == 1 && arr[offset+1] == x {
		return offset + 1
	}

	return -1
}

func min(x, y int) int {
	if x < y {
		return x
	}
	return y
}

func main() {
	arr := []int{10, 22, 35, 40, 45, 50, 80, 82, 85, 90, 100}
	x := 85

	index := FibonacciSearch(arr, x)
	if index != -1 {
		fmt.Printf("%d found at index %d.\n", x, index)
	} else {
		fmt.Printf("%d not found.\n", x)
	}
}

Program çalıştırıldığında çıktısı aşağıdaki gibi olacaktır.

85 found at index 8.

Programın çalışır haline şuradan erişilebilir.

Kaynaklar

https://en.wikipedia.org/wiki/Fibonacci_search_technique

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Kanı-İstek-Hedef Etmenlerinin Geliştirilmesi için bir Tersine Mühendislik Yöntemi

Mon, 04 Feb 2019 00:00:00 GMT

Ege Üniversitesi Uluslararası Bilgisayar Enstitüsünde Bilgisayar Bilimleri alanındaki yüksek lisansımı Doç. Dr. Geylani KARDAŞ hocamın danışmanlığında, yazılım mühendisliği konusunda yazdığım bir tez ile bitirdim.

“Kanı-İstek-Hedef Etmenlerinin Geliştirilmesi için bir Tersine Mühendislik Yöntemi” ismini taşıyan tez çalışmamda; otonom çalışma yeteneğine sahip yazılım etmenlerinin geliştirilmesi sürecini kolaylaştıran model güdümlü mimarilerdeki bir eksikliğin giderilmesi için bir yöntem önermekteyiz. Buradaki eksik, model yardımıyla tasarlanıp sonrasında çalıştırılabilir kodları üretilen etmen yazılım sistemlerinde, son çalıştırılabilir kodda yapılan değişikliklerin tasarım modellerine aktarılamamasıdır. Bu eksiklik yeniden yapılan her modelden kod üretimi işleminde, kodda yapılan son değişikliklerin yeni sisteme aktarılamamasına sebep olmaktadır.

Tez çalışmasının sonuçları 7. Ulusal Yazılım Mimarisi Konferansı (UYMK 2018) (29-30 Kasım 2018, İstanbul, Türkiye, ss. 1-16)‘de yayınlanmıştır. Tez’e erişmek için tıklayınız

YÖK tarafından kabul edilen tez çalışması 539474 tez numarası ile YÖK Tez Merkezi‘de yayınlanmıştır. Tez’i indirmek için tıklayınız

Tez’in özet kısmını okuyup bilgi sahibi olmak isteyenler aşağıda özet kısmını bulabilirler:

Kanı-İstek-Hedef (BDI) etmenlerinin model-güdümlü mimari kullanılarak geliştirilmesinde, genellikle yukarıdan aşağıya bir yaklaşım izlenerek, etmenler önce tanımlanan bir üstmodele göre çeşitli bakışaçılarından modellenmektedir. Sonrasında, hazırlanan bu modeller bir dizi modelden modele ve modelden koda dönüşümlere girdi olarak verilmektedir. Bu dönüşümler işletilerek etmen yazılımlarının otomatik elde edilmesi sağlanmaktadır. Fakat bu süreçte kod üretiminin ardından geliştiricilerin yazılım kodlarında yapacakları değişiklikler etmen tasarım modellerine yansıtılamamaktadır. Mevcut çalışmalarda görülen bu eksiklik, özellikle hazırlanan etmen modellerinin ve yazılımlarının yeniden kullanılabilirliğini zorlaştırmaktadır. Bu tezde, söz konusu eksikliği gidermek amacıyla etmen sistemlerinin yazılım kodlarından BDI modellerinin otomatik elde edilmesini sağlayacak bir tersine mühendislik yöntemi ve bunu destekleyen bir araç geliştirilmiştir. Yeni yöntemin uygulanması ile yaygın kullanıma sahip JACK platformu üzerinde çalışan yazılımlardan etmenlerin BDI modellerinin geri elde edilmesi ve böylece kodlardaki değişikliklerin etmen yazılım modellerine yansıtılması mümkün hale getirilmiştir.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Bir Alt Dizin için Virtual Host Oluşturma

Mon, 22 Oct 2018 00:00:00 GMT

Virtual Host (Sanal Konak), bir sunucu üzerinde birden fazla siteyi barındırmak istediğimizde kullanılmaktadır. Örnek olarak 3 adet domainimiz ve sunucuda da 3 adet farklı projemiz(klasör diyebiliriz) olduğunu düşünelim.

example.com ---> /var/www/example
example2.com ---> /var/www/example2
example3.com ---> /var/www/example3

Bu domainlerin oklar ile gösterilen klasörlerdeki projeleri çalıştırmasını sağlamak için virtual host tanımlamalarını yapmamız gerekiyor. Bunun için aşağıdaki gibi bir tanımlama işimizi görecektir.

<VirtualHost *:80>
    DocumentRoot "/var/www/example"
    ServerName example.com
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/var/www/example2"
    ServerName example2.com
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/var/www/example3"
    ServerName example3.com
</VirtualHost>

Yukarıdaki tanımlamalar bize farklı domainler için farklı projeleri çalıştırma imkanını sağlamaktadır. Fakat aynı domain içerisinde farklı alt dizinlerin farklı projeleri çalıştırmasını Virtual Host ile nasıl sağlayabiliriz?

Bunun için yukarıdaki tanımlamaya yeni bir ekleme yapmamız yeterlidir. Örnek olarak bir adet domainimiz olduğunu ve 3 adet farklı projemiz olduğunu düşünelim.

example.com ---> /var/www/example
example.com/alt1 ---> /var/www/example2
example.com/alt2 ---> /var/www/example3

Bu domain ve alt dizinlerin oklarla gösterilen projeleri çalıştırmalarını sağlamak için Virtual Host tanımlamalarımızı şu şekilde organize etmemiz yeterli olmaktadır.

<VirtualHost *:80>
    DocumentRoot "/var/www/example"
    ServerName example.com

    Alias /alt1 "/var/www/example2"
    Alias /alt2 "/var/www/example3"
</VirtualHost>

Kaynaklar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Singleton Tasarım Deseni

Thu, 13 Sep 2018 00:00:00 GMT

Singleton, tasarım desenleri arasındaki en basit modellerden birisidir ve yaratıcı tasarım desenleri arasında yer almaktadır. Singleton ile sistem içerisinde bir sınıfın yalnızca bir tane nesnesinin oluşturulabilmesi garanti altına alınmaktadır.

Bazı durumlar da bir sınıfın yalnızca tek bir örneği işlemlerimizi gerçekleştirmemiz için yeterlidir. Örneğin, veri tabanı bağlansını gerçekleştiren bir sınıfımız olduğunu düşünelim. Bu sınıfımızı kullanmak isteyecek birden fazla nesnemiz olabilir/olacaktır. Böyle bir durumda her nesnenin bu sınıfı kullanmak için ayrı ayrı birden fazla veritabanı bağlantı nesnesi üretmeleri maliyetli ve gereksiz olacaktır. Bu durumun önüne geçmek için sistemde veritabanı sınıfından tek bir tane nesne üretilmesini ve veritabanı sınıfına ihtiyaç duyan nesnelerin bu nesneye erişmelerini sağlayacak bir sınıf işimizi görecektir.

Bu tasarım deseni kullanılarak, sistem içerisindeki genel değişkenler ya da değeri değişmeyen değişkenler tek bir nesnede toplanabilir. Sistem içerisinde tek nesne yaratılabilmesi yordamlar ve statik değişkenler yardımıyla gerçekleştirilebilir.

Yöntem 1. Klasik Yöntem

// Singleton tasarım deseninin Java'da klasik uygulaması 
class Singleton {
 
    private static Singleton instance; 
  
    // Singleton nesnesi oluşturmak için getInstance () kullanımını zorlayan özel kurucu 
    private Singleton() {} 
  
    public static Singleton getInstance() { 
        if (instance == null) 
            instance = new Singleton(); 
        return instance; 
    } 
}

Bu yöntemde nesne ilk defa kullanılmak istendiği sırada yaratılmaktadır. Bu nesne her kullanılmak istendiğinde tekrar yatılmaması için “instance == null” koşulu kullanılmaktadır.

Fakat bu klasik yöntem thread safe bir yapıda değildir. Aynı anda iki thread iki farklı nesne (veya daha fazla thread daha fazla nesne) oluşturabilir. Bu yüzden klasik yönteme thread safe bir yapı kazandırmamız gerekmektedir.

Yöntem 2. Eşzamanlı getInstance()

// Singleton tasarım deseninin thread eşzamanlı java uygulaması
class Singleton { 

    private static Singleton instance; 
  
    private Singleton() {} 
  
    // Bunu aynı anda yalnızca tek bir thread yürütebilir 
    public static synchronized Singleton getInstance() { 
        if (instance == null) 
            instance = new Singleton(); 
        return instance; 
    } 
}

Burada synchronized kullanarak, bir seferde sadece bir iş parçacığının (thread) getInstance() işlevini yürütebilmesini sağlamış oluyoruz.

Bu yöntemin dezavantajı, nesneyi oluştururken her seferinde synchronized kullanmanın (kontrolünün) pahalı olması ve programın performansını düşürebilmesidir. Ancak, getInstance() uygulamasının performansı uygulama için kritik değilse, bu yöntem temiz ve basit bir çözüm sağlamaktadır.

Yöntem 3. İstekli Yükleme

// Singleton tasarım deseninin statik başlatıcı tabanlı java uygulaması
class Singleton { 

    private static Singleton instance = new Singleton(); 
  
    private Singleton() {} 
  
    public static Singleton getInstance() { 
        return instance; 
    }
}

Burada ise nesne, sınıf belleğe yüklendiği anda oluşturulmaktadır. Bu yöntem yalnızca singleton sınıfına programın başlatılması sürecinde ihtiyaç duyuluyorsa kullanılmalıdır.

Yöntem 4. Çift Kontrol Kilitleme

Dikkat ettiğimizde, bir nesne oluşturulduktan sonra senkronizasyon artık yararlı olmaz çünkü artık instance null olmayacak ve herhangi bir işlem sırası tutarlı sonuçlar doğuracaktır.

Bu yüzden, instance null olduğunda, sadece bir kez getInstance() üzerindeki kilidi geçerli olur. Bu şekilde sadece ilk adımda senkronizasyon elde etmiş oluruz.

// Singleton tasarım deseninin çift kontrollü kilitleme tabanlı Java uygulaması
class Singleton { 

    private volatile static Singleton instance; 
  
    private Singleton() {} 
  
    public static Singleton getInstance() { 
        if (instance == null) { 
            // Thread safe
            synchronized (Singleton.class) { 
                // Birden fazla thread buraya ulaşabileceğinden tekrar kontrol
                if (instance == null) 
                    instance = new Singleton(); 
            }
        }
        return instance; 
    } 
}

Singleton instance başlatıldığında, birden çok iş parçacığının nesne değişkenini doğru bir şekilde sunmasını sağlayan tarafsızlığı tanımlamış olduk. Bu yöntem ile senkronize metodu her seferinde çağıran ek yükü büyük ölçüde azaltmış oluyoruz.

Referanslar

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Kaplumbağa ile Tavşan Yarışıyor [JAVA]

Mon, 09 Oct 2017 00:00:00 GMT

Bilgisayar bilimleri ile alakalı bölümlerin çoğunda, programlama derslerinin öğrenilmesi aşamasında, ödevlerde ya da sınavlarda öğrencilere yöneltilen bir probleme benim geliştirdiğim çözümü aşağıda paylaşmak istiyorum. Program ile ilgili tüm açıklamalar aşığıda yer almaktadır.

Program Yönergesi

İki yarışmacı da 70 tane karelik bir yolun ilk karesinden yarışa başlayacaktır. Her kare yarış boyunca yarışmacıların bulunabileceği yerleri ifade etmektedir. 70. kareye ilk varan ya da geçen, yarışmayı kazanacaktır. Yarış kaygan bir zeminde olduğu için yarışmacılar zaman zaman kayabilmektedir. Saniyede bir kere rasgele sayı üretilerek yarışmacıların hangi hareketi gerçekleştireceği belirlenecektir. Şekil 7.34’de yarışmacıların hangi hareketi yüzde kaç olasıkla gerçekleştirdiği verilmiştir. Eğer yarışmacılardan biri 1 karesinden geriye kayarsa onu yine 1 karesine alın (-değerli kareler kullanmayın. )

Kaplumbağa için, üretilen sayı i,1 <= i<=5 için “fast plod” hareketi, 6<=i<=7 ise “slip” hareketi, 8<=i<=10 için ise “slow plod” hareketi gerçekleştirilecektir. Her saniyede ,tavşan ve kaplumbağanın 70 parçalık yoldaki yerleri H ve T harfleri ile gösterilmelidir. İkisi aynı kareye düşerse H Ve T yerine OUCH yazdırılmalıdır. Yarış sonunda kaplumbağa kazanırsa “TORTOISE WINS!!! YAY!!” mesajı ekrana yazılmalıdır. Eğer tavşan kazanırsa “Hare wins. Yuch” mesajı, beraberlik olursa “It’s a tie” mesajı ekrana yazdırılmalıdır.

Kaplumbağa’nın hareket olasılıkları:
o Hızlı Hareket --- %50 --- 3 pozisyon sağa
o Geriye Kayma --- %20 --- 6 pozisyon sola
o Yavaş Hareket --- %30 --- 1 pozisyon sağa
Tavşa’nın hareket olasılıkları:
o Uyku Halinde --- %20 --- Hareket yok
o Büyük Hareket --- %20 --- 9 pozisyon sağa
o Büyük Kayma --- % 10 --- 12 pozisyon sola
o Küçük Hareket --- %30 --- 1 pozisyon sağa
o Küçük Kayma --- %20 --- 2 pozisyon sola

[JAVA] Program Kodları

TortoiseHare.java

/*
 * coded by hkucuk
 * */
public class TortoiseHare {

  public static void main(String [] args){

    int clock = 0; // Geçen zaman
    
    Move move = new Move();
    
    // Başlangıç için bir şeyler söyleyelim
    System.out.print("\nLets Goooo\n----------------------------------------------------------------------\n\n");
     
    // 70. kareye ulaşılana kadar yarışı devam ettirelim
    while(move.getTortoisePosition() != 70 && move.getHarePosition() != 70){
        
        move.actionTortoise(); // Kaplumbağa-yı hareket ettirelim =)
        move.actionHare();     // Tavşan-ı hareket ettirelim =)
        move.echoPositions();  // Kaplumbağa ve Tavşan'ın pozisyonunu yazdıralım
        clock++;               // Her adımda geçen süreyi arttıralım
      }
     
    System.out.print("\n----------------------------------------------------------------------\n");
     
    if(move.getTortoisePosition() >= move.getHarePosition()){ // Kaplumbağa kazandı :D
      System.out.print("\nTORTOISE WINS!!! YAY!!!\n");
    }else{ // Tavşan kazandı :D
       System.out.print("\nHare wins. Yuch\n");
    }
    
      // Geçen süreyi söyleyelim
    System.out.printf("Elapsed Time : %d\n\n", clock);
    
  }	
}

Move.java

import java.util.Random;

/*
 * coded by hkucuk
 * */
public class Move {

	public int tortoisePosition = 1; // Kaplumbağanın pozisyonu
	public int harePosition     = 1; // Tavşanın pozisyonu
	
	Random rand = new Random();
	
	public void actionTortoise(){
		
		int randomNumber = rand.nextInt(10) + 1;
		
		if(randomNumber >= 1 && randomNumber <= 5) setTortoisePosition(3);
		else if(randomNumber == 6 || randomNumber == 7) setTortoisePosition(0, 6);
		else setTortoisePosition(1);
		      
		if(getTortoisePosition() < 1) restoreTortoisePosition(1); if(getTortoisePosition() > 70) restoreTortoisePosition(70);		
	}

	public void setTortoisePosition(int positionRight){ this.tortoisePosition += positionRight; }
	public void setTortoisePosition(int positionRight, int positionLeft){ this.tortoisePosition -= positionLeft; }
	public void restoreTortoisePosition(int position){ this.tortoisePosition = position; }
	
	public int getTortoisePosition(){ return this.tortoisePosition; }

	public void actionHare(){
		
		int randomNumber = rand.nextInt(10) + 1;
		
		if(randomNumber == 3 || randomNumber == 4) setHarePosition(9);
		else if(randomNumber == 5) setHarePosition(0, 12);
		else if(randomNumber >= 6 && randomNumber <= 8) setHarePosition(1);
		else if(randomNumber == 9 || randomNumber == 10) setHarePosition(0, 2);
		      
		if(getHarePosition() < 1) restoreHarePosition(1); if(getHarePosition() > 70) restoreHarePosition(70);		
	}

	public void setHarePosition(int positionRight){ this.harePosition += positionRight; }
	public void setHarePosition(int positionRight, int positionLeft){ this.harePosition -= positionLeft; }
	public void restoreHarePosition(int position){ this.harePosition = position; }
	
	public int getHarePosition(){ return this.harePosition; }
	
	public void echoPositions(){
		
	   int counter;
	   
	   // Pozisyonlar 1 ile 70 arasında olacağı için 1'den 70'e kadar her bir pozisyona bakıyoruz
	   for(counter = 1; counter <= 70; counter++){
	      // Eğer kaplumbağa ve tavşan aynı pozisyonda iseler uyarı veriyoruz
	      if(counter == getTortoisePosition() && counter == getHarePosition())
	         System.out.printf("OUCH!!!");
	      // Geçerli pozisyonda kaplumbağa varsa ekrana T yazdırıyoruz
	      else if(counter == getTortoisePosition())
	    	  System.out.printf("T");
	      // Geçerli pozisyonda tavşan varsa ekrana H yazdırıyoruz
	      else if(counter == getHarePosition())
	    	  System.out.printf("H");
	      else // Geçerli pozisyonda kimse yok ise boşluk bırakıyoruz
	    	  System.out.printf(" ");
	   }
	   System.out.printf("\n");
	}
}

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Görev Zamanlaması Problemi (Java, C++)

Wed, 23 Aug 2017 00:00:00 GMT

Daha önce yazılımcılara iş mülakatlarında sorulmuş bir problem ve bu probleme benim geliştirdiğim çözümü paylaşmak istiyorum.

Problem Tanımlaması

Dexter’ın elinde bugün yapıp bitirmesi gerek uzun bir iş listesi vardır. Dexter’ın herhangi bir i görevini bitirebilmesi için Mi dakikaya ihtiyacı vardır ve i görevinin son bitirme anı Di’dir. Hiçbir görev Di’den daha uzun sürede bitirilemez. Fakat Dexter bir görevin bir parçasını tamamlayıp başka bir göreve geçebilir ve ardından o göreve geri dönebilir.

Fakat iş listesine bakıldığında verilen deadline’a göre tüm görevlerin tamamlanması mümkün gibi gözükmüyor. Bu yüzden Dexter’ın deadline’ını aşan görevleri olabildiğince kısa sürelerde bitirmeye çalışması gerekiyor.

Girdi
İlk girilen satır görevlerin sayısı (T). T’den sonra girilen satırlardaki değerler ise sırasıyla Di ve Mi.

Çıktı
Optimal planlanan bitirme süresi, kendi bitiş tarihini ıskalayan azami görev miktarını içerecektir.

Daha iyi anlaşılması için aşağıdaki örnek incelenebilir:

Örnek Girdi

Örnek Çıktı

Yanlızca ilk görev 2 dakika içerisinde tamamlanabilir ve süre aşımı olmaz
İlk iki görev ile şöyle bir optimal zamanlama yapılabilir:
Süre 1: Görev 2
Süre 2: Görev 1
Süre 3: Görev 1
1. görev 2. dakikada bitmesi gerekirken 3. dakikada bittiği için ekrana 1 yazdırdık (Deadline’ı aşma miktarı).
İlk üç görev ile şöyle bir optimal zamanlama yapılabilir:
Süre 1: Görev 2
Süre 2: Görev 1
Süre 3: Görev 3
Süre 4: Görev 1
Süre 5: Görev 3
Süre 6: Görev 3
Görev 1’in deadline’ı 2 ve o 4. dakikada bitiyor. Yani kendi deadline’ını 2 dakika aşıyor
Görev 2’in deadline’ı 1 ve o 1. dakikada bitiyor. Yani kendi deadline’ını 0 dakika aşıyor
Görev 3’in deadline’ı 4 ve o 6. dakikada bitiyor. Yani kendi deadline’ını 2 dakika aşıyor

Böylece Dexter’ın deadline’ı maksimum 2 dakika aştığını anlamış olduk. Bundan daha iyi bir taslak yapmak olası değildir.

Benzer hesaplama 5 görev için de yapılabilir.

Java’da Problemin Çözümü

/*
 * Coded by hkucuk
 */
import java.util.*;
import java.io.*;

class SolutionSchedule{
    
	BufferedReader b_input;
	BufferedWriter b_out;
	StringTokenizer token;

	int[] ST;
	int[] add;

	void update(int s,int e,int x,int a,int b,int v){
        
        if(s > b || e < a) return; 
        if(s >= a && e <= b){ 
            add[x] += v; return; 
        }
        
        add[2*x+1] += add[x]; 
        add[2*x+2] += add[x]; 
        add[x] = 0; 
        
        update(s,(s+e)/2,2*x+1,a,b,v); 
        update((s+e)/2+1,e,2*x+2,a,b,v); 
        
        ST[x] = Math.max(ST[2*x+1]+add[2*x+1],ST[2*x+2]+add[2*x+2]); 
    } 
    
    void build(int s,int e,int x){ 
        if(s==e){ 
            ST[x] = -s; return; 
        } 
        
        build(s,(s+e)/2,2*x+1); 
        build((s+e)/2+1,e,2*x+2); 
        
        ST[x] = Math.max(ST[2*x+1],ST[2*x+2]); 
    } 
    
    int query(int s,int e,int x,int a,int b){ 
        if(s > b || e < a)return 0; if(s >= a && e <= b){
			return ST[x]+add[x];
		}
        
		add[2*x+1] += add[x];
		add[2*x+2] += add[x];
		add[x] = 0;
        
		ST[x] = Math.max(ST[2*x+1]+add[2*x+1],ST[2*x+2]+add[2*x+2]);
        
		int first = query(s,(s+e)/2,2*x+1,a,b);
		int second = query((s+e)/2+1,e,2*x+2,a,b);
		return Math.max(first,second);
	}

	void solve() throws IOException{
        
		b_input = new BufferedReader(new InputStreamReader(System.in));
		b_out = new BufferedWriter(new OutputStreamWriter(System.out));
        
		int T = nextInt();
		int maxD = 4*(100000+3);
        
		ST = new int[maxD];
		add = new int[maxD];
		build(0,100000,0);
        
		for(int t = 0; t < T; t++){
			int D = nextInt();
			int M = nextInt();
			update(0,100000,0,D,100000,M);
			b_out.write(""+query(0,100000,0,0,100000));
			b_out.newLine();
		}
        
		b_out.flush();
	}

	int nextInt() throws IOException{        
		if(token == null || !token.hasMoreTokens())
			token = new StringTokenizer(b_input.readLine());
		return Integer.parseInt(token.nextToken());
	}

	Long nextLong() throws IOException{
		if(token == null || !token.hasMoreTokens())
			token = new StringTokenizer(b_input.readLine());
		return Long.parseLong(token.nextToken());
	}

	String next() throws IOException{
		if(token == null || !token.hasMoreTokens())
			token = new StringTokenizer(b_input.readLine());
		return token.nextToken();
	}

	public static void main(String[] args) throws Exception{
		new SolutionSchedule().solve();
	}
}

C++‘da Problemin Çözümü

/*
 * Coded by hkucuk
 */
#include 
#include 
#include 
#include 
#include 
#include 
using namespace std;

class SolutionSchedule{
    
    public:SolutionSchedule(int left, int right, const vector& original_data){
    
        this->left = left;
        this->right = right;
        this->lazy_flag = 0;
        left_tree = right_tree = NULL;
    
        if (left == right){
            this->value = this->max_value = original_data[left];
        }else{
            mid = (left + right) / 2;
            left_tree = new SolutionSchedule(left, mid, original_data);
            right_tree = new SolutionSchedule(mid + 1, right, original_data);
            push_up();
        }
    }
    
    void modify(int left, int right, int m_value){
        
        if (this->left == left && this->right == right){
            leaf_modify(m_value);
        }else{
            
            push_down();
            
            if (left <= mid){ if (right >= mid + 1){
                    left_tree->modify(left, mid, m_value);
                    right_tree->modify(mid + 1, right, m_value);
                }else{
                    left_tree->modify(left, right, m_value);
                }
                
            }else{
                right_tree->modify(left, right, m_value);
            }
            
            push_up();
        }
    }
    
    int query(int left, int right){
        
        if (this->left == left && this->right == right){
            return this->max_value;
        }else{
            
            push_down();
            
            if (left <= mid){ if (right >= mid + 1){
                    int max_value_l = left_tree->query(left, mid);
                    int max_value_r = right_tree->query(mid + 1, right);
                    return max(max_value_l, max_value_r);
                }else{
                    return left_tree->query(left, right);
                }
                
            }else{
                return right_tree->query(left, right);
            }
        }
    }
    
    private:int left, right, mid;
    SolutionSchedule *left_tree, *right_tree;

    int value, lazy_flag, max_value;

    void push_up(){
        this->max_value = max(this->left_tree->max_value, this->right_tree->max_value);
    }
    
    void push_down(){
        
        if (this->lazy_flag > 0){
            left_tree->leaf_modify(this->lazy_flag);
            right_tree->leaf_modify(this->lazy_flag);
            this->lazy_flag = 0;
        }
    }
    
    void leaf_modify(int m_value){
        this->lazy_flag += m_value;
        this->max_value += m_value;
    }
};

vector vec_d, vec_m, vec_idx, vec_rank, vec_d_reorder;

int cmp(int idx_x, int idx_y){
    return vec_d[idx_x] < vec_d[idx_y];
}

int main(){
    
    int T;
    scanf("%d", &T);
    
    for (int i = 0; i < T; i++){
        int d, m;
        scanf("%d%d", &d, &m);
        vec_d.push_back(d);
        vec_m.push_back(m);
        vec_idx.push_back(i);
    }

    sort(vec_idx.begin(), vec_idx.end(), cmp);
    vec_rank.assign(T, 0);
    vec_d_reorder.assign(T, 0);
    
    for (int i = 0; i < T; i++){
        vec_rank[ vec_idx[i] ] = i;
    }
    
    for (int i = 0; i < T; i++){
        vec_d_reorder[i] = -vec_d[ vec_idx[i] ];
    }

    SolutionSchedule tree(0, T-1, vec_d_reorder);

    for (int i = 0; i < T; i++){
        tree.modify(vec_rank[i], T-1, vec_m[i]);
        int ans = tree.query(0, T-1);
        printf("%d\n", max(0,ans));
    }
}

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

İyzico Ödeme Sistemi Laravel Paketi

Fri, 19 Aug 2016 00:00:00 GMT

Iyzico gayet basit ve kolay anlaşılır bir ödeme sistemi. İyzico hakkında daha ayrıntılı bilgi almak için sitesindeki bağlantıları takip edebilir, ayrıca ayrıntılı bir kullanımı için şu adresi takip edebilirsiniz. Ben burada iyzico’nun bize sunduğu api’nin kullanımı için PHP Laravel Framework‘üne uygun olarak geliştirdiğim paketin tanıtımını yapacağım.

Çalışma Mantığı

Iyzico’nun temel çalışma mantığında “2 sorgu 2 cevap” prensibi yatmaktadır. İlk önce belirli parametreleri iyzico api-ye göndererek bir ödeme formu istiyoruz. Ardından kullanıcı formu doldurup onayladıktan sonra iyzico’dan gelen cevaplara göre işlemlerimizi yönlendiriyoruz.

Geliştirdiğim paket bu aşamaların iyzico api-ye bağlanarak ödeme formu isteme aşamasını laravel için uygun bir hale getiriyor. Gerçi bu aşamlar normal bir fonksiyon tanımlama ile de gerçekleştirilebilir fakat laravel dünyasının gelişimine katkı sağlamak hiçte kötü bir düşünce değil.

Paket Bağlantıları:
Github: https://github.com/medyun/hkucuk-iyzico-laravel-package Packagist: https://packagist.org/packages/hkucuk/iyzico

Paketin Yüklenmesi:
Paketin yüklenmesi için Composer kullanmamız gerekiyor. Eğer composer kullanımıyorsanız linki takip ederek hemen kullanmaya başlamalısınız. Proje dosyamızdaki composer.json dosyasına aşağıdaki eklemeyi yapıyoruz:

{
    "require": {
        "hkucuk/iyzico": "v1.0.0"
    }
}

Ardından composer dosyamızı update ediyoruz:

composer update

Buraya kadar sorun yok ise paket bilgisayarınıza yüklenmiş durumda olacaktır. Bundan sonra paketin laravel’de kullanılabilir duruma gelmesi için aşağıdaki düzenlemeleri yapmamız gerekiyor.

İlk olarak config/app.php dosyası içerisindeki providers değerine aşağıdaki eklemeyi yapıyoruz.

'providers' => array(
    // ...
    'Hkucuk\Iyzico\IyzicoServiceProvider',
)

Ardından yine config/app.php dosyasındaki aliases değerine aşağıdaki eklemeyi yapıyoruz.

'aliases' => array(
    // ...
    'Iyzico' => 'Hkucuk\Iyzico\Facades\Iyzico',
)

Bu ayarların ardından son olarak paketi publish etmemiz gerekiyor. Bunun içinde consol’dan aşağıdaki komudu çalıştırmamız yeterli olacaktır.

php artisan vendor:publish

Paketin Kullanımı

Paket içerisinde gelen config/config.php içerisindeki api_id ve secret değerlerini girmemiz gerekiyor. Eğer bu değerleri ana config kalsörünüzün altına taşımak isterseniz config/packages/hkucuk/iyzico/config.php dosyasını oluşturarak, bu dosya içerisinde de tanımlayabilirsiniz.

$data = array(
    "customer_language" => "tr",
    "mode" => "test",
    "external_id" => rand(),
    "type" => "CC.DB",
    "installment" => true,
    "amount" => 1099,
    "return_url" => "http://example.com/iyzicoResponse",
    "currency" => "TRY"
);

$response = Iyzico::getForm($data);

echo $response->code_snippet;

Ödeme formu isteme işlemi yukarıdaki gibi yapılabilir. Burada $data içerisinde gönderilen parametreler değişkenlik gösterebilir, ihtiyaca uygun olarak belirlenebilir. Burada dönen cevabın code_snippet değeri bize formun kodlarını vermektedir. Bu kodları ekrana bastığımızda ödeme formu gözükecektir.

Form gönderildikten sonra iyzico’dan bize gelen cevabı aşağıdaki gibi izleyebilir:

$data = json_decode(Input::get("json"), true);
var_dump($data);

Hepsi bu kadar. İşler yolunda gider ise bu adımların ardından Laravel ile iyzico bağlantısı bu şekilde gerçekleştirilebilir.

Kolay gelsin.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Sherlock mu? Ben mi? Süper Bilgisayar mı?

Mon, 16 May 2016 00:00:00 GMT

Bu yazıda dedektif kahramanların en ünlüsü Sherlock Holmes‘e yardımcı olmaya çalışacağız. Sherlock Holmes süper bilgisayara karşı.

Senaryomuz

Sherlock Holmes, ezeli düşmanı olan Moriarty hakkında iyice paranoyaklaşır. Moriarty’i bastırmak için sarfettiği tüm çabaları boşa çıkmıştır. Sherlock bugünlerde Watson ile bir sorun üzerine çalışmaktadır. Watson, son zamanlarda, CIA’in süper bilgisayarı Beast’de tuhaf sorunlarla karşı karşıya olduğunu belirtmiştir.

Bu öğleden sonra Sherlock, Moriarty’den Beast’e bir virüs aracılığı ile sızdığını belirten, bir not alır. Ayrıca, notun üzerinde N adet numara vardır. Bazı hesaplamalar yaptıktan sonra Sherlock virüsü kaldırmak için gereken anahtarın en büyük makul değerinin N basamaklı olacağını çözmüştür.

En makul sayının aşağıdaki özelliklere sahip olması gerekmektedir:

Basamaklarda yalnızca 3 veya 5 rakamları kullanılabilir. Başka rakamlar olmamalıdır.
Bir çok kez kullanılan 3 sayısı 5 ile bölünebilir.
Bir çok kez kullanılan 5 sayısı 3 ile bölünebilir.

Bu arada sayaç Beast’i imha etmek amacıyla çok hızlı çalışıyor. Acaba biz Beast’i kurtarmak için gerekli anahtarı bulabilir miyiz? Peki bunu Sherlock’tan önce yapabilir miyiz?

Girdi Biçimi: 1. satır test durumlarının sayısını ifade edecek bir tam sayı (T) olacaktır.

Çıkış Biçimi: En büyük makul sayımız N basamaklı olacaktır. Eğer eğer bir numarak girilmezse Sherlock yanlış girdi olduğunu söylecek ve ekrana -1 yazacaktır.

Kısıtlamalar

1≤T≤20
1≤N≤100000

Açıklama

N = 1 için, geçerli değildir.
N = 3 için, 555 tek olası sayıdır.
N = 5 için 33.333 tek olası sayıdır.
N = 11, 55555533333 bu rakamlarla oluşturulabilecek olasılıklar arasındaki en büyük sayıdır.

Çözümümüz

/*
 * Coding by hkucuk
 */
import java.io.*;

public class SolutionSTB {

    public static void main(String[] args) throws IOException {

        StringBuffer sb = new StringBuffer();
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        
        byte[] mults = new byte[]{0, 2, 4, 1, 3, 0, 2, 4, 1, 3};

        for(int T = Integer.parseInt(br.readLine()); T > 0; T--){

            String S = br.readLine();
            int N = Integer.parseInt(S);
            
            // Silinecek kaç tane 5'li grup var
            int G = mults[S.charAt(S.length()-1) - 48];
            N -= 3*G;
            
            // Eğer numara çok küçükse
            if (N < 0){ sb.append("-1\n"); continue; } // 5 gruplarını ekleme for(G += 5*(N/15); G > 0; G--){
                sb.append("555");
            }
            
            // 3 gruplarını ekleme
            for(G = (N%15)/5; G > 0; G--){
                sb.append("33333");
            }
            
            // Yeni satır ekleme
            sb.append("\n");
        }
        
        System.out.print(sb);
    }
}

Örnek Girdi

Örnek Çıktı

-1
555
33333
55555533333

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Bir Aritmetik Serinin Kayıp Teriminin Bulunması

Sat, 15 Aug 2015 00:00:00 GMT

Aritmetik bir seride sayılar, aralarındaki oran sabit kalacak şekilde artış gösterirler.

Orjinal bir aritmetik serinin bir elemanının eksik olduğunu düşünelim. Bu durumda eksik olan bu elemanın bulunması için geliştirilebilecek bir algoritma aşağıdaki gibi olacaktır.

Problemi daha iyi anlayabilmek adına bir örnek verelim:
Örnek girdi: 1 3 5 9 11
Örnek çıktı: 7

Çözümümüz

import java.io.*;
import java.util.Scanner;

public class SolutionAP {

    public static void main(String args[] ) throws Exception {
        
        Scanner in = new Scanner(System.in);
        
        String temp;
        String temp2;
        
        temp = in.nextLine();
        temp2 = in.nextLine();
        
        int totalNum = Integer.parseInt(temp);
        
        if(totalNum <= 3) {
            return;
        }
        
        String[] tempNums = temp2.split(" ");      
        
        // parse the integer array
        int[] nums = new int[totalNum];
        for(int i = 0; i < totalNum; i++) {
            nums[i] = Integer.parseInt(tempNums[i]);
        }
        
        int SUM = (nums[0] + nums[totalNum - 1]) * (totalNum + 1)/ 2;
        
        for(int i = 0; i < totalNum; i++) {
            SUM -= nums[i];
        }
        
        System.out.println(SUM);
    }
}

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Bizim Gibi Bir Kaybeden, Charles Bradley

Tue, 28 Jul 2015 00:00:00 GMT

Bir kaybeden, ezilen, duygu insanı,
sahneden göz yaşları içinde inip,
kendisini dinleyenleri tek tek kucaklayacak kadar yoğun,
yıllarca sokaklarda yaşamak zorunda kalan bir evsiz,
içtenlikle, daha iyi bir ülke, daha iyi bir dünya isteyen bir meczup,
65 yaşında ünlenmeyi bekleyebilecek bir sabır taşı,
her dinleyenin kalbine, içinden geçenleri sesiyle işleyebilen,
dünyada örneği az kalmış siyah bir inci:
Charles Bradley

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Suits'den Gelen Esintiler

Fri, 03 Jul 2015 00:00:00 GMT

Diziler konuları, oyuncuları, yapımcıları gibi değişkenlerle bizleri kendilerine bağlıyorlar. Kuşkusuz bunlar bir diziyi dizi yapan temel taşları. Fakat müzik anlatılamayanları anlatabilme yeteneği sayesinde bu değişkenleri hem destekleyen hem de kendi başına bir değişken olma durumunda.

Suits; harika bir dizi. Harvey Specter ve Mike Ross’un zeka, karizma ve özgüven taşkınlıklarını izlemek insanı çok farklı bir şekilde etkiliyor. Suits’in konusu kadar bölümlerinde seçilen ve konuyu duygusal olarak bizlere aktarmada çok yardımcı olan müzikleri de muazzam. O kadar ki hayranları bu müzikleri tekrar tekrar dinlemek, onlar ile yaşamak dahi istiyorlar. Tüm bölümlerin müziklerini sunan bir bloğun varlığı bile bunu kanıtlar nitelikte.

Her bölümde bir sürü farklı şarkı kulaklarımıza kazındı. Benim dinlediğim ve vazgeçemediğim şarkılar aşağıdaki spotify listesinde ve sürekli güncellenme durumunda. Suits devam ettiği sürece de güncellenmeye devam edecek.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Anroid Hesap Makinesi - Mobil Programlama

Fri, 09 Jan 2015 00:00:00 GMT

Bu seneki beni en çok heyecanlandıran ders hiç kuşkusuz ki Mobil Programlama dersi. İlk sekiz haftalık periyot nesneye dayalı programlama ile geçmesine rağmen, sonraki süreç benim için gerçekten bir kazanıma dönüşüyor.

Ders kapsamında verilen bir çok ödevi yapmamama rağmen, mobil programlama ile ile ilgili ödevleri yapmaya gayret gösteriyorum. Çünkü öğrenmek istediğim, bilmediğim taraf burası.

İlk mobil programlama ödevimiz basit bir hesap makinesi yapımıydı. Toplama, çarpma, bölme, çıkarma gibi temel işlemleri yapması beklenen hesap makinesinin bu ödev için en zor tarafı bir textbox’a yazılacak formülün google.com üzerinde hesaplatılıp webview ile görüntülenmesiydi.

Benim ödevde kullandığım çözümler ve proje raporunu aşağıdaki linki kullanarak indirebilirsiniz.

İndirmek için tıklayınız

Kolay gelsin.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Kırılmış Bir Oyuncak İçin Sone

Thu, 27 Feb 2014 00:00:00 GMT

Karmaşa ve giderek artan bilinmezlik. Bu bilinmezlik içerisinde hayata karşı beklediklerini elde etmek için çabalamanın verdiği sevinç ya da bıkmaya yakınlık hissi. Beklenen ne? Bazen küçük bir oyuncak, bazense kırılmış bir oyuncağın eskisi gibi olabilmesi. Oyuncak ve beklenti deyince aklımıza düşer, Rus şair Yunna Morits’in “Oyuncak satıcısına sone” adlı şu şiiri:

Oyuncaklar satıyordu sakat bir ihtiyar
Çocuklar sevinçten çıldırmış, ustanında keyfi yerinde.
Cıvıldıyor, miyavlıyor, ötüyor oyuncaklar
Takla atıyor kimi, kimi amuda kalkmış kulağı üstünde.
İhtiyar da coştu, numaralar yapıyor şimdi
Üflüyor kuyruğuna bir kuşun ve öykünüyor ona
Gurulduyor, kuğuruyor, eğlendiriyor izleyenleri,
Çekiyor sümüklü bir serseriyi mıknatısıyla
Akşamla, yaylıya koşan bir at gibi koşup tezgahına
Gider o koltuk değneklerinde sekerek bir meyhaneye
Birkaç meze atıştırıp, fıçı birası içmeye.
Ve bu sonede bir delik açarak iki yüz yıl sonra
Uçarak yükselip bir inciçiçeğinin sapından havaya
Bir kuşa ıslık çalacaktır iç sızlatan bir kederle

Oyuncak ve insan kalbi çok benzer birbirine. Bazen tamiri olmaz ikisinin de!

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Veri Yapıları ve Algoritmaları Dönem Projesi

Fri, 14 Feb 2014 00:00:00 GMT

Geçtiğimiz dönem Veri Yapıları ve Algoritmaları (Data Structures and Algorithms) dersinin dönem projesi olarak, bir öğrenci bilgi sistemini yapılar (“struct”), bağlaçlı listeler(“linked list”) ve dosyalar(“file”) kullanılarak gerçekleştirdik. C ve temel veri yapılarını anlamada çok yararlı olan bu projeyi kendisini geliştirmek isteyenlerin yararlanması adına paylaşıyorum. Aşağıda Proje Metnini ve benim çözümümü bulabilirsiniz.

Proje Metni

Projede bir öğrenci işleri bilgi sistemi simülasyonunun yapılar (“struct”), bağlaçlı listeler(“linked list”) ve dosyalar (“file”) kullanılarak yapılması istenmektedir. Buna göre;

a) course olarak adlandırılan bir yapı oluşturun. Bu yapının üyeleri, code, name, instructor, term (Spring veya Fall değerleri alabilir), year ve bir course işaretçisi olsun. Öğrencilerin aldıkları dersler bağlaçlı liste ile tutulmak istendiğinden course veri yapısı elemanları üzerinde işlem yapacak void insertCourse(CourseNodePtr* cr, CourseNodePtr* inscr, char* code), char* deleteCourse(CourseNodePtr* cr, CourseNodePtr* inscr, char* code) prototipine sahip fonksiyonları yazınız. insertCourse() fonksiyonunu yazarken aynı öğrencinin aynı dersi birden fazla kez almasını engelleyiniz.

b) student olarak adlandırılan bir yapı oluşturun. Bu yapının üyeleri, id, name, surname, department, class (B.Sc., M.Sc., Ph.D. değerlerini alabilir), faculty, gpa, year, bir course işaretçisi ve bir student işaretçisi olsun. Öğrenciler bilgi sisteminde bağlaçlı liste ile tutulmak istendiğinden student veri yapısı elemanları üzerinde işlem yapacak void insertStudent(FILE* filePtr, StudentNodePtr* cr, int id), int deleteStudent(FILE* filePtr, StudentNodePtr* cr, int id) prototipine sahip fonksiyonları yazınız. insertStudent() fonksiyonunu yazarken aynı öğrencinin sisteme birden fazla kez girilmesini engelleyiniz. Hem insertStudent() fonksiyonunda hem de deleteStudent() fonksiyonlarında bağlaçlı listedeki elemanları filePtr ile işaret edilen main() fonksiyonu içinde açtığınız dosyanın içine yazınız. Böylece bağlaçlı listenizin en son hali bir dosya içinde de olacağından programınız farklı çalıştırmalarda da en son veritabanını kullanmış olacaktır.

c) Girilen öğrenci id’sine göre sistemde arama yapan ve eğer öğrenci sistemde mevcutsa onunla ilgili bilgileri ekranda gösteren bir void displayStudent(FILE* filePtr, int id) fonksiyonu yazınız. Fonksiyonunuz öncelikle dosyadan okuma yaparak öğrencileri bir bağlaçlı liste içine yerleştirmelidir. Daha sonra bu bağlaçlı liste üzerinde id’ye göre arama yapmalıdır ve eğer öğrenci mevcutsa onunla ilgili bilgileri ekranda göstermelidir. Örnek çıktı: Öğrencinin id’sini giriniz? > 2008199999 id Name Surname Department Class Faculty Gpa Year Recv. Courses 20 John White ICI M.Sc. Ege 82 2009 UBI501,UBI503,UBI505

d) Her bir öğrenci class’ına ait sistemde mevcut kayıtlı kaç adet öğrencinin bulunduğunu hesaplayan ve bunu ekranda uygun şekilde gösteren bir void displayClassNumbers(FILE* filePtr, int id) fonksiyonu yazınız. Fonksiyonunuz öncelikle dosyadan okuma yaparak öğrencileri bir bağlaçlı liste içine yerleştirmelidir. Daha sonra bu bağlaçlı liste üzerinde class değerlerine göre hesaplama yapmalıdır. Örnek çıktı: Class Number of Students B.Sc. 120 M.Sc. 55 Ph.D. 18

e) Girilen ders code’una, term değerine ve year değerine göre o dersi istenen dönem ve yıl içinde almış olan öğrencileri sistemde bulup ekranda gösteren bir void displayRecvCourse (FILE* filePtr, char* code, char* term, int year) fonksiyonu yazınız. Fonksiyonunuz öncelikle dosyadan okuma yaparak öğrencileri bir bağlaçlı liste içine yerleştirmelidir. Daha sonra bu bağlaçlı liste üzerinde değerlere göre arama yapmalıdır ve eğer öğrenci mevcutsa onunla ilgili bilgileri ekranda göstermelidir. Örnek çıktı: Dersin kodunu giriniz? > UBI503 Dönemi giriniz? > Fall Yılı giriniz? > 2008 id Name Surname 20 John White 25 Jeny McCain 29 Gregory Whitehead

f) a ve b şıkkında tanımlamış olduğunuz insertStudent(FILE* filePtr, StudentNodePtr* cr, int id) ve insertCourse(CourseNodePtr* cr, CourseNodePtr* inscr, char* code) fonksiyonunu kullanarak detaylı bir şekilde kullanıcıdan girdi alıp öğrenci kaydı yapan void registration(FILE* filePtr) fonksiyonu yazınız. Bu fonksiyon kullanıcıdan öğrenci ile ilgili bütün bilgileri aldıktan sonra onun kaydını gerçekleştirmelidir.

g) Bundan önceki yazdığınız bütün şıklardaki fonksiyonları kullanarak bir menu oluşturunuz. Menünüzün öğrenci kaydı girişi, öğrenci kaydı silme, arama gibi temel özellikleri içermesi gerekmektedir.

Proje Çözümü

/* Hüseyin Küçük
* Öğrenci İşleri Bilgi Sistemi
*/
#include
#include
#include

// Student yapısı
struct student{
int id;
char name[20];
char surname[20];
char department[20];
char clas[10];
char faculty[20];
int gpa;
int year;
struct course *coursePtr;
struct student *studentPtr;
};

// Course yapısı
struct course{
char code[10];
char name[30];
char instructor[30];
char term[10];
int year;
struct course *coursePtr;
};

// Kolay kullanabilir hale getirelim
typedef struct course Course;
typedef Course* CourseNodePtr;
typedef struct student Student;
typedef Student* StudentNodePtr;

// Fonksiyon prototype-larımız
void readFile(FILE* filePtr, StudentNodePtr* sPtr); // Veritabanındaki bilgileri belleğe taşıma
void readStudent(StudentNodePtr* sPtr, StudentNodePtr* readingPtr); // Dosyadan okunan öğrenci bilgilerinin belleğe, öğrenci listesine yazılması
void readCourse(CourseNodePtr* crSPtr, CourseNodePtr* crReadPtr); // Dosyadan okunan ders bilgilerinin belleğe, ders listesine yazılması
void registration(StudentNodePtr* sPtr); // Yeni öğrenci kayıt etme
StudentNodePtr insertStudent(StudentNodePtr *sPtr, int id); // Öğrenci ile ilgili bilgilerin alınıp, uygun şekilde listeye eklenmesi
void insertCourse(CourseNodePtr* cr, char* code); // Öğrencinin aldığı derslerin bilgilerinin alınıp listeye eklenmesi
void findStudent(StudentNodePtr* sPtr); // Öğrenci arama
void displayClassNumbers(StudentNodePtr* sPtr); // Öğrenci sınıflarında kaç kişinin olduğunun hesaplanması
void displayRecvCourse(StudentNodePtr* sPtr); // Belli bir dersi alan kişilerin listesi
void deleteStudent(StudentNodePtr* sPtr); // Öğrenci silme
void deleteCourse(StudentNodePtr* sPtr); // Ders silme
void writeDb(FILE* filePtr, StudentNodePtr* sPtr); // Bellekteki verileri dosyaya yazma

// Ana fonksiyonumuz
int main(void){
/* Tanımlamalarımız
* studentStartPtr : student yapısında bir kopya üretir. Bu yapımız aracılığı ile
dosyadaki verilerimizi bellekte tutacağız
* filePtr : dosyamıza ulaşmak için kullanacağımız pointer
* menu : menümüzden yapılan seçimi tutacağımız değişken
*/
StudentNodePtr studentStartPtr = NULL;
FILE *filePtr;
int menu;
// Veri dosyamızdaki tüm bilgileri daha rahat işlem yapabilmek adına linked-list-imiz
// aracılığı ile belleğimize çekiyoruz
readFile(filePtr, &studentStartPtr);
/* Menümüz
* 1: Yeni öğrenci ve ders kaydı
* 2: Öğrenci arama
* 3: Öğrenci silme
* 4: Öğrenci'nin aldığı derslerin arasından silme işlemi
* 5: Öğrenci sayısının sınıfa göre dağılımı
* 6: İstenen dersi alan öğrencilerin listesi
* 7: Çıkış
*/
do{
printf("\n\t------------------------------------------------------\n");
printf("\n\tSTUDENT INFORMATION SYSTEM \n\n");
printf("\tEnter 1 > Registration for Student and Courses\n");
printf("\tEnter 2 > Find a student\n");
printf("\tEnter 3 > Delete a student\n");
printf("\tEnter 4 > Delete a course from a student's courses\n");
printf("\tEnter 5 > Display class numbers\n");
printf("\tEnter 6 > Display received courses\n");
printf("\tEnter 7 > Exit\n");
printf("\n\t------------------------------------------------------\n");
printf("\tYour Choice > ");
scanf("%d", &menu); // Kullanıcının seçimi
// Kullanıcının seçimine göre işlemlere yönleniyoruz
switch(menu){
case 1:
registration(&studentStartPtr); break;
case 2:
findStudent(&studentStartPtr); break;
case 3:
deleteStudent(&studentStartPtr); break;
case 4:
deleteCourse(&studentStartPtr); break;
case 5:
displayClassNumbers(&studentStartPtr); break;
case 6:
displayRecvCourse(&studentStartPtr); break;
case 7:
writeDb(filePtr, &studentStartPtr); break;
}
}while(menu != 7);
return 0;
} // end main

/* return null
* Açıklama: Bu fonksiyon program başlatıldığı anda veritabanı dosyasındaki verileri
düzenli bir şekilde (öğrenci bilgilerini öğrenci listesine, ders bilgilerini ders
listesine) belleğe çekmektedir.
Bu fonksiyon çalışması anında readStudent() ve readCourse() fonksiyonlarını çağırmaktadır.
* Öncelikler: student.dat dosyasının oluşturulmuş ve okuma yazma izinlerinin verilmiş olması gerekmektedir.
*/
void readFile(FILE* filePtr, StudentNodePtr* sPtr){
int counter =0; // Öğrenciye bağlı tüm dersleri okumak için sayacımız
StudentNodePtr studentReadPtr;
StudentNodePtr currentPtr;
CourseNodePtr courseReadPtr;
// Dosyamızı içerisindeki verileri okuyabilecek şekilde hazırlıyoruz.
// Herhangi bir hata durumunda kullanıcıyı bilgilendiriyoruz
if((filePtr = fopen("student.dat", "rb")) == NULL){
printf("\n\tFile couldn't be opened!!!\n");
printf("1. If This is the first run or no data has been saved at first run, IGNORE this message.\n");
printf("2. If it's not the first run, check your file system permitions,\n avaible disk space and avaible memory space\n\n");
}else{
// Dosyanın içerisindeki tüm verileri okuyana kadar dosyada dolaşıyoruz
while(!feof(filePtr)){
// Bilgilerimizi tutmak için bellekten yer alıyoruz
if((studentReadPtr = malloc(sizeof(Student))) == NULL){
printf("No memory space");
}else{
// Öğrenci listemizin büyüklüğü kadar veri yapısını dosyamızdan okuyoruz
fread(studentReadPtr, sizeof(Student), 1, filePtr);
// Öğrenci yapımızın referans göstereceği öğrenci kaydını bilmediğimiz için null atıyoruz
studentReadPtr->studentPtr = NULL;
// Dosyadan gelen verileri öğrenci listemize yazıyoruz
readStudent(sPtr, &studentReadPtr);
// Öğrenciye bağlı ders kaydı var ise o bilgileri de listemize alıyoruz
if(studentReadPtr->coursePtr != NULL){
// Hafızamızda yer var mı? varsa az alalım
if((courseReadPtr = malloc(sizeof(Course))) == NULL){
printf("No memory space");
}else{
// Öğrenciye bağlı dersler bilinmediği için null
studentReadPtr->coursePtr = NULL;
// Ders bilgilerini okuyalım
fread(courseReadPtr, sizeof(struct course), 1, filePtr);
// Okunan dersin referans gösterdiği başka ders var ise sayaç 1
if(courseReadPtr->coursePtr != NULL){
counter = 1;
}else{
counter = 0;
}
// Okunan ders bilgileri belleğe alınıypr
readCourse(&(studentReadPtr->coursePtr), &courseReadPtr);
// Başka ders olduğu sürece okumaya devam ediyoruz
while(counter == 1){
// Bilgilerimizi tutmak için bellekten yer alıyoruz
if((courseReadPtr = malloc(sizeof(Course))) == NULL){
printf("No memory space");
}else{
// Veriyi dosyadan alıyoruz
fread(courseReadPtr, sizeof(struct course), 1, filePtr);
// Bu dersin referans gösterdiği başka ders var mı?
if(courseReadPtr->coursePtr != NULL){
counter = 1;
}else{
counter = 0;
}
// Okunan ders bilgileri belleğe alınıypr
readCourse(&(studentReadPtr->coursePtr), &courseReadPtr);
} // end if
} // end while
} // end if
} // end while
} // end if
} // end while
// Dosyamızı kapatıyoruz
fclose(filePtr);
} // end if
} // end readFile()

/* return null
* Açıklama: Fonksiyon dosyadan okuduğumuz öğrenci bilgilerini öğrenci listemize
eklemektedir.
* Öncelikler: Fonksiyon dosya içerisindeki verilerin doğru sıralanmış olduğu koşuluyla
verileri listenin süreli sonuna eklemektedir.
*/
void readStudent(StudentNodePtr* sPtr, StudentNodePtr* readingPtr){
StudentNodePtr newPtr = *readingPtr; // Dosyadan gelen verilerimiz
StudentNodePtr currentPtr = *sPtr; // Öğrenci listemizin başlangıç noktası
StudentNodePtr previousPtr = NULL; // Bir önceki işlem yapılan alan. Başlangıçta null
// Listemizin sonuna gidiyoruz
while(currentPtr != NULL){
previousPtr = currentPtr;
currentPtr = currentPtr->studentPtr;
}
// Daha önce listeye bir veri eklenmediyse yeni verimiz listemizin başına geliyor
if(previousPtr == NULL){
*sPtr = newPtr;
}else{ // Eğer listede önceden veri varsa yeni verimizi listenin sonuna ekliyoruz
previousPtr->studentPtr = newPtr;
} // end if
} // end readStudent()

/* return null
* Açıklama: Fonksiyon dosyadan okunan öğrenciye bağlı dersleri ders listesine eklemektedir.
* Öncelikler: Fonksiyon dosya içerisindeki verilerin doğru sıralanmış olduğu koşuluyla
verileri listenin süreli sonuna eklemektedir.
*/
void readCourse(CourseNodePtr* crSPtr, CourseNodePtr* crReadPtr){
CourseNodePtr newPtr = *crReadPtr; // Dosyadan okunan ders bilgileri
CourseNodePtr currentPtr = *crSPtr; // Ders listesinin başlangıcı ve dolaşma anında aktif olacak noktası
CourseNodePtr previousPtr = NULL; // Bir önceki noktamız başlangıçta null
newPtr->coursePtr = NULL; // Dersin referans edeceği dersi bilmediğimiz için null

// Ders listemizin sonunu belirliyoruz
while(currentPtr != NULL){
previousPtr = currentPtr;
currentPtr = currentPtr->coursePtr;
}
if(previousPtr == NULL){ // Liste boş ise yeni veri listenin başlangıcı oluyor
*crSPtr = newPtr;
}else{ // Liste boş değil ise listenin sonuna ekleme yapılıyor
previousPtr->coursePtr = newPtr;
} // end if
} // end readCourse()

/* return null
* Açıklama: Bu fonksiyon sisteme yeni öğrenci kaydı yapmamızı ve öğrencinin aldığı derslerin
kaydının yapılmasını sağlamaktadır.
* Fonksiyon işlem aşamasında öğrenciye bağlı ayrıntılı belgeleri alıp kaydetmek için insertStudent()
ve ders kayıdı yapmak için insertCourse() fonksiyonlarını çağırmaktadır.
* Fonksiyon bir sefer de 1 adet öğrenci kaydı yapabilmektedir. Fakat her öğrenciye istenilen sayıda ders
ataması yapılabilmektedir.
* Öncelikler: İstenilen bilgi alanlarına istenilen bilginin tipinde bilgi girileceği ön görülmüştür.
*/
void registration(StudentNodePtr* sPtr){
/* Tanımlamalar
* currentPtr : student yapımız içerisinde işlem yapma aşamasında gezinme işlemimiz sırasında
işlem yapılan geçerli alanı tutacak
* id : öğrenciin id-si
* yesNo : öğrenciye bağlı ders eklemeye devam edilip edilmeyeceğinin cevabı
* code : ders kodu
*/
StudentNodePtr currentPtr = *sPtr;
int id;
char yesNo;
char code[10];
printf("\n Student's Identification Number > ");
scanf("%d", &id);
// girilen id ile daha önceden herhangi bir kayıt oluşturulup oluşturulmadığına bakıyoruz
while((currentPtr != NULL) && (currentPtr->id != id)){
currentPtr = currentPtr->studentPtr;
}

// Eğer bu id ile daha önce kayıt yapıldı ise hata verdiriyoruz
if(currentPtr != NULL && currentPtr->id == id){
printf("\n ID is already in database. Try new one!\n");
}else{ // eğer bu id ile daha önce kayıt yapılmadıysa kayıt işlemine devam ediyoruz
/* insertStudent aracılığı ile öğrenci ile ilgili diğer bilgileri alarak listemize ekliyoruz
Bu fonksiyon bize eklenen veri bloğunun bilgilerini döndürecek.
Eklenen öğrencinin listedeki alanı döndürülerek ona bağlı derslerin kayıt edilmesi sağlanmakta
*/
currentPtr = insertStudent(sPtr, id);
// Birden fazla ders eklemesi yapılabileceği için do - while
do{
// Öğrenciye atanacak olan kurs kodunu alıyoruz
printf("\n\n Enter Course Code (Example: UBI503) > ");
scanf("%s", code);
/* Öğrenci listesinin course pointer adresini fonksiyonumuza gönderiyoruz.
Fonksiyon içerisinde derse ait diğer bilgilerin alınmasının ardından kaydedilecekleri
course listesinin başlangıç noktası bu değer olacak.
*/
insertCourse(&(currentPtr->coursePtr), code);
// Bir öğrenci birden fazla ders alabilir. Ders ekleme işleminin devam edip etmeyeceğini soruyoruz
printf("\n\n Do you want to continue to enter course(Y/N)? >");
yesNo = getch();
}while(yesNo == 'Y' || yesNo == 'y' );
} // end if
} //end registration()

/* return int
* Açıklama: Fonksiyon öğrenci kaydında öğrenci'nin bilgilerini almayı ve bu alınan bilgileri
öğrenci listesinde id-sine göre uygun olan yere yerleştirmektedir. Öğrenci bilgilerinin öğrenci
listesinde eklendiği alanın bilgisi öğrencinin aldığı derslerin kayıt aşamasında gerekli olduğu için
çıktı olarak gönderilmektedir.
* Öncelikler: İstenilen bilgi alanlarına istenilen bilginin tipinde bilgi girileceği ön görülmüştür.
*/
StudentNodePtr insertStudent(StudentNodePtr *sPtr, int id){
/* Tanımlamalar
* newPtr : kullanıcıdan alınacak verilerin tutulacağı student yapısı
* currentPtr : Başlangıç değeri üzerinde işlem yapacağımız ve dosyadan okuduğumuz verilerimizi
tutan listemizin ilk alanı olacak. Liste üzerinde gezinme yaparken o an üzerinde işlem yaptığımız
alan ifade edecek
* previousPtr : Liste üzerinde işlem yaparken o anki alandan önceki son alanımızı ifaed edecek
*/
StudentNodePtr newPtr;
StudentNodePtr currentPtr = *sPtr;
StudentNodePtr previousPtr = NULL; // Başlangıçta null çünkü herhangi bir gezinme yapılmadı
// Kayıtlarımız için hafızadan yer alıyoruz, yani almaya çalışıyoruz
if((newPtr = malloc(sizeof(Student))) == NULL){
printf("No memory space!!!"); // alamazsak hata veriyoruz, oha :D
}else{
newPtr->id = id; // öğrencinin id-sini yapımıza atıyoruz
// ve öğrenci ile ilgili diğer bilgileri almaya başlıyoruz
printf("\n Student Name > ");
scanf("%s", newPtr->name);
printf("\n Student Surname > ");
scanf("%s", newPtr->surname);
printf("\n Student Department > ");
scanf("%s", newPtr->department);
printf("\n Student Class (B.Sc., M.Sc., Ph.D.) > ");
scanf("%s", newPtr->clas);
printf("\n Student Faculty > ");
scanf("%s", newPtr->faculty);
printf("\n Student GPA > ");
scanf("%d", &(newPtr->gpa));
printf("\n Student Year > ");
scanf("%d", &(newPtr->year));
newPtr->studentPtr = NULL; // Bir sonraki adresi bilmediğimiz için null
newPtr->coursePtr = NULL; // Henüz ders eklemesi yapmadığımız için null

// Yeni veri yapımızdaki bilgilerin listemizde nereye yerleşeceğini belirliyoruz
while((currentPtr != NULL) && (newPtr->id > currentPtr->id)){
// Gezinme işlemi
previousPtr = currentPtr; // Şuan baktığımız kayıt en son bakılan oluyor
currentPtr = currentPtr->studentPtr; // Şuan baktığımız kaydın referans gösterdiği
// kayıt yeni şuanki kaydımız oluyor
}

// Verimizi listemize yerleştirelim
if(previousPtr == NULL){ // Eğer liste boş ise kaydımızı listenin başına ekliyoruz
newPtr->studentPtr = *sPtr;
*sPtr = newPtr;
// Kayıt noktamızı döndürüyoruz
return newPtr;
}else{ // Listenin herhangi bir alanına ekliyoruz
previousPtr->studentPtr = newPtr;
newPtr->studentPtr = currentPtr;
// Kayıt noktamızı döndürüyoruz
return newPtr;
}
} // end if
} // end insertStudent()

/* return null
* Açıklama: Fonksiyon yeni öğrenci kaydı sırasında öğrenciye bağlı derslerin ders listesine
uygun şekilde ders koduna göre eklenmesini sağlamaktadır.
* Öncelikler: İstenilen bilgi alanlarına istenilen bilginin tipinde bilgi girileceği ön görülmüştür.
*/
void insertCourse(CourseNodePtr* cr, char* code){
/* Tanımlamalar
* newPtr : Eklenecek ders'in bilgileri
* currentPtr : Ekleme yapılacak ders listemiz
* previousPtr : Ekleme aşamasında ders listesini gezinme işlemimizde en son işlem yapılan
ders listesi alanı
*/
CourseNodePtr newPtr;
CourseNodePtr currentPtr = *cr;
CourseNodePtr previousPtr;
// Daha önce bu ders'in öğrenciye atanıp atanmadığına bakıyoruz
while((currentPtr != NULL) && (strcmp(currentPtr->code, code) != 0)){
currentPtr = currentPtr->coursePtr;
}
// Eğer bu code ile daha önce kayıt yapıldı ise hata verdiriyoruz
if(currentPtr != NULL && strcmp(currentPtr->code, code) == 0){
printf("\n This course is already assinged. Please assign an other one or quit.\n");
}else{ /* Daha önce bu kod ile bir ders eklenmemiş ise ders ile ilgili diğer bilgileri de
alarak listemize ekliyoruz */
// Umarım hafızamızda yer vardır O_o
newPtr = malloc(sizeof(Course));
strcpy(newPtr->code, code);
printf("\n\t Course Name > ");
gets(newPtr->name); // Bu kod parçacığını iki kez yazmamdaki amaç; bir kez yazığımda
gets(newPtr->name); // hata alıyor olmamdır.
printf("\n\t Course Instructor Name > ");
gets(newPtr->instructor);
printf("\n\t Course Term (Spring/Fall) > ");
scanf("%s", newPtr->term);
printf("\n\t Course Year (2014) > ");
scanf("%d", &(newPtr->year));
newPtr->coursePtr = NULL; // Referans edeceği yeni alanı bilmediğimiz için null
previousPtr = NULL; // Bir önce işlem yapılan alan olmadığı için null
currentPtr = *cr; /* currentPtr-i başlangıçta gelen code ile daha önce bir kayıt
girilip girilmediğini belirlemek için kullanmıştık. Bu yüzden tuttuğu değer değişmişti.
Listemizi tekrardan dolaşmak ve yeni kaydın yerleşeceği yeri belirlemek için kayıt
yapacağımız listemizin ilk alanını atıyoruz */
// Yeni kaydın listemiz de nereye yerleşeceği belirliyoruz
while((currentPtr != NULL) && ((strcmp (newPtr->code, currentPtr->code)) == 1)){
previousPtr = currentPtr; // Şuan baktığımız kayıt en son bakılan oluyor
currentPtr = currentPtr->coursePtr; // Şuan baktığımız kaydın referans gösterdiği
// kayıt yeni şuanki kaydımız oluyor
}
// Verimizi listemize yerleştirelim
if (previousPtr == NULL){ // Eğer liste boş ise kaydımızı listenin başına ekliyoruz
newPtr->coursePtr = *cr;
*cr = newPtr;
}else{ // Listenin herhangi bir alanına ekliyoruz
previousPtr->coursePtr = newPtr;
newPtr->coursePtr = currentPtr;
}
} // end if
} //end insertCourse()

/* return null
* Açıklama: Fonksiyon girilecek id-ye göre öğrenci listesinde arama yapmaktadır.
Bulunan öğrencinin tüm bilgileri ve öğrenciye bağlı derslerin kodları listelenmektedir.
*/
void findStudent(StudentNodePtr* sPtr){
int id; // aranan öğrenci id-si
StudentNodePtr currentPtr = *sPtr; // Üzerinde işlem yapılan öğrenci listesi noktası
CourseNodePtr tempCoursePtr; // Öğrenci'nin course listesinde referans ettiği nokta
// Eğer öğrenci listemiz boş ise aranacak öğrenci de yok demektir
if(currentPtr == NULL){
printf("\n There is no student registration in DataBase!!!\n\n");
}else{
// Aranacak öğrenci id-sini alıyoruz
printf("\n Enter Student's ID > ");
scanf("%d", &id);
// Tüm listeyi kontrol ediyoruz, öğrenci bilgilerini bulabilmek için
while(currentPtr != NULL){
// Eğer aranan öğrenci listemizde var ise bilgilerini okuyabiliriz
if(currentPtr->id == id){
// Öğrenci'nin course listesinde referans ettiği noktayı tutuyoruz
tempCoursePtr = currentPtr->coursePtr;
printf("\n%-8s%-8s%-10s%-15s%-8s%-10s%-6s%-8s%-13s", "Id","Name","Surname","Department","Class","Faculty","Gpa","Year","Courses");
printf("\n%-8d%-8s%-10s%-15s%-8s%-10s%-6d%-8d",currentPtr->id, currentPtr->name, currentPtr->surname, currentPtr->department, currentPtr->clas, currentPtr->faculty, currentPtr->gpa, currentPtr->year);
// Referans aldığımız noktadan başlayarak tüm bağlı dersleri okuyoruz
while(tempCoursePtr !=NULL){
printf("%s, ", tempCoursePtr->code);
tempCoursePtr = tempCoursePtr->coursePtr;
} // end while
printf("\n");
// Öğrenciyi bulduğumuz noktadan sonraki kayıtlara bakmamıza gerek yok.
// Zamandan ve kaynak kullanımından tasarruf =)
break;
} // end if
// Öğrenciyi bulamadığımız sürece bir sonraki alana bakıyoruz
currentPtr = currentPtr->studentPtr;
} // end while
// Liste içerisinde öğrenci bulunamazsa olmadığını söylüyoruz
if(currentPtr == NULL){
printf("\n Student couldn't be found in DataBase!!!\n\n ");
}
} // end if
} // end findStudent()

/* return null
* Açıklama: Fonksiyon öğrenci listesinden id değerine göre öğrenci kaydı silme
işlemini yapmaktadır. Silme işlemi gerçekleşmeden önce arama fonksiyonundaki gibi
öğrenci bilgileri (aldığı dersler hariç) gösterilmektedir. Kullanıcının sildiği kayıttan
emin olması sağlanmaktadır.
Öğrenci bilgileri ile birlikte öğrencinin aldığı dersler de ders listesinden silinmektedir.
*/
void deleteStudent(StudentNodePtr* sPtr){
int id; // Silinmek istenen öğrenci'nin id-si
char yesNo; // Silme işlemi onayı
StudentNodePtr currentPtr;
StudentNodePtr previousPtr;
StudentNodePtr tempPtr; // Silinecek noktanın bilgisini tutacak
previousPtr = NULL;
currentPtr = *sPtr;
CourseNodePtr tempCoursePtr; // Öğrencinin derslerini silmede tampon
CourseNodePtr currentCoursePtr; // İşlem yapılan ders alanı
// Silinmek istenen öğrencinin id-sini alıyoruz
printf("\n Enter student's Id that you want to delete > ");
scanf("%d", &id);
// Öğrenci'nin listedeki yerini belirlemeye çalışıyoruz
while(currentPtr != NULL){
// Öğrenci'nin yerini belirlediğimiz anda silme işlemine başlıyoruz
if(currentPtr->id == id){
// Öğrenci'nin ders listesindeki ilk ders kaydının bilgisini alıyoruz
currentCoursePtr = currentPtr->coursePtr;
// Kullanıcının doğru kaydı silip silmediğini görebilmesi için öğrenci bilgilerini ekrana basıyoruz
printf("\nYou're about to delete following student !!!\n");
printf("\n%-8s%-8s%-10s%-15s%-8s%-10s%-6s%-8s","Id","Name","Surname","Department","Class","Faculty","Gpa","Year");
printf("\n%-8d%-8s%-10s%-15s%-8s%-10s%-6d%-8d",currentPtr->id, currentPtr->name, currentPtr->surname,
currentPtr->department, currentPtr->clas, currentPtr->faculty, currentPtr->gpa, currentPtr->year);
// Gerçekten silmek istiyor mu? istemiyor mu?
printf("\n\n Are you sure to delete (Y/N) > ");
yesNo = getch();
if((yesNo == 'y') || (yesNo == 'Y')){

// Öğrenciye bağlı tüm dersleri siliyoruz
while(currentCoursePtr != NULL){
tempCoursePtr = currentCoursePtr;
currentCoursePtr = currentCoursePtr->coursePtr;
free(tempCoursePtr); // Alanımızı bellekten kaldırıyoruz
}

if(id == (*sPtr)->id){ // Silinecek nokta listenin başlangıç noktası ise
tempPtr = *sPtr; // Silinecek alanı tutuyoruz
*sPtr = ( *sPtr )->studentPtr; // Listenin yeni başlangıç listesini silinecek
// alanın referans ettiği alan yapıyoruz
free(tempPtr); // Alanımızı listeden siliyoruz
}else{ // Silinecek nokta başlangıçtan farklı bir yerde ise
tempPtr = currentPtr;
previousPtr->studentPtr = currentPtr->studentPtr;
free(tempPtr); // Alanımızı listeden siliyoruz
//return id;
}
printf("\n\n STUDENT IS DELETED\n");
} // end if
// Öğrenciyi bulduğumuz noktadan sonrasına bakmaya gerek yok
break;
}/*end if*/
// Listeyi dolaşma işlemine devam ediyoruz.
previousPtr = currentPtr;
currentPtr = currentPtr->studentPtr;
} // end while
if(currentPtr == NULL){ // Eğer id listede yok ise yok diyoruz =)
printf("\n Student's ID is not in database!");
}
} // end deleteStudent()

/* return null
* Açıklama: Fonksiyon öğrenci listesinde kayıtlı olan bir öğrenciye atanmış dersler
arasından herhangi bir veya daha fazlasını silme işlemini yapmakltadır.
Girilen id değerine göre öğrenci listesinde bulunan öğrencinin bilgileri ev aldığı derslerin
kodları kullanıcının rahat işlem yapabilmesi adına listelenmektedir.
Kullanıcının gireceği ders koduna göre ders listesinden ilgili dersi silme işlemi gerçekleştirilmektedir.
*/
void deleteCourse(StudentNodePtr* sPtr){
/* Tanımlamalar
id: Öğrenci'nin id-si
wannaDeleteCode : Silinecek course kodu
yesNo : Silme işlemi onayı
currentPtr : Öğrenci listesi'nin o anda işlem yapılan alanı
currentCoursePtr : Üzerinde işlem yapılan ders alanı
tempCoursePtr : Silinecek ders bilgisi
previousCoursePtr : Bir önce üzerinde işlem yapılan ders alanı
*/
int id;
char wannaDeleteCode[10];
char yesNo;
StudentNodePtr currentPtr = *sPtr;
CourseNodePtr currentCoursePtr;
CourseNodePtr tempCoursePtr;
CourseNodePtr previousCoursePtr;
// Öğrenci listemiz boş ise herhangi bir işlem yapamayız
if(currentPtr == NULL){
printf("\n There is no student registration in DataBase!!!\n\n");
}else{
// Ders kaydını sileceğimiz öğrencinin id-sini alıyoruz
printf("\n Enter Student's ID which you want to delete his/her course > ");
scanf("%d", &id);
// Öğrenci listemizi dolaşıyoruz, istenen öğrencinin bilgilerini bulabilmek için
while(currentPtr != NULL){
// Öğrencinin listedeki yerini bulduk isek işlemlere başlayalım
if(currentPtr->id == id){
// Öğrenci'nin ders listesindeki ilk ders kaydının bilgisini alıyoruz
currentCoursePtr = currentPtr->coursePtr;
// Öğrenci bilgilerini kullanıcıya sunalım ki doğru öğrenci üzerinde işlem yaptığından emin olsun
printf("\n%-8s%-8s%-10s%-15s%-8s%-10s%-6s%-8s%-13s", "Id","Name","Surname","Department","Class","Faculty","Gpa","Year","Courses");
printf("\n%-8d%-8s%-10s%-15s%-8s%-10s%-6d%-8d",currentPtr->id, currentPtr->name, currentPtr->surname, currentPtr->department, currentPtr->clas, currentPtr->faculty, currentPtr->gpa, currentPtr->year);
// Öğrenciye bağlı dersleri yazdıralım
while(currentCoursePtr !=NULL){
printf("%s, ", currentCoursePtr->code);
currentCoursePtr = currentCoursePtr->coursePtr;
if(currentCoursePtr == NULL){
printf("\n");
}
}
// Silinmek istenen ders'in kodu-nu alalım
printf("\n Enter Course Code which you want to delete > ");/*course code is got from user*/
scanf("%s", wannaDeleteCode);
/* Dersleri yazdırma aşamasında ders başlangıç noktamızı kaybettiğimiz için
başlangıç noktamızı yeniden alıyoruz */
currentCoursePtr = currentPtr->coursePtr;
// Silinmek istenen dersin alanını bulabilmek için listeyi sonuna kadar dolaşıyoruz
while(currentCoursePtr != NULL){
// Dersin yerini belirlediysek silme işlemine başlıyoruz
if(strcmp(currentCoursePtr->code, wannaDeleteCode) == 0){
// Kullanıcı dersi silmekten gerçekten emin mi?
printf("\n Are you sure to delete (Y/N) ? >");
yesNo = getch();
// Emin ise silme işlemine geçelim
if((yesNo == 'y') || (yesNo == 'Y')){
// Silinecek nokta listenin başlangıcı ise
if(strcmp(currentPtr->coursePtr->code, wannaDeleteCode) == 0){
tempCoursePtr = currentPtr->coursePtr; // Silinecek alanımızı tutuyoruz
currentPtr->coursePtr = currentPtr->coursePtr->coursePtr; // Silinecek alanın referans gösterdiği alanı
// listenin başlangıç npktası yapıyoruz
free(tempCoursePtr); // Alanımızı bellekten kaldırıyoruz
printf("\n\n > COURSE IS DELETED\n");
// Dersi bulduğumuz noktadan sonrasına bakmaya gerek yok
break;
}else{ // Silinecek nokta başlangıçta değilse
tempCoursePtr = currentCoursePtr;
previousCoursePtr->coursePtr = currentCoursePtr->coursePtr;
free(tempCoursePtr); // Alanımızı bellekten kaldırıyoruz
printf("\n\n > COURSE IS DELETED\n");
// Dersi bulduğumuz noktadan sonrasına bakmaya gerek yok
break;
}
} // end if
} // end if
// Listemizi dolaşmaya devam ediyoruz
previousCoursePtr = currentCoursePtr;
currentCoursePtr = currentCoursePtr->coursePtr;
} // end while
// İstenen code ile öğrenciye ders ataması yapılmamış ise uyarıyoruz
if(currentCoursePtr == NULL){
printf("\n This course is not assigned to this student!");
break;
}
// Dolaşmaya evam etmemize gerek yok
break;
} // end if
// Öğrenciyi bulmak için listeyi dolaşmaya devam ediyoruz
currentPtr = currentPtr->studentPtr;
} // end while
// Öğrenci listede yok ise uyarıyoruz
if(currentPtr == NULL){
printf("\n Student couldn't be found in DataBase!!!\n\n ");
}
} // end if
} // end deleteCourse()

/* return null
* Açıklama: Fonksiyon sınıf dönemlerinde kaç adet öğrencinin olduğunu hesaplamakta
ve ekrana yazdırmaktadır.
*/
void displayClassNumbers(StudentNodePtr* sPtr){
StudentNodePtr currentPtr = *sPtr; // Öğrenci listesi başlangıç noktası
int bsc = 0; // B.Sc. olan kişi sayısı
int msc = 0; // M.Sc. olan kişi sayısı
int phd = 0; // Ph.D. olan kişi sayısı
// Öğrenci listesinin tamamını dolaşıyoruz
while(currentPtr != NULL){
// Tipe göre değer arttırmalarımızı yapıyoruz
if(strcmp(currentPtr->clas, "B.Sc.") == 0){
bsc++;
}else if(strcmp(currentPtr->clas, "M.Sc.") == 0){
msc++;
}else if(strcmp(currentPtr->clas, "Ph.D.") == 0){
phd++;
} // end if
// Listeyi dolaşmaya devam ediyoruz
currentPtr = currentPtr->studentPtr;
} // end while
// Sonuçları ekrana basıyoruz
printf("\n\t%-10s%-25s\n","CLASS", "NUMBER OF STUDENTS");
printf("\t%-10s%-25d\n", "B.Sc.", bsc);
printf("\t%-10s%-25d\n", "M.Sc.", msc);
printf("\t%-10s%-25d\n", "Ph.D.", phd);
printf("\n\t> LISTED");
} // end displayClassNumbers()

/* return null
* Açıklama: Fonksiyon kullanıcının gireceği ders kodu, ders dönemi ve yılı bilgileri
ile kısıtlanan arama koşulunda bu dersi alan öğrencileri listelemektedir.
* Öncelikler: İstenilen bilgi alanlarına istenilen bilginin tipinde bilgi girileceği ön görülmüştür.
*/
void displayRecvCourse(StudentNodePtr* sPtr){
StudentNodePtr currentPtr = *sPtr; // Öğrenci listesi başlangıcı
CourseNodePtr courseCurrentPtr; // Ders listesi o anki noktası
char courseCode[10]; // İstenen dersin kodu
char courseTerm[10]; // İstenen dersin dönemi
int courseYear; // İstenen dersin yılı
// Kullanıcıdan ders kriterlerini alalım
printf("\n\tCourse Code > ");
scanf("%s", courseCode);
printf("\n\tCourse Term > ");
scanf("%s", courseTerm);
printf("\n\tCourse Year > ");
scanf("%d", &courseYear);
printf("\n\t%-10s%-20s%-20s\n","ID", "NAME", "SURNAME");
// Öğrenci listesinin tamamını dolaşalım
while(currentPtr != NULL){
// Üzerinde işlem yapılan öğrenciye bağlı ders listesi alanı
courseCurrentPtr = currentPtr->coursePtr;
// Başlangıç liste noktası ve buna bağlı alanların gezerek ders kriterlerimize uygun
// ders olup olmadığına bakıyoruz
while(courseCurrentPtr != NULL){
// O an üzerine işlem yaptığımız ders'in bilgileri kriterlerimize uygun ise ekrana yazdırıyoruz
if((strcmp(courseCurrentPtr->code, courseCode) == 0) && (strcmp(courseCurrentPtr->term,courseTerm) == 0) && (courseCurrentPtr->year == courseYear)){
printf("\t%-10d%-20s%-20s\n", currentPtr->id, currentPtr->name, currentPtr->surname);
// Bir tane uyan bulmamız, öğrencinin o dersi aldığının kanıtı. Diğer dersleri dolaşmamıza gerek yok.
break;
}
// Bakılan kriterlere uygun ders değil ise bir diğer ders ile aramaya devam ediyoruz
courseCurrentPtr = courseCurrentPtr->coursePtr;
} // end while
// Diğer öğrenci'nin dersi alıp almadığına bakıyoruz
currentPtr = currentPtr->studentPtr;
} // end while
printf("\n\t> LISTED");
} // end displayRecvCourse()

/* return null
* Açıklama: Bu fonksiyon kullanıcının sistemden çıkışı sırasında bellekte bulunan
öğrenci ve ders listesi içerisindeki bilgileri veritabanımız olan student.dat
dosyası içerisine kaydetmektedir.
*/
void writeDb(FILE * filePtr, StudentNodePtr * sPtr){
StudentNodePtr currentPtr = *sPtr; // Öğrenci listesinin başlangıç noktası
CourseNodePtr tempCoursePtr; // Öğrenciye bağlı dersleri dolaşmada kullanılacak nokta tutucu

// Veritabanı olarak kullanacağımız dosyayı işlem yapılabilir hale getirelim
if((filePtr = fopen("student.dat", "r+")) == NULL){
printf("\n file can't be opened!!!\n");
}else{
// Öğrenci listesinin tamamını dolaşalım
while(currentPtr != NULL){
// Öğrenciye bağlı derslerin ders listesindeki başlangıç noktasını tutalım
tempCoursePtr = currentPtr->coursePtr;
// O anki öğrencinin bilgilerini dosyamıza yazalım
fwrite(currentPtr, sizeof(struct student), 1, filePtr);
// Öğrenciye bağlı tüm dersleri de dosyamıza yazalım
while(tempCoursePtr != NULL){
// Bilgileri dosyaya yazalım
fwrite(tempCoursePtr, sizeof(struct course), 1, filePtr);
// Bir sonraki derse geçelim
tempCoursePtr = tempCoursePtr->coursePtr;
}
// Bir sonraki öğrenciye geçelim
currentPtr = currentPtr->studentPtr;
} // end while
} // end while
close(filePtr); // Dosyamızı kapatalım
printf("\n Data has been saved to the student.dat File\n");
} //end writeDb()

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

C İle Kodlanmış Algoritma Örnekler

Mon, 20 Jan 2014 00:00:00 GMT

Bu sene Yüksek Lisans kapsamında aldığımız Veri Yapıları ve Algoritmaları dersinde her hafta için farklı ödevler hazırladık. Bu ödevlerin her biri temel veri yapılarını anlamayı, temel algoritma geliştirme becerilerini geliştirmeyi ve algoritmik düşünmeyi geliştirmeyi amaçlıyordu. Bu amaçlarla ortak hedefleri olan kişilerin yararlanabilmeleri adına aşağıda proje programlarını ve çözümlerini bulabilirsiniz.

Ödev içerisinde geliştirilmesi istenenler:

İkilik sayı sistemindeki bir sayının onluk sistemdeki karşılığının hesaplayan programın kodlanması Pozitif bir sayının faktöryelini hesaplayan programın kodlanması Matematiksel Sabit e ‘ yi hesaplayan programın kodlanması

Program: C ile geliştirilmiş çözüm algoritmaları için tıklayınız

Ödev Raporu: İndirmek için tıklayınız

Ödev içerisinde geliştirilmesi istenenler:

Bir şirketin çalışanlarına haftalık olarak yapacağı ödemeleri hesaplayan programın kodlanması 1994 ile 1999 yılları arasındaki tarihlerden istenilenin takvimini listeleyen programın kodlanması

Program: C ile geliştirilmiş çözüm algoritmaları için tıklayınız

Ödev Raporu: İndirmek için tıklayınız

Ödev içerisinde geliştirilmesi istenenler:

1 ile 1000 arasında üretilen bir sayıyı tahmin etmek için oynanan oyunun programı Fibonacci sayılarının istenilen adımı kadar hesaplanmasını sağlayan ve sistemin hesaplayabileceği en büyük fibonacci sayısını bulan program İki sayının en büyük ortak bölen’ini hesaplayan program

Program: C ile geliştirilmiş çözüm algoritmaları için tıklayınız

Ödev Raporu: İndirmek için tıklayınız

Ödev içerisinde geliştirilmesi istenenler:

Matematikte Eratosthenes (Eratosten) Eleği olarak bilinen ve belirli bir sayıya kadar yer alan asal sayıların bulunması amacıyla kullanılan yöntem aracılığı ile 1 – 1000 arasındaki sayılardan asal olanları bulan sistemin kodlanması

Program: C ile geliştirilmiş çözüm algoritmaları için tıklayınız

Ödev Raporu: İndirmek için tıklayınız

Ödev içerisinde geliştirilmesi istenenler:

İki hayvanın yarışmasını anlatan Kaplumbağa ile Tavşan hikayesinden yola çıkarak, Kaplumbağa ve Tavşan’ın yarışmalarını sağlayan programın kodlanması

Program: C ile geliştirilmiş çözüm algoritmaları için tıklayınız

Ödev Raporu: İndirmek için tıklayınız

Ödev içerisinde geliştirilmesi istenenler:

Bir hırdavat dükkanının sahibi olarak, envarterlerimizin kayıtlarını tutabileceğimiz programın kodlanması

Program: C ile geliştirilmiş çözüm algoritmaları için tıklayınız

Ödev Raporu: İndirmek için tıklayınız

Ödev içerisinde geliştirilmesi istenenler:

Sıralanmış iki tam sayı listesini birleştirerek sıralı tek bir tam sayı listesi yapan programın kodlanması

Program: C ile geliştirilmiş çözüm algoritmaları için tıklayınız

Ödev Raporu: İndirmek için tıklayınız

Her programın kodlaması ile ilgili açıklamalar raporlarının içerisinde ayrıntılı yer almaktadır. Bununla beraber kodlar içerisinde yorum satırları ile de gerekli açıklamalar yapılmıştır. Programların çalıştırılmasından kaynaklanacak hatalardan sorumlu olmadığımı da belirtmek isterim. Yararlı olmasını dilerim.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Bir Çocuktan Katil Yaratma

Mon, 25 Nov 2013 00:00:00 GMT

… Bir çocuktan katil yaratma öykülerinin en korkuncu 1920’li yıllarda başlamıştır. Chicago’lu şekerleme fabrikatörü Otto Schnering, piyasaya sunduğu yeni >ürününe, ABD Başkanı Cleveland’ın yeni doğan kızı Ruth’tan etkilenerek, “Babe Ruth” adını verir. Babe Ruth, üstü çikolata kaplı çubuk şekerlerdir. Schnering, >ürünün tanıtımı için Doug Davis’le anlaşır. Davis, ordudan ayrılan bir pilottur ve birlaç uçaklık filonun da sahibidir. Reklam kampanyası olarak, kağıttan >yapılan küçük paraşütlere bağlı “Babe Ruth” çikolataları uçaktan halkın üstüne atılacaktır. Pilot Davis, bir arkadaşının evine ziyarete gittiğinde yeni aldığı >reklam işini anlatır. Sohbete kulak misafiri olan evin çocuğu Paul, çikolataları uçaktan atmayı çok istediğini söylese de, babası bunu tehlikeli bulur ve izin >vermez. Reklam kampanyasında bir çocuğun kullanılması fikri hoşuna giden Davis, güç olsada arkadaşını ikna etmeyi başarır. O günden sonra, bir uçak sesi duyan >halk gökyüzüne bakmakta ve 12 yaşındaki Paul’un pilot kabininin penceresinden attığı çikolataları kapışmaktadır. Havacılığı uçaktan çikolata atmakla seven >Paul Tibbets adlı o çocuk pilot olacak ve 6 Ağustos 1945 tarihinde Hiroşima’ya “Little Boy” adlı atom bombasını atacaktır.

Sunay Akın, Geyikli Park, Türkiye İş Bankası Kültür Yayınları

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Kutsal Olmayan Bir Arzunun Kurbanı

Mon, 22 Jul 2013 00:00:00 GMT

Gençken, bir gün ormanda okla yaraladığım bir kuşun ölümünü seyretmiştim; bu dünyayı terk etme arzumu harekete geçiren işte bu olaydır. Kuşun kanayan göğsünü >hatırladıkça hala ürperiyorum. Bugün bile kendimi o kuş gibi görüyorum; az önce özgürce uçabilirken, bir dakika sonra yere çakılmış can çekişen bir canlı…

…Cinlerim bu sabah iş başında! Erimiş mum kokan kasvetli taş hücremde, her şey bir yana, bunların yalnızca küçük kederler olduğuna kendimi ikna etmem çok >zor oluyor. Kalbimin tedirginliği ile karşılaştırıldığında ölü bir kuşun cansızlığı aslında küçük bir olay. Ruhum huzursuz; çünkü sürekli olarak, her türlü >mantığa meydan okuyan bir şeye elimi uzatıyorum. İmanım, özlemlerimin o geniş ve boş uzamını kuşatmaya yeterli görünmüyor…

James Cowan, -A Mapmaker’s Dream- Haritacının Rüyası, Literatür Yayınları. Çeviri: Zarife Biliz

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Madımak, Kirlenmiş Bir Renkten Fazlası

Tue, 02 Jul 2013 00:00:00 GMT

Kova Kaleci

Yedi kova su yeterliydi
sıvas’taki ateşi söndürmek için
oysa her biri devlet dairesindeki kovaların
üstüne yazılı altı harfli bir sözcüktü yangın
Yedinci kova taşar engellenemez biçimde
çünkü emekçilerin alın teriyle doludur
işte bu yüzden sinek ölüleri yüzemez
üstünde Futbol takımında mahallenin
kova kaleciydi lakabım ilk kez sevinecektim buna
ama yalnızca avuçlarıma alabildiğim suyu
bir kova gibi sıvas’a taşıyamadım
G harfi boştur yangın kovalarının
ki ortaya çıkar dolu olanları
okununca madımak oteli’nin
merdivenlerinde kurtulmayı bekleyenler için verilen karar: Yan ın
Ve başında anladım
ki bir kuyunun ipin
ucunda derinlerdeki suya uzanan birer kova gibidirler
yangınları söndürmek isteyen darağacına asılı devrimciler.

Sunay AKIN

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

İlköğretim Birinci Kademe Öğrencileri İçin HTML Öğrenme Sistemi

Tue, 01 May 2012 00:00:00 GMT

Geçen sene öğretim materyali hazırlama ile ilgili bir dersimiz kapsamında ilköğretim birinci kademe Bilişim Teknolojileri dersinin ders programlarında da yer alan “İnternet Sitesi Yapıyorum” ünitesi üzerinden hareketle, öğrencilerin videolu anlatımlar aracılığıyla HTML dilini öğrenmelerini amaçlayan bir site tasarlamıştım. İş dosyalarımı tuttuğum klasörümü düzenlemeye çalışırken sildim sandığım :D bu siteyi sapasağlam bir şekilde buluverdim.

Bu sene İzmir Dr. Cavit ÖZYEĞİN İlköğretim Okulunda öğretmenlik stajımı yapıyorum. İkinci dönem boyunca 7/C sınıfının derslerini yürütüyorum ve derslerimde öğrencilerime HTML öğretmeyi, daha doğrusu HTML ile ilgili temel bilgileri onlara kazandırmayı amaçlıyorum. Bu derslere başlamadan önce geçen sene yaptığım ve buradan paylaşıyor olduğum programı çok aramıştım fakat bulamamıştım. Derslerin bitmesine çok az bir zaman kala karşıma çıkan programı tekrardan incelediğimde birinci kademe öğrencileri için biraz ağır olduğunu düşünmeme rağmen öğrencilerimle paylaşmayı düşünüyorum. Biraz zorlanma olmadan kalıcı bilgiler elde edilemez. Fakat sadece öğrencilerim bu kaynaktan faydalanmasın, ihtiyacı olan herkes kullanabilsin, öğrenebilsin diyerek bloğuma da koymaya karar verdim :)

Program içerisinde;
*Html Nedir?
*Html Etiketleri
*Html Parametreler
*Html Metin Biçimlendirme
*Html Listeleme
*Html Formları
*Html Form Action
*Html Tablolar
*Html Bağlantı
*Html Arka Plan
*Html Font
*Html Stiller
*Html Script
*Html Başlık
*Html URL

konu başlıkları basit bir dille anlatılmaya çalışılmaktadır. Ayrıca basit örnek kodlar ve basit bir değerlendirme kısmı da program içerisinde yer almaktadır.

Programı indirmek için tıklayınız.

Yararlı olması dileklerimle ;)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Denizli'de Çalışma Toplantısı

Sun, 29 Apr 2012 00:00:00 GMT

3 - 4 - 5 - 6 Mayıs tarihlerinde Denizli’de Toplum Gönüllüleri Atak Organizasyonlarından biri gerçekleştirilecek. “Pati Atak” adını taşıyan bu proje ile sokak hayvanları hakkında bireylerin bilinçlendirilmesi, bir farkındalık oluşturulması amaçlanıyor. 4 gün sürecek olan bu organizasyon için 50’ e yakın kişi farklı şehirlerden Denizliye gelecek ve koordineli bir organizasyon yapılması gerekiyor. Bizde organizasyona katkı sağlamak için Saha Koordinatörümüz ile birlikte geçen hafta sonunu Denizli’de geçirdik ve bir çalışma toplantısı gerçekleştirdik.

Bu çalışma toplantımızın amacı ekibin atak sonuna kadar yapacaklarının neler olduğunun üzerinde çalışarak bir iş takvimi çıkartmaktı. İş takvimi çıkarmanın öncesinde yapılacak olan atağın ilk fikir süreçleri, hazırlık süreci, hazırlık sürecinde yaşanılan olumlu ve olumsuz durumlar, atak anı ve sonrası hakkında konuşarak ne durumdayız, nereye varmak istiyoruzu biraz daha belirgin hale getirdik. Güzel de oldu :)

İş takvimi oluşturma aşamasında her ekip (ulaşım, konaklama, yemek, iletişim vb.) kendi iş kalemleri üzerinde çalıştılar. İlk olarak yarım saatlik bu süreçte oluşturdukları iş kalemlerini diğer ekiplere de sunarak eksik olan yerler tamamlandı, yanlışlar düzeltildi. Bu süreçte bir çalışma toplantısından atak toplantısına dönüşen anlar olsa da ekip için verimli tartışmalar da yaşandı. Sunumların ardından her ekip tekrardan bir araya gelerek çıkan iş kalemlerini düzenli bir yapıya getirerek (iş kalemlerinin gruplandırılması, her iş kaleminin hangi tarihler arasında, kim tarafından yapılacağının belirlenmesi) görsel olarak iş takvimlerini oluşturdular. Tüm ekiplerin iş kalemlerinin toplanmasının ardından 137 satırlık bir çalışma takvimi oluşturuldu. :D Allah kolaylık versin :))

Ekip oluşturduğumuz çalışma takvimi üzerinde hareket ederek daha sağlıklı bir şekilde bu organizasyonun altından kalkacaktır diye düşünüyorum. Her türlü o ekip bu işin üstesinden gelecek, sadece işleri kolaylaştırmanın bir yolunu sunduk biz onlara. Umarım haftaya çok güzel bir organizasyon gerçekleştirirler :) Ben onlarla olamayacağım çünkü büyük ihtimal Bandırma’da yapılacak olan atakta olacağım.

Dipnot: Toplum Gönüllüleri sahasında yapılan, yapılacak bir çok etkinlik var :) Bunların neler olduğunu merak ediyorsanız Tog Takvim aracılığıyla bu merakınızı giderebilirsiniz :)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

İYTE Anahtar Eğitiminleri

Wed, 18 Apr 2012 00:00:00 GMT

Geçtiğimiz hafta sonu İYTE (İzmir Yüksek Teknoloji Enstitüsü) de Toplum Gönüllüleri Vakfı anahtar eğitimlerini gerçekleştirdik. Mavi(Sivil Toplum, STK, Gönüllülük), Kırmızı (Proje Yönetimi), Yeşil(Ekip Çalışması, Etkili İletişim) anahtar eğitimlerini eğitmen arkadaşım Hasan ALTUNOK ile birlikte gerçekleştirdik. Bir de bu eğitimlerden önce Sarı Anahtar - Tog oryantasyonu vardı. İYTE Saha Sorumlusu Cihan’ın başka bir eğitime gitmesinden ötürü oryantasyonu da ben gerçekleştirdim. Süper, tog, sivil toplum, gençlik, enerji dolu bir hafta sonu oldu.

Eğitimlere ve oryantasyona ortalama 22 - 24 kişi katıldı. Zaten var olan ekip, eğitimlere katılan arkadaşlar ile daha da genişledi. Eğitimler sırasında gerek uygulamalarımız da gerekse canlandırıcılar da bir gençlik topluluğunda olmanın ne demek olduğunu gösterircesine canlı, enerjik, verimli zamanlar geçirdik. Bundan sonraki süreçte orada kaynaşan ekibin güzel işler çıkarması en büyük dileklerimden bir tanesi. Ki bunu yapabileceklerini gösterdiler hem bizlere hem birbirlerine :)

İYTE kampüsü benim hoşuma gitti. Çok eleştiri vardı ama ben beğendim :) Gayet geniş, havadar, doğal bir yer. Fakat kampüs de bu kadar çok köpeğin olması biraz ürkütücü :P Havadar demişken, Hasan kardeşim eğitimin birinci gününde bende dönüşünde hasta olduk. Biraz fazla havadardı anlayacağınız :D

Cumartesi akşamı gittiğimiz mekan (Calipso), kır evi tadındaki kafe, kyk zamalarımı hatırlamamı sağlayan kyk yemekhanesi, iyte kütüphanesine girmek için çektiklerimiz :P her şey yorgunluğuna rağmen güzeldi, verimliydi.

Son olarak cumartesi gecesi bizi evinde misafir eden Egem’e, eğitime katılan tüm gönüllülere teşekkür ederim.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Sorumlular ve Proje Atölyesi Uygulama Yöntemleri

Wed, 04 Apr 2012 00:00:00 GMT

Şu yazımda Manisa’da yaptığımız Proje ve sorumlular atölyelerinden bahsetmiştim. Atölyelerin nasıl uygulandığı, hangi metotların kullanıldığı gibi konulara değinmemiş, bunlarla ilgili bir döküman oluşturacağımı söylemiştir. O dökümanı daha yeni oluşturabildim :D

Döküman içerisinde uygulamalar ile ilgili açıklamaları bulabilirsiniz.

Yararlı olması dileklerimle. Dökümanı indirmek için tıklayınız.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Manisa'da Sorumlular Atölyesi

Sun, 01 Apr 2012 00:00:00 GMT

Geçtiğimiz hafta sonu Manisa’da Celal Bayar Üniversitesi Toplum Gönüllüsü arkadaşlar ile iki adet atölye yaptık. Tog Manisa da örgütlenme içerisinde uygulanacak olan sorumluluk sisteminde sorumluluk alacak kişilerin hangi işleri yapacağını konuştuğumuz, belirlediğimiz sorumlular atölyesi ile örgütlenme içerisinde uygulanması için yeni projelerin oluşturulmasını amaçladığımız proje atölyesini gerçekleştirdik. İtiraf etmeliyim, iki atölyenin toplamda 7 buçuk saat sürmesinden dolayı çok yorulduk. Fakat hedeflediğimiz verimi elde ettiğimiz için bu yorgunluk hiç önemli değildi :)

Manisa Celal Bayar Üniversitesi Tıp Fakültesi Dersliklerinde yaptığımız atölyeler sırasında oldukça eğlenceli ama en önemlisi de konuşarak, tartışarak, üreterek zaman geçirdik. Kocaman derslikte atölyenin sonunda poster asacak duvar kalmaması, ellerimizin board marker ve keçeli kalemler yüzünden rengarenk olması zamanımızı hiç de boşuna geçirmediğimizin birer kanıtıydı :) Atölyeler de neler yaptık, nasıl yaptık gibi konulara girmeyeceğim. Atölyelerin çıktıları tamamlanır tamamlanmaz ve atölyelerde uyguladığım metodlardan oluşan dökümanı hazırlar hazırlamaz buradan paylaşmayı düşünüyorum. Ayrıntıları merak edenler dökümanları inceleyebilirler. Kim bilir, farklı alanlarda bu bilgilerden yararlanmak isteyenler olabilir :)

Atölyelere katılarak değerli zamanlarını ayıran, bilgilerini sunan tüm katılımcılara bir kez daha teşekkür ediyorum :) Önümüzdeki hafta sonu da İzmir Üniversitesi Toplum Gönüllüleri ile aynı atölyeleri gerçekleştiricez. Aynı güzellik ve verimlilikte geçeceğinden şüphem yok :D

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Nezle ve Nezle Adam

Wed, 28 Mar 2012 00:00:00 GMT

Ne illet bir şeydir nezle. Herhangi bir şekilde yakalandıktan sonra ellerimizde kağıt mendillerle gezmeye başlarız. Uzun bir süre devam eder bu. Öğrenciysek, kendi işimizi yapıyorsak ya da izin alması kolay olan bir işte çalışıyorsak tek derdimiz nezle ile mücadele etmek için işi gücü bırakıp kalabiliriz evimizde. Ohh rahat, sıcak evimiz de yatar, musluk olan burnumuzun civataları düzelene kadar yapmayız bir şey. Bu şekilde “nezle-adam” olmuş sayılmayız. Nezle olan adam/kadın ile nezle adam farklı şeylerdir.

Elbette her insan gibi şairler de zaman zaman nezle olmuş, olmakla kalmayıp nezleyi şiirlerinde misafir etmişlerdir. Şair A. Kadir bir dizesi ile her burnumu silişimde çıkardığım seste bir aşk melodisi aramama sebep oldu. İşte o dizeler;

Ben burda kasvetli bir yerde olurum
Sen orda rüzgarlı bir yerde olursun
Ben burda öksürür nezle olurum
Sen orda öksürür nezle olursun
Nezleyi dizelerinde misafir eden bir diğer şair de Orhon Murat Arıburnu’dur.
Gani gönüllü Mustafa Bol verir,
herkes sever Lakin Macuun!..
diye bağırırken sesi sevilmez
Nezledir!..

Rengarenk tablasının arkasında “Macuun” diye bağıran seyyar satıcının sesi elbet kırıktır. Nezle olsa bile çocuklarının cep harçlıklarını toplamak, akşam sofrasına ekmek taşıyabilmek için hasta hasta adımlar durur sokakları, bir çok işçi kardeşi gibi… Bir çok kişi tek derdi nezleymiş gibi evinde kalıp hastalığı atlatmaya çalışırken kafasını cama çevirip de dışarıda, soğukta çalışan insanları görmez. Ama gören birisi vardır.

Bardaktan boşanan yağmurun altında
kablo çekiyor amele
bizimse odamız sıcak çay ibriği kaynıyor
bir derdimiz var: Nezle!

Dışarıya bakıpta soğukta, yağmurun altında çalışmak zorunda olan işçileri gözlemleyen kişi Oktay Rifat’dır. Tek derdimiz nezle olmasa bile öyle davranmaktan kendimizi alamamamız, ne komik bir şeydir.

Nezle olan kadın/adam, aynı zaman da “nezle-adam” olmuyor demiştik. Peki ama nedir bu “nezle-adam”? Bunun cevabını Nazım Hikmet’ten dinliyoruz.

“Nezleye benzeyen nezle-adam’lar vardır. Nezle-adam size yapacağı kötülüğü önceden bildirmeyecek, anlatmayacak kadar güçsüzdür, boysuz bossuzdur. Ancak onun bütün gücü, bütün boyu bosu buradadır. Nezle nasıl bir öksürükle, bir el sıkmasıyla yakanıza yapışırsa, nezle-adam da bir iki söz, ufacık bir yalanla yakanıza yapışır ve yapıştı mı bir, onun yumuşak, ıslak ellerinden kolay kolay kurtulamazsınız. Ne nezle olun, ne nezle-adam’larla arkadaş…”

Sunay AKIN - İstanbul’un Nazım Planı

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Kriptoloji = Kriptografi + Kriptoanaliz

Mon, 27 Feb 2012 00:00:00 GMT

İlgimi uzun zamandır çeken ve üzerinde çeşitli araştırmalar, çalışmalar yaptığım kriptoloji; bilgisayar biliminde güvenlik, gizlilik dendiğinde akla gelen ilk alan olması sebebiyle hem yazılımcılar hem de bilgisayar kullanıcıları açısından büyük önem taşıyor.

Teknolojinin inanılmaz hızlı gelişimi sırasında hayatımızı kolaylaştıran, güzelleştiren yapılar bir yandan da güvenliğimizi tehdit edecek eksiklikleri de kendileri ile birlikte hayatımıza sokuyorlar. İnsanların ağlar aracılığı ile birbirleri ile bilgi paylaşımlarında bulunmaları bir yandan da bu bilgilerin üçüncü, beşinci, onuncu kişiler tarafından elde edilme olasılıklarını arttırıyor.

“Facebook da arkadaşımla sohbet etmem de ve o konuşmalarımın alınmasında ne sorun var ki?” diye bir soru aklınıza gelebilir. “Hey, naber?”, “İyidir, senden naber?” gibisinden bir sohbet evet sizler için ileride bir sorun teşkil etmeyebilir ama daha derin konuşmalarınızdan bilgisayar korsanlarının yararlanabileceğincen emin olabilirsiniz ;) Olayı biraz daha geniş düşünmekte fayda var.

Devlet kurumları, askeri birimler vb. önemli kuruluşlar da internette, bilgisayar ortamında bilgi paylaşımında bulunuyorlar ve evet onların paylaştıkları bilgiler “Naber?” değil. Bir e-ticaret platformundan yaptığımız alış verişlerimiz de kart numaramızdan tutunda bir çok bilgiyi sisteme güvenerek bir yerelere gönderiyoruz. Peki ama nereye gidiyor? Nasıl gidiyor? Giderken yolculuğu nasıl geçiyor, başına bir şey geliyor mu? diye düşünüyor muyuz? İşte bu soruları aklımıza getirmeden, güvenli bir şekilde bilgisayar dünyasından paylaşımlarda bulunmamız için bilgisayar bilimciler kriptolojiyi kullanıyorlar.

Peki ama Kriptoloji tam olarak ne?

Kriptoloji; temeli zor matematiksel işlemlere dayanan, bilgi paylaşımında bulunan iki veya daha fazla tarafın arasındaki iletişimin güvenli bir şekilde sağlanması için kullanılan tekniklerin adıdır. Kriptoloji bir matematik bilimidir ve genelde sayılar teorisi üstüne kuruludur. Kriptoloji konusunda çalışan kişiler, bir yandan bilgilerin daha etkili bir şekilde gizlenmesi (Kriptografi) ile uğraşırken bir yandan da bu şifrelerin nasıl çözüleceği (Kriptoanaliz) ile ilgili çalışmaktadırlar. İşte bu yüzden şifre bilimi kendi içerisinde iki farklı alana ayrılır. Kriptografi’nin temel amacı iki veya daha fazla ilgili kişi arasında giden gelen verilerin ilgisiz, alakasız kişiler tarafından anlaşılamamasını sağlamaktır. Bunun için gönderici tarafından gönderilecek olan veri belirli kurallar uygulanarak anlaşılamayan bir veri elde edilir.

Örnek: Açık mesaj: Merhaba ------------ Kapalı mesaj: abahreM

Bu anlaşılamayan mesaj ( burda anlaşılıyor ama aldırmayın :P ) alıcıya ulaştığında, alıcı mesajın oluşturulma kuralını tersten kullanarak orjinal mesajı elde eder (Kriptoanaliz). Kriptolojinin önemi gün geçtikçe artıyor. Modern kriptoloji mesajın istenmeyen kişiler tarafından anlaşılamaması, iletimi sırasından değiştirilememesi, mesajı gönderenin saha sonradan “Bunu ben göndermedim.” diyememesi ve mesajı kimin göderdiğinin anlaşılabilmesi gibi konularla ilgilenmektedir. Kriptolojiye küçük bir giriş yaptığım bu konunun ardından kriptoloji dili, kripto sistemler ve bir sürü konu ile ilgili makaleler paylaşacağım. Bilgilerin yararlı olması dileklerimle.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Odamın Duvarında Volta Atan Mahkumlar, Tutuklular Çemberi

Tue, 31 Jan 2012 00:00:00 GMT

Dünyaya açılımı 1800’lü yıllar da imparator Meici tarafından sağlanan Japonya, bu dönemde Avrupa’ya tabak, çanak, fincan gibi japon seramiklerini ithal etmeye başlamıştı. Tüccarlar uzun süren deniz yolculuklarında eşyaların kırılmaması için kağıtlara sıkıştırılmalarını isterler. Porselen ve seramikler hazırdır, sipariş de vardır, ama ambalaj olarak kullanılacak kağıt ihtiyacı da çoktur.

Geleneksel Japon resim sanatı olan “ukiye-o” yetişir imdada. Doğa ve gündelik hayata ilişkin olan bu resimlerden Japonya’da öylesine çok vardır ki, eski ve kullanılmayan “ekiye-o”ler Avrupa’ya gönderilen kırılacak aşyanın sarılmasında kullanılır.

Gemiler Avrupa kenarlarına ulaştığında, akılları porselen ve seramiklerin kırılıp kırılmadığında olan tüccarlar, paketleri açıp eşyaları kontrol ederler ve bu sırada da kağıtları atarlar.

Zamanla, “ekiye-o” resimlerinin limanda biriken kağıtları sanatsever tüccarların ilgisini çeker. İnsana huzur veren reklerle çizilen resimlerden etkilenenler o kadar çoktur ki, onlardan biri Anvers Limanı’na her gün gelmekte ve porselen takımları koruma görevi sona erdikten sonra atılan resimleri toplamaktadır. O adam Hollandalıdır ve hiç tanımadığı Japon sanatının dilinden etkilenerek tablolar yapıp, altlarına imzasını “Vincent van Gogh” olarak atacaktır.

Vincent van Gogh’un öyle bir tablosu vardır ki, sanatçının diğer eserleri arasında aykırı ve çok farklı durmaktadır. Moskova Puşkin Müzesi’ndeki bu tablonun adı Prisoners Round-after Gustave Dore’dir (Tutuklular Çemberi - Gustave Dore’den sonra). Bu tablunun öyküsü Fransa’nın Strasbourg kentinde yaşayan yedi yaşındaki bir çocuktadır…

Dadısı Françoise, kapıyı açtığında karşısındaki çocuğu görünce çok şaşırır. “Tanrı aşkına! Efendi Gustave, ne oldu sana böyle?.. Kutsal bakire aşkı için, ayakkabıların nerede? Annen seni bu durumda görünce ne diyecek? Neredeydin?”

Soğuk bir kış günü eve yalın ayak dönen çocuk yanıt verir: “Tamam Françoise, bugün oldukça talihsiz bazı kimselerle, özellikle de kokunç derecede yoksul küçük bir çocukla bayağı bir yol yürüdüm. Benim gibi biriydi, ama paçavralar içindeydi ve ayağında pabuçları yoktu. Kışta kıyamette onu öyle görmek beni üzer biliyorsun. Bu yüzden ona kendiminkileri verdim, çünkü onun benim gibi ayakkabı alacak bir babası yok. Bu konuda hiç bir şey söyleme. Eski pabuçlarını dört ay daha giyerim. Ayaklarına tam uydu; ne şans değil mi?”

Gustave Dore’dir, ayakkabılarını çıplak ayaklı bir arkadaşına verecek kadar duyarlı olan çocuğun adı… Ve, bu duyarlılığını büyüdüğünde resimlerine, gravürlerine taşıyacaktır.

Vincent van Gogh, 1890 yılında, Arles’daki St. Paul Akıl Hastanesi’nde tedavi görürken, kardeşi Theo ona Gustave Dore’nin bir gravürünü gönderir. Dore’nin Newgate-Exercise Yard (Newgate Hapishanesi’nde Volta Atan Mahkumlar) adlı bu eserinde, Charles Dickens’ın “Londra’nın sefaletini ve suçluluğunu barındıran bir depo ” olarak tanımladığı ünlü hapishanede çember şeklinde volta atan mahkumlar görülür. Van Gogh, Dore’nin bu eserinden öylesine çok etkilenir ki, aynısını tuvale aktarır. Dore’nin gravüründeki hapsedilmişlik duygusu ve duvarlar arasından kurtulma arzusu, van Gogh’un akıl hastanesinde yaşadığı sıkılmışlıkla birebir örtüşmektedir. Öyle ki, resimde adımlarını tutuklusu ve suçluluk duygusuyla atan adamlar arasında, ortada duran bize doğru bakan şapka giymemiş tek mahkum Vincent van Gogh’tan başkası değildir.

Kendimi sıkışmış, isteksiz hissettiğimde bu iki tabloya bakarım. Çoğu sabah bu resimlerden kurtulan birinin hissedebileceği gibi mutlu çıkarım evden. Özgürlüğü hatırlatan bu resimlere bu günlerde farklı bir sebepten daha bakıyorum. Bu soğuk havalar da tuvalden bana bakan van Gogh ile her göz göze gelişimizde dışarıda olan, üşüyen , insanlar geliyor aklıma. Gustave Dore gibi ayakkabılarımı vererek herhangi birisine yardımcı olabilmek istiyorum. Ama hangi birisine yetebilirim ki.

Sokakta, soğukta olduğunu bildiğiniz gördüğünüz kişilere aşağıdaki numaralara ulaşarak yardımcı olabilirsiniz. Ayakkabılarımızı vererek yeterince yardımcı olamayabiliriz fakat bir telefon ile çok yardımcı olabiliriz.

ANKARA: 4186662
İSTANBUL: 4551300
İZMİR: 3617151

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Php de Anagram Şifreleme

Mon, 19 Dec 2011 00:00:00 GMT

Son zamanlarda kritografiye ilgi duymaya başladım. Okul, staj, iş, toplum gönüllüleri derken yazılımsal anlamda ilgi duyduğum farklı alanlar konusunda çalışma yapmak konusunda pek zamanım kalmasa da arada sırada zamanım oluyor :) Dünde böyle bir zaman ayırdım kendime ve edebiyatta bir sözcüğün harflerinin farklı dizilmesi ile yeni bir sözcük elde etme olarak bilinen anagram tekniğini kullanarak bir şifreleme scripti yazdım. Anagram tekniği hakkında bilgi almak için tıklayın.

Anagram ile bir metnin şifrelenmesi çok karmaşık olmayan bir algoritma ile sağlanabiliyor. PHP nin karakter işlemler için sağladığı fonksiyonları doğru yerlerde kullanarak, çok uzun olmayan bir kodlama ile şifreye ulaşabilirsiniz :) Ben scripti yaparken daha dinamik bir sistem olması düşüncesi ile Php’nin yanında Javascript(ajax) kullandım. Tek sayfa üzerinden işlemimizi halledebiliyoruz. Anagram Şifrele Kaynak Dosyaları: Anagram Şifreleme Kayank Kodları

NOT: Script i indirdiğiniz taktirde kodların açıklamalarını dosyanın içerisinde bulacağınız için tekrardan buradan açıklamak istemiyorum. Yararlı olması dileklerimle, kolay gelsin :)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

PHP de BiSection Method ile Bir Fonksiyonun Kökünü Bulma

Sun, 18 Dec 2011 00:00:00 GMT

Matematikte bir fonksiyonun köklerini bulmaya yarayan bisection method, verilen değer aralıklarından başlayarak sürekli olarak bu iki değer arasından yeni bir değer oluşturup bu değerin fonksiyonu sıfıra ne kadar yaklaştırdığına bakarak, fonksiyonun kökünü bulamaya yarayan yöntemdir. Ayrıntılı bilgi için tıklayın.

Karabük Üniversitesi Bilgisayar Mühendisliği’nde okuyan can dostum Mustafa UYSAL‘ın algoritma dersi kapsamında, bisection method kullanılarak bir fonksiyonun kökünü hesaplayan programı C programlama dilinde geliştirmesi gerekiyordu. Bu yüzden bende yardımım dokunabilmesi için bisection method ile ilgili araştırma yapıp bir algoritma çıkartmak için kolları sıvadım. Araştırmalarım sonucunda algoritmamı hazırladım ve ardından daha somut bir şeyler görebilmek için PHP kullanarak fonksiyonun köklerini hesaplayan bir script ortaya çıkardım. Bu script’in kaynak kodları içerisinde her adım da yapılan işlemlerin açıklamalarını bulabileceğiniz için tekrardan buradan anlatma gereği duymuyorum. Bu yazıda sadece benim PHP kullanarak oluşturduğum scriptin kaynak kodlarını sizlerle paylaşacağım. C dilinde yazdığımız program ile ilgili paylaşımları Mustafa UYSAL proje teslimi ve değerlendirmelerin ardından kendi sitesinden yapacaktır.

Kaynak Dosyaları: BiSection Kaynak Dosyaları

Yararlı olması dileklerimle, kolay gelsin.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Kuşlar Cıvıldıyor, Evet Uyanmışım...

Tue, 22 Nov 2011 00:00:00 GMT

Az önce uyandım. Uyanıp uyanmadığımı anlamak için uzun süre kendimle soru cevap oyunu oynamak zorunda kaldım. Midem gerçekten ağrıyor muydu? Yoksa gece yarısı sadece dolaşmaya mı çıkmalıydım, yemek yemekte nereden çıktı? Yatak iktiriyor beni. Bir şeyler batırarak, ağırlığımdan yorulduğu için kovuyor beni. Kalk. Kalkamıyorum. Bedenimin ağırlığı değil ki bu… Düşüncelerimin gerçek yüzlerinin dayanılmaz çekingenliğinde, gerçeklere bakmanın, gerçekleri yaşamanın verdiği isteksizlik.

Bugün gerçekten işe gitmeli miyim? İşe gidip öğleye kadar bilgisayar başında en iyi yaptığım işlerden birini yapıcam. Ne kadar iyi yaptığım iş var ki? Evde kalıp kitap okusam? Midem ağrıyor. Yatak kalk üstümden diyor. Yorganın ağırlığı ezmeye başlıyor beni. Öğle işten çıkıp derse gitmeliyim. İletişim ile ilgili zar zor iletişime girilerek yapılan bir ders. Sevgili, aşk, sex … Konuşabildiğimiz konuların ilişkiler ile sınırlandığı bu derste olmalı mıyım? Tüm gün işte olma fikri geliyor aklıma. Vazgeçiyorum.

Hafta sonu gördüğüm, tatlı gülüşüne takıldığım kız geliyor aklıma. Ne kadar da saf, temiz duruyordu. Bu düşünceyi kovuyorum hemen. Başıma gelenlerin hepsinin en temel sebebi bu değil miydi? Saf, temiz insan … “Acaba sevgilisi var mıdır?” diye düşünüyorum bir ara. İğreniyorum bu düşüncemden hemen. Sevgilisi olmasa ne olacak ki? Dün yaşadığım beş saniyelik bir an geliyor aklıma. Beş saniye, fakültemin girişindeki kızın kırmızı rujuna takıldığım an. Bir şiir’den, kızın diliyle ıslattığı hafif parlayan ince ve kırmızı dudaklardan başka bir şey hatırlamıyorum. Şiiri tekrar hatırlıyorum. Sunay AKIN’ın kırmızı şiiri;

Sevgilim kızma sakın ve lütfen yanlış anlama kırmızı rujunu sürünce paramın yetmediği elma şekerleri geliyor aklıma.

Yatakta doğruluyorum artık. Evet uyandım. Yüzümü yıkamalıyım. Su… Ne kadar derin bir kelime. Ama artık o da saf değil ki… Tekrar yatmak istiyorum. İnsanların gerçekleri dile getirme konusundaki beceriksizlikleri geliyor aklıma. Ya da onlardan kaçma isteği. Kaçamayacağını bilemeyerek. Ne istediğini bilmeyenler var bir de. Davranışları ile söyledikleri birbirini tutmayanları ne yapmalı. Son yaşadığım olay geliyor aklıma. Çarpık diyorum, tek kelime. Arkadaşlık anlattığı gibi olmaz. Yüzümü yıkıyorum, odama dönüyorum. Sifonu çekmiş miydim? Yazma isteği duyuyorum. Bilgisayarı açıp açmama konusunda bir kararsızlık. Hem okumak hem yamak istiyorum. Yazma isteği ağır basıyor. Bilgisayar açılırken Dostoyevski’nin Budalasından bir kesit geliyor aklıma.

Gözümün doğrusuna yürüsem, göğün yerle birleştiği çizgiyi geçince bütün bilinmezlerin çözüleceği inancına kapılırdım.

Bilgisayar açılıyor. Midem hala kötü. Saat ilerliyor. Evden çıkma vaktim geldi. Yazmak güzel geldi. Ama hala bir sürü düşünce aklımda. İşe gitme kararım kesin, sonrasında da derse gitme. Ardından ne yaparım. Belki yine kırmızı rujlu kızı görürüm. Bu kez yüzünü de aklımda tutmalıyım.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Paradokslar - Düşünce

Tue, 15 Nov 2011 00:00:00 GMT

Paradoks; görünüşte doğru olan bir ifade veya ifadeler topluluğunun bir çelişki yaratması veya sezgiye karşı bir sonuç yaratmasıdır. Doğru gibi gözüken önerme veya fikirler, tamamen yanlış olarak çıkar karşımıza. Bazende, yıllarca yanlış olarak zannettiğimiz olaylar, düşünceler doğru olarak bizi şaşkına çevirirler.

Hayatımın çok çok yoğun olduğu bugünler de bir sürü şey düşünüyorum. Kendime ayırdığım zamanlarda da beynim sürekli bir arayış içerisine giriyor. Bu süreçleri değerlendirmek için başvurduğum yollardan birisi de paradoksları araştırmak, üzerlerine düşünmek oldu. Bloguma uzun süren bir aranın ardından dönüş olması için de bulduğum bazı paradoksları sizlerle paylaşmak istedim. Umarım okurken, düşünürken sizde keyif alırsınız. Hadi iyi düşünceler :))

Giritli Eupiminides “Bütün Giritliler Yalancıdır.” Eğer gerçekten giritliler yalancı ise kendisi de giritli olduğuna göre o da yalancıdır.

Eublides “Yaptığım Açıklama Yanlıştır.” Cümlenin doğru olduğunu düşünürse cümlenin yanlış olması gerekir, eğer cümlenin yanlış olduğunu düşünürsek de doğru olduğunu kabul etmiş olur fakat yanlış olduğunu başta kabul ettiğimiz için tam bir paradoksa düşmüş oluyoruz.

Cümle Paradoksu “Bu cümle yanlıştır.” Cümle yanlışsa doğru, doğruysa da yanlış olmak zorundadır.

Timsah Paradoksu “Bir annenin elinden çocuğunu kapan timsah, çocuğa ne yapacağını annenin bilmesi durumunda çocuğu vereceğini söyler. Anne, timsaha çocuğunu yiyeceğini söyler, böylelikle meydana gelen paradoksal durum sonucunda çocuğunu kurtarır.”

Şöyle ki, timsah çocuğu yiyecekse anne timsahın ne yapacağını bilmiş olacak ve timsah çocuğu teslim edecek ancak çocuk teslim edilince anne timsahın ne yapacağını bilememiş olacak; timsah çocuğu yemeyecekse anne bilemediğinden çocuğu yiyecek ama o zaman anne timsahın yapacağının bilmiş olacak ve bu yüzden yememesi gerekecek. Kısaca, bu iki durumda da timsah çocuğu ne yiyebilir ne de yiyemez.

SOCRATES “Bildiğim tek şey var; o da hiç bir şey bilmediğim.”

Yalancı paradoksu “Şimdi yalan söylüyorum.”

Bu önermenin doğruluk değeri nedir? Yani “şimdi yalan söylüyorum” derken doğru mu söylüyorum yoksa yalan mı söylüyorum? Düşünecek olursak;Bu önermenin doğru olduğunu varsayalım. Öyleyse yalan söylüyorum. Ancak önermenin doğru olduğunu varsaymıştım öyleyse çelişkiye düştüm.Bu önermenin yalan olduğunu varsayalım. O zaman bu cümle doğru olmalıdır. Gene bir çelişki.

Yamyam Paradoksu ” Bir adada yaşayan bir grup yamyamın eline bir mantıkçı düşer. Yamyamlar mantıkçıya şöyle derler: “Biz her yakaladığımız yabancıyı yeriz. Kimini haşlayıp, kimini kızartıp yeriz. Avımıza bir soru sorarız. Avımız soruyu doğru yanıtlarsa haşlarız, yanlış yanıtlarsa kızartırız.”

Dedikleri gibi de yaparlar. Mantıkçıya şu soruyu sorarlar: “Seni haşlayıp da mı yiyeceğiz, yoksa kızartıp da mı yiyeceğiz?” Mantıkçı bir süre düşündükten sonra soruyu çok akıllıca cevaplar: ‘Kızartacaksınız!’ ” Bir an için mantıkçının kızartılacağını varsayalım. O zaman verdiği yanıt doğru olur. Ama yanıt doğru olduğu için -yamyamların kendi kurallarına göre- mantıkçının haşlanması gerekmektedir. Demek mantıkçı kızartılamaz. Şimdi de mantıkçının haşlanacağını varsayalım. O zaman mantıkçının yanıtı yanlış olacak. Yanıt yanlış olduğundan da kızartılması gerekmektedir. Demek mantıkçı haşlanamaz da. Yamyamlar tam bir kısırdöngüye girmişlerdir. Kızartsalar haşlamaları gerekecek, haşlasalar kızartmaları! Sonuç olarak adamımız kurtulur.

Berber Paradoksu “Seville’ in kendini traş etmeyenlerini traş eden berberi kendini traş eder mi etmez mi?” Kendini traş etmeyenleri traş eden berber kendini traş ederse kendi kendiyle çelişki içine düşer. Kendini traş etmezse tanımdan ötürü kendini traş etmesi gerekir, ama bu da bir çelişkidir.

Kant “Her ne kadar ben inanmasam da bir tanrının var olduğunu kabul etmek gerekir.”

Para paradoksu “Aynı paradan ikisini yan yana koyup birini sabit tutarak diğerini onun etrafında döndürün. Döndürülen para yarım tur attığında kendi ekseni etrafında bir tam tur atmış olacaktır.”

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Ayçöreği ve Deniz Yıldızı --- Sunay AKIN

Sat, 15 Oct 2011 00:00:00 GMT

Sunay AKIN dünyası farklı; bilginin, ayrıntının yoğunluğunda insanın düşünmek için var olduğu bir dünya. Ayçöreği ve Denizyıldızı da o dünyaya açılan kapılardan bir tanesi sadece.

Arka Kapak

Bir adam var bilir misiniz? Her gece deniz ilk dalgalarla uyanana değin, umutları, hüzünleri, bekleyişleri ve ruhun ışığını, eski kitapların hamuruna katarak rengarenk ayçörekleri yaratan; özgürlük adına, barış adına, emek adına… Peki, hiç yediniz mi onun bu sihirli ayçöreklerinden? Eğer kocaman bir parça ısıracak olursanız, kendinizi bir anda, küçücük ışıklardan oluşmuş bir gemide bulabilirsiniz; minareler arasında uyuyan bir mahyaya yelken açmış… Belki de birdenbire duyuverirsiniz tulumbacıların o alevlenen şarkılarını; cariyelerin aklına başından alan… Ya da bir tarlanın başucundan, koşarak geliverir yanınıza bir korkluk -emeğin bu en eski koruyucularından sevimli ve cesur varlık- ve onunla elele gidersiniz miting alanlarına, yine kucaklamaya; sevgiyi, alınterini, kardeşliği… Korkmayın sakın, başınızın üzerinden ansızın uçuverirse bir cadı; kaçmaktadır belki o da yakılmaktan… Sunay Akın “Ayçöreği ve Denizyıldızı”nı yine bir filozof zekası ve inceliğini, bir çocuğun kalbi, bir şairin duyarlılığı ve bir serüvencinin düşgücüyle sunuyor bizlere. Kitabın her lokması; yaşamın bir başka ucu, dünyanın bir başka köşesi… “Ayçöreği ve Denizyıldızı” tam bir Sunay Akın’sal deneme… Ama kitaptaki her denemenin sonunu, bir roman okuyormuşcasına merakla beklediğiniz için; yazılanlar belki bir roman, dizelere yansımış, neredeyse hiçbir gerçek kalmadığı için dünyada; belki de bir şiir tüm yazdıkları. Yine de her şeyden önce, çok düşünen, merak eden, araştıran, kolay ikna olmayan bir kitap gezgininin görüp keşfettikleriyle dolu, bambaşka bir iklim bulutu bir yapıt… Kitabı okuyup bitirdikten sonra bazı geceler “Anne Frank”ın solgun şarkılarıyla uyanacaksınız uykularınızdan… Ve birlikte, ayışığında titreyen bir kumsalda bulacaksınız kendinizi… İşte o an, eğilip deniz yıldızlarını topladığını göreceksiniz “Anne Frank”ın… Sabahın ışıklarıyla, hiç beklemedikleri bir anda, onlar da yanıp kül olmasınlar diye..

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

İstanbul'un Nazım Planı

Sun, 02 Oct 2011 00:00:00 GMT

Sunay AKIN dünyasının o güzel ahengi ile Nazım HİKMET ‘in birleştiği bir eser. Şiir bir düz yazıya daha ne kadar güzel harmanlanabilir ki?

Arka Kapak Yazısı

Saraylardan haber uçar “bizi de yaz” diye, duymazlıktan gelir. İnadına gecekondular, Kız Kulesi’ni, işçi kahvelerini yazar. Yağmur pencerede sırasını beklerken; o şemsiyeleri yazar. Pembe dizilerde balonlar uçarken; işçi sigaralarının ucunu yazar. İncili boncuklu kadınlar aynalarda gezerken, o, “lambalı kadın”ı yazar.

Birileri Hırsızıstan’a damat olurken; hiç üşenmez, Berberistan’ın kanaryalarını yazar. Yarış atlarına ve süs köpeklerine övgüler düzer birileri; o, atlıkarıncaya içi giderek bakan çocukları yazar. Bal tutanlar parmaklarını yalarlar; o, denize dökülen simitleri yazar.

Medya hokkabaları para sayma makinalarını ceplerinde taşırken; o, Ahmet Samim’i yazar. Haydarpaşa’nın işçi tulumuyla dolu gardırobunu yazar. Ve herkes gecenin bir yerinde söndürmüşken fenerini; Sunay Akın birileri ateşin altını beslesin, karanlık defolup gitsin diye, “devrim” sözcüğü güzel kitapların ilk sayfasına yazılsın diye, sabahlara kadar beynine fazla mesai yaptırıp, Nazım Hikmet’in gülümseyen bir fotoğrafına bakarak “İstanbul’un Nazım Planı’nı yazar.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Madımaktan Amsterdama Düşülen Not

Tue, 05 Jul 2011 00:00:00 GMT

Anne Frank, saat 6 da uyanır, 13 yaşına girdiği 1942 yılının 12 Haziran günü. Anne ve babasının kızaacğından korktuğu için bir saat yatağın içinde oyalanır. Sonra da yemek odasında kendisini bekleyen armağan paketlerini açmaya koyulur. Gözüne ilk çarpan bir hatıra defteri olur. Sanki bir insanmış gibi sayfalarında “Kitty” diye sesleneceği, yaşantısının geride kalan iki yılını günü gününe yazacağı, pembe kaplı, sırdaş bir hatıra defteri. Hasan Hüseyin’in “Büyük Sürü” şiirinde bu defterle karşılaşırız:

Sen her gün Hitler’sin Ben her gün Yahudi Oturur ağlarsın utancından Anne Frank’ın hatıra defterine

Amsterdam’da yaşayan Frank ailesi, gamalı haçların bu şehrin sokaklarına da asılmaya başlamasıyla ölüm korkusunu enselerinde duyar. Yahudi oldukları için her an toplama kampına götürülme olasılıkları vardır. Otto Frank’ın aklına bir kurnazlık gelir. Kendisi için toplama kamplarına götürülme çağrısı gelince planını uygulamaya koyar. Plan şudur: Kaçar gibi yapacaklar, arkalarında öyle bir hava estirecekler, fakat kentten ayrılmayıp bir evin çatısında gizleneceklerdir.

Anne Frank, gizlendikleri evde ilk olarak 9 ağustos günü seslenir Kitty’ye. Prinsengracht 263 adresinde bulunan ev gizlenmek için ideal bir yerdir. Otto Frank’ın eşi ve iki kızıyla birlikte sokağa hiç çıkmadan, gündüz yüksek sesle konuşmadan, gürültü yapmadan, perdeleri kımıldatmadan barış dolu günleri beklemeye koyulduğu yer, iş yerinin üst katlarıdır. Peter adlı bir oğulları bulunan Van Daan ailesinin de gelmesiyle gizlenenlerin sayısı yediye yükselir. Kısa bir süre sonra da yaşlı bir diş doktoru katılır aralarına. Sekiz insan yakalanıp öldürülme pahasına dostlarının getirdikleri yiyeceklerle doyururlar karınlarını. Bundan sonrası umut ve korkunun sarmaşık gibi birbirine dolandığı günlerdir. Anne Frank’ın ablası Margot’un, babasına doğum günü armağanı olarak yazdığı şiir, gizli bölmenin nabzını tutar:

Gece yarısı duyuldu ilk top sesi. Ne oldu, ne var? Kapımı gıcırdıyor ne? Bir kızcağız görünür, sapsarı beti benzi, Bir yastık bastırmış sıskacık göğsüne.

25 Eylül 1942’de, Anne Frank şunları yazar Kitty’ye: “Dün gece yukarı yukarı çıkıp Van Daan’ları ziyaret ettim. Peter’den söz ettik. Peter’in ikide bir yanağımı okşadığını anlattım şikayet yollu. Sevmiyorum oğlan çocuklarının böyle üstüme varmasına.” Yanağının, kendisinden yaşça büyük Peter tarafından okşanılması hoşuna gitmeyen Anne Frank, 1944 yılının 16 Nisan günü “Dünkü tarihi aklından çıkarma” diye seslendiği Kitty’ye en önemli sırlarından birini verir: “Kızların hayatlarında illk öpüştükleri günü dönüm noktasıdır. Benim başıma geldi de bu. Artık Bram’ın sol yanağıma, Walker’ın sağ yanağıma oturttuğu öpücüklerin pabucu dama atıldı.”

15 Nisan 1944’te faşistlerin çok korktuğu bir şey olur. Amsterdam’daki ahşap bir evin çatı katında bir aşk doğar. Peter ile anne Frank arasında: “Dün akşam saat sekizde Peter ile divan üzerinde oturuyorduk, çok geçmeden elini belime attı. Baya bir yakınlaştık ve iş bununla bitmedi.”

4 Ağustos 1944’te, Gestapo’nun çizmeleri gıcırdatır tahtaları. Anne Frank’ın, Goethe’nin “Gökler katında ya da umutsuzluğun derinliklerinde” dizesiyle tanımladığı evde gizlenen sekiz insan, çok korktukları toplama kamplarına gönderilirler. Nasıl yakalandıklarını, kendilerini kimin ihbar ettiğini öğrenemezler. Bu soruların yanıtı günümüzde de verilememektedir.

Savaş sonrasında geriye ilk dönen Otto Frank olur. Bombalardan harabeye dönen bir kentte ailesinden, arkadaşlarından bir haber alabilmek için uğraşırken, gizlendikleri günlerde yardım eden Bayan Miep, götürülmelerinin ardından yerde bulduğu bir defter uzatır kendisine. Otto Frank, küçük kızının elyazısıyla dolu olan sayfalrı okurken, bekleyişinin bir kez daha boşuna olduğunu öğrenir. Bir evin çatısında saklanan sekiz kişiden yedisi toplama kamplarında öldürülürler!.. Kurtulan bir tek Otto Frank’tır… Bir de, Kitty!

Amsterdam’daki hatıra defterinin bir diğeri de, Thuys ailesinin evindeki bir çekmecede durmaktadır. Bu defter, antropoloji öğrenimi gören Carina Thuys’un el yazısını taşır. Deftere en son 2 Temmuz 1993 tarihinde, Sivas’ta yazılır. Yer, Madımak Oteli’nin merdivenleridir: “Şimdi durum kritik. Bir süreden beeri oteldeyiz. Dışarıda büyük bir güruh bağırıyor. Bu otelde özgür düşünür, laik yazar Aziz Nesin kalıyor. O, Şeytan Ayetleri’ni yayımlamayı düşünüyor. Durum hiç de hoş değil. Kendimi gergin hissediyorum. Çünkü ne olacağını hiç bilmiyorum. Bu durum aşırı dincilerin bir oyunudur. Slogan atıyor ve tahribat yapıyorlar. Oldukça polis var. Ama ben ne yapabilirim ki? Bağırılıyor, çağırılıyor ama ben anlayamıyorum…” Sivas’ta yakılan 37 insandan biri olan Carina Thuys, tezine konu olarak seçtiği Alevi kültürüni daha yakından tanımak, çalışmalar yapmak üzere Pir Sultan Abdal şenliklerine katılır. Ailesine gönderilen eşyalar arasından çıkan günlüğe, 22 Haziran 1993’te, Amsterdam Havaalanı’nda şunları yazar genç kız: “Türkiye’ye giden uçakta adım yoktu. Bir kaç dakika korktum: Gidemeyecek miydim?..”

Sunay AKIN, Ayçöreği ve Denizyıldızı

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

İlk Ev Arkadaşım, Hoşlandığım Kadın ve Dostum Sandığım Adam

Fri, 01 Jul 2011 00:00:00 GMT

Hayat bir şakadan ibaret geliyor artık bana. Bazen kötü bazen güzel şakalara maruz kalıyoruz. İnsanın yaşanmışlıkları attıkça güzeli de kötüsü de karşısına fazlasıyla çıkmaya başlıyor. Yaşadığım ve başardığım onca güzel şeye rağmen şu son 7 ay içerisinde 3 kişinin bana yaşattıkları yüzünden psikolojim alt üst oldu. İnsan içine çıkma isteğim kalmadı, girdiğim ortamlardan zevk alamadım, kendimi işime vererek oyalanmaya çalıştım. Şuan bu yazıyı yazabiliyor olmam iyileştiğimin bir göstergesidir.

Mevlana bir sözünde şöyle seslenir bizlere: “Denizin dibinde incilerle taşlar karışık olarak bulunurlar, övülecek şeyler de kusur ve yanlışların arasında bulunurlar.”. Benim de yaptığım onca güzel şey yalnız kalamazlardı ve kalamadılar da.

İlk kötü şakayı, ilk ev arkadaşım yaptı. Bu adam üniversiteye ilk geldiğim de tanıştığım, bölümüme geçtikten sonra arkadaşlığımızı devam ettirdiğimiz birisiydi. İyi denebilecek seviyede şiir yazan ve boş konuşmak üzerine ileri düzey bir yeteneği olan bu arkadaş; onca sınıf arkadaşı olmasına, katılıyorum dediği onca topluluk olmasına rağmen benimle arkadaşlık etmek istiyordu. Bunun sebebi iyi bir dost olmam da olabilir fakat asıl sebep insanlar arasında kendisine yer edinememesiydi. Kim ne yapsın böyle adamı? Boş boş konuşup insanları rahatsız eden, her kadına sırnaşmaya çalışan, haksız olduğu zamanlarda karşısındakine haklısın diyemeyecek kadar aciz bir insan. İşte ben böyle bir adamla aynı evde yaşama kararı aldım. Bunun sebebi başka arkadaşım olmaması değildi. Benim ben geliyorum dediğimde evini açacak hatta evini değiştirecek bir sürü arkadaşım var. Fakat insanlar içinde yer edinemeyen, toplumsal alanda tutunmayı bilemeyen bu arkadaşıma iki yıl uğraştığım gibi daha yakından uğraşarak bir şeyler katabilirim diye düşündüm. Düşünmez olsaydım keşke.

Bir dönem (üniversite eğitim dönemi) boyunca aynı evde kaldık. Elimden geldiğince yardımcı olmaya çalıştım. Tabi o da bana yardımcı olmaya çalıştı. Ev işlerinden anlamam ve bana çok yardımı oldu. Onu bir çok ortama soktum, arkadaşımla tanıştırdım. Yanlışlarını göstermeye çalıştım. Fakat hiç bir düzelme göstermeyen bu adamın beni tanımadığına kesin kanaat getirdiğim bir zamanda yanından ayrılmaya karar verdim. Bunu kendisine 1.5 ay önceden söyledim ve ilk olarak onunda tanıdığı yeni ev arkadaşım ile beraber yani üçümüz çıkalım istedim fakat o istemedi. Neyse. Ben dönem arasında yeni evime çıktım. İşte olaylar o zaman başladı. Benim para konuşmayı hiç sevmediğimi tüm dostlarım iyi bilir. Cebime giren çıkan paranın hesabını bilmem ben. Para muhabbeti yapmaktan da nefret ederim. Fakat beni en iyi tanıması gereken kişilerden biri olan bu fizikçi arkadaş bunu bilmiyormuş.

Bir gün telefonuma bir mesaj geldi. Mesaj da benden bu arkadaş evin kirasını istiyordu. Pardon! Ben kiramı ödeyip çıkmıştım evden ve benden para istiyordu. Güzelce açıkladım ve bu kez de fatura parası istedi. Evet son ayın faturalarını ödememiştik ve onları verecektim zaten. Fakat benden 150 tl isteyen arkadaşımın açıklaması beni şaşırttı. Ona göre biz geçen ayı ödememişiz. Yani 2 aylık faturaymış bunlar. İyi de ben geçen ayın parasını eline verdiğimi dün gibi hatırlıyorum? aa orada başladı tartışma işte. Benim TOG ile tanıştırıp içerisine girmesine vesile olduğum, arkadaşlarım ile tanıştırıp kendisine yer edinmesini sağladığım, hasta olduğunda ilk ben koştuğum, başı sıkıştığında (maddi - manevi) yanında olduğum, eski sevgilisi yüzünden tartıştığı adamlardan olaylarla alakam yok iken hakaret işittiğim ve kavga ettiğim bu adam benden para koparmaya çalışıyordu. Adam gibi ihtiyacı olduğunu söylese ben ona bir şekilde mutlaka yardımda bulunurdum ama olay farklıydı. Tog da benim aracılığım ile girebildiği ortamlarda benim arkadaşlarıma benim hakkımda atıp tuttuğunu duydum. Bunu da söylediği insanlardan duydum. Benim faturaları ödemeyip kaçtığımı, onu yalnız bıraktığımı söyleyip beni karalamaya çalışan bu adama en güzel cevabı ona inanmayan arkadaşlarım verdi zaten. Fakat son konuşmamızda ağzının payını güzel bir şekilde verdim bu arkadaşın ve son ayın faturalarını ödeyerek aramızdaki muhabbeti kapattım.

Dostum sandığım, beni tanıdığını sandığım, onun için elimden geleni yaptığım bir insandan böyle davranışlarda bulunmasını beklemezdim. Gerçekten benim için çok kötü bir durum. Ona son bir şey söylemek istiyorum, onun en çok sevdiği sanatçını Sezen AKSU’nun ağzından: “Soğuk yenir kin, ihanet intikamsız kalmaz.”.

İlk şakanın gelişme sürecinde birisinden hoşlanıyordum. Görünüşüyle gerçek kimliğini gizleyen kişiler vardır ya, işte öyle birisiymiş. Ağzından sevgi lafını eksik etmeyen ama sevmenin ne olduğunu bilmeyen kişilerden. Bana göre sevmek Sunay AKIN ın dizelerinde saklı:

Saçak altına sığınmış göçmen kuşun kar tanecikleri arasında düşen beyaz tüyünü de görebilmek İşte sevmek.

İşte sevmek, tüm dikkatimi onun üzerine vermiş, tüm çabamı kendisine olan özgüveni geri kazanması için uğraşmaya adamıştım. Eğitimlere ve çeşitli organizasyonlara katılması için sorumluluklar alması için çabalar gösterdim. Bu çabalarım sonuç verdi. Ona duygularımı söylediğim de beklemediğim bir cevap aldım. O beni sadece dostu olarak görüyormuş. Dost. Bu olabilecek bir şey. Yaptığım onca şeyi bir dosttan ayrı bir ilgiyle yaptığımı ona da hissettirdiğimi düşünüyorum. Fakat istemiyorum demenin farklı bir yöntemi işte olabilir. Saygı duyarım. Fakat beni kıran nokta beraber katıldığımız bir ortamda benim yanımda hiç tanımadığı veya az biraz tanıdığı adamlar ile gecenin bir körü dışarı çıkıp, zaman geçirmesi oldu. Yanı başında oturan ve dostum dediği adamı çağırmaması ki yanlarına gittiği adamların kimseye söylemeyin demesi yüzünden bunu yaptı, kabul edilemez bir durum.

Bunu yapan kişinin kişiliğinden şüphe etmek gerekir. Hiç tanımadığın bir yerde, ne oldukları belli olmayan bu adamlar ile (kişilere sözüm yok yanlış anlaşılmasın) gecenin bir saati dışarı çıkıp zaman geçirmek, ki bunu dostum dediği kişiden habersiz yapmak kimlere uygun bir davranıştır adını siz koyun. O olaydan sonra haksızlığını, yanlışını kabul etmesi güzel bir durumdu ama bunu hiç yapmaması gerekirdi. Ona da güzel bir konuşma yaptım. İzmir de gece arada bir dışarı çıkar arkadaşlarım ile eğlenirim. Bu çıkmalarım da onunla karşılaşmam ve bulunduğu ortamı görme şansı yakalamam iyi ki böyle birisinden kurtulmuşum dedirtti bana.

İkinci şakadan sonra hayatım tam anlamıyla cehennem oldu. Ruh gibi dolaştığım, uyuyamadığım zamanları hatırlıyorum. Tam düzelmeye başladığım bir dönemde de dostumuz dediğimiz bir kişinin sorunları patlak verdi. Bir insan düşünün ki her şeyi bildiğini sanır ama hiç bir şeyden anlamaz, üstün gözükmeye çalışır fakat yaptığı kendisini bitirmektir. İşte böyle bir adamın bir çok yanlışını dostumuz dediğimiz için görmezden geldik. Taki son olaya kadar. Bir insan kardeşim dediği adamın eski sevgilisiyle birlikte olmak için nasıl uğraşır? Nasıl bir işkemben var senin. Sonra düşündük ki bize söylediği yalanlar, onu soktuğumuz ortamlarda arkadaşlarımıza sırnaşmaya çalışmaları, saygısızca hareketleri. Biz bu adamı çok görmezden gelmişiz. Kendisini bitiren insanlardan nefret ederim. Kişiliği oturmamış insanlardan da.

Fakat bu son şaka diğer ikisi kadar derin yara vermedi. Ona son bir konuşma yapma gereği dahi duymadım. Gerek yok çünkü. Kaybeden, ahlaksız durumuna düşen de o. Gerisini o düşünsün artık.

Bir kızıl derili atasözü şöyle der: “İhanet arkadaşlık zincirini karartır, fakat vefa onu her zamankinden parlak yapar.” Herkesin hayatında vefasız insanlar vardır. Önemli olan onlara dahi vefalı davrandım diyebilmektir. Ben rahat bir şekilde bunu söyleyebiliyorum. Her arkadaşıma, dostuma elinden geldiğince yardımcı olmaya, onun yanında olduğumu hissettirmeye çalıştım. Gerisi onların karakterlerine kalmış. Büyük konuşmayı sevmem ama benim dostluğumu kaybetmek servet kaybetmekten daha zordur. Fakat kaybedilirse de dünyaları kaybetmekten beter olur.

Yaptığım iyilikleri söylemek asla huyum değildir. Burada söylemem gerekiyordu çünkü bu şekilde, bu yazıyı yazarak müthiş bir rahatlık duyacağımı düşünüyordum ve duyuyorum :)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Registry Booster 2011 Crack - Serial (Yerel Makine Hack)

Mon, 27 Jun 2011 00:00:00 GMT

Registry Booster programı; windows işletim sisteminde bulunan ve bilgisayar ile ilgili önemli bilgileri içerisinde bulunduran kayıt defterleri içerisinde ki hataları bulup düzeltmek için kullanılmaktadır. Kayıt Defterinde ki hatalar bilgisayarımızın yavaşlamasına, programların hata vermesine sebep olmaktadır. Bu yüzden hata içeren bölümlerin düzeltilmesi gerçekten önemlidir.

Programın 2011 versiyonlarında internet üzerinden yayılan seriallar, crackler işe yaramamaktadır. Bu da programın demo sürü ile verimsiz bir şekilde çalışmasına sebep olmaktadır. Aşağıdaki video da programın kurulumunu ve kayıt defteri ile kendi bilgisayarımızı hackleyerek programı full versiyon kullanmamızı sağlayacak işlemleri anlattım. Umarım yararını görürsünüz :)) Programı indirmek için TIKLAYINIZ.

Program ile ilgili sorularınız için iletişim bölümünden bana mail atabilirsiniz. Görüşmek Üzere :)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Mersin Tog Atak Geldi Geçti

Thu, 02 Jun 2011 00:00:00 GMT

Mayıs ayının 20, 21 ve 22 sinde düzenlenen bu sene ki Toplum Gönllüleri Vakfı atak organizasyonlarından Mersin Atak’a ben ve Ege Üniversitesi Toplum Gönüllüleri Örgütlenmesinden Dilara OMAY arkadaşım ile birlikte Tog Ege’yi temsilen katıldık. Akdeniz’in güzel mi güzel şehrinde yolculuk dışında güzel zaman geçirdik. Mersin Atak’ta yaşadıklarımıza geçmeden önce atak nedir’in bi cevabını verelim. Atak; en az 1 en çok 3 gün süren, Türkiye genelinden Toplum Gönüllülerinin katılımıyla ulusal düzeyde geniş çaplı bir şekilde gerçekleştirilen, bir sosyal duyarlılık projesidir. Amaç yerel kamuoyunun dikkatini sosyal sorumluluk projelerine çekmektir. Daha ayrıntılı bilgi için buyurun.

Biz İzmir’den 18 Mayıs gecesi yola çıktık. Yolculuk öncesi yaptığım küçük çaplı araştırmamda yolumuzun 9 - 10 saat süreceği kanaatine vardım. Bir çok kanalda söylenen oydu çünkü :)) Fakat yola koyulup 10 saat geçtikten sonra işin doğrusunun öyle olmadığı, internet çöplüğünün pisliğine bulanmış bilgiler ile kandırıldığımızı anladım. 15 saat süren yolculuktan sonra ancak Mersin’e varabildik. Neyse ki yol arkadaşım ile iyi ikili olduk ve yolculukta hiç sıkılmadım. Dilara da sıkılmadı diye tahmin ediyorum :)) Bizi otogar da Mersin Organizasyon Ekibi’nden gönüldaşlarımız karşıladı. Diğer gelen gönüllü arkadaşlarımızın yanına bizleri götürdüler. Bekleme noktamız aynı zamanda Mersin Tog’un toplantılarını yaptığı bir kültür sanat eviydi. Gerçekten hoşuma giden bir mekandı. Bekleme sırasında Mersin de küçük bir iki tur attık ve küçük olmasına rağmen zevkli geçen bu gezinti ile Mersin’i tanımaya çalıştık. Ne kadar tanıdık? Çok az ama olsun :)) Gece kararmaya başladığı sıralarda servis ile yola koyulduk. Eğitimlerin yapılacağı ve konaklayacağımız -adını unuttuğum- motel tadında, denize sıfır, yurt olmadığına çok sevindiğim yerimize yarı uykulu, şarkı söyleyip alkış yapıp vardık ve odalarımıza yerleştir. İlk geceden eğitimlere başlamamız biraz verimsiz olsa da güzel bir ilk gün geçirmiş olduk :))

Atak teması “Kuşak Çatışma”sıydı. 80 ler, 90 lar, 2000 ler temelli eğitim içerikleri amacına uygun atölyelerden ve oturumlardan oluşuyordu. Fakat gelişi güzel sıralanmış olduğu izlenimi veren eğitimlerin kalıcılığı konusunda şüpheliyim. Atak çıktıları henüz paylaşılmadığı için de şüphem devam ediyor ;) Her şeye rağmen böyle bir konu işlendiği için mutlu oldum diyebilirim. Çünkü Tog çatısı altında “Gençlerin Öncülüğünde” yürütmeye çalıştığımız sosyal sorumluluk projelerinde ilk hedef kitlelerimizi gençler oluşturuyor. Fakat bizler çocuklara yönelik, yaşlılara yönelik projeler yapmaya kendimizi o kadar çok kaptırdık ki toplum da sorun teşkil eden, sivil örgütlenmelerin öncülüğünde çözüm geliştirilebilecek konulara değinmez olduk ve en önemlisi de gençlerimizi unutur olduk. Gençlerin sorunlarını görmemeye başladık. Bu yüzden, gençlerin yaşamlarında ki en önemli sorunlardan bir tanesine hatta sadece gençler değil toplumun bir çok kesimini ilgilendiren “Kuşak Çatışması” konusu üzerine eğilmek öze dönmek anlamında bir hareketti diye düşünüyorum. Bu başlangıç ile farklı bir çok sivil toplum örgütünün de farkındalıklarının artacağını ümit ediyorum.

Atak’a dönecek olursak 2. günümüzde kanlıdivane de geçekleştirdiğimiz, sıcağın altında tarihi kalıntılar arasında dolaşarak yaptığımız atölye’nin hiç yararlı olduğunu düşünmüyorum. Taş zihniyetiyle kalıntılara bakmıyorum evet ama oraların kullanılış şekilleri ile “Kuşak Çatışması” nı birleştiremedim ve hala da birleştiremiyorum. Zaman kaybı olan bir atölyeydi. Bunun aksine kız kalesi gezisi öncesi yaptığımız emekli öğretmenlerin, sağlık çalışanlarının ve lise öğrencisi(mezunu) arkadaşların katılımıyla geçekleşen oturum zevkli, gerçekten amacına yönelik, etkileşimi yüksek bir sürece sahipti.

Atak sırasında Kuşaklar partisi eğlencenin tavan yaptığı zamanlardan bir tanesiydi. Kostüm değiştirip 80 lerde ki 90 larde ki gibi giyinen arkadaşlar çok güzel gözüküyorlardı. (Ben değiştirmedim, 2000 ler de kaldım :P) Ayrıca Kuşaklar partisini yaptığımız ve aynı zaman da eğitimlerimizi yaptığımız salonun yakınında, partimizin olduğu gece gerçekleşen düğüne bu kılıklarla katılarak güzel anılar elde ettik :)) Eğitimler arasında sahile inip sohbet etmek, sahil yolunda ki duvarda oturup sohbet etmek, deniz manzaralı açık havada yemeklerimizi yemek atağın tatlı anlarına bazı örnekler olabilir.

En son Kız kalesi gezimizin ardından atağımıza son noktayı koymuş olduk ve otogara doğru yola koyulduk. 15 saatlik yolculuğa doğru. Dönüş yolu çoğu aşaması uyku ile geçmiş olmasına rağmen Dilara ile zevkli bir şekilde geçti :)) Bitirirken…

Mersin Atak Organizasyon Ekibine emeklerinden ötürü, bize gösterdikleri yakınlıktan ötürü, sıcaklıklarından ötürü, zevkli bir atak geçirmemizi sağladıkları için çok teşekkür ederim. Katılımcı arkadaşlarıma da katılımlarından ötürü kendi adıma teşekkür ederim. Umarım ulusal etkinliklerde hepsiyle tekrardan görüşme şansına erişiriz.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Kule Canbazı --- Sunay AKIN

Fri, 20 May 2011 00:00:00 GMT

Çocukluğunuzda oyalanmanız için elinize tutuşturulan boyalı kalemlerle üzerinde gidip geldiğiniz sayfaları bir kerecik Sunay Akın’a vermeyi hiç düşündünüz mü? Onun büyülü sözcükleriyle çizdiği resimlerin içinde hiç kimsenin göremediği güzel bir ayrıntıydınız belki de…

Gün oldu, o resimlerde sizi Hezarfen’in kanatlarına bindirdi; herkes o güzelim insana şaşkınlıkla bakarken, siz bulutlara yüzünüzü sürdünüz. Gün oldu, batan bir denizaltının haberiyle sarsılırken tüm dünya, içinizden bir parça koptu; siz hafifledikçe belki o gemi yeniden suyüzüne çıkar diye düşündünüz… Ama o resimlerde kızgın bir çöle bile düşseniz, Sunay Akın’ın usta elleriyle verdiği gölgelere sığınabileceğinizi hep bildiniz.

Serüven sürüyor…

Haliç’te yan yana duran yedi gemi düşünün ve uzunca bir halatın o gemilerin yedi direğine gerildiğini… Haliç’i o halatın üstünde geçmeyi başaran Canbaz Şahin olmak istemez miydiniz? Ne dediniz, yükseklik korkunuz mu var? O halde, bir koyunu omuzlarına alıp ip üstünde ilerleyen ve hatta onu kurban edip mangalda pişirerek afiyetle yiyen Ahmet Ağa’nın muhteşem gösterisini izlemeye hayır diyemeyeceksiniz…

Düşlerinizde bir çizgi çekin dün ve bugün arasına, hatta yarına uzayıp giden, yılları yıllara bağlayan… Gördünüz mü, o çizgi üstünde Sunay Akın yürüyor!.. Oyuncaklarla dolu bir el arabasını katmış önüne, şiirler okuyarak dengesini buluyor yaşamın. Düşecek diye korkmayın sakın. Bir yanı şiir, bir yanı düzyazı; hangisine düşse söz canbazı oluyor bu kez. Ve ustaca beceriyor her ikisini de!..

Tanıtım Yazısı’ndan Alıntı

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

PHP de Türkçe Karakter Sorunu

Sun, 15 May 2011 00:00:00 GMT

Öncelikle merhaba =) İnternet dünyasında aradığınızda üzerine en çok konuşulmuş, konuşulan konulardan birisidir aslında “Türkçe Karakter Sorunu”. Web yazılımı / tasarımı ile uğraşanlar sık sık ya da genellikle bu sorunla karşılaşmaktadır. Kendi açımdan konuşmam gerekirse ne kadar tecrübem olursa olsun, ne kadar çok bu sorun üzerine çözümüm olursa olsun yine de projelerin belirli sürelerini Türkçe Karakterlerle uğraşmaya ayırıyorum.

Üzerinde çalıştığım en son projem de başıma gelenlerin hala cevabını bulamadım. Bir çözüm geliştirdim ama aklımda müthiş bir soru işareti olarak kaldı yaşadıklarım. Kısaca açıklamam gerekirse, projemin veri tabanı ile bağlantılı (ki hepsi bağlantılıydı, index hariç) sayfalarında charsetimi utf8 olarak tanımladım.

HTML; charset=utf-8" />

Veri tabanımın ve toblolarımın karakter karşılaştırma tiplerini de utf8turkishci olarak ayarladım. Yönetici panelim dahil hiçbir sayfa da türkçe karakter sorunum olmadı fakat index.php sayfam da ilginç bir şeyler yaşanmaya başlandı. İçeriği, menuleri vb. include ettiğim sayfamda türkçe karakterler ama hepsi değil sadece ş ve ğ sorun çıkartıyordu.

İlk olarak sayfa charsetini ISO ya çevirdim ve veri tabanımın karşılaştırma tiplerini latin5turkishci yaptım.

HTML; charset=ISO-8859-9" />

Fakat sorun yine aynı kaldı. index.php sorunluydu. Ardından veri tabanı bağlantımdan sonra karakter tipim ile ilgili sorgular döndürerek karakter tipimi sağlam bir şekilde tanımlamak istedim.

mysql_select_db("veritabanı_adı");
mysql_query("SET NAMES ´latin5´");
mysql_query("SET CHARACTER SET latin5");

Fakat sonuç tekrardan hüsran ile bitti. index.php sorunlu çalışmaya devam etti. Uygulumalaya çalıştığım ilk çözümlerin ardından 3 güne yakın bu sorun ile uğraştım ve merakımın giderek artmasına rağmen çözüm aramayı bıraktım ve gözünü sevdiğim html kodları ile (türkçe karakterlerin html kodları) sorunu hallettim.

Öncelikle PHP de bir fonksiyon yazdım.

function tr($yazi) {
    $yazi = trim($yazi);
    $ara = array('Ç','ç','Ğ','ğ','ı','İ','Ö','ö','Ş','ş','Ü','ü');
    $degistir = array('Ç','ç','Ğ','ğ','ı','İ','Ö','ö','Ş','ş','Ü','ü');
    $yeni_yazi = str_replace($ara,$degistir,$yazi);
    return $yeni_yazi;
}

Bu fonksiyonun ne işe yaradığı zaten ortada ama kısaca türkçe karakterleri verilen string bloğu içerisinden bulup html kodlarıyla değiştiriyor. Bu fonksiyonu yazdıktan sonra veri tabanına kayıt aşamasında verilerimi bu fonksiyonumun süzgecinden geçirerek kayıt ettim ve hiç bir sorun olmadan index.php sayfamda türkçe karakterleri kullanabildim. Hala index.php üzeinde oluşan ilk sorunun nedenini merak etmekteyim ve umarım çalışmalarım sonucunda sorunu çözerim =)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Karpuz ve İlişkiler

Tue, 26 Apr 2011 00:00:00 GMT

Bir zamanlar karpuzdan fenerler yapılırmış. Şöyle bir düşündüğümüzde estetik açıdan farklılık oluşturmak açısından güzel fikir gibi duruyor. Karanlıkta yolumuzu aydınlatan ışık kaynaklarına belki de bir tatlılık katmak amacı gütmüş olabilir ilk karpuzdan feneri yapan kişi. Orhan Veli “Sakal” isimli şiirinde;

Hanginiz bilir, benim kadar, Karpuzdan fener yapmasını.

diyerek bu işte ne kadar iyi olduğunu hiç de mütevazi olmayan bir şekilde bizlere söyler. Şüphesiz ki Orhan Veli gibi bu işte usta olan birisi her karpuzu kullanmıyordu fenerleri yaparken. En iyilerini seçmeye çalışıyordu. Karpuzların nasıl seçildiğini bilir misiniz?Şöyle bir ele alınır karpuz, ellenir kurcalanır. Öyle karar verilir karpuz iyi mi kötü mü…

Bir başka şairimiz Cevat Çapan’ın bir şiirinde de geçer karpuz;

Babam iki tek atınca, “Hadi seni karpuzlara götüreyim” derdi. (Karpuzlar Gebze’de oturan kızlardı) Annem kızarır, kızar, “Bey, çocuk daha küçük” diye çıkışır, Mutfağa gider ağlardı. Babam karpuzdan anlardı.

Şiirinde karpuz’u kadınların yerine kullanan Cevat usta ile Orhan Veli yi birleştirdiğimizde ilişkiler ile ilgili bir noktaya varıyoruz aslında, erkekler açısından. Tabi yorumu tersten yaparsak kadınların açısından da bir noktaya varabiliriz. Kendimiz için en iyi kadını / erkeği bulabilmek için (Yolumuzu aydınlatmamıza yardımcı olacak fenerlerimizi bulabilmek için) öncelikle ona duygusal olarak dokunmamız gerekiyor. Daha sonrasında da psikolojik olarak kurcalamamız gerekiyor. Bunların hepsi en iyi için yapılıyor. Tabi bu aşamalarda biraz ileriye gidersek işler sarpa sarabiliyor. Aşırı ilgi, baskı, bağlılık, kopamama … Az olması da gerçeği görmeyi zorlaştırıyor.

Tabi bu seçim aşaması her zaman göründüğü gibi işlemeyebiliyor. Her ne kadar her şeyi kararında yapsanızda bazen karpuzun için geçiş veya tam olgunlaşmamış olabiliyor. Bu aşama ya aşırıya kaçmayı ya da karpuzu atmayı gerektiriyor. Artık seçim kişiye kalmıştır. Peki her şeyi nasıl doğru yapıcaz? Bunu bilemem. Karşınızdaki ve sizin kişiliğinize göre değişkenlik gösterebilecek bu süreçleri iyi tahlil etmek ve gerçekleşen olayları iyi yorumlamak gerekiyor. Eğer dikkatli olunursa doğruya ulaşılabilir. Her yaz sonunda bir şekilde bitip giden karpuzlarımız için …

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

PHP ile Access Veri Tabanı Bağlantısı

Sun, 17 Apr 2011 00:00:00 GMT

PHP nin her veri tabanı ile çalışabildiği gerçeği, bu dilin en önemli özelliklerinden bir tanesi. Video dersimizde de bunun bir örneğini görüyoruz. Tam olarak bir veri tabanı bile sayılmayan access e PHP ile bağlanıp, üzerinde işlemler yapıyoruz. Kullandığımız fonksiyonlar odbcconnect ve odbcexec.

Algoritmik içeriği merak ediyorsanız, video merakınızı giderecektir. İyi seyirler =) ve iyi çalışmalar =)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

PHP ile Veri Tabansız Telefon Rehberi

Thu, 14 Apr 2011 00:00:00 GMT

Bölümümüzün en iyi hocası olduğunu düşündüğüm Tarık KIŞLA hocamızından bu dönem hem ağ hem de veritabanı dersini alıyoruz. Geçen sene misafir!!! bir öğretim görevlisinden aldığımız veritabanı dersi pek yararlı geçmemiş, çoğu insan hak etmediği puanları almış ve en önemlisi de kimse bir şey öğrenememişti. Bu dönem bu dersi Tarık Hocadan almamız bizim için müthiş bir şans.

Bu şansı tüm BÖTE 3. sınıf öğrencilerinin en iyi şekilde kullanabilmesi en büyük temennim.

Tarık Hoca’nın veri tabanı dersine henüz girmemiş olsam da :D verdiği ödevden arkadaşlarım sayesinde haberdar oldum. Hocamız bize veritabanının önemini anlamamız amacıyla veritabanı yerine bir .txt kullanarak telefon rehberi yazmamızı istemiş. Bir not defteri ve istediğimiz bir dili kullanacakmışız. :) Hocamızın mantığı çok hoşuma gitti. Hemen oturup yazmak istedim ama kısmet bu güneymiş. Anca zamanım oldu :D Ben bu ödevi yaparken PHP, Ajax(Javascript), CSS, HTML teknolojilerini kullandım. Ödevin teslim günü benim grubum için salı günü. Erkenden ödevi paylaşmamda ki amaç, arkadaşlarıma yardımcı olabileceğini ya da en azından fikir verebileceğini düşünmemdir. Yanlız bir hatırlatma. Eğer buradaki kodlardan bir şeyler öğrenmek istiyorsanız, LÜTFEN algoritmayı anlamaya çalışın. Kopyala yapıştırdan kaçının.

Proje kodlarını görmek isteyenler, iletişim sayfasındaki form aracılığı ile bana ulaşabilirler.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Anahtar Eğitmen Eğitimi || İstanbul Eğlencesi

Wed, 13 Apr 2011 00:00:00 GMT

Şiledeki eğitimimizin ardından yaşadığımız şehirlere geri dönebilme için bizleri İstanbul’a getirdiler :) Taksimde servisten indik ve acelesi olmayan arkadaşlar ile birlikte biletlerimizi aldık, cebimize koyduk ;) Sonrasında da hadi birazcık İstanbul dedik. Pek bir açılamasak da istiklalde geçirdiğimiz anlar harikaydı :D

Önce karnızı doyurduk ki enerji alalım dedik. Sonrasında da istiklalin ara sokaklarından bir tanesine girip oradaki barlardan bir tanesine oturduk. Kimimiz alkol aldı kimimiz nargile içti. Hafif sohbetler eşliğinde biraz zaman geçirdik ama sıkıldık. Ne yapalım dedik? Akla bir şey gelmiyor. Derken bir iki arkadaş geldi. Kan ter içerisinde :D İstiklalde koşturmuş akıllı arkadaşlarım :) Dedik ki bizde yapar mıyız? yaparız.

Attık kendimizi istiklale :D başladık koşmaya, kovalamacaya. Evet bu aşamada etraftaki insanlara biraz rahatsızlık vermiş olsakta heyecanımızı görerek bir şey demediler sağ olsunlar :D neyse el ele tutuşup tren şeklinde istiklalin ortasında zik zak çizerek koştuktan sonra bizim eğitimlerde uyguladığımız ve canlandırıcı adını verdiğimiz insanların kendilerine gelmelerine yardımcı olan uygulamalardan bir kaçını uygulamaya karar verdik. İstiklalin ortasında tramvay yolunun üzerinde bir çember olduk ilk olarak ve başladık at gibi ayak sesleri çıkarmaya, zıplamaya :D Bu aşamada turistler de katıldı aramıza. Uygulamayı ingilizce yürütmeye başladık :D Uygulamanın sonlarına doğru çemberimizin ucuna devriye gezen bir polis otosu geldi ve durdu. Onlarda bizleri izlemeye koyuldu. :D

Ekip otosunun geçmesi için ara verdiğimiz uygulamamıza devam etmedik. İstiklalde biraz daha yol aldıktan sonra bir iki uygulama daha yaptık. En ilginci yine çember halinde iken sırayla hepimizin bağırmaya başladığı uygulamaydı. Bu uygulama aşamasında bizi eli sandılar kesin :D ama sanan sansın öenmli değil. Biz eğlendik =)

Oradan yorulmuş halde yine istiklalin ara sokaklarından bir tanesinde bulunan, Galatasaray Lisesinin yan sokağında bulunan (yanlış hatırlamıyorsam) “45lik” isimli mekana girdik. Eski 45liklerin eşliğinde bazı zamanlar eşlik ederek bazı zamanlar sadece dinleyerek güzel vakit geçirdik. =)

Derken otobüs saatlerimiz geldi :( ayrılık vakti geliyordu artık. 45lik isimli mekandan kalktık ve servislerimize doğru yol aldık. Ayrılık aşamalarını pek sevmem. Yine sevmedim ama ayrıldık :( Güzel dostluklarımız ile beraber yollara düştük.

Müthiş bir tecrübe olan bu eğitime bir çok okurumun da dahil olmasını çok isterim. Umarım bu hazza, bu duygulara sizlerde sahip olursunuz =)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Anahtar Eğitmen Eğitimi || 5. ve 6. GÜN

Tue, 12 Apr 2011 00:00:00 GMT

Eğitimin 5. ve 6. günleri yani 26 Şubat ile 27 Şubat günleri bizlerin sahaya çıktığımızda yapacağımız eğitimlerin provalarını yapacağımız günlerdi. Mavi, Kırmızı ve Yeşil Anahtar eğitimlerinin sunumları bu günlerde gerçekleştirildi. Bu aşamalarda iki eşit gruba ayrıldı. Her iki grup kendi içerisinde bu eğitimleri ayrı olarak yerine getirdi. Bu iki grup da kendi içerisinde eşit üç gruba ayrıldı çünkü üç adet eğitim gerçekleştirilecekti.

Ben Mavi Anahtar Eğitimini gerçekleştirecek olan gruba düştüm. Bu ilk eğitimi bizim yapacağımız anlamına geliyordu :D Bu eğitimlerin gerçekleşeceği günlerin bir önceki akşamı iyi hazırlıkların yaşandığı, ekip çalışmasının ve verimin arttığı zamanlardı. Her grup iyi çalışmalar yaparak sunumlarını gerçekleştirdiler. Her eğitimden sonra o eğitim gerçekleştiren arkadaşlarımız üzerine ve katılımcılar üzerine kısaca konuştuk. Geri bildirimlerin çok önemli böylesi ortamlarda yapılabilecek en önemli şey iyi bir iletişim kurabilmektir. Kurabildiğimizi düşünüyorum. Sadece bir eğitim sonrasında bir eğitmen arkadaş ile yaşadığımız kısa süreli tartışma o arkadaşın bizler ile düzgün bir iletişimde olmadığı düşüncesini doğurdu bende. Rahatsız olduğu bir durumu söyleyerek “Bu konu üzerine düşünün ve sonra konuşalım.” edikten sonra söz alarak o konu üzerindeki düşüncelerimi dile getirmeye çalıştım.Bana “Düşünün de konuşun dedim.” gibisinden kaba bir cevap veren bu arkadaşın tüm çabalarına rağmen düşüncelerimi söyledim. Bu yaptığından ötürü de kendisini kınadım. Eğer düşünmemiş olsam zaten konuşmam. Sen kimsin ki bana böyle bir yaklaşımda bulunuyorsun. Neyse.

günümüz eğitimlerin ardından GDG leri yaptıktan sonra sona erdi. Biz rahatladık ama Yeşil anahtar Eğitimini yapacak arkadaşlar rahatlayamadılar. Çünkü onların sunumları 6. gündü ve çalışmaları gerekiyordu.
gün yeşil anahtardan sonra “Birlikte Nasıl Çalışıyoruz?” oturumu ile devam etti. Burada eğitimlere çıkmaya başladığımız zaman neler yapmamız gerekiyor? Nasıl sorumlulukları yerine getirmeliyiz? vb. soruları konuştuk ve şuan da orada öğrendiklerimizi uyguluyoruz. Hatta bu yazıyı yazmadan önce formları doldurdum ve vakfa yolladım :D
günümüzün sonunda eğlence vardı ama eğitmenler bizlere harika bir uygulama yaptılar. Bizleri düşünceler iten o uygulama üzerine konuşmayacağım. Bizleri daha bir bütünleştiren o uygulama gerçekten duygusal anlara sahne oldu. Ağlamadım ama ağlama aşamasına geldim diyebilirim =)

Bu günden sonra eğitimimiz sona erdi. Dönüşlerimizin ardından eğitime çıkmayı beklemeye başladı :D

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Anahtar Eğitmen Eğitimi || 3. ve 4. GÜN

Sun, 10 Apr 2011 00:00:00 GMT

Eğitimin üçüncü gününde yani 24 Şubat Perşembe günü “Öğrenme ve Eğitim” isimli oturum ile başladı. Bu oturumda öğrenme nedir? eğitim nedir üzerinden giderek yapacağımız işin temelleri üzerinde konuştuk. Bizim fakülte derslerinde aldığımız eğitim bilimleri derslerinin formal olmayan eğitim ortamlarında nasıl daha verimli olabileceğini canlı olarak yaşadım =)

Bu oturumun sonunda bir yemek arası verildi ve ardından eğitmenlerimizin “Barcelona” adını verdikleri, daha sonradan da imece dediğimiz, ekip çalışması ve güzen temelli uygulamayı gerçekleştirdik. Kafalarımız yan yana gelecek şekilde yere uzandık ve en baştan başlayarak arkadaşlarımızı ellerimizin üzerinde taşıdık. Eğlenceli ama dikkat gerektiren bir uygulamaydı. Sonunda uygulama üzerinde konuşarak günü bitirdik. Sonrasında serbest zamanımızı kullandık :D Tabi GDG yapmayı ihmal etmedik.

Eğitimin dördüncü gününde yani 25 Şubat Cuma günü “Eğitmenlik becerileri I” oturumu ile başladı ve “Eğitmenlik Becerileri II” oturumu ile devam etti. Adından da anlaşılacağı üzere bir eğitmen nasıl olmalı? neleri yapmalı? neleri yapmamalı gibi konular üzerinde durduk. Daha sonra bir bir yemek arasından sonra “Program Tasarlama” oturumumuzu gerçekleştirdik. Eğitim programları Eğitim Bilimlerinin en önemli kısımlarındandır.Biz de tog da proje tasarlamaya eğindik ama aşamalar benzerlik gösterdiği için burada eğitim planı da çıkardık diyebiliriz :) Bu oturumumuzdan sonra yemek arası verdik ve GDG mizi gerçekleştirdik.

Bu iki günümüz biraz sıkılarak ama çoğunlukla öğrenerek ve eğlenerek geçti. Tadılası şeylerdi =)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Onlar Hep Oradaydı --- Sunay AKIN

Sat, 09 Apr 2011 00:00:00 GMT

Sunay AKIN’ın kendisi hakkında çıkmış sorulara ve eleştirilere cevap niteliği de taşıyan kitap “Kız Kulesindeki Kızılderili” kitabına göre az olsa da kızılderililer hakkında bizlere güzel bilgiler sunuyor. Sunay AKIN ustanın anlatımıyla, olayların en küçük ayrıntılardan nasıl birbirlerine bağlandığına şahit olacaksınız.

Kitabın Arka Kapak Yazısı Her hafta yüzlerce çadırın kurulduğu Kuşdili çayırında intihar eden Hamdi Bey’i nasıl kıskanmasın, beton ve çelikten gökdelenlerin yükseldiği Manhattan’da yaşama gözlerini yuman Kızılderili? Ki bir geyik olarak gelir dünyaya hiç doğmamış çocuğu…

Ve Resneli Niyazi’nin hürriyet mücadelesine katılır Balkanlar’ın dağlarında. Haliç kıyısındaki şadırvanın çatısında bir yerde saklıdır, sırtına sıkılan kurşun… O günden beri de Sunay Akın yalnızca okurlarına güvenir, sırtını dönebilecek kadar… Çok iyi bilir çünkü, özgürlük direnişi boyunca onlar hep arkasındaydılar… Onlar hep oradaydılar.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Anahtar Eğitmen Eğitimi || 2. GÜN

Wed, 06 Apr 2011 00:00:00 GMT

Anahtar Eğitmen Eğitimini tamamladık ama ben yaşadıklarımızı - en azından bir kısmını anlatmayı tamamlayamadım. Gerek zamanımın olmamasından gerekse şu son blog engelinden sonra isteksizleştim. Fakat devam ediyorum ve eğitimin tam olarak başladığı gün ile devam ediyorum.
gün ilk olarak “Sivil Toplum” oturumu ile başladı. Bu oturumda Sivil Toplum’un tarihsel gelişimine kısaca değinildikten sonra bizlerin Sivil toplum dendiğinde ne anladığımızdan yola çıkarak Sivil Toplum’un ne olduğu üzerine koştuk. Sivil Toplum “Belirli amaçlar uğrunda insanların birlikte hareket etmesi.” olarak söylendiğinde tam anlamıyla ifade edilmiş olur mu? Bu tarz terimleri sözcük anlamlarıyla mı anlamalıyız yoksa kendi anlam yüklemelerimiz ile mi anlamalıyız? Bu sorulara benim verdiğim cevaplar şunlar.

ST dediğimizde akla gelecek en temel kavramlar insanlar, birey, amaçlar ve birlikteliktir. Biraz önce belirttiğim tanımda bu temel kavramların birlikteliğinden oluşturulmuş bir tanım ve benim anlam yüklemelerimle örtüşüyor. Bu yazıyı okuyan şanslı ve bilinçli blog okuyucularının da ST ve yazı da geçecek diğer terimleri kendi anlam yüklemeleriniz ile yorumlamanızı öneriyorum :) Kısa bir aradan sonra eğitim “Sivil Toplum Kuruluşları” oturumu ile devam etti. En etkili yöntemlerden birisi olduğunu düşündüğüm tartışma yöntemi ile (çok tartışmasak da) bu kez STK nedir? neden vardır? gibi sorulara cevap aramaya çalıştık. STK dendiğinde üzerinde durulacak en önemli unsurlar bence örgütlenme, katılım, toplumsal fayda ve şiddetsiz eylemler. Daha bir sürü kavram çıkabilir çünkü bu da yoruma açık bir durum. Bu yüzden eğitim esnasında da tam olarak bir tanımını yapmadık. Öğle yemeğimizden sonra Mandala uygulaması ile başlayarak “Gönüllülük” oturumunu gerçekleştirdik. Mandala, büyülü çemberler dendiğinde tam anlamına ulaşıyor kanımca.Daha ayrıntılı bilgi için BURAYA bakabilirsiniz.

Bu oturumda da tahmin edeceğiniz gibi gönüllü nedir? e ulaşmaya çalıştık. Mandala da gruplara ayrılarak politika, ekip çalışması, katılım gibi öğeleri tema yaparak mandala çemberleri oluşturduk ve sonrasında da mandalalarımızın hazırlanma aşamalarını, o aşamalarda neler düşündüğümüzü diğer gruplarda ki arkadaşlarımıza sunduk. Benim yer aldığım grup politika temalı mandala çemberini yaptı :) Bir aradan sonra “Örgütlenme” oturumu ile devam ettik. Bu oturumda örgütlenmek üzerine kısaca konuşulsa da asıl olan bir örgütlenmenin örgütlenme olması ne demektir? soruydu. Bu soruya kısaca hemde çok kısaca şu cevabı verebiliriz. Örgütlenme bir fikir ile yapılanan, vizyon ve misyonları belli yapılardır. Bir örgütlenmenin örgütlenme olabilmesi için şu aşamaları yerine getirebilmesi gereklidir.

Planlama Organize Etme Yürütme Kontrol Etme Akşam yemeğinden sonra programda GDG (Günlük Değerlendirme Grupları) olmasına rağmen biz BBŞO yaptık. Açılımını hatırlayamadığım bu oturumda bir kısmımızın gemi olduğu, bir kısmımızın deniz feneri olduğu, bir kısmımızın korsan olduğu güven ekip çalışması temelli bir uygulama yaptık. Gerçekten eğlenceli bir uygulamaydı ve bir eğitimde ilk kez denenmişti. Başarılı olduğunu ve bundan sonraki eğitimlerde de uygulanması gerektiğini düşünüyorum. BBŞO dan sonra toplan 6 kişiden oluşan (bir kişi eğitmen) GDG mizi yaptık. O gün gerçekleştirilen oturumları, kendi katılımımız, eğitmenleri, diğer katılımcıları daha doğrusu aklınıza ne geliyorsa hepsini konuştuğumuz bir oturum olan GDG ler benim en çok hoşuma giden eğitim parçalarından bir tanesiydi. GDG ler de ki konuşmaların gerçekten verimli olduğunu düşünüyorum. Çünkü küçük gruplar da daha çok nesne nesne uyumu gerçekleştirilebiliyor ;)

İkinci günümüz kısaca ama gerçekte uzun ve yoğunca böyleydi. Görüşürüz tekrardan :D

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Anahtar Eğitmen Eğitimi || 1. GÜN

Tue, 05 Apr 2011 00:00:00 GMT

İlk gün eğitim anlamında neler yaşadığımızı anlatmaya başlamadan önce yolculuk ve şileye hareketimiz öncesi İstanbul turumuzdan bahsetmek istiyorum. Pazar akşamı saat 23:59 ( evet 00:00 değil ) aracı ile diğer bir eğitmen adayı arkadaşım ve ben İstanbula hareket ettik. Yolculukları ve yolculuk süresince ekrandan yolu izlemeyi seven birisi olarak, yolculuğumuzdan sıkılmadığımı itiraf etmeliyim yalnız feribot da ki zamanımızı bundan çıkartmak istiyorum. Yavaş yavaş hareket eden feribot da soğuktan dolayı otobüste oturduğumuz için belki de o kadar çok sıkıldım ki anlatamam. Kabus gibiydi.

Sabah İstanbul trafiğinin de etkisiyle saat 9:00 gibi Esenler otogarına vardık. Oradan servise binip çapa ya oradan da metro ile Sirkeci’ye geçtik. Hemen Toplum Gönüllüleri Vakfının yerini aramaya koyulduk. Zor olmadı bulduk :D Vakfın bulunduğu bina dışarıdan eski (içeriden de eski sayılır) ama benim çok hoşuma gitti. Eskileri severim. Eşyalarımızı vakfa bıraktıktan sonra attık kendimizi dışarıya ) Gamze’nin İstanbul da yaşayan bir arkadaşı ile buluştuk. Ne yapalım ne edelim derken hasta Beşiktaşlı arkadaş bize Beşiktaş’a gitmeyi önerdi ve bizde kabul ettik.

Yolculuk sırasında ki görsel şölen diyebileceğim manzaralar harikaydı. Neyse Beşiktaş’a gittik ve kahvaltı için bir restorana oturduk. Beşiktaş semti manzaralı kahvaltımızdan sonra nargile içelim dedik. Elma nane bir nargileden sonra bir sahafa girdik. Küçük ama içerisine girince zevk veren bir dükkandı. Kitaplara dalarak baktım kaldım :) sonrasında da tekrar aynı yolu izleyerek sirkeciye döndük. Yalnız Beşiktaş hakkında bir şeyler söylemek isterim. Sokakların zemin döşemesinden evlerin yapısına harika bir oturmuşluğu var. Yaşamak isteyeceğim bir İstanbul semti. Dar ve küçük ara sokaklarına ise bayıldım. Hele ki meyhanelerin olduğu o sokağa :P Sirkeci’ye geldikten sonra daha zamanımız olduğu için gamze ve ben deniz kenarında biraz dolaşalım ve fotoğraf çekelim dedik.

Vapur iskelesinin girişinden ötürü deniz kenarının telle çevrili olması ??? yüzünden uzun bir mesafe yürüdükten sonra Galata Kulesinin manzarasını arkamıza alarak fotoğraf çektirdik J sonrasında da fotoğraf çeke çeke vakfın yolunu tuttuk. Vakıfta toplantı odasında diğer eğitmen adayı arkadaşları beklemeye koyulduk. Ofis çalışanı arkadaşlarla ve kendi aramızda sohbet ederek zamanı geçirmeye çalıştığımız sırada bir ofis çalışanı arkadaş ile bir anlaşma yaptık. Bana bir çakmak verdi ve eğitimin son gününe kadar bu çakmağı saklamamı ve kaybetmememi söyledi ama nedenini söylemedi. Bende kabul ettim. Ne olacağını merak ediyorum ve bunu öğrendiğim zaman ismini de buradan paylaşıcam :) Neyse 24 arkadaş toplandık ve şileye hareket ettik. Boğaz köprüsünden geçerek yola koyulduk. Boğaz Köprüsünden geçmenin tadı çok hoşuma gitti. Bunun tekrarları mutlaka olacak :) yolun bazı zamanlarında uyudum bazı zamanlarında şapşal bir şekilde uyanıktım. Bu yüzden ayrıntıları hatırlamıyorum.

Yaklaşık 2 saatlik bir yolculuktan sonra şilede şuan da kaldığımız otelimize geldik. Grand Otel ;) Kaydımızı yaptırıp odalarımıza yerleştik. Yerleştik dediğim eşyaları fırlattık attık odalara hemen lobiye indik J Saat 8 gibi de ilk toplantımızı yaptık. Tanışma eğitimi desek çok daha doğru olur. Bu tarz yaptık ettik dolu bir yazı yazmamın ve olayları kısaca yazmamın sebebi zamanımın olmaması. Sürekli eğitimlerdeyiz ve ben bilgisayara zorla dokunuyorum ama bundan şikayetçi değilim. Çünkü bizler bu eğitimden döndükten sonra sahaya çıkıp gönüllü arkadaşlarımıza aktarımlarda bulunacağız. Bunun içinde bizlerin donanımlı olması gerekiyor ve bunun içinde şuanda ki eğitim yoğunluğunun tamamına katılmamız gerekiyor. Sonuç olarak şikayetçi değilim aksine çok memnunum. Diğer günlerde de neler yaşadığımızı zaman buldukça paylaşmaya çalışacağım. Hadi ben eğitime kaçtım :D

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Ay Hırsızı --- Sunay AKIN

Sun, 28 Feb 2010 00:00:00 GMT

Sunay AKIN eğitimini aldığı konulara değiniyor bu kez. Gözünü yukarılara ve çok uzaklara dikiyor. Karanlıklar içerisini hayatımızla öyle güzel noktalardan birleştiriyor ki tadına doyamıyorsunuz. Mutlaka okunması gereken bir yapıt.

Sunay Akın yeni kitabı Ay Hırsızı’nda gözünü Ay’a dikiyor ve bir arkeoloğun sabrıyla kazıyor insanlığın ortak birikiminin üzerine çöken tozu toprağı… Ortaya çıkardığı bilgiyi şair duyarlığıyla ilmek ilmek dokuyor ve okurunu hayrete düşürecek öyküler bir bir diziliyor karşımıza.

Cervantes ve Mimar Sinan hangi caminin inşaatında buluştu? .. Enver Paşa’nın uçağı kaç kez düştü? .. Piri Reis’in haritası Topkapı Sarayı’nda nasıl bulundu? .. İstanbul Boğazı’nı yürüyerek geçen Attila Hülagü’nün sırrı neydi? 157 yıl yaşayan Zaro Ağa’nın Amerika seferi… Atatürk neden hiç uçağa binmedi? ..

Tanıtım Bülteninden

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

NBA All Star 2011 Yetenek Yarışmaları

Sat, 20 Feb 2010 00:00:00 GMT

Aristoteles’in güzel bir sözü şöyle der: “Hiç bir dahi, biraz çılgınlık karışımından yoksun olamaz.” Basketbolun dahilerinin şov gecesi de işte bu sözdeki çılgınlıkların sergilendiği ve izleyenlerin müthiş zevk aldıkları bir gece oldu. Özellikle smaç yarışması ben dahil bir çok basketbolseveri büyüledi. Arabanın üzerinden zıplayanı, üç topu smaç yapanı, iki potaya aynı anda smaç yapanı… Öldü denilen, eski tadını bir daha yakalayamaz denilen smaç yarışması tarihin en güzel (bana göre) yarışmasına dönüştü. Beklenildiği gibi Blake Griffin smaç yarışmasını kazandı. Üçlük yarışmasını bence süpriz bir şekilde son şampiyon Paul Pierce ve benim favorim Ray Allen’ın önünde James Jones kazandı. Yetenekte ise Stephen Curry birinci geldi.

Smaç Yarışması Katılımcılar Blake Griffin, Serge Ibaka, JaVale McGee ve DeMar DeRozan idi :) Harika bir çekişme yaşandı. Her smaç alkışı hak etti ve her smaç görülmeye değerdi. Tabi bazıları diğerlerinden ayrılıyordu. Ben de bir ayrım yaptım. Şampiyonun videolarını bloguma taşıdım. İşte o akıldan silinemeyecek smaçlar. Blake Griffin’in havada 360 derece dönür çift el ile bastığı smaç görülmeye değerdi. Evet bunu daha önce yapanlar oldu ama çift elle bitirebilen çok az kişi var.

Sakatlanma tehlikesine rağmen havada tam tur dönerek yaptığı smaçtan sonra hızlanacağı belliydi. Takım arkadaşı Baron Davis’in panyaya çarptırarak verdiği topu değirmen ile bitirdiği smaç bunun göstergesiydi.

Bu iki smaç griffin’in finale kalmasına yetti de arttı bile :) Final de ise tam anlamıyla bir büyüleme operasyonu vardı. İlk olarak Carter’ın kolunun dirseğine kadar olan kısmını potaya sokarak yaptığı smacın benzerini fakat panyadan pas alarak olanını yaptı Blake.

Ve bitiriş. Staphes Center’ın ortasında bir koro, koronun dilinde “I believe I can flying (uçabileceğime inanıyorum)”, potanın altında bir araba ve arabanın üstünden uçan bir adam. Blake Griffin.

Müthiş bir sunum :) I believe I can fly şarkısı Michael Jordan’ın oynadığı Space Jam filminin de müziğiydi. Jordan akıllardan asla çıkmıyor :) Bu son smaç ile şampiyonluğunu kesinleştirdi Blake Griffin. Tam anlamıyla hak ettiğine inanıyorum. Bu müthiş geceyi bize yaşattıkları için bu basketbol dahilerine teşekkür ediyorum.

Diğer smaçları izlemek istiyorsanız >>> http://www.youtube.com/user/medyunhavba?feature=mhum

İyi seyirler.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

17. Gençlik Konseyi --- Ankara

Tue, 16 Feb 2010 00:00:00 GMT

5 - 8 Şubat tarihleri arasında Ankarada gerçekleştirilen Toplum Gönüllüleri Vakfı 17. Gençlik Konseyinin katılımcılarından bir tanesi de bendim. Her ne kadar kaçak olarak katılmış olsamda katılımcı olduğum gerçeği göz ardı edilemez :D 4 gün boyunca Ankarada tog dolu günler geçirdik.

Türkiyenin dört bir yanından gelen hatta Kıbrıs ve Azerbeycandan dahi gelen Toplum Gönüllüleri ile birlikte bitmek bilmeyen otobüs yolculuklarımızda, konferans aralarında, yurt kantin ve spor salonunda kısaca bulduğumuz her alanda kaynaşmaya, iletişim kurmaya çalıştık. Çünkü bu kadar farklı kültürü bir arada bulmak çok kolay olmuyor. Bu fırsatımızı en iyi şekilde değerlendirmek, yeni arkadaşlıklar edinmek, yeni şeyler öğrenmek amacıyla arı misali her çiçeği dolaştık (Çiçekler Toplum Gönüllüleri :)) Her çiçekten bir şeyler almaya, oraya bir şeyler bırakmaya çalıştık. Bu dolaşmaların, konuşmaların ne kadar sağlıklı olduğunu konsey dönüşü örgütlenmek için farklı yollarla bir araya gelmeye çalışan arkadaşlarımı görünce anladım. Evet işe yaramış dedim :) Konseyin benim açımdan bir değerlendirmesi yapmak istiyorum şimdi. Kısaca ama benim için önem arz eden şeyler ;)

Organizasyon Organizasyonda ankara organizasyon ekibinin eksik kaldığını düşünüyorum. Gelişlerden başlayarak gidişlere kadar bir sürü aksaklıklar yaşandı. Ne gibi mi? İşte bir kaçı.

Ege Üniversitesi Toplum Gönüllülerinden bir katılımcı ve iki adet atölye uygulatıcısı ile birlikte Ankaraya geldim. Bize ilk olarak ODTÜ karşısındaki KYK yurduna (adını unuttumda :P) gelmemiz söylendi. Orada buluşulup yemeğe gidilecekti. Evet biz yurda gittik ama güvenlikten öğrendiğimiz bilgi ile sinir olduk. Kadın bize “Yurt değiştirildi. Başka bir yurda geçiş yaptı onlar” dedi. Haydeee. Hemen saha sorumlularından bir tanesini arayıp yerlerini öğrendik.Gecikmeli olarak diğer yurda ulaştık. Millet bizi beklemiş. Kimse kusura bakmasın ama bizim suçumuz değildi. Ege Üniversitesi Toplum Gönüllüleri katılımcılarından bir tanesi konsey öncesi bilgilendirme için aranmadı. Sorduğumuzda arandık dendi. Hayır aranmadı. Aranması gerekiyordu. Büyük bir şehirde olmanın verdiği bir sıkıntı olsa dahi yerleşim, yemek ve konferans salonlarının mesafesinin bu kadar çok olmaması iyi olabilirdi. Otobüs ile seyahat etmekten bir yerlerimiz ağrıdı. Kendimi bir ara koyun gibi hissettim. Atölye salonlarının daha sakin alanlar olması beklenir. Dışarıdaki sesin atölyede yeri yoktur. Fakat ortalık yerde atölye yapmamız istendi. Yaptık ama millete susar mısınız demekten atölyeye odaklanamadık.

İçerik İçerik konusunda ilk olarak Bolu konseyinin daha dolu olduğunu söylemem gerekiyor. Tabi ki de yaz konseyi ile bahar konseyi arasında fark olacaktır. Çünkü bahar konseyesinde YK seçimi ön plandadır. Fakat bu kadarda kısır olamaz ama ya.

İlk gün tanışma ve bilgilendirmeler ile geçti. Neden? Yarım saatlik bir dilimin yeterli olduğu bu alana neden tek bir gün ayrıldı? Gereksiz zaman kaybı. Atölye uygulama süreleri çok kısaydı. Sonradan farkına varıldı atölye sırasında uzatıldı. Atölye uygulatıcıları her şeylerini ayarlamış planlamışken. Eğitimden anlamak lazım biraz.

B planı olmayan bir organizasyon olamaz. Gençlik kollarının foruma gelememesi ile oluşan boşluk berbattı. Gerçi gelmiş olsalardı süre yetmicekti ya ona birazdan değinelim. Süre kullanımlarında dikkatli davranılmadı. Sürekli sarkmalar oldu. Sürekli olması sıkıntılı olan durum. Bir iki kabul edilebilir. Konuk olarak çağırılan ve konuşma yapan kişilerin Toplum Gönüllüleri ile ilgili bilgilendirilmeleri gerekirdi. Konuşmalarından, tavırlarından hiç bir şekilde Tog hakkında bir bilgilerinin olmadığı belli oluyordu. İdeolojik savaş bile yaşandı bir ara. Sunum yapan kişilerin biraz daha işlerini ciddiye almaları gerekiyor. Hepsine lafım yok ama bir kısmının laubali tavırları hiç hoş değildi.

Olumlu Olumsuz bazı kısımları söyledik fakat olumlu yönler de vardı :D

Şehir içi ulaşım her ne kadar biraz söylendiysemde başarılıydı. 4 gün boyunca, günde 4 ile 6 kez 300 - 350 kişilik bir grubu Ankara içerisinde hareket ettirmek kolay değildir ve bunda gayet başarılı olunduğunu söylemek zor değil. KYK yurdunun ayarlanması hatta güze bir yurdun ayarlanması :D gerçekten güzeldi.

Bitirirken Söyleyeceklerim Dönüş için bilet ayarlamaya çalışırken sadece telefon numarası istediğim kadının bana hırsız muamelesi yapması hiç hoş değildi. Böyle zihniyetsiz, kendisini beğenmiş, kendini yüksek gören bir kişinin Tog da olması üzdü beni. Bir şarkı sözü “A me piace così, e non chiedo il permesso, perchè questo dolore è amore per te.” yani “Bunu seviyorum, ve izin istemeye gerek yok, bu acı senin aşkın için” diyor. (ya tam çevirememiş olabilirim :P mazur görün :P) Çektiğimiz her çile tog için dolayısıyla toplumsal barış için, gençler için, bizim için ;) İşte bunu seviyorum.

Şarkı sözünün geçtiği şarkıyla bitirelim :)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Değişim ve Yeni Hayat

Fri, 22 Jan 2010 00:00:00 GMT

Ne gariptir ama hayatını devam ettirebilmek için her şeyini, bütün düzenini, bütün arkadaşlarını bırakıp hiç bilmediğin bir yere gelmek ve o yerde hayatına şekil vermek. Yeni bir okul, yepyeni arkadaşlar, yepyeni bir ev (yurt). Bunların nedeni sürekli bir değişimin hüküm sürmesi ve bizlerinde ona ayak uydurmamız. Çünkü ayak uydurmamamız sonucunda hayat çekilmez olarak onun oyununa uymamanın cezasını kesiyor bize. Gariplik dediğim nokta hayatımızı devam ettirmek için bu kadar çabaya gerek var mı? Her şey yerli yerindeyken - ben annemin yanı başında, babamın sert bakışları altında - bu süreci atlatıp, düzenli bir hayata sahip olamaz mıyım? Olurum evet haklısınız.

Burada önemli olan nokta insanın bir şekilde yanlızlığı öğrenmesinin gerektiğidir. Hayatlarımızı bir şekilde yoluna koyabiliriz ama onun ruhsal olarak iyi bir şekilde devam edebilmesi işte bu yanlızlıkta gizli. Bir arkadaşınızdan kötü bir kazık yiyebilirsiniz, anne ve babanız yanınızdan ayrılabilir :’( , insanlar size boğucu gelmeye başlayabilir. İşte bu noktalarda bir köşeye çekilip kendinizle olmanız gerekebilir. O arkadaşınız güvendiğiniz tek insan olabilir, anne ve babanız artık yoklarken nasıl bir hayat devam ettireceksiniz?, insanlar dedim onlardan uzak durmak için onlara yanaşmazsınız di mi? işte bu gibi durumlarda sağlıklı kalabilmek, iyi kararlar verebilmek için kendinizle iyi bir arkadaş olmanız gereklidir. Bunun için de erken yaşlardaki bu değişim önemli bir hal alıyor.

Bende bu değişime uyan bir bir kişiyim. Benim değişimim İzmir de oluyor. Hala oluyor çünkü değişmeyen tek şey değişimin kendisi :) İzmire gelişimi sorguluyorum uzun süredir. Sonuçta hep iyi ki gelmişim diyorum :) Bunu söylememin sebebi burada sürekli güzel şeyler yaşamam değil. Aksine çok kötü, beni etkileyen olaylarla karşı karşıya kalarak, bir nebze de olsa hayatı öğrenmeye başlamamdır. Elbette güzelliklerini de gördüm ama önemli olan nokta acı duyduğum noktalar şuan da. (Not: Mazoşist değilim)

Aşağıda beni üzen, büyük ihtimalle sizlerinde hayatınızda karşılaştığınız durumlardan bazılarını yazıcam. Tam şuan da arka planda çalan şarkıda “When people run in circles it’s a very very mad world (Daireler içinde döner insanlar bu delirmiş dünyada)” diyor. Aşağıda okuyacaklarınızı bu sözü de düşünerek yorumlamanızı rica ediyorum :)

Yardım etmeyi amaçlarsın. Bunun için elinden geleni yaparsın. Karşılığında aldığın cevap “Sen ne yaptın ki?” dir. İyi olmamayı bu durumlarda sevmiyorum.
Çok çok önemli işlerin, sınavların olduğu halde zaman ayırıp derdine ortak olduğun dostun, başka bir kişi için seni tanımaz. O kişi benim için o an bitmiştir.
Çok çalışmışsındır ama sınavın kötü gelir. Hocaya elam vermen dahi yetecektir notunun yükselmesine ama sen haketmediğini düşünerek, arkadaşlarına haksızlık olacağını düşündüğünden tenezzül bile etmezsin. Fakat bazıları senin tersindir. Onlar senin gibi düşünmüyordur. Bu insanlara güvenim o anda azalır.
Seversin ya da çok hoşlanırsın. Karşındaki kişiden de bu hisleri teyit eden davranışlar görürsün ama konuştuğunda o kişinin acısı vardır ve henüz böyle bir şeye hazırlıklı değildir. Bir olsa anlarım da fazlası zarar. Ben yardım kurumu değilim.
Bir işte uzmansındır en azından bulunduğun ortamda. Fakat öyle kişiler vardır ki sana sorulan alanınla ilgili sorularda dahi sözünü kesip bilmedikleri halde söze karışarak saçmalarlar. Yaptıkları size ve bilginize saygısızlıktır. Bu insanlara yararım dokunacağını bilsem dahi zor yardım ederim.
Sabahlarsın akşamlarsın bir ekip olarak bir şeyleri ortaya çıkarırsın. Birisi çıkar ben yaptım diyerek söz etmeye başlar. Al o adamı boğazla.

Uykum geldi artık. Daha bir çok örnek verilebilir ama türevler size kalsın. Son olarak yukarıda bir iki sözünü paylaştığım şarkıyla güle güle demek istiyorum sizlere =)

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Önce Çocuklar ve Kadınlar --- Sunay AKIN

Fri, 15 Jan 2010 00:00:00 GMT

Deniz ve denizin oyuncakları gemiler, vapurlar vb. Sunay AKIN dan dünya tarihindeki önemli deniz olayları üzerine önemli bir yapıt. Bir şair bakış ve anlatış açısıyla :) Eski şarkıcı ozanlara benzer Sunay Akın. Ortaçağda kasaba kasaba dolaşan, köy meydanlarında türkülerini söyleyen ozanlara. Geçtiği her yerde insanların yüreğine bir şair izi bırakır. Ama aynı zamanda bir tarih yazarıdır o.

Şiirsel gizli tarihimizin yazarı! Açarsanız bu kitabın kapağını geçmişe, denizlerin derinliklerine ineceksiniz. Sizin olan batıkların öyküsünü, yaşanmış ölümsüz anların nasıl buluştuğunu göreceksiniz. Denizdeki kavun kabuklarının izinin Che Guevara’ya, astronot James Irwin’in uzay gemisinin kendi çocukluğuna çıktığını ve 1942’de Boğaz sularında yüzlerce insanın nasıl öldürüldüğünü okuyacaksınız.

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)

Narmanlı Hanı

Sat, 09 Jan 2010 00:00:00 GMT

Bedri Rahmi EYÜPOĞLU, Ahmet Hamdi TANPINAR gibi bir çok sanatçımızın yaşamış ve çalışmış olduğu Narmanlı Hanı 1831 yılında inşa edilmiştir. İstanbul Beyoğlun da yer alan bina 1880 yılına kadar Rus Büyükelçiliği, 1914 e kadar Rus Hapishanesi, daha sonrasında da Harmanlı ailesi mülkü olarak kullanılmıştır. Sonra ki yıllarda bir çok sanatçımıza yaşama ve çalışma alanı olmuştur.

Beş ressam tarafından D Grubu 1933 yılında ilk sergisini burada açmıştır.

Bir zamanların istanbulunun merkezlerinden olan, 170 yıllık istanbul tarihine tanıklık etmiş bu binada bu yıllarda sadece bir noter ofisi bulunuyor. Ben gidip görmedim ama içerisinde elli adet kediye sahip bir kadının yaşadığı da söyleniyor. Yekta KOPAN ın Narmanlı Hanı Ne Olacak adlı yazısını okuduktan sonra ben de bir şeyler söylemek istedim.

Tarih kokan böyle bir yapının; bir müzeye, bir kültür merkezine dönüştürülmesini beklemeye hepimizin hakkının olduğunu düşünüyorum. Düşünsenize; İstanbulun merkezinde, tarih kokan bir depoya tarihinizi koyarak onu koruma altına alıyorsunuz ve düzenli bir şekilde insanlara bunu sunuyorsunuz. Müzeler kültürel depo alanlarıdır. Yekta KOPAN “İstanbul şehrinin merkezinde bir “Kent Müzesi” yok.” diyor. Kültürünüzü koruma altına almazsanız, başkaları gelir onu sahiplenir sesinizi bile çıkaramazsınız. Kaybolur, yıpratılır ve sizde tarihinize hakaret etmiş olursunuz.

İstanbulda her gün bu binanın yanından geçen ama o binanın nasıl bir çınar olduğunu bilmeyen bir sürü insan var. Peki bilmemek sadece onların suçu mu?

(This is an article posted to my blog at hkucuk.me. You can read it online by clicking here.)