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)

Kitabın yazarı Melanie Mitchell, doktorasını AI dünyasının efsane ismi Douglas Hofstadter'in (okumadıysanız G.E.B. kitabını "okumaya çalışın") yanında tamamlamış.

Özellikle ChatGPT ve sonrasında çıkan diğer LLM (large language models) uygulamaları ile AI artık her yerde. Yapay zekâ bizim için kod yazıyor, ödev yapıyor, araştırma yapıyor, makale yazıyor, seyahat planlıyor ve daha sayamadığımız pek çok iş için yardımcımız oluyor. Ben gelişmelere yetişmekte zorlanıyorum ama bir yandan da neler olup bittiğini ve nereye doğru gittiğimizi anlamak istiyorum. Bu yüzden seçtim bu kitabı ve çok iyi bir seçim yapmışım.

Şunu da belirteyim, kitap 2019’da yayınlanmış. Dolayısıyla son 5-6 yıllık gelişmelerden önce yazılmış. Eğer LLM’ler ile ilgili detaylı bilgi almak istiyorsanız, bu kitap işinize yaramayabilir.

Yapay Zekâ Hype Döngüsü

Yapay zekânın tarihine baktığımızda, ilk olarak 1950'li yıllarda "artificial intelligence" isminin ortaya çıktığını görüyoruz. Ve o tarihten beri yapay zekâ sürekli bir iniş çıkış döngüsüne girmiş. On yıl kadar çok popülerken, sonraki on yıl düşüşe geçmiş, sonra tekrar revaçtaymış gibi bir döngü. Şimdi yine oldukça popüler. Bakalım buradan sonra düşüşe geçecek mi?

Zekâ Nedir?

Kitapta felsefi açıdan sorular da soruluyor: Bizi zeki varlıklar yapan şey ne? Beynimizdeki sinir hücreleri mi? Sinir hücrelerini birebir simüle ederek, insan zekâsını kopyalamak mümkün olabilir mi? Bilinç nasıl oluşuyor, insan nasıl öğreniyor? Bu kavramları makinalara kodlamak mümkün olabilir mi?

Yazar bu soruları teorik açıdan ele alıyor. Yapay zekânın (teoride bile olsa) insan zekâsına yaklaşabilmesi için öncelikle insanların algı ve duyularına sahip olması gerektiğini vurguluyor. Yani, bizimle aynı zekâ seviyesine çıkabilmesi için makinaların da bizim gibi bir öğrenme sürecinden geçip dünyayla benzer bir etkileşime girmesi gerekiyor. Şu an için bu çok uzak bir ihtimal.

AI konusunda dikkat edilmesi gereken bir husus da terminoloji ve tanımlar. Henüz bilgisayar bilimciler daha tanımlar üzerinde bile bir fikir birliğine varamamış. Yani zekâ nedir diye sorduğunuzda, birbirinden bambaşka şeyler anlatan çok farklı tanımlar yapılabiliyor. Bazı tanımlara göre, satrançta Kasparov’u yenen algoritma zekâ olarak adlandırılırken, kimine göre ise zekâ “kendinin farkında olabilme” (bu ne demekse artık) şeklinde tanımlanıyor.

Symbolic vs Subsymbolic AI

Yapay zekâ algoritmaları ikiye ayrılıyor: symbolic ve subsymbolic. Symbolic AI, "şu durumda bunu yap, bu durumda bunu yap" tarzı daha üst seviye prosedürler kullanıyor. Subsymbolic AI ise bizim beyin ve sinir sistemimizi taklit etmeye çalışıyor.

Örnek olarak, satranç oynayan birinin sinir sistemini açıp incelesek, satranç kurallarını veya stratejilerini göremeyiz. Ama bir şekilde o alt seviyede işleyen sinyaller birleşerek satranç oynayabilen bir "zekâ" oluşturuyor. Subsymbolic AI da arkada derin yapay sinir ağlarını eğiterek bir üst zekâ ortaya koymuş oluyor. Ama bu zekâya veya onu kodlayan ve eğiten kişilere “şu hamleyi neden yaptın” diye soracak olursanız size bunun gerekçesini açıklayamıyor.

Yapay sinir ağları kendilerinin farkına varamıyor, bu bağlamda da aslında “düşünemiyor”. İstatistik ve matematik kullanarak belirli girdiler için bir çıktı üreten kara kutu gibi düşünün. Peki insan beyni bir kara kutu mu? İnsan beyni, kendini modelleyebilecek yeteneğe sahip mi? Eğer sahipse, bir noktada bizimle aynı seviyede bir zekâ üretebiliriz demektir. Peki bu ürettiğimiz zekâ bizden daha zeki bir hale gelebilir mi? Eğer o gelebiliyorsa, biz de gelebilmeliyiz değil mi? Ne de olsa onu biz ürettik. Bunlar işin felsefi kısmı.

Sizce yapay zekâ, bu fotoğraftaki karartının kaşığın gölgesi olduğunu “anlayabilir” mi?

ChatGPT vb. LLM uygulamaları da subsymbolic AI örnekleri arasına giriyor. Arkada terabaytlarca veri üzerinde eğitilmiş yapay sinir ağları (artificial neural networks) ve istatistik kullanarak, sorduğumuz sorulara cevap verebiliyor veya bize tavsiyelerde bulunabiliyor. Fakat özünde bu uygulamalar yeni değil, kullanılan algoritmalar bambaşka değil. On yıl öncesiyle aradaki tek fark, artık CPU'lar (işlemciler) çok güçlü ve internetin yaygınlaşmasının bir neticesi olarak veri de çok. Keşfedilen yeni bir şey yok, çığır açan bir keşif yok. Buna rağmen, üzerinde eğitilebileceği devasa veri havuzları ve çok daha güçlü işlemciler sayesinde subsymbolic AI algoritmaları ortalığı kasıp kavuruyor.

It turns out that the recent success of deep learning is due less to new breakthroughs in AI than to the availability of huge amounts of data (thank you, internet!) and very fast parallel computer hardware. These factors, along with improvements in training methods, allow hundred-plus-layer networks to be trained on millions of images in just a few days.

Ahlaki ve Etik Açıdan AI

Yapay zekâdaki gelişmeleri sadece magazin ve kıyamet senaryoları üzerinden irdelemek doğru değil. İşin ahlaki ve etik boyutlarını iyi düşünmek gerekiyor. Yapay zekânın zaaflarını istismar edecek kötü niyetli kişilere karşı nasıl önlemler alınabilir ve algoritmalar nasıl manipülasyonlara daha dayanıklı hale getirilebilir diye düşünmemiz elzem.

Kitapta dikkat çekilen bazı hususlar şunlar:

• Kişisel verilerin korunması ve işlenmesi. Size ait bilgilerin yapay zekâ tarafından girdi olarak kullanılmasına razı olmayabilirsiniz.

• Kötü niyetli saldırılar (hacking, prompt injection, sinyal manipülasyonu). Mesela, otonom sürüş algoritmasını kandıracak bir görseli trafikteki bir tabelaya yapıştırıp arabaların kontrolden çıkarılması.

• Şeffaflık. Subsymbolic AI algoritmalarında, algoritmanın bir sonuca nasıl vardığını takip etmek imkansız gibi bir şey. Sinir hücrelerinizden geçen elektrik akımını ölçerek ne düşündüğünüzü görebilir misiniz?

• Ahlaki ve etik değerler. Bunlar insanlığın üzerinde mutabakata vardığı kavramlar değiller. Hal böyleyken yapay zekâya bu değerleri nasıl aktaracağız? Doğruyu ve hakikati biz kavrayamamışken, makinalara bunu nasıl kodlayacağız?

Kitapan Çeşitli Alıntılar

People worry that computers will get too smart and take over the world, but the real problem is that they’re too stupid and they’ve already taken over the world.

Yani, insanlar bilgisayarların aşırı zeki hale gelerek dünyayı ele geçireceğinden korkuyor. Ama asıl problem, şu an bilgisayarlar aptal olmalarına rağmen çoktan dünyayı ele geçirdiler bile.

Human intelligence is a marvelous, subtle, and poorly understood phenomenon. There is no danger of duplicating it anytime soon.

İnsan zekâsı muazzam ve çözülememiş bir olgu. Makinaların bize yetişmesi, en azından yakın zamanda, mümkün görünmüyor.

As soon as it works, no one calls it AI anymore.

Bir problem yapay zekâ ile çözüldükten sonra, artık konu ilginçliğini yitiriyor. Mesela artık satrançta makinalar en yetenekli satranç ustalarını bile yenebiliyor. Ama bu demek değil ki makina bizden daha zeki. Sadece belli işler özelinde (satranç) ve sınırlandırılmış bir bağlamda (dijital bir dünyada) bize galip geliyor. Genel bir durum yok.

The term long tail comes from statistics, in which certain probability distributions are shaped like the one in figure 13: the long list of very unlikely (but possible) situations is called the “tail” of the distribution. (The situations in the tail are sometimes called edge cases.) Most real-world domains for AI exhibit this kind of long-tail phenomenon: events in the real world are usually predictable, but there remains a long tail of low-probability, unexpected occurrences. This is a problem if we rely solely on supervised learning to provide our AI system with its knowledge of the world; the situations in the tail don’t show up in the training data often enough, if at all, so the system is more likely to make errors when faced with such unexpected cases.

Kısaca açmak gerekirse, yapay zekâ istisnai durumlarla başa çıkmakta insanlar kadar maharetli değil. İstisnalar ise hayatın bir gerçeği ve kaçınılmaz. Ama tanımı itibariyle istatistiksel olarak çok nadir rastlandıklarından, yapay zekânın radarına giremiyor istisnalar.

Kitapta İsmi Geçen Önemli Şahıslar

• Douglas Hofstadter

• Ilya Sutskever

• Alex Krizhevsky

• Yann LeCun

• Ray Kurzweil

• Alan Turing

• Geoffrey Hinton

• Demis Hassabis

• Marvin Minsky

Interlaken “göller arasında” demek. Bir tarafında Brienz, diğer tarafında ise Thun Gölü var.

İlk Gün

İstasyona oldukça yakın ufak bir otelde kaldık. Otele yerleştikten sonra kasabayı keşfetmeye çıktık. Küçük bir yer, nüfusu 6000 civarında. Hediyelik eşya dükkanlarını gezdik, bir şeyler yedik ve otele döndük.

Otelin girişinde, misafirlerin dışarıdan getirdikleri yiyecek/içecekleri tüketebilecekleri güzel ve geniş bir salon vardı. Ayrıca ufak bir mutfak da bulunuyordu ve buradan çeşitli bitki çayları, kahve vb. sıcak içecekleri ücretsiz olarak kendiniz alabiliyordunuz. Akşamları burada çay içip marketten aldığımız atıştırmalıkları yedik ve dinlendik.

İkinci Gün, Jungfrau Dağı

Interlaken'deki ikinci gün, 4158 metre yükseklikteki Jungfrau Dağı'na çıkmak üzere yola çıktık. Buraya çıkan iki yol var, ya Grindelwald köyünden teleferikle gelebilirsiniz (bu en hızlı yol) ya da Lauterbrunnen köyü üzerinden trenle. Biz çıkarken tren kullandık o yüzden Lauterbrunnen tarafından geldik. Çok iyi bir tercih yapmışız, çünkü buradaki tren yolu çok güzel ve yolculuk boyunca lapa lapa kar yağdı.

Nasıl gelirseniz gelin, Eigergletscher istasyonuna varınca o noktadan sonra ulaşım özel bir trenle yapılıyor. Bu son trenin pek bir güzelliği yok, dağın içindeki tünelden gidiyor. Ama elbette mühendislik olarak oldukça etkileyici bir yol, o yükseklikte böyle bir tren yolu yapabilmeleri dikkate şayan. Jungfrau Bahn adındaki bu yol 1912 yılında kullanıma açılmış ve Avrupa'nın en yüksek tren yolu. Sizi 2000 metredeki ilk istasyondan alıp 3450 metredeki Jungfraujoch istasyonuna kadar çıkarıyor. Dağın 4000 metredeki zirvesine çıkan bir yol yok, dağcı değilseniz uzaktan izlemekle yetiniyorsunuz. 3450 metre bile beni zorlamaya yetti, nefes darlığı ve baş dönmesi başladı.

Jungfrau'daki tesislerde bir-iki saat oyalanabileceğiniz çeşitli bölümler var. Girişten itibaren sizi yönlendiren tabelalar bulunuyor, biz de tabelaları takip edip tüm görülecek yerleri gördük. En güzeli, bir buzul mağarasının içinde dolaşmaktı. Bu mağarada buzdan çeşitli heykeller yapmışlar.

Tesislerin restoran kısmının üstünde yine bir Lindt çikolata mağazası vardı. Girip şöyle bir baktık ki bazı ürünlerde %50 indirim varmış. Hemen birkaç paket çikolata aldık :) Tesislerden dışarıya çıkabildiğiniz bir bölüm de var. Çıktık ama beş dakikadan fazla duramadık dışarıda, 3500 metrede kar fırtınasının içinde durmak kolay değil.

Dönüşte Grindelwald üzerinden dönmek için teleferik yolunu tercih ettik. Jungfrau Dağı’nda kızakla kayabileceğimiz uygun bir yer yoktu. Saat henüz 15:00 civarı olduğundan, biraz daha oyalanmak için vaktimiz vardı. Grindelwald istasyonunda görevliye kızakla kaymak için en ideal neresi var diye sorunca, Mannlichen'e çıkabileceğimizi söyledi. Biz de biletleri aldık ve atladık teleferiğe.

Mannlichen'de güzel kayak pistleri ve büyük bir Intersport mağazası var. Intersport mağazasından kızak kiralayacaktık fakat maalesef o saatten sonra kızak vermiyorlarmış. Dönüş için de son teleferik 16:30'daymış. Oradaki büfede birer sıcak çikolata içip son teleferiğe atlayıp Grindelwald'a döndük.

Üçüncü Gün, Gstaad

Interlaken'deki üçüncü günümüzde hedefimiz Glacier 3000'e çıkmak ve 3000 metre yüksekte iki tepenin arasında uzanan asma köprüden geçmekti. Sabah erkenden trene atladık ve Gstaad köyüne vardık. Buradan otobüsle yaklaşık yarım saat giderek Glacier 3000'e çıkan teleferik istasyonuna geldik. Fakat maalesef şiddetli rüzgarlar sebebiyle teleferik kapalıymış.

Onca yol gelip yukarı çıkamayınca moralimiz biraz bozuldu. Bize de bir ders oldu, bir yere gitmeden önce web sitelerinden açık mı kapalı mı diye bakıp ona göre hareket etmek gerekiyormuş. Dönüşte Gstaad’da biraz oyalanalım dedik ve köye hayran kaldık. Sokaklarında dolaştık ve bir restoranda karnımızı doyurduk. Daha sonra da hayatımızda ilk kez buz pateni denedik, tabii pek beceremedik.

Akşam Interlaken'e döndük ve odamızı toparlamaya başladık. Ertesi gün bir sonraki durağımız olan Zermatt'a doğru giden trene atladık. Böylelikle İsviçre gezimizin yarısını bitirmiş olduk.

Seyahatimiz Zürih havalimanında başladı ve bitti. Her birinde üç gece olmak üzere toplam dört farklı şehirde (bazıları kasaba veya köydü aslında) kaldık. Bunlar sırasıyla: Luzern => Interlaken => Zermatt => St. Moritz

Bu yazıda gezinin Luzern ayağını anlatıyorum.

Ulaşım

En ücra köylerden bile bir şekilde tren yolu geçirmişler. En sarp dağların tepesine teleferik kurmuşlar. Kışın ortasında gitmemize rağmen, istediğimiz yere oldukça konforlu ve hızlı bir şekilde seyahat edebildik.

Her türlü bileti veya rezervasyonu online olarak alabiliyorsunuz. SBB uygulamasını cep telefonunuza yüklemenizi tavsiye ederim, seyahat planlamak veya bilet satın almak için yapılmış resmî uygulama. Bir yere mi gideceksiniz, uygulamadan giriyorsunuz ve size dakikası dakikasına hangi istasyondan hangi trene binip nerede ineceğinizi detaylarıyla gösteriyor. UX olarak mükemmel tasarlamışlar, kullanımı çok kolay. Ayrıca trenlerin vagon vagon doluluk oranlarını da gösteriyor. Trenin hangi vagonu hangi sektörde duracak (istasyonlar A-B-C-D… diye sektörlere ayrılmış) gösteriyor. Bu sayede mesela ikinci sınıf biletiniz varsa hangi sektörde beklemelisiniz biliyorsunuz.

Tren istasyonlarında - özellikle büyük şehirlerde - birçok market, cafe ve restoran bulunuyor. Ayrıca merkez istasyonlarda her boydan valiziniz için kilitli kasalar var, ücret karşılığında bunları kullanabiliyorsunuz.

İsviçre pahalı bir ülke, ulaşım da buna dahil. Gitmeden önce online “Swiss travel pass” satın aldık, 15 gün için kişi başı 16.000TL civarındaydı fiyatı. Hesaplı olabilmesi için baya yoğun seyahat etmeniz gerekiyor. Eğer çok sık şehir değiştirmeyecekseniz mantıklı olmayabilir. Bunun yerine “half fare” kartı düşünebilirsiniz, fiyatı daha ucuz ve bir kere alınca tüm biletleri yarı fiyatına alabiliyorsunuz bu kart ile.

Swiss travel pass’ın asıl avantajı bence şu: Bu kart olmasa, her seyahatten önce bilet almanız gerekiyor; zaten yabancı memlekettesiniz nereye gideceğinize bakarken bir de bilet satın alma derdiyle uğraşmamak çok konforlu oluyor. Trene binmeden önce biletinizi satın almış olmanız gerekiyor, trende kontrol sırasında bilet satın alma gibi bir şansınız yok ceza ödersiniz. Kontroller çok sıkı, bize hemen hemen her seyahatte bilet kontrolü yapıldı.

Bilet kontrolünde travel pass’ı göstermek için SBB uygulamasını kullanabilirsiniz, bileti uygulamaya yükleyince QR kodu göstermek daha kolay oluyor. Bilet kontrolünde pasaportunuzu da sorabiliyorlar, birkaç kere denk geldi. Pasaportunuz yanınızda değilse bile en azından fotoğrafı telefonunuzda olsun ki gösterebilesiniz.

Unutmadan, yanınıza nakit almanıza gerek yok, en bilinmeyen dağdaki tesiste bile kredi kartı geçiyor. Kredi kartıyla ödeme yaparken CHF kurunu seçmek daha avantajlı dediler, biz de öyle yaptık.

Luzern

Dağların arasında, tertemiz akan bir nehrin döküldüğü büyük bir gölün kenarında ufak bir şehir diye tarif edebilirim Luzern’i. Ben çok beğendim, göl ve etrafındaki dağlar insanın içini açıyor. Güneyinde Pilatus ve Titlis dağları, doğusunda ise Rigi dağı bulunuyor. Üç günlük gezimizin her bir gününde bu dağlardan birine çıktık.

Rigi Dağı

İlk gün programına Rigi Dağı'nı dahil etmiştim. Yaklaşık 1600 metre yükseklikte, Luzern'e tepeden bakan dağlardan biri. Ulaşım Vitznau'dan "cog wheel" dedikleri ufak trenlerle sağlanıyor. Vitznau'ya gitmek içinse bir saatlik bir tekne yolculuğu gerekiyor. Hızlıca hazırlanıp saat 14:12'de kalkacak olan tekneye yetiştik. Buna yetişemeseydik, programı iptal edecektik çünkü dönüşteki son tekneyi yakalayamazdık.

Vitznau’da tekneden indiğimiz iskeleden yaklaşık 50 metre yürüyerek saat 15:30 gibi hareket eden trene bindik ve 16:00 civarı dağın tepesindeydik. Dönüşte son tekne seferine yetişebilmemiz için dağda sadece bir saat kalabildik. Zaten güneş de batmak üzereydi ve güneşi batırıp dönüş için trene atladık.

Pilatus Dağı

İkinci gün hedefimiz, biraz daha yüksek olan (yaklaşık 2100 metrede bulunan) Pilatus Dağı'na çıkmaktı. "Golden round trip" adı verilen ve dağın bir tarafından teleferikle gelip diğer tarafından trenle döndüğünüz turu yapmak istiyorduk. Fakat kışın tren işlemiyormuş, zaten dağa çıkınca neden işlemediğini gördük. Aşırı dik bir tren yolu ve tamamen karla kaplıydı.

Böyle olunca, biz de teleferikle çıkıp teleferikle indik bu dağdan. Teleferik istasyonuna kadar Luzern merkezden yaklaşık 15 dakikalık bir otobüs yolculuğu yaptık. Otobüslerde hiç bilet kontrolüne denk gelmedim, QR kodumuzu da hiç okutmadık. Okutanı da görmedim.

Pilatus Dağı’ndan Luzern ayaklarınızın altında, hele de gölün üstünde sis yoksa manzara çok daha güzel oluyordur eminim. Maalesef biz gittiğimizde Luzern ve göl genelde bulutlarla kaplıydı. Her ne kadar dağların zirvesi güneşli de olsa, aşağıya bakınca bulutlardan dolayı her tarafı göremeyebiliyorsunuz.

Lindt Çikolata Müzesi ve Yediğimiz Ceza

Aynı güne bir de Lindt çikolata müzesi gezisini sıkıştırdık. Müze Zürih ile Luzern arası bir noktada, tren istasyonuna çok yakın. Müzenin en güzel yanı ikram edilen çikolatalar ve çikolata çeşmeleri. Müze aynı zamanda fabrika, yaklaştıkça buram buram çikolata kokuları geliyor.

Müzeden dönüşte iki durak sonra inmek üzere bir trene alelacele atladık. Binerken dikkat etmemiştik, birinci sınıf vagona binmişiz. İş çıkışı olduğu için tren çok kalabalıktı, birlikte oturacağımız bir yer yoktu. Biz de ayakta durduk. Birinci sınıf vagonda olduğumuzu fark ettim ama nasılsa ayaktayız diye ikinci sınıfa geçmeye gerek yok dedim.

Bir durak sonra inenler olunca koltuklar boşaldı, boş koltuğu görünce de oturalım dedik, uzun bir gündü ve yorgunduk. Oturur oturmaz öteden bilet kontrolcüsü genç geldi. Baktı ki biletimiz ikinci sınıf, tutturdu size ceza yazacağım. Dedim iniyoruz şimdi, o hâlâ cezayı yazmakla meşgul. Durağa geldik ve indik, peşimizden o da geldi (kaçıyoruz zannetmese bari). Ben “zaten tren kalabalıktı bir de aceleyle binince fark etmedik, iki durak geldik vs. vs.” dil döksem de nafile. Neyse dedi bari birinize yazayım, 75 CHF cezamızı ödedik paşa paşa. Kuralları çok dikkatli uyguluyorlar, bir yandan takdir ettim. Öte yandan “bu kadar acımasızlık da olmaz be kardeşim” diye düşündüm :)

Titlis Dağı

Üçüncü gün yine sabahın köründe, saat 8'de kahvaltıya indik ve yabancı ülkelerde alışageldiğimiz yavan bir kahvaltıyla Titlis Dağı'na çıkmak üzere hoş bir tren yolculuğuna başladık. Titlis Dağı 3200 metre yükseklikte. Luzern'den 45 dakikalık bir tren yolculuğuyla Engelberg'e geldik. Burada kocaman bir teleferik istasyonu var. Biletlerimizi satın alıp teleferiğe atladık.

Önce bir teleferikle ara istasyona kadar çıkılıyor. Sonra daha büyük ve 360 derece dönen başka bir teleferikle dağın zirvesine tırmanılıyor. Dönüşte Trübsee denilen ara istasyonda inip kızak parkurunda biraz kızak kaydık.

Luzern’de Son Gün

Dördüncü gün Luzern'den ayrılıp Interlaken'e doğru yaklaşık iki saatlik bir tren yolculuğu yapacaktık. Fakat henüz Luzern şehir merkezini pek gezmemiştik. O yüzden otelden çıkış yapıp ilk iş olarak valizleri tren istasyonundaki kilitli dolaplara yerleştirdik. Daha sonra biraz hediyelik eşya, saat vs. bakındık. Ardından eşimin Luzern'de yaşayan bir arkadaşıyla buluştuk, birer kahve içtik. Sağolsun bizi merkezdeki önemli yerlere götürüp gezdirdi. Vedalaştıktan sonra dolaplardan valizlerimizi alıp trene atladık.

İsviçre gezimizin bir sonraki durağı olan Interlaken ve 4000 metre yükseklikteki Jungfrau Dağı’nı anlatan yazıyı bu bağlantıdan okumaya devam edebilirsiniz.

Eğer işiniz size söyleneni yazmaktan ibaretse; evet geçmiş olsun, yapay zekâ işinizi elinizden alacak.

Yaptığı işi sorgulayan, müşteri memnuniyetini önemseyen, eleştirel düşünebilen, “nasıl” sorusunun yanında “neden” diye de sorabilen bir yazılımcıysanız korkmanızı gerektirecek bir durum yok. Çünkü yapay zekâ bunları yapamıyor.

Yazının sonunda bir quiz var, bakalım sorduğum soruyu bilecek misiniz…

Yapay Zekâ ve LLM’ler

ChatGPT 2022 yılının sonlarında hayatımıza girdiğinde, henüz neyle karşı karşıya olduğumuzu pek anlamamıştık. Zaman içinde, makina öğrenmesinde kullanılan LLM’lerin (large language model) yazılımcıların iş yükünün bir bölümünü üstlenebildiğini gördük. Nasıl ki “git”, “docker“ veya bir “debugger” yazılım döngümüzün içinde yer alıyorsa, yapay zekâ da yeni bir katman olarak alet çantamızda yerini aldı.

2025’e girdiğimiz şu günlerde ise, yapay zekâ sadece basit sorular sorup cevap aldığımız veya yazdığımız kodu debug ettirdiğimiz bir aracın ötesine geçti. Birkaç örnek verelim:

• cursor ai veya github copilot ile konuşma dilini kullanarak yazdırmak istediğimiz kodu tarif edebiliyoruz

• vercel v0 ile react önyüz oluşturabiliyoruz

• dall-e vb. modeller ile kafamızdaki görseli yapay zekâya çizdirebiliyoruz

• chatgpt’ye uygulamamızın veri ihtiyacından bahsedip, çıktı olarak SQL şemamızı alabiliyoruz

Yazılımcının İşi Ne

Yapay zekâ işimizi elimizden alacak mı almayacak mı tartışmadan önce, işimiz ne onu tanımlayalım. Hangi işten bahsediyoruz? Kod yazmak mı? Klavyedeki tuşlara belli kombinasyonlarda basmak mı?

Bizim işimiz “problem çözmek”.

Müşterimizin dertlerine dermân olmaya çalışıyoruz. Bazı durumlarda müşteri “derdinin” bile farkında olmayabiliyor. Bu durumda müşteriyle birlikte çalışarak ve sorulmamış sorular sorarak önce problemi tanımlıyoruz. Daha sonra probleme bir çözüm getiriyoruz ve müşterimizin görüşüne sunuyoruz. Bazen bu sonsuz bir döngü şeklinde ilerliyor, bazen de döngü nihayete eriyor ve başka problemlere geçiyoruz.

Yapay Zekânın Yapamadıkları

Peki, yapay zekâ problem çözemiyor mu? Çok net tanımlanmış dar kapsamlı problemleri çözebiliyor. Ama onda bizde olan öngörü ve geniş bağlam yok. Çok ufak bir pencereden bakıyor. Siz ona hususen söylemedikten sonra başka yere kıpırdama yeteneği yok.

Diyeceksiniz ki yapay zekâ çok gelişti, hiç kod yazmadan sıfırdan uygulama yaptırabiliyorum yapay zekâya. Bazı durumlar için bu belki yeterli olabilir. Ama olay hiçbir zaman ortaya bir uygulama koyup kenara çekilmek değildi ki. Yaptığınız uygulamanın bakımı, ölçeklenmesi, hataların ayıklanması, müşteriyle fikir alışverişi ve uygulama mimarisinin zamanla doğru yönde evrilmesi gibi pek çok başka görevlerimiz de var.

Kodlama asistanları vb. yapay zekâ uygulamaları, ellerindeki devasa veriye dayanarak ve istatistikten faydalanarak bize bir sonraki adımda neler yapmamız gerektiğini söyleyebiliyorlar. Yapay zekânın işimizi elimizden alabilmesi için bu yeterli değil. Eleştirel düşünceye sahip olmak ve sorulmamış soruların peşine düşebilmek gerekir. Teknik olarak LLM’lerin bunu yapması mümkün değil.

Yapay zekâ modelleri istatistiksel tahminlere dayalı çalıştıklarından, gerçekte bulunan bağlama ve şartlara vâkıf değildir. Mesela, bir problemi analiz etmek ve çözmek için tüm operasyonel bağlamı anlamak gerekir. Yapay zekâ yüzeydeki verilerden hareket eder, ancak kurumsal veya sosyal dinamikleri göz önünde bulunduramaz.

Bana öyle geliyor ki, yapay zekâ yerimize geçmeyecek. Öte yandan, LLM uygulamaları ile yazılım geliştirme süreçlerinde verim biraz daha artacak. Nasıl ki “git” yahut “vs code“ türü araç-gereçler vazgeçilmezimiz oldular, yapay zekâ da benzer bir adaptasyona sahip olacaktır.

Quiz

Bu yazıdaki bir paragrafın bir bölümünü chatgpt’ye yazdırdım. Sizce bu hangi paragrafın hangi bölümü olabilir? Yorumlara cevaplarınızı bekliyorum.

Kitabın ana fikri şu: Karmaşıklığı (complexity) modüllerde izole et, dış dünyaya basit bir arayüz sun.

Modül burada genel bir anlam ifade ediyor. Örneğin; bir sistemi oluşturan API’ların her biri veya bir proje içerisinde yer alan farklı sınıflar modül olarak düşünülebilir. Modülü kullanan her bir öge ise dış dünyadır. Modülün kullanılabilmesi için dış dünya tarafından bilinmesi gereken tüm detaylara da “arayüz” (interface) denir.

Yazılım süreçlerinde tüm planlama ve tasarımın en baştan yapıldığı “waterfall” anlayışının işe yaramadığı konusunda herkes hemfikir. Çünkü işe başlarken nasıl bir sistem tasarlanacağı konusunda kafalarda net bir resim olmuyor. Bundan kaçış yok. Tüm belirsizlikleri ilk günden giderme şansımız yok.

Geliştirme süreci boyunca tasarımlarımızın ve bu doğrultuda verdiğimiz kararların pek çok kere değişmesi gerekecek. İyi tasarımın amacı, bu değişiklikleri olabildiğince rahat yapabileceğimiz bir yapı kurmaktır. Bunun da ilk şartı, değişmesi muhtemel kararlarımızı küçük bir etki alanına hapsetmektir.

Modüller arası bağımlılıkları (dependency) minimumda tutarsak, değişiklik yapılacağı zaman elimiz kolumuz bağlanmamış olur.

Derin Modüller

Yazdığımız kodu kullanıcı gözünden değerlendirirsek, nasıl bir modül olsun isterdik? Kullanımı kolay olsun, fazla uğraştırmasın, fazla düşündürmesin ve işlevsel olsun. Yüzeyde basit görünsün, detayları ise kendi içinde çözsün. Kullanıcıyı uğraştırmamak için varsayılan (“default”) davranış genele hitap etsin. İhtiyaç varsa, özelleştirmeye fırsat tanısın.

Örnek olarak, unix dosya sistemini kullanmak için şu dört metod yeterli: open, close, read, write. Çünkü genelde I/O işlemleri “seri” şekilde yapılıyor. Eğer dosyanın rastgele bir yerine erişmemiz gerekiyorsa, o zaman lseek metodunu kullanabiliriz. Fakat sadece seri erişim olacaksa, bu metodu bilmemize gerek yok. Dosya sistemi gibi çetrefilli bir işlev, çok temiz ve kompakt bir arayüzle sunulmuş.

Derin modüllere bir diğer örnek de Java’daki GC (garbage collector). Arayüzü o kadar basit ki, yok. Arkada çaktırmadan çalışıyor, bellekte artık ihtiyaç duyulmayan nesneleri siliyor. Arayüzü basit ama yaptığı iş oldukça komplike; bütün referansları takip edip belleği düzenlemek kolay değil.

İdeal bir modülün arayüzü implementasyonundan çok daha basittir. Bu sayede:

1. Karmaşıklık modülün içinde kalır ve diğer modüllere bulaşmaz.

2. Modüllerde arayüz sabit kaldığı sürece, yapılan değişikliklerden bağımlı modüller etkilenmez. Eğer modülün arayüzü basitse, modül içerisinde değişiklik yapmak daha kolaydır. Çünkü değişikliklerin arayüze dokunma ihtimali azdır. Değişikliğe izin veren yapılar yazılım geliştirirken çok işimize yarar.

Bilgi Saklama

Bilgi saklama, “information hiding” veya “encapsulation” olarak adlandırılan bir kavram. Dış dünyaya bir işlev sunarken, bilmesi gereken en az bilgiyi vererek modüllerimizi derinleştirebiliriz. Detayları olabildiğince modülün içine gizleyebilirsek bunu başarırız.

Bilgi sızıntısı bunun tam tersidir, modüller arası bağımlılığı artırır. “A” modülünün dışarıya açtığı bilgiyi “B” modülü kullanmaya başladığı anda bağımlılıklara bir yenisi daha eklenmiş olur. Artık o bilgiyi ilgilendiren tüm değişiklikler her iki modülü de etkileyecektir.

Bu noktada, sızıntıyı önlemek için “A” ve “B” modüllerini birleştirmeyi düşünebiliriz. Eğer iki modülün sunduğu işlevi tek bir basit arayüzle dışarıya açabiliyorsak, derin bir modül elde edebiliriz.

Varsayılanlar

Modüllerimizi kullanacak olan dış dünyanın işini kolaylaştırmak için, tercihlerimizi en sık kullanım şeklini kolaylaştıracak biçimde yapmalıyız. Yukarıda unix dosya sisteminden verdiğimiz örnekteki gibi; dosya içeriğine erişirken varsayılan yöntem “seri erişim”, en sık duyulan ihtiyaca cevap veriyor.

Varsayılanlar sık duyulan ihtiyacı çözecek şekilde tasarlanmayınca, modülün içinde çözülmesi gereken tüm detaylar kullanıcının sırtına yüklenmiş oluyor. Kullanıcının koduna ve diğer modüllere sızıyor. Örneğin Java’da dosya okurken, “buffering” istiyorsak bunu ayrıca belirtmemiz gerekiyor. Neden varsayılanı bu şekilde değil ki? Bu tercihi niye kullanıcıya bırakıyorsun ve arayüzü karmaşıklaştırıyorsun?

new BufferedInputStream(new FileInputStream(new File(...

Kullanım Kolaylığı

Eğer bir modülü kullanmak için kırk takla atmanız gerekiyorsa, bu durum modülün arayüzünün doğru tasarlanmadığını gösterir. Karmaşıklık modülün dışına taşmış demektir. Yazılım geliştirirken amacımız doğru soyutlamaları bulmaktır ki böylece kompleks işler tüm sisteme yayılmak yerine, modüllerin içine hapsolsun. Modül sahibi olarak önceliklerimizin başında, modülümüzü kullanacak olanların hayatını kolaylaştırmak gelmelidir.

Konfigürasyon

Karmaşıklığın kullanıcıya yüklendiği bir başka konu ise konfigürasyon parametreleridir. Bir API tasarladınız diyelim. Kullanıcıya da her ihtiyacını çözebilsin diye onlarca parametre sundunuz. Modülün içinde çözmeniz gereken konuları kullanıcıya bırakarak, aslında kullanıcının işini zorlaştırmış oldunuz.

Konfigürasyon parametreleri, çözümü zor problemleri veya yapamadığımız tercihleri kullanıcıya yüklemek bize kolay bir kaçış yolu sunuyor. Bu hataya düşmemeliyiz. Eğer konfigürasyonu kullanıcıya bırakmak zorundaysak da mutlaka mâkul varsayılan değerler belirlemeliyiz.

İdeal şartlarda modüller bir problemi “tamamen” çözmelidir. Konfigürasyonu kullanıcıya bırakıyorsak, çözüm yarım kalmış demektir ve buradaki karmaşıklık dış dünyaya sızmıştır.

Bizde hep şu düşünce vardır, “esnek bir yapı kuralım, parametrik olsun”. Bu çok yanlış. Esnek olsun, ama kendi içinde esnesin. Dışarıdan bakıldığında, esneklik ve ek parametreler kullanımı zorlaştıran ve kullanıcıyı tercih yapmak zorunda bırakan ek bir külfete dönüşüyor.

Kapanış

Kitaptan aklımda kalan temel birkaç fikri tekrar ederek özeti sonlandırıyorum.

1. Modüllerin dışarıdan görünen yüzleri (arayüz) basit, sunduğu işlev derin olmalı.

2. Kodda değişiklik yaparken sizi en çok zorlayan şey bağımlılıklardır. Soyutlama yaparken, çizgileri bağımlılıkları en aza indirecek şekilde çizin. Eğer basit bir arayüz tasarlayabiliyorsanız, gerektiğinde iki modülü birleştirmeyi bile düşünebilirsiniz.

3. Kod yazarken, kodu daha sonra okuyacak olan insanları düşünerek anlaşılır yazmalıyız. Kod bir kere yazılır, pek çok kere okunur.

Kitapta benim burada değinmediğim konular da var. Classlar ve fonksiyonlar nasıl yazılmalı, exception handling ve hatta commentlerle ilgili de pek çok faydalı bilgi var. Bu özetle kalmayın, kitabın kendisini de mutlaka okuyun.