Transaction’lar ömürlerini “commit” olarak ya da “rollback” edilerek tamamlarlar. Commit, işlemler veritabanına kaydedildi ve başarıyla bitti anlamına gelir. Rollback’te ise transaction içinde bulunan işlemlerin etkisi geri alınır, yani iptal edilir diye düşünebiliriz.

Okuma/yazma işlemlerine verilen genel ad “query”. Select, insert, update ve delete olarak dört temel query var. Select okuma, diğerleri ise yazma.

PostgreSQL’da Transactionlar Nasıl Çalışıyor

Örnek olarak “hesaplar” adında bir tablo kullanacağız. Hesabın adı ve bir de bakiyesi var. İsterseniz siz de PostgreSQL indirip bilgisayarınıza kurabilirsiniz. Böylece makaleyi okurken bir taraftan da komutları ve davranışları kendiniz deneyip pekiştirebilirsiniz. PostgreSQL güncel versiyonu 18, bendeki versiyon ise 17.

Tabloyu oluşturmak için şu komutu çalıştırın.

CREATE TABLE hesaplar (
  isim text PRIMARY KEY,
  bakiye numeric NOT NULL
);

Transaction başlatmak için iki yöntem var. “begin transaction” komutuyla başlatabilirsiniz. Veya herhangi bir query (select, insert, update, delete) çalıştırdığınızda, halihazırda bir transaction içinde değilseniz, postgresql sizin için otomatik olarak bir transaction başlatacak ve komutu o transaction içinde gerçekleştirip daha sonra da “commit”leyecektir. Teknik olarak şu ikisi aynı şey

begin transaction;
insert into hesaplar values ('selcuk', 30000);
commit;

-- bu komut başlarken otomatik bir transaction açılıyor
insert into hesaplar values ('selcuk', 30000);
-- komut bittiğinde ise transaction yine otomatik olarak commitleniyor

Bir başka deyişle, PostgreSQL’da her komut bir transaction içinde çalışıyor. Transaction’ı siz başlatmazsanız, veritabanı kendisi başlatıp bitiyor.

Transaction Isolation Seviyeleri

Veritabanları aynı anda yüzlerce farklı istemciden (client, uygulama) gelen istekleri (query) işleyebiliyor. Banka hesabına para transferi yapan tek kişi siz değilsiniz, uygulamayı aynı anda binlerce insan kullanıyor olabilir.

Veritabanında her query bir oturum (session) içinde çalıştırılır ve aynı anda yüzlerce oturum aktif olabilir. Peki sistem farklı istemcilerden gelen ve her biri farklı operasyonlar içeren, farklı farklı zamanlarda başlayan ve biten transaction’ların birbirleriyle olan ilişkilerini nasıl yönetiyor? Transaction’lar aynı anda aynı veriye erişmeye çalıştıklarında ne ile karşılaşıyorlar? Bir transaction, aynı anda devam eden başka transactionlardaki değişikliklerin ne kadarını görmeli? Birlikte nasıl davranmalılar?

SQL standardı dört çeşit davranış tanımlıyor. Bunları, transaction’da bize sağlanan esnekliğin kapsamı gibi düşünebiliriz. En laçkadan en sıkıya doğru sıralarsak:

1. Read Uncommitted

2. Read Committed

3. Repeatable Read

4. Serializable

Hangi seviyeyi istediğinizi transaction başladıktan sonra (ama herhangi bir query çalıştırmadan önce) belirtebiliyorsunuz.

begin transaction;
-- 4 seviyeden birini isteyebilirsiniz
set transaction isolation level read uncommitted;
set transaction isolation level read committed;
set transaction isolation level repeatable read;
set transaction isolation level serializable;

PostgreSQL veritabanı, standartta belirtilen dört davranışın üçünü destekliyor. Gerçek anlamda “read uncommitted” desteği yok. Arkada onu da “read committed” gibi yapıyor. Bu ne demek? Standartta tanımlanan garantiden biraz daha fazlasını, bir sonraki seviyedeki garantiyi veriyor.

Read Uncommitted

Bitmemiş transaction’lardaki değişiklikleri görebileyim.

“Read uncommitted” seviyesinde, A transaction’ı B' transaction’ında gerçekleşen ama henüz commitlenmeyen işlemin etkisini görebiliyor. Bu duruma “dirty read” deniyor, yani henüz nihai duruma ulaşmamış bir transaction’daki geçici etkiyi görmek gibi. PostgreSQL’da bu mümkün değil. Size her zaman şu garantiyi veriyor: okuduğun veri, devam eden başka bir transaction’ın yarım kalmış işlemlerinden etkilenmeyecektir.

Read Committed

Commit’leneni okuyabileyim.

Varsayılan seviye bu, eğer “set transaction isolation level…” diyip bir seviye seçmezseniz, transaction’larınız bu seviyede başlıyor. A transaction’ı B’deki değişiklikleri B commit’lendiği an görebiliyor.

-- T1 anında A kullanıcısı akiyeyi 30.000 görüyor
begin transaction;
set transaction isolation level read committed;
select * from hesaplar;                                                                                             isim  | bakiye
--------+--------
 selcuk |  30000

-- T2 anında B kullanıcısı (başka bir transaction) güncelleme yapıyor
update hesaplar set bakiye=40000;
-- burada transaction otomatik açıldı ve commitlendi

