Database , veriyi yalnızca saklayan değil; onu düzenli, güvenilir, hızlı, erişilebilir ve yönetilebilir hale getiren bir sistemdir.

Peki, neden verileri basit metin dosyalarına yazmıyoruz ya da Excel bizim için yeterli gelmiyor?

Bu ayrım önemli. Çünkü şirketlerde asıl ihtiyaç veriyi bir yere koymak değildir. Asıl ihtiyaç şudur:

• Bu veriye birden fazla kişi aynı anda erişebilsin
• Veri bozulmasın
• Yanlışlıkla kaybolmasın
• Gerektiğinde çok hızlı bulunsun
• Sistem çöktüğünde geri getirilebilsin
• İş büyüdükçe sistem de büyüyebilsin

Bir örnek düşünelim.
Bir e-ticaret sisteminiz var. Aynı anda yüzlerce kullanıcı ürün satın alıyor. Ürün stoğu azalıyor, ödeme bilgileri işleniyor, sipariş geçmişi yazılıyor.

Bunu metin dosyalarıyla yönetmeye çalıştığınızda şu sorular çıkar:

• Aynı anda iki kişi aynı ürünü alırsa stok nasıl doğru kalacak?
• Sistem çökmeden hemen önce yazılan veri kaybolursa ne olacak?
• Bir müşterinin son 1 yıldaki siparişlerini nasıl hızlıca bulacaksınız?
• Yanlışlıkla dosya bozulursa nasıl toparlanacaksınız?

Database tam olarak bu sorunları çözmek için vardır.

1. Database ile DBMS aynı şey mi?

Burada çok sık karıştırılan bir ayrım var. Günlük konuşmada “database kullanıyoruz” deriz. Ama çoğu zaman aslında database’i değil, DBMS’i kastediyoruz.

Database nedir?

Database, verinin kendisidir. Tablolar, kayıtlar, index’ler, şemalar, ilişki tanımları, metadata… Bunların tamamı verinin yapısal dünyasını oluşturur.

DBMS nedir?

DBMS, yani Database Management System, bu veriyi yöneten yazılımdır.

Örneğin:PostgreSQL, MySQL, Oracle, SQL Server, MongoDB bunların her biri birer DBMS’tir.

Yani basitçe:

• Database = veri ve veri yapısı
• DBMS = bu veriyi yöneten motor

Bunu bir kütüphane gibi düşünebilirsin:

• Kitapların kendisi = database
• Kütüphane sistemi, raf düzeni, ödünç alma mekanizması = DBMS

Şirketler yalnızca veri depolamaz; veriyi güvenli, denetlenebilir ve performanslı biçimde yönetmek zorundadır.

2. Database’in kalbi

Bir database’in en temel vaadi hız değildir.İlk vaadi güvenilirliktir.Çünkü iş dünyasında en pahalı hata çoğu zaman “yavaşlık” değil, yanlış veridir.

Bir kullanıcıya iki kez ücret yansıtılması, siparişin kaybolması, stok bilgisinin yanlış görünmesi, raporların hatalı çıkması… Bunların hepsi doğrudan iş kaybına dönüşür.

Bu yüzden ciddi database sistemleri bir güven modeli üzerine kuruludur. Bunu teknik dünyada genellikle ACID kavramıyla anlatırız.

3. ACID

Atomicity

Bir işlem ya tamamen olur ya da hiç olmaz.Örneğin banka transferi düşünün.Bir hesaptan para düşülüp diğerine eklenmeden sistem çökerse ne olacak?

Atomicity der ki:
Bu işlem yarım kalamaz. Ya iki taraf da tamamlanır, ya da hiçbir şey olmamış sayılır.Bu, teknik olmayan ekipler için de çok önemli bir kavramdır. Çünkü “yarım işlem” iş süreçlerinin en tehlikeli halidir.

Consistency

Veri her zaman tanımlanmış kurallara uygun kalmalıdır. Örneğin: olmayan bir kullanıcıya sipariş yazılamaz, eksi stok oluşmamalı, boş geçilmemesi gereken alanlar boş olamaz

Consistency, sistemin kendi kurallarına sadık kalmasını sağlar.

Isolation

Aynı anda çalışan işlemler birbirini bozmasın.Gerçek dünyada onlarca, yüzlerce işlem paralel yürür.Isolation olmazsa bir kullanıcının yaptığı değişikliği diğer işlem yarım halde görebilir. Bu da yanlış raporlara, bozuk hesaplamalara ve kaotik davranışlara yol açar.

Durability

“Kaydedildi” denmişse gerçekten kaydedilmiş olmalı Sistem kapansa, sunucu çökse, elektrik gitse bile commit edilmiş veri kaybolmamalı. Kurumsal dünyada bu madde kritik önemdedir. Çünkü kullanıcı “işlem başarılı” gördüğünde, bunun teknik olarak garanti altına alınmış olması gerekir. Kısacası ACID şunu söyler:

Database, veriyi sadece tutmaz; ona güvenebilmeni sağlar.

4. Storage engine

Birçoğumuz database ile SQL üzerinden konuşuruz ama SQL, görünen yüzdür. Perdenin arkasında asıl ağır işi yapan katman storage engine’dir.

Storage engine şu soruların cevabıdır:

• Veri diskte nasıl tutuluyor?
• Nasıl bulunuyor?
• Nasıl güncelleniyor?
• Çökme sonrası nasıl geri yükleniyor?

Bir database mimarı için burası çok kritiktir. Çünkü performans ve ölçeklenme davranışı büyük ölçüde burada belirlenir.

B-Tree Yaklaşımı: Okuma Performansının Mimarı

Birçok ilişkisel veritabanı sisteminin (PostgreSQL, MySQL, SQL Server) kalbinde B-Tree tabanlı yapılar yatar. Eğer sisteminizde kullanıcı kayıtları, sipariş geçmişi veya rapor sorguları gibi “bulma” (read) işlemleri yoğunsa, B-Tree en mantıklı tercihtir.

Peki, B-Tree neden okuma dostudur?

B-Tree, veriyi ve indeksleri dengeli bir ağaç yapısında tutar. Bu dengeli yapı sayesinde arama işlemleri logaritmik karmaşıklıkla (O(logn)) gerçekleştirilir. Yani veriniz bin kat büyüse bile, arama maliyeti sadece küçük bir miktar artar; sistem kontrolünüzden çıkmaz.

Daha da önemlisi, B-Tree doğrudan disk erişimi düşünülerek tasarlanmıştır:

• Disk Dostu Organizasyon: Ağacın düğümleri (nodes), diskteki sayfa yapısına (page size) uygun biçimde organize edilir.
• Minimum Rastgele Okuma: Tek bir düğümde çok sayıda anahtar tutularak ağacın derinliği azaltılır. Böylece veriye ulaşmak için gereken “disk sıçraması” sayısı minimuma iner.

Bu yapı şu senaryolarda rakipsizdir:

• Tekil Kayıt Bulma: Milyonlarca satır arasından spesifik bir ID’ye anında ulaşmak.
• Aralık Sorguları (Range Scans): Belirli iki tarih arasındaki tüm siparişleri hızlıca listelemek.
• Sıralı Okuma: Verileri alfabetik veya kronolojik sırayla, ekstra bir sıralama maliyeti olmadan getirmek.

Kısacası B-Tree; veriyi rastgele bir yığın olmaktan çıkarıp, her bir parçanın adresini milisaniyeler içinde bulabileceğiniz devasa ve düzenli bir kütüphaneye dönüştürür.

LSM-Tree Yaklaşımı: Yazma Yoğun Sistemlerin Güç Kaynağı

B-Tree okuma işlemlerinde parıldarken, bazı modern sistemler (Cassandra, RocksDB, InfluxDB) tamamen farklı bir felsefeye odaklanır: LSM-Tree (Log-Structured Merge-Tree). Eğer sisteminiz saniyede on binlerce log satırı üretiyorsa, sürekli IoT sensör verisi akıyorsa veya devasa event stream’leri (olay akışlarını) yönetiyorsanız, LSM-Tree sizin için en doğru mimaridir.

Peki, LSM-Tree neden “yazma dostu” bir yapıdır?

LSM-Tree’nin temel mantığı, veriyi diskteki ana yerine hemen yazmaya çalışmak yerine katmanlı bir yapı kullanmaktır:

• Önce Bellek (MemTable): Gelen her yeni veri önce bellekte (RAM) çok hızlı bir şekilde tutulur. Bu, disk gecikmesini (latency) tamamen ortadan kaldırır.
• Sıralı Yazma (Sequential Write): Bellek dolduğunda, veriler disk üzerine büyük bloklar halinde ve sıralı şekilde aktarılır. Disk ve SSD seviyesinde “sıralı yazma”, “rastgele yazmaya” (random write) göre çok daha verimlidir. LSM-Tree, küçük ve dağınık yazma taleplerini devasa bir nehre dönüştürerek diske akıtır.
• Arka Planda Birleştirme (Compaction): Diske yazılan bu küçük dosyalar, arka planda periyodik olarak birleştirilir (Merge). Bu sayede veri hem temizlenir hem de okunabilirliği artırılır.

Bu yaklaşım şu senaryolarda rakipsizdir:

• Yüksek Hacimli Event Akışları: Sürekli gerçekleşen kullanıcı hareketlerini kaydetmek.
• IoT ve Sensör Verileri: Binlerce cihazdan gelen anlık metrikleri milisaniyeler içinde depolamak.
• Log Yönetimi: Sistemin her adımını izleyen devasa günlük kayıtlarını performans kaybı yaşamadan tutmak.

5. WAL: “Kaydettim” sözünün teknik karşılığı

Durability’den söz ettik. Peki bu nasıl sağlanıyor?

Burada karşımıza WAL — Write Ahead Log çıkar. Mantığı şudur:Asıl veri yapısını değiştirmeden önce, yapılacak değişiklik önce log’a yazılır.

Bunun iki büyük faydası vardır:

1. Birincisi, sistem çökerse log yeniden oynatılarak hangi işlemlerin tamamlandığı anlaşılır.
2. İkincisi, sıralı log yazımı çoğu zaman rastgele disk güncellemelerinden daha verimlidir.

Bir muhasebecinin önce işlem defterine not düşüp sonra ana kayıtları güncellemesi gibi düşünün. Ana tablo bozulsa bile işlem kaydı sayesinde ne yapıldığını biliyorsunuzdur.

İşte WAL, database’in hafızasını koruyan mekanizmalardan biridir.

6. Index: Hızın görünen ama yanlış kullanıldığında pahalı olan kısmı

Bir database konuşmasında index anlatmadan ilerlemek olmaz. Çünkü insanlar çoğu zaman index’i “performans düğmesi” gibi düşünüyor.Bir açıdan doğru. Ama eksik.

Klasik örnektir Index’i şöyle düşünelim:
Bir kitabın sonunda konu dizini varsa, istediğin kavramı hızlıca bulursun. Yoksa her sayfayı tek tek çevirmen gerekir.Bu örnek öğretici olsa da çok temel kalır. Bir adım daha derine inelim.

Bir index, çoğu zaman verinin kendisini değil, veriye giden yolu tutar.

Yani kabaca şunu yapar:

• belirli kolon değerlerini sıralı veya aranabilir bir yapıda tutar
• her değerin yanında ilgili satıra ulaşmayı sağlayan bir referans taşır

Bu referans bazı sistemlerde RowID, bazı sistemlerde primary key, bazı yapılarda doğrudan fiziksel sayfa adresi benzeri mantıklarla temsil edilir.

Bu yüzden index, “verinin kopyası” değil; çoğu zaman “veriye erişim haritası”dır.Ama burada kritik bir mimari gerçeği var:

Index bedava değildir.

Her index:

• ek disk alanı kullanır
• write işlemlerini yavaşlatır
• bakım yükü oluşturur

Çünkü veri eklendiğinde, silindiğinde veya güncellendiğinde sadece tablo değil, index de güncellenir.

Bu yüzden iyi mimar şu hatayı yapmaz: “Her sütuna index atalım.”

Onun yerine şunu sorar:

• En çok hangi sorgular çalışıyor?
• Filtrelenen kolonlar hangileri?
• Sıralama nerede yapılıyor?
• Join hangi alanlardan kuruluyor?

Yani index, veriye değil; kullanım desenine göre tasarlanır.

7. Query execution: Yazdığın SQL’in arka planda başına ne geliyor?

Teknik ekip için en dönüştürücü kavramlardan biri budur.Çünkü çoğu geliştirici SQL’i metin gibi görür. Oysa database onu bir yürütme planına çevirir. Bir sorgu geldiğinde kabaca şu adımlar olur:

Parsing

Yazdığın SQL önce dil bilgisi açısından çözülür.

Semantic analysis

Tablo var mı, kolon var mı, veri tipleri uyumlu mu, yetkin var mı kontrol edilir.

Optimization

Aynı sonucu üreten farklı yollar arasından en düşük maliyetli olan seçilmeye çalışılır.

Bu aşamada veritabanı şunları düşünür:

• full scan mi yapayım?
• index scan mi kullanayım?
• hash join mi daha uygun?
• merge join mi?
• önce filtreleyip sonra mı join yapayım, yoksa tersi mi?

Execution

Seçilen plan gerçekten çalıştırılır. İşte bu yüzden performans sorunu yaşayan bir sistemde mühendis yalnızca sorguya bakmaz;execution plan’a bakar.

8. Normalizasyon ve denormalizasyon: Düzen ile hız arasındaki denge

Veri modelleme tarafında da önemli bir denge vardır.

Normalizasyon

Amaç veri tekrarını azaltmak ve tutarlılığı artırmaktır.

Avantajı:

• daha temiz veri modeli
• daha az tekrar
• güncelleme anomalisinin azalması
• kuralları merkezi yönetebilme

Örneğin kullanıcı bilgilerini her sipariş satırına yazmak yerine ayrı kullanıcı tablosunda tutarsın.

Denormalizasyon

Bazen de hız için bilerek tekrar üretirsin.Özellikle analitik sistemlerde veya çok sık raporlanan yapılarda sürekli join yapmak maliyetli olabilir. O zaman bazı bilgileri bilinçli şekilde tekrar edersin.

Burada doğru soru “hangisi doğru?” değildir.
Doğru soru şudur:

Bu sistem işlem odaklı mı, analiz odaklı mı?

• OLTP sistemleri çoğu zaman daha normalize yapılardan fayda görür
• OLAP sistemleri çoğu zaman daha denormalize yapılardan fayda görür

Bu da yine mimari bir karar alanıdır.

9. Replication ve sharding: Sistem büyümeye başladığında

Tek bir veritabanı sunucusu her zaman yeterli olmayabilir. Sistem büyüdükçe iki temel strateji öne çıkar.

Replication

Aynı veriyi birden fazla kopyada tutarsın.

Genel mantık şöyledir:

• yazmalar primary node’a gider
• okumalar replica’lara dağıtılabilir

Bu yöntem özellikle okuma ağırlıklı sistemlerde çok etkilidir.

Ama yeni sorular doğurur:

• Replica ne kadar güncel?
• Replication lag kabul edilebilir mi?
• Primary çökerse failover nasıl olacak?

Sharding

Burada aynı veriyi çoğaltmak yerine veriyi parçalarsın.Örneğin kullanıcıları user_id’ye göre farklı shard’lara dağıtabilirsin.

Bu sayede:

• yazma yükü bölünür
• depolama yükü dağılır
• tek node üzerindeki baskı azalır

Ancak bedeli büyüktür:

• cross-shard sorgular zorlaşır
• transaction yönetimi karmaşıklaşır
• operasyonel maliyet ciddi biçimde artar

Yani ölçekleme teknik bir başarı olduğu kadar, aynı zamanda karmaşıklık yönetimi problemidir.

10. CAP teoremi: Dağıtık sistemlerde her şeyi aynı anda alamazsın

Dağıtık sistemlerle (distributed systems) çalışan her mühendisin karşısına çıkan en temel kısıt CAP Teoremi’dir. Bu teorem, sadece teknik bir kısıtlama değil; aynı zamanda bir ürünün karakterini belirleyen stratejik bir karar mekanizmasıdır.

CAP Teoremi bize şunu söyler: Bir dağıtık sistemde aşağıdaki üç özelliğin üçünü birden aynı anda, en yüksek seviyede garanti edemezsiniz:

1. Consistency (Tutarlılık): Her okuma işlemi, en son yazılan veriyi (veya hata mesajını) döndürmelidir. Yani her düğümde veri aynı anda güncel olmalıdır.
2. Availability (Erişilebilirlik): Sistemdeki her istek, (başarılı veya başarısız) bir yanıt almalıdır. Sistem her zaman “açık” olmalıdır.
3. Partition Tolerance (Bölünme Toleransı): Ağdaki düğümler arasındaki iletişim kopsa bile (network partition) sistem çalışmaya devam etmelidir.

Gerçek Hayatın Seçimi: AP mi, CP mi? Gerçek dünyada ağ bölünmeleri (network split) kaçınılmazdır. Bu yüzden Partition Tolerance (P) bir lüks değil, zorunluluktur. Bu durumda asıl seçim şuna döner:

• CP (Consistency + Partition Tolerance): “Eğer ağda bir sorun varsa ve veriyi güncelleyemiyorsam, yanlış bilgi vermektense isteği reddederim (hata döndürürüm).” Örnek: Banka transfer sistemleri. Yanlış bakiye göstermektense, sistemin kısa süreliğine “hizmet dışı” kalması tercih edilir.
• AP (Availability + Partition Tolerance): “Ağda sorun olsa bile sistem çalışmaya devam etsin. Veri o an eski (tutarsız) olsa bile kullanıcıya bir cevap dönerim, ağ düzelince veriyi eşitlerim.” Örnek: Sosyal medya beğeni sayacı. Bir gönderinin beğeni sayısının birkaç saniye eski görünmesi kritik bir sorun yaratmaz; önemli olan kullanıcının uygulamayı kullanmaya devam edebilmesidir.

Bir veritabanı mimarı için “en iyi” diye bir şey yoktur; “bu iş yükü için en doğru takas (trade-off)” vardır.

Popüler bir yemek teslimat uygulamasını ele alalım:

1. Sipariş ve Ödeme Kayıtları: Burada hata payı sıfır olmalıdır. Güçlü tutarlılık (Consistency) ve ACID desteği için PostgreSQL gibi ilişkisel (Relational) bir sistem şarttır.
2. Sepet ve Oturum Yönetimi: Kullanıcının sepetindeki ürünler milisaniyeler içinde güncellenmelidir. Çok hızlı erişim için Redis gibi In-memory (bellek içi) sistemler tercih edilir.
3. Kurye Lokasyon Takibi: Saniyede binlerce koordinat verisi akan bir senaryoda, yüksek yazma hızına sahip LSM-Tree tabanlı bir NoSQL yapısı veya zaman serisi (Time-series) veritabanı çok daha verimlidir.
4. Arama ve Filtreleme: Binlerce restoran arasından “en yakın ve en ucuz” olanı bulmak için Elasticsearch gibi Full-text search motorları kullanılır.

Bu yüzden iyi bir veritabanı mimarisi yalnızca teknik bilgiyle değil, iş önceliklerini (business priorities) doğru analiz ederek inşa edilir. Teknik kararlarınız, ürünün kullanıcıya verdiği sözün teknik karşılığıdır.

11. Connection Pooling: Sistemin Görünmeyen Taşıyıcı Kolonu

Şimdi çok pratik ama çoğu zaman göz ardı edilen bir konuya gelelim.Database’e bağlantı açmak ucuz bir işlem değildir. Her web isteği için yeni bağlantı açarsan sistem boğulur.İşte burada connection pool kullanılır.

Uygulama, önceden belirli sayıda bağlantı açar ve bunları havuzda bekletir.
İstek geldiğinde havuzdan bir bağlantı alınır, işlem yapılır, sonra geri bırakılır.

Bu küçük gibi görünen konu, gerçek sistem performansında çok büyüktür.

Yanlış pool ayarı:

• gereksiz beklemeye
• database overload’ına
• timeout’lara
• ani performans düşüşlerine

neden olabilir. Yani bazen sorun SQL’de değil, bağlantı yönetimindedir.

Yazının başında sorduğumuz soruya dönelim.

Database nedir? En sade haliyle: organize edilmiş, kalıcı ve yönetilebilir bir veri sistemidir. Ama bu tanım, bir veritabanının gerçekte ne yaptığını anlatmaya yetmez.

Daha doğru bir tanım şöyle kurulabilir:

Database; veriyi güvenilir, tutarlı, hızlı ve ölçeklenebilir biçimde yönetmeyi sağlayan; eş zamanlılığı, bütünlüğü ve kalıcılığı garanti altına alan bir sistemdir.

Bu yazı boyunca gördük ki bir veritabanı seçimi, yalnızca teknik bir tercih değildir. Hangi garantileri verdiğinizi, hangi trade-off’ları kabul ettiğinizi ve sistemin hangi koşullar altında nasıl davranacağını belirleyen bir mühendislik kararıdır.Doğru soruyu sormak her şeyden önce gelir: Bu sistem ne kadar tutarlı olmalı? Ne kadar hızlı yazmalı? Ağ bölünmesinde ne yapmalı? Veri ne zaman gerçekten “güvenli” sayılmalı?

Bu soruların cevabı sizi doğru veritabanına götürür. Teknolojiyi seçmek değil, problemi anlamak — işin özü budur.

Hafta sonu boyunca eğitmenlerle yaptığımız sohbetler bu konuda zihnimi açtı. Özellikle Yusuf Bey’in yaklaşımı, mesleki tatminin yalnızca “kodu bizzat yazmakla” değil, insanlara değer sağlayan bir çıktıyı üretebilmekle mümkün olduğunu hatırlattı. Yapay zekânın artık yazılım geliştiricilerin bir parçası olduğu, asıl farkın ise güçlü bağlam kurabilme, problemi doğru tanımlayabilme ve doğru çıktıyı yönlendirebilme becerisinde ortaya çıktığı vurgulandı.

Bu bakış açısı, yazılımcı olma yolculuğumda beni kaygılandıran soruların yerini daha net bir farkındalığa bıraktı:
“Değer kodu yazan elde değil, problemi doğru çözen zihindedir.”

1. Oturum: Mutlu Polatcan ile Yapay Zekâ Temelleri

AI Weekend’in ilk oturumunda Mutlu Polatcan, günümüz yapay zekâ teknolojilerinin temelini oluşturan büyük dil modellerini (LLM) sade ve anlaşılır bir dille ele aldı. Sunumun ilk bölümü, LLM’lerin ne olduğu ve neden dönüştürücü bir teknoloji haline geldiğini anlamak için güçlü bir çerçeve sundu.

Polatcan, LLM’leri “Model aslında sadece bir sonraki token’ı tahmin ediyor. Ama bunu o kadar iyi yapıyor ki, bize anlamış gibi geliyor.” olarak tanımlıyor. Bu ifade, LLM’lerin insan benzeri bir anlayış sergiliyor gibi görünmesinin aslında devasa ölçekli istatistiksel tahminlerin bir sonucu olduğunu ortaya koyuyor.
GPT-3’ün 175 milyar, GPT-4’ün trilyon seviyesinde parametreye sahip olduğu düşünüldüğünde, neden bu kadar ‘akıcılık’ üretebildikleri daha da anlaşılır hale geliyor.

Bu mimarinin temelinde, 2017’de tanıtılan Transformer yapısı ve özellikle self-attention mekanizması bulunuyor. Polatcan’ın işaret ettiği gibi, self-attention modelin bir cümledeki tüm kelimeler arasındaki ilişkileri paralel olarak analiz etmesini sağlıyor ve bu yetenek uzun bağlamları anlama kapasitesinin özünü oluşturuyor.

LLM’ler Nasıl Çalışır?

Oturumun önemli bölümlerinden biri, LLM’lerin çalışma prensibini oluşturan next-token prediction mekanizmasının açıklanmasıydı. Model, verilen bir metinden sonra gelmesi en olası kelimeyi istatistiksel olarak tahmin ediyor. Bu tahmin süreci, gramer, bağlam, mantık ilişkileri ve uzun bağımlılıkların bir arada değerlendirilmesiyle gerçekleşiyor.

Bu gelişmiş yapının kalbinde, 2017’de tanıtılan Transformer mimarisi bulunuyor. Transformer’ın “self-attention” mekanizması, bir cümlenin içindeki her kelimenin diğer kelimelerle olan ilişkilerini çözümleyerek bağlamsal anlamı yakalıyor. Polatcan’ın verdiği örnekte olduğu gibi; “The animal didn’t cross the street because it was tired” cümlesindeki “it” kelimesinin “animal”ı işaret ettiğini doğru ilişkilendirmek, Transformer tabanlı modellerin güçlerinden biri.

Token’lar: LLM’lerin Temel İşlem Birimi

Token kavramı oturumda ayrıntılı şekilde ele alındı. Tokenlar her zaman bir kelimeye karşılık gelmeyebilir; kelime parçaları, ekler veya hatta boşluklar bile birer token olarak işlenebilir. Bu durum, özellikle Türkçe gibi eklemeli dillerde token sayısının artmasına ve maliyetin etkilenmesine neden olabiliyor.

Polatcan’ın gösterdiği tokenizer örneği (ör. “AI Weekend’e hoş geldiniz” cümlesinin 6 token’a bölünmesi) tokenizasyon mantığını somutlaştırdı ve eklemeli dillere özgü token dağılımının nasıl farklılaştığını görmemi sağladı.

Polatcan’ın gösterdiği tokenizer örneğinde, “AI Weekend’e hoş geldiniz” cümlesinin 6 token’a bölünmesi, tokenizasyonun pratikte nasıl çalıştığını netleştirdi.
Her modelin belirli bir context window sınırı olduğu için, token sayısı hem maliyet hem performans açısından kritik bir değişkendir. Örneğin GPT-4’ün 128K token’lık kontekst sınırı, aynı anda işleyebileceği metnin büyüklüğünü belirliyor.

Embedding: Anlamın Matematiksel Temsili

Token’ların sayısal vektörlere dönüştürülmesi, yapay zekânın metni “anlamlandırdığı” aşamayı oluşturuyor. Embedding’ler, her kelime veya cümlenin yüksek boyutlu bir uzayda temsil edilmesini sağlıyor. Mutlu Polatcan’ın örneğinde “king”, “queen”, “man” ve “woman” gibi kelimeler arasındaki ilişkiler vektör aritmetiğiyle açıklanıyor:

king — man + woman ≈ queen

Bu örnek, embedding uzayının yalnızca anlamı değil, kavramlar arasındaki ilişkileri de temsil edebildiğini gösteriyor. Bu nedenle embedding’ler semantik arama, öneri sistemleri, sınıflandırma ve kümeleme gibi birçok uygulamanın temelini oluşturuyor.

Colab Üzerinde Yapılan Uygulama: Kavramların Somutlaşması

Oturumun uygulamalı bölümünde, Google Colab üzerinde SentenceTransformers kullanılarak embedding oluşturma süreci gösterildi:

from sentence_transformers import SentenceTransformer
model = SentenceTransformer('all-MiniLM-L6-v2')
sample_text = "AI Weekend'e Hoş Geldiniz!"
embedding = model.encode(sample_text)

Bu çalışmanın çıktısı olan 384 boyutlu embedding vektörü, metnin sayısal uzayda nasıl temsil edildiğini somut bir şekilde gösterdi. Mutlu Bey’in cosine similarity üzerinden benzerlik hesaplamasını açıklaması, semantik arama mantığını daha anlaşılır hale getirdi.

LLM Pipeline’ı Bir Arada Düşünmek

Mutlu Bey, bu üç temel bileşenin (token → embedding → transformer) nasıl birlikte çalıştığını basit bir akışla özetledi:

1. Input metni verilir
2. Metin tokenize edilir
3. Tokenlar embedding modelinde vektörlere dönüştürülür
4. Transformer, self-attention ile ilişkileri çözer ve bağlamı anlar
5. Model, bir sonraki tokenı tahmin ederek çıktı üretir

Bu süreç, bir LLM’in nasıl “düşündüğünü” anlamak için temel bir referans oluşturuyor.

Gerçek Dünya Uygulamaları ve İyi Pratikler

Oturumun son bölümünde, LLM’lerin günlük iş süreçlerindeki kullanım örnekleri paylaşıldı:

• 7/24 müşteri destek botları
• Otomatik biletlendirme ve kategorizasyon
• İçerik üretimi ve kod geliştirme
• Veri analizi ve duygu analizi
• Semantik arama ve öneri sistemleri

Ayrıca prompt engineering ve context management gibi pratik konulara da değinildi. Büyük işlerin küçük parçalara bölünmesi, net talimatlar verilmesi ve token maliyetinin kontrol edilmesi gibi noktalar, LLM’lerle çalışırken kritik öneme sahip.

2. Oturum: Kadir Çubukçu ile Yapay Zekâya Doğru Soru Sorma Sanatı

AI Weekend’in ikinci oturumunda Kadir Nuri Çubukçu, yapay zekâ modelleriyle etkili iletişim kurmanın yalnızca teknik bir beceri değil, aynı zamanda bilinçli bir yönlendirme gerektiren bir süreç olduğunu vurguladı. Modern LLM’ler her ne kadar yüksek kapasiteli modeller olarak konumlansa da, ürettikleri yanıtların niteliği büyük ölçüde kullanıcı tarafından sunulan bilgi setine ve bu bilginin nasıl yapılandırıldığına bağlıdır. Bu nedenle doğru soruyu sormak, AI ile çalışmanın en kritik bileşenlerinden biri hâline geliyor.

AI Neden İyi Bir Cevap Veremiyor?

Kadir Bey’in sunumunda altını çizdiği temel prensiplerden biri, LLM’lerin insan benzeri bir “anlama” kapasitesine sahip olmadığıydı. Bu modeller, bağlamı insan gibi yorumlamak yerine istatistiksel olasılık dağılımları üzerinden tahmin üretir. Dolayısıyla girdiler eksik veya belirsiz olduğunda, model en güvenli ve en sık rastlanan yanıt kalıplarına yönelir.

Bu durum, özellikle gerçek hayata yakın sorularda açıkça görülebilir. Örneğin, “Köpeğim hasta, ne yapmalıyım?” gibi yüzeysel bir soru, modelin genel tavsiye moduna geçmesine sebep olur. Çünkü elimizde yalnızca kategori düzeyinde bilgiler vardır; yaş, cins, semptom süresi, risk derecesi gibi karar destekleyen değişkenler eksiktir.

Bu örnek, LLM’lerle iletişimde bilginin kapsamı, doğruluğu ve netliğinin yanıt kalitesini doğrudan belirlediğini gösteriyor
Model, kullanıcı kadar bilgili değildir; yalnızca kullanıcı kadar bilgilidir.

Prompt Tasarımında Yapısal Yaklaşım

Kadir Bey’in sunduğu yaklaşım, prompt tasarımını dört bileşenli bir mimari çerçevesine oturtuyor. Bu çerçeve, LLM’lerin tahmin mekanizmasını yönlendirmek ve belirsizlik düzeyini azaltmak için sistematik bir yöntem sunuyor.

1) Bağlam (Context)

Modelin içinde çalışacağı bilgi alanını belirler.Başarılı bağlam, konu hakkında gereksiz ayrıntı vermeden yönlendirici bilgiler sunar.
Bağlam, modelin problem uzayını daraltarak tahmin kalitesini artırır.

2) İstek (Instruction)

Modelden tam olarak ne yapılmasının istendiğini açıkça tarif etmek:
“Özetle”, “Karşılaştır”, “Tablo oluştur”, “Yeniden yaz” gibi net eylemler.

3) Format (Output Structure)

Çıktının hangi yapıda gelmesi gerektiği.
Özellikle teknik işlerde format belirlemek, çıktının kullanılabilirliğini doğrudan etkiliyor.

4) Örnek (Example)

Örnek, modelin üslup, kapsam ve beklenti seviyesini hizaladığı için kaliteyi belirleyen kritik bir unsurdur.
İyi bir örnek, modelin “hangi derinlikte ve hangi doğrultuda” yanıt üretmesi gerektiğini çok net şekilde gösterir.

Bu dört başlık birleştiğinde, modelin “tahmin etmesine” gerek kalmadan doğru davranış biçimi tanımlanmış oluyor.

Geri Bildirim Döngüsü: Tek Cevapla Yetinmemek

Oturumun öne çıkan bir diğer noktası, modelin ilk cevabını nihai kabul etmemenin önemiydi.
Kadir Bey’e göre en doğru çıktı çoğu zaman iteratif bir süreçle elde ediliyor.

Kullanılabilecek geri bildirim türlerinden bazıları:

• Ton ayarı: “Daha profesyonel bir tonda yaz.”
• Uzunluk ayarı: “Bu kısmı iki kat daha detaylandır.”
• Format güncelleme: “Bunu JSON formatında ver.”
• Derinlik artırma: “Gerçek bir örnek ekle.”
• Basitleştirme: “Yeni başlayan biri için anlat.”

Bu yaklaşım, LLM’lerle çalışırken kullanıcıyı aktif rol alan bir editör konumuna getiriyor.

Bağlam Kayması ve Oturum Yönetimi

Kadir Çubukçu’nun özellikle vurguladığı bir konu da şuydu:
Model, tek bir oturum içinde önceki mesajlarla ilişki kurmaya devam eder.

Bu bazen avantajdır, ancak konu değiştiğinde dezavantaj hâline gelir.
Örneğin hava sıcaklığı konuşulurken, aniden yemek tarifi sormak modelin yanlış bağlam kurmasına neden olabilir.

Bu yüzden:
Yeni konu = Yeni oturum
ilkesi, daha kararlı ve hatasız sonuçların alınmasını sağlıyor.

Genel Değerlendirme

Bu oturum, yapay zekâ ile çalışmanın yalnızca teknolojiyi bilmekten ibaret olmadığını gösterdi.Doğru soruyu sormak, doğru yapıyı kurmak ve yanıtları iteratif şekilde geliştirmek; AI kullanımında en kritik yetkinlikler arasında.

Kadir Çubukçu’nun perspektifi, özellikle test, yazılım, ürün ve içerik ekipleri için uygulanabilir bir metodoloji sunuyor:
“Yapay zekâdan beklediğimiz verimi almak istiyorsak, önce doğru soruyu inşa etmeyi öğrenmeliyiz.”

3. Oturum: Yusuf Tayman & Eren Akyol :Prompt Refine Atölyesi

AI Weekend’in üçüncü oturumu, teorik kavramları pratiğe taşıyarak LLM’lerle çalışma biçiminin nasıl sistematik bir yönteme dönüşmesi gerektiğini ortaya koydu. Yusuf Tayman ve Eren Akyol’a göre etkili bir prompt, yalnızca bir isteği ifade eden metin değildir; aynı zamanda modelin nasıl düşüneceğini, hangi sınırlar içinde hareket edeceğini ve nasıl bir çıktı üretmesi gerektiğini tanımlayan yapısal bir talimattır.

Prompt Tasarımında 6 Kural: Teoriden Pratiğe

Mutlu Bey’in ve Kadir Bey’in anlattığı teorik çerçeve, bu oturumda somut örneklerle uygulamaya dönüştürüldü. Yusuf Bey ve Eren Bet, iyi bir prompt’un şu altı temel prensibe dayanması gerektiğini gösterdi:

1. Bağlam oluşturmak (Context)
2. Örnek göstermek (Example)
3. Format/çıktı kısıtları belirlemek (Constraints)
4. Görevi adımlara ayırmak (Steps)
5. Modelin önce düşünmesini istemek (Think-first prompting)
6. Modele rol tanımlamak (Role Assignment)

Bu altı ilke, yalnızca daha doğru sonuçlara ulaşmayı değil, AI ile çalışırken tekrar edilebilir ve istikrarlı bir yöntem geliştirmeyi de mümkün kılıyor.

1. Bağlam: Belirsiz Bir Soru, Belirsiz Bir Çıktı Üretir

Oturumun ilk uygulaması, katılımcılardan rastgele bir konu seçip önce bağlam vermeden, ardından bağlam ekleyerek iki farklı çıktı üretmeleriydi.
Amaç, bağlamın çıktı kalitesini nasıl dramatik şekilde değiştirdiğini gözle görünür hâle getirmekti.

Örnek:

• “İklim değişikliği hakkında bilgi ver.”
  → Model, genel tanımlar ve bilinen etkiler üzerinden ilerler.
• “Son 10 yılda tropikal bölgelerde tarımsal üretimi etkileyen üç iklim değişikliği faktörünü örnekleriyle birlikte açıkla.”
  → Çıktı daha spesifik, ölçülebilir ve doğrulanabilir hâle gelir.

Bu egzersiz, bağlamın yalnızca “ek bilgi” değil, modelin düşünce alanını belirleyen bir sınır olduğunu gösterdi.

2. Örnek Vermek: Modelin ‘Seviyeyi’ Doğru Anlamasını Sağlamak

Katılımcıların en sık yaptığı hatalardan biri, bir görevin nasıl ideal göründüğünü modele göstermemekti.
Eren Bey’in verdiği örnek, bu hatanın kod yazımı ve e-posta hazırlama gibi alanlarda ne kadar kritik olduğunu gösteriyordu:

“İyi bir çıktı istiyorsanız, modelin ‘iyi’ kavramını sizin nasıl tanımladığınızı bilmesi gerekir.”

Model, siz örnek vermedikçe doğruluk, tarz veya kalite standardınızı tahmin edemez.

3. Format ve Kısıtlar: Modelin Serbestlik Alanını Yönetmek

Format belirtilmediğinde LLM’lerin:

• gereksiz uzun çıktılar üretmesi,
• yanlış veri yapıları kullanması,
• istenmeyen tonlarda içerik oluşturması,
• halüsinasyona daha açık hâle gelmesi

çok doğal.

Bu nedenle katılımcılar, önce format tanımlanmamış hâliyle, ardından açık bir çıktı yapısı ekleyerek aynı görevi modele tekrar iletti. İki sonuç arasındaki fark, formatın model davranışını ne kadar belirgin biçimde yönlendirdiğini ortaya koydu.

Örneğin:

“Bir portföy sitesi tasarla”
→ Rastgele renkler, rastgele layout, değişken kalite.

“Tek sayfalık, modern, sunset renk paletli bir portföy tasarla. Bölümler: Hero, About, Skills, Projects, Contact. Navigasyon sticky olmalı.”
→ Tutarlı, öngörülebilir, yeniden kullanılabilir bir çıktı.

4. Karmaşık Görevleri Adımlara Bölmek: Hata Tespitinin En Etkili Yolu

Modelden karmaşık bir iş istenirken (ör. site tasarımı, rapor analizi, veri yorumlama) tek bir paragraf hâlinde komut verilmesi, modelin tüm adımları aynı anda yürütmeye çalışmasına neden oluyor.
Bu da:

• adımların karışmasına,
• mantık hatalarına,
• eksik veri kullanımına
  yol açıyor.

Yusuf Tayman’ın deneyimle aktardığı önemli nokta şuydu:

“Görevi adımlara böldüğünüzde, hatanın hangi adımda üretildiğini görebilir ve yalnızca o adımı düzelterek ilerleyebilirsiniz.”

Bu yaklaşım, AI ile çalışan teknik ekiplerin hata ayıklama süreçlerinde zaman kazanmalarını sağlıyor.

5. Modelden Önce “Düşünmesini” İstemek

“Think before you answer” yaklaşımı, özellikle analiz, değerlendirme ve problem çözme gerektiren görevlerde modelin performansını belirgin biçimde iyileştiriyor. Bu yöntemle model, doğrudan çıktı üretmek yerine önce içsel bir akıl yürütme süreci gerçekleştiriyor.

Bu ek düşünme aşaması, yanıtların:

• daha yapılandırılmış,
• tutarlılığı yüksek,
• hata oranı düşük

bir formda üretilmesini sağlıyor.

Uygulamalı örneklerde, bu tekniğin özellikle veri analizi, karar destek sistemleri ve çok adımlı mantık gerektiren görevlerde daha güvenilir sonuçlar ortaya çıkardığı gözlemlendi.

6. Modele Rol Tanımlamak: Beklentiyi Netleştirmek

Oturumda üzerinde durulan son ilke, LLM’in rolünü belirlemekti.
“Bir bilim öğretmeni gibi açıkla”,
“Deneyimli bir yazılım mühendisi gibi düşün”,
“Profesyonel bir UX tasarımcısı gibi geri bildirim ver”

gibi ifadeler, modelin hem tonu hem de detay düzeyini hedeflenen standarda yaklaştırıyor.

Bu yöntem, özellikle içerik üretimi, eğitim amaçları ve kod geliştirme süreçlerinde çıktı kalitesini doğrudan etkiliyor.

Gerçek Zamanlı Uygulamalar ve Karşılaştırmalar

Oturum boyunca katılımcılar:

• yemek tarifi oluşturma,
• öğrenme planı çıkarma,
• kod yazdırma,
• kişisel web sitesi tasarlatma

gibi farklı pratik görevlerde “before–after” karşılaştırmaları yaptı.
Her uygulama, modelin belirsizlikte çabaladığını, yapı verildiğinde ise beklenenden çok daha iyi performans sergilediğini gösterdi.

Sonuç: Prompt, Bir Komut Değil Bir Tasarım Süreci

Bu oturumun genel çerçevesi, prompt yazmanın tek seferlik bir talep değil; bir tasarım süreci olduğu yönündeydi.

Yusuf Tayman ve Eren Akyol’un aktardığı perspektif şu noktada birleşiyor:

İyi bir prompt, net bir hedefi olan, sınırları tanımlanmış, adımları belirli ve örneklerle desteklenmiş bir çalışma talimatıdır.

Böyle bir yapı sayesinde LLM’ler:

• daha az hata yapıyor,
• daha öngörülebilir sonuç üretiyor,
• iterasyon süreçleri daha az zaman alıyor,
• çıktı kalitesi daha yüksek oluyor.

Bu oturum, katılımcıların yapay zekâyı sadece kullanmakla kalmayıp, onu etkili şekilde yönlendirebilecek bir çalışma alışkanlığı edinmesini sağladı.

4. Oturum: Murat Polatcan : Kendi GPT’ni Tasarla

AI Weekend’in dördüncü oturumu, yapay zekâyı “kullanıcı” seviyesinden çıkarıp “üretkenlik mimarı” seviyesine taşıyan ayrı bir bakış açısı sunuyordu. Murat Polatcan, Custom GPT’lerin yalnızca ChatGPT’nin kişiselleştirilmiş sürümleri olmadığını; aslında bireyin kendi çalışma biçimini kodlaştıran, şirket süreçlerini modülerleştiren ve ekip içi uzmanlığı merkezileştiren yeni bir araç sınıfı olduğunu vurguladı.

Modern LLM modellerinin en büyük dezavantajlarından biri, “çok fazla şey bilmesi” nedeniyle dikkatin kolayca dağılabilmesi. Polatcan’ın ifadesiyle, standart ChatGPT geniş bilgi uzayı nedeniyle kimi zaman “fazla özgür” davranıyor. Custom GPT yaklaşımı ise modele adeta at gözlüğü takarak onu yalnızca belirli bir alanda çalışmaya zorluyor. Böylece hem tutarlılık hem de hız radikal şekilde artıyor.

Neden Custom GPT? Sadece Özelleştirme Değil, Operasyonel Kararlılık

Mutlu Bey’in altını çizdiği temel faydalar üç başlıkta toplanabilir:

• Tutarlılık:
  Birden fazla departmanın aynı karar süreçlerini takip etmesi gerekiyorsa, Custom GPT bu standartları otomatik olarak uygular. Böylece her kullanıcı — deneyimi ne olursa olsun — aynı kalite seviyesinde çıktı alır.
• Verimlilik:
  Modelin odak alanı daraldıkça yanıt süresi kısalır. Gereksiz bilgi aramaları, bağlam hataları ve halüsinasyonlar minimize edilir. Gerçek dünyada bu, %30 ile %70 arasında zaman kazancı anlamına geliyor.
• Paylaşılabilir uzmanlık:
  Bir şirketin ya da ekip liderinin bilgi birikimi, bir Custom GPT’ye gömüldüğünde, herkes aynı uzmanlık seviyesine erişebilir. Bu, operasyonel bilgi kaybını ortadan kaldıran ciddi bir avantaj.

“Model Çok Bildiği İçin Hata Yapıyor” — Paradoksun Çözümü

Oturumda en çok ilgi çeken bölümlerden biri, Mutlu Bey’in büyük modellerin neden hata üretebildiğine dair açıklamasıydı.

“Model aslında çok şey bildiği için zihni dağılıyor. Biz ona ‘sadece buraya bakacaksın’ demediğimiz sürece odaktan sapması doğal.”

Bu nedenle Custom GPT, modeli sınırlandırarak onu belirli bir görevde uzman hâline getiriyor. Örneğin yalnızca yemek tarifi veren bir GPT, başka bir konuya sapmadan hızlı ve doğru çalışıyor. Aynı model geniş bilgi alanında çalıştığında ise tahmin yüzeyi büyüdüğü için hataya daha açık hale geliyor.

Teknik Derinlik: GPT Tasarlamanın Gerçek Yapı Taşları

Mutlu Bey sunumunda GPT tasarımının 7 temel aşamasını ele aldı :

• Purpose (Amaç):
  GPT’nin tek bir alana yoğunlaşması şart. “Her şeyi bilen” bir GPT her zaman düşük performans gösterir.
• Instruction Set (Talimat Kurgusu):
  Modelin nasıl davranacağını belirleyen en kritik katman. Emir kipindeki net talimatların halüsinasyonu azalttığı vurgulandı.
• Knowledge Base (Bilgi Tabanı):
  Doğru yapılandırılmış PDF, Excel ya da kod dosyalarıyla GPT tamamen şirkete özel bir asistana dönüşebiliyor.
• Actions (Aksiyonlar):
  Web taraması, görsel üretimi veya Python yorumlayıcısı gibi ek yetenekler, GPT’yi basit bir asistan olmaktan çıkarıp aktif bir iş yürütücüsüne dönüştürüyor.
• Testing & Refinement (Test ve İyileştirme):
  Her GPT ilk denemede kusursuz olmaz; asıl ürün test sürecinde ortaya çıkar.

Gerçek Dünya Etkisi: 80% Daha Hızlı Müşteri Hizmetleri

Sunum boyunca sıkça geçen yoğun istatistikler, Custom GPT yaklaşımının pratik değerini net biçimde ortaya koydu:

• Müşteri hizmetlerinde %80 daha hızlı yanıt süresi
• Tekrarlayan görevlerde %30–70 zaman tasarrufu
• Kod incelemeleri ve raporlama süreçlerinde dramatik otomasyon verimleri

Bu veriler, Custom GPT’yi yalnızca bir “kişiselleştirme” aracı değil, işletme verimliliğini yeniden tanımlayan bir yapı olarak konumlandırıyor.

Sonuç: Yapay Zekâyı Kullanmanın Ötesine Geçip Kendi İş Akışını Tasarlamak

Bu oturum, AI çağında gerçek farkın yalnızca yapay zekâ araçlarını kullanmaktan değil, bu araçların nasıl çalışacağına dair kendi metodolojisini oluşturabilmekten geçtiğini ortaya koydu. Custom GPT’ler, bireylerin ve kurumların çalışma biçimini modele aktararak süreçleri daha tutarlı, tekrarlanabilir ve ölçeklenebilir hâle getiriyor. Böylece yapay zekâ, sadece destekleyici bir araç olmaktan çıkıp, iş akışlarının merkezine yerleşen stratejik bir bileşene dönüşüyor.

5. Oturum: Damla Karakoyun & Muhammed Çelebi ile Multimodal AI — Görsel ve Video Üretimde Yaratıcılığı Yeniden Tanımlamak

AI Weekend’in son oturumu, Damla Karakoyun ve Muhammed Çelebi’nin yürüttüğü multimodal AI atölyesiydi. Gün boyunca işlenen teknik içeriklerin ardından bu oturum, yapay zekânın yaratıcılık tarafını ön plana çıkararak oldukça keyifli bir atmosfer yarattı. Farklı görsel ve video modellerinin nasıl çalıştığını yalnızca teorik olarak anlatmakla kalmadı; katılımcıların bu araçları gerçek zamanlı olarak deneyimleyebileceği bir ortam oluşturdu. Böylece herkes, yapay zekânın prodüksiyon süreçlerini nasıl hızlandırdığını ve basit bir fikrin nasıl saniyeler içinde görsele ya da videoya dönüştüğünü birebir gözlemleme fırsatı bulduk.

AI ile Görsel ve Video Üretimi: İşçilikten Yaratıcılığa Geçiş

Muhammed Bey’in paylaştığı örneklerden birinde, geleneksel yöntemlerle haftalar sürebilecek bir süper kahraman temalı şirket içi projenin, AI araçları kullanılarak çok daha kısa sürede tamamlandığı anlatıldı. Karakter tasarımları Midjourney ile oluşturulmuş, Wan veya Veo 3 üzerinden kısa video sekansları üretilmiş, ardından minimal post-prodüksiyon işlemleriylekip içinde kullanılabilecek bir görsel-video çalışmasına dönüştürülmüş.Bu süreç, yapay zekânın görsel üretim ve video prodüksiyonundaki hız kazandırıcı etkisini net şekilde göstermesi açısından güzel bir örnekti.

Bu örnek, üretken yapay zekânın teknik iş yükünü azaltarak yaratıcı süreci hızlandırma potansiyelini net bir şekilde gösteriyordu. Damla Hanım, bu noktada AI tabanlı görsel ve video üretiminin deneme-yanılma temelli bir çalışma biçimi olduğunun altını çizdi. Tek seferde “ideal” sonuca ulaşmanın her zaman mümkün olmadığını; modelleri test etmek, farklı çıktıları karşılaştırmak ve gerektiğinde yeniden üretim yapmak gerektiğini belirtti.

Bu çalışma biçimi, özellikle fal.ai’nin sunduğu eş zamanlı model karşılaştırma imkânı sayesinde son derece pratik ve hızlı bir metodolojiye dönüşüyor.

Multimodal Araçların Gücü: Tek Prompt, Çok Sonuç

Oturumun son bölümünde fal.ai’nin sunduğu multimodal çalışma yapısı üzerinden, üretken yapay zekânın yaratıcı süreçlerde nasıl bir altyapıya dönüştüğü ele alındı. Aynı fikrin farklı modellerde eş zamanlı test edilebilmesi, katılımcılara görsel stil, kalite ve kompozisyon açısından hızlı bir karşılaştırma imkânı sağladı. Bununla birlikte görsel, video, efekt ve düzenleme adımlarının tek bir akış içinde birleştirilebilmesi; 3D varlık, avatar, kısa video veya sahne gibi farklı çıktı türlerinin aynı arayüzden yönetilmesi üretim sürecini oldukça bütüncül bir yapıya taşıdı.

Model maliyetlerini, üretim hızlarını ve çıktı kalitesini gerçek zamanlı kıyaslama olanağı ise bu yaklaşımın pratikte ne kadar güçlü olabileceğini gösterdi. Tüm bu özellikler bir araya geldiğinde, üretken yapay zekânın artık yalnızca yaratıcı bir araç değil, ekiplerin üretim süreçlerini taşıyabileceği tam teşekküllü bir prodüksiyon altyapısı hâline geldiği net bir şekilde ortaya çıktı.

Sonuç: Günü Eğlenceyle Birleştiren Yaratıcı Bir Kapanış

Muhammed Bey ve Damla Hanım’ın atölyesi, AI Weekend’in e en eğlenceli bölümü oldu.
Günün sonunda hepimiz yalnızca yeni araçlar öğrenmiş değil; aynı zamanda yapay zekâ ile üretmenin ne kadar hızlı, esnek ve keyifli olabileceğini birebir deneyimlemiş olduk. Aşağıdaki görsel, atölye sırasında benim de AI ile ürettiğim çalışmalardan birisi :)

2. Gün — 1. Oturum: Mutlu Polatcan ile Otomasyonun Temelleri

AI Weekend’in ikinci gününün açılışı, Mutlu Bey’in LLM tabanlı otomasyon mimarisine dair kapsamlı sunumuyla yapıldı. İlk gün modelleri anlamaya odaklanan katılımcılar, bu oturumla birlikte yapay zekânın iş akışlarında nasıl konumlandırılması gerektiğini, hangi metodolojinin izlenmesi gerektiğini ve otomasyon tasarımında hangi yapı taşlarının kritik olduğunu net bir şekilde görmüş oldu.

Mutlu Bey’e göre LLM çağında otomasyon; yalnızca tekrarlayan adımları mekanik olarak devreden çıkaran bir süreç değil, bağlamı anlayabilen, karar alabilen ve veriyi işleyerek eyleme dönüştürebilen akıllı iş akışlarının tasarlanmasıdır.

1. n8n ile Fonksiyonel Otomasyonun Yapı Taşları

Oturumun ilk bölümünde n8n’in görsel iş akışı mimarisi ele alındı. Mutlu Bey, platformun yalnızca uygulamalar arası bağlantı sağlayan bir araç olmadığını; doğru LLM entegrasyonuyla birlikte karar mekanizması içeren bir orkestrasyon katmanına dönüştüğünü vurguladı.

Katılımcılar şu temel kavramlar üzerinden ilerledi:

• Trigger: Süreci başlatan tetikleyici
• Nodes: İş mantığını oluşturan bileşenler
• Connections: Veri akışını yöneten dinamik bağlar

Bu yapı sayesinde e-posta sınıflandırmadan raporlama süreçlerine, doküman işlemekten içerik dönüştürmeye kadar pek çok senaryo birkaç node ile tanımlanabilir hâle geliyor.

2. LLM’lerin Otomasyona Eklediği Değer: Karar Mekanizması

Mutlu Bey, otomasyonun LLM öncesi ve sonrası arasındaki temel farkları net bir şekilde ortaya koydu. LLM öncesinde otomasyon büyük ölçüde kural tabanlı sistemlere dayanıyordu; süreçler yalnızca tanımlı koşullar gerçekleştiğinde ilerleyebiliyor ve çoğunlukla yapılandırılmış veriyle sınırlı kalıyordu. Esneklik düşük, yorumlama kapasitesi ise oldukça sınırlıydı.

LLM’lerle birlikte bu yapı önemli ölçüde değişti. Modeller artık:

• bağlamı anlama,
• yapılandırılmamış veriyi işleme,
• sınıflandırma ve özetleme,
• analiz yapma,
• gerektiğinde öneri üretme

gibi yeteneklerle otomasyona yeni bir katman ekleyebiliyor.

Bu gelişim, otomasyon kavramının artık yalnızca “uygulamaları birbirine bağlamak” anlamına gelmediğini; karmaşık girdileri değerlendirebilen ve buna göre karar üretebilen sistemlerin tasarlanabileceğini gösteriyor.

3. LLM Node Tasarımında Best Practices

Bu bölümü daha profesyonel hâle getirmek için özellikle derinleştirdim.
şağıda Mutlu Bey’in vurguladığı LLM node tasarımı için en kritik best practice’ler yer alıyor:

a) Görev Tanımı (Task Definition) Kesin Olmalı

• Belirsiz komut → belirsiz çıktı
• İşlevi tanımlayan kısa ve direkt talimatlar

b) Çıktı Formatı Mutlaka Yapılandırılmış Olmalı

LLM tabanlı otomasyonun en sık hata verdiği nokta budur.
Önerilen format:

• JSON
• Markdown tablo
• Liste yapılandırmaları

c) Prompta Aşırı Serbestlik Verilmemeli

• “Açıkla” yerine “Şu formatta açıkla”
• “Bir özet oluştur” yerine “200 kelimelik, 3 başlıklı özet oluştur”

d) Node İçinde Rol Ataması Yapılmalı

“Profesyonel bir sınıflandırma aracı gibi davran.”
LLM’in tonunu ve mantığını net biçimde sabitler.

e) Hata Yönetimi (Error Handling) Stratejisi Zorunlu

• Boş çıktı kontrolleri
• Retry mekanizmaları
• Alternatif yol (fallback) tasarımı

f) Input Kontrolü

Gereksiz uzun girdiler hem maliyeti artırır hem de model performansını düşürür.
“Prompt sanitization” bu nedenle kritik bir adımdır.

4. Sık Kullanılan Otomasyon Örüntüleri

Mutlu Bey, gerçek üretim ortamlarında sık karşılaşılan otomasyon örüntülerini metodolojik bir çerçevede sundu:

a) Sınıflandırma → Yönlendirme

Metin, e-posta veya destek taleplerinin LLM ile kategorize edilip ilgili departmana aktarılması.

b)İçerik Üretimi → Platform Optimizasyonu

Tek bir içerikten sosyal medya için farklı formatlarda otomatik varyasyon oluşturma.

c)Doküman İşleme → Veri Yapılandırma

Sözleşme, CV, fatura, akademik makale gibi belgelerden veri çıkarma ve tabloya dönüştürme.

d) Özetleme → Raporlama

Toplu verilerden günlük/haftalık rapor oluşturma.

e) Soru Cevap → Bilgi Tabanı Araması

Şirket içi dokümanlardan beslenen akıllı yanıt sistemleri tasarlama.

Her örnek, LLM + n8n entegrasyonunun gerçek hayattaki potansiyelini gösteren teknik bir çerçeve sundu.

5. Maliyet, Performans ve Doğruluk Arasında Optimum Dengeyi Kurmak

Mutlu Bey’e göre LLM tabanlı otomasyonun verimli olabilmesi için üç unsurun dengede olması gerekir:

a) Performans

Görev karmaşıklığına göre doğru modelin seçilmesi.

b) Maliyet

• Basit görevler: GPT-3.5 / Lokal modeller
• Karmaşık görevler: GPT-4 / Claude 3
• Ağır işleyişler için batching ve caching teknikleri

c) Doğruluk

• Model çıktılarını doğrulayan kontrol node’ları
• JSON-parsing temelli validasyon
• Ölçekli sistemlerde A/B test yaklaşımı

Bu yapı, üretim ortamında otomasyonun kararlı ve sürdürülebilir olmasını sağlar.

Sonuç: LLM Destekli Otomasyon Artık Bir Yetkinlik Alanı

Oturumun sonunda ortaya çıkan tablo çok netti:
LLM’lerle geliştirilen otomasyon sistemleri, klasik otomasyon anlayışından farklı bir disiplin oluşturuyor. Süreçler yalnızca otomatikleşmiyor; yapılandırılıyor, yönetiliyor ve karar verebilir hâle geliyor.

Mutlu Bey’in sunduğu metodoloji, katılımcılara yalnızca “bir otomasyon kurmayı” değil, sürdürülebilir ve profesyonel bir LLM otomasyon stratejisi geliştirmeyi öğretti.

2. Gün — 2.Oturum: Yusuf Tayman & Eren Akyol ile Uygulamalı Otomasyon Atölyesi LLM Tabanlı İş Akışları

İkinci günün pratik kısmında Yusuf Tayman ve Eren Akyol, LLM tabanlı otomasyonun gerçek hayatta nasıl kullanılabileceğini n8n üzerinde adım adım uygulayarak anlattı. Bu bölüm, özellikle iş akışı tasarımına yeni başlayanlar için kavramları somutlaştıran, teknik detayları ise uygulanabilir hâle getiren bir çalışma ortamı oluşturdu.

Amaç; tek bir LLM çağrısıyla sınırlı kalmayan, birden fazla veriyi toparlayıp yorumlayan ve farklı platformlara aksiyon üreten uçtan uca akıllı süreçler kurmaktı.

1. Slack Otomasyonu: Mesajları İşleyip Karara Bağlayan Akış

Atölyenin ilk senaryosu Slack üzerinden yapıldı.
Katılımcılar, Slack’ten gelen mesajları:

• çekip,
• LLM ile analiz edip,
• ilgili kanala yönlendiren

bir iş akışı tasarladı.

Bu akış sayesinde LLM:

• mesajı yorumladı,
• konusuna göre sınıflandırdı,
• formatlı bir çıktı üretti,
• Slack’e geri gönderdi.

Bu örnek, anlık iletişimde LLM’in yalnızca üretim için değil, karar destek unsuru olarak da kullanılabileceğini gösterdi.

2. Form → GPT → Mail Akışı: Dinamik Yanıt Üreten Bir Sistem

Bir diğer uygulamada, bir formdan gelen verilerin GPT tarafından işlenip otomatik olarak e-posta şeklinde iletildiği bir yapı kuruldu.
Bu akış şu adımlardan oluşuyordu:

1. Form verisinin n8n’e alınması
2. LLM’in veriyi analiz edip anlamlı bir yanıt oluşturması
3. Çıktının belirlenen formatta bir e-postaya dönüştürülmesi
4. Gmail node’u ile otomatik gönderim

Bu senaryo, müşteri talepleri ya da şirket içi formlar gibi tekrar eden süreçlerin LLM ile kişiselleştirilmiş ve tutarlı bir akış hâline gelebileceğini gösterdi.

3. API → GPT → Slack Akışı: Çoklu Veri Kaynağını Tek Çıktıya Dönüştürme

Atölyenin en öğretici bölümlerinden biri, birden fazla API kaynağından veri toplayıp bunları GPT ile tek bir bağlam altında birleştiren akıştı.

Katılımcılar:

• finans verisi,
• haber akışı,
• hava durumu,
• ilginç bir bilgi (ör. cat fact)

gibi farklı API çağrılarını tek bir Merge node’unda topladı.

Ardından bu veriler GPT’ye gönderildi ve model:

• tüm veriyi analiz etti,
• özet bir metin oluşturdu,
• Slack’e gönderdi.

Bu uygulama, LLM’in çoklu veri kaynağını tek bir anlamlı çıktıya dönüştürmekte ne kadar etkili olduğunu gösterdi.

4. Workflow Görselleri: Tasarım Mantığının Görsel Karşılığı

Eğitim boyunca kullanılan akışlar — paylaştığın görsellerdeki gibi — LLM tabanlı otomasyonun içindeki mantığı oldukça sade bir biçimde ortaya koyuyordu:

• API çağrıları
• birleştirme (Merge)
• LLM’in bağlamsal analiz yapması
• farklı platformlara sonuç gönderimi

Bu yapı, n8n’in LLM ile birleşince yalnızca entegrasyon değil, akıllı süreç orkestrasyonu sağlayabildiğini somut şekilde hissettirdi.

Sonuç: LLM ile Otomasyon, Pratik Uygulamayla Anlam Kazandı

Yusuf Tayman ve Eren Akyol’un yürüttüğü bu atölye, otomasyonun gerçek değerinin doğru kurgulanmış bir akışla ortaya çıktığını gösterdi.
Katılımcılar yalnızca örnek akışlar oluşturmadı; aynı zamanda:

• veri toplama,
• analiz ettirme,
• formatlama,
• dağıtım,
• platform entegrasyonu

gibi süreçlerin nasıl tek bir çatı altında birleştiğini deneyimlemiş oldu.

Bu bölüm, yapay zekânın iş akışlarını güçlendiren bir bileşen olduğunu değil onları yeniden tanımlayan bir mimariye dönüştüğünü gösteren güçlü bir deneyimdi.

2. Gün — 3.Oturum: Mutlu Polatcan ile Uygulamalı Colab Çalışmaları: LLM Davranışını Kod Üzerinden Anlama

İkinci günün teknik açılışında Mutlu Polatcan, LLM’lerle çalışırken temel kavramları yalnızca teorik seviyede anlatmakla kalmadı; Colab üzerinde paylaştığı beş farklı örnekle model davranışını doğrudan kod üzerinden gözlemlememizi sağladı. Bu bölüm, üretken modellerin nasıl çalıştığını anlamak isteyen katılımcılar için oldukça yol göstericiydi.

Mutlu Bey’in vurguladığı temel yaklaşım şuydu:

“Modeli anlamadan otomasyon kuramazsınız. Önce küçük örneklerde nasıl davrandığını gözlemlemek gerekir.”

1. Temperature ve Top-P: Modelin Kişiliğini Belirleyen Ayarlar

Mutlu Bey, temperature ve top-p’nin çoğu kişi tarafından göz ardı edildiğini, ancak model davranışını belirleyen en kritik parametreler olduğunu vurguladı.

• Düşük temperature: Daha tutarlı, otomasyona uygun çıktılar
• Yüksek temperature: Daha yaratıcı metinler
• Top-p daraltıldığında: Modelin olası seçenekleri azaltarak daha deterministik davranması

Bu ayarların ne kadar küçük değişikliklerle bile çıktıyı tamamen değiştirdiği Colab üzerinden canlı şekilde gösterildi.

2. Prompt’un Küçük Değişikliklerle Çıktıyı Tamamen Değiştirmesi

Colab örnekleri, beş kelimelik bir eklemenin bile modeli farklı bir yanıt tarzına yönlendirebildiğini gösterdi.

Mutlu Bey burada özellikle şuna dikkat çekti:

• Görev tanımı net değilse model de net değildir.
• Role assignment, bağlam ve kısıtlar net verilmeli.
• Gereksiz özgürlük modeli tahmin edilemez hâle getirir.

Bu nedenle prompt’ların otomasyonda “tasarım girdisi” olarak görülmesi gerektiğini belirtti.

3. JSON Çıktı Zorlaması: Otomasyonun Zorunlu Bileşeni

Mutlu Bey’in üzerinde en çok durduğu konulardan biri modelin JSON çıktısını her zaman düzgün üretmemesiydi.

Colab’daki örneklerde model:

• JSON’un dışına çıkabildi,
• açıklama eklemeye çalıştı,
• property eksiltebildi,
• tırnak hataları yapabildi.

Bu nedenle otomasyon kurarken mutlaka:

• JSON schema dayatılması,
• validasyon yapılması,
• hata yakalama mekanizmalarının kullanılması

gerektiğini vurguladı.

“Model mükemmel değildir. Mükemmelliği siz zorunlu kılarsınız.”

4. Multi-Turn Diyalog ve Context Window Yönetimi

Bazı Colab örneklerinde çok adımlı (multi-turn) konuşmalar gösterildi. Mutlu Bey şu noktayı açıkça belirtti:

“Modelin hafızası yoktur; ona verdiğinizden başka hiçbir şeyi hatırlamaz.”

Bu nedenle uzun süreçlerde:

• gereksiz içerikten kaçınmak,
• bağlamı sadeleştirmek,
• her adımda yeniden çerçeve çizmek

gibi teknikler üzerinde duruldu.

5. Kod Tarafında Modeli Tanımak, Otomasyonun Temeli

Son bölümde Mutlu Bey, bu beş Colab çalışmasının neden önemli olduğunu şu şekilde özetledi:

• Otomasyon kurarken modelin nasıl düşündüğünü bilmek şart.
• API çağrılarında beklenmedik davranışlar olabilir; sürprizleri ancak test ederek görürsünüz.
• “Küçük testler → davranış analizi → güvenli akış” üçlüsü, profesyonel çalışma yönteminin temelidir.

Bu anlayış, ikinci günün devamındaki Slack, Form → Mail, API → GPT → Slack gibi otomasyon örneklerinin altyapısını oluşturdu.

Sonuç: Kod Seviyesinde LLM Davranışını Gözlemlemek, Yöntemi Olgunlaştırdı

Mutlu Bey’in hazırladığı bu Colab seti, katılımcılara yalnızca model çıktısı üretmeyi değil, model davranışını yönetmeyi öğretti.
Bu bölümden sonra herkes LLM’lerin:

• nasıl karar verdiğini,
• nerelerde hataya açık olduğunu,
• hangi parametrelerin kritik olduğunu,
• otomasyon için neden validasyon gerektiğini

çok daha net bir şekilde anlamış oldu.

Bu çalışmalar, ikinci günün geri kalanındaki otomasyon oturumlarının teknik temelini oluşturdu.

2. Gün — 4.Oturum:Kadir Nuri Çubukçu ile Yapay Zekâda Bilgi Kalitesi ve Güvenilirlik

Haftasonunun son oturumu, Kadir Nuri Çubukçu’nun yapay zekâ sistemlerinde bilgi kalitesi ve doğrulama tekniklerine odaklanan sunumuyla tamamlandı. Gün boyunca otomasyon, workflow tasarımı ve çoklu ajan sistemlerini ele aldıktan sonra, bu oturum AI projelerinde sıklıkla göz ardı edilen ama profesyonel ölçekte kritik öneme sahip bir soruya yöneldi:

“Modelin ürettiği bilginin güvenilir olduğundan nasıl emin oluruz?”

Kadir Bey, yazılım test süreçlerinden gelen deneyimini üretken yapay zekâ bağlamına uyarlayarak, bilgi kalitesi konusunu teoriden uzak, tamamen pratik bir açıyla ele aldı.

Bilgi Kalitesinin Temel Boyutları

Sunumun giriş bölümünde bilgi kalitesini oluşturan beş ana boyut üzerinde duruldu:

• Doğruluk (Accuracy)
• Güncellik (Timeliness)
• Tamlık (Completeness)
• Tutarlılık (Consistency)
• Alaka Düzeyi (Relevance)

Bu yapı, LLM’lerin ürettiği çıktıları değerlendirirken “iyi hissettiren bir cevap” ile “gerçekten güvenilir bir bilgi” arasındaki farkı ayırt etmeye yardımcı olan temel çerçeve olarak sunuldu.

Kadir Bey’in ifadesiyle:
“Her bilgi kaliteli değildir. Kaliteyi biz tanımlar, biz kontrol ederiz.”

Yapay Zekâda Bilgi Kalitesi Problemleri

Oturumun devamında, LLM’lerin neden hatalı ya da yanıltıcı cevaplar üretebileceği örnekler üzerinden açıklandı.
Öne çıkan problem türleri:

• Yanlış veya tutarsız etiketleme
• Dengesiz veri kümeleri
• Gürültülü veriler
• Veri setindeki önyargılar (bias)
• Eski, geçerliliğini yitirmiş bilgiler
• Modelin eğitim verisinden kaynaklanan yanılgılar

Özellikle “kedilerin 6 bacağı olduğu” gibi absürt ama teknik olarak açıklanabilir hatalar, bu problemlerin günlük hayatta nasıl ortaya çıkabileceğinin iyi bir örneği olarak paylaşıldı.

Kalite Kontrol Teknikleri: Profesyonel Yaklaşım

Kadir Bey, bir AI kalite kontrol uzmanının günlük iş akışını sade ve anlaşılır şekilde kategorize ederek anlattı.
Bu süreçler:

1. Veri Ön İşleme (Preprocessing)

• Etiket tutarsızlıkları
• Görsel sınıflandırma anlaşmazlıkları
• Kaynak kalitesinin manuel kontrolü

2. Veri Doğrulama (Validation)

• Mantık hataları
• Tarih, yaş, sayı gibi alanların sınırlandırılması
• Tutarsız kayıtların tespiti

3. Veri Temizleme (Cleansing)

• Eksik veya hatalı veri tiplerinin ayrıştırılması
• Girdi formatlarının standardizasyonu

4. Veri Dengeleme (Balancing)

• Çok az görülen sınıfların iyileştirilmesi
• Aşırı temsil edilen sınıfların azaltılması

5. Bias (Önyargı) Kontrolü

• Veri hazırlayan kişiden modele taşınan yanlılık
• Kültürel, bölgesel veya toplumsal önyargıların filtrelenmesi

6. Human-in-the-loop Yaklaşımı

• Modelin emin olmadığı durumlarda insana devretme
• Kritik kararların hibrit şekilde yönetilmesi

Bu tekniklerin tümü, özellikle kurumsal seviyede LLM kullanımında güvenilirlik için zorunlu adımlar olarak ele alındı.

Gerçek Hayattan Mini Senaryolar: Halüsinasyonun Anatomisi

Sunumun en ilgi çekici kısmı, yapay zekâ sistemlerinin yaşadığı tipik bilgi hatalarının günlük örnekler üzerinden gösterildiği mini senaryolardı:

• Düz Dünya (Flat Earth) iddiaları
• Aşı-mikroçip komplo teorileri
• Güneş’in Dünya’nın etrafında döndüğü savı
• Deepfake videolar
• Klasik halüsinasyon örnekleri

Bu senaryolar üzerinden Kadir Bey, “modelin ikna edici görünmesinin doğru olduğu anlamına gelmediğini” belirterek, kullanıcıların teyit kültürünü güçlendirmesi gerektiğini vurguladı.

Sonuç: Bilgi Kalitesi, Model Kalitesinden Daha Temel Bir Konu

Oturumun kapanışında ortaya çıkan ana mesaj netti:

Yapay zekâ uygulamalarının güvenilirliği, modelin ne kadar gelişmiş olduğundan çok, kullanılan bilginin ne kadar kaliteli olduğuyla doğrudan ilişkilidir.

Kadir Nuri Çubukçu’nun sunduğu kalite kontrol perspektifi, hem otomasyon hem de çoklu ajan oturumlarında kurulan akışları düşünürken kritik bir bakış açısı kazandırdı.
Haftasonunun son oturumu olarak, AI projelerinde “üretmekten önce doğrulamayı öğrenmek” gerektiğini hatırlatan değerli bir kapanış niteliği taşıdı.

1.Hafta: LLM Temelleri ve Python ile NLP’ye Giriş

Bootcamp’in ilk haftasında, “LLM nedir?” sorusuna yanıt aradık. LLM’ler (Büyük Dil Modelleri), adından da anlaşılacağı gibi milyarlarca parametreye sahip devasa yapay zeka modelleridir. GPT ve BERT gibi modeller, insan dilini anlamak, üretmek ve işlemek için tasarlanmıştır. Bu modellerin temel mimarisi Transformer olarak bilinir ve paralel işlem yeteneği sayesinde yüksek performans sağlar.

Token’lar ve Tokenizer’lar: Makinelerin Dili

LLM’ler, metinleri en küçük yapı taşlarına, yani token’lara böler. Token’lar kelime, alt kelime veya karakter olabilir. Belki de ilk haftanın en önemli konularından biri token’lar oldu. Çünkü token’lar, modelin maliyetini ve işleme hızını doğrudan etkiler ve bir metnin sayısallaştırılma yöntemini gösterir.

Örnek olarak :

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("bert-base-uncased")
text = "Transformers are powerful LLMs!"
tokens = tokenizer.tokenize(text)
ids = tokenizer.convert_tokens_to_ids(tokens)

print("Tokens:", tokens)
print("Token IDs:", ids)

Bu kodu çalıştırdığımızda, "LLMs" kelimesinin "ll" ve "##ms" olarak ikiye ayrıldığını gördük. Bu, subword tokenization’ın bir örneğidir. "##" işareti, bir token’ın önceki token’ın devamı olduğunu gösterir. Bu yöntem sayesinde model, eğitim sırasında hiç karşılaşmadığı uzun veya karmaşık kelimeleri bile anlamaya çalışabilir.

Hugging Face: LLM’ler İçin Bir Kütüphane

Bootcamp boyunca büyük ölçüde Hugging Face platformunu kullandık. Bu platform, önceden eğitilmiş binlerce modeli indirmeyi ve kullanmayı kolaylaştırır. Özellikle pipeline() fonksiyonu, metin tamamlama, duygu analizi veya varlık tanıma gibi görevleri tek bir satırla yapmamızı sağlar. Örneğin, duygu analizi için:

from transformers import pipeline

classifier = pipeline("sentiment-analysis")
print(classifier("I love using large language models."))

Bağlam ve Embedding’ler: Kelimelerin Anlam Haritası

LLM’lerin en güçlü yanlarından biri, kelimelerin bağlamını anlamasıdır. Örneğin “En popüler yaz içecekleri” sorusundan sonra “Neden popülerler?” diye sorduğumuzda, model bu iki soru arasındaki ilişkiyi kurabilir. Bu bağlam, hem sistem prompt’ları hem de konuşma geçmişi gibi unsurlarla oluşturulur.

Her kelime, bir embedding vektörüne dönüştürülür. Bu vektörler, kelimelerin anlamsal özelliklerini içeren çok boyutlu sayı dizileridir. PCA (Temel Bileşen Analizi) kullanarak bu vektörleri görselleştirdik ve kelimelerin bağlamsal yakınlıklarını 2D bir grafikte gözlemledik. Örneğin, "the" kelimesi farklı bağlamlarda farklı konumlarda yer alırken, "sat" ve "on" gibi ilişkili kelimeler birbirine yakın duruyordu. Bu görselleştirme oldukça etkileyici ve öğreticiydi.

2. Hafta: Prompt Engineering ve OpenAI API Kullanımı

İlk haftada LLM’lerin temellerini ve Python ile ilk adımlarımızı attıktan sonra, ikinci haftada modellerden en iyi şekilde nasıl yararlanabileceğimizi öğrendik: Prompt Engineering ve Agent’lar. Bu hafta, LLM’lerin yalnızca metin üreten araçlar olmadığını, aynı zamanda belirli görevleri yerine getirebilen akıllı sistemler olduğunu keşfettik.

Prompt Engineering: Modelin Dilini Konuşmak

Prompt Engineering, bir modelden istediğimiz yanıtı alabilmek için doğru yönergeleri (prompt’ları) tasarlama sanatıdır. Bu yaklaşım, modeli baştan eğitmek yerine, mevcut yeteneklerini en etkili şekilde kullanmaya odaklanır.

Bootcamp’te üç temel prompt tekniğini öğrendik:

• Zero-Shot Prompting: Modele hiçbir örnek göstermeden doğrudan soru sorarız. Örneğin:
  "İklim değişikliği nedir?"
  Model, önceden öğrendiği bilgilerle yanıt verir.
• Few-Shot Prompting: Modelin yanıt formatını öğretmek için birkaç örnek sunarız. Örneğin:

Soru: Sera gazı nedir? 
Cevap: Atmosferde ısıyı tutan gazlardır.

• Bu sayede model, kalıbı öğrenir ve yeni sorulara benzer formatta cevap verir.
• Chain of Thought (CoT): Modelden cevaba ulaşmadan önce adım adım düşünmesini isteriz. Prompt’a "Düşün:" gibi bir ifade ekleyerek, modelin akıl yürütme sürecini dışa vurmasını sağlarız. Bu yöntem, karmaşık sorularda daha mantıklı ve açıklayıcı yanıtlar üretir.

Bu teknikler, aynı soruya farklı yaklaşımlarla nasıl değişik kalitede yanıtlar alınabileceğini net bir şekilde gösteriyor.

Agent’lar: LLM’ler İçin Akıllı Asistanlar

Prompt Engineering ile doğru yanıtı almayı öğrensek de, LLM’ler hâlâ yalnızca metinlerle sınırlıydı. İşte burada Agent’lar devreye giriyor.

Bir Agent, verilen bir görevi çözmek için elindeki araçları (tools) ne zaman ve nasıl kullanacağına kendi başına karar verebilen bir yapıdır.

• Agent (Akıllı Asistan): Ne yapacağına karar verir.
• Tool (Araç): Agent’ın kullanabileceği hazır bir işlevi olan fonksiyondur.

Örneğin: "İstanbul'da hava durumu nedir?" sorusu geldiğinde, Agent bu sorunun bir hava durumu sorgusu olduğunu anlar, uygun API aracını çağırır ve veriyi işleyerek kullanıcıya anlamlı bir yanıt sunar.

Bootcamp örneklerinden conversational_agent.py, bir Agent’ın konuşma geçmişini nasıl hafızasında tuttuğunu gösteriyor. "Fransa nerede?" sorusuna yanıt verdikten sonra "Başkentinde ne meşhur?" sorusu sorulduğunda, Agent bağlamı koruyarak doğru aracı çağırıyor ve ilgili cevabı buluyor.

LangChain: Agent’ların Hayatımızdaki Yeri

Bu akıllı sistemleri kurmak için LangChain gibi kütüphaneler kullanılıyor. initialize_agent fonksiyonu ile bir Agent’ı, ona vereceğimiz araçları ve kullanacağı LLM’i belirleyebiliyoruz. verbose=True parametresi ise Agent’ın düşünme ve aksiyon alma sürecini adım adım izlememizi sağlıyor.

Böylece LLM’ler artık sadece metin üretmiyor; dış kaynaklara erişebiliyor (Wikipedia, Google Search vb.), hesap yapabiliyor ve çok adımlı sorguları çözebiliyor.

İkinci haftanın sonunda, prompt tekniklerini ve Agent’ların nasıl çalıştığını uygulamalı olarak deneyimledik. Modelin yanıt kalitesini kontrol etmeyi ve bir LLM’i akıllı bir asistana dönüştürmeyi öğrendik.

Ödevimizde, bir prompt tekniği ile bir Agent’ı birleştirerek bir uygulama geliştirmemiz isteniyor.

Proje Linki : https://github.com/Severustark/book_summarizer_agent-

3. Hafta: Derinlemesine Hugging Face Transformers

LLM Bootcamp’in üçüncü haftasında, daha önce temel seviyede kullandığımız Hugging Face Transformers kütüphanesine daha derinlemesine daldık. Artık sadece hazır pipeline’ları kullanmakla kalmayıp, bir modeli kendi özel veri setimizle fine-tuning yapmayı ve bunu bir web arayüzü ile sunmayı öğrendik.

Haber Sınıflandırma Projesi

Haftanın en önemli uygulaması, Türkçe haber metinlerini kategorilere ayırmak için bir model eğitmekti. Önceden eğitilmiş bir Türkçe BERT modelini, özel bir haber veri seti üzerinde fine-tuning yaparak kullandık.

Projenin teknik detayları arasında şunlar öne çıktı:

• csv.field_size_limit: Uzun metin dosyalarında karşılaşılabilecek hataları önlemek için CSV okuma limitini yükseltmek.
• attention_mask: Modelin bir metin içindeki hangi token’lara odaklanacağını belirten maske.
• Epoch Sayısı: Modelin tüm veri setini kaç kez işleyeceğini gösterir. Epoch sayısını artırmak, modelin performansını yükseltir.

Bu adımlar sayesinde, genel amaçlı bir dil modeli olan dbmdz/bert-base-turkish-cased’i, Türkçe haber sınıflandırması gibi spesifik bir görevi başarıyla yerine getiren özel bir modele dönüştürdük.

CPU vs. GPU

Hocamız, model eğitimindeki kritik bir konuya değindi: CPU ve GPU farkları.

• CPU (Merkezi İşlem Birimi): Genel amaçlı görevler için tasarlanmış, seri işlemler yapan bir birim.
• GPU (Grafik İşlem Birimi): Binlerce çekirdeğe sahip ve paralel işlem yapabilme yeteneği ile yoğun matematiksel hesaplamaları çok hızlı gerçekleştirebiliyor.

LLM’ler gibi devasa modellerin eğitimi yoğun hesaplama gerektirir. Bu nedenle GPU, özellikle büyük veri setlerinde eğitim süresini kat kat hızlandırıyor.

Gradio: Modelleri Hızla Paylaşma

Eğittiğimiz haber sınıflandırma modelini test etmek için Gradio kullandık. Gradio, makine öğrenmesi modelleri için kolayca web arayüzleri oluşturmamızı sağlayan bir Python kütüphanesi. Birkaç satır kodla, metin girişi ve model çıktısını gösteren basit bir arayüz hazırladık. Bu sayede modelin çalışma mantığını kod yazmadan da gözlemleyebildik.

Haftanın projesi: Haber sınıflandırma örneği yerine, farklı bir model seçip Gradio ile bir arayüz oluşturmak istendi. Bu, tüm adımları yeni bir veri seti ve model üzerinde tekrarlamamızı gerektiren bir görevdi.

Bu hafta, LLM’lerin sadece bir “sihirli kutu” olmadığını, doğru araçlar ve veri setleriyle nasıl şekillendirilebileceğini somut olarak gördük.

Proje Linki : https://github.com/Severustark/character-morality-classifier

4. Hafta: RAG, Embedding ve Akıllı Arama

LLM Bootcamp’in dördüncü haftasında, modellerin kendi bilgi setlerinin ötesine geçerek harici kaynaklardan nasıl bilgi alabileceğini öğrendik. Bu hafta, modern LLM uygulamalarının en önemli mimarilerinden biri olan Retrieval-Augmented Generation (RAG) sistemlerine daldık.

Üç temel kavram etrafında çalıştık: Embedding, Vektör Veritabanları ve LangChain ile bunları bir araya getirmek.

RAG Nedir? LLM’lere Dış Kaynaklardan Bilgi Sağlamak

Büyük dil modelleri ne kadar bilgili olsalar da, eğitim verilerinden sonra olan güncel bilgilere veya özel belgelere erişimleri yoktur. İşte burada RAG devreye girer. RAG iki ana adımdan oluşur:

1. Retrieval (Bilgiyi Getirme): Kullanıcının sorusuna en uygun bilgiyi harici bir kaynaktan (PDF, web sitesi, Excel vb.) bulur.
2. Generation (Yanıt Üretme): Bulunan bilgiyi LLM’e bağlam olarak sunar ve modelin bu bağlama dayanarak doğru ve güncel bir yanıt üretmesini sağlar.

Bu yöntem, modelin yanlış bilgi üretme (halüsinasyon) olasılığını azaltır ve yanıtları daha güvenilir hâle getirir.

Embedding ve Vektör Veritabanları: Anlamın Sayısal Temsili

RAG sisteminin kalbinde Embedding ve Vektör Veritabanları bulunur.

• Embedding: Metinleri (kelime, cümle, paragraf) sayısal vektörlere dönüştürme işlemidir. Örneğin, “mutlu” ve “neşeli” gibi anlamsal olarak yakın kelimeler, vektör uzayında birbirine çok yakın konumlanır.
• Vektör Veritabanları: Bu sayısal vektörleri saklamak ve benzerliklerini hızlıca bulmak için özel olarak tasarlanmıştır.

Dersimizde iki önemli vektör veritabanını inceledik:

• FAISS (Facebook AI Similarity Search): Milyonlarca vektör içeren büyük ölçekli projeler için yüksek performanslı bir kütüphane.
• ChromaDB: LLM projeleri için optimize edilmiş, kullanımı kolay ve LangChain ile güçlü entegrasyona sahip bir çözüm.

LangChain: RAG Sistemini Kurma Aracı

Tüm bileşenleri bir araya getiren ve LLM uygulamalarını geliştirmeyi kolaylaştıran framework ise LangChain. Karmaşık ve çok adımlı yapıları basitleştirir.

LangChain ile bir RAG sistemi kurarken izlediğimiz adımlar şunlardı:

1. Dokümanları chunk’lara (parçalara) ayırmak.
2. chunk_overlap ile parçalar arasında anlam bütünlüğünü korumak.
3. Chunk’ları embedding modeline gönderip vektörlere dönüştürmek.
4. Vektörleri FAISS veya ChromaDB’ye kaydetmek.
5. Kullanıcı sorusu geldiğinde, sorunun vektörünü oluşturup veritabanında en benzer chunk’ları bulmak.
6. Bulunan chunk’ları LLM’e özel bir prompt ile vererek son yanıtı üretmek.

Haftanın projesi, öğrendiklerimizi uygulamaya dökmek için harika bir fırsattı. Geliştirmemiz gereken RAG sistemi, bir Excel dosyasındaki soru-cevap setine dayanıyordu. Sistem:

• Sorunun cevabı kendi bilgi setinde varsa yanıt veriyor.
• Yoksa OpenAI API’ye gidip doğru cevabı buluyordu.
• Önemli koşul: Sadece ilgili konudaki sorulara yanıt veriyor; alakasız sorularda cevap üretmiyordu.

Bu hafta, LLM’lerin yalnızca genel bilgiye değil, özel bilgi kaynaklarına da erişebildiğini ve bu sürecin arka planda nasıl işlediğini gördük. LangChain gibi araçlar sayesinde karmaşık sistemleri kurmanın ne kadar kolay olduğunu görmüş olduk.

Proje linki : https://github.com/Severustark/qa-with-books

5. Hafta: LangChain ile Uygulama Geliştirme

LLM Bootcamp’in beşinci haftası, şimdiye kadar öğrendiğimiz tüm bilgileri bir araya getirerek gerçek dünya uygulamaları geliştirmeye odaklandığımız bir hafta oldu. Haftanın yıldızı, LangChain’in temel yapı taşları olan Chain, Agent, Tool ve Memory kavramlarının canlı bir senaryoda nasıl kullanılabileceğiydi.

LangChain’in Yapı Taşları: Chain, Memory ve Agent

Karmaşık LLM uygulamaları oluşturmak için kullandığımız ana bileşenler şunlardı:

• Chain (Zincir): Birden fazla LLM çağrısını veya aracı, belirli bir sırayla arka arkaya çalıştıran yapı. Örneğin, bir metni özetlemek ve ardından bu özete dayanarak bir soru sormak gibi adımları otomatikleştirebilir.
• Memory (Bellek): LLM’lerin konuşma geçmişini hatırlamasını sağlar. Tıpkı ChatGPT gibi, model önceki konuşmalardan bağımsız yanıtlar vermek yerine, sürekli ve akışkan bir diyalog kurabilir.
• Agent (Ajan): LLM’in hangi aracı (Tool) ne zaman kullanacağına kendi başına karar vermesini sağlar. Karmaşık ve çok adımlı görevlerde (ör. e-ticaret asistanı) performans ve maliyet avantajı sağlar.

Streaming, model yanıtlarının parça parça gelmesini sağlar ve kullanıcı deneyimini iyileştirir. Normal bir LLM’de, model tüm cevabı üretene kadar beklenirken, streaming sayesinde yanıt anında akmaya başlar. Bu, özellikle uzun metinler veya çok aşamalı işlemler için sistemin daha hızlı ve duyarlı hissettirmesini sağlar.

E-ticaret Asistanı Senaryosu:

Haftanın en önemli uygulaması, bu kavramların bir araya geldiği e-ticaret asistanı projesiydi. Bu projede bir LLM’i (GPT-4) çeşitli araçlarla donattık:

• akilli_urun_onerisi: Kullanıcının tercihlerine göre ürün önerir.
• siparis_takibi: Sipariş numarasına göre durum sorgular.
• kullanici_profili_goster: Kullanıcının geçmişini ve tercihlerini listeler.
• baglam_takip: Son konuşmanın konusuna göre akıllı cevaplar üretir (örn. “değer mi?” sorularını yanıtlar).

Agent, kullanıcının sorusuna göre hangi aracı kullanacağını kendisi seçiyordu. Örneğin, "telefon öner" denildiğinde akilli_urun_onerisi, "12345 siparişim nerede?" denildiğinde ise siparis_takibi çağrılıyordu. Böylece LLM, sadece bir sohbet robotu değil, belirli görevleri yerine getirebilen bir “ajan” hâline geliyordu.

Haftanın ödevi, önceki haftada öğrendiğimiz RAG sistemini, Makine Öğrenimi dokümanlarıyla geliştirmekti.

Adımlar şunlardı:

1. Dokümanları Yükleme ve Parçalama: PDF veya metin dosyasındaki makine öğrenimi terimlerini parçalara ayırmak.
2. Embedding Oluşturma: Her terimi sayısal vektöre dönüştürmek.
3. Vektör Veritabanına Ekleme: Vektörleri FAISS veya ChromaDB’ye kaydetmek.
4. RAG Zincirini Kurma: Kullanıcının sorusunu vektör veritabanıyla eşleştirip ilgili doküman parçasını LLM’e göndermek.

Böylece sistem, sadece genel bilgilerle değil, kendi beslediğimiz özel bilgilerle de akıllıca yanıt verebiliyordu. Bu, sürekli API çağrısı yapmanın maliyetini azaltmak ve modeli kendi veri tabanımızla özelleştirmek için kritik bir adımdı.

Bu hafta, LLM’lerin sadece metin üretmenin ötesine geçip, gerçek dünyada işe yarayan karmaşık uygulamaların merkezinde nasıl konumlandığını gösterdi

Proje linki : https://github.com/Severustark/ml-mentor

6. Hafta: LLM’lerde Fine-Tuning ve Kişiselleştirilmiş Inference

Büyük Dil Modelleri (LLM’ler) devasa veri setleri üzerinde eğitilmiş olsalar da, bazen şirketinizin özel ihtiyaçlarına veya spesifik bir göreve uygun hâle getirilmeleri gerekir. İşte bu noktada Fine-Tuning (İnce Ayar) devreye girer. Hazır eğitilmiş bir modelin tüm ağırlıklarını güncellemek yerine, onu belirli bir veri setiyle yeniden eğiterek tamamen kendi işinize özel bir model oluşturabilirsiniz.

Bu haftanın ana odak noktaları, fine-tuning süreçlerini verimli hâle getiren yöntemler ve modelin nihai kullanım aşaması olan inference üzerineydi.

Fine-Tuning ve PEFT (Parameter-Efficient Fine-Tuning)

• Fine-Tuning: Modelin tüm katmanlarındaki ağırlıkların, belirli bir görev için yeniden eğitilmesi. Yüksek performans sağlar fakat maliyetli ve zaman alıcıdır.
• PEFT (Parametre Verimli Fine-Tuning): Tüm parametreleri güncellemek yerine, sadece az sayıda parametre ekleyerek veya değiştirerek modeli yeniden eğitme yöntemi. LoRA (Low-Rank Adaptation) da buna örnektir.

Optimizer (Optimizasyon Algoritması)
Modelin çıktıları ile gerçek etiketler arasındaki farkı (loss) en aza indirmek için ağırlıkları günceller. Her adımda kaybı azaltacak şekilde küçük adımlar atar.

Attention Mask (Dikkat Maskesi)
Transformer’larda, modelin hangi token’lara odaklanacağını kontrol eder. Dolgu (padding) tokenlarını göz ardı edip sadece gerçek metin tokenlarına dikkat edilmesini sağlar.

Inference (Çıkarım)
Eğitilmiş modelin, daha önce görmediği verilere tahmin yapma sürecidir. Metin üretmek, duygu analizi yapmak veya görüntüde nesne tanımak gibi işlemler inference aşamasında gerçekleşir.

Ödev Analizi:Bu kod, temel bir modelin ve üzerine eklenmiş kişiselleştirilmiş PEFT modelinin nasıl yükleneceğini ve inference için nasıl kullanılacağını gösterir.

Kodun ana adımları:

1. load_base_model(): GPT-2 gibi temel modeli yükler ve tokenizer ile generation_config tanımlar.
2. load_personalized_model(): PEFT ile eğitilmiş adaptör katmanlarını yükler. Başarılı olursa model kişiselleştirilmiş şekilde çalışır.
3. create_personalized_prompts(): Test senaryolarına uygun özel prompt’lar oluşturur.
4. batch_inference(): Hazırlanan prompt’lar üzerinden toplu tahminler üretir.
5. analyze_generation_quality(): Üretilen çıktıları analiz eder ve kalite metriklerini hesaplar.
6. save_results(): Tahmin sonuçlarını JSON dosyasına kaydeder.

Kişiselleştirme ve Kullanım:

• Prompt’ları kendi senaryonuza göre özelleştirin (örn. "Finansal danışmanım olarak yatırım tavsiyesi ver").
• Kalite analizini geliştirmek için doğruluk veya uygunluk gibi ek metrikler ekleyebilirsiniz.
• Çalıştırdıktan sonra sonuçları JSON dosyası veya konsol çıktılarıyla paylaşabilirsiniz.

Bu adımlarla, fine-tuning ve inference süreçlerini teorik değil, pratik bir örnek üzerinden deneyimlemiş oluyorsunuz. LLM’leri kendi ihtiyaçlarınıza uygun hâle getirerek, onları sadece genel amaçlı değil, gerçekten işlevsel ve kişiselleştirilmiş araçlar hâline getirebilirsiniz.

Proje linki : https://github.com/Severustark/personalized_inference

7. Hafta: LLM Dağıtımı ve Uygulama Entegrasyonu

Bu hafta, LLM’lerin sadece model olarak değil, uçtan uca bir proje olarak nasıl geliştirileceğini ve dağıtılacağını öğrendik. Dersin temelinde, bir PDF dosyasından soru-cevap yapabilen bir RAG (Retrieval-Augmented Generation) sistemi geliştirmek vardı ve bu sistem için web arayüzü (Streamlit) ile API (FastAPI) entegrasyonu yapıldı.

Projeyi farklı ortamlarda sorunsuz çalıştırmak için Docker kullanıldı ve Docker imajı oluşturuldu. Bu sayede uygulamayı paketleyip kolayca dağıtabilmek mümkün oldu.

Temel Kavramlar ve Araçlar

• Docker: Uygulamayı bağımlılıklarıyla birlikte bir konteyner içinde paketler. docker komutuyla imaj oluşturulur; docker-compose.yml ise birden fazla servisi tek komutla yönetmeyi sağlar.
• FastAPI: Yüksek performanslı ve modern web API’leri oluşturmak için kullanılan Python kütüphanesi.
• Endpoint: API’nin belirli bir işlevi gerçekleştirmek için erişilebilen adresleridir (örn. /analyze, /upload).

HTTP Metotları:

• GET: Sunucudan veri almak için kullanılır; veri URL üzerinden görünür.
• POST: Sunucuya veri gönderir; veri isteğin gövdesinde gizli şekilde iletilir.
• Uvicorn: Asenkron çalışan Python web sunucusu; FastAPI projelerini çalıştırmak için kullanılır.
• .env dosyası: API anahtarları gibi hassas bilgileri güvenli şekilde saklamak için kullanılır.
• app klasörü: Ana uygulama kodu ve endpoint’lerin bulunduğu klasördür (main.py vb.).
• schemas.py: Pydantic ile API’den gelen ve giden verilerin yapısını tanımlar.
• Swagger UI: API’nin interaktif dokümantasyon arayüzü; http://localhost:8000/docs üzerinden test edilebilir.
• CORS (Cross-Origin Resource Sharing): Farklı domain’lerden gelen isteklerin API’ye erişimine izin verir.

Bu haftanın projesi , kendi belirlediğiniz bir LLM uygulamasını FastAPI kullanarak küçük bir API hâline getirmekti.

Bu ödev, LLM modellerini uçtan uca bir projeye entegre etme, API ve web arayüzü ile dağıtma sürecini deneyimlemek için mükemmel bir fırsattı.

Proje linki :https://github.com/Severustark/llm_fastapi_app

8. Hafta: Agent Sistemlerinde Protokoller ve Streamlit Entegrasyonu

Büyük LLM bootcamp’inin son haftasında, çoklu agent sistemlerinde protokoller ve iletişim mekanizmaları üzerinde yoğunlaştık. Bu hafta, agent’ların birbirleriyle veya dış sistemlerle güvenli ve standart bir şekilde etkileşim kurmasını sağlayan MCP (Model Context Protocol) ve A2A (Agent-to-Agent) Protokolünü öğrendik.

MCP (Model Context Protocol):
MCP, yapay zeka modelleri ile dış sistemler arasında güvenli ve standart bir iletişim protokolüdür. Adeta bir “ortak kutu” görevi görür; agent’ların birbirleriyle veya dış araçlarla iletişim kurmasını sağlayan temel veri formatını tanımlar.

Ne Zaman Gerekir?

• Birden fazla agent aynı görevi paylaşması gerektiğinde.
• Agent’ların bağlam (context) ve durum bilgisini sürekli güncellemesi gerektiğinde.
• Veritabanı erişimi veya API çağrıları gibi dış sistemlerle güvenli bir şekilde etkileşim kurulması gerektiğinde.

Schema:
schemas.py dosyasında tanımlı olan schema yapısı, MCP’nin temelini oluşturur. Mesajların hangi veri tipinde ve formatta olacağını belirler, tip güvenliği sağlar.

A2A (Agent-to-Agent) Protokolü:
A2A, birden fazla AI agent’ı arasında veri paylaşımı ve haberleşme protokolüdür. MCP gibi veri formatını standartlaştırır, ancak özel olarak agent’ların birbirine görev vermesi ve sonuçları aktarması için tasarlanmıştır.

Ne Zaman Gerekir?

• Karmaşık bir görevi birden fazla uzman agent’a bölmek istediğinizde (ör. araştırma, analiz ve raporlama agent’ları).
• Sisteminizin ölçeklenebilir ve hataya dayanıklı olmasını istediğinizde.
• Agent’lar arasında paralel işlem yapılması gerektiğinde.

Agent Haberleşme Bileşenleri

schemas.py dosyasındaki A2AMessage sınıfı, agent’lar arasındaki mesajlaşmanın temel bileşenlerini tanımlar:

• sender (Gönderen): Mesajı yollayan agent.
• receiver (Alıcı): Mesajın hedefi olan agent.
• task (Görev): Agent’ın hangi görevi yerine getireceğini belirten ana eylem.
• payload (Veri): Görevin yerine getirilmesi için gerekli detaylı veriler.

Bu hafta ödevimiz, çoklu agent projesine Streamlit eklemekti. Streamlit, veri uygulamaları ve etkileşimli arayüzler oluşturmayı kolaylaştıran bir Python kütüphanesidir.

Amaç:

• Agent’ların çalışma sürecini görselleştirmek.
• Kullanıcının agent’lara komut vermesini sağlamak.
• Analiz sonuçlarını kullanıcı dostu bir rapor şeklinde sunmak.

FastAPI’de tanımladığımız endpoint’ler, Streamlit arayüzünden çağrılabilecek API’ler olarak hizmet verdi. Böylece kullanıcılar, web arayüzü üzerinden agent’larla etkileşime geçebildi ve sistemin işleyişini gerçek zamanlı gözlemleyebildi.

Bu hafta Insider’daki staj sürecimizde, bize verilen backend path’ni başlamakla birlikte teknik anlamda oldukça verimli bir dönem geçirdik. Grup arkadaşlarımla birlikte hem proje üzerinde aktif bir şekilde çalıştık hem de teknik konularda bilgi paylaşımında bulunduk. Bununla birlikte, Emin Bey’in verdiği UX 101 eğitimi sayesinde yazılım geliştirme sürecine yalnızca teknik açıdan değil, aynı zamanda kullanıcı odaklı bir bakış açısıyla yaklaşmayı da öğrendik. Kullanıcının ihtiyaçlarını anlamak, deneyimlerini ön planda tutmak gerektiğini görmek benim için oldukça ufuk açıcıydı. Bu yazıda, bu haftaki deneyimlerimin bir özeti olarak özellikle Docker ve Kubernetes teknolojilerinden edindiğim bilgileri sizlerle paylaşmak istiyorum.

DOCKER

“It works on my machine.”

Eskiden uygulamaları deploy etmek çok daha karmaşık ve zordu. Neden?
Çünkü, örneğin bir Java uygulamanız var: Java kuracaksınız, environment ayarlayacaksınız, portları ayarlayacaksınız vs… Lokalde çalışıyor fakat başka bir ortama geçtiğimizde, o ortam daha önceden hazırlanmış, yani hazır bir setup’a sahip olmadığı için patlıyor ya da patlayabiliyor.

Bu klasik bir hikâyedir. Ortam bağımlılığına çözüm olarak containerization dediğimiz yaklaşım ortaya çıkıyor. Bu aynı zamanda cloud devrimi ile birlikte yaşanıyor.

Docker’dan önce de sanal makineler (virtual machines — VM’ler) vardı. Buna virtualization diyoruz. Ancak Docker dediğimiz şey aslında sadece bir platformdur. Ne bir teknoloji icat etti, ne de sıfırdan bir şey yarattı.

Containerization dediğimiz şey zaten daha önceden vardı. Örneğin Linux Containers (LXC). Ancak bu oldukça zahmetliydi çünkü manuel olarak konfigüre ediliyordu.

Docker Ne Yaptı?

Aslında bir developer experience devrimi yaptı. Ne yaptı?

Docker:

• Zaten var olan arka plandaki daemon’ları,
• CLI (komut satırı arayüzü),
• API,
• Ve en önemlisi kullanıcı deneyimi (UX) ile
  birleştirerek geliştiricilerin containerization dediğimiz şeyi çok daha rahat, basit ve etkili bir şekilde kullanmasını sağladı.

Ne İşe Yarıyor?

Uygulamanızı hızlıca build edebiliyor, test edebiliyorsunuz.
İster development ister production ortamı olsun, her ortamda stabil bir build elde ediyorsunuz.Yani artık :

“It works on my machine” → “It works on your machine too.”

Container Runtime Nedir?

Container runtime, imajları arka planda çalışan proseslere (container prosesleri) dönüştüren çekirdektir.Biz image yazıyoruz, Dockerfile’lar yazıyoruz, bunlar image’lara dönüşüyor. Ve container runtime da bu image’ları aktif proseslere çeviriyor.

Docker Ne Değildir?

Şunu sorarak başlayalım: Docker nedir, ne değildir?

• Docker, Linux kernel’a yeni bir özellik getirmiyor.
• Yeni bir sistem üretmedi.
• Container fikrini de icat etmedi.

Peki ne yaptı?

Linux kernel’da hali hazırda bulunan bazı mekanizmaları (örneğin namespaces ve cgroups) kullanarak bunları geliştiricilerin kolayca kullanabileceği hâle getirdi.

Linux zaten LXC (Linux Containers) diye bir teknolojiyi barındırıyordu.

• Namespaces → Her container kendi dosya sistemi, ağı, kullanıcıları vb. ile tamamen izole olur. Buna process isolation denir.
• Cgroups → Her container’ın ne kadar kaynak kullanabileceğini tanımlar (örn. %10 CPU, belirli miktarda RAM vs).

Docker bu mekanizmaları bir araya getirerek developer-friendly bir format sundu.

Ürünleştirme (Productization) ve Devrim

Buradaki asıl devrim, bu fikrin ürünleştirilmesiydi .Yani teknik bir konsepti, geliştiricilerin kolayca kullanabileceği bir ürüne dönüştürmek.

Bu devrim de, tam anlamıyla cloud devrimi ile birlikte geldi.

Virtualization’dan Containerization’a

1960–2000: Her şey fizikseldi : Eskiden, şirketler her bir görev için ayrı bir fiziksel sunucu kullanıyordu:

• E-posta sunucusu,
• Veritabanı sunucusu,
• Web sunucusu…

Bu çok kötü bir kaynak kullanımıydı çünkü sunucuların genelde sadece %10–15’i aktif kullanılıyordu. Geri kalanı boşuna çalışıyordu.

Üstelik:

• Dependency Hell yaşanıyordu. Örneğin bir uygulama PHP 5.6 istiyor, diğeri 8.0… Aynı OS üzerinde bunları çalıştırmak zor.
• Port Conflict yaşanıyordu. İki uygulama aynı portu kullanmak istiyorsa? Olmaz.
• Güvenlik açıkları büyüyordu. Bir uygulama hacklenirse, aynı OS üzerinde çalışan diğerleri de riske giriyor.

Virtual Machine (VM) Devri

Çözüm olarak virtualization geldi.Hypervisor denen yazılımlar, tek fiziksel makine üzerinde birden fazla sanal makine (VM) çalıştırmayı mümkün kıldı.

Her VM:

• Kendi işletim sistemine (Windows/Linux)
• Kendi CPU/RAM/Disk/Network kaynaklarına
  sahipmiş gibi davranır.

Bu yaklaşım tam bir machine isolation sağlar. Ama…

VM’lerin Sorunları

• Her VM ayrı bir OS içerdiğinden:
• Boyutları çok büyüktür (GB’larca).
• Boot süresi uzundur (3–5 dakika).
• Performans overhead’i %20–30’dur.

Bu yüzden:

• Her microservice için ayrı bir VM açmak mümkün değil.
• Netflix gibi firmalar microservice mimarisine geçtiklerinde bu sınırlamalara takıldılar.

Docker ile Container Devri

İşte tam burada Docker sahneye çıktı.Kendi yazılımımızı bir image olarak build edebiliyor, bunu saniyeler içinde ayağa kaldırabiliyoruz.

• Container’lar, tek bir Linux kernel üzerinde çalışır.
• Kendi OS’leri yoktur.
• User-space seviyesinde izole edilirler.
• Saniyeler içinde çalışır duruma gelirler.
• Boyutları küçüktür (100–200 MB).
• Overhead oranı çok düşüktür (%1–2).

Docker ile Gelen Güç

• Bir kere yazarsınız, her yerde çalıştırırsınız.
• Dockerfile yazar, image build eder, her ortamda aynı sonucu elde edersiniz.
• DevOps kültürüne çok uygundur:
• Continuous Integration / Continuous Deployment (CI/CD)
• Günde onlarca kez deploy yapabilme
• Hızlı iterasyon

Peki Ya Bugün?

• Günümüzde hâlâ bazı sektörlerde (örneğin yüksek güvenlik gerektiren finans, savunma sanayii gibi) VM kullanımı devam ediyor.
• Ancak modern cloud-native uygulamalar, microservice mimarileri neredeyse tamamen container’lar üzerinden çalışıyor.

Neden Docker Başarılı Oldu?

Docker:

• Basit bir CLI + API + UX deneyimi sundu.
• Tek bir Dockerfile ile logic yazmanıza imkân tanıdı.
• Build → Ship → Run sürecini devrim niteliğinde basitleştirdi.
• Cloud devrimi ile birleşerek modern yazılım dağıtımının temeli oldu.

İşte bu yüzden:
Docker sadece bir araç değil, bir zihniyet değişimi, bir devrim.

Docker Temel Terimler Rehberi :

Image :
Uygulamanın çalışması için ihtiyaç duyduğu bütün bileşenleri içeren bir pakettir. ISO dosyası gibi düşünebilirsiniz. Örneğin PHP geliştirme ortamı için PHP, MySQL, phpMyAdmin ve Apache gibi bileşenlerin birlikte bulunduğu bir image gerekir.

Docker Engine & Docker Daemon :
Docker Engine, image’lardan container oluşturmayı sağlayan çekirdektir. Docker Daemon ise bu işlemleri arka planda gerçekleştiren servis yapısıdır. Komut verildiğinde image’tan bir container üretmek bu sistemler sayesinde gerçekleşir.

Container :
Docker Engine’in image’tan ürettiği, içinde uygulamanın çalıştığı izole yapıdır. Sanal makineler gibi davranır ama çok daha hafif ve hızlıdır. İçinde kod çalıştırabilir, servisleri ayağa kaldırabilirsiniz.

Network & Çoklu Container :
Farklı container’lar (örneğin Apache ve MySQL) aynı Docker ağı (network) içinde haberleşebilir. Bu sayede servisler modüler ve izole hâlde çalışırken, birbirlerine erişim sağlayabilirler.

Dockerfile :
Kendi özel image’ınızı oluşturmak için yazdığınız tarif dosyasıdır. İçine hangi komutların çalışacağını, hangi dosyaların kopyalanacağını, hangi base image kullanılacağını yazabilirsiniz. RUN, COPY, CMD gibi komutlar içerir.

Docker Compose :
Birden fazla container’ı tek bir yapı (kompozisyon) olarak yönetmenizi sağlar. Örneğin veritabanı, backend ve frontend servislerinizi tek bir docker-compose.yml dosyası ile aynı anda başlatabilir veya durdurabilirsiniz.

Docker Hub :
Docker image’larının paylaşıldığı merkezi havuzdur. Başkalarının hazırladığı image’ları buradan çekebilir, kendi image’larınızı buraya push edebilirsiniz. App Store mantığıyla çalışır.

Volume :
Container silindiğinde içindeki veriler de silinir. Verilerin kalıcı olmasını istiyorsanız volume kullanmalısınız. Volume’ler, container’dan bağımsız olarak veri saklamanızı sağlar.

Kubernetes Nedir?

Kubernetes, mikroservis mimarisi kullanan geliştiricilerin adeta bir kurtarıcısı; öte yandan monolitik mimari ile çalışan geliştiriciler için pek de ihtiyaç duyulmayan bir teknoloji olarak görülür. Aslında uzun yıllar boyunca hepimiz monolitik yapılarla projeler geliştirdik, bu nedenle Kubernetes gibi bir teknolojinin eksikliğini çok da hissetmedik.

Monolitik Mimari Ne Demek?

Monolitik mimari, yazılımın tüm bileşenlerinin tek bir proje çatısı altında bulunduğu bir yapıdır.Günümüzde hâlâ yaygın şekilde kullanılmaktadır. Örneğin, Laravel gibi bir framework ile geliştirmeye başladığınız projelerin çoğu büyük olasılıkla monolitik olacaktır.

Burada Laravel gibi framework’lerin direkt olarak monolitik olduğunu söylemiyoruz; demek istediğimiz şey şu: Eğer standart ve küçük-orta ölçekli bir proje geliştiriyorsanız, bu genelde monolitik bir yapıya sahip olacaktır.Herkesin bildiği örneklerden biri: WordPress. WordPress başlı başına klasik bir monolitik yapıdır.

Monolitik Yapının Sınırları Nerede Başlar?

Projeniz büyüdükçe ve daha fazla kullanıcı tarafından kullanılmaya başlandıkça, bakım ve dağıtım süreçleri gittikçe karmaşık hâle gelir.
Örneğin kullanıcı kayıt kısmında bir değişiklik yapmak istiyorsanız, tüm projeyi tekrar deploy etmeniz gerekebilir.

Aynı şekilde, tek sunucuda çalışan uygulamanız bir süre sonra yetmemeye başlar ve ikinci bir sunucuya ihtiyaç duyarsınız. Monolitik yapılarda bu tür durumlarda genellikle dikey ölçeklendirme tercih edilir.
Yani RAM veya CPU artırımı gibi çözümlerle sistem güçlendirilir. Bu da yeterli gelmediğinde yatay ölçeklendirme yapılır ama esnekliği sınırlıdır.

Mikroservis Mimarisi: Neden Geçiş Yaptık?

Monolitik yapılar karmaşıklaştıkça, geliştiriciler daha esnek bir yapı aramaya başladı.İşte burada mikroservis mimarisi devreye giriyor.
Mikroservis mimarisi, büyük ve karmaşık sistemleri küçük, bağımsız servisler hâline bölerek geliştirme yöntemidir.

Bu mimari sayesinde:

• Her servis bağımsız olarak güncellenebilir.
• Yük arttığında sadece ihtiyaç duyulan servis ölçeklendirilebilir.
• Farklı programlama dilleri aynı proje içinde kullanılabilir.

Örneğin bir e-ticaret sitesinde ürün arama servisi çok yoğun kullanılıyorsa, bu servisten birkaç tane daha ayağa kaldırabilirsiniz. Kullanıcılar azaldığında ise bu servisleri düşürebilirsiniz.

Amaç Mikroservis Değil, Mikroservisleri Yönetebilmek

Mikroservis yapısını kurduktan sonra ortaya bazı problemler çıkmaya başlar:

• Servisler düştüğünde kim ayağa kaldıracak?
• Yük artınca hangi servisten kaçı çalışacak?
• Kullanıcı istekleri hangi servislere yönlendirilecek?
• IP adreslerini kim yönetecek?
• Servisler nasıl rollback yapacak?

Bu tür ihtiyaçlar arttıkça, sadece mikroservis yapısı değil, bu yapıyı yönetecek bir sistem ihtiyacı da doğar.

Borg → Kubernetes

Google, 2000’li yıllardan beri container teknolojilerini hem de production seviyesinde kullanıyor. Bu kapsamda geliştirdiği iç araçlardan biri olan Borg, Kubernetes’in atası sayılır. Borg, büyük ölçekte container yönetimi sağlayan ancak esnek olmayan, sıkı bağlı (tightly coupled) ve monolitik bir sistemdi.

Zamanla Google mühendisleri bu sistemi daha modüler hale getirmek istediler ve Omega adında yeni bir sistem geliştirdiler. Ancak Omega, deneysel kaldı ve production ortamında kullanılmadı. Bu süreçten edindikleri tecrübelerle 2014 yılında Kubernetes projesini başlattılar. 2015 yılında ise proje, CNCF (Cloud Native Computing Foundation) çatısı altında açık kaynak olarak yayımlandı.

Peki neden açık kaynak?

Google, Kubernetes’i sadece kendisi için değil, herkesin kullanabileceği bir endüstri standardı haline getirmek istiyordu. Bu sayede Kubernetes’in “doğal habitatı” olarak Google Cloud Platform (GCP)’u konumlandırabileceklerdi. Yani mesaj şuydu:

“Evet Kubernetes herkesin olabilir, ama biz bu işin ustasıyız.”

Kubernetes Neyi Çözüyor?

Container orchestration dedik. Peki bu tam olarak ne demek?

• Container’ları pod adı verilen birimlerde toplar.
• Hangi container hangi node’a gidecek, onu scheduler belirler.
• Trafik artarsa otomatik olarak yeni instance’lar yaratır (auto-scaling).
• Container çökerse yeniden başlatır (self-healing).
• Uygulama güncellenirken kesinti yaşanmaması için rolling update uygular.
• IP adresleri değişse bile sabit bir servis katmanı sağlar (abstraction).

Bu sistemde bazı yeni kavramlar karşımıza çıkar:

• Pod: Kubernetes’in deploy edilebilir en küçük birimidir. Genellikle bir pod tek bir container içerir, ancak örneğin log toplamak için ek bir sidecar container da içerebilir.
• Node: CPU, RAM ve storage gibi kaynakları barındıran fiziksel ya da sanal makineler.
• Control Plane: Sistemin beyni. Burada scheduler, controller, API sunucusu gibi bileşenler bulunur.

Kubernetes Mimarisi

Kubernetes mimarisi üç ana bileşenden oluşur:

1. Cluster

Tüm yapının genel ismidir. İçerisinde Control Plane ve Node’lar bulunur.Yani beraber çalışan sistem grubu.

2. Control Plane

Sistemin beyni gibi çalışır. İçerisinde şu bileşenler vardır:

• etcd: Kubernetes’in tüm verilerini sakladığı dağıtık key-value veritabanıdır.
• kube-apiserver: Sistemin tüm dış dünya ile konuştuğu API arayüzüdür.
• kube-scheduler: Hangi pod’un hangi node’a atanacağını belirler.
• controller-manager: Sistem durumunu izler, gerekirse aksiyon alır.
• cloud-controller-manager: Kubernetes’in bulut servis sağlayıcılarıyla iletişimini sağlar.

3. Node

Her biri bir compute birimi (CPU, RAM, disk) olan fiziksel veya sanal makineler:

• Kubelet: Node üzerinde çalışan ve container’ları ayağa kaldıran ajan.
• Kube-proxy: Node içi ve dış dünya arasındaki ağ trafiğini yönetir.
• CRI (Container Runtime Interface): Docker veya containerd gibi container çalıştırıcılarla etkileşir.

Sonuç: Modern Dağıtımın Standardı

Bugün Amazon’un Elastic Kubernetes Service (EKS), Microsoft’un AKS’i, IBM’in OpenShift’i gibi hizmetler, Kubernetes’in farklı dağıtımlarıdır. Tıpkı Linux’un Ubuntu, Fedora, Debian gibi farklı distroları olduğu gibi, Kubernetes de bir “çekirdek”tir.

Kubernetes, Google’dan doğmuş ve tüm dünyaya yayılmıştır. Modern yazılım dünyasında uygulama dağıtımının ve ölçeklenebilirliğin endüstri standardı haline gelmiştir.

Mehmet Emin Ciddi (UX 101)

Deneyimi Her Yerde

“Deneyim” dediğimiz şey; bir butonun rengi, bir masanın yüksekliği ya da hangi malzemeden üretildiği gibi yalnızca somut özelliklerden ibaret değildir. Aslında deneyim, bir hizmetin ya da ürünün en başından en sonuna kadar yaşattığı tüm süreci kapsar. Bu nedenle deneyim soyut bir kavramdır; hissedilir, hatırlanır ama çoğu zaman kelimelere dökülemez.

Kullanıcı deneyimi (UX) kavramını bu sektörde ilk kez kullanan kişi Don Norman olmuştur. Apple’da çalıştığı dönemde, bu kavramı yazılım ve donanım dünyasına kazandırdı. Onun bakış açısıyla deneyim, sadece kullanıcı arayüzüyle sınırlı değildir; iletişimde, algıda, hatta zihinsel süreçlerde bile ortaya çıkar.

Henry Ford’un meşhur bir sözü vardır:

“Eğer kullanıcıları birebir dinleseydim, onlara araba değil, daha hızlı atlar verirdim.”

Bu söz, kullanıcıyı anlamanın her zaman doğrudan söylediklerinden ibaret olmadığını gösterir. Kullanıcının ihtiyacını doğru anlayabilmek, onun yerine empati kurmakla mümkündür.

Empati: Tasarımcının En Önemli Kaslarından Biri

Bir tasarımcının sahip olması gereken en güçlü yetkinlik empatidir. Muhatabının dertleriyle dertlenebilen bir kişi, gerçek anlamda çözüm üretebilir. Don Norman’ın kitapları bu konuda muazzam bir rehberdir, fakat empati sadece kitaplardan öğrenilmez.

Empati kasını geliştirmek için iki temel yol vardır:

1. Çok gezmek — Gerçek insanlarla, gerçek deneyimlerle yüzleşmek
2. Çok okumak — Özellikle Dostoyevski gibi yazarlar, insan ruhuna dair derinlikleri ortaya koyar

Tasarım yaparken, o ürün ya da hizmetin kullanıcısıyla etkileşime geçmek; onların dünyasına girmek, gerekirse onların deneyimlerini birebir yaşamak büyük önem taşır. Derdi çekilen yerde bulunmak, anlamlı bir çözüm için ilk adımdır.

Segmentasyon ve Persona: İnsanları Anlamak

Bir kullanıcıyı tanımlarken yalnızca demografik bilgilerle (segment) yetinmek yeterli değildir. İnsanların neyi sevdiği, neye ihtiyaç duyduğu, nelerden hoşlanmadığı gibi özellikleri de anlamamız gerekir. Persona oluşturmak, kullanıcıları gerçekten tanımak ve onlara uygun deneyimler sunmak için hayati bir adımdır.

Tasarım Sürecine Yaklaşım: Küçük Başla, Doğru İlerle

Tasarım süreci, T-şekilli veya M-şekilli bir gelişimle ilerlemelidir:

• T-şekilli birey: Bir alanda derinleşmiş, ama birçok farklı disiplinden anlayan kişidir.
• M-şekilli birey: Birden fazla alanda uzmanlaşmış ve bu alanları birbiriyle entegre edebilen kişidir.

Ürün geliştirme sürecinde herkes fikirler üretebilir. Ama önemli olan bu fikirleri doğru bir problem çözümüne dönüştürebilmektir. Bunun için de sürece en küçük yapı taşından başlamak gerekir: MVP (Minimum Viable Product).

Prototipleme aşamasında her şeyin mükemmel olması gerekmez. Bazen basit bir “mış gibi” yapmak bile fikirleri test etmek için yeterlidir. Burger King örneğinde olduğu gibi, tonlarca para ve zamana gerek kalmadan sade prototiplerle kullanıcıya ulaşmak mümkündür.

Son Söz: Negatif Olmayan İnsanlarla Çalışın

Başarılı ekipler, sadece çözüm üreten değil; çözümün bir parçası olmayı seçen insanlardan oluşur. Negatif enerji yayan kişiler süreci yavaşlatır. Oysa doğru insanlar, sorunları sahiplenir, birlikte üretir ve birlikte büyür.

Insider’da geçirdiğim bu haftada en çok dikkatimi çeken şey, iletişime verilen gerçek değerdi. Hem ekip içi etkileşimlerde hem de partnerlerle olan ilişkilerde iletişim sadece bir gereklilik değil, kültürün merkezinde yer alan bir öncelik. Üstelik bu, yalnızca sözde değil — gerçekten önemsenen, üzerine düşünülen ve sürekli geliştirilen bir alan. Belki de Insider’ın global başarılarının arkasındaki en güçlü etkenlerden biri de bu: İnsanların birbirini gerçekten dinlediği, anladığı ve birlikte hareket ettiği bir yapı.

Cengizhan Anıl Onay(Code Editors & AI Tools)

Bu hafta katıldığımız eğitimde Anıl Bey bizlere yazılım dünyasının gelişen araçları ve yapay zekâ destekli geliştirme süreçleri hakkında oldukça kapsamlı bilgiler sundu. Eğitim, Visual Studio Code, WebStorm ve özellikle Cursor gibi modern kod editörlerinin sunduğu avantajları tanıyarak başladı. Cursor’ın LLM destekli özellikleri sayesinde, artık sadece kod yazmak değil; kodla iletişim kurmak mümkün hale geliyor.

Devamında “Prompt Engineering” konusuna geçildi. Yapay zekadan verimli şekilde faydalanmak için nasıl doğru prompt’lar yazmamız gerektiğini, kötü ve iyi prompt örnekleriyle karşılaştırmalı olarak öğrendik. Doğru sorular sormanın, doğru çözümlere ulaşmak için ne kadar kritik olduğunu net bir şekilde kavradık.

Limitasyonlar ve riskler başlığında ise 4 önemli konu dikkat çekiciydi:

1. Yapay zekânın zaman zaman halüsinasyon görmesi,
2. Modellerin bilgi güncelliğinin sınırlı olması,
3. Güvenlik riskleri — özellikle API anahtarlarının paylaşılmaması gerektiği,
4. Ve belki de en insani olanı: Beyin tembelliği riski.

Ancak bana göre eğitimin en etkileyici kısmı, interaktif ve gerçek zamanlı yapılan hands-on demo oldu. Kahoot’a benzer bir yapıda gerçekleşen canlı coding oturumu, teorik bilgilerin pratiğe dönüşmesini sağladı.Bu kısımda öğrendiğim bazı önemli kavramları açıklayacağım :

1.WEB SOCKET:

HTTP

Biz WebSocket’i kullanmadan, HTTP’nin nimetlerinden yararlanarak gerçek zamanlı olmasa da bunu simüle edebiliriz. Nasıl mı? Short polling ve Long polling yöntemleriyle.

Short Polling:
Bir senaryo düşünün: İki tane cihaz, iki tane client var ve aralarında WhatsApp gibi bir mesajlaşma uygulaması üzerinden konuşuyorlar. Bir tanesi diğerine mesaj attığında, mesajı alan client bu mesajın geldiğini öğrenmek istiyor. Bunun için backend’e (sunucuya) 1 saniye aralıklarla sürekli istek atıyor:

GET /updates  
GET /updates  
GET /updates  
GET /updates ...

Ta ki mesaj gerçekten gelene kadar. Yani mesaj henüz ulaşmadıysa backend her seferinde boş bir yanıt dönüyor çünkü içinde mesaj yok. Bu istekler sürekli gidiyor ama cevap gelmiyor. Bu yöntem hem gereksiz, hem verimsiz, hem de mantıklı değil.

Neden mantıklı değil? Çünkü her istek için bir TCP bağlantısı açılıyor. Bu da sistemde ekstra yük yaratıyor. Bunu yapan sadece 1 kişi değil, bin kişi olduğunu düşünün. Bin kişi sürekli olarak sunucuya “mesajım geldi mi?” diye soruyor ve sunucu her seferinde boş bir yanıt olarak döndürüyor. Bu, bandwith (bant genişliği) açısından oldukça kötü bir kullanım. Ayrıca client tarafında da sürekli kaynak tüketiliyor.

Long Polling:
Short polling’e göre daha mantıklı, ama hâlâ bizim istediğimiz kadar verimli ve ölçeklenebilir (scalable) değil. Biz bir çözüm üretiyorsak, bu çözümün scalable ve performanslı olması gerekir. Mühendis dediğimiz kişi, bir soruna en optimal ve uygulanabilir çözümü bulmalı ve onu uygulamalıdır.

Long polling şöyle çalışır:
Client, backend’e bir istek atar, örneğin GET /updates. Fakat backend bu isteği hemen cevaplamaz, suspend eder yani askıya alır. Daha sonra belirli bir event (tetikleyici bir olay) oluştuğunda — örneğin yeni veri geldiğinde — backend cevabı gönderir.

Buradaki problem şu: Bu istekler tarayıcı için hâlâ “uçuşta”dır (inflight request). Tarayıcı henüz bu isteğin gelip gelmediğini bilmez. Bir tane attı, gelmedi. İki tane attı, gelmedi. Böylece beş tane inflight request oluşur. Bunlar hâlâ cevap bekliyor. Bu da kötü bellek kullanımı (memory usage) anlamına gelir. Yani yine gerçek zamanlılık elde edemiyoruz.

Peki bunu nasıl çözeceğiz? İşte burada devreye WebSocket giriyor.

WebSocket Nasıl Çalışır?

Öncelikle client, sunucuya bir GET isteği gönderir. Biz buna handshake diyoruz. Gerçekten client ve server arasında bir anlaşma başlar. İsteğin içinde bir header bulunur: Connection: UpgradeBackend, bu isteği aldığında client’a 101 kodlu bir response döner:

101 Switching Protocols

Yani sunucu, client’a “artık HTTP konuşmayalım, WebSocket üzerinden devam edelim” der. Bu aşamaya da ACK (acknowledgement) denir.

Bu andan sonra client ile server arasındaki iletişim artık data frame üzerinden ilerler. Bu data frame içindeki tüm konuşmalar çift yönlü (full duplex) gerçekleşir. Yani hem server client’a konuşur, hem de client server’a. Üstelik eş zamanlı olarak.

Örneğin client bir mesaj gönderdi — tıpkı WhatsApp’ta Ali’nin Ahmet’e mesaj göndermesi gibi. Server bu mesajı aldıktan hemen sonra, WebSocket ile bağlı olan diğer client’a “sana mesaj geldi kardeşim” diyebilir. Bu tamamen gerçek zamanlı olur ve tek bir TCP bağlantısı üzerinden işler. İşte bu yüzden WebSocket gerçekten gerçek zamanlı bir çözümdür.

Her mesaj için ayrı bir HTTP request işlemediğimiz için:

• Bandwidth verimli kullanılır,
• Sistem çok daha scalable (ölçeklenebilir) hale gelir.

Bu çözüm, 10.000 hatta 1.000.000 kullanıcıya bile cevap verebilecek kadar güçlüdür.

Peki Ne Zaman WebSocket Kullanmamalıyız?

Gerçekten gerçek zamanlı bir iletişime ihtiyaç duymuyorsanız, WebSocket kullanmamalısınız. Çünkü bu yapı, sisteminize gereksiz karmaşıklık katar. Düşük trafikli bir sistemde, az sayıda istek varsa HTTP, yani short polling ya da long polling gayet yeterli olabilir.

Örneğin 5 saniyede bir yapılan bir işlem için WebSocket kurmak mantıksız olur.

Ekstra: Broadcast Nedir?

WebSocket ile yalnızca iki uç nokta arasında değil, çoklu istemciler arasında da anlık iletişim kurulabilir. Broadcast, sunucuya bağlı olan tüm client’lara aynı anda mesaj göndermek anlamına gelir. Örneğin bir kullanıcı kanvasa bir şey çizdiğinde, bu “draw event” sunucuya iletilir. Sunucu ise bu olayı bağlı olan tüm client’lara broadcast eder:

“Birisi bir şey çizdi, alın bu veriyi siz de kendi ekranınıza çizin.”
Bu şekilde tüm kullanıcılar eş zamanlı olarak aynı çizimi görebilir. Bu da WebSocket’in en önemli kullanım alanlarından biridir: gerçek zamanlı iş birliği.

2.MCP(Model Context Protocol)

MCP nedir?

MCP (Model Context Protocol), LLM’lerimizi (Large Language Models) harici veri kaynaklarına bağlamanın standartlaştırılmış bir yoludur. Bu protokolün yaratıcısı Anthropic’tir — yani aslında Claude’un geliştiricileri.

Peki, buradaki temel mantık nedir?

MCP’den önce LLM’imiz, Slack API, Figma API, GitHub API gibi çeşitli servislerle doğrudan entegre olabiliyordu. Ancak bunu gerçekleştirebilmek için, her API’ye özel kod yazmak ve tüm implementasyon detaylarını modele uygun şekilde oluşturmak gerekiyordu. Yani modelin, örneğin Slack API’yi nasıl kullanacağını, GitHub API ile nasıl etkileşime geçeceğini birebir bilmesi gerekiyordu. Bu da şu demekti: Kodu her modele özel yazmamız gerekiyordu. Yeni bir model veya versiyon çıktığında ise tüm süreci yeniden baştan geliştirmek gerekiyordu.

İşte MCP’nin getirdiği yenilik burada devreye giriyor. Artık modeller, function call yapma konusunda fine-tune ediliyor ve birçok farklı API’yi kullanabilmeleri için ortak bir yapı (unified API) tanımlanıyor. Bu yapıya da MCP deniyor.

MCP basitçe bir server ve bir client yapısından oluşuyor. Model, client ile konuşuyor; client da MCP server’da tanımlı olan tool’ların açıklamalarına bakarak hangi tool’un kullanılacağına karar veriyor. İşte bu kadar basit.

MCP neden ortaya çıktı?

Sorun oldukça basitti: LLM’lerin bilgi veri tabanı (knowledge store) sınırlıdır. Yani yalnızca eğitildikleri veri setiyle sınırlı çalışırlar. Güncel bilgilerden izole olmuşlardır. Bu izolasyon, her tool entegrasyonu için özel, yani “custom” yapıların geliştirilmesini gerektiriyordu.

Bu da bizi bir n*m problemine götürüyor:
n tane modelimiz, m tane tool’umuz varsa, her modelin her tool ile özel bir şekilde konuşabilmesi için n*m adet entegrasyon yapılması gerekiyordu. Bu da büyük bir kaos, gereksiz geliştirme ve bakım yükü demekti.

MCP bu sorunu çözüyor. Modeli function call yapabilir şekilde fine-tune ediyoruz ve MCP ile bu çağrıları standardize hale getiriyoruz. Böylece her LLM’e ayrı ayrı kod yazmak zorunda kalmıyoruz.

MCP ne sağlar?

MCP, LLM’lere function call işlemini öğrenmeleri için bir yöntem sunar. Bu yöntem sayesinde:

• Her tool için ayrı ayrı entegrasyon yazmak gerekmez.
• Gereksiz bakım ve geliştirme yükü ortadan kalkar.
• Sistemler arasında ölçeklenebilirlik (scalability) sağlanır.
• LLM, elindeki araçlara (tool’lara) bakarak neyi yapabileceğine kendisi karar verir.

MCP = Tool Discovery for LLMs
Yani model, kendi erişebildiği tool’lara bakar ve “Ben şunları yapabiliyormuşum” der. Bu sayede ihtiyaç duyduğu işlemleri doğru şekilde yönlendirebilir.

MCP Mimarisi

MCP mimarisini nasıl hayal etmeliyiz?

Bir host düşünün. Bu bir VS Code, IDE, Notepad veya başka bir editor olabilir. Bu host’un içinde bir MCP client bulunur. Ayrıca LLM ya host’un içinde yer alır ya da host, bir LLM ile API üzerinden konuşur. Bir ya da birden fazla MCP server da olabilir.

Bu MCP server’lar:

• Local veya remote bir veritabanına bağlı olabilir.
• Host’tan gelen kullanıcı sorgularına göre ilgili tool’u bulabilir.
• LLM’e bağlanarak işlemi gerçekleştirmek üzere yönlendirme yapabilir.

Örneğin:
Kullanıcı “Ankara’da hava durumu nasıl?” diye sorduğunda, LLM kendi eğitildiği veri setinin dışında olduğu için bu soruya cevap veremez. Ancak MCP client, LLM’e şunu söyler: “Senin şu tool’ların var: getWeather.”
Tool’un açıklamasını okuyan model, bu tool’u çağırarak MCP server üzerinden hava durumu bilgisini alır ve kullanıcıya döner.

Buradaki önemli ayrım:

• Resources: Statik ya da dinamik veri kaynaklarıdır. Hangi verinin kullanılacağına client karar verir.
• Tools: Yürütülebilir (executable) fonksiyonlardır. Hangi tool’un kullanılacağına model karar verir.

Süreç Nasıl İşliyor? (Kısa Özet)

1. Kullanıcı LLM’e bir soru sorar: “Bugün Ankara’da hava nasıl?”
2. Model, bu bilgiye sahip olmadığını ve dış veri kaynağına (function call) ihtiyaç duyduğunu bilir.
3. MCP client ile MCP server arasında daha önceden bir bağlantı kurulmuştur. Client, modelin erişebileceği tool ve resource listesini almıştır.
4. LLM, listede “getWeather” tool’unu ve açıklamasını görerek bunu kullanması gerektiğine karar verir.
5. Tool’u çağırır.
6. MCP server gelen request’i işler, schema validation yapar ve external servise (örneğin bir hava durumu API’si) istek atar.
7. Gelen veriyi formatlar, client’a gönderir.
8. Client da bu veriyi alır, model üzerinden kullanıcıya döner.

Bu sayede model dış veri kaynaklarından anlamlı ve güvenilir bilgi çekebilir hale gelir.

Transport Katmanı

MCP ile konuşurken iki farklı iletişim yöntemi kullanılabilir:

• stdin/stdout → Local kullanımlar için (client ve server aynı makinedeyse)
• HTTP/SSE → Remote kullanımlar için

MCP, dış veri kaynaklarıyla konuşabilen modeller yaratmanın en önemli yapı taşlarından biri haline geliyor. Web search gibi ama daha güvenilir, daha kontrollü ve daha entegrasyon dostu — çünkü API standardı ile çalışıyor.

3.Redis ve Caching

Kullanıcımız , telefonundan, bilgisayarından ya da dizüstü bilgisayarından bir web sitesine giriyor. Bu, bizim için bir client demektir. User, giriş yaptığında bilgilerini almak için kendi backend sunucusuna bir istek (GET request) gönderir:
GET /api/user/1
(ID değeri burada 1'dir.)

Bu istek önce API router’a, ardından da user rotasına ulaşır. Gönderilen ID (örneğin 1), bir ORM (Object-Relational Mapping) aracılığıyla veritabanına bir sorgu olarak iletilir. Bu sorgu, veritabanının diskine yazılır ya da diskten okunur. Yani burada klasik bir input/output (I/O) işlemi gerçekleşir.

Ancak bu işlem yavaştır. Neye göre? Redis’e göre çok daha yavaş.

Veritabanı diskinden gelen yanıt, tekrar backend’e, ardından da client’a gönderilir. Böylece kullanıcı, örneğin şu bilgileri öğrenmiş olur:

• Kim olduğu
• Hesabını ne zaman açtığı/kapatttığı
• Ne satın aldığı vb.

Peki bu yapıda geliştirmek istediğimiz veya sorunlu gördüğümüz ne?

Aslında Redis olmadan da sistem çalışır. Ama yüksek trafik altında çalışmaz — ya da verimli çalışmaz. Neden mi?

Neden Redis’e İhtiyacımız Var?

Şöyle bir senaryo düşünelim:
Sunucuya aynı anda 10.000 kişi bağlanıyor ve her biri 10 saniye boyunca aynı route’a (örneğin /api/user) istek atıyor. Yani her kullanıcı için tekrar tekrar veritabanına sorgular gönderiliyor.

Bu durumda:

• 10.000 bağlantı = 10.000 ayrı veritabanı sorgusu
• Her biri I/O işlemi (disk erişimi)
• Her seferinde veritabanı bağlantısı (connection pool) açılıyor

Sonuç?
Bu süreç çok maliyetli ve yavaş.
İşte bu noktada devreye Redis giriyor.

Redis ile Ne Yapıyoruz?

Redis, genelde bir cache server olarak kullanılır. Yani biz, veritabanının döndüğü verileri alıp önbelleğe (cache memory) kaydediyoruz.
Bu cache memory, diske erişimden kat kat daha hızlıdır. (Ancak RAM tabanlı olduğu için daha maliyetlidir.)

Senaryo: Redis ile User Bilgisi Getirme

1. Kullanıcı GET /api/user/1 isteğini gönderir.
2. Backend sunucusu önce veritabanına gitmez.
3. Önce Redis’e sorar:
   “Hey Redis, bu kullanıcı bilgisi sende var mı?”

Bu kontrol için bir fonksiyon çalışır: getCachedUser()

4.Redis bir key-value veri tabanıdır. getCachedUser() fonksiyonu, ID'si 1 olan kullanıcıyı Redis içinde arar.

İki Olası Durum:

1. Hit (Cache’te bulduk):

• Redis, aradığımız veriyi key-value olarak tutuyorsa:
• Veritabanına hiç gitmeden,
• Doğrudan client’a veri döneriz.
• Connection açılmadığı için çok daha hızlı ve maliyetsizdir.

2. Miss (Cache’te yok):

• Redis’te veri bulunmazsa:
• Mecburen veritabanına sorgu gönderilir.
• Bağlantı açılır, veri alınır.
• Fakat döndürmeden önce bu veri Redis’e yazılır.

Bunun için ayrı bir fonksiyon çalışır: cacheUser()
Ayrıca, bu verinin bir TTL (Time To Live) değeri olur.
Yani: "Bu cache, x saniye sonra silinebilir" denir.

İlk Request Neden Maliyetli?

İlk istek (yani Miss durumunda):

• Redis’e bakılır (veri yok),
• Veritabanına gidilir (maliyet),
• Veritabanından alınan veri Redis’e kaydedilir (ekstra işlem),
• Sonra client’a veri döner.

Ancak ikinci request artık farklıdır:

• Redis’e tekrar sorulur,
• Bu kez veri vardır (Hit),
• Veritabanına hiç uğramadan,
• Doğrudan client’a veri döner.

İlk istek pahalı olabilir, ama ikinci ve sonraki istekler çok daha hızlıdır.

Örnek: 10.000 kişi 10 saniye boyunca aynı endpoint’e istek atıyor.
İlk istek maliyetlidir, ama 2., 3., 4…. tüm istekler Redis’ten döner.
Yani yüksek trafik altında performansımız dramatik şekilde artar.

Redis Ne Tür Veriler Tutabilir?

Redis sadece key-value değil, aynı zamanda:

• String
• List
• Set
• Sorted Set
• Hash

gibi veri yapıları da tutabilir. Bu sayede birçok farklı kullanım senaryosu mümkündür.

• Redis ile yüksek trafikte bile sistemimiz hızlı çalışır.
• Gereksiz veritabanı bağlantılarını önler.
• Cache sayesinde istemciler veriye daha hızlı erişir.
• TTL (zaman aşımı) ile güncel olmayan verilerin otomatik temizliği sağlanır.

Bünyamin Gökkaya (CSS & Layouts)

Bünyamin Bey, temel HTML anlatımının ardından katılımcılara CSS ile sayfa düzeni (layout) konusuna giriş yaptı. Bu bölümde özellikle modern web tasarımında sayfa yapısını oluşturmada kullanılan CSS tekniklerine odaklanıldı.

1. Layout’a Giriş

• Layout (yerleşim düzeni) kavramının ne olduğu, kullanıcı deneyimi üzerindeki etkisi anlatıldı.
• HTML elementlerinin görsel yerleşimini düzenlemek için CSS’in nasıl devreye girdiği açıklandı.

2. Kullanılan Temel Layout Yöntemleri

• Block & Inline elementler
• display kullanımı:
• block, inline, inline-block, none
• Float ve Clear: Eskiden kullanılan klasik layout yöntemi olarak tanıtıldı.
• Flexbox:
• Ana eksen, çapraz eksen kavramları
• justify-content, align-items, flex-direction
• Responsive tasarım için kullanım örnekleri

3. Responsive Layout’lara Giriş

• Mobil uyumlu tasarımlar için media queries kullanımı kısaca tanıtıldı.
• W3Schools üzerinden bazı örnek responsive sayfa yapıları gösterildi.

Berke Altıparmak (JavaScript Basics)

Değişken Nedir?
Değişken, veri depolamak için kullanılan bir kaptır. JavaScript’te 3 şekilde değişken tanımlanabilir:

• var → (Eski yöntem – artık önerilmez)
• let → (Blok kapsamında geçerli – değişebilen değerler için önerilir)
• const → (Blok kapsamında geçerli – sabit değerler için kullanılır)

Değişken Tanımlama Kuralları:

• Harf, _ (alt çizgi) veya $ ile başlamalıdır.
• Sayı ile başlayamaz.
• Büyük/küçük harf duyarlıdır (myVar ≠ myvar)
• let, function gibi JavaScript’e ait anahtar kelimeler kullanılamaz.

Veri Türleri:

• String → Metin verileri
• Number → Sayısal değerler (tam sayı, ondalıklı)
• Boolean → true veya false
• Array → Liste veri tipi
• Object → Anahtar-değer çiftleri
• null ve undefined değerleri

Hoisting (Yukarı Taşınma):

• var ile tanımlanan değişkenler kapsamın başına taşınır, ancak tanımsız (undefined) olarak başlatılır.
• let ve const ise tanımlanmadan önce kullanılamaz (Temporal Dead Zone – geçici ölü bölge).

Fonksiyon Nedir?
Fonksiyon, belirli bir görevi yerine getiren ve tekrar kullanılabilen kod bloklarıdır. Kodun organize edilmesini ve tekrar kullanımını sağlar.

Fonksiyon Türleri:

• Klasik Fonksiyon Tanımları
• Arrow Functions (=>) → Daha kısa sözdizimi
• Anonim Fonksiyonlar → İsimsiz fonksiyonlar, genellikle callback olarak kullanılır
• Callback Functions → Bir başka fonksiyona argüman olarak verilen fonksiyonlar
• Higher-Order Functions → Fonksiyonu argüman olarak alan veya fonksiyon döndüren fonksiyonlar

Döngü Nedir?
Bir koşul sağlandığı sürece aynı kod bloğunu tekrar tekrar çalıştırmamızı sağlar. Tekrarlı işlemleri otomatik hale getirir.

Döngü Türleri:

• while → Koşul doğru olduğu sürece çalışır (koşul önceden kontrol edilir)
• do-while → En az bir kez çalışır, sonra koşula bakılır
• for-of → Dizi (array) ve iterable nesneler üzerinde döner
• for-in → Nesnelerin anahtarları üzerinde döner

Diğer Yapılar:

• break → Döngüyü tamamen durdurur
• continue → Sadece mevcut döngü adımını atlar
• Nested Loops → İç içe döngüler
• Array ve String Üzerinde Dönme

DOM Nedir?
DOM (Document Object Model), web sayfalarını temsil eden ve JavaScript ile etkileşim kurmamızı sağlayan bir modeldir.

JavaScript ile DOM Üzerinde Yapılabilecekler:

• HTML elementlerine erişme
• Element içeriğini değiştirme
• Yeni element oluşturma ve ekleme
• Event Listener (Olay dinleyicisi) ekleyerek kullanıcı etkileşimlerine yanıt verme

Örnek: Bir butona tıklanınca yazının rengini değiştirme gibi işlemler DOM ile gerçekleştirilir.

Anıl Nuhoğlu(JS Events & Web APIs)

Anıl Bey, bu eğitimde JavaScript’te olay yönetimi (event handling) ve Web API kullanımı konularını detaylı bir şekilde ele aldı. Eğitim boyunca tüm konular, kendi hazırladığı ve uygulamalı örneklerle zenginleştirilmiş özel web arayüzü üzerinden işlendi.

https://js-events-inky.vercel.app/

Bu bağlantı, eğitimin tüm başlıklarını, kod örneklerini ve anlatımı barındırmakta olup incelemek isteyenler için güzel bir kaynak.

Mehmet Sel (HTML Basics)

Mehmet Sel, bu eğitimde HTML’in temel yapı taşlarını detaylı bir şekilde anlattı. Eğitim süresince sadece teorik bilgiler değil, aynı zamanda canlı uygulamalar da yapıldı.

Özellikle web sayfalarının yapısını daha iyi anlamak için Google gibi popüler siteler üzerinden tarayıcı geliştirici araçları (Inspect / İncele) kullanılarak gerçek örnekler incelendi. Öğrencilere HTML etiketlerinin nasıl çalıştığı, nerede ve nasıl kullanıldığı doğrudan sayfa üzerinden gösterildi.

Ceyhun Alyeşil — Quality Assurance (QA)

Bu eğitimde Ceyhun Bey, kalite süreçlerini yalnızca otomasyon testlerine indirgemeyen; manuel (elle) testlerin kritik rolünü vurgulayan kapsamlı bir perspektif sundu. Eğitimin en dikkat çekici yanlarından biri, otomasyonun her zaman her şeyi yakalayamayacağına dair verdiği somut örneklerdi. Özellikle bazı hata türlerinin zamanla sistemin evrilmesiyle birlikte değiştiğini, bu nedenle manuel kontrollerin güncelliğini ve önemini hiçbir zaman yitirmediğini gerçek projelerden aktardığı kişisel tecrübeler ile açıkladı.

Ceyhun Bey, yalnızca teknik test araçlarının nasıl çalıştığını değil, bir QA uzmanının sahip olması gereken düşünce yapısını, sorgulama refleksini ve risk farkındalığını da bizlere kazandırmayı hedefledi.

Testin 7 temel prensibini ele aldı:

1. Test etmek hataların varlığını gösterir
2. Tüm ihtimaller test edilemez
3. Teste erken başlamak daha verimlidir
4. Hatalar genellikle belli noktalarda kümelenir
5. Aynı testler sürekli uygulanırsa yeni hatalar yakalanmaz
6. Test bağlama (ürüne, kullanıcıya, sektöre) göre değişir
7. Hata olmaması, ürünün doğru çalıştığı anlamına gelmez

Bunlara ek olarak, QA süreçlerinde yaygın olarak kullanılan %80 — %20 kuralı (Pareto Prensibi) üzerinde durularak, yazılımdaki hataların büyük çoğunluğunun genellikle kodun küçük bir bölümünden kaynaklandığı vurgulandı. Bu nedenle, test odağının stratejik şekilde belirlenmesinin önemi açıkça ortaya kondu.

“Test sadece teknik bir görev değil, kaliteye olan zihinsel bir bağlılıktır.”

Bu hafta edindiğim en değerli tecrübelerden biri, şirketteki insanlarla yaptığım sohbetlerde fark ettiğim; herkesin karakteri ve farkındalığıyla en iyi olduğu alanda çalışıyor olması ve bu durumun bana farklı bir bakış açısı kazandırmasıydı. Insider, herkesin iyi olduğu noktayı ön plana çıkarıyor ve bu sayede inanılmaz işler ortaya çıkıyor.

Muhammet Furkan Demiral (What/How a QA does !)

Quality Assurance Team

Yazılım geliştirme süreçlerinde kalitenin korunması, müşteri memnuniyetinin artırılması ve sürdürülebilir ürünler oluşturulması adına Quality Assurance (QA) ekibinin rolü kritik önemdedir. Bu yazıda, kalite kavramından yazılım test yaşam döngüsünü (STLC), test süreçlerinin evriminden etkili hata raporlamaya kadar QA dünyasına dair temel konulara teknik bir perspektiften ışık tutuyoruz.

Kalite Nedir?

Kalite, genel anlamda “standartlara uygunluk” olarak tanımlanır. Ancak yazılım sektöründe kalite, müşteri beklentilerini karşılamakla eşdeğerdir. Özellikle Growth Management Platform gibi hızlı iterasyon gerektiren sistemlerde, kalite yalnızca kodun düzgün çalışması değil; aynı zamanda sürdürülebilir, ölçeklenebilir ve kullanıcı dostu bir deneyim sunmaktır.

Yazılımda Kalite ve Kontrol

Yazılım testi yalnızca hata bulma aracı değildir; aynı zamanda kalite güvencesinin ayrılmaz bir parçasıdır. Kalite kontrol (QC), uygulamanın çıktısını değerlendirirken, kalite güvence (QA) sürecin kendisini iyileştirmeyi hedefler.

• QC = Ürün üzerinde kontrol
• QA = Süreçlerin kontrolü

Bu sayede yalnızca çalışan bir ürün değil, aynı zamanda sürdürülebilir, güvenilir ve kullanıcı odaklı bir sistem elde edilir.

SDLC ve STLC Farkı

• SDLC (Software Development Life Cycle): Gereksinim analizi → Tasarım → Geliştirme → Test → Dağıtım → Bakım adımlarını kapsayan genel yazılım yaşam döngüsüdür.
• STLC (Software Testing Life Cycle): SDLC’nin “test” adımının detaylandırılmış halidir. Test planlaması, test case yazımı, ortam kurulumu, test yürütme ve kapanış gibi aşamalardan oluşur.

Kritik fark: SDLC tüm süreci kapsarken, STLC sadece test evresine odaklanır.

QA Neden Gereklidir?

• QA süreçleri, sadece hataları tespit etmeyi değil, hataları oluşmadan önlemeyi amaçlar.
• Zaman, maliyet ve kaynak verimliliği sağlar.
• Yasal veya sözleşmeye dayalı yükümlülüklerin yerine getirilmesini güvence altına alır.
• Kullanıcı memnuniyetini artırır, çünkü son ürün beklentilere daha uygun olur.

Test Sürecinin Evrimi

Yazılım testi artık yalnızca hata bulma eylemi değildir. Günümüzde test, aşağıdaki modern yaklaşımları içerecek şekilde evrilmiştir:

• Fonksiyonel, yıkıcı ve otomasyon testleri
• Agile ve sürekli test (continuous testing)
• CI/CD entegrasyonu
• Yapay zekâ destekli test senaryoları

Test artık yalnızca bir aktivite değil, bir kültür ve bakış açısıdır.

Doğrulama ve Geçerleme (Verification vs Validation)

• Verification (Doğrulama): Doğru şekilde mi geliştirildi?
• Validation (Geçerleme): Doğru ürün mü geliştirildi?

Bu ayrım, QA süreçlerinde sıkça karşılaşılan ancak çoğu zaman karıştırılan iki kavramın teknik temelini oluşturur.

Tester Mindset: Testçinin Bakış Açısı

Başarılı bir QA uzmanı yalnızca teknik bilgiye değil, aynı zamanda şu niteliklere de sahip olmalıdır:

Detay odaklı — Sorgulayıcı — Sürekli öğrenmeye açık — Analitik — Sistematik
Kullanıcı odaklı — Risk bazlı yaklaşım — Takım çalışması — Sabırlı ve kararlı

Yazılım Testinin 7 Temel İlkesi (7 Principles of Software Testing)

1. Tüm olası testleri yapmak imkansızdır.
   Exhaustive testing is not possible.
2. Hatalar genellikle aynı modülde kümelenir.
   Defect clustering.
3. Aynı testler tekrarlandığında yeni hata bulunamaz.
   Pesticide paradox.
4. Testler hata olmadığını değil, hata olduğunu gösterir.
   Testing shows presence of defects.
5. Hatasız yazılım, ihtiyaçları karşılayan yazılım demek değildir.
   Absence of error is a fallacy.
6. Erken yapılan test daha az maliyetlidir.
   Early testing.
7. Test bağlama (context) bağlıdır.
   Testing is context dependent.

Etkili Bir Hata Raporu Neden Önemlidir?

İyi yazılmış bir bug report:

• Geliştiricilerin hatayı hızlıca anlamasını sağlar.
• Hataların üretime taşınmasını önler.
• Test ve geliştirme ekipleri arasında verimli iletişim kurar.
• Gelecek sürümler için belge niteliği taşır.

Bug Report Template:

Sonuç

Kaliteli yazılım, yalnızca işlevsel değil; aynı zamanda hatalardan arındırılmış, güvenilir ve sürdürülebilir olmalıdır. Bunun için yalnızca test etmek değil, doğru zamanda, doğru yöntemle test etmek gerekir.

STLC süreçlerini iyi yönetmek, etkili test ilkelerine bağlı kalmak ve güçlü bug report’lar yazmak, QA ekiplerinin yazılım başarısına olan katkısını maksimize eder.

Kaynaklar ve Ek Okumalar :

• QA Roadmap: Learn to become a modern QA engineer
• QA Engineer Roadmap 🚀

Bulutay Saraç(Clean Code ,Git,Debugging)

Yazılım geliştirme dünyasında yalnızca çalışan kod yazmak yeterli değildir. Kodun okunabilir, sürdürülebilir ve hatalardan arındırılmış olması gerekir. Bu noktada Clean Code (Temiz Kod) yaklaşımı, Debugging (Hata Ayıklama) becerisi ve Git versiyon kontrol sistemi devreye girer. Bu yazıda bu üç temel konuyu hem teorik hem de pratik yönleriyle inceleyeceğiz.

1. Clean Code (Temiz Kod) Nedir?

Clean Code, yalnızca çalışmakla kalmayıp, aynı zamanda anlaşılabilir, sürdürülebilir ve geliştirilebilir olan koddur. Temiz kod yazarken hedef, gelecekte bu kodu geliştirecek kişinin (hatta bizzat sizin) zorlanmadan kodu okuyabilmesi ve değiştirebilmesidir.

“Temiz kod, kendini açıklayan koddur. Yorum satırlarına ihtiyaç duymadan niyetini belli eder.”

Felsefesi

• Okunabilirlik > Kısa Yol: Performans gerekmedikçe anlaşılırlık her zaman önceliklidir.
• Anlamlı İsimlendirme
• Basitlik: Gereksiz soyutlamalardan kaçın.
• Küçük Birimlere Bölme: Tek sorumluluk prensibi.
• Sürekli İyileştirme: Refactor etmekten çekinme.

Benzer Yaklaşımlar

• YAGNI (You Aren’t Gonna Need It)
• SOLID Prensipleri
• DRY (Don’t Repeat Yourself)
• TDD (Test-Driven Development)

10 Temel Temiz Kod Prensibi

1. Anlamlı İsimlendirme
2. Küçük Fonksiyonlar Yaz
3. Tek Sorumluluk Prensibi (SRP)
4. Yinelemeden Kaçın (DRY)
5. Gereksiz Kod Yazma (YAGNI)
6. Kodun Okunabilirliğini Öncelikli Tut
7. Basitlikten Şaşma (KISS)
8. Hataları Anlamlı Yönet
9. Test Edilebilir Kod Yaz
10. Gereksiz Yorumlardan Kaçın

Her prensibe ait örnek kodlar eğitim sırasında ele alındı. Bu prensiplerin gerçek dünyada uygulanması, projelerin ölçeklenebilirliği açısından kritik öneme sahiptir.

2.Code Review

Code review, geliştirilen kodun başka bir geliştirici tarafından incelenmesidir. Genellikle PR (Pull Request) açılarak yapılır. Kod okunur, yorumlanır ve iyileştirme önerileri verilir. Kod onaylandığında ana dala (main/master) merge edilir.

3. Debugging (Hata Ayıklama)

Debugging, yazılım geliştirme sürecinde hataların nedenini bulma, analiz etme ve düzeltme sürecidir.

Debugging = Hatanın izini sürmek + Davranışı anlamak + Çözmek

Neden Önemlidir?

• Kod her zaman beklendiği gibi çalışmaz.
• Hataların nerede oluştuğu her zaman açık değildir.
• Geliştirme sürecinin büyük kısmı debugging’e gider.

Debugging Araçları

• Tarayıcı Geliştirici Araçları (Chrome DevTools, Firefox DevTools)
• IDE Debugger (VS Code, GoLand)
• Logging (Loglama ile davranış analizi)
• Delve, GDB (Go ve sistem dilleri için)

JavaScript Debugging (DevTools)

Chrome DevTools, kodun satır satır izlenmesi, değişkenlerin gözlenmesi ve hata tespiti için yaygın olarak kullanılır.

DevTools’un Temel Sekmeleri:

• Elements: HTML/CSS analiz
• Console: JS komutları & loglar
• Sources: Breakpoint ile adım adım izleme
• Network: API çağrıları
• Application: LocalStorage, Cookie vs.

Go API Debugging

Delve Debugger ile çalışan Go servisleri adım adım izlemek, değişkenleri görmek ve performans izlemek mümkündür.

Logging ile Debugging

Kodun çeşitli noktalarına log satırları eklenerek akış ve veri analizi yapılır. Özellikle dağıtık sistemlerde en etkili hata ayıklama yöntemlerinden biridir.

Git: Temel Versiyon Kontrolü

Git Clone

Uzak bir Git reposunun yerel kopyasını oluşturur.

git clone https://github.com/kullanici/proje.git
git clone git@github.com:kullanici/proje.git

Branch (Dal)

Kodun bağımsız bir kopyasında geliştirme yapmaya olanak tanır.

git checkout -b feature/OPT-169278

Commit

Yapılan değişiklikleri Git’e kaydeder.

git add .
git commit -m "OPT-169278 1 new: inshoppingcart add product getter service"

Push & Pull Request (PR)

git push --set-upstream origin feature/OPT-169278

Push işleminden sonra GitHub’da PR (Pull Request) açılır ve kodun ana dala eklenmesi için review süreci başlatılır.

Sonuç

Clean Code prensipleri, debugging becerileri ve Git gibi versiyon kontrol sistemleri yazılım geliştiricilerin en temel taşlarıdır. Bu bilgiler, sadece bugünkü yazılımlar için değil, gelecekteki sürdürülebilir sistemler için de vazgeçilmezdir.

Kod yazarken okunabilirliği, hata ayıklarken sistematik yaklaşımı ve versiyon kontrolü yaparken işbirliğini merkeze koyan her yazılımcı, mesleğinde fark yaratacaktır.

“Kod yalnızca makine için değil, insanlar için de yazılır.”

Deniz Doğan(Algorithms & Problem Solving)

Giriş: Verimli Kodlama

Kod yazmak kolaydır.
Verimli kod yazmak ise bir sanattır.

Modern uygulamalarda performans kritik bir faktör haline gelmiştir. Milyonlarca kullanıcıya hizmet eden sistemlerde doğru algoritma seçimi ve optimizasyon, ürünün başarısını doğrudan etkiler. Bu nedenle algoritmalar, zaman karmaşıklığı ve sıralama yöntemleri gibi konular, yazılım mühendisliğinin temel yapı taşlarıdır.

Bu yazıda:

• Döngüler (Loops)
• Özyineleme (Recursion)
• Zaman Karmaşıklığı (Time Complexity)
• Sıralama Algoritmaları (Sorting)

temelinde verimli algoritmaların nasıl tasarlanacağını öğreneceğiz.

1. Loops (Döngüler)

Döngü, belirli bir koşul sağlandığı sürece tekrar eden işlemleri ifade eder.

Temel Döngü Yapıları

• for
• while
• do ... while
• for ... of, for ... in

for (let i = 0; i < 5; i++) {
  console.log("Adım: " + i);
}

2. Recursion (Özyineleme)

Recursion, bir fonksiyonun kendini çağırmasıdır. İki temel bileşeni vardır:

1. Base Case (Çıkış Koşulu): Fonksiyonun durmasını sağlar.
2. Recursive Case (Yeniden Çağrı): Fonksiyonun kendini tekrar çağırdığı durum.

def factorial(n):
    if n == 1:  # Base Case
        return 1
    return n * factorial(n - 1)  # Recursive Case

3. Time Complexity (Zaman Karmaşıklığı)

Bir algoritmanın giriş büyüklüğüne göre çalışmasının ne kadar zaman alacağını ölçer. Big O Notasyonu kullanılır.

Big O Örnekleri

• O(1): Sabit zaman — Örnek: Diziye index ile erişim
• O(n): Tek döngü — Örnek: Listeyi baştan sona gezmek
• O(n²): İç içe döngü — Örnek: Bubble Sort
• O(log n): Binary Search
• O(n log n): Merge Sort, Quick Sort (ortalama durum)

4. Big O, Omega ve Theta

• Big O (O): En kötü durum analizi (Worst Case)
• Omega (Ω): En iyi durum analizi (Best Case)
• Theta (Θ): Ortalama durum analizi (Average Case)

Örnek:
Binary Search algoritması, en kötü durumda O(log n) zaman karmaşıklığına sahiptir.

5. Sorting (Sıralama Algoritmaları)

Veri setini artan ya da azalan sıraya sokma işlemidir.
Gerçek dünya kullanımları: arama motorları, e-ticaret filtreleme, skor listeleri vb.

Temel Sıralama Algoritmalar

1. Bubble Sort: Komşu elemanları karşılaştırır, büyük olanı sağa iter.
   Zaman karmaşıklığı: O(n²)
2. Selection Sort: En küçük elemanı bulur ve başa yerleştirir.
   Zaman karmaşıklığı: O(n²)
3. Insertion Sort: Elemanları tek tek alıp sıralı kısmın uygun yerine yerleştirir.
   Zaman karmaşıklığı: O(n²) (ama küçük/nasıl sıralı dizilerde hızlıdır)
4. Quick Sort: Pivot seçilir, küçük elemanlar sola, büyük elemanlar sağa ayrılır.
   Ortalama karmaşıklık: O(n log n)
5. Counting Sort: Elemanların frekansını sayar, pozitif tamsayılar için uygundur.
   Zaman karmaşıklığı: O(n + k)

6. Sorting Algoritmalarının Performansı

Sonuç

• Döngüler ve Recursion, problem çözümünün temel yapı taşlarıdır.
• Time Complexity, algoritma seçiminde yol gösterir.
• Sorting algoritmaları, gerçek hayattaki veri işlemenin kalbidir.

Verimli algoritmalar yazmak, bir yazılımcının profesyonellik göstergesidir.

Özgür Ünlü(Yapay Zeka Koduna Akıl Katıyor)

Giriş: Yapay Zeka ile Üretkenliğin Kesişim Noktası

Yazılım geliştirme dünyasında üretkenliği artıran en büyük devrimlerden biri, yapay zeka destekli araçların doğrudan geliştirme sürecine entegre edilmesidir. Artık yazılımcılar için sadece kod yazmak değil, doğru sorularla yapay zekayı yönlendirmek de temel bir beceri haline gelmiştir.

Sunumlarda paylaşılan çarpıcı örneklerden biri, Cursor kullanılarak 3 ayda tamamlanacak bir projenin yalnızca 3 günde bitirilmiş olmasıdır. Bu farkı yaratan şey, sadece teknoloji değil; teknolojiyle nasıl konuşulacağını bilmektir.

Yapay Zeka ve Etkili Prompt Kullanımı

Yapay zekaya verilen komutlara “prompt” denir. Basit bir komut ile verilen talimatların kalitesi, yapay zekadan alınan sonucu direkt etkiler.
İyi bir prompt = Daha doğru, anlamlı ve hızlı sonuçlar.
Kötü bir prompt = Belirsiz ve hatalı yanıtlar.

Eğitimde Özgür Bey’in altını çizdiği en önemli konu buydu:

“AI ile konuşurken, sanki 5 yaşındaki bir çocuğa anlatır gibi detaylı ve net olmalısınız.”

Örnek:
“Bir bardak çiz” demek yerine:
“Beyaz arka plan üzerinde cam bir su bardağı çiz, içi yarıya kadar su dolu olsun ve yanından ışık vuruyor gibi görün.”

Aynı mantık kod yazarken de geçerli.
“HTML’de güzel bir iletişim formu yap” demek yerine:
“HTML’de ad, soyad (ayrı alanlarda), e-posta ve mesaj alanlarını içeren, butonla gönderilen basit bir iletişim formu ver. Veriler henüz kaydedilmeyecek ama Supabase’e aktarım için placeholder kod ekle.”

CRISPE Metodu ile Etkili Promptlar

Yapay zeka modelleri, ne yapmaları gerektiğini insan gibi “anlamaz”. Onlara detaylı, bağlama uygun ve yapılandırılmış komutlar verilmelidir. İşte burada devreye CRISPE metodu girer:

AI’yi Asistanınız veya Mentörünüz Yapın

Sunumda aktarılan stratejiler, özellikle yazılım projelerinde AI’den mentör gibi faydalanmayı öneriyor. Uygulama:

1. Büyük resmi AI’ye anlatarak planlama: “Bu projede üç modül olacak, veri API’den gelecek.”
2. Task’lara bölme ve test case yazdırma: “Her modül için edge-case testleri yaz.”
3. Kodları birleştirip refactor ettirme: “Kod tekrarlarını azalt ve dosya yapısını sadeleştir.”

Böylece AI sadece kod yazan bir araç değil, aynı zamanda bir teknik danışman rolüne bürünmüş olur.

Stajyerler İçin Yapay Zeka Kullanım Alanları

1. Yazım ve Tercüme: ChatGPT, Deepl, Grammarly.
2. Görev ve Zaman Yönetimi: Notion AI, ClickUp, Taskade.
3. Profesyonel E-posta: Compose.ai, GrammarlyGO.
4. Kod Anlama / Açıklama: Cursor, Claude AI, ExplainDev.

Live Coding ve Vibe Coding

Eğitimde canlı kodlama örneği üzerinden AI’nin nasıl yönlendirileceği gösterildi.
Vibe Coding adı verilen bu yaklaşımda, AI sanki bir kıdemli yazılımcıymış gibi kullanılıyor. Kod parçaları, test senaryoları ve hata kontrolleri tamamen yapay zekaya yöneltilen net talimatlar (promptlar) ile şekilleniyor.

“Yapay zekayı, doğru sorular sorarak ve net brief vererek kendi senior developer’ınız gibi kullanabilirsiniz.”

DNS ne iş yapar? Domain adını (örneğin youtube.com) IP adresine (192.158.1.38) çevirir. DNS, tıpkı bir telefon rehberi gibi çalışır: Siz kişinin adını yazarsınız, sistem arka planda o isme karşılık gelen telefon numarasını bulur ve aramayı başlatır.

Tarayıcı (browser) ne yapar? Tarayıcı, kullanıcının yazdığı web adresini analiz eder, ilgili IP adresini bulur ve uygun HTTP isteğini sunucuya gönderir. Sunucudan gelen yanıtı aldıktan sonra, sayfanın HTML, CSS ve JavaScript dosyalarını işler ve bu içerikleri kullanıcıya görsel olarak sunar. Bu süreci birazdan daha ayrıntılı olarak inceleyeceğiz.

HTTP ve HTTPS nedir?
HTTP (HyperText Transfer Protocol), web tarayıcımız ile sunucu arasında veri alışverişini sağlayan iletişim protokolüdür. Yani, tarayıcıdan sunucuya istek gönderilmesini ve sunucudan yanıt alınmasını sağlar.HTTPS (HTTP Secure), HTTP protokolünün şifrelenmiş ve güvenli versiyonudur. Veriler, SSL/TLS protokolleri ile şifrelenerek iletilir; böylece üçüncü kişilerin bu verilere erişmesi engellenir.

Client–Server Mimarisi Nedir?
İstemci–sunucu mimarisi, temel olarak istemcinin (client) gönderdiği istekler ve sunucunun (server) bu isteklere verdiği yanıtlar üzerine kuruludur.En basit haliyle: istemci talep eder, sunucu yanıtlar.
Bu model günümüzde web uygulamalarının temel çalışma prensibini oluşturur.

API nedir?
API (Application Programming Interface), bir uygulamanın başka bir sistemdeki veri veya işlevlere erişmesini sağlayan bağlantı arayüzüdür.
Genellikle istemci–sunucu modeliyle çalışır: İsteği gönderen taraf istemci, yanıtı sağlayan taraf sunucudur.Örneğin, hava durumu uygulaması Meteoroloji Genel Müdürlüğü’nün veritabanından veri almak için API kullanır.“Google ile giriş yap” ya da ödeme sistemlerinde banka altyapılarıyla iletişim kurmak gibi işlemler de hep API’ler sayesinde gerçekleşir.e-Devlet platformu, farklı kurum sistemlerini bir araya getiren güçlü bir API örneğidir.
Kısaca API, iki sistemin birbiriyle konuşmasını, veri okuma-yazma işlemlerini yapmasını sağlar.

SSL/TLS Nedir?

SSL (Secure Socket Layer) ve TLS (Transport Layer Security), internet trafiğini şifrelemek ve güvenli iletişim sağlamak için kullanılan protokollerdir. Temel amacı, verilerin güvenli bir şekilde iletilmesini ve üçüncü tarafların bu verilere erişimini engellemektir.

SSL, ilk olarak Netscape Communications tarafından geliştirilmiş ve daha sonra TLS olarak standartlaştırılmıştır. TLS, SSL’in güncellenmiş ve daha güvenli bir sürümüdür ve günümüzde daha yaygın olarak kullanılmaktadır. Ancak, genellikle SSL/TLS terimi kullanılarak her ikisi de ifade edilir.

Veri Güvenliği: Veriler şifrelenerek iletilir, üçüncü kişiler erişemez.

Veri Bütünlüğü: Verinin transfer sırasında bozulmadığı kontrol edilir (hash algoritmaları ile).

Kimlik Doğrulama: Sunucu kimliği dijital sertifikalarla doğrulanır (sahte sitelere karşı koruma).

SEO ve Güvenlik Uyarısı: HTTPS kullanan siteler tarayıcılar tarafından “güvenli” olarak işaretlenir, Google sıralamasında avantaj sağlar.

TCP Nedir?

TCP (Transmission Control Protocol), IP protokolü üzerinde çalışan, güvenli ve sıralı veri iletimi sağlayan bir bağlantı tabanlı (connection-oriented) protokoldür.
Veri kaybını önler, paketlerin doğru sırayla ve eksiksiz ulaşmasını garanti eder.HTTP, SMTP gibi uygulamalar bu güvenli aktarım yapısını kullanır.

Artık Hazırız: Web Tarayıcısına URL Yazıp Enter’a Basınca Neler Oluyor?

Tarayıcımıza bir web sitesinin adresini yazıp Enter’a bastığımız anda, arka planda tam olarak neler olduğunu hiç merak ettiniz mi? Bu yazıda, web geliştiricisi olarak mutlaka bilmeniz gereken birkaç temel kavram ve terimden bahsedeceğim.

Öncelikle, diyelim ki tarayıcınızı açtınız ve youtube.com gibi bir web sitesine gittiniz. Tarayıcıdaki adres çubuğunda yazan bu adrese URL (Uniform Resource Locator) denir. URL, internette bir kaynağı (örneğin web sayfası veya HTML belgesi) bulmanın yoludur.

Bunlar; resimler, video dosyaları, yazı tipleri vb. olabilir. Bir web sitesinin URL’sini yazıp Enter’a basıyoruz. Peki şimdi ne oluyor?

Burada iki parça söz konusu: Tarayıcı, istemci olarak da adlandırılır ve hedef web sitemizi barındıran bilgisayar veya bilgisayarlara web sunucuları (veya kısaca sunucular) diyoruz. Bu yapıya client-server modeli denir.
İstemci bir hizmet talep eder, sunucu ise bu hizmeti sağlar.

Tarayıcımız sunucuya bir mesaj gönderir ve şöyle der:
“Hey, bana bu web sitesinin ana sayfasını ver!”

Bu, bir arkadaşınıza kısa mesaj göndermeye benzer.
Telefondan mesajı gönderen taraf istemci, arkadaşınızın telefonu ise mesajı alan sunucu (server) gibidir.

Şimdi örneğimize geri dönelim. Bu mesaj, HTTP (Hypertext Transfer Protocol) adı verilen bir protokole göre biçimlendirilmiştir.

Muhtemelen daha önce fark etmişsinizdir: https://www.youtube.com gibi bağlantılar görmüşsünüzdür, ancak tam olarak ne anlama geldiğini bilmiyor olabilirsiniz.

HTTP, istemci ve sunucuların birbirleriyle konuşmak için kullandığı bir iletişim protokolüdür.
Bir programlama dili değildir; internet üzerinden iletişim kurmak için kullanılan düz bir metin dilidir.

Ayrıca:
HTTPS = HTTP + Encryption
Yani şifrelenmiş HTTP diyebiliriz. Bu sayede istemci ve sunucu arasındaki mesaj alışverişi şifrelenmiş olur.

İşte basitleştirilmiş bir HTTP mesajı örneği:

GET /index.html HTTP/1.1
Host: www.youtube.com
Accept-Language: en-us

Bu mesajla tarayıcı, sunucuya ne aradığını söyler.

İlk satırda, HTTP 1.1 sürümünü kullanan tarayıcının index.html adlı bir sayfayı (veya dosyayı) almak istediğini görebiliriz.
index.html genellikle web sitelerinin ana sayfalarını temsil eder.

İkinci satırda, youtube.com olan ana bilgisayar (host) bilgisini görürüz.

Üçüncü satırda ise, istemcinin kabul edebileceği dili görebiliriz. Bu durumda İngilizce (en).

Bunların hiçbirini ezberlememiz gerekmez; sadece nasıl çalıştığını anlamamız yeterlidir.

Bu mesaj, istemcilerin ve sunucuların anladığı HTTP protokolüne göre yapılandırılmıştır.
Sunucu, bu mesajı aldığında istemcinin ne istediğini anlar ve ona yanıt olarak başka bir mesaj gönderir.

İlk mesaja HTTP isteği (Request), ikinci mesaja ise HTTP yanıtı (Response) denir.
HTTP protokolünü kullanan her veri alışverişi, mutlaka bir istek ve bir yanıt olmak üzere iki mesaj içerir.

Şimdi yanıtta ne var?

HTTP/1.1 200 OK
Date: 1 Jan 2021 09:00
Content-Type: text/html

<!DOCTYPE html>
<html>
…
</html>

İlk satırda, kullanılan HTTP protokolünün sürümünü ve ardından durum kodu olan bir sayı görüyoruz. Örneğin, 200 kodu başarılı veya tamam anlamına gelir.

İkinci satırda, yanıtın tarih ve saat bilgisi yer alır.

Üçüncü satırda ise, istemciye geri gönderilen içerik türünü görebiliriz. Bu durumda, içerik metin/html türündedir. Ardından, youtube.com sitesinin ana sayfasını temsil eden HTML kodu ya da HTML belgesi gelir. Elbette, gerçek HTML kodu çok daha uzundur.

Şimdi tarayıcı, bu HTML belgesini okurken, bir DOM (Document Object Model) oluşturur. DOM, HTML belgesindeki nesneleri veya öğeleri temsil eden bir modeldir.

Peki bu öğeler nelerdir? Sayfadaki metin paragrafları, resimler, bağlantılar ve diğer bloklar gibi parçalar.

Tarayıcı, sunucudan dönen bu HTML belgesini işlerken, içindeki resimler, yazı tipleri ve diğer kaynaklara dair referanslar keşfeder. Bu kaynakların her birinin bir adresi yani URL’si vardır.

Dolayısıyla, tarayıcı her bir kaynak için sunucuya o kaynağı almak üzere ayrı bir HTTP isteği gönderir. Bu HTTP isteklerinin çoğu paralel olarak yapılır; böylece sayfa mümkün olduğunca hızlı yüklenir ve görüntülenir.

Tarayıcı, gerekli tüm kaynaklara sahip olduğunda HTML belgesini işler.
Bir HTML belgesini işlemek, aslında onu görüntülemek anlamına gelir.
Bu, sıkça kullandığımız teknik bir terimdir.

Özetle, tarayıcımız sunucuya bir HTTP isteği (request) gönderir ve bir HTTP yanıtı (response) alır.
Bu yanıt genellikle bir HTML belgesi içerir.
Tarayıcı, bu HTML belgesini okuyarak bir Belge Nesne Modeli (DOM) oluşturur ve sayfayı işler.

Tarayıcı, HTML belgesini okuyup DOM’u oluşturduktan sonra, sayfanın görünümünü belirlemek için CSS dosyalarını indirir ve uygular. CSS (Cascading Style Sheets), sayfadaki yazı tipleri, renkler, yerleşim gibi görsel tasarım özelliklerini kontrol eder.

Ardından, sayfaya işlevsellik ve etkileşim kazandırmak için JavaScript dosyaları yüklenir ve çalıştırılır. JavaScript, butonlara tıklama, form gönderme, dinamik içerik güncelleme gibi özelliklerin gerçekleşmesini sağlar.

Sayfa içindeki resimler, videolar ve diğer medya dosyaları da tarayıcı tarafından arka planda yüklenir. Bu yüklemeler, genellikle paralel olarak gerçekleşir, böylece sayfa daha hızlı açılır.

Tüm bu kaynaklar yüklendikten sonra, tarayıcı sayfayı tam anlamıyla işler ve kullanıcıya etkileşimli, görsel olarak zengin bir web deneyimi sunar.

Son olarak, tarayıcı kullanıcı etkileşimlerini takip eder; örneğin, fare hareketleri, tıklamalar veya klavye girdileri gibi olaylara tepki verir. Böylece sayfa sürekli canlı ve dinamik kalır.

Insider’daki ilk günümde elime verilen giriş kartının sadece bir kart olmadığını kısa sürede fark ettim. Kartın arkasında yer alan altı madde, kurumun vizyonunu ve değerlerini sade ama güçlü bir şekilde özetliyordu. İlk başta basit bir bilgilendirme gibi görünse de, zamanla bu altı ilkenin şirketin her köşesine işlemiş olduğunu gördüm.

Toplantı odalarında, ekranlardaki sunumlarda, ekip içi sohbetlerde…
Bu değerler sadece yazılı birer ifade değil; gerçekten yaşanıyor, karar alma süreçlerine ve günlük iletişime yön veriyordu. Insider’da kurum kültürünün afişlerde kalmayıp davranışa dönüştüğüne tanıklık etmek, benim için en etkileyici deneyimlerden biriydi.

Kerem OKUDAN (Department Introduction)

İlk staj günümde, Insider’da çalıştığım departman hakkında oldukça bilgilendirici bir sunum yapıldı. “Departman Tanıtımı” başlığı altında Kerem Bey, şirketin iş yapış şekli ve bizim departmanın rolü hakkında değerli bilgiler paylaştı.

Yazılım Satışı Değil, Hizmet Kiralama Modeli

Insider, parasını ödediğiniz sürece kullanabileceğiniz yazılımlar sunan bir teknoloji firması. Buradaki önemli fark şu: Yazılımı satın alıp sahip olmuyorsunuz, kiralıyorsunuz. Yani ne zaman vazgeçerseniz, o zaman kullanımı da sona eriyor. Teknik olarak “satış” dense de aslında bir “hizmet kiralama” modeli söz konusu.

Insider, “müşteri” yerine partner kelimesini kullanıyor. Çünkü burada kurulan ilişki sadece bir alıcı-satıcı ilişkisi değil, bir iş ortaklığı. Insider, B2B yani şirketten şirkete hizmet sunan bir firma. Dolayısıyla odak noktası sadece iş ortağı değil, onların müşterileri — yani son kullanıcılar.

Partner Success: Müşteri Başarısından Fazlası

Insider’da “Customer Success” değil, “Partner Success” bu bile şirketin jargonunun ne kadar özgün olduğunu gösteriyor. Amacımız, partnerimizin ürün ve hizmetlerini daha iyi sunmasını sağlamak. Onlar daha çok satış yaptıkça, biz de kazanıyoruz.

Departmanımızın misyonu ise net: Yazılımlarımızı partnerin ihtiyacına göre özelleştirmek. Bu özelleştirme süreci, “Optimus” adı verilen alt birim tarafından yürütülüyor.

Optimus Nedir?

Optimus bir ürün değil, bir bakış açısı. Araba örneğiyle anlatmak gerekirse: Bir araç aldığınızı düşünün. Aracı beğendiniz, ama müzik sistemini daha iyi bir sistemle değiştirmek istiyorsunuz. Gidip serviste bunu yaptırabiliyorsunuz. İşte Optimus, bu özelleştirme sürecini yürütüyor. Araba aynı kalıyor ama müzik sistemi değişiyor — tıpkı yazılımda olduğu gibi.

Burada iki seçenek var:

1. Özelliği sisteme entegre edip tüm kullanıcılara sunmak.
2. Sadece isteyen partnerlere özel hale getirmek.

Hangisini seçeceğimiz ise tamamen arz-talep dengesine bağlı.

Arz-Talep Dengesi

Kerem Bey bu konuyu şu şekilde özetledi:

• Arz yüksekse, talebi artırmaya çalışırsın.
• Talep yüksekse, ürünü arz edersin ki pazar kazanılsın.

Ürün geliştirme süreci de bu dengeyle yönetiliyor. Örneğin bir özelliği 30 partnerden 18’i istiyorsa bu durum roadmap’e alınıyor ve ürünün içine dahil ediliyor.

Insider’ın çalışma mantığı “agile” yani çevik yöntemlerle ilerliyor. Tıpkı bir fabrikanın üretim hattı gibi: Görevler Jira isimli bir proje yönetim aracıyla takip ediliyor. Her görev bir karta işleniyor ve süreç boyunca izleniyor. Çalışanların performansı da bu sistem üzerinden ölçülüyor.

Burada beyaz yaka — mavi yaka ayrımı yok; herkes aktif bir üretim sürecinin parçası gibi çalışıyor. Yapılan işlerin kalitesi, zamanında teslimi ve verimlilik çok önemli. Verimsizlik, adeta şirketin parasını çalmak gibi görülüyor.

NPS: Herkesin Geri Bildirimi Değerli

Insider, hem müşterilere hem de çalışanlara Net Promoter Score (NPS) uygulayarak geri bildirim topluyor. Bu sistem sayesinde süreçlerdeki aksaklıklar tespit ediliyor ve iyileştirmeler yapılıyor.

“Optimus” Bir İş Parçası Değil, Bir Yaşam Tarzı

Bu cümle gerçekten çok etkileyiciydi. Optimus sadece görevlerin yapıldığı bir birim değil; sürekli gelişen, partnerle birlikte dönüşen ve ihtiyaçlara göre şekillenen bir felsefe.

“Her şirketin artıları ve eksileri vardır. Hiçbir şirket kusursuz değil, zaten öyle olması da mümkün değil. Mükemmel bir yer ya da departman yoktur; mükemmeli aramak vardır.”

Bünyamin İŞERİ (Agile,Scrum,Kanban)

Agile, “insanların ve etkileşimlerin süreç ve araçlardan daha önemli olduğunu” savunan bir çalışma felsefesidir. İş yaparken ve öğrenirken de biz bu felsefeyi benimsiyoruz.

Waterfall (Şelale) Yöntemi Nedir?

Waterfall, yani şelale yöntemi, proje yaşam döngüsünün baştan sona planlandığı klasik modeldir.

• Proje başlangıcında neyin ne zaman yapılacağı net olarak belirlenir.
• Plan tamamen yapıldıktan sonra uygulamaya geçilir.
• Ürün ortaya ancak projenin sonunda çıkar.

Ancak günümüzde projelerde belirsizlikler çoktur ve bazen baştan sona tüm planı yapmak mümkün olmaz. İşte tam bu noktada Agile devreye girer.

Agile Nedir?

Agile, kısa döngülerle (sprintlerle) değeri aşamalı olarak ortaya koymayı amaçlayan bir felsefedir.

• Ürün, parçalar halinde geliştirilir.
• “İş tamamlandıysa vardır; yoksa çaba sıfırdır” prensibiyle ilerler.
• Agile’da “hizmetkar lider” kavramı ön plandadır.

Örnekle açıklarsak: Bir ev inşa edilecekse, öncelikle ne yapılacağı belirlenir, ardından kısa sürelerde bitirilebilecek parçalar halinde ilerlenir. Bu süreç, müşteri gereksinimlerinin önceliklendirilmesini sağlar.Agile bir felsefedir; amacı, kısa döngülerle değeri aşamalı olarak ortaya koymaktır. Ürünü parça parça geliştirir ve her tamamlanan işin somut bir sonucu olur. Agile’da ilerleyiş “1–0” mantığıyla işler: İş tamamlandıysa vardır, yoksa çabamız sıfırdır.

Ayrıca Agile’da “hizmetkar lider” (servant leader) kavramı önemli bir yer tutar. Bu lider, ekibin önünü açar, destek olur ancak işi doğrudan yapmaz. Ekip üyelerinin potansiyellerini en iyi şekilde kullanabilmeleri için ortam yaratır.

Agile Rolleri

• Product Owner: Ürünün sahibi, müşteri temsilcisi. Backlog’u önceliklendirir ve ürünle ilgili detayları sağlar.
• Development Team: Ürünü geliştiren ekip. İşin doğrudan sorumlusu.
• Scrum Master: Scrum sürecinin doğru işlemesini sağlar, ekip içi engelleri kaldırır ve Agile prensiplerin uygulanmasına rehberlik eder. Ekip için bir kolaylaştırıcı ve liderdir, ancak işi doğrudan yapmaz.

Predictive vs Agile

• Predictive (Waterfall): Gereksinimler baştan belirlenir ve ürün sonunda teslim edilir.
• Agile: Gereksinimler adım adım belirlenir, ara teslimatlar yapılır.

Agile’ın Uygulanışı (Agile in Action)

• Ürün istekleri (user story) Product Owner’dan alınır, küçük parçalara bölünür.
• İşin büyüklüğü süre değil, efor olarak Fibonacci serisi (1,3,5,8…) ile tahmin edilir.
• Sprintler 1–4 hafta arasında sürer.
• Her sprint sonunda çalışan bir ürün parçası çıkar.

Scrum Süreçleri

• Sprint Planlama: Sprint başlamadan önce hangi işlerin yapılacağı belirlenir.
• Daily Scrum (Günlük Stand-up): Kısa toplantılar; herkes üç soruya cevap verir:

1. Dün ne yaptım?
2. Bugün neleri yapacağım?
3. İşleri yaparken karşılaştığım herhangi bir zorluk var mı? Bu zorlukları aşmak için nasıl bir yardıma ihtiyacım var?

• Sprint Review(Gözden Geçirme): Sprint sonunda yapılan iş müşteri veya paydaşlara gösterilir.
• Sprint Retrospective(Geri Bildirim): Sürecin nasıl iyileştirileceği konuşulur.

Diğer Önemli Kavramlar

• Velocity Tracking: Ekibin ne kadar işi ne kadar sürede bitirebildiğinin ölçümü.
• Definition of Done (Tamamlanma Tanımı): İşin tamam sayılması için hangi kriterlerin sağlanması gerektiği.
• Bruce Tuckman’ın Modeli: Takım gelişim aşamalarını açıklar (Forming, Storming, Norming, Performing).

80/20 Kuralı ve Agile

Bruce Tuckman’ın modeline ek olarak,

“İşlerimizin %20’si zamanımızın %80’ini alır.”

Bu yüzden Agile’da, kullanıcı hikayelerinin %20’si ürünün değerinin %80’ini oluşturur. Product Owner’ın görevi bu kritik %20’yi belirlemektir.

Kanban Metodolojisi

Kanban, Japonca “işaret tahtası” anlamına gelir ve iş akışını görselleştirerek verimliliği artıran bir sistemdir. Toyota’nın üretim bantlarında kullanılmıştır.

• Kanban Board: İşlerin statülerini (To Do, In Progress, Done) gösteren tahta.
• Task: Her iş veya görev için kartlar.
• WIP Limit (Work In Progress): Aynı anda devam eden iş sayısının sınırlandırılması.
• Cycle Time: Bir işin başlanmasından bitimine kadar geçen süre.

Kanban’da belirli roller yoktur, ancak takım yapısına göre görevler dağıtılır: Developers, QA, Team Leader, vb.

Kanban ve Scrum Arasındaki Farklar

• Kanban belirli süreçler ve kısıtlamalar getirmez, Scrum daha yapılandırılmıştır.
• Projenin karmaşıklığı ve takım dinamiklerine göre tercih edilir.
• Kanban daha esnektir, Scrum belirli sprint döngüleriyle çalışır.

Buket YEŞİLÖZ (OKRs & KPIs in Tech)

Birçok çalışan neyi, neden yaptığını tam olarak bilmeden iş üretmekte; bu durum hem bireysel motivasyonu hem de şirket başarısını olumsuz etkiliyor. İşte tam bu noktada OKR (Objectives and Key Results) ve KPI (Key Performance Indicators) sistemleri devreye girer. Bu sistemler, belirsizliği ortadan kaldırarak herkesin net hedefler doğrultusunda çalışmasını sağlar.

Hedeflerle Yönetim Nedir?

Hedeflerle yönetim, çalışanların ve ekiplerin işlerini rastgele değil, belirli hedeflere ulaşmak için bilinçli bir şekilde yapmalarını sağlayan yaklaşımdır. Bu sayede şirket kaynaklarını boşa harcamaz, çalışanlar da yaptıkları işin neden önemli olduğunu bilir.

Örneğin, bir geliştirici için sadece “bir task yapmak” değil, “müşteri memnuniyetini artırmak için hatayı düzeltmek” anlamına gelir. Hedeflerle yönetim, sadece performansı değil, işin anlamını da ön plana çıkarır.

KPI Nedir? Ne İşe Yarar?

KPI (Key Performance Indicator), bir kişi, ekip veya departmanın performansını objektif olarak değerlendirmek için kullanılan ölçütlerdir. Genellikle sayı, oran veya zaman gibi ölçülebilir verilerle tanımlanırlar.

Örnek KPI’lar:

• Müşteri hizmetlerinde ortalama çağrı süresi: 3 dakika
• Destek taleplerine 24 saat içinde dönüş yapılması

KPI’ların amacı, yapılan işlerin ne kadar etkili olduğunu değerlendirmek ve ekiplerin güçlü-zayıf yönlerini belirleyerek gelişim sağlamak.

İyi Bir KPI Nasıl Yazılır?

• Ölçülebilir olmalıdır; çünkü ölçülemeyen bir şeyi yönetmek mümkün değildir.
• Spesifik, ulaşılabilir ve zamana bağlı olmalıdır.

Örneğin, “müşteri memnuniyetini artırmak” gibi genel bir ifade yerine,
“Her ay müşteri anketlerinden alınan puanı minimum 80 puanda tutmak” daha etkili bir KPI’dır.

KPI Örnekleri

• Satış ekibi için: “Aylık 500.000 TL satış yapmak”
• Yazılım destek ekibi için: “Taleplere ilk yanıt süresi < 2 saat”
• İçerik ekibi için: “Ayda 4 blog yazısı yayınlamak”

Her KPI, farklı rollerin performansını somut şekilde ölçer ve gelişim fırsatları sunar.

KPI Takibi ve Kullanımı

KPI’lar belirli periyotlarla (haftalık, aylık, çeyrek) takip edilip raporlanmalıdır. Düzenli değerlendirme, çalışanlara geri bildirim vermeyi ve süreç iyileştirmeyi sağlar.

Örneğin, aylık efor hedefi tutmadığında nedenleri analiz edilir: Eksik developer sayısı mı var, task eforları mı düşük, bilgi paylaşımı mı yetersiz? Bu analizler gelecekte daha etkili stratejilerin geliştirilmesine yardımcı olur.

Performans Geri Bildirimi ve KPI

KPI sonuçları bireylere ve ekiplere doğrudan geri bildirilmelidir. Ancak bu geri bildirim sadece rakamlara değil, süreçlere odaklanmalıdır. Hedefe ulaşılamaması başarısızlık değil, gelişim fırsatı olarak görülmelidir.

Liderler, KPI verilerini kullanarak kişiye özel destek ve gelişim planları oluşturabilir.

OKR Nedir?

OKR (Objectives and Key Results), bireylerin ve ekiplerin ulaşmak istedikleri vizyoner hedefleri belirlemesini ve ilerlemeyi somut olarak ölçmesini sağlayan sistemdir.

• Objective (Amaç): Motivasyon verici, net bir yön gösteren hedeftir.
• Key Results (Anahtar Sonuçlar): Bu hedefe ne kadar yaklaşıldığını ölçen, somut ve ölçülebilir çıktılardır.

Örnek:

• Objective: “Pazar lideri olmak”
• Key Results:
• 3 yeni pazara açılmak
• Müşteri sayısını %30 artırmak

OKR Nasıl Yazılır?

• Objective motivasyon verici ve net olmalı; ölçülemeyen ancak ilham veren ifadeler tercih edilir.
• Key Results mutlaka ölçülebilir ve somut olmalıdır.

Şirket ve Takım Seviyesi OKR Örnekleri

Şirket Seviyesi:

• Objective: Türkiye’de pazarlama alanında öncü SaaS markası olmak.
• KR1: 10 büyük müşteriye satış yapmak
• KR2: Dijital görünürlüğü %40 artırmak
• KR3: Ürün değerlendirme platformlarında 4.5 puan ortalaması sağlamak

Takım Seviyesi:

• Objective: Backend kod kalitesini artırmak.
• KR1: Test coverage %80’in üzerine çıkartmak
• KR2: Code review cevap süresini ortalama 12 saatin altına indirmek

OKR Yapısında Yaygın Hatalar

• Objective’lerin belirsiz olması.
• Key Results’ın ölçülebilir olmaması veya aktiviteleri tanımlaması.
• Çok fazla Key Result yazılması (2–4 arası ideal).

OKR Değerlendirme Dönemi

OKR’lar genellikle çeyrek bazında değerlendirilir. Başarı oranı %70–80 arasında olmalıdır; bu, hedeflerin hem iddialı hem de ulaşılabilir olduğunu gösterir. %100 başarı hedefin kolay olduğunu, %40 altı ise gerçekçi olmadığını gösterir.

OKR ve KPI Nasıl Birlikte Kullanılır?

Birbirlerini tamamlarlar. KPI’lar mevcut durumun ölçümünü yaparken, OKR’lar iyileştirme ve büyüme hedeflerini belirler. Örneğin:

• KPI: Destek taleplerine dönüş süresi 8 saat
• OKR: Destek dönüş süresini 3 saate düşürmek

Kapanış: Kültür Haline Getirme

OKR ve KPI sistemleri birer araçtır; asıl amaç bu araçları ekip kültürüne dönüştürmektir. Hedeflerin herkes tarafından bilindiği, takip edildiği ve sahiplenildiği bir ortam yaratıldığında hem bireyler hem de şirket gelişir.

Çağatay KANDAZ (How the Internet Works)

Bilgisayarımız internete nasıl çıkar:

Bilgisayarımızın tuşuna bastık ve kısa süre sonra işletim sistemimiz ayağa kalkacak. Bilgisayarımız hemen internete çıkmak için ethernet kartımızla iletişime geçer. Ethernet kartı, bilgisayarın diğer cihazlar ile ağ üzerinden haberleşmesi için gerekli olan elektronik komponentlerin bulunduğu bir devre kartıdır.

Ağ bağdaştırıcısı = network kartı = internet kartı = ethernet kartı
Bu terimlerin hepsi aynı anlama gelir ve aynı şeyi betimler.

Ethernet kartının doğrudan diğer cihazlarla iletişime geçebilmesi için bir adrese ihtiyacı vardır. Yani bir ethernet kartına veri göndermek istiyorsanız, o ethernet kartının adresini bilmek zorundasınız. Bu adres, 12 karakterli ve 48 bitten oluşan bir dizedir: 01:1A:7B:3C:8D:5E gibi görünür.

Bu adrese MAC (Media Access Control) adresi diyoruz.
MAC adresi fiziksel bir adrestir ve sabittir. Yani bir ethernet kartında kullanılan MAC adresi başka bir ethernet kartında kullanılamaz. Üretici tarafından MAC adresi bu ethernet kartına gömülür ve tıpkı bir “vatandaşlık numarası” gibidir. Bu ethernet kartıyla doğar, bu kartla ölür.
Bu adresi değiştirmenin tek yolu ethernet kartının üzerindeki entegre devrenin yazılımına müdahale etmektir.

IP adresine neden ihtiyacımız var?

MAC adresi ethernet kartımızın fiziksel adresidir.
IP adresi ise ethernet kartımızın mantıksal adresidir.
Yani MAC adresi bizim “vatandaşlık numaramız” ise, IP adresi bizim “ev adresimizdir”.

Bir evden başka bir eve taşındığımızda ev adresimiz değişebilir ama vatandaşlık numaramız kalıcıdır. Ağ üzerinde sağlıklı iletişim kurabilmemiz için hem MAC adresine hem de IP adresine ihtiyacımız var.

Ethernet kartı IP adresini nasıl alır?

IP almanın iki yolu vardır:

1. Manuel: El ile ethernet kartına bir IP adresi atanabilir.
2. DHCP (Dynamic Host Configuration Protocol): Son kullanıcının hayatını kolaylaştırmak için geliştirilmiş otomatik sistemdir.

Bir ethernet kartı, DHCP üzerinden IP almak istediğinde, tüm karakterleri F’lerden oluşan MAC adresine (yani ff:ff:ff:ff:ff:ff) bir broadcast çerçevesi gönderir.
Cihazın bir IP adresi olmadığı için “avazı çıktığı kadar bağırmasına” broadcast denir.

Bu çağrıya sadece tek bir cihaz, yani modem cevap verir.
Modemlerin de içinde ethernet kartı vardır, bu yüzden broadcast çerçevelerini dinleyebilir.Modemin bu çağrıya cevap verme sebebi, içinde DHCP sunucusu bulunmasıdır.

Modem, gönderilen broadcast çerçevesini duyduğunda paketi açar, bizim MAC adresimizi ve ne istediğimizi görür. DHCP sunucu, hemen boşta olan bir IP adresini hazırlar ve bize bir cevap döner:
“Bu IP adresini senin için ayarladım.”

Ethernet kartımız gelen IP adresine bakar ve eğer beğendiyse DHCP sunucusuna tekrar cevap gönderir:
“Ben bu IP’yi aldım ve kabul ettim.”

DHCP sunucusu, IP adresinin kabul edildiğini onayladıktan sonra:

• 1 adet IP adresi
• 1 adet default gateway
• 1 adet subnet mask

gönderir.

Ethernet kartımız da bu bilgilerle kendi IP adresini ayarlar. Artık cihazımız IP üzerinden haberleşebilir.

Default Gateway Nedir, Nereden Çıktı?

Şu anda aktif olarak kullandığımız IPv4 sistemi 32 bitten oluşur. Bu da 4.294.967.296 farklı IP adresi türetilebilir anlamına gelir. Ancak bu adreslerin çoğu özel IP adresleridir ve internete doğrudan çıkamaz.

Gerçekten internete çıkabilen IP adresi sayısı yaklaşık 3.3 milyardır. Bu sayı, tüm cihazlar için yetersizdir.

Peki internete çıkmak için hangi IP adresini kullanacağız?

Evimizdeki hiçbir cihaz hangi IP adresi ile internete çıkacağını bilmez. Evdeki modemimizin bize sağladığı internete çıkış kapısı vardır.
Cihazlarımız internete çıkmak için veri paketlerini default gateway’e gönderir.

Peki, MAC adresini nasıl öğreniyoruz?

Bir ethernet kartının başka bir ethernet kartına bilgi gönderebilmesi için onun MAC adresini bilmesi gerekir.
Bizim bildiğimiz sadece IP adresi, peki MAC adresi nasıl öğrenilir?

Bunu bize söyleyen şey ARP (Address Resolution Protocol)’dür.

Her cihazda bulunan bu protokol, IP adresine karşılık gelen MAC adresini bulmak için önce kendi kayıtlarına bakar. Daha önce sormuşsa cevabı oradan alır, bulamazsa yeni bir ARP talebi gönderir.

Bu da broadcast türünde bir çerçevedir:
“192.168.1.1 IP adresi kime ait?”
Bu tüm ağa yayılır ve sadece bir cihaz cevap verir:
“Bu IP bana ait, MAC adresim şu.”

Gelen MAC adresi genellikle bizim modemimizin MAC adresi olur. Çünkü biz internete modem üzerinden çıkıyoruz.

NAT (Network Address Translation) Neden Vardır?

Local IP’ler internete çıkamaz.
Bu yüzden NAT sistemine ihtiyaç duyarız. Cihazımızın kullandığı yerel IP (örneğin 192.168.1.5) NAT sayesinde, internet sağlayıcımızın verdiği public IP ile değiştirilir.

Yani NAT, tüm cihazlarımız için tek bir IP kullanarak internete çıkmamızı sağlar.
Modem, bu işlemi yapar: Yerel IP’yi siler, public IP’yi yazar.

Peki dışarıdan gelen paketler nasıl karışmıyor?

Modem, dışarı gönderdiğimiz her paket için NAT tablosuna bir kayıt oluşturur:

• Kaynak IP ve port
• Hedef IP ve port

Dışarıdan gelen cevaplar da bu tablodaki kayıtlar sayesinde doğru cihaza yönlendirilir.

Örneğin, evde iki cihaz YouTube’a bağlanıyor. NAT her cihaz için farklı bir port numarası belirler.
Cevap geldiğinde gelen porttan hangi cihazın veri istediği anlaşılır ve doğru cihaza iletilir.

DNS Nedir?

Sunucuya erişmek için IP adresini bilmemiz gerekir. Ancak IP’ler karmaşık ve ezberlemesi zordur.
Bu yüzden DNS (Domain Name System) adında bir sistem kullanırız.

DNS, alan adlarını (örneğin: www.youtube.com) IP adreslerine çevirir.

Tarayıcı, yazdığınız adresin IP’sini öğrenmek için DNS sunucusuna bir istek gönderir.
Örneğin: 8.8.8.8 Google’ın DNS sunucusudur.

DNS sayesinde domain isimleri ezberlenebilir ve kullanıcı dostu olur.

IP’nin Network ve Host Kısımları

Bir IP adresi ikiye ayrılır:
Network ve Host.

Örneğin: 192.168.1.5

• 192.168.1 kısmı network
• .5 kısmı host (cihaz)

Bu ayrımı yapabilmek için AND işlemi kullanılır.
Böylece cihaz, verdiğiniz IP’nin kendi ağına ait olup olmadığını anlayabilir.

İnternete Çıkışın Teknik Akışı:

1. Cihaz açılır ve Ethernet kartı aktif olur.

2. DHCP ile IP alınır (IP, gateway ve subnet mask).

3. DNS çözümlemesi yapılır (örneğin, useinsider.com hangi IP’de).

4. Gerekirse ARP ile MAC adresi öğrenilir.

5.Cihaz, default gateway üzerinden NAT ile internete çıkar.

6.Veri paketleri sırasıyla bina kutusu > saha dolabı > santral > router üzerinden internete ulaşır.

7.Sunucuya HTTP GET isteği gönderilir ve yanıt alınır.

HTTP & HTTPS Nedir?

HTTP (HyperText Transfer Protocol): Web tarayıcınız ile sunucu arasındaki iletişim protokolüdür.

HTTPS: HTTP’nin şifrelenmiş versiyonudur; güvenli veri iletimi sağlar.

200 OK: Her şey yolunda

404 Not Found: Sayfa bulunamadı

500 Internal Server Error: Sunucu hatası

301 / 302: Yönlendirme kodları

API Nedir?

API (Application Programming Interface), yazılımlar arasında veri alışverişi yapılmasını sağlayan yapıdır.

Örneğin: Hava durumu uygulaması, bir API üzerinden hava durumu verilerini çeker.

API genellikle GET veya POST metoduyla çalışır ve genellikle JSON formatında veri döner.

Gerçek Hayat Analojisi:

Web, bir restorana benzetilebilir:

• Kullanıcı: Müşteri
• Menü: API dökümanları
• Garson: API
• Mutfak: Sunucu
• Yemek: Veri

Kullanıcı sipariş verir, garson siparişi iletir, mutfak yemeği hazırlar ve garson kullanıcıya getirir. Kullanıcı ise güzel bir deneyim yaşar.

Sonuç:

Teknolojiyi yalnızca kullanan değil, anlayan biri olduğumuzda daha etkili çözümler geliştirebiliriz. Bir cihazın internete nasıl bağlandığını bilmek, hem sistemin işleyişini kavramamızı hem de problemlerde daha etkili müdahale edebilmemizi sağlar.

Serhat Soyuerel

1. Verimli stajın förmülleri:

Serhat Bey’in konuşması “merak” kavramıyla başladı.Her ne kadar içimizdeki korkular bazen bizi frenlese de doğru soruları sormaktan çekinmemeliyiz.“Bir soru etikse ve estetikse, herkes her şeyi sorabilir.” Insider’daki insanları “tüketmekten” çekinmemek gerektiğini de özellikle vurguladı.Kim, ne okuyor? Hangi teknolojileri kullanıyorlar? Ne üzerine kafa yoruyorlar? Bu soruları sormak, bu ortamdan en yüksek verimi almak için anahtar niteliğinde.

“Yazmak” ise staj sürecinde en güçlü araçlardan biri.Her hafta öğrendiklerimizi Medium yazılarına dökmek, bir yandan düşüncelerimizi olgunlaştırırken diğer yandan hedeflerimizi netleştirmemizi sağlıyor.

Bunun yanında okuma önerileri:

1. The Mythical Man-Month
2. Zero to One
3. How Google Works

Ne kadar çok proje görür, ne kadar çok elini kirletirsen; o kadar yetkinleşirsin.

Şu an Avrupa’nın en iyi, dünyanın ise 5. en iyi yazılım şirketindesin… Bunun farkındalığında ol ;)

2. Yaşam Sanatı:

1. Sevdiğin işi sevmek zorunda değilsin.
   Asıl önemli olan, yaptığın işin hizmet ettiği misyona tutkuyla bağlı olabilmek.(müzisyen örneğindeki gibi).

Önce emek, sonra başarı, en son ise sevgi gelir.
Ve o sevgi zaten, yolculuğun tamamına duyulan sevgidir.

2. Hayat sana her zaman iki seçenek sunar:
Disiplin ya da pişmanlık.
Seçim senin.

3. Bildirimleri kapat.
Çünkü bildirimler, başkalarının senin telefonuna kurduğu alarmdır.

4. Ve cebinde hep şu beceriler olsun:

• İyi derecede İngilizce
• Hızlı okuma

5. Her sene iş değiştirme.
Bu, firmalara kötü bir izlenim verir.Kariyerine başlarken, en az 3 yıl kalabileceğin bir yer seçmeye çalış.

6. Master yapma. En iyi master programı YouTube’da.

7. MVP minimum variable world :)

Ve kapanışta ne yaparsan yap, hep altın madalya peşinde koş.

Kerem Bozokluoğlu

Dijital Detox ve Boş Vakit Yaratmak

Meşgul olmak = kendini değerli hissetmek daha önce benim de sıkça düşündüğüm bir konuyu, birisinin yıllar önce fark edip hayatında uygulaması, bugün en çok dikkatimi çeken şey oldu.

Fırsat alanları =Boş vakit yaratmak. İyi bir zaman yönetimiyle aslında her şeye vakit ayırmak mümkün, önemli olan ne için meşgul olduğumuzu bilmek. Hatta FOMO (bir şeyleri kaçırma korkusu) nedeniyle sürekli aktif kalmaya çalışıyoruz; ama bu durumda odağımız asla sabit kalmıyor.Hiç “Yapacak bir şeyim yok” dediğinde huzursuz hissettin mi? İşte tam da burada, fırsat alanları yaratmak gerekiyor. Boş vakitlerimizi düşünme ve gelişme zamanına çevirmeliyiz.

Ve bu fırsat alanlarında izlenen bir videonun uygulanıp doğru sonuçlara ulaşıldığını duymak, benim için önemli bir kanıt oldu. Bazen sadece 15 dakikalık bir video bile, mikro öğrenme fırsatları yaratıyor; bu sayede boş vakitlerimizi düşünme ve gelişme alanına dönüştürdüğümüzde, çok daha büyük işler başarabileceğimizi deneyimleyerek öğrenmiş oldum.

En iyi fikirler, aslında sıkıldığımız ve kendimize gerçekten boş zaman tanıdığımız anlarda ortaya çıkıyor. Bu yüzden, zaman zaman kendimize bilinçli olarak “sıkılma” vakitleri yaratmamız gerektiğini fark ettim.

Bir de kendimize şu soruyu sormalıyız: Kendimi üç cümleyle nasıl tanımlarım?
Çünkü yöneticilerimizle yapacağımız birebir görüşmelerde kendimizi doğru ifade etmek çok önemli. En azından bunun üzerine düşünmek ve denemek, kendimizi daha iyi tanımamız için değerli bir adım olabilir.

Sabah yaptığın kısa yürüyüşler bile sana fark yaratma şansı verir. Düşünsene, bir gün boyunca sadece 30 dakika kendinle baş başa kalacak olsan neler yapardın, neler düşünürdün?

İş hayatında fark yaratmanın en önemli yolu, birisinden görev beklemeden kendi görevini yaratmak. Çünkü gerçekten de, eğer fark yaratmak istiyorsak, kimsenin bize sorumluluk vermesini beklememeliyiz; işleri sahiplenmeli ve inisiyatif almalıyız. Ne kadar çok sahiplenirsek, o kadar fazla farkındalık kazanır, o kadar iyi işler çıkarırız.

Beklemek, aslında tamamen pasif bir refleks. Zamanla, ekipte bazı kişiler işleri sahiplenip sorumluluk aldıkça, o ekip daha da güçleniyor. Hatta bazen bu kişiler, ekibin önünü açmak için yollarına başka yerlerde devam edebiliyorlar.

Bu yüzden “beklemek” yerine proaktif bir şekilde sürece dahil olmak, fark yaratan kişi olmanın anahtarı. Bunu yapabilmek için ise her gün kendimize şu soruyu sormalıyız:
“Bugün ben, gerçekten elimden geleni yaptım mı?”
Bu soruyu sormadıkça farkında olmadan içimize çekiliriz.

Proaktif olmak = Problemi fark edebilmek ve çözüm üretebilmek.

Söylemeden, beklemeden iş yapmak için çabalamalıyız. Eğer biri size görev vermeden harekete geçemiyorsanız, gerçekten sevdiğiniz bir alanda mısınız, bunu sorgulamalısınız. Kendinize dürüstçe şu soruyu sorun:
“Ben burada neyi sevmedim?”

İş yapmak sadece görev tamamlamak değildir; esas mesele proaktif olabilmek, yani problemi fark edip çözüm üretebilmektir. Mikro girişimcilik tam da budur. Girişimcilik illa bir şirket kurmak değildir, bazen sadece bulunduğun yerde fırsat yaratmaktır.

Unutmamalıyız: Proaktif insanlar değer yaratan insanlardır.
Ve en önemlisi; soru sormak bir zayıflık değil, bir güçtür.
Bilgisiz değil, öğrenmeye açık insanlar soru sorar.
Bu yüzden derinleştirilmiş, anlamlı sorular sormaktan asla çekinmemeliyiz.

Damla Dural

Eisenhower Matrisi :

Önceliklerimizi belirlemenin en etkili yöntemlerinden biri Eisenhower Matrisi. Yapmamız gereken işleri bu matrise yerleştirip önem ve aciliyet durumlarına göre sınıflandırmalıyız. Çünkü her zaman işler arasında net bir “deadline” (bitiş tarihi) olmayabiliyor. Örneğin, bir iş diğerinden daha önemli olabilir; ama ikisinin de kesin bir teslim tarihi yoksa odak kaybı yaşamak kaçınılmaz olur.

İşte tam da bu yüzden zaman bloklama yöntemi devreye giriyor. Zaman bloklamada önce önceliklendirilmiş bir iş listesi oluşturuyoruz. Ardından haftalık ve günlük olarak zaman aralıkları belirliyoruz. Hangi gün hangi iş üzerinde çalışacağımızı ve neyi ne zaman bitirmemiz gerektiğini netleştiriyoruz. Eğer bu işleri bir yere yazmazsak, zihnimizde sürekli “Buna ne zaman bakacağım?” sorusu dönüp durur.

Zaman bloklamanın iki önemli kuralı var:

• Bloklara sadık kalmak
• Esnek olmak (Çünkü bazı işleri tam olarak tahmin edemeyebiliriz; bu durumda stres yapmadan planı güncellemek önemli.)

Haftalık ve günlük planlama dağılma riskini azaltır. Bunun için her hafta, hatta her gün, planlarımızı gözden geçirmeliyiz. Tamamlayamadığımız işleri fark edip, planlarımızı güncelleyebiliriz.

Hedef koyarken ise SMART yöntemi devreye giriyor. Yani hedeflerimiz görsele uygun bir biçimde koymalıyız:

Tüm bu yöntemler aslında güçlü bir alışkanlık inşası.
Sürekli öğrenmeye açık olmak ve hedeflerimizi (veya senin deyiminle “almaçlarımızı”) netleştirmek bu sürecin temel taşları.

Ben de bu alışkanlıkları kazanmak için şimdiden küçük adımlar atmaya başladım.

Umur Korkut

Bu bölümde Umur Bey’in hem eğlenceli hem de öğretici videolarını izledik. Paylaşacağım linklerden sizler de faydalanabilirsiniz.

Staj,insani bağlantılar kurmaktır!

Empati != Sempati

Karar öncesi tartış -> Karar sonrası tam destek

Radikal samimiyet ile iş yerinde gerçek etki yaratmak nasıl mümkün?

Bir stajyer :)

Emrah Polatcan

Bu bölümde Emrah Bey, “Yapay Zeka = 10x Güç” yaklaşımını anlattı.
Özellikle canlı olarak yaptığı Copilot kullanarak bizelere gerçek bir proje üzerinde deneme yapması , yapay zekanın aslında bizim gücümüze nasıl güç kattığını gösterdi.Ancak sadece yapay zekaya güvenmenin yeterli olmadığını; tecrübe faktörünün bu süreçte çok önemli bir rol oynadığını da vurguladı. Yapay zekayı doğru kullanan, tecrübesiyle harmanlayan kişilerin fark yarattığına dikkat çekti.

Kerem Okudan

Kerem Bey, sektörde kullandığımız kelimelerin ne kadar önemli olduğundan ve kelimelerin kökenine dikkat etmemiz gerektiğinden bahsetti. Özellikle, teknik insanlarla aynı masaya oturduğumuzda daha etkili iletişim kurabilmek için dikkat etmemiz gereken püf noktalara değindi.Ama itiraf etmeliyim ki, benim en çok hoşuma giden kısım aslan, tilki ve tavşan hikayesi oldu! :)

Fazlasıyla farklı bir deneyimdi,İnanılmaz keyif aldığım bir 9 saat geçirdim. Hoşgeldim Insider ❤