-- T3 anında A kullanıcısı (devam eden transaction'ında) güncellemeden haberdar oluyor
select * from hesaplar;
  isim  | bakiye
--------+--------
 selcuk |  40000

Eğer B commit’lemeseydi, o değişiklik A’da görünmeyecekti, A eski değeri okumaya devam edecekti. Şu şekilde deneyip görebilirsiniz:

-- T1 anında A kullanıcısı bakiyeyi 40.000 görüyor
begin transaction;
set transaction isolation level read committed;
select * from hesaplar;
  isim  | bakiye
--------+--------
 selcuk |  40000

-- T2 anında B kullanıcısı (başka bir transaction) güncelleme yapıyor
begin transaction;
update hesaplar set bakiye=50000;
-- güncelleme yapıldı fakat henüz commit'lenmedi

-- T3 anında A kullanıcısı (devam eden transaction’ında)
-- güncellemeden haberdar değil çünkü commit'lenmemişti
select * from hesaplar;
  isim  | bakiye
--------+--------
 selcuk |  40000

Repeatable Read

Başta gördüğüm değerler değişmesin.

Transaction başladığı anda veritabanı ne haldeyse (bu transaction’da yapılan değişiklikler haricinde) o halde kalsın. Diğer transaction’lar değişiklikler yapabilir fakat bu değişiklikler görünmeyecek. Örnek vermek gerekirse:

-- T1 anında A kullanıcısı
-- bakiyeyi 50.000 görüyor
begin transaction;
set transaction isolation level repeatable read;
select * from hesaplar;
  isim  | bakiye
--------+--------
 selcuk |  50000

-- T2 anında B kullanıcısı (başka bir transaction)
-- güncelleme yapıyor
update hesaplar set bakiye=60000;
-- burada transaction otomatik açıldı ve commitlendi

-- T3 anında A kullanıcısı (devam eden transaction’ında)
-- commit'lenen güncellemeden haberdar değil
select * from hesaplar;
  isim  | bakiye
--------+--------
 selcuk |  50000

Repeatable read seviyesindeki transaction’lar başlangıçta veritabanının bir “snapshot”ını alıp, commit’leninceye kadar aynı snapshot’a bakıyorlar gibi düşünebiliriz. Veritabanı bu seviyedeki garantiyi “snapshot isolation” metoduyla veriyor. Her transaction, veritabanının kendi başladığı zamandaki şeklini görüyor.

Bu seviyeyi kullanıyorsanız, uygulama katmanında transaction’ları tekrar denemeniz gerekebilir. Farz edin ki repeatable read olarak başlattığınız transaction bakiyeyi okudu ve 60000 olarak gördü. Bu esnada başka bir transaction bakiyeyi güncelledi ve commit’lendi. Repeatable read olan transaction bu aşamada gidip o güncellenen değeri tekrar güncellemek isterse veritabanı hata verecek ve transaction iptal edilecektir. Çünkü değişiklik yapmaya karar verdiğinizdeki şartlar artık değişti.

-- T1 anında A kullanıcısı
-- bakiyeyi 60.000 görüyor
begin transaction;
set transaction isolation level repeatable read;
select * from hesaplar;                                                                                             isim  | bakiye
--------+--------
 selcuk |  60000

-- T2 anında B kullanıcısı (başka bir transaction)
-- güncelleme yapıyor
update hesaplar set bakiye=70000;
-- burada transaction otomatik açıldı ve commitlendi

-- T3 anında A kullanıcısı (devam eden transaction’ında)
-- bakiyeyi güncelleyemiyor çünkü başka transaction'da değer çoktan değiştirildi
update hesaplar set bakiye=80000;
ERROR:  could not serialize access due to concurrent update

Bu hatayı alan uygulama, gerek görürse transaction’ı tekrar deneyebilir. Şartlar değiştiği için başa dönmek ve yeni bir snapshot okumak zorunda.

Serializable

Eş zamanlı çalışan transaction’lar tutarsızlık oluşturamasın.

En güçlü garanti serializable seviyesinde mevcut. Dolayısıyla en hantal olan da bu, çünkü veritabanı sizin adınıza ekstra kontroller yapıyor transaction’ların birbirini etkileyip etkilemediğini tespit edebilmek için. Bu tespit edildiğinde de, transaction’lardan bazılarını şu mesajla iptal ediyor

ERROR:  could not serialize access due to read/write dependencies among transactions
DETAIL:  Reason code: Canceled on identification as a pivot, during commit attempt.
HINT:  The transaction might succeed if retried.

Örnek olarak nöbetçiler tablosunu ele alalım ve tutarsız bir durum oluşturmaya çalışalım.

CREATE TABLE nobetciler (
  isim text PRIMARY KEY,
  aktif boolean NOT NULL
);

INSERT INTO nobetciler VALUES
  ('ahmet', true),
  ('mehmet', true);

Bu tablodan aktif nöbetçilere bakıp, bazı nöbetçileri pasife çeken bir uygulama yapmış olsak ve bu uygulamadan veritabanına eş zamanlı transaction’lar açsak. Tutarsızlığımız şu olsun: uygulamada tek aktif nöbetçi istiyoruz, ve iki transaction da farklı nöbetçileri pasife çekiyor ama birbirlerinden haberleri yok.

begin transaction;
-- Bu transaction'a A diyelim
set transaction isolation level serializable;
SELECT count(*) FROM nobetciler WHERE aktif = true;
 count
-------
     2
-- hmm, 2 nöbetçi varmış, birini pasife çekeyim
UPDATE nobetciler SET aktif = false WHERE isim = 'ahmet';
COMMIT;

begin transaction;
-- Bu transaction'a B diyelim
set transaction isolation level serializable;
SELECT count(*) FROM nobetciler WHERE aktif = true;
 count
-------
     2
-- hmm, 2 nöbetçi varmış, birini pasife çekeyim
UPDATE nobetciler SET aktif = false WHERE isim = 'mehmet';
COMMIT;

İki transaction’ın aynı anda başladığını düşünelim. Birinin okuduğu veriyi (select) diğeri değiştirdiği için (hata mesajında read/write dependency olarak geçen durum), serializable modunda PostgreSQL buna izin vermeyecek. Bu iki transaction’dan hangisi önce commit’lerse o başarıyla tamamlanacak, sona kalan dona kalacak ve hata alacak.

Eğer serializable modunda olmasaydık, ikisi de commit’leyebilecekti ve hiç aktif nöbetçi kalmamış olacaktı.

Özet

Transaction isolation seviyelerini öğrendik. Mutlaka kendiniz deneyip görün, o şekilde daha iyi pekişir. Eğer anlaşılmayan bir yer varsa da yorumlarda belirtebilirsiniz. Son olarak, PostgreSQL resmî dokümanları çok teferruatlı ve maalesef biraz robotik olmakla birlikte, transaction isolation konusundaki şu tablo anlattıklarımın güzel bir özetini veriyor.

Yapay zeka (LLM) neye benziyor, mimarisi itibarıyla nelerde iyi, nelerde kötü ve bu iş daha nerelere gidebilir?

Bu sorulara cevap arayan biri için Andrej Karpathy’den daha iyi bir kaynak yoktur.

Karpathy kim?

Yazının çıkış noktası, Andrej Karpathy’nin “ChatGPT benzeri LLM’lere detaylı bakış” videosunu izleyip çok beğenmem ve sizinle paylaşmak istemem. Burayı okuyup bu bana yeter demeyin. 3 saatlik bir video. Yazılımla uğraşıyorsanız veya bu konulara meraklıysanız bundan daha iyi bir içerik bulmanız zor. Mutlaka izleyin.

Karpathy için kısa bir tanıtım yapayım. Şu an Antrophic’te çalışıyor. Anthropic’e geçtiğini duyurduğunda yer yerinden oynamıştı. Geçmişte Tesla ve OpenAI’da çalışmış. Çekoslovakya doğumlu bir göçmen. Doktorasını MIT’de yapay zeka üzerine yapmış. Zor konuları basitçe anlatmakta usta. Kafası zaten zehir gibi. Kendisini mutlaka takip edin. YouTube kanalına abone olun, eski videolarına bakın. Pişman olmazsınız.

Video güncel mi?

Kısa cevap: evet güncelliğini koruyor.

Video 5 Şubat 2025’te eklenmiş. Son bir yılda o günden beri çok büyük atılımlar oldu. Özellikle 2025’in sonlarına doğru coding agent’lar aldı başını yürüdü. Ama LLM dediğimiz şey özünde değişmedi, çalışma mantığı aynı. İlk duyuruldukları 2018’lerden beri temel bir farklılık gelmedi. Ama modeller büyüdü, ince ayarları daha güzel yapılmaya başlandı ve tabii üzerinde eğitildikleri veri miktarı ve kalitesi arttı.

Bu yazıyı yazarken Antrophic yeni modeli olan Fable 5’i duyurdu. Şu an Twitter’da herkes bu modelin uçup kaçtığından bahsediyor. Ama arkada nasıl bir yapı olduğunu anlayınca taşlar yerine daha iyi oturuyor ve bu gibi yeni modellerden neler beklemeliyiz daha netleşiyor.

Özetle, bir yıl bu günlerde uzun gibi görünse de, LLM’ler çok değişmedi ve birazdan öğreneceğiniz yapılar halen kullanımda.

LLM Mimarisi

LLM’ler üç temel parçaya sahip. Karpathy bu üç temel parçayı, ders kitapları örneği üzerinden şöyle izah ediyor:

1. Konu anlatımı: İlk aşamada dünyadaki bütün kitapları modele ezberlettiğinizi düşünün. Buna pre-training deniyor. Inference (çıkarım) kavramı bu aşamayı ilgilendiriyor.

2. Örnek çözümlere çalışmak: İkinci aşamada, çeşitli problemler ve sorulara uzmanlarca verilen cevaplar modele öğretiliyor. Bir nevi çözümlü problemler kitabına çalışmak gibi. Bu aşama post-training, ya da supervised fine-tuning (SFT) olarak adlandırılıyor.

3. Kendi kendine problem çözmek: Modele problemi ve cevap anahtarını verdiğinizi düşünün. Çözüme kendisi gitmek zorunda. Buna da reinforcement learning (RL) deniyor.

Her adımı tek tek detaylıca inceleyeceğiz. İlk ve en büyük parçayla başlıyoruz.

1. Adım: Inference (Çıkarım)

İster ChatGPT olsun ister Gemini veya başka bir ürün, LLM dediğimiz modeller matematiksel birer ifade.

e^(3x + 5y) - 6z …

Yukarıdaki ifade gibi. Fakat çok daha fazla parametreye sahip (mesela GPT 5.5’te 10 trilyon parametre olduğu söyleniyor). Parametreleri denklemdeki katsayılar olarak düşünün (3, 5, -6). LLM’e verdiğimiz girdi önce “tokenization” denilen işleme tâbi tutuluyor ve kodlanarak rakamlara dönüştürülüyor. Mesela diyelim ki “Merhaba Merhaba Merhaba” yazdık, bu şöyle kodlanıyor

200264, 1428, 200266, 18280, 129766, 9708, 129766, 9708, 129766, 200265, 200264, 173781, 200266

Dikkat ettiyseniz “9708” sayısı iki kere tekrar etmiş (“ “, “M”, “e”, “r“ dizisini kodluyor ve bu dizi iki kere geçiyor verdiğimiz girdide)

Araya sisteme özel token’lar da enjekte ediliyor (im_start, im_end vb.) ve bu sayı dizisi modeli temsil eden ifadeye girdi olarak yerleştiriliyor. Peki bu modeller çıktı olarak ne üretiyor? Çıktı olarak bir sonraki token’ın hangi token olması gerektiğinin olasılıklarını üretiyor. Bu ne demek? Her LLM'in bir token dağarcığı var: kaç farklı token tanıyıp bildiği. Mesela ChatGPT’nin 200.000 tokenlık bir dağarcığı var. Model her çalıştığında 200.000 adet olasılık üretiyor ve daha sonra bu olasılıkların ağırlıklarını dikkate alarak rastgele bir örnekleme yapıp size bir sonraki token’ın ne olduğunu söylüyor. Hileli bir zar attığını düşünün, hilesi de şu: eğitildiği datayı taklit etmeye meyilli.

Basit bir örnek üzerinden göstermek gerekirse, diyelim ki sadece 5 token’lık bir dağarcığı olan hayali bir model olsun. Token’lar 1, 2, 3, 4 ve 5 olsun. Çıktı olarak şöyle bir şey göreceğiz:

[0.1, 0.05, 0.3, 0.15, 0.4]

Olasılıklar toplamı 1’e eşit ve bu olasılık dağılımını örneklediğimizde ortalamada her 10 örnekten 4 tanesinde cevap olarak “5” token’ını verecek model bize. Ya da her 20 örnekten sadece bir tanesinde “2” token’ını göreceğiz (0.05 olaslığa sahip). Eğer 200.000’lik bir token havuzuna sahipse, her seferinde 200.000 adet olasılık üretmiş olacak.

LLM nedir sorusuna verilecek en kısa yanıt: Bir sonraki token’ı tahminleyen matematiksel bir model.

Neden Tokenization Yapılıyor?

Token dediğimiz şeyleri birer ID gibi düşünün, bir nevî kimlik. Bir veya birkaç harf veya karakter grubunun kimliği. Ama neden böyle bir şeye ihtiyaç duyulmuş? Çünkü matematiksel ifadeye girdi olarak sayılar vermek zorundayız. Dolayısıyla yazıları bir şekilde sayılara çevirmemiz gerekiyor.

“Peki tamam burayı anladık da, neden token’lar yerine harfleri veya kelimeleri kullanmamışlar” diye düşünebilirsiniz. “Merhaba” sözcüğüne bu haliyle bir kimlik verilseydi, bu kelimenin bütününe denk gelen token 1234 gibi bir sayı olsaydı. Ya da tam tersi, her bir harfe ayrı ayrı kimlik verseydik ve “M” 1, “e” 2, “r” 3 şeklinde gitseydi. Neden bu iki şekilde değil de rastgele gibi görünen ve tek başına anlamları olmayan harf kümeleri olarak tokenization yapılıyor? Çünkü;

1. Eğer her harf bir token olsaydı, LLM’lere verdiğimiz girdiler çok uzun serilere dönüşmek zorunda kalacaktı ve bu da “context window”un çabucak dolmasına yol açıp modeli zayıflatacaktı. Her bir karakterin kendi kimliği olduğunu düşünün, en kısa yazı bile bir sürü kimlik temsil eden upuzun bir diziye dönüşecekti.

2. Eğer her kelime bir token olsaydı, en ufak bir yanlış yazım veya enteresan harf kombinasyonları LLM tarafından kodlanamayacaktı, farklı dillerdeki kelimeleri temsil etmek için her dile özel tokenlar koymak gerekecekti.

Bu sebeplerle, pratikte iki problemi de çözecek biçimde, token’lar kendi başlarına anlam ifade etmeyebilen harf grupları olarak ayarlanıyor.

Context window

Yukarıda lafı geçmişken hemen açıklayayım. Bağlam penceresi olarak çevirebiliriz Türkçe’ye. LLM’in bir seferde girdi olarak alabildiği en uzun token serisinin uzunluğu olarak düşünün. Genelde 100.000 ila 1.000.000 civarlarında bir değer oluyor ve her model için bu sabit. Bu uzunluğun büyük bir kısmı girdi olarak verilen token’lara tahsis ediliyor ve kalanı da çıktı olarak gelen token’lara ait oluyor. Biz mesela ChatGPT ile konuşmaya devam ettikçe, context window’u yavaş yavaş dolduruyoruz. Hem bizim yazdıklarımız hem onun çıktıları birleşip bir sonraki iterasyonda girdi olarak veriliyor ve böyle böyle bağlam penceresi dolmaya başlıyor.

Bağlam penceresi ne kadar geniş olursa, model o kadar büyük bir hafızaya sahip oluyor gibi düşünebilirsiniz. Bağlam penceresini aştığımızda ise, eskiden yazdığımız yazılar artık hafızadan silinmeye başlıyor. Sohbete yeni başladığımızda ise context window boş oluyor (gerçekte tamamen boş değil, sistem komutları ve bize çaktırmadan girilen başka verilerle de beslenmiş oluyor, bize daha iyi bir deneyim sunmak adına).

Bir önceki konuya, tokenization’a bağlayacak olursak (tekrar hatırlamış olalım) eğer her harf bir token’a denk gelseydi context window çok daha çabuk dolacaktı.

Pre-training

LLM modelleri geliştirirken en uzun süren safha pre-training dediğimiz aşama. Bu aşamada modellerdeki (o karmaşık matematiksel ifade) parametreler rastgele değerlerle başlatılıyor ve sonrasında devasa veri setleriyle parametreler ayarlanıyor. Yani aslında pre-training esnasında model, üzerinde eğitildiği veriyi taklit etmesini sağlayacak parametrelere yakınsatılmaya çalışılıyor. Pre-training çok büyük veriler üzerinden yapıldığı için muazzam bir hesaplama kapasitesi (binlerce GPU) ve çok uzun zaman gerektiriyor. Genelde aylar sürüyor bu aşama. Ve neticesinde modeldeki parametreler belirlenmiş oluyor. Model, eğitildiği veriye istatistiksel olarak benzer çıktılar üretebilir hale geliyor.

Modeldeki matematiksel ifade

Hep “matematiksel ifade” diyip diyip geçiştirdim. Neden derseniz, işin bu kısmı bizim için biraz kara kutu gibi. Burada “transformers” denilen bir mimari kullanılıyor ve matematiksel ifadenin de elbette belli nüansları ve hassasiyetleri oluyor. Bu, modelin öğrenme şeklini ve yeteneklerini belirleyici bir faktör. Video bu konuda detaya girmiyor. Zaten oldukça derin ve uzmanlık gerektiren bir konu. Maxwell denklemlerini düşünün (düşünemedi), ben fizik dersini o noktada kapatmıştım. Burada da maalesef kendi adıma algılayabileceğim son noktaya gelmiş oluyorum. Algılayabildiklerimizden devam edelim biz.

2. Adım: SFT (Asistanlaştırma)

Şimdiye kadar gördüğümüz kısım “next token prediction” yani bir sonraki harf dizisinin tahminlenmesiydi. Bu kendi başına ne işe yarar, mesela bir hikayeye başlarsınız LLM sizin için devamını getirir. Ama LLM’e bir soru sorduğunuzda soruya cevap alamazsınız, büyük ihtimalle sorunuza yeni sorular ekleyerek üretmeye devam eder. Çünkü LLM’i ona asistanlık rolünü verecek eğitimden henüz geçirmedik.

SFT, supervised fine-tuning’ing kısaltması. Yani modeli gözetim altında vermesini istediğimiz biçimde cevaplar verecek şekilde eğitmek. Bu iş için görevlendirlen insanlar var, kendi kendine otomatik yapılan bir iş değil.

Bu aşama “post-training” olarak da adlandırılıyor, modele temel eğitimi sonrası bir uzmanlık vermek gibi düşünebilirsiniz. Çok daha kısa sürüyor ve insanlardan yardım alınıyor. Modeli internetten toplanan verilerle eğitmek yerine, firmalar bu aşamada belirledikleri kişilere diyaloglar yazdırıyor. Şöyle veri setleri oluşturuluyor:

İnsan: 2 + 2 kaç eder?
Asistan: 2 + 2 = 4

İnsan: İstanbul’da nereleri ziyaret etmeliyim?
Asistan: İstanbul’a gelirseniz, Topkapı Sarayı’nı, Ayasofya Camii’ni ve Galata Kulesi’ni mutlaka görün.

İnsan <> asistan arasında geçiyormuş gibi üretilen diyaloglarla model tekrar eğitiliyor ve parametreler model sanki asistanmış gibi cevap versin diye “fine-tune” ediliyor (ince ayar çekiliyor).

Tekrar hatırlatmak gerekir ki, bu aşama “pre-training” aşamasından çok daha ucuza mal oluyor ve çok daha kısa sürüyor çünkü üzerinde eğittiğimiz veri seti çok daha küçük. Post-training için genelde ucuz iş gücünün olduğu ülkelerden insanlara para verip onlardan istifade ediyor firmalar.

LLM mimarisini düşündüğünüzde, modele insan gibi düşünebilmeyi öğretmek istiyorsanız, öğrettiğiniz çözüm yolları da insanların takip edeceği türden yollar olmalı. Şu problemi ele alalım:

Kötü örnekte fark ettiyseniz direkt cevapla başladık. Ama LLM’in tek boyutlu token dünyasında tek seferde neticeye varma ihtimali yok. Cevaptan başlamak, modelin eğitimi açısından mantıksız. Çünkü benzer problemi farklı sayılarla çözdürdüğümüzde ona öğrettiğimiz gibi hemen cevabı söyleyerek başlamak isteyecek. Ama cevabı hesaplamadığı için halüsinasyon görecek. Elbette burada hesaplamadan kastımız aslında hesaplama taklidi yapmak. Modele o taklidi yapmayı öğretmediğimizden çuvallayacak. Şimdi iyi bir cevap örneğine bakalım:

Eğer modelin bu tarz problemleri çözebilmesini istiyorsak, eğittiğimiz cevaplar çözüme nasıl ulaştığımızı adım adım gösteren türden olmalı. Bu örnekte olduğu gibi. Aslında biz modele dört işlem öğretmiyoruz. Zaten modelin sayılardan haberi bile yok. Onun için sadece “token”lar var. Dolayısıyla biz eğitmek için kullandığımız cevaplarda ne kadar detaya inersek, model de çözüm yolunu parametrelerinde o kadar detaylı biçimde kodlamış olacak. Ona bu fırsatı vermek için bu şekilde cevaplarla eğitmek şart.

3. Adım: Reinforcement learning (Testlere tâbi tutuyoruz)

Bu aşamada artık model asistanmış gibi davranmayı öğrendi. Tüm interneti de zaten ilk adımda yalayıp yutmuş ezberlemişti. Şimdi ise modele son bir ince ayar daha çekiyoruz ve modeli cevabı bilinen konularda sınava tâbi tutuyoruz.

2. adımdan farklı olarak, burada problemlerin çözümlerini öğretmiyoruz. Problemleri modele defalarca çözdürüyoruz. Cevaplarını gerçek cevaplarla karşılaştırıyoruz ve doğru cevaplara giden yolları ödüllendirip, yanlış cevaba götüren yolları cezalandırıyoruz. Böylece doğru çözdüğü çözüm yöntemlerinin pekiştirilmesini (reinforcement) sağlıyoruz. Yanlış çözdüğü çözüm yollarını da cezalandırdığımızdan, modeli bir daha o yoldan gitmemesi için caydırmış oluyoruz. Bu aşamada herhangi bir insan dahil olmuyor sürece, tamamen otomatik olarak yapılıyor “reinforcement learning” aşaması.

Strawberry kelimesinde kaç “r” harfi var?

3 tane var değil mi? Bir ara LLM’ler bu soruya acayip halüsinasyonlu cevaplar veriyordu. Çünkü soruyu tokenlara çevirdiğiniz an “r” diye bir harf kalmıyor, misal “Stra”, “wbe”, “rry” şeklinde tokenize edilyor. Model tek tek harf görmediği için sayamıyor. Bu arada, tek tek harf görse bile sayamazdı. Çünkü modeller aritmetik yapmıyor, istatistiksel olarak bir sonraki token’ı tahmin ediyor. Fakat yeni modeller bu tarz soruları da içerecek şekilde eğitildiklerinden artık pek halüsinasyon görmüyorlar. Ama bu demek değil ki kelime kavramına veya aritmetik yeteneğine sahipler.

Karpathy videosunda bu tarz sorular için modele “tool use” yapmasını söylüyor ve bu sayede model bir kelimedeki “r” harfini sayan Python kodunu üretip Python interpreter üzerinden “Strawberry” kelimesini de girdi olarak vererek kodu çalıştırıp kesin cevabı veriyor. Modellerin zayıf oldukları noktaları bilip, ona göre yönlendirme yapmak gerekiyor.

Modellerin bir başka eksikliği de güncel bilgiye sahip olmamaları. Dikkat ederseniz model duyurularında bir “cut-off” tarihinden bahsediliyor. Bu tarih bize modelin eğitildiği datanın hangi tarihe kadar olduğunu söylüyor. Mesela 31-12-2025 cut-off’una sahip bir modele ABD - İran savaşını sorsanız bilemez. Bu durumda model internet aramasına yönelebilir ve güncel bilgiyi oradan çekebilir. Ama modelin içerisinde bu bilgi yoktur. O yüzden mesela bir kitap özeti yaptıracaksanız, modele kitabın tamamını girdi olarak verip sonra özetlemesini isterseniz daha başarılı sonuçlar alırsınız. Aksi takdirde belki o kitap eğitim datasında yoktur veya sadece bir bölümü vardır ve alacağınız özet bol halüsinasyonlu olabilir.

Kapanış

3 saatlik bir videoyu özetlemeye çalıştım. Umarım anlaşılır olmuştur. Ama eğer anlamadıysanız, videoyu mutlaka izleyin. Görsel öğelerle de destekleyerek tane tane anlatıyor.

Bütün bunlardan benim anladığım şu:

1. LLM dediğimiz şey sonraki token tahmincisi ve eğitim verisi taklitçisi.

2. Çok büyük veri üzerinden eğitilmişler ve bu veriyi taklit edebilme yetenekleri çok iyi.

3. Eğer ihtiyaç duyduğunuz şey önceden çözülmüş problemlerse, LLM’ler işinize çok yarayacaktır.

4. Eğer ihtiyaç duyduğunuz şey yeni fikirler, farklı çıkarımlar ve perspektifler veya sağduyuysa; LLM’ler size yardımcı olamaz.

Uçaktan inince tramvaya binerek şehir merkezine 15-20 dakikada geliniyor, havaalanı merkeze çok yakın. Otelimiz Massena meydanında, şehrin merkezindeydi. Bu şekilde tüm şehri yürüyerek gezebildik. Trene bineceğimizde de istasyona 15 dakikada yürüyebiliyorduk.

Çok dalgalı olmasına rağmen denize giren insanlar vardı, muhtemelen deniz suyu yavaş yavaş ısınmaya başlamıştı. İlk gün Nice sahilinde yürüyüş yapıp, yorulduğumuzda yerel pazara girip “socca” diye yöresel bir atıştırmalık yedik. Nohut unundan yapılıyormuş, çok alakası olmasa da gözlememsi bir yiyecek olarak tanımlayabilirim.

Nisan ayı olmasına rağmen hava oldukça sıcaktı. Buralara yazın ortasında gelinmez diye düşünüyorum, ya da gelinir ama deniz tatili şeklinde planlamak lazım. Çok sıcak bir memleket, klasik Akdeniz havası hakim.

Şehre tepeden bakan parka çıkarken biraz yorulsak da, manzara ve parkın güzelliğine değiyor. Akdeniz akşamları burada da güzel :) Millet sahile akın ediyor, spor yapanlar, mehtabı seyredenler, denize girenler, müzik dinleyenler...

İkinci gün film festivaliyle meşhur komşu Cannes (kan) şehrine günübirlik geçtik. Yarım saatte bir tren var, fiyatlar gidiş geliş 20 euro civarındaydı. Trenlerden güzergah üzerinde istediğiniz durakta inip binip devam edebiliyorsunuz. Tekrar bilet almanız gerekmiyor.

Cannes da güzel bir şehir, oldukça sakin ve huzurlu bir ortam var. Cuma namazını Medine-i Münevvere camiinde Fransız din kardeşlerimle kıldım. Ömrümde dinlediğim en uzun hutbe rekorunu da bu camide egale etmiş oldum.

Dönüşte Antibes (antib) kentine uğradık. Eğer buralara gelirseniz mutlaka görün, bence Cannes’dan daha güzel. Eski şehir içindeki sokaklara dalın, sonra surların üstüne çıkıp kıyıya vuran dalgaları seyredin. Herhangi bir kafede oturup kahve için. Nereden kahve aldıysak hepsini beğendik.

Üçüncü gün bu kez İtalya istikametine, yani doğuya doğru gittik. Gittiğimiz yerler Nice’ten en fazla 40-45 dakika uzaklıkta yerlerdi, yollarda fazla vakit geçirmemek için yakın yerleri gezmek istedik. Limonuyla meşhur Menton şehrine vardık. Menton’da tepedeki kiliseye çıkan dar sokaklara vurduk. Taa en tepeye, mezarlığın olduğu yere kadar çıktık. Muhteşem bir manzara eşliğinde mezar taşı okuduk ve yorumladık :)

Aşağı inerken bu kez şehrin diğer tarafına doğru geçtik ve kilisenin altındaki ünlü sarı renkli merdivenlerden sahile düştük. Yayalara da açık olan ve şehrin kurulduğu tepeyi delip geçen tünelden tren istasyonuna doğru giderek Monaco’ya giden bir trene atladık.

Monaco, Menton ve Nice’in ortasında yer alıyor. Çok tepelik ve yüksek yamaçların olduğu, üst üste binalardan müteşekkil daracık bir ülke. Monaco, Vatikan’dan sonra Avrupa’nın en küçük ülkesi. Fransa’nın şehri gibi görünse de, kağıt üstünde bağımsız bir ülke.

Biz gittiğimizde Monaco grand prix’ine birkaç hafta kalmıştı, o yüzden pisti oluşturan yolların kenarına barikatlar kurulmuştu ve yaya trafiği belli yerlerden verilmişti. Bir şekilde yolumuzu bulduk ve meşhur Fairmont Monte-Carlo otelinin altından geçen tünele girdik. Formula 1 arabaları bu tünelden geçerken öyle bir ses çıkarıyor ki, ben TV’de izlerken bile zevkten dört köşe oluyorum.

Monaco zenginlerin yoğun olduğu bir yer, sokakta Ferrari görünce dönüp bakmıyorsunuz bile bir süre sonra. Acayip arabalar var.

Saat 3-4 gibi hafiften acıkmıştık, güzel manzaralı hoş bir kafeye oturduk. Ançüezli (hamsili) pizza ve trüf mantarlı risotto aldık. Risotto karambole geldi. Aslında sadece pizza alacaktık, ara öğün gibi. Garson fransızca risotto falan bir şeyler dedi, ben de 20 yıl evvel hafif yollu bir fransızca tedrisatı görmenin verdiği özgüvenle garsonla konuşmaya başladım. Ve zannettim ki o güne özel bir kampanya varmış da pizza alana risotto bedavaymış. Saflığa bak, sanki dominos pizzaya gitmişiz de bir alana bir bedavaymış. Ne kampanyası… Hesap gelince anladık ki, o güne özel spesyal olarak risotto varmış. Garson bana günün spesyalini anlatıyormuş.

150 euro hesap ödedik ya neyse.

Aslında aklımızda Monaco’ya çok yakın olan Eze’ye de uğramak vardı fakat saat geç olmuştu. Otelimize döndüğümüzde ayaklarımıza kara sular çoktan inmişti. Akşam hafif bir şeyler atıştırdık, çünkü Monaco’daki kafede kampanyadan istifade ederek karnımızı iyi doyurmuştuk.

Pazar günü ise sabahtan otelden ayrıldık ve güney Fransa kaçamağının sonuna geldik.

Geçen aylarda freelance çalışmaktan bıktığımdan dem vurmuştum. Gerçekten sıkıldım artık. Yalnız sürekli ofiste bulunamayacak kadar da esnek çalışma şartlarına alıştım. O yüzden ara bir çözüm olarak hibrit işlere bakayım dedim. Hibrit => Türkiye. TR’deki maaşlar yurtdışına çalıştığınız zaman kazanacağınızın yarısı. Hele şimdi %100 vergi istisnası gelince, yurtdışı daha da cazip hale geldi maddi olarak. O yüzden ne kadar sıkılsam da, yurtdışından devam edeceğim gibi görünüyor. Şurada kaç yıl daha mühendislik yapabilirim? Zamanım daralıyor. Kalan vaktimi verimli değerlendirmem lâzım.

Yurtdışı piyasa hareketli. Birçok firmanın açık ilanları var. Neredeyse hepsi senior roller için. Şimdilik başvuru yaptığım yerler şöyle:

• Buffer

• Zapier

• Gradle

• Gitlab

• Ghost

• Elastic

• Chess.com

• Linear

• Duckduckgo

• Sezzle

• Ounass

Birkaç tanesi daha CV’den eledi bile. Bakalım nereye varacak diğerleri, göreceğiz. Bir yandan da Toptal üzerinden ilanlara başvurmaya devam ediyorum. Fakat orada da rate’ler düşmüş. İnatla kendi rate’imden başvuruyorum ama tabii dönüş yapma ihtimalleri oldukça düşük.

Toptal’a benzer Andela diye bir platform var, kayıt oldum. İlk aşamada online bir değerlendirme testi yaptılar. Cloud engineer kimliğimle girdiğim için, gelen sorular daha çok bulut mimarisi vb. sorulardı. Test çok hoşuma gitti. Kod falan yazdırmıyorlar.

Üç bölüm var, her bölümde bir senaryo verip o senaryoya göre bazı şeyler anlatmanızı istiyorlar. Mesela ilk senaryoda prod’da hata alan bir uygulamadan bahsediyordu, uygulamanın mimarisini anlatmış, ne zaman hata almaya başladığı gibi bazı detaylar vermiş. Sizden bu hataların neden kaynaklı olabileceği yönünde teoriler üretmenizi istiyor. Keyifle çözdüm bu aşamayı. Şimdi biriyle online görüşme yapacağım son aşamada, ondan sonra platforma dahil oluyorum inşallah.

Suboptimal Süreçler

Bazı firmalar acayip sinir bozucu ilan başvuru süreçlerine sahip. Bir sürü saçma sapan sorular sorup, bin dereden su getirtiyorlar. Mesela linear, daha başvuru yaparken insanı bezdiriyor, soruya bakın:

What would you want to work on? Tell us about the features you would want to implement in your first month.

Ya da şimdi hangi firmaydı hatırlayamadım ama şöyle bir soru vardı:

Please tell us about the time you most successfully hacked a non-computer system to your advantage.

Elbette amaçları insanları elemek, ama ne bileyim bana daha CV’me bakma aşamasında bunları sormaları hoşuma gitmiyor.

Sonra bir de mülakatlarda yok bize neler katacaksın, yok efendim bizi tercih etmendeki motivasyonun ne gibi lüzumsuz sorular gelecek. Size neler mi katacağım; doğru, dürüst, ilkeli belediyecilik.

Yaş kemâle erdiğinden midir nedir, artık heyecanlıymış gibi yapamıyorum. Kariyerimin başlarında gerçekten heyecanlıydım. Sonra tabii her şey normalleşiyor, heyecan falan kalmıyor ama en azından heyecanlıymış gibi görünebiliyordum. Artık onu da yapamıyorum.

Kafamdaki ideal mülakat süreci şu:

1. CV’me bakarlar, tecrübemi değerlendirirler

2. Online bir test, yukarıda bahsettiğim türden mesela.

3. 1-1 teknik mülakat, yaptığım işler üzerine sohbet şeklinde

4. Zor bir problem verirler, o konuda high-level bir çözüm üretirim ve çözümü tartışırız

5. Teklif verirler

Hayalimdeki İş

İsterdim ki,

1. Müşteriye doğrudan etki edebileyim, hayatını kolaylaştırabileyim

2. Etki alanım geniş olsun, inisiyatif alabileyim

3. Asenkron çalışma kültürü olsun, slack vb. anlık mesajlaşma uygulamaları yerine bilgi ve birikim issue tracker gibi yazılı ortamlarda kayıt altına alınsın

4. Uçtan uca tüm geliştirme süreci benim sorumluluğumda olsun, tasarımdan tutun da canlı ortamların bakımına kadar

5. İş çok yoğun olmasın, iş dışında da bir hayatım olsun

Eğer tavsiyeleriniz veya paslayacağınız bir ilan varsa duymak isterim.

• Daha hızlı üret.

• Daha hızlı yaz.

• Daha hızlı tasarla.

Hız, hız, hız. Bu hıza ayak uydurmaya çalışırken, düşünme işini ikinci plana attık.

Yapay zeka bizim yerimize üretebilir ama bizim yerimize düşünemez. Düşünmenin kestirmesi, alternatifi yok.

TLDR;

• Yapay zeka bir şeyler üretiyor da, problemi anlıyor mu? “Çalışan çıktı” ile “doğru çözüm” arasında bir uçurum olabilir.

• Problemi anlamadan üretilen çıktı, çözülmemiş bir sorunun üstüne giydirilmiş süslü bir örtü gibi.

• Düşünme süreci bir maliyet değil, asıl değer. Yapay zeka bu süreci hızlandırmıyor, tamamen atlıyor.

• Düşünmeyip doğrudan kolları sıvayarak üretime geçtiğimizde, yarın çok daha büyük borçlarla uğraşıp vakit kaybı ve kalitesiz ürünlerle baş başa kalıyoruz.

Düşünme İşi Hâlâ Bizde

Amazon’un meşhur liderlik prensiplerinde “working backwards” diye bir ilke var. Bir ürünü inşa etmeden önce, basın duyurusunu yazıp bazı sorulara cevap arıyoruz:

• Müşteriye ne söyleyeceğiz?

• Hangi problemi çözüyoruz?

• Müşteri neden umursasın?

Bu egzersiz bizi çıktıdan geriye, probleme doğru düşünmeye zorluyor. Çoğu zaman basın bültenini yazmaya çalışırken fark ederiz ki aslında problemi yeterince anlamamışız.

Yapay zeka araçları ise tam tersini teşvik ediyor. “Şunu yap” diyoruz, makine yapıyor. Problem tanımı yok, bağlam analizi yok, alternatif değerlendirmesi yok. Doğrudan çıktı. Ve çıktı makul göründüğü için, problemi gerçekten anlayıp anlamadığımızı sorgulamıyoruz bile.

Süreç Maliyet Değil, Asıl Değer

Bir şeyi yazarak öğrendiğimi fark ettiğimden beri yazıyorum. Bu blog’un varlık sebebi de bu aslında, bildiklerimi ve öğrendiklerimi pekiştirmek. Yazmak düşüncelerimi organize etmeye zorluyor beni. Kafamdaki bulanık fikirler, yazıya dökülürken netleşiyor.

Tasarım da aynı şekilde çalışıyor. Bir arayüzü elle çizerken, bir mimariyi beyaz tahtada şekillendirirken, bir veri modelini tartışırken; aslında bu süreçler zaten düşünmenin ta kendisi. Bunları yaparken fark ederiz ki bir varsayımımız yanlışmış, bir gereksinimi atlamışız, iki şey birbiriyle çelişiyormuş.

Hız Yanılgısı

“Ama çok hızlı üretiyoruz, bu iyi bir şey değil mi?”

İyi bir şey; koşullu olarak. Eğer problemi zaten anladıysak ve üretim aşamasında yapay zekayı kullanıyorsak, harika. Prototipleme, keşif, alternatif üretme vb. işlerde yapay zeka gerçekten işe yarıyor.

Ama eğer problemi henüz anlamadıysak ve yapay zekanın ürettiği çıktıyı “çözüm” olarak kabul ediyorsak bir yanılsamanın peşinde koşuyoruz demektir. Test dünyasından bir benzetme yapayım. Testlerimiz geçiyor ama yanlış şeyi test ediyorsak, o yeşil tiklerin hiçbir değeri yok. Hatta zararlı, çünkü sahte bir güven veriyor. Yapay zekanın ürettiği çıktılar da benzer: sahte bir “hallettik” hissi.

Ne Yapmalı?

Yapay zekayı kullanmayalım demiyorum. Ben de kullanıyorum, hem de giderek daha fazla. Ama düşünme sürecini korumanın bilinçli bir çaba gerektirdiğine inanıyorum. Çünkü yapay zeka beni düşünmekten alıkoyuyor gibime geliyor. İnsan zaten kolaya kaçmaya meyilli. Yapay zeka ile kolaya kaçmak eskisinden de kolay :)

Peki, ne yapabiliriz?

• Önce problemi anlayın. Yapay zekaya “çöz” demeden önce, kendinize “ne çözüyorum?” diye sorun. Bunu bir cümleyle açıklayamıyorsanız, henüz hazır değilsiniz. Bu aşamada biraz daha vakit harcamanız gerekiyor demektir.

• Süreçten kaçmayın. Elle çizmek, beyaz tahtada tartışmak, pair programming yapmak — bunlar “yavaş” yöntemler değil. Bunlar düşünme yöntemleri. Düşünmenin kestirmesi yok.

• Makul görünene şüpheyle yaklaşın. Yapay zekanın en tehlikeli özelliği ikna edici olması. Çıktı akıcı ve kendinden emin görünse bile bir adım geri atıp “bu gerçekten doğru mu?” diye sorun.

Yapay zeka araçları gelişmeye devam edecek, daha hızlı üretecek, daha akıcı konuşacak, daha ikna edici olacak. Ama düşünme işi bizde kalacak. Çünkü düşünmenin alternatifi henüz yok.

Okuduğunuz için teşekkürler! Yazılarımı takip etmek için ücretsiz abone olabilirsiniz.

Evvel zaman içinde…

Yeni mezun olarak girdiğim İş yerinde “source control” namına bir şey yoktu. Git kullanmadığınızı düşünsenize, kaos. Gitsizlik sendromu. Ben de duymuşum ki var böyle bir şey. Biraz mızmızlandıktan sonra dedim bari en azından kendi makinamda bir svn (subversion) kurup projelerimi versiyonlayayım. Commit’lerimi düzenli olarak yapmaya gayret ettim, benden başka kimse görmese de. Çıktığım release’lerin versiyonlarını bir kenara not etmeye başladım. Bu sayede yazılım geliştirme döngümü az da olsa iyileştirdim. Hem işlerim kolaylaşmıştı, hem de kendimi iyi hissetmiştim trendleri takip ettiğim için.

Benzer bir durum özellikle bankacılık sektöründe faaliyet gösteren veya bir sebeple elindeki veriyi public cloud’a veremeyen şirketlerde yaşandı. Bulut bilişimin patlamasıyla birlikte uygulamaların canlıya alınması ve operasyonları oldukça kolaylaştı ama regülasyonlar sebebiyle birçok organizasyon bu nimetlerden faydalanamadı. Fakat ara çözümler bularak cloud mantığını kendi data center’larına taşıdılar ve uygulama geliştiricilerin hizmetine sunmaya çalıştılar.

Geldik yapay zeka çağına. Elimizin altında daha önce görmediğimiz bir yetenek, adeta bir sihirbaz var. Belki çalıştığınız şirket yapay zeka aboneliğinizin ücretini karşılamıyor. Veya veri dışarı gitmesin diye komple yasaklamış olabilirler. Ne olursa olsun, her durum için kendi kısıtları içerisinde bir ilerleme şansı var.

Diyelim ki iş yerinde yapay zekaya resmî olarak henüz geçmediniz. En azından geçişe hazırlanabilirsiniz. İnsanların kafasında bulunan bağlamı dokümantasyonlara dönüştürüp bilgi havuzunuzu inşa etmeye başlayabilirsiniz. Kimse sizin için doküman yazmasa da, kendi kendinize bu inisiyatifi alıp işe koyulabilirsiniz. Çözdüğünüz problemlerin çözümlerini bir kenara yazıp, benzer durumlarda başvuracağınız bir kaynak oluşturabilirsiniz. Projelerde hatırı sayılır büyüklükteki her değişiklik için neden/nasıl sorularına cevap verecek mimari veya tasarım dokümanları yazabilirsiniz. İlk kez baktığınız bir uygulamaya (“bu nasıl çalışıyor acaba” diye kurcalarken) müşteri gözüyle yaklaşıp bir kullanıcı kılavuzu yazabilirsiniz. Gün gelip de yapay zeka araçlarına geçtiğinizde, elinizin altında kullanıma hazır bir bağlam olur.

Yeniliklere kapalı veya hantal bir organizasyonda çalışıyor olabilirsiniz. Bu hiçbir şeyin iyileşemeyeceği anlamına gelmiyor. Yapılacak ufak tefek ama katma değerli dokunuşlar her zaman var. Bu işlere ya hep ya hiç mantığıyla bakmayın. Bunca verimsizliğin içinde ben mi işleri düzelteceğim demeyin. Hayattaki hemen hemen her şey gibi burada da bir spektrumdayız. İbreyi olumlu yöne kıpırdatmakta tereddüt etmeyin. Bir de bu işler bulaşıcıdır. Bakarsınız aynı bakış açısı ekibe sirayet etmiş. Oradan diğer ekipler sıçramış.

Bu şekilde düşündüğünüzde, yapılacak çok şey var aslında:

• Dokümantasyon mu yok, sen başlat, ilk dokümanı sen yaz

• Test mi yok, ilk testi sen yaz

• Sürekli prod’dan hata mı geliyor, her seferinde sana ne kadar süreye mal olduğunu bir kenara logla, ay sonu raporla: “şu şu iyileştirmeleri yaparsak bu kadar saat cebimizde kalacak”

• Çalışanlar için bir eğitim bütçesi ve planlaması mı yok, patrona durumu izah et: az bir yatırımla hem çalışan memnuniyeti ve bağlılığını hem de şirketin bilgi birikimini artırabileceğinizi anlat.

Her şey bu kadar hızlı hareket ederken, insan bir noktada “amaaan kim yetişecek” demeye meylediyor. Yetişip yetişmemek dert değil. Ama olduğumuz yerde de çakılıp kalmayalım.

Chamonix doğada vakit geçirmeyi sevenler için çok uygun. Dağcılık, kayak, rafting, yamaç paraşütü, aklınıza ne gelirse. Annecy’ye göre burada vakit geçirmek için daha çok şey var, o yüzden üç günlük bir ziyaret planladık.

Geniş bir vadide yer alan büyük bir düzlüğe kurulu. İçinden akan ve şehri ikiye ayıran bir dere var. Derenin güney tarafı daha yüksek tepelerin olduğu bölge. Bu taraftan teleferikle 3800 metre yükseklikteki Aiguille du Midi tepesine çıkılabiliyor. 4800 metrelik zirve olan Mont Blanc da bu tarafta yer alıyor.

Derenin kuzey tarafında, fotoğrafın solunda, Le Brevent tepesi ve orada yer alan kayak tesisleri bulunuyor. Şehre vardığımız gibi eşyalarımızı otele bırakıp Le Brevent’a çıkan teleferiklerin kalktığı noktaya gittik. Saat dört civarı artık son teleferik seferleri yapılıyor. Ara istasyona giden son sefere bindik, ama maalesef zirveye çıkan teleferiğe yetişemedik. Yine de güzeldi. Açık bir hava vardı ve Chamonix’yi tüm detaylarıyla tepeden izledik.

İlk akşam, helal sertifikalı bir Hint restoranında yemek yedik. Zaten başka da helal restoran göremedik. Ama diğer restoranlarda vejeteryan seçenekler çok, o yüzden problem olmuyor. Yemekler yine lezzetliydi. Bir öğün yemek için fiyatlar kişi başı 30 euro civarında.

Chamonix’de toplu taşıma araçlarını kullanmak pek gerekmiyor. Ufak bir yer ve düzlük olduğundan merkez bölgede yürüyerek gezebiliyorsunuz. Ama ihtiyaç duyarsanız da sık seferlerle kayak merkezlerine gidip gelen belediye otobüsleri var. Bunlar için bilet almanız gerekiyor. Eğer kayak merkezine giriş kartı alırsanız, otobüsleri ücretsiz kullanabiliyorsunuz.

Şehirdeki ikinci günümüzü kayak yapmaya ayırdık. Sağolsun otelin resepsiyonundaki görevli bizim için ESF adındaki kayak okulundan özel ders ayarladı. Derslerin saatlik ücreti 70 euro civarında. Ailecek alabiliyorsunuz. Hayatımızda ilk kez kayak yapacağımız için işi bilen birinden ders alalım dedik. İyi ki de almışız, kendi kendine öğrenilecek bir şeye benzemiyor.

Kayak için diğer harcamalar: kişi başı 30 euroluk kayak merkezi kullanım ücreti ve yine yaklaşık 30 euro tutan ekipman kiralama.

Chamonix’de başlangıç seviyesindekiler için en uygun kayak merkezi Les Planards. Bizim ders de buradaydı. Nispeten tenha bir yer ve konforlu. Restoran, kafe vb. tesisler bulunuyor. Kayak pistindeki karlar suni olarak yapılmıştı. Biz gittiğimizde şehirde kar yoktu.

Gelelim günün sonuna. Kayak zaten yorucu bir spor. Bir de biz kayak takımlarını ucuz olsun diye dışarıda kiralayıp onca ağırlık ve o rahatsız botlarla kayak merkezine gidip gelince yorgunluktan canımız çıktı. O gün erkenden yatıp uyuduk.

Kayak konusunu kapatmadan önce birkaç tespit ve tavsiyem var:

1. Kayakları, kayak botlarını, batonları, kaskları vb. araç gereçleri kayak merkezine mümkün olan en yakın yerden kiralayın. Taşımak çok büyük eziyet.

2. Mümkünse kayak botlarını hemen giymeyin, kendi ayakkabınızla kayak merkezine gelip ayakkabılarınızı orada bir dolaba kilitleyin. Diğer türlü, bizim gibi kayak botlarıyla yolda yürümekten ayaklarınız mahvolur.

3. İki veya üç saat ders fazlasıyla yeterli. Biz dört saat aldık, sonlara doğru dizlerimiz tutmamaya başladı. Çok yorucu.

4. Uygun kıyafetler giyin. Su tutmayan kayak pantolonu ve kayak montu konforunuzu artırır. Ben inat edip kendi paltomla kaymıştım, hem içten terleyerek hem de dıştan yere düştükçe sırılsıklam oldum.

5. Sakın ben bu işi kaptım diye gaza gelip riskli işler yapmayın. Bir yerinizi kırabilir veya dizlerinizin bağını falan yırtabilirsiniz. Efendi efendi kayın. Tatil yerinde bir de hastane işleriyle uğraşmak zorunda kalmayın.

6. Kaç yaşında olursanız olun deneyebilirsiniz, göründüğü kadar zor değil. Biz sıfır kayak bilgisiyle dersin ilk saatinin sonlarına doğru basit pistte kaymaya başlamıştık.

Chamonix’deki son günümüzde Montenvers trenine binip yakındaki bir buzul mağarasına gittik. Bu tren yarım saatte bir kalkıyor ve Mer de Glace’a yani buzulların olduğu yere gidiyor. Oradan da bir teleferikle buzulların yanına iniliyor. Buraya gitmenizi tavsiye ederim, inanılmaz manzaralar var. Koca dağların arasında pek güneş almayan bir yerde bulunuyor. Denizdeki dalgalar gibi görünüyor, 7.5 km uzunluğunda 200 metre derinliğinde bir buzul.

Buzul mağarasına inmek isterseniz, tren + teleferik gidiş geliş toplam 40 euro civarı tutuyor. Mağaraya inişte çok merdiven var, asansör yok maalesef. Dönüş yorucu oluyor, sağlık ve yorgunluk durumunuza göre karar verin. Eğer buzul mağarasına inmeyecekseniz daha ucuz olan bileti alıp sadece treni kullanabilirsiniz. Biletler tren istasyonunda satılıyor. Trende gidiş istikametinde sol tarafa oturursanız daha çok manzara var.

Buzul ziyaretinden sonra şehre döndük. Tren istasyonu kayak yaptığımız Les Planards’ın yanında bulunuyor. Kayarken rollercoaster tarzı bir oyuncak görmüştük, ona binmek için tekrar tesise girdik. İki kişi veya tek kişi binebiliyorsunuz. Hızı da fena değil, iki tur bindik. Bir turun fiyatı 10 euro. Çocukların çok seveceği bir oyuncak.

Üçüncü günün sonunda şiddetli kar yağışı başladı ve sabah uyandığımızda her taraf bembeyazdı. Online rezervasyon yaptırdığımız otobüs otelin hemen yanından kalkıyordu. Chamonix’ye karlı bir günde veda edip Cenevre’ye geçtik. Cenevre’nin detayları da bir sonraki yazıda inşallah.

Yolculuk

Alp Dağları Allah’ın sayısız lütfundan biri. Baktıkça insanın içi açılıyor. Tatilden önce Youtube’dan tırmanış ve dağ yürüyüşü videoları izleye izleye bölgeye ısınmaya başlamıştık zaten. İlk durağımız Fransa - İsviçre sınırında yer alan ufak bir şehir olan Annecy (annesinin bi tanesi) oldu.

Sabiha Gökçen’den Cenevre’ye yaklaşık üç saatlik bir uçuşun ardından Cenevre havaalanından 272 nolu belediye otobüsüne bindik ve direkt gidilse 45 dakika sürecek yolu dolaşa dolaşa 90 dakikada aldık. Keşke şehirlerarası otobüslere binseymişiz, yolu çok uzatmış olduk.

Şehir

Annecy’de airbnb’den kiraladığımız ev tam şehrin merkezindeydi. Bu da gezimizi kolaylaştırdı, yoruldukça eve geçtik dinlenmeye. Tam bir tatil yöresi Annecy, insanlar çok rahat ve hayat yavaş akıyor. Gitmeden araştırmıştık, herkes çok güvenli bir yer olduğunu söylüyordu, biz de öyle hissettik.

Şehir gölün yanına kurulmuş. Göldeki su tertemiz. Oldukça sığ başlıyor, suya girseniz dizinize gelir ancak. Gölle bağlantılı ufak dereler şehrin içinden kanallardan akarak geçiyor. Bu yanıyla biraz Venedik’e benzetiliyor.

Yeme İçme

Yemekler lezzetliydi. Meşhur peynir fondüsü ve envai çeşit peynirleriyle peynir severler için bu bölge ideal. Şehir ufak olduğundan, çabucak gezip bitirebiliyorsunuz. Dolayısıyla iki günden fazla zaman ayırmaya gerek yok şehir merkezine. Biz iki gece kaldık ve fazlasıyla yetti.

Yerel pazar kuruluyor bazı günler. Denk geldik şansımıza, peynir reçel vs. aldık biraz. Vakumlattık, zaten kış olunca bozulma ihtimali pek yok.

Değişik aromalı çayları çok seviyorum. Her gittiğim yerde gözüme kestirdiğim dükkanlardan çay alırım. Annecy’de de Les Notes de Thé isimli dükkandan vanilya aromalı bir çay aldım. Dün akşam demledik, oldukça güzel. Dükkanın sahibi ile biraz muhabbet etmiştik. Meğer kızı Türkiye’ye staj tarzı bir program için gelmiş ve burada zeytinliklerde çalışıp zeytin toplamış.

Sıradaki Durağımız

Annecy’de iki gün kaldıktan sonra yine Fransa’ya bağlı olan Chamonix kentine, bu kez şehirlerarası bir otobüsle, yola koyulduk. Chamonix de bir sonraki yazıda inşallah.

William Zinsser’in “On Writing Well” (iyi yazmak üzerine) kitabı bu konuda yazılmış en iyi kitaplardan biri. Yazarken dikkat etmemiz gereken püf noktaları eğlenceli bir şekilde anlatıyor. “Şunu yapın, bunu yapmayın” gibi somut tavsiyeleri çeşitli metinlerden örneklerle adeta gözümüze sokuyor.

Kitap İngilizce dilinde yazmayı anlatıyor. Ama Türkçe’ye veya herhangi bir dile uygulanabilecek genel öğütler de veriyor.

İyi Yazmak

Bilgisayarlar yaygınlaştığından beri yazı üretmek giderek kolaylaştı. Şimdi bir de yapay zekâ çıktı ve kelimeleri bir araya getirmeyi bile bilgisayara bıraktık. Ama bu gelişmeler insanları yazıda ustalaştırmadı. Yazmak kolaylaştıkça kötü yazmak daha da kolay hale geldi. İnternette rastladığınız çer çöpü düşünün.

Basitlik

İyi yazının püf noktası basitlik. Cümlelerinizi mümkün olan en basit hale getirin. Bir amaca hizmet etmeyen, laf olsun diye söylenen tüm sözleri çıkarın. Uzun kelimeler yerine kısa kelimeler tercih edin. Lüzumsuz sıfat ve belirteçleri (zarf) kaldırın.

“Çok yüksek bir gökdelenden aşağı bakıyordu.”

Gökdelen demişken, bir de yüksekliğini anlatmaya gerek yok.

Uzun cümleleri mecbur kalmadıkça tercih etmeyin. Virgülle birbirine eklenmiş vagonlardan oluşan cümleler okuyucuyu yorar. Kısa cümleler kurmaya gayret edin.

Fiiller Bizim Canımız

İsim ve sıfat, fiil kadar güçlü değil. Fiilleri baş karakter olarak kullanın. Edilgen anlatım yerine etken anlatımı tercih edin. Edilgen anlatımda özne işi yapmaz, yapılan işten etkilenir. Bu da anlatımı daha dolaylı ve karmaşık hale getirir. Şu iki örnekte olduğu gibi:

• Arkadaşlarım tarafından anlaşılmadığımı düşünüyorum.

• Arkadaşlarım beni anlamıyor.

Hangisi daha sade?

Çekinmeyin

Fikirlerinizi desteklemek için kullandığınız ama elzem olmayan belgisiz sıfatları kaldırın. Mesela, “uyandığımda biraz bitkindim” yerine “uyandığımda bitkindim” demek daha basit ve keskin. Düşüncelerinizi ortaya dökerken frene basmayın. Ayar yapayım derken vermek istediğiniz duygu kaybolmasın.

Ahenk

Sözcükler, cümleler ve paragraflar bir ahenk oluşturmalı. Bunun bir formülü yok maalesef. Yazdıkça gelişecek olan tarzınıza güvenmeniz gerekiyor.

Ahengin bir formülü olmasa da ahenksiz bir yazıyı hemen anlarsınız. Bunu fark ettiğinizde uyumu bozan kısımları silin. Silmek ve tekrar yazmak iyi bir yazar olmanın en önemli koşulu. Hayranlıkla okuduğumuz eserler yüzlerce kez silinip bozulup tekrar yazılarak o hale geliyor.

Kapanış Notlarım

Önce kendiniz için yazın. Yazdıklarınız özgün olsun, kalıplara oturtmaya uğraşmayın. Duygu ve düşüncelerinizi bir bütünlük içinde ve en az kayıpla aktarmaya çalışın. Yazmak da herhangi bir iş gibi yaptıkça ustalaştığınız bir iş. Bol bol yazın.

Yeni yıldan herkese merhaba. 2025 de tıpkı diğer seneler gibi oldu bittiye geldi. Zamanın akışına yetişemiyorum.

Geçen hafta genellikle devops ve operasyonel işlerle ilgili haberler ve makaleler dikkatimi çekti. Production’dan sorumluysanız bu makaleleri ve röportajları daha dikkatli inceleyin. Ders alınacak çok şey var.

MongoDB Heartbleed

Aralık ayı içerisinde MongoDB’de kritik bir zafiyet tespit edilmişti. Bu zafiyetten faydalanan saldırılar da gecikmedi. The Register’ın haberinde konuya detaylıca değinilmiş.

Eğer internete açık bir MongoDB sunucunuz varsa, siz de bu güvenlik açığından zarar görebilirsiniz. Bu açıktan faydalanan biri, sunucu belleğinden bazı bölümleri okuyabilir. Zlib kütüphanesinin kullanımı ile ilgili istenmeyen bir yan etki sonucu, kötü niyetli kişiler şifreler, API key’ler veya kullanıcı verileri gibi bilgilere erişebilir.

MongoDB’deki bu problemi çözen yeni versiyonlar çoktan yayınlandı. Eğer versiyon değiştiremiyorsanız, en azından zlib sıkıştırma özelliğini devre dışı bırakarak sunucunuzu koruyabilirsiniz.

Cloudflare Code Orange: Fail Small

Buluta ve dağıtık sistemlere ilgisi olanların keyifle okuyacağı bir makale yayınladı Cloudflare. Bazıları Cloudflare’i interneti göçerten firma olarak biliyor olabilir. Kasım ve Aralık aylarında etki alanı büyük iki farklı kesinti olmuştu. Cloudflare kesintilerin altında yatan problemleri çözmeye yönelik bazı tedbirler almaya başladı.

Kod değişiklikleri çok detaylı kontrollerden ve testlerden geçtikten sonra canlıya alınıyor. Ama Cloudflare aynı hassasiyeti konfigürasyon değişikliklerine göstermemiş bugüne kadar. Oysa kesintilerin çoğu network veya uygulamalardaki ayar değişiklikleriyle tetikleniyor.

Amazon’da çalışırken kritik dönemlerde “code freeze” olurdu. Mesela “black friday” haftası kimse uygulamalarda değişiklik yapamazdı. Buna konfigürasyonlar da dahildi. Hatta canlı sistemlere uzaktan bağlanmak bile yasaktı bu dönemde. O zamanlar bana biraz abartılı gelmişti. Ama düşününce, ister kod ister ayar değişikliği olsun, bir sistemde değişiklik yapıyorsanız işlerin ters gitme olasılığını göz ardı etmemelisiniz. Ve değişikliklerin hepsine aynı özeni göstermelisiniz.

Kent Beck: Party of One for Code Review

Yazılım dünyasının bilinen isimlerinden Kent Beck yapay zeka ve code review süreçlerine dair bir makale yazmış. Kod üretimini üstlenen yapay zeka araçları sayesinde eskiden bir haftada yazdığımız kodu şimdi bir günde yazmaya başladık. Yazılan kodu kim denetleyecek ve bu hıza nasıl yetişecek?

Kent Beck yapay zeka kullanımında code review süreçlerinin iki temel amaca hizmet etmesi gerektiğini savunuyor. Birincisi, yapılan değişiklik gerçekten istediğimiz değişiklik mi. Yani yapmak istediğimizi yapmış mı. İkincisi ise yapısal olarak projeyi bozuyor mu yoksa mevcut düzene uyum sağlıyor mu.

AI, DevOps, and Kubernetes: Kelsey Hightower

JetBrains’in yayınladığı videoda Kelsey Hightower ile bir röportaj yapılmış. Devops alanında akla ilk gelen isimlerden biri Kelsey Hightower. Zor konuları basitçe açıklayabiliyor. Yapay zeka çağında devops nereye doğru gidiyor analiz etmiş. Mutlaka izlemeniz gereken bir başka video.

Andrej Karpathy: Geri kaldığımı hissediyorum

Andrej Karpathy OpenAI'ın kurucularından biri. Attığı tweette yazılım geliştirme süreçlerinde yapay zekanın getirdiği dönüşüme yetişemediğini söylemiş. En öndeki adam yetişemiyorsa, biz nasıl yetişeceğiz?

Kıymetli yorumlarınızı bekliyorum.

Twitter ve Linkedin’de yazılım ve teknoloji alanında kaliteli içeriklere ve bizi ilgilendiren haberlere denk geliyorum. Evet, onca saçmalığın yanında üzerinde durmaya değer yazılar da oluyor. Bunların içinde firmaların ürün tanıttığı pazarlama tarzı içerikler de var, sizin gibi insanların elinden çıkan ilgi çekici bloglar da. Paylaşmaya değer yazıları, kısa bir özetle birlikte haftalık olarak derlemeye karar verdim. Her cuma yayınlamaya çalışacağım.

Marc Brooker: Natural Language Programming

Paylaştığım ilk yazı yapay zeka ile ilgili, ne ilginç değil mi? Marc Brooker Twitter’dan takip ettiğim bir mühendis. AWS’te “distinguished engineer” (kurumdaki en üst seviye mühendis ünvanı). Blog yazıları güzel oluyor. Daha çok veritabanları üzerine yazıyor.

Özetle, yazılım geliştirme pratiğinin “bu problemi nasıl çözerim”? mantığından sıyrılıp, “elimde böyle böyle bir problem var, ne yapılmalı?" sorusuna cevap aradığından bahsediyor. Nasıl => Ne dönüşümü, yani bilgisayara bir işi nasıl yapması gerektiğini değil de ne yapması gerektiğini anlattığımız modele doğru gidiyoruz.

The practice of programming has become closer and closer to the practice of specification. Of crisply writing down what we want programs to do, and what makes them right. The how is less important.

Yann LeCun: LLM’ler ve AGI:

Bir Youtube videosu. Yann LeCun, makina öğrenmesi ve yapay zeka alanında sayılı bilim insanlarından. Meta’da yapay zeka bölümünde “chief scientist”. Bu mülakatta, LLM’lerin (büyük dil modelleri) neden AGI’yi (insan zekâsı) getirmeyeceğini anlatmış.

Karri Saarinen: Design Is Search

Tasarım konusunda kıymetli fikirleri olan Karri Saarinen, Twitter üzerinde bir makale yazmış. Linear‘ı duymuşsunuzdur, ben beğenerek kullanıyorum. CEO’su Karri Saarinen çok iyi bir tasarımcı. Makalede, tasarımın implementasyonla karıştırıldığını anlatıyor. Diyor ki: Tasarımcı hep arayış içindedir. Araç-gereçlere bağımlı hale gelirse, çok kısıtlı bir alana sıkıştırır kendini.

Early design needs freedom. Later design needs reality.

Demis Hassabis: The Future of Intelligence

Bir başka YouTube videosu. Yapay zeka diyince akla gelen ilk isim Demis Hassabis. Google DeepMind CEO’su. Adam bir dâhi. Sohbetleri çok keyifli oluyor, mutlaka izleyin. Bu mülakatta yapay zekanın geleceğiyle ilgili tahminlerde bulunuyor ve şu an teknolojinin nerede olduğunu anlatıyor. Özetlenemeyecek kadar çok konuya giriyor, izlemeniz lazım.

AWS re:Invent 2025

Bu seneki AWS re:Invent geçtiğimiz haftalarda yapıldı. Resmî sitede dikkat çeken gelişmeleri derlemişler. Benim ilgimi üç şey çekti:

1. AWS Kiro: Bir agentic IDE. Cursor tarzı bir “integrated development environment”. Denemesi bedava, indirip kullanın. Ücretsiz sürümde her ay 50 krediniz var. Basit işler bir krediden daha az yiyor, ama zorlu ve büyük kapsamlı işlerde krediler çabuk bitebilir.

2. AWS Lambda Durable Functions: Uzun soluklu işler için lambda çok uygun değildi, fakat yeni getirdikleri “durable functions” ile workflow tarzı işleri step functions’a gerek kalmadan yapabiliyorsunuz. Bunun bir benzeri Cloudflare workflows’ta var, fikir edinmek isterseniz bu ürünü incelediğim videoya bakabilirsiniz.

3. AWS Lambda Managed Instances: Lambda çok sevdiğim bir ürün ve sıkça kullanıyorum. Fakat büyük ölçekli trafik alıyorsa uygulamanız, lambda çok pahalı oluyor. Lambda managed instances özelliğiyle birlikte, çok kullanışlı olan lambda modelini alıp EC2’dan uygun fiyata kiraladığınız makinalarla birleştirebiliyorsunuz. Böylece yüksek trafikte hesaplı bir çözüm elde ediyorsunuz.

Jeremy Daly: Post-Serverless World

Bu yazısında, Jeremy serverless’ta son durumu güzel anlatmış. Akıllı altyapılardan bahsediyor, modern sistemlerin artık akıllı altyapılar üzerinde koşacağı bir dünyaya doğru gidiyoruz diyor. Serverless önceleri istisnaydı, ama artık http gibi veya tcp/ip gibi tartışmasız kabullendiğimiz varsayılan dünyayı yansıtıyor. Yeni bir projede alt tarafta tcp/ip mi kullanmalıyım diye sorduğunuz oluyor mu? Serverless da artık kendini çaktırmadan her mimariye dahil etmeye başladı.

In that world, choosing infrastructure looks a lot like choosing a compiler today. Important, for sure, but rarely a daily concern.

GitHub: Self-Hosted Actions Ücretli Hale Geliyor

GitHub’ın yaptığı duyuruda, self-hosted yani kendi makinalarınızda koşan GitHub Actions akışları için dakikasına 0.002 dolar ücret getiriyorlar. Onların makinalarını kullanalım diye mi bu işe kalkıştılar, anlamadım. Hiç hoş olmamış, onu söyleyebilirim. Twitter’da insanlar çok tepki göstermiş.

Sonradan yapılan duyuruda, GitHub bu değişikliği ertelediğini söylüyor. Gelen tepkilere kayıtsız kalmamaları güzel.

Cursor: Visual Editor

AI IDE tercihim olan Cursor, görsel editörünü duyurdu. Yapay zeka alanındaki her ürün, olası tüm özellikleri bünyesinde toplamaya başladı. İstiyorlar ki başka yere gitmeyelim, mesela Cursor istiyor ki IDE’yi terk etmeyelim hiçbir iş için. Onlar açısından mantıklı olabilir. Ama Cursor, bizim asıl derdimiz olan kullanışsız UI/UX problemini halen çözemedi. Uygulamayı kullanmak her geçen gün zorlaşıyor.

pg_textsearch open source oluyor

Twitter’da denk geldim, herhangi bir şeyin open source olması gayet güzel bir haber. Bu eklenti postgresql veritabanında text arama işini iyi yapıyor. Ama SQL veritabanı diyince benim aklıma free-text arama gelmiyor, o iş için özelleşmiş başka çözümler var mesela elasticsearch.

SQLite-Vec: SQLite üzerinde vektör veritabanı

Yine Twitter’da karşıma çıktı. Yapay zekadaki gelişmelerle, vektör veritabanlarını daha sık duymaya başladık. SQLite oldukça kullanışlı, az yer kaplayan, standalone (bir dosyadan ibaret diye düşünebilirsiniz) SQL uyumlu bir veritabanı. Bunun üzerinde vektör datası saklayabilmek için geliştirilen bir çözüm SQLite-Vec. Ufak yapay zeka modelleri için kullanışlı olabilir.

Freelance işler kısa süreli olur. Bir müşteriden diğerine geçersiniz birkaç ayda. Benim işlerse hep uzun solukluydu, minimum bir yıl. Buna rağmen hiçbirinde şirketin parçası gibi hissedemedim.

Muhabbet yok

En büyük derdim sosyalleşememek. Saat farkı ve asenkron çalışma modeli yüzünden insanlarla video konferans yapmak zor. Genellikle slack mesajları üzerinden konuşuyoruz. Chatbotla yazışmaktan farksız. Robotlaştım.

Ofis

Bu söyleyeceğime ofisten çalışanlar itiraz edecektir: ofiste olmak birçok açıdan güzel. Elbette ofise “gitmeyi” özlemiyorum. Trafiğin özlenecek bir tarafı yok. Ama ekip arkadaşlarımla yaptığım geyiği, kendiliğinden gelişen muhabbetleri ve ortamın tetiklediği fikir alışverişlerini arıyorum. Bunların varlığını çok düşünmeyiz fakat yokluğu hemen hissediliyor.

Savrulmak kolay

Bir kurumun parçası olduğunuzda, oradaki değerler ve ortam sizi belli bir yola sokuyor. Hareket alanınızın sınırları belli. Elinizde iyi kötü bir harita var. Ama kurumun parçası olmadığınızda, bilinmezlik rahatsız edici seviyede.

• Bir sonraki projede yer alacak mıyım?

• Daha fazla sorumluluk için bastırıyorum, verecekler mi?

• Bu firmada kariyer hayali kurmalı mıyım?

• Bu işe burnumu sokmalı mıyım? Yoksa sadece denileni yapıp geçmeli miyim?

Bitti mi, bitiyor mu, şimdi ne olacak derken zaten hepten kopuyor ipler. Boşlukta süzülüyorum.

Problem bende mi?

Olabilir. Belki bu modelde bile insan kurumlara kendini kabul ettirip içeri girebiliyordur, ilerleyebiliyordur, sosyalleşebiliyordur, kariyer basamaklarını tırmanabiliyordur. Ben yapamadım.

İşler ve ekonomi eskisi kadar iyi gitmiyor farkındayım. Kıymet bilmek şart. Üniversiteden mezun olduğum ilk yıllarda olsaydım hemen bırakır kaçardım, alternatiflere yönelirdim. O zamanlar tahammülüm az, motivasyonum fazlaydı. Şimdi tahammül seviyem arttı, ama enerji ve motivasyon yerlerde.

Biraz içimi döktüm. Tanıdık geliyor mu? Belki siz de benzer yollardan geçiyorsunuzdur.

AWS Mimarisi

AWS altyapısı tüm dünyada bölgelere ayrılmış durumda. 30’u aşkın bölgeye dağıtılmış. Mesela “eu-west-1” bölgesi İrlanda’da, “us-east-1” ise ABD’nin doğu kıyısında Virginia eyaletinde yer alıyor. Kesinti ise alıştığımız şekilde, “us-east-1” bölgesinde gerçekleşti. AWS’in pilot olarak kullandığı bir bölge bu. Yeni ve deneysel işleri önce orada yapıyor. Hareket eden parça sayısı arttıkça problemler de beraberinde geliyor. Son 10 büyük kesintinin 6’sı burada olmuş.

Yine DNS

Kesintinin sebebi de tanıdık: DNS. Otomasyondaki hatadan kaynaklı, DynamoDB servisinin bölgesel adresine ait DNS kayıtları (dynamodb.us-east-1.amazonaws.com) siliniyor. DynamoDB AWS’in en kritik servislerinden biri, bir NoSQL veritabanı. Veritabanı olduğu için de, onu kullanan pek çok başka AWS servisi var. Bunlardan biri de EC2.

EC2 Giderse Her Şey Gider

EC2 çok temel bir servis; sunucu kiralama servisi olarak düşünebiliriz. Saniye bazında kiralama yapılabiliyor ve kullandığımız çoğu uygulama bu sunucularda çalışıyor. EC2 da etkileniyor durumdan. Yeni sunucular ayağa kalkamıyor, çünkü EC2 servisi sunucuları yönetmek için DynamoDB’ye ihtiyaç duyuyor.

EC2’da yaşanan problemler bu kez NLB (load balancer) servisini etkiliyor. NLB servisini basitçe, EC2 üzerinde kiralanan sunuculara yük dağıtan bir sistem olarak düşünebilirsiniz. NLB’deki health checkler (sistemin sağlıklı işleyişini kontrol eden bir otomasyon) patlıyor çünkü bu kontrolleri yapmak için yeni EC2 sunucuları ayağa kaldırmaya çalışıyor. Ama olmuyor… NLB ve ona bağlı servisler de göçüyor.

Bu olaylar olurken, DynamoDB, EC2 ve NLB’ye bağımlılığı olan diğer tüm servisler de patlıyor haliyle. Koca bir AWS bölgesi kullanılamaz hale geliyor. Bu bölgeyi kullanan pek çok ürün hizmet dışı kalıyor. WhatsApp, Fortnite, SnapChat, Reddit, Perplexity, CoinBase... Liste uzun. Kesintiyle ilgili detayları okumak isterseniz, AWS tarafından yayınlanan resmî yazıya bakabilirsiniz.

Kim bilir bu şekilde - sistemlere gömülü ve kimsenin farkında olmadığı - patlamaya hazır daha ne bombalar var. Bir diğer dikkat çekici nokta da, bir serviste ortaya çıkan problem nasıl da domino etkisi yapıp bambaşka amaçlara hizmet eden farklı servisleri ve uygulamaları da beraberinde götürüyor.

Kıssadan hisseler

1. Hatalar her zaman olacaktır. Hataları halının altına süpürmeyip kök nedenine inip, kökünden çözmeliyiz.

2. En zayıf halka kadar güçlüsünüz. Sistemlerin bağımlılıkları ve zaafları çok iyi bilinmeli ki, başımıza neler gelebileceğini kestirebilelim ve ona göre tedbirler alalım.

3. Maceracı bir kişiliğiniz yoksa, kritik iş yükleriniz için us-east-1’dan uzak durun :)

Bonus: Cloud platformları ve servislerinin hizmet sağlığını gösterdiği ve çoğunlukla yalan yanlış işe yaramayan veriler sunduğu status sayfaları olur (mesela servisler tamamen kullanılamaz durumdadır ama status sayfasına sorsan her şey güllük gülistanlık). DataDog bu boşluğu doldurabilecek güzel bir sayfa hazırlamış: updog.ai

Eğer sık sık iOS uygulamaları geliştiriyorsanız ve bunların App Store konfigürasyonlarıyla uğraşmak çok vaktinizi alıyorsa, geliştirdiğimiz bu ürün ilginizi çekebilir: storeconfig.com

StoreConfig Nedir?

App Store’a uygulama koyanlar bilir; insanı canından bezdiren çok sayıda ayar ve doldurulması gereken alan var. Bunlarla uzun uzun uğraşmayasınız diye, StoreConfig bu ayarları sizin için yapıyor.

iOS geliştiriciler, App Store Connect yapılandırmalarını manuel olarak yönetmek, farklı bölgelerdeki fiyatları güncellemek ve yeni sürümlere uygulama ayarlarını kopyalamak için sayısız saatler harcıyor. Artık bunun daha kolay ve zahmetsiz bir yolu var.

Ürün sizin adınıza App Store Connect API'si ile entegre oluyor. Pricing, localization, metadata ve in-app purchase gibi birçok ayarı tek bir dosya üzerinden “Configuration as Code” mantığıyla yönetmenizi sağlıyor. Üstelik, bu ayarlarınızı AI desteği ile çok daha kolay bir şekilde düzenleyebiliyorsunuz. Websitesine alternatif bir arayüz olarak düşünmeyin, bambaşka ve çok daha gelişmiş bir workflow bu.

Fastlane Alternatifi Değil

Fastlane harika bir araç; ancak amacı farklı, CI/CD otomasyonu için tasarlanmış. App Store Connect üzerinden desteklediği ayarlar çok sınırlı, yetersiz ve kullanımı zor.

Çıkış Hikayesi

Kardeşim Semih bir iOS geliştirici; indie developer da diyebiliriz. Yüzlerce uygulaması var. App Store konfigürasyonları ile uğraşmaktan bıkıp, kendi kullanımı için basit bir uygulama yapmıştı. Bana bahsetti. Acaba bundan başkaları da faydalanmak ister mi diye düşündük. Nihayetinde bunu bir ürün haline getirelim dedik.

Kendi uygulamalarımızda kullandığımız kişisel bir çözüm olarak başlayan StoreConfig’in, dünya çapında binlerce geliştiricinin zamandan tasarruf etmesine ve en iyi yaptıkları şeye, yani harika uygulamalar geliştirmeye odaklanmalarına yardımcı olan bir platforma dönüşmesini umuyoruz.

Nasıl Deneyebilirsiniz?

StoreConfig’i denemek isteyenler için bir bekleme listesi oluşturuyoruz. Bekleme listesine katılarak, beta aşamasındaki ürünümüzü ücretsiz deneyebilirsiniz. Katılım için storeconfig.com adresindeki “Join Waitlist” butonuna tıklayıp eposta adresinizle kaydolabilirsiniz. Ayrıca, web sitesi üzerindeki demo videosunu izleyip biraz daha fikir edinebilirsiniz.

Bundan on sene evvel, 2016 civarları; üç yıldır aynı şirkette çalışıyordum ve artık işler çok rahat yürüyordu. Benim pek bir şey yapmam gerekmiyordu, her şey tıkırındaydı. Siz de yaşamışsınızdır, birkaç yıl aynı yerde çalışınca insan iyice rutine bağlıyor. Bankacılık sektöründeydim, ay sonu piyasa şartlarına göre hiç de fena olmayan maaşım yatıyordu. Performansımı sorgulayan yoktu. Diğer yandan terfî gibi bir beklentim de yoktu. Ne uzayıp ne kısaldığım, ama oldukça konforlu bir pozisyondaydım. Eğlenceli ve sosyal olarak güzel bir ekipteydim, arkadaşlarla ve yöneticimle aram çok iyiydi.

Peki sonra ne oldu? Rahat battı.

İçimi kemiren bir his vardı. Aslında, âkıbetimin kaynayan kurbağa anektodundaki gibi olmasından endişelenmeye başlamıştım. Kurtulmak için son fırsatlarımı yaşadığımın farkına vardım. Hem mevcut konforum giderek artıyordu, hem de meslekî olarak sektördeki gelişmelerden gittikçe uzaklaşıyordum.

Rahatlık Veren Rahatsızlık

Durumu tersine çevirmek için ailecek bir maceraya atılmaya karar verdik. 2017'nin başlarında Londra'ya taşındık ve Amazon'da yazılımcı olarak çalışmaya başladım. Londra oldukça pahalı bir yerdi. İş değişikliği maddi olarak bize fazla bir şey kazandırmadı. Ama yine de doğru bir hamle yaptığımdan emindim.

İlk günlerde çok zorlandım. Herkes devamlı "müşteri" odaklı tartışmalara girip, bu doğrultuda fikirler üretiyordu. Kimse, gördüğü bir problem veya aksaklıkla ilgili harekete geçmeden durmuyordu. "Amaaan bana ne" diyen yoktu ve bu duruma alışmam uzun sürdü. Önceki tecrübelerimde, elimi taşın altına koymadan iş yürütmeye (veya yürütüyor gibi yapmaya) programlanmıştım. Ayrıca müşteriyi de pek umursamazdık, sanki cam fanusun içinde kendi kendimize takılıyor gibiydik.

Amazon global ve devasa bir firma. Yaptığı pek çok gayri ahlâkî ve tasvip etmediğim şeyler var. Ama şunu takdir etmek gerek ki; böylesi büyük ölçekte bir organizasyona, özenle tasarlanmış eşsiz bir kültürü yaymayı başarmışlar. Bahsettiğim kültürün iki temel özelliği var:

1. Müşteri memnuniyetini her şeyden üstün tutmak.

2. Her işi sahiplenebilmek, asla "benim vazifem değil" dememek.

Disiplin ve müşteri odaklılık bir araya gelince, başarı kaçınılmaz oluyor.

Sonra zamanla ben de ortama alışmaya ve ayak uydurmaya başladım. Amazon’da kullandığımız son teknoloji ürünler ve başka hiçbir yerde göremeyeceğiniz ölçekte büyüklüğe sahip problemlere getirdiğimiz çözümler elbette beni heyecanlandırıyordu. Ama asıl tadı damağımda kalan şey yaptığımız işlerden ziyade, işleri yaparken takındığımız tavır ve bakış açısıydı. Ben bu kültürü çok sevmiştim. Keşke üniversiteden mezun olduğumdan beri bu kafaya sahip ortamlarda bulunabilseydim.

Müşteri memnuniyetiyle kafayı bozunca, yaptığınız işin gözünüzdeki değeri ve dolayısıyla motivasyonunuz çok artıyor. Emeğiniz anlam kazanmaya başlıyor. Sadece ürünleri satın alan son kullanıcı aklınıza gelmesin. Yeri geliyor diğer yazılım ekipleri sizin müşteriniz oluyor. Aynı hassasiyeti onlara karşı da göstermeniz gerekiyor.

Dönüş ve Sonrası

Yaklaşık iki sene sonra, işle ilgisi olmayan başka sebeplerden ülkemize geri döndük. Döndüğümden beri de çalıştığım tüm işlerde müşteri memnuniyetini en öne koymaya gayret ettim. Problemleri çözüp insanların hayatını kolaylaştırmayı kendime vazife edindim. Bu yaklaşım, heves ve motivasyonumu yukarıda tutmaya devam ediyor.

Tavsiyeler

Bazen köklü değişimler, başka türlü açılması mümkün olmayan kapılar açabiliyor. Arada bir kafayı kaldırıp ne değişiklikler yapabileceğinize bakın. Mevcut durum rahatsızlık vermeye başladıysa, sizin de vaktiniz gelmiş demektir.

Yukarıdaki grafiği düşünün. Arada farklı tepeleri veya çukurları görmeden tüm haritayı gezmek mümkün değil. Bir yere saplanıp kalmayın.

Haritadaki gezintilerimi anlatmaya çalıştım. Aradıklarınızı bulabilmeniz temennîsiyle…

• Yapay zekâ (YZ): İnsan zekâsıyla ilişkilendirilen bazı görevleri gerçekleştirebilen algoritmalar ve uygulamaları.

• Gen AI (Generative AI): Üretken yapay zekâ, YZ’nin bir alt dalıdır. Metin, resim, video veya diğer veri biçimlerini üretmek için kullanır.

• LLM (Large Language Models)

  • Büyük Dil Modelleri

  • Gen AI’ın bir alt dalıdır.

  • Bazı örnekler: GPT, DeepSeek, Llama vb.

  • Çok büyük ölçekli veri setleri üzerinde eğitilmişler.

  • Milyarlarca parametre tarafından kontrol edilen olasılık hesaplarını kullanır.

  • Parametreleri belirleyen şey, modelin eğitim süreci ve üzerinde eğitildiği veri setidir.

  • Verdiğiniz girdiye bir çıktı üreten kapalı kutu olarak düşünebilirsiniz.

  • Güncel veriye erişimi yoktur, ne ile eğitildiyse onunla yetinir.

• OpenAI

  • ChatGPT’yi çıkaran şirket.

  • LLM işlerinde başı çekiyor.

  • En büyük yatırımcısı ve ortağı Microsoft.

• GPT (Generative Pre-trained Transformer)

  • Bir LLM modeli.

  • OpenAI tarafından geliştirildi.

• Diğer LLM’ler

  • Gemini: Google’ın LLM’i.

  • Llama: Meta’nın (Facebook) LLM’i.

  • DeepSeek: Çinlilerin LLM’i.

  • Grok: Twitter’ın LLM’i.

  • Claude: Anthropic’in LLM’i.

• ChatGPT: Arkada GPT kullanan gelişmiş bir chat bot.

• Copilot

  • GitHub’ın (yani Microsoft’un) YZ kodlama asistanı.

  • VS Code ile entegre çalışabiliyor.

  • Agent modu geçtiğimiz günlerde eklendi.

• Anthropic

  • Bir YZ startup’ı.

  • Claude’nin sahibi.

  • MCP’yi de onlar ortaya koydu.

• MCP (Model Context Protocol)

  • Anthropic’in geliştirdiği bir protokol, yani iletişim standardı diyebiliriz.

  • Bu protokol, YZ araç-gereçlerinin diğer sistemlerle entegre olup iletişim kurabilmesini sağlayan standart bir çatı oluşturuyor.

  • MCP Host: YZ araç-gereci, mesela Cursor veya VS Code.

  • MCP Server (sunucu): MCP standardı üzerinden çeşitli işlevler sunan küçük uygulamalar.

  • MCP Client (istemci): MCP Host üzerinde yer alır ve MCP sunucusu ile iletişimden sorumludur.

• Cursor

  • Gen-AI kullanan bir IDE.

  • VS Code tabanlı.

  • İstediğiniz LLM’i seçip kullanma şansınız var.

  • Agent modu sayesinde dosya oluşturma, komut çalıştırma, API call etme gibi işleri sizin için yapabiliyor.

• Agent: Belirli hedeflere ulaşmak ve çeşitli görevleri tamamlamak için yapay zekayı kullanan yazılım sistemleridir. Mesela Cursor bir agent olarak düşünülebilir.

• RAG (Retrieval Augmented Generation)

  • Güncel veriye erişimi olmayan LLM’lerin bu eksikliğini gidermek için kullanılan bir yöntem.

  • Harici veri setini LLM’e verme işlemine deniyor.

  • Sabit bir veri seti üzerinde eğitilen LLM’lere dışarıdan güncel ve dinamik veri besleme yöntemi.

  • Örnek: Kendi API dokümanınızı GPT’ye verip, o API’ı kullanan bir client/SDK yazdırabilirsiniz.

• Vibe Coding: Gen-AI’ın direksiyona geçtiği bir yazılım geliştirme biçimi. Normalde direksiyonda siz olursunuz, gen-ai sizin yardımcı pilotunuz gibidir. Bunda tam tersi oluyor.

• Lovable.dev: Vibe kodlayabileceğiniz bir platform, programlama bilmenize gerek kalmadan full-stack web uygulamaları geliştirebiliyorsunuz.

• Vercel v0.dev: Gen AI ile React tabanlı önyüzler geliştirmenizi sağlıyor.

Eğitimi duyurduğumuzdan beri, ilgilenen arkadaşlardan çeşitli sorular geldi. Genelde şunlar merak ediliyor:

• Bu eğitim acaba bana göre mi?

• Bu eğitimi neden almalıyım?

• Eğitim kapsamında neleri öğreneceğiz?

• Öncesinde ne gibi bir hazırlık veya yetkinlik gerekir?

• Hangi programlama dilini kullanacağız?

• Eğitimler nasıl ilerleyecek, biz bir şeyler yazacak mıyız?

Hedef Kitle

Her ne kadar eğitim kapsamında çok fazla kod yazmayacak olsak da, herhangi bir programlama diliyle uygulama geliştirmiş olmak eğitimden daha iyi istifade edebilmenizi sağlayacaktır. HTTP ve web uygulamaları üzerine bir bilgi birikimi ve tecrübe, anlatılanları daha iyi kavramanıza yardımcı olacaktır.

Eğer AWS ile profesyonel işler yaptıysanız, bu eğitimi almanıza gerek yok. Ama bir istisnâ var: AWS çok geniş bir alana yayılan yüzlerce servisten oluştuğu için, eğer sadece EC2 veya EKS gibi servislerle çalıştıysanız serverless tarafında neler olduğunu görmek için bu eğitimi almak isteyebilirsiniz.

Eğitimi Neden Almalıyım?

AWS bulut bilişim sağlayıcılarının en büyüğü. Serverless teknolojiler, uygulamaları hızlıca geliştirip düşük maliyetle ayağa kaldırabilmemizi sağlıyor. LLM ve yapay zekâ asistanlarının yükümüzün bir kısmını üstlendiği son zamanlarda, artan kapasitemizi uygulamaların mimari ve operasyonel taraflarına kaydırıp İsviçre çakısı tarzı her işi görebilen bir yetkinliğe gelirsek fark yaratabiliriz.

Eğer daha önce herhangi bir cloud’u kullanmadıysanız, zaten bir yerden mutlaka başlamalısınız. Düşen maliyetler firmaları public cloud’a gitmeye zorluyor ve bu alanda oluşan istihdam talebini karşılayabilmek önünüze gelen fırsatları artıracaktır.

Neler Öğreneceğiz?

Eğitim giriş seviye olmasına rağmen, geniş bir spektruma sahip. Öğreneceğimiz servislerden bazıları şunlar:

• Lambda

• S3

• API Gateway

• SQS

• SNS

• IAM

• CloudFront

• CloudWatch

IaC (infrastructure as code) konusuna yüzeysel olarak değineceğim, ama şimdilik bütün bunları AWS Web Console üzerinden yapacağız.

Bunların yanında, tüm servisleri ilgilendiren ortak konulara da değineceğiz:

• AWS ekosistemini nasıl tarayabiliriz, merak ettiğimiz bir konuyu veya ihtiyaç duyduğumuz bir bilgiyi nereden bulabiliriz?

• AWS CLI nasıl kullanılır?

• API dokümanlarını nasıl okumalıyız?

• SDK’leri nasıl kurarız ve kullanırız?

• Servislerin kullanım ücretlerini nasıl hesaplarız?

• Loglara ve metriklere nasıl bakarız?

Eğitimlerin en büyük katkısı, hangi servisin ne zaman kullanılacağını ve bu servislerin püf noktalarını öğrenmek olacak. Malum, AWS üzerinde 200 küsür servis var. Bu servislerin birçoğu çok özel use-case’ler için tasarlanmış olup, ihtiyaç duyuldukça açılıp bakılıp öğrenilmesi daha mantıklı. Ama bazı servisler var ki, AWS’in sinir sistemini ve beynini oluşturuyor. Bunları mutlaka öğrenmelisiniz.

Hazırlık

Eğitim öncesi özel bir hazırlık yapmanız gerekmiyor. Ama kendinize bir AWS hesabı açarsanız, eğitim süresince geliştirdiğimiz uygulamayı siz de kendi hesabınız üzerinden geliştirip yaptıklarımızı pekiştirmiş olursunuz. Tavsiyem, bir AWS hesabı açın. Hesap açışıyla ilgili yazdığım yazıya bakabilirsiniz.

Bilgisayarınızda belirli bir işletim sistemi olması gerekmiyor. Windows da iş görür, Mac de iş görür, Linux da…

Programlama Dili

Kod yazdığımız kısım AWS Lambda ile uğraştığımız kısım olacak. Burada muhtemelen Python kullanacağız. Ya da belki JavaScript, henüz karar vermedim. Yazdığımız kodla S3, SQS ve SNS gibi servisleri çağıracağız. Ayrıca data transformation yapıp, API Gateway entegrasyonu ile de bir REST API oluşturacağız.

Lambda kodlarını yazarken IDE olarak Cursor kullanmayı düşünüyorum. Yapay zekâ araç/gereçlerini nasıl kullanabiliriz merak edeniniz varsa, canlı olarak görmek ufkunuzu açabilir.

Eğitim Nasıl İlerleyecek?

Dört hafta sürecek ve her hafta üç ders yapılacak. Örnek bir uygulama geliştireceğiz, bunu yaparken hafta hafta farklı servisleri öğrenip uygulamamızda kullanacağız.

• Uygulamamız veriyi S3 üzerinde private bir bucket içinde saklayacak

• Frontend React ile yazılacak (v0.dev ile yapay zekâya yazdırırız muhtemelen) ve S3 üzerinde saklanıp CloudFront (CDN) ile kullanıcılara sunulacak.

• Backend API Gateway + Lambda ile basit bir API olacak ve S3’teki veriyi okuyup frontend uygulamamıza uygun bir şekilde sunacak.

• SQS ile uygulamaya yeni veriler ekleyeceğiz. SQS’i dinleyen bir Lambda, verileri 3rd party bir API üzerinden çekip S3’e yazacak.

• SNS ile de uygulamaya yeni eklenen verileri özet bir email olarak göndereceğiz.

Eğitimlerde bol bol soru sorulmasını bekliyorum ve istiyorum. Zamanımızın yetmediği durumlarda veya offline olarak sonradan aklınıza gelen sorular olduğunda da mail kutum daima kursiyerlere açık olacak. Anlatılan her şeyin tam anlamıyla anlaşılmasını borç biliyorum. Bu düşünceyle hareket ederek, derslerin dışında gelecek soruları da cevaplamak için elimden geleni yapacağım.

Sizlerle buluşmak için sabırsızlanıyorum!

İnsanın gün içinde en korumasız olduğu anlar, uykuda olduğu anlardır. Bu savunmasızlığa rağmen, çok eski çağlardan beri insanlar hep uyumuştur. Demek ki uyku o kadar kritik ki; evrim sürecini göz önüne aldığımızda, uykunun getirdiği o savunmasızlık riskini almaya değecek kadar önemli bir fonksiyona sahip. İnsan, uykudan vazgeçememiş.

Yeterli Uyku

Ne kadar uyumalıyız? Yeterince uyuduğumuzu nasıl bileceğiz?

• Eğer sabah uyandıktan sonra saat 10-11 gibi tekrar uyuyabilecek durumdaysanız, yeteri kadar uyku almamışsınız demektir.

• Eğer sabah uyanırken alarm kurmamış olsaydınız, yine de kendiniz yaklaşık olarak o saatlerde uyanır mıydınız? Eğer uyanamazdım diyorsanız, demek ki yeteri kadar uykunuzu alamamışsınız.

Öğlen uykusu genlerimize kodlanmıştır, hangi coğrafya veya hangi kültüre giderseniz gidin insanların öğleden sonra hafif bir uykuya meyilli olduklarını görürsünüz. Akdeniz ülkelerinde bol uykulu yaşamlar süren insanların ömürlerinin uzun olması sürpriz değil.

Gençlerin uykuları daha geç gelir. Ergen çocuğunuzu saat 10’da yatırmaya çalışmak, sizin saat 8’de yatmanıza tekabul eder, pek mümkün değildir. Zorlamaya gerek yok. Gençleri sabah 7’de uyandırmak, sizin saat sabahın 5’inde uyanmanıza benzer, o saatlerde gençlerden fazla bir şey beklemeyin. Yetişkinlerin ise günde 7-9 saat uykuya ihtiyacı vardır, ne kadar çok o kadar iyi.

Uyku İçin İdeal Ortam

• Karanlık olmalı, mümkünse karartmalı perde kullanın.

• Serin olmalı, tavsiye edilen sıcaklık 18.3 derece (bizim 23-24 derecede uyumaya çalışmamız tam delilik).

• Uykuya geçmeden önceki 1-2 saat parlak ışıktan, fiziksel aktiviteden ve telefondan uzak durun (gece 11-12 halısaha maçından gelip de uyumaya çalıştığımda saatlerce yatakta dönüp durmam boşuna değilmiş).

• Kahve, alkol vb. maddeler tüketmeyin. Beni etkilemiyor demeyin, etkiliyor. Siz güzelce uyuduğunuzu sanıyorsunuz ama çok kalitesiz bir uykunuz oluyor.

• Uykudan hemen önce yemek yemeyin.

Hafıza ve Zihin Açıklığı

İyi uyuyan insan, sabah kalktığında berrak bir zihne sahip olur ve dün çözemediği sorunlara bugün farklı bakış açılarıyla yaklaşarak orijinal çözümler üretebilir. İyi bir uyku sonrası sadece zihinsel değil, fiziksel kabiliyetimiz de üst düzeylere çıkar. Diğer taraftan, uykusuz kalan insanların muhakeme yeteneği büyük bir darbe alır.

Ezber için en iyi vakit uyku öncesidir, çünkü uykudan önce okuduğumuz şeyi gece boyu uykuda beynimiz kalıcı hafızaya doğru arşivler.

Uyku Safhaları

REM uykusu, rüya gördüğümüz uyku safhasıdır ve vücut tamamen felçli gibidir, kıpırdayamaz. Hatta bazen rüyadan uyanırız, gözlerimiz açıktır ama kıpırdayamayız (karabasan). REM uykusu, başımıza gelen tramvaları ve yaşadığımız olayları aşabilmemiz için beynimizin kendi kendine yaptığı bir terapi seansı gibidir. NREM uykusu (yani derin uyku) safhasında beyin hafıza ile ilgili düzenlemeler yapar.

Sağlık Açısından Uyku

Uykunun sağlığımıza doğrudan etkileri var. Uykusuzluk şakaya gelmeyecek kadar önemli bir problem.

• Az uyuyan insanların bağışıklık sistemi daha zayıf olur.

• Az uyuyan insanların kansere ve alhzeimer, depresyon vb. sinirsel hastalıklara yakalanma riski artar.

• Az uyuyan insanlar daha çok yemek yemek ister ve bu da obezite ihtimalini artırır.

• Az uyku ile otizim ve ADHD gibi durumlar arasında bir ilişki var. Otizimli çocukların uyku düzenleri ve ritimleri zayıftır. Ama henüz bilimsel olarak hangisi hangisine sebep oluyor ispatlanmış değil. Yani az uyumak mı otizime sebep oluyor yoksa otizimli olduklarından mı az uyuyorlar bu henüz tespit edilememiş.

• Uykusuz kalmış bir çocuğu doktora götürdüğünüzü, ama uykusuz kaldığını söylemediğinizi varsayalım. Yaşadığı semptomları anlatın. Doktor çocuğa büyük olasılıkla ADHD tanısı koyacaktır. Uykusuzluğun etkileri bu kadar net.

• Guinness rekorlar kitabında eskiden uykusuz kalma rekorları varmış, fakat bilimsel kanıtlarla uykusuzluğun vücuda ne kadar zarar verdiğinin anlaşılmasından sonra Guinness rekorlarından uykusuz kalma kategorisi çıkartılmış. Öte yandan Guinness, insanların (Felix Baumgartner) uzaydan dünyaya serbest atlayış yapmasına izin verebiliyor. Uykusuzluğun risklerini varın siz hesap edin. Uzaydan atlamak bile daha az riskli.

• Uykusuz kalan insanın trafikteki riski, alkollü araç kullanan kadar yüksektir.

• Kuzey yarımkürede Mart ayında yaz saatine geçildiğinde, ertesi gün kalp krizi vakalarında gözle görülür bir artış oluyormuş. 1 saatlik az uyumanın yarattığı neticeye bakın.

• Uykusuzluğun telafisi de yok, yani borçlanıp da sonra uyku borcunu ödemek diye bir şey yok. Uykusuzluğun beyninize yaptığı tahribatın geri dönüşü yok.

Jet Lag

Her insanın yaklaşık 24 saatlik bir uyku ritmi vardır. Yeni bir zaman dilimine geçtiğinizde, ritminiz her gün yaklaşık 1 saat kadar yeni zaman dilimine yaklaşır. Mesela, 10 saatlik bir zaman dilimi farkı oluşturacak bir seyahat yaptığınızda, jet lag etkisinden tam olarak kurtulabilmeniz 10 gün sürecektir.

Hormonlar, Kahve, Alkol ve Uyku Hapları

Melatonin salgısı uykuyu başlatmak için gereklidir, ama uyurken bir etkisi yoktur. Sadece uykuya geçebilmemiz için gereklidir. Adenozin ise, uyandığımızdan beri geçen zamanı ölçmeye yarayan kimyasal bir ölçüm cihazı gibidir. Kahve, çay ve diğer uyarıcılar sinir hücrelerimizi bloke ederek uykuyla ilgili hormonların etkisini baskılar.

Kahve bir gıda maddesinden ziyade, uyarıcı bir ilaç olarak görülmelidir. Kahve içecekseniz, uykunuzdan en az 6-7 saat önce içmeniz gerekir ki uyku kaliteniz kötü etkilenmesin. Kafeinin yarılanma ömrü 6-7 saat kadardır, yani kahveyi içtikten 6 saat sonra vücudunuzdaki etkisi %50 civarındadır.

Yapılan bir deneyde, örümceklere çeşitli maddeler (marijuana, kahve, LSD) verilerek o maddelerin etkisindeyken yaptıkları örümcek ağları incelenmiş. En kötü ağ, kafein etkisindeyken ortaya çıkmış. Kafeinin beynimize etkisi o kadar kötü.

Alkol, vücut için kritik olan REM uykusunu bozduğu için çok zararlıdır. Alkolik annelerin yeni doğan bebekleri de bu durumdan etkilenir ve onların da REM uykuları bozulur. Alkol de uyku hapları gibi yatıştırıcı etkiye sahiptir ve uykuya dalmanızı kolaylaştırır, ama uyku haplarında olduğu gibi uykunuzun kalitesini bozduğu için zararı faydasından çok daha büyüktür.

Uykunun yerine geçebilecek veya uykuyu telafi edebilecek hiçbir şey yok. Uyku problemlerini çözerken öncelik ilaçlar olmamalıdır, çünkü ilaçların faydası kadar zararı da bulunuyor ve uykuya dalmanızı kolaylaştıran bazı ilaçlar, uykunuzun kalitesini kötü etkileyebiliyor. İlaç yerine uyku terapisi mümkün olduğunca tercih edilmeli.

Uyku hapları doğal bir uyku sağlamaz. Alkolün etkisi gibi, ilgili reseptörleri durdurarak sizi yatıştırır ve uykuya geçmenizi kolaylaştırır. Ama uykunuz asla kaliteli bir uyku olmaz. Oysa vücudumuzun ihtiyacı olan, kaliteli bir uyku.

İyi Uykular

Bu kitabı mutlaka okumanızı tavsiye ederim. Anlatılan her şey bilimsel deneyler çerçevesinde elde edilen bulgularla destekleniyor. Kitabın Türkçe çevirisi mevcut ama ben çeviriden okumadığım için onunla ilgili yorum yapamıyorum. Çevirisini mesela Amazon üzerinden satın alabilirsiniz: https://amzn.eu/d/guVeVGh.

En sık kullandığım uygulama GitHub Copilot. Ayda 10$’a pro üyeliğim var. İki IDE kullanıyorum çoğunlukla

• Java/Scala/Kotlin için IntelliJ IDEA

• Diğer tüm ihtiyaçlar için VS Code

Her iki IDE’de de Copilot eklentilerini kurdum ve aktif olarak kullanıyorum. Copilot ile yaptığım bazı şeyler:

1. Otomatik kod yazdırıyorum. Mesela bir fonksiyonun ismini ve argümanlarını yazıp geri kalanını Copilot’tan gelen öneriyle tamamlıyorum.

2. Bazen sadece comment yazıyorum ve istediğim şeyi tarif ediyorum. Örnek:

// Write a function that will list all the objects with a given S3 prefix. It should iterate through the list and get the individual objects which are JSON serialized.

Ve yazdığı kod:

import boto3
import json
from botocore.exceptions import NoCredentialsError

def list_and_get_s3_objects(bucket_name, prefix):
    s3 = boto3.client('s3')
    try:
        # List objects with the given prefix
        response = s3.list_objects_v2(Bucket=bucket_name, Prefix=prefix)
        objects = response.get('Contents', [])

        for obj in objects:
            key = obj['Key']
            print(f"Fetching object: {key}")

            # Get the object
            obj_response = s3.get_object(Bucket=bucket_name, Key=key)
            obj_data = obj_response['Body'].read().decode('utf-8')
            obj_json = json.loads(obj_data)

            # Print or process the JSON object
            print(json.dumps(obj_json, indent=2))

    except NoCredentialsError:
        print("Credentials not available")
    except Exception as e:
        print(f"Error fetching objects: {e}")

# Example usage
bucket_name = 'your-s3-bucket-name'
prefix = 'your-prefix/'
list_and_get_s3_objects(bucket_name, prefix)

3. SQL veritabanı şeması oluşturma: Copilot chat penceresinde uygulamamda saklayacağım datanın şeklini şemalını anlatıp, buna karşılık gelecek tabloların “CREATE TABLE” ifadelerini ürettiriyorum.

4. SQL Query'si yazdırma: Copilot chat penceresinde, istediğim sorguyu tarif ediyorum. “Şu indeksi kullan, şu alanlara ihtiyacım var, şu ilişkili tabloda kayıt olmasa da sonuçları görmek istiyorum” gibi tariflerle istediğim query’yi ürettirip hemen veritabanında deneyip görebiliyorum.

5. Hata çözümleme: Özellikle react vb. çok ustası olmadığım yerlerden gelen hataları hemen anlayamayabiliyorum. Bu durumda Copilot’a hata mesajını verip, bu hatayı nasıl çözebilirim diye soruyorum.

6. Uygulamamdaki çeşitli modüller için unit-test yazmasını istiyorum. Bunun yanında seed ve test datası oluşturmasını da istiyorum. Mesela

Create some test data that follows this format

{
  "authors": [
    {
      "author": {
        "key": "/authors/OL447710A"
      },
      "type": {
        "key": "/type/author_role"
      }
    }
  ],
  "covers": [
    9333846
  ],
  "created": {
    "type": "/type/datetime",
    "value": "2020-04-22T12:24:06.390097"
  },
  "key": "/works/OL20666330W",
  "last_modified": {
    "type": "/type/datetime",
    "value": "2025-01-18T18:32:09.935060"
  },
  "latest_revision": 4,
  "revision": 4,
  "subjects": [
    "Science",
    "Artificial intelligence",
    "Machine learning",
    "Nonfiction"
  ],
  "title": "Artificial Intelligence",
  "type": {
    "key": "/type/work"
  }
}

Copilot’un ürettiği örnek:

{
  "authors": [
    {
      "author": {
        "key": "/authors/OL123456A"
      },
      "type": {
        "key": "/type/author_role"
      }
    }
  ],
  "covers": [1234567],
  "created": {
    "type": "/type/datetime",
    "value": "2021-05-15T10:20:30.123456"
  },
  "key": "/works/OL98765432W",
  "last_modified": {
    "type": "/type/datetime",
    "value": "2025-02-21T12:45:00.000000"
  },
  "latest_revision": 3,
  "revision": 3,
  "subjects": [
    "Technology",
    "Computer Science",
    "Programming",
    "Nonfiction"
  ],
  "title": "Introduction to Programming",
  "type": {
    "key": "/type/work"
  }
}

7. Çeşitli ihtiyaçlar için config veya policy dokümanları üretmekte de Copilot’tan istifade ediyorum. Mesela

Write an IAM policy document for my AWS Lambda Function that will be synchronously invoked through API Gateway to serve some http requests. It should have read-only access to an S3 bucket and it will publish to an SNS topic.

Gelen cevap:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "logs:CreateLogGroup",
      "Resource": "arn:aws:logs:us-east-1:536697245225:*"
    },
    {
      "Effect": "Allow",
      "Action": ["logs:CreateLogStream", "logs:PutLogEvents"],
      "Resource": [
        "arn:aws:logs:us-east-1:536697245225:log-group:/aws/lambda/sqs:*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::your-s3-bucket-name",
        "arn:aws:s3:::your-s3-bucket-name/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:us-east-1:536697245225:your-sns-topic-name"
    }
  ]
}

Akabinde yönelttiğim sual ve gelen cevap

ChatGPT

Bazen IDE’de olmuyorum, ortada hiçbir şey yok diyelim. Bu durumda elim chatgpt’ye gidiyor. Mesela tek sayfalık bir web uygulaması yapmak istiyorum. Önce chatgpt ile istediğim uygulama için örnek bir veri oluşturuyorum. Kafamda neleri görmek isteyip istemediğimi netleştiriyorum.

Bazen de bir framework ya da tooling tercihi için chatgpt’ye danışabiliyorum:

Which IaC tool should I use to manage a full stack web app on AWS? I want the best development experience and it should be free.

I'm planning to build a serverless app that makes use of AWS Lambda, API Gateway, SQS/SNS and Step functions. It will involve managing multiple environments and automated CI/CD pipeline.

ChatGPT bana güzel bir karşılaştırma tablosu çiziyor

Vercel V0

Web uygulamaları yaparken önyüzü genellikle nextjs ile yapmayı tercih ediyorum. Ve çoğunlukla da Vercel üzerinden host ediyorum. Vercel’in geliştirici deneyimi mükemmel. Bunun yanında bir de v0.dev var ki en çok kullandığım tarafı da bu. Benim asla yapamayacağım kadar güzel ön yüzler çıkarıyor.

Yukarıda chatgpt ile ürettiğim veriyi kullanarak v0.dev’e derdimi anlatıyorum

Create a client-side rendered single page app that will display the places I've visited. For now ignore the server-side and assume we have an endpoint that returns a list of the places in this format:

... (buraya yukarıdaki json'ı yapıştırıyorum)

Ve bana gayet şık bir react uygulaması veriyor.

https://v0-client-side-rendered-app.vercel.app

Eğer v0.dev üzerinden, yapay zekânın yazdığı koda bakmak isterseniz buraya tıklayın.

Eğer sizin de geliştirme döngünüzde kullanıp memnun kaldığınız use-case’ler ve yapay zekâ araç gereçleri varsa, nasıl kullandığınızı yorumlarda paylaşabilirsiniz. Her şey çok taze ve gelişme sürecinde olduğu için farklı kullanım şekillerini görmek insanın ufkunu açıyor.

Ücretlendirme

AWS’teki pek çok servis, belli koşullar dahilinde ücretsiz (free tier). Üç farklı ücretsiz kullanım türü sunuluyor:

1. Bazı servislerin kısa bir süre için deneme periyodu oluyor.

2. Eğer AWS hesabınızı yeni açtıysanız, çoğu serviste 12 aylık ücretsiz kullanım hakkınız bulunuyor.

3. Yine bazı servislere özel olmak koşuluyla, ister yeni müşteri olun ister eski, sürekli devam eden bir ücretsiz kullanım kotanız bulunuyor.

AWS’in ücretsiz kullanım kotaları cömert. Mesela en sık kullanılan servislerden biri olan S3 için şöyle bir güzellik yapmışlar:

• 12 ay boyunca 5GB depolama alanı

• Her ay için 20.000 adet GET ve 2.000 adet PUT request’i ücretsiz kullanıma dahil. Bu ne demek: bir ay içinde toplamda 2.000 farklı nesneyi S3’te saklayabilirsiniz ve bu nesnelere toplam 20.000 kere ulaşıp indirebilirsiniz.

• Yine her ay için 100 GB’a kadar dışarıya veri transferi de ücretsiz (S3’ten bir nesneyi AWS networkü dışına çıkardığınızda, bu veri transferi hakkınızdan gidiyor)

• S3’ün ücretsiz kotalarıyla kişisel web sitenizi bedava host edebilirsiniz. Bir seneden sonra da eğer fazla trafik alan bir sayfa değilse iki-üç lira gibi çok cüzi bir fatura gelecektir.

AWS üzerinde pek çok hobi projem var ve yıllardır sıfır (0) TL fatura geliyor. Free tier gerçekten faydalı.

Açılış Süreci

Hesap açmak için gerekenler:

1. Email adresi

2. Kredi kartı

3. Telefon numarası

4. Adınız, soyadınız ve adres bilgileriniz

5. Dedenizin kızlık soyadı

6. Noter tasdikli vukuatlı nüfus kayıt örneği

(İlk dördü gerçek, son ikisi şaka)

Bunlar hazırsa, https://aws.amazon.com adresinden “Get started for free” butonuna tıklayarak süreci başlatabilirsiniz.

Gelen sayfada aşağı doğru scroll edip, “free tier” kapsamındaki koşulları ve kullanım kotalarının detayını görebilirsiniz.

“Create a Free Account” butonuna tıklayarak gelen ekranda email adresinizi ve hesaba vermek istediğiniz ismi seçiyorsunuz.

“Verify email address” butonuna tıkladığınızda emailinize bir doğrulama kodu gelecek, bir sonraki ekranda bu kodu girerek sürece devam edin.

“Root” kullanıcı şifresini belirleyin ve şifrenizi güvenli bir şekilde saklayın. AWS üzerindeki servisleri kullanabilmek için “kullanıcı”lar gerekiyor ve her AWS hesabının mutlaka bir “root” kullanıcısı bulunuyor. Genellikle root’un, hesabı açıp daha sonra bir “admin” kullanıcısı oluşturmak haricinde kullanılması tavsiye edilmiyor. Çok geniş yetkileri olduğu için, herhangi bir şifre çalınma durumunda hesap elden gider. Kötü niyetli birileri hesabınızı kullanarak faturanızı şişirebilir, milleti spamlayabilir, yasadışı işler yapabilir. Bu yüzden, hesap açıldıktan sonra birazdan aşağıda anlatacağım şekilde yeni bir “admin” kullanıcısı oluşturacağız. Şimdilik root ile devam.

Şifrenizi belirlediyseniz, sırada iletişim bilgileriniz var. İsterseniz sağ üst köşede “Dil” seçeneğinden Türkçe’yi seçip devam edebilirsiniz. İletişim bilgileri ekranında, eğer bir kurum adına açmıyorsanız hesabı “kişisel” olarak seçin.

İletişim bilgilerinizi girdikten sonra gelen ekranda kredi kartı bilgilerinizi girmeniz istenecek. Tavsiyem sanal bir kredi kartı oluşturup bunu kullanmanız. Bu aşamada kartınızı doğrulamak için 1 TL (1 dolar deniyor ama ben denediğimde 1 TL çekildi) çekilecek karttan. Birkaç gün içinde de iade ediliyor bu ücret.

Eğer 3d secure açıksa sizden bir onay kodu isteyecek, bu onay ekranında 1 TL’lik tutarı görebilirsiniz. Kredi kartınız doğrulandıktan sonra sizden müşteri türünü seçmenizi isteyecek. Eğer bir kurum adına açmıyorsanız hesabı, “bireysel” seçeneğini işaretleyip TCKN numaram yok diyerek hızlı bir şekilde bu ekranı geçebilirsiniz.

Bir sonraki adımda sizden telefon numaranızı doğrulamanız istenecek.

Son adımda ise bir destek planı seçmeniz isteniyor, ücretsiz olarak gelen “basic support” seçeneğiyle hesabınızı açabilirsiniz.

AWS konsol deneyiminizi özelleştirmek için sizden rolünüzü ve ilgi alanlarınızı isteyecektir.

Yeni hesabınız hayırlı olsun! AWS hesap numaranızı (account ID) ve root kullanıcı email/şifrenizi bir kenara not etmeyi unutmayın.

Konsolu keşfetmeye başlayabilirsiniz. Yukarıdaki arama çubuğuna istediğiniz servisi yazıp ilgili servis sayfasını açabilirsiniz. Mesela S3 yazıp, “Simple Storage Service” sayfasına gidebilirsiniz.

Fatura Alarmı

Hesap açılışından sonra yapacağınız ilk iş “Billing” servisinden bir fatura alarmı oluşturmak olsun. https://us-east-1.console.aws.amazon.com/costmanagement/home?region=eu-north-1#/home sayfasını açın ve burada tavsiye edilen aksiyonlar kısmında “Create budget” bağlantısına tıklayın. Gelen ekranda bildirim almak istediğiniz email adresinizi yazın. Böylece 1 kuruşluk bir harcama olsa bile emailinize bir bildirim gelecektir. Bu sayede eğer unuttuğunuz veya istemediğiniz bir kullanım varsa gereken tedbiri erkenden alabilirsiniz.

Gönül isterdi ki AWS fatura limiti koymamıza izin versin. Her ne kadar “billing alarm” ile olası bir fazla harcamadan hemen haberdar olsak da, maalesef harcama limiti koyulamıyor. O yüzden ekstra bir tedbir olarak hesap açılışında sanal kartınızı girin ve kartın limitini düşürün.

IAM ve Kullanıcılar

AWS’in kullanıcı ve yetki yönetim servisinin adı IAM. Bu servis ile gerçek kullanıcılar ve uygulama kullanıcıları için istediğiniz yetkileri belirleyebilirsiniz.

Kullanıcı grupları oluşturup bu şekilde kullanıcıları türlerine göre ayırabilirsiniz. İstediğiniz kullanıcılara yetkileri gruplar aracılığıyla da verebilirsiniz, doğrudan kullanıcıya yetki atayarak da verebilirsiniz. Eğer pek çok farklı kullanıcı türleriniz olacaksa, gruplar yetki yönetimini biraz daha kolaylaştırıyor. Ama kişisel kullanım için çok da gerekli değil.

Yetkiler “policy” adı verilen ve JSON ile tanımlanan yapılarla temsil ediliyor. Kendi özel policy’lerinizi oluşturabilirsiniz. Ayrıca AWS tarafından sağlanan önceden tanımlanmış policy’ler de var. Mesela kullanıcınıza S3 için okuma izni verecekseniz, hazırdaki şu policy işinizi görecektir: “AmazonS3ReadOnlyAccess”.

Yeni Kullanıcı

Yukarıda bahsettiğim gibi, root kullanıcısını bir kenara bırakabilmek için kendimize bir “admin” kullanıcısı oluşturalım. IAM ekranında kullanıcı isminizi ve şifrenizi seçin.

Şimdi kullanıcınızın yetkilerini belirleyeceksiniz. Burada isterseniz bir “grup” oluşturabilirsiniz veya mevcut bir kullanıcının yetkilerini kopyalayabilirsiniz. Ya da benim seçtiğim gibi “Attach policies directly” diyerek AWS’in hazır sunduğu policy’lerden seçebilirsiniz. Ben bu şekilde “AdministratorAccess” yetkilerini seçtim. Her policy için yandaki + işaretine tıklayarak detaylarını görebilirsiniz. Mesela AdministratorAccess şöyle tanımlanmış:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

Kullanıcınızı oluşturduktan sonra size bir “sign-in” URL verecek. Örnek vermek gerekirse, eğer hesap numaranız 12345 ise bağlantınız https://12345.signin.aws.amazon.com/console oluyor. Hesabınıza özel olan bu URL’i bookmarklamanızı tavsiye ederim. Bu bağlantıyı kullanarak yeni oluşturduğunuz kullanıcıyla konsola giriş yapabilirsiniz. Ya da https://console.aws.amazon.com üzerinden gelip account ID (örneğimizde 12345) ve yeni oluşturduğunuz kullanıcı adını girerek login olabilirsiniz.

Son olarak, root kullanıcısı ve oluşturacağınız diğer tüm konsol kullanıcıları için MFA özelliğini açıp güvenliği biraz daha sıkılaştırabilirsiniz. Bunun için, https://us-east-1.console.aws.amazon.com/iam/home?region=eu-north-1#/home bağlantısından yetkilendirme ve kullanıcı servisi olan IAM'i açın ve “Add MFA” butonuna tıklayın. MFA için cep telefonunuza kurabileceğiniz çeşitli uygulamalar (“authenticator app”) bulunuyor. Ya da “Passkey” kullanarak parmak izi veya yüz tanımayla da bir MFA yöntemi oluşturabilirsiniz.

AWS Organizations

“AWS Organizations” ile birden fazla AWS hesabını ortak bir ana hesaptan yönetebilirsiniz ve bu organizasyonlardaki kullanıcıların farklı hesaplara erişimini sağlayabilirsiniz. Bütün bunlar kişisel hesaplar için çok gerekli olmasa da, eğer büyük bir şirketseniz her bir departmanın veya her bir ekibin, hatta her bir yazılımcının ayrı bir AWS hesabı olacak şekilde bir yapı kurabilirsiniz. Bu tarz ihtiyaçlar için AWS Organizations hizmetini kullanmanız gerekiyor.

Kapanış

Hesap kapanışı değil, yazıyı kapatıyorum. Şimdi gidin ve yeni hesabınızla güzel uygulamalar geliştirin, konsolu kurcalayın. Başlangıç için şu servislere bakmanızı tavsiye ederim

• S3 (object storage)

• CloudFront (CDN)

• SQS (queue)

• SNS (pubsub)

• Lambda (serverless)

• API Gateway

• RDS (SQL)

• DynamoDB (NoSQL)

• CloudWatch (monitoring)

• CloudFormation (IaC)