Git kendini çok sevdirmeden 18 Nov 2016 3:47 PM (8 years ago)

Microsoft'un “hard-core geek” tayfa içinde oluşturduğu antipati bulutu, son yıllarda iyiden iyiye dağılmış gözüküyor. Az çok bilgisayarın dilinden anlayan, ikili düzende XOR'lama yapmayı öğrenmiş, eli konsol tutan delikanlıların Microsoft'u anti-kapitalist söylemlerin de katkısıyla nasıl yerdiklerini çok da unutmuş değilim.

Microsoft, kapalıydı. Hiçbir şeyi açıklamıyordu. Her bir şeyi satıyordu. Her şey “next next next” idi. Uzmanlık gerekmiyordu. Eğitim ve danışmanlık maliyeti getiriyordu. Bi’ saniye burada çeliştik. Lisanslar belimizi büküyordu. Tekel olmaya çalışıyordu. Güvensizdi. Verileri NSA'ye gönderiyordu. Nasıl güvenecektik? Ürünleri çok kaynak tüketiyordu. Performanssızdı. UX'i berbattı (UX mi vardı o zaman üstad?). Açık kodu engellemeye çalışıyordu.

Bu konularda oldukça tarafsız ve fayda-tecrübe kazancı gözeterek giden birisi olarak hep dinledim sizi üstad. Kimi zaman size hak verdiğim oldu… kimi zaman eleştirinize anlam veremediğim de.

Çünkü meselâ, bir eski mezunumuzun okul toplantısında Microsoft'un kapalı sistem olmasına saydırıp… yıllar sonra havalimanında tesadüfen karşılaştığımda bana Macbook aldığından bahsetmesiydi. OS X açık sistem miydi?

“Next next next"i çok yerdiniz ama bu yerdiğiniz yerden vuruldunuz. Android gelip "next next next"i Linux çekirdeğine entegre edene kadar masaüstünde sinek avladınız.

Evet, her branşta olduğu gibi burada da tenkitler, hicivler, methiyeler, tapınmalar… marjinal boyutlara ulaştı; asla hâkiki ve yapıcı fikirleri konuşamadık bile.

Neyse ki Microsoft, acı tecrübeler yaşayarak kullanıcıyı dinlemenin iyi bir fikir olduğuna hükmetti. Firmanın stratejik hedefleri ile kullanıcıların güncel beklentilerini bir yerde buluşturmak ve sinerjik bir motivasyonla ilerlemek, adımları senkronize etmek gerekiyordu. Şu an sanırım karşılıklı ikna süreci tamamlanmış durumda.

Microsoft, niyetindeki kararlılığını iki yıldır hep müspet ve kullanıcı lehine attığı adımlarla kanıtlamış durumda. Öyle ki şu an Microsoft logolu bir entari giymek için oldukça güzel bir zaman.

Gelelim bahsin aktüel ayağına.

Geçtiğimiz günlerde SQL Server'ın Linux versiyonu görücüye açıldı. Yani bildiğimiz, vatanı Windows olan ve oldukça iyi de pazar payına sahip olan SQL Server, rakip bir sunucu işletim sisteminde de çalışabilecek. Yıllardır Linux'un sunucu pazarındaki payını ele geçirmeye çalışan Microsoft için ne de ironik bir adım değil mi?

Buna bükemediğin bileği öpmek mi demeliyiz? Yoksa aklın yolu bir mi? Yoksa "Karaman'ın koyunu, sonra çıkar oyunu” mu? Yoksa şu atasözlerine fazla takılmayıp, soğuk kanlı, rasyonel ve pragmatist mi yaklaşmalıyız?

Bilmiyorum size daha önce bahsettim mi… Microsoft, Azure veri merkezi tarafında yönetsel görevler için kullandığı bir işletim sistemini Linux üzerine inşa etti. Tabi bu ilk değil. Linux çekirdeğine yıllardır sessizce sanallaştırma için kod ekleyen bir Microsoft var. Ve en son günün haberi de Linux vakfına Microsoft'un üst seviyeden üye olması.

Linux çekirdeğini bilgisayarların başına gelmiş en güzel şey olarak tanımlayabiliriz. Şahsen ben böyle kabul ediyorum. Öyle bir eser ki elimizi attığımız her nesne, onunla hayat buluyor neredeyse. En ağır işleri yapan bir sunucudan, minik bir IoT yongasına kadar içinde CPU yürüyen her bilgisayarın yoldaşı, arkadaşı, ruhu oldu. Elbette bu bir aşkın ürünü olmasından. Helsinkili Linus'un, işlemciye olan aşkının ürünü…

Dünyada Linux çekirdeği gibi, samimi bir aşk ile var olan, vücud bulan ne varsa değeri hiçbir zaman yitmiyor ve aksine sürekli de katlanıyor. Mona Lisa… İstiklâl Marşı…

İşte bu aşk dolu çekirdek artık her yanımızı sarmışken, Microsoft'un yapacağı en akıllıca adım ya da elinde kalan son adım: o çekirdeğe cem olmak.

Yalnız bunu çok romantiğe sarıp sadece aşkın hükümranlığı ile açıklamak saçma olur. Ortada yine kapitalist bir bağlamın kokusunu almak işten bile değil. Microsoft bize pencere metaforuyla onu anlatmak istedi de biz anlayamadık: bulutlar.

“Bulut Bilişim” paradigması, tüm iş kollarını ciddi bir dönüşümün içine soktu. En çok etkilenen de bu işin sağlayıcı tarafında, üretim bandında yer alan dünya IT devleri. O yüzden şu anda gittiğiniz her seminerde size yeniden, bıkmadan “bulut” tanımı yapıyorlar ve “bilmem ne as a servis"i anlatıyorlar.

Microsoft yazılımdan geleneksel modelde para kazanan ve her konuda geç kaldı denen bir şirket olarak bence "bulut"u iyi anladı ve iyi doldurdu. Hatta herkes Microsoft'un hareketlerine şaşırdığına göre, konuyu herkesten iyi anlamış bile olabilir.

Allah ne verdiyse Github'a koyup açık kaynak geliştirme modeline geçmek… Geliştirme ortamlarını kısmen ücretsizleştirmek… Windows'a Linux getirmek, Linux'a Windows götürmek… Konteyner ve Docker çağına tutunmak… On-premise lisanslı ürünlerin alayını bulutta servisleştirmek… Tüm mobil platformlara aynı anda uygulama koymak… Office'i her yere taşımak… Azure'da her platforma ve yazılıma derinlikli destek vermek…. Windows 10'un hâlâ adam olmadığına ikna olmak…

Microsoft, bugün dünyanın yazılım üretimini ve tüketimini şekillendiren ne varsa orada olmak istiyor. Eskiden kendisine mecbur bırakarak, belki de cebren yapıyordu. Şimdi buna bizi ikna ederek, bizi kendine çekerek yapıyor. Açık dünyanın koşullarına uygun olarak. Şirketin benmerkezci yaklaşımlarını hiç olmadığı kadar rafa kaldırıp, egosunu öldürerek…

Zorlarsanız her gönül almanın ve her bir teşekkürün de kapitalizmde karşılığını bulursunuz. Ama bu kadar zorlarsak, kimseye teşekkür edemeyiz.

Biz mesleğimize vefalıyız üstad. Bilgisayarımızı, işlemcimizi sevindireni severiz, sayarız.

Eyvallah Satya. Aro.

Not: Yazının ana gövdesinde çok teknik kaçacağından bahsedemedim ama ilave olarak buraya alayım. Linux'taki SQL Server, doğal Windows binary'si olarak çalışıyormuş. Yani SQL Server'in Linux için yeniden yazılması değil; çevresinin yazılması. Linux'taki standart proses yapısında çalışan bir proses, arka planda user-mode NT çekirdeği sağlıyor ve native SQL Server binary'sini yürütüyor. Reddit'teki bazı meraklılar neden Windows binary'lerini çalıştıran Wine'a yatırım yapmadı diye sormuşlar ama en mantıklı yorum elbette Microsoft'un UI için değil, servis prosesi olarak uzun süreli çalışacak işlere yoğunlaşması ve elinde daha önce başka amaçlar için geliştirdiği hazır Drawbridge'i kullanması. Windows, çekirdek sanallaştırmada ve çekirdek'leri user-mode'da taklit etmede oldukça ustalaşmış durumda. Git gide iç içe geçmiş, sınırları belli olmayan işletim sistemi dünyasına doğru gidiyoruz. Akrabalık bağları kuvvetleniyor.

Burası sıra dışı kahramanlıklar ülkesi 20 Jul 2016 2:32 PM (8 years ago)

Kahramanmaraşlıyım. İçinde birçok anlam var bu şehrin. Milli mücadelenin kendi kendine yürüdüğü, işgal kuvvetlerine halkın düzensiz bir orduyla kendi kendine direndiği ve sonunda şan ve şerefle bağımsızlığını kazanan bir derinlik.

Evet, bir de İstikâl Madalyalı bir şehir.

İsmine eklenen “kahraman”, Antep için “gazi”, Urfa için de “şanlı” olarak düşünülmüş. Bir vilayetin adını, yaptığı kahramanlıklara ve destanlara selam durarak değiştirmek, gerçekten ciddi bir taltif, takdir.

O yüzden biz Kahramanmaraşlıyız derken… sadece bir yeryüzü toprağını anmıyoruz. Özgürlüğü, dini, bayrağı ve vatanı için destan yazmış bir geçmişi anıyoruz.

Beş gün önce, öyle şeyler yaşadık ki ben geriye dönüp hüzne ama en çok gurura boğuluyorum. Milli Mücadele dönemindeki destanların 2016'daki versiyonuydu sanki.

Atalarımız şunu yapmış, ninelerimiz bunu yapmış, yiğitlerimiz şu yiğitliği göstermiş diye sadece dinlediğimiz, okuduğumuz destansı şeyler… gözümüzün önünde, İstanbul'umuzda, Ankara'mızda, şehrimizde, semtimizde, hava limanımızda, köprümüzde, yollarımızda, her yerde oldu.

Evet, büyük ve sistemli bir işgâle uğradık. Hem özgürlüğümüz, hem değerlerimiz ve hem de onurumuz saldırıya uğradı. Amerikanların sadece filmini çekerek fantezi yaşadığı dev iç terör eylemlerine biz canlı canlı şahit olduk.

Ne kadar acı şeyler yaşadıysak o kadar da destansı şeyler yaşadık. Ben bu tankın önüne çıkıp kendini kurtaran meslektaşımı unutmayacağım.

Ama onu ezmek için tereddüt etmeyenleri de unutmayacağım.

Milletimiz, kendi içinden çıkan insanlarca hiç böyle bir aşağılama yaşamamıştı.

Evet, biz kendi işimizi en iyi yaparak bu aslan millete lâyık olmaya çalışacağız. İhtilal haberi alınca kışlanın kapısına dayanan Mustafa Dede'ye lâyık olmaya çalışacağız.

Bu ülkeyi, her kibirlinin ezberini bozan sıradan vatandaşlarından dolayı seviyorum. Roket bilimi alsa da sıradanlığını kaybetmeyen Anadolu insanı oluşundan seviyorum.

Dinimiz, dilimiz, ırkımız, mezhebimiz, cinsiyetimiz, siyasi aidiyetimiz ne olursa olsun… biz sıradanız.

Ama ummadığınız bir gecede sıra dışı işler yapıp eve döneriz.

Maraş kalesindeki haykırış artık tüm ülkenin dilinde olsun: Maraş bize mezar olmadan, düşmana gülizar olmaz.

Docker Medeniyeti 12 Jun 2016 3:18 PM (8 years ago)

- Hocam siz hâlâ kopyala-yapıştır ile mi yaygınlaştırıyorsunuz?
- Hocam “deployment pipeline” var mı sizde? Hani Push-Button, basıyorsun dağıtıyor. Dash buton da olur.
- Hocam “agile” diyorum, çevik diyorum sana!
- Hocam mikroservislerimiz hazır mı?
- Hocam dev'i tamam da ops'u nerede bunun?
- Hocam Docker harika ya. Muhteşem. Öyle böyle değil. Yani ne desem. Nasıl övsem.

Radarları açık yazılımcıların sohbetinde artık bu kelimeler, konseptler havada uçuşuyor. Radarları açık yazılım evlerinde, klasik yazılım geliştirme usullerini terk edip, yeni usullere geçmenin hesapları yapılıyor. Kurumsal departmanlar da trene en son “business” vagonundan binecek olmanın rahatlığıyla radar bakımı yapıyor.

Evet, dünya değişiyor. Yazılımcılar için de son üç senedir oldukça hareketli bir yüzey genişlemesi vuku buluyor. Geliştirme ortamındaki çeşitlilik ve karmaşıklık, kendini test ve dağıtım noktasına kadar hissettiriyor. Üstüne bir de ölçülebilen bir nitelik olan ne kadar “Agile” olduğumuz eklenince… beyin yakan bir noktaya geliyoruz.

Her şeyi bir anda ve bir arada çözmek elbette çok iyi niyetli bir hayal. Ancak çözülmesi gereken şeylerin de birbirine güçlü bağlarla kenetlendiği de bir gerçek. Mesele nereden ne kadar derinleşerek başlayacağını bulmakta. Bu da muhtemelen genel geçer bir formülle değil, her organizasyona göre terzi usulü dikilecek bir elbise ile olur.

Docker, son zamanların en popüler konularından birisi. C-suite retoriğine girmesi de yakındır. Peki ortalığı kasıp kavuran bu konsept, bu teknoloji nedir? Neden bu kadar heyecan veriyor topluma? Neden sağlam bir davaya dönüştü şehirlerde? İşte bu yazıda Bay Tahiroğlu, size Docker'ın teorisini anlatacak. İçinde “Hello World” olmayacak.

Hocam “konteyner"den başla

Konteyner için artık Haydarpaşa Limanı'nındaki MAERSK'leri gösterme devri geçtiği için yazıyla devam edeceğiz. Siz hayal edeceksiniz.

Sanallaştırma yazılım endüstrisinin en sevdiği şey. Biz yazılıma hizmet eden her şeyi sanallaştırabiliyoruz. Meselâ fiziki dünyayı… Daha da güzeli bilgisayarın kendisini. Tüm kaynaklarıyla. CPU, bellek, sabit disk, ağ arayüzü, USB. Artık VMWare, Hyper-V gibi teknolojileri kanıksadık. Fiziki bir donanım üzerinde, sanal donanımlar varmış gibi çalışıyor ve endüstrideki bir merhaleyi daha aşmış oluyoruz. Sanallaştırıyoruz çünkü muhteşem esneklik kazanıyoruz. Olağanüstü Durum Merkezi (ODM) aynalamalarını kolaylaştırıyoruz. Kapasiteleri havadan / yalandan veriyoruz. Anlaşılmaz donanım problemlerini azaltıyoruz. Yedekleme işlerini kolaylaştırıyoruz.

Her şey çok güzel ama bir noktada tekrara düşüyoruz. Her sanal donanım üzerine birbirinin hemen hemen kopyası olan işletim sistemleri kuruyoruz ve bu işletim sistemleri zaten verilen kapasitenin belli bölümünü sabit olarak tüketiyorlar.

Neden bağımsız işletim sistemi ve onların sanal donanımlarına ihtiyaç duyuyoruz? Evet, oraya koyacağımız uygulamalar özelinde daha ciddi kaynak yönetimi ve izolasyon için.

E işletim sisteminde prosesler birbirinden yalıtık değil miydi hocam? OS dersinde öyle anlattılar?

Prosesler birbirinden bağımsız yönetiliyor. Ama konteyner mantığı, bu izolasyonu daha ileri götürüyor. Bir prosese sanal (yavru) bir işletim sistemi sunuyor. Kernel seviyesinde perdelemelerle proses kendini tek başına izole takıldığı bir işletim sistemi ortamında zannediyor.

Bu tekniğin ilk örneği UNIX dünyasında 80'lerde başlıyor (chroot). Sonradan ganimetçilerin lideri Linux dünyasında bereketleniyor. Google tarafından 2006'da fişeklenen ve 2008'de de Linux çekirdeğine resmen eklenen "control groups” (cgroups) özelliği ile olgunlaşıyor. Cgroups, proseslerin kaynak kullanımlarını sınırlamayı sağlıyor ve güçlü yalıtım getiriyor.

Kernel, imkanları sununca bağımsız konteyner implementasyonları doğmaya başlıyor. Bunlardan birisi de LXC.

Esas oğlan Docker'ın hikâyesi nerede başlıyor bayım?

Biraz sabrederseniz efendim, LXC'yi Docker'a bağlayacaktım lâkin aceleniz var galiba. Çevik yazılım bilinci buna denir, doğru ya.

Docker'ın doğuşu epey ilginç. Aslında ilk gününde tam bir konteyner teknolojisi değil. Var olan konteyner konseptinin üzerine kurulmuş bir uygulama dağıtım aracı. Evet ilk gününde diyoruz. Yani 2013 Mayıs'ta. Biz mâlum parkla uğraşırken.

Docker, Solomon Hykes isimli bir geliştiricinin elinden çıkıyor. 2013'teki bir Python konferansında tanıtılıyor ve çok geçmeden açık kaynak kod modeline geçip işaret fişeğini fırlatıyor.

Hocam bu Solomon nerenin tezenesi?

Güzel noktadan yakaladınız. Konumuz Solomon değil ama tezene keyfini sürdürmek için hafif dokunalım.

Solomon'a Paris'in tezenesi diyebiliriz çünkü adam Paris'te büyümüş ve okumuş. Ama aslen Amerika doğumlu. Çünkü baba Amerikan, anne Kanadalı-Fransız. Kendisi Paris'te sunucu sistemlere bakım yaparak geçimini sağlamaya başlamış.

San Francisco'ya da dotCloud'u kurmaya gelmiş. PaaS şeklinde hizmet veren bir geliştirme ortamı. Yazıyorsun, çalışıyor. Tabi şu an AWS ve Azure bu fonksiyonları ham-hum yaptığı için bu tür platformların yaşama şansı pek yok. O da dotCloud ile devam ederken arada yan proje olarak Docker'ı yazıyor. Dediğimiz gibi bir Python konferansında oldukça ilkel bir demo yapıyor ve sonra olaylar gelişiyor. Hacker News'te tavan oluyor. Sunumu izlerseniz milletin pür dikkat bir devrimin kıvılcımına şahit olduklarını görürsünüz.

Peki üstad neden Docker ilk gününden itibaren bu kadar sükse yaptı?

Çünkü herkesin bildiği ve var olan bir teknolojinin üzerine basit, herkesin anlayabileceği ve kullanabileceği bir kurgu getirdi. Evet, alternatifler vardı çıktığı dönem. Ama doğru yere odaklandı ve doğru bir toplulukla buluştu. Ve elbette, zamanlama en büyük talihi oldu.

İnsanlığın icrada “mikroservis” ve süreçte “çeviklik” iştiyakına kitlendiği bir dönemde geldi davetsizce diye oturdu sofraya. Çevikliği besleyen CI/CD ve Dev-Ops meselesine ilaç oldu. Mikroservis yaklaşımına birebir uydu.

Bir Hacker News yorumunda, 21. yüzyılın “static linking"i deniyor. Kesinlikle.

Linux ve Linus ile ilgili neşrettiğimiz yazıda "doğru zamanda doğru iş” yorumunu yapmıştık. Docker için de aynı şeyi söyleyebiliriz. Var olan birden fazla fikri, teknolojiyi ve kompozisyonu alıp 21. yüzyılın ihtiyacı olan çevik ve mikro platformu çıkarmak. Bir de iyi pazarlanırsa… al sana rock-star.

Burada şunu söylemek istiyorum efendim. Bir şeyin rock-star olması, bizi ondan soğutmasın. Docker'ın bu kadar parlaması, bizde antipati oluşturmasın. Mutlaka ve mutlaka oradan edineceğimiz bir şeyler vardır. Docker kullanmasan da Docker'ı doğuran, yoğuran şeyler senin de gündemindedir veya planındadır.

Çünkü hepimiz benzer sorunları yaşıyoruz. Hepimiz için “works for me” diye bir gerçek var. Herkes otomasyon testleri için ortam kurmayı ne kadar hızlı ve ekonomik yaparım diye bakıyor. Herkesin derdi geliştirici makinesinde gerçek ortamı eşdeğer olarak çalıştırabilmek. Herkesin derdi, sürüm geçerken ya da “canlıya taşıma yaparken” ölmemek, vefat etmemek. Tüm CIO'lar “zero-downtime” ister. Müşteriler, topluca yüklenince göçmeyen bir uygulama ister. Maaşlı adam ayın 15'inde tıkır tıkır çalışan, kütür kütür komisyon kesen internet şubesi ister.

Yani Docker'ın yoğunlaştığı ve çözmeye çalıştığı problem uzayı, aslında hepimizin uzayı. O nedenle ilgisiz, müstağni kalamayız.

Uf, bu kadar şeyle aynı anda ilgilenmemiz beynimizi yakmaz mı?

Nazım Hikmet'in dediği gibi; senin beynin yanmazsa, benim beynim yanmazsa…

Tamam hocam anladım. Soru iyi değildi zaten. Son olarak bir sorum var. Kafamız yeterince karıştı. Bugünü kurtardık diyelim; yarın ne olur?

Bugün itibariyle sanalcılar tutuşmuş durumda. Çünkü Docker ve beraberinde güçlenen konteyner altyapısı, donanım sanallaştırmasına karşı ciddi bir cephe açmış durumda. Herkes birbirinin tamamlayıcısı diye yumuşak yorumlar yapsa da VMWare gibi yerlerde Docker soğuk rüzgârlar estiriyor. Ciddi bir iş tehdidi. Daha önceleri VMWare imajları ile dağıtılan yazılımlar şimdi Docker imajları ile dağıtılıyor. Kullanması da iki üç komuta bakıyor. Artı sıradan bir proses olarak çalışıyor.

Düşünün, çeviklik istediğimiz bir çağda, “Infrastructure as Code” ya da “Immutable Infrastructure” ya da “Disposable Server” gibi kavramları konuştuğumuz bir çağda beklenen çevikliğe prangalarından dolayı bir türlü ulaşamayacak bu sanalcılar. O nedenle tüm planlarını ve yatırımlarını revize etmeliler; trene binmeliler. Burada Microsoft için olumlu bir not eklemek gerekir. Olayın gidişatını erken anlayıp, Hyper-V'yi konteyner'a uyumlu hâle getirdi. Yarına bugünden hazırlanıyor Microsoft.

Docker'ın doğrudan uyum sağladığı platform ise Bulut. Zaten makinelerin ölçek ekonomisiyle kullanımına odaklanan Bulut Bilişim inisiyatifi, Docker gibi hem araçlarıyla ve hem de ekonomisiyle kazanç sağlayan bir ürünü görünce bayram ediyor. Şu an Docker'ı herkesten çok yücelten ve pompalayan cenahın Bulut platformları olması tesadüf değil.

Yarın, insanlar sanal işletim sistemlerini konuşmayacak artık. Tek bir işletim sistemi, tek bir kernel… ve üzerinde yeterince izole olmuş, her biri kendini hususi bir işletim sisteminde zanneden prosesler. Açılıp kapanmaları iş değil. Sürüm geçmek saniyeler seviyesi: yeni prosesi aç, eskisini kapat. Ve tüm bunlar bir kaynak kod deposuyla uçtan uca bağlı. Hepsi bir kod “commit"ine bakıyor.

Dev-Ops terazisinde "Dev” kefesine sağlam bir ağırlık eklenmiş oluyor böylece.

Kaynaklar:

- Interview with Solomon Hykes, Co-Founder and CEO of dotCloud, 10-09-2012
- Binpress Podcast Episode 28: Solomon Hykes of Docker, 17-02-2015
- The future of Linux Containers, Solomon Hykes Pycon sunumu, Mayıs 2013

Kendine Meydan Okuyan Adam 12 Apr 2016 10:22 AM (9 years ago)

Geçenlerde üniversiteye giriş sınavının sonuçları açıklanmış ve tam puan alan bir öğrencinin sözleri gündeme roket gibi düşmüştü: hayvan gibi çalıştım. Kibarlıktan ve nezaketten kırım kırım kırılan aktüel hayatımız için kaba saba bir laftı bu ve her kesimden eleştiriler geldi.

Acaba başarmak için odaklanmak ve bu kardeşimiz gibi insanlık sınırlarını zorlayarak çalışmak zaruri mi? Nereye gittiğini bilmeden, sadece içinden geleni yapan ve sonunda bir devrimin kahramanı olmuş olan tutkulu insanlarla dolu tarih. O nedenle bu tür başarı hikâyelerinden ibret almak yerine… kendi yolumuzu çizecek motivasyonu bulmalıyız belki.

Çünkü başarı başkasından bize naklen gelmeyecek, içimizden çıkacak.

Bugün kahramanımız, bir adam.

Avrupa Parlementosu'nun komünist üyelerinden Nils. Babası bir şâirdi bu entelektüel adamın. Yine aynı dünya görüşündeki Anna ile evlendi.

Pek anlaşamadılar. Sürekli Moskova'yı ziyaret edip, damardan komünizm alıyordu. Sonuçta o da kariyerini inşa ediyordu. Parçalanmış âilede biri erkek, diğeri kız iki çocuk ise birbiriyle didişerek çocukluğun neşesini çıkarıyordu.

Heisenberg şekilli Nils'i anlatmayacağız tabi ki size efendim. Hikâyemiz, bu çocuklardan büyük olanın hikâyesi.

Helsinki'nin tezenesi, Kernel'lerin bi’ tanesi, Anna ve Nils oğlu Torvalds'lardan, Linus'un hikâyesi.

Buyrun.

…

Linus için dâr-ı dünya, 1969'da Fin başkenti Helsinki'de başladı. Babasını çok görmedi; annesiyle ve üniversitede bir istatistik profesörü olan dedesiyle takıldı. Matematik kurdunun zehir gibi matematiği, dededen geliyordu besbelli.

Dedesinin şahsi kullanım için aldığı PC öncesi çağa ait bilgisayarlarla programlamanın haz dolu evrenine geri dönemeyeceği bir adımı atıyordu Linus. Assembly komutlarıyla program yazmaya daha çocuk yaşında merak saldı. Yaşıtları Helsinki'nin soğuk hayatını doya doya yaşarken, bu insan sıcak odasında sadece makinelerle ve kodla meşguldü. Babasının eğlenceye, ortamlara akmaya yönelik teşvikleri hiç mi hiç fayda etmedi. Linus, bugün de olduğu gibi kafasının dikine gidiyordu.

Kardeşi Sarah ile de anlaşamadığı bir gerçek. Aslında Linus'un anlaşabildiği insan sayılı olduğu için, bu gayet normal.

Elbette üniversite çağına geldiğinde gideceği okul ve branş belliydi: Helsinki Üniversitesi, Bilgisayar Mühendisliği.

Adam matematik ve programlama dehası olduğu için dersler yağ gibi aktı. Üçüncü sınıfta Amerika'dan, Bell laboratuvarlarından süzülüp gelen C'yi öğrendi. Ve kafayı Tanenbaum'un Operating Systems kitabına kilitledi. Makineye doğrudan hükmeden kodlar yazmak ve CPU üzerinde çalışmak ona dünyanın en önemli meşgalesiydi.

Ama ortada adam vardı, bilgi vardı; adam gibi bilgisayar yoktu. Kuzey ülkelerindeki mahrumiyet yılları.

Üniversite son sınıfta (1991), taksitle 3500 dolara bir 386 PC aldı. İlk iş olarak PC'deki MS-DOS'u sildi. (Microsoft'u ilk silişi olmayacaktı bu). Allah'ım ne yükleyebilirdi bu PC'ye.

O dönemler UNIX adlı bir işletim sistemi, sadece üniversitelerin kullanımına açılmış ve kafeste tutulan bir varlıktı. Eve götüremediğiniz, hiçbir şeye yükleyemediğiniz… Mona Lisa tablosu. Linus, UNIX'i, arkasındaki felsefeyi çok sevse bile ona erişemiyordu, ulaşamıyordu. Ulaşmak istese binlerce dolar tutuyordu.

Karacaoğlan, “ben güzele güzel demem, güzel benim olmayınca” diyerek Linus'un derdini özetliyordu.

UNIX güzeldi ama kimsenin değildi. AT&T yasal sıkıntılardan dolayı yazdığı mükemmel işletim sistemini kendi bile makine üretip kullanamıyordu. Berkeley üniversitesindeki UNIX'ten türetilen versiyon, BSD (Berkeley Software Distribution) ise AT&T'nin lisans hakkı davasıyla yüzleşecekti.

Evrende bir “işletim sistemi” sıkışması yaşanıyordu adeta. Bu dağdağada - bedava mı özgür mü olduğuna karar veremediğim - “Free Software” hareketi baş göstermişti ve Richard Stallman adlı tarikat lideri GNU (GNU not UNIX) diyerek ticari işletim sistemlerine ve yazılım endüstrisine meydan okuyordu.

Buhran devam ediyordu. Transistörler ağlıyordu.

Linus, bu karmaşada PC'sine yükleyecek bir işletim sistemi arayışında kıvranırken, Tanenbaum'un MINIX'i geldi aklına. Üstad, Operating Systems kitabının eğitici materyali olarak bu eğitici işletim sistemi prototipini 16 disketle isteyene gönderiyordu.

MINIX, Helsinki'ye bir ayda geldi. Linus beklemekten zeytin ağacı oldu.

MINIX'i kurdu. O da nesi! MINIX bazı yönlerden iyi olsa bile, çoğunlukla berbattı. Lisans gereği de gelişmiyordu, önemli kısımlarının kodu saklıydı. Ancak başka geliştiricilerin dağıttığı yamalarla adama dönüyordu. Linus da yamalarla MINIX'i biraz adam etti.

Terminal emulatörü ile üniversiteye bağlanıp duyuruları okuyor ve haber grubuna takılıyordu. Ama bu emülatör canını sıkıyordu. Adam programcıydı. CPU'yu seviyordu. Neden bir emülatör de kendi yazmasındı? Helsinki'nin karpuz çatlatan kışında ne yapılırdı başka?

İşte yine bir dönüm noktası. Yine bir meydan okuma.

Linus, yazacağı terminal emülatörünü MINIX üzerinde bir uygulama olarak yazabilirdi. Yapmadı. Meydan okumayı seçti ve CPU üzerinde doğrudan çalışacak bir emülatöre karar verdi. PC mimarisini böylelikle daha yakından tanıyacak, görecekti. Bu prototip, onun da dünyanın da dengesini değiştirecekti.

Minix'te yazıp derliyor, diskete yazıyor ve BIOS'tan direk kendi emülatörüne geçiyordu. Üniversiteye bağlanıp, kendi yazdığı emülatörle keyifli okumalar yapıyordu. Fevkalade bir gururla. Bu gururu ancak programcılar anlar değil mi?

Linus'un emülatör üzerindeki deneyleri artık büyük bir doğum sancısına doğru gidiyordu. Gönlü, sadece okuma yapabildiği bu emülatöre bir de kaydetme özelliği, yani dosya sistemine erişim özelliği de eklemek istiyordu. Okuması ve öğrenmesi gerekiyordu. POSIX standardıyla yürüyebilirdi. UNIX'e kavuşamasa da seviyordu onu.

Bir gün kafayı kırdığı bir anda tuhaf bir hata yaptı. Kendi emülatöründen üniversiteye bağlanayım derken, yanlış bir adresleme neticesi diskten MINIX'i uçurdu.

Onu buralara getiren MINIX artık yoktu. Yine iki seçenek çıktı önüne. Ya MINIX'i tekrar yüklemek. Ya da… evet. Meydan okumak. Kodu açık olmayan MINIX'teki güzel yönleri düşünüp, POSIX'e uyumlu kendi MINIX'ine başlamak.

POSIX ile belgeleri için epey kastı. Üniversitedeki bir araştırma görevlisinden yardım istedi. O da dosyaların olduğu FTP'yi Linus'un erişimine açtı. Adamın dibisin dedi, ilk benim haberim olsun dedi. Ari Lemmke.

Linus'un aklındaki isimle Freax, hemen hemen görücüye çıkmaya hazırdı. Programcı gururuyla camiaya sunmak için sabırsızlanıyordu.

Üniversitedeki MINIX grubuna bu heyecanını şöyle duyurdu: MINIX'te ne görmek isterdiniz? Bedava bir işletim sistemi yazdığını, hobi amaçlı olduğunu, GNU gibi büyük ve profesyonel olmayacağını, tekrar edelim, GNU gibi büyük ve profesyonel olmayacağını… söyledi. Bash ve GCC hazırdı. Yani komut işleten kabuğu ve C derleyicisi ile yumurtlayabilir bir tavuk kıvamındaydı.

Linus bu yeni, taze ve “bedava” işletim sistemini artık kaynak koduyla FTP'ye koymaya hazırdı. Ari Lemmke, paylaşılan klasöre Freax değil, Linus'un kendi bilgisayarında kullandığı sürücü adını verdi: Linux.

İsimler önemlidir. O nedenle hâlâ elimizdeki Linux dağıtımlarına Linux dediğimiz için GNU camiası sinir krizleri geçiriyor.

Çünkü Linux, Linus'un elinde bir kernel olarak gelişirken insanlar bir yandan da üzerine kullanışlı araçları, uygulamacıkları taşımaya başladılar. “Kernel senden, ekosistem benden” misâli imdada GNU yatırımı yetişti. O güne kadar UNIX dünyası için üretilen GNU uygulamaları, patır patır Linux çekirdeği üzerine nakledildi. GNU'nun kendi çekirdeği sorunluydu. UNIX paralıydı. MINIX'ten adam olmuyordu. BSD engelliydi. MS-DOS, zaten rakiplerine göre sınırlıydı. Linux çekirdeği dünyadaki buhranın perdesini yavaş yavaş kaldırıyordu.

Kartlar geliyordu dünyanın dört bir yanından. Herkes merak ve heyecan içindeydi. (Herkes dediysek, “geek” tayfa). Linus'un bir kahraman olacağına işaretler oluşuyordu. Bacısı Sarah anlamıştı Linus'un gerçekten evrensel bir devrimin fitilini ateşlediğinin.

Linus, idealist bir insan olmadı hiçbir zaman. Nihai bir hedefi yoktu. Sadece o anı önemsiyordu. Önemsediği şey, hep daha mükemmel bir çekirdek oldu. İyi kod, kokuşmamış kod oldu.

Toplum için değil, makine için kodladı. Makine gibi kod yazdı. İnsan görmedi, yaşıtları gibi âlemlere akmadı, kod yazdı. Kendisine e-posta ile çıkma teklif eden ilk kıza da evet dedi.

Bu insan hayatında CPU'dan sonra belki de ilk defa birine sempati besledi. Şimdilerde üç çocuk annesi ve eşi olan, Finlandiyalı karate şampiyonu ve o dönem öğrencisi olan Tove'a.

Zira Linus'a üniversitesi kucak açmış ve kendisine sadece Linux'la ilgilenmesini sağlayacak bir iş vermişti. Arada da öğrencilerin e-postalarına cevap verirsin demişlerdi. Kısmet böylece ayağına geldi.

Ayrıca aldığı PC'nin kalan taksitlerini de Linux için heyecanlanan camia, aralarında para toplayıp ödedi. Allah razı olsun.

Evet, devlet (yani üniversitesi) tarafından kendisine tevdi edilen Linus'un görevi, Linux'u başka işlemci mimarilerine taşımaktı. x86 yetmezdi. Bu dünya Intel'den ibaret değildi.

İlk kızı dünyaya geldiğinde Linus'un derdi Kernel'in ikinci versiyonuydu. İkisi de güzel oldu. 1996'da, yani beşinci yılında çekirdek ikinci versiyona geçti.

Linus endüstri ile adeta tek başına savaşıyordu. Linux'un yayılan şöhretine dayanamayan MINIX'çi Tanenbaum, mikro-kernel yaklaşımını yücelten ve monolitik çekirdek olan Linux'u çöp olarak niteleyen bir salvoya girişmişti. GNU şeyhi Richard Stallman ise Linux denilen işletim sisteminin aslında GNU/Linux diye anılmasını istiyor, ekosistemimi yedirmem diyordu. Linus haklı veya haksız, bu salvolarla göğüs göğüse çarpışıyor ve bebeği, gençliği, derdi, tasası ve davası olan Linux'u savunuyordu.

Aile büyümüştü. Finlandiya ısınmıyordu. Silikon Vadisi'nde teknolojiye yön verecek yeni bir dünya kuruluyordu. Linus, Linux dağıtım şirketlerine mesafeli yaklaşıyor, birini diğerine yeğlemiyordu. Adildi adam beyler.

Linux'a hiçbir etkisi olmayan bir Amerikalı şirketin teklifine evet dedi ve Kaliforniya'nın yolunu tuttu. Transmeta, Linus'a mesai saatlerinde Linux ile ilgilenmesine imkan vermişti. Böylelikle kurumsal imajı da sükse yapmıştı. Linus'u yedirip içirip, dolaylı yoldan Linux'u besliyordu.

Linux'a katkı sağlayan camiada ise tereddütler vardı. Yoldaş Linus neden para kazanmak istemişti? Linux ne olacaktı?

Oysa endişeler yersizdi. Linus ve Linux'u kimse ayıramıyordu.

Dünyada Linux üzerine önemli bir iş hacmi oluşmuş ve bu işin mimarı olan adam programcı maaşıyla ev geçindiriyordu. Linux bedava ve açık kodlu bir yazılım olmasına rağmen çevresinde hizmet üzerinden doğan ciddi bir ekonomik ivme oluşmuştu. Acaba bizim Linus'a piyango ne zaman vuracaktı?

Redhat, vefasını gösterdi ve Linus'a katkılarından ötürü hisse verdi. Şirket 1999'da halka açıldığında Linus artık bir milyonerdi. Artık konuşmaya gerek yoktu. Finlandiya'da daracık ve rutubet kokulu bir odada, uykusuz ve huzursuz gecelerle başlayan meydan okuma, dünyalığı yaparak tarihsel sürecinde önemli bir eşiği geçmişti. Devrimin cüzdanı dolmuştu artık. Düğün takısı, bebek altını vs. hepsini geçmişti bu hisse vurgunu. Linus bu olaydan sonra ilk defa para için kalbinin attığını söyler.

Ve kaçınılmaz kurumsal yakınlaşma.

Microsoft, Internet Explorer ile Netscape'i ezmeye başlamıştı. Netscape sonunda havlu attı ve kodunu açarak Mozilla'yı kurdu. Bu hareket o dönem açık kodla destan yazan Linux camiasına kötü haber oldu. Çünkü Mozilla'nın başarısızlığının kendilerini de olumsuz etkileyeceğini düşündüler. Bir de “loser” bir firmanın “açık kod"a sarılmasını etik bulmadılar.

Ayrıca ilginç şeyler de oldu. O dönemdeki düzenlemeler gereği Amerika'da topraklarında yazılmış kripto kodu dışarıya çıkamıyordu. Dışarıdan da ülkeye giremiyordu. Mozilla açık kod olunca bir Avustralyalı ekibin yazdığı kripto modülü, proje için bir anlam ifade edemedi. Türkiye'de olsa bu olay, ne gülerdik değil mi katıla katıla.

1998'de Sun, ürettiği sunucularda Linux'a destek vereceğini duyurdu. Sıra IBM'deydi. Microsoft'tan hayatının şamarını yiyen IBM, rotasını Linux'a çevirdi ve parayı basacağım, Linux'a coşku katacağım dedi. Elbette öyle de oldu. Bir yandan açık kod camiası, Linux için efsane bir HTTP sunucu yazılımı geliştirdi: Apache. Bu dayanılmaz bir cazibe oluşturdu ve şu an bize internetin yarıdan fazlasını Apache takdim ediyor. Oracle ise serinin yeni halkası olarak Linux'a geçti.

Forbes, nihayet buradan bir öykü çıkarttı:

Bu ticari dünyanın özgür yazılıma boyun eğmesi yoksa başka bir şey miydi?

Linus, özgür yazılımın herkesin malı olduğunu söylüyor. Bir ticari işletme ile bir bireyin onun açısından farkı yok. Herkes alabilir, kullanabilir, kurcalayabilir, modifiye edebilir, üzerine bir dünya inşa edebilir.

Büyük teknoloji devlerinin, tamamen kamusal bir aktivite olarak gelişen bu çekirdeğe bu kadar tutkuyla yaklaşmalarının nedeni birden fazladır muhakkak. En önemlisi, evet, özgürlük. Elinize alıp eğip bükebildiğiniz, kararlılığını kazanmış, rüşdünü ispat etmiş bir çekirdek var. Kimse size hesap sormuyor, dava açmıyor. Makineyi bu çekirdeğe emanet edip, kendi iş modelinize odaklanıyorsunuz.

Linus, doğru zamanda doğru işi yaptı ve bir devrimin kahramanı oldu. Koduna başladığı ve şu an sadece %1.5-2'sinin yazarı olduğu çekirdeği hâlâ o yönetiyor. Camia ona saygı duyuyor, tüm huysuzluklarını sineye çekiyor ve her ne yapıyorsa Kernel için yapıyordur diye otomatik bir hüsnüzan sergiliyor. Belki de ancak böyle bir adam, küfretse bile alkışlanır.

…

Ruhani lider, çekirdek insanı Linus'un dünyaya armağan ettiği bir güzellik daha var. Üçüncüsü olur mu dediklerinde, adam haklı olarak "artık yeter” diyor.

2001'de Linux kodunu el yordamıyla yamalamaktan yorulan Linus, dağıtık kod kontrol için Bitkeeper kullanmaya karar verdi. Bitkeeper, 2-3 sene sonra ücretli modele geçince bu kızgın adamın kafası attı.

Yine meydan okudu. Sırf çekirdeğini dilediği gibi katılımcı şekilde geliştirebilmek için bir dağıtık kod versiyonlama sistemi yani DVCS yazdı. Git yazılalı 11 yıl oldu. Aptal, huysuz bir adam demek Git. Yine sadece şaka amaçlı bir proje gibi değil mi?

Dünya kodunu şu an o şakanın üzerinde yazıyor.

Git'i Linus yazdı, Github meşhur etti. Ama Github olmasa da Git'in bir şekilde açık kod - Linux camiasından tüm ortamlara yürüyeceğini tahmin etmek güç değil. Github, en fazla bu geçişi hızlandırmış olur.

Bir mesele daha. Linux'un masaüstündeki geri kalmışlığına cevaben Linus, Android kartını oynuyor. Cebinizdeki çekirdek benim diyor.

…

Sizlere Linus'u anlattık. Ömrünün çok az bir bölümünü kodlamadan yaşamış olan bir insanı. Bilgisayara dokunduğundan beri, donanım seviyesinde kod yazıyor. Önüne çıkan yollardan hep zor olanı seçti. Kodlamanın sanatsal yanını yüceltti. Saplantılı biçimde iyi kodun, sanatın peşinde.

İyi kod belki de her zaman yazılmaz. Ama mutlaka, her yazılan kodun daha iyisi olacaktır.

Programcının derdi de keyfi de… işte bu arayışta.

Yaşasın Kara Konsol 2 Apr 2016 3:20 AM (9 years ago)

Kara Konsol ve grafik arayüz. Klavye ve işaretçi. Birinde işinizi hep yazarak dikte ediyorsunuz. Diğerinde grafik arayüzündeki eylemleri işaretçiyle tetikleyerek.

Tarihin görünen akışına bakarsak, artık kara konsola veda etmemiz gerek. Ama o da nesi.. Her geçen gün kara konsola bir hayat öpücüğü daha geliyor. RAD araçlarıyla konsoldan ve dahi kod yazmaktan uzaklaştırılan geliştirici camiası, tabir yerindeyse “eve dönüyor”.

Böyle diyoruz da konsol hiçbir zaman ölmedi. Endüstri sadece onu unutturacak bir ilerlemeler kaydetti. Özellikle Microsoft. 2016′da ise, bir Build geliştirici etkinliği sonrası Microsoft’un da üstad konsolu ana eksene aldığı bir manzara görüyoruz.

Windows’un içindeki standart konsol, işletimci arkadaşlar için oldukça yetersiz kaldığı için Powershell serüveni başlamıştı. Powershell, şu anda olgunlaşmış, Windows’u, sunucuları, uygulamaları ve Azure servislerini yönetebilecek, tüy gibi bir mekanizma. Grafik arayüzün ciddi bir alternatifi. Hatta bazı yerlerde alternatif değil, mecburi istikamet.

Gel gelelim geliştirici dünyasına.

Microsoft, geliştirici kanadını kara konsoldan uzak tutmayı uzunca bir dönem başardı. Hatta adı “Visual Studio Command Prompt” ya da “Visual Studio Developer Tools” olan özel ortam bilgileriyle ön hazırlığı yapılmış shell’i saklayacak yer aradı. Bunun iki olumsuz etkisi oldu camiaya. Birincisi usta geliştiriciler komut satırına erişirken acı çektiler. İkincisi ise daha vahim. Kalfa ya da çırak geliştiriciler ise komut satırını görmezden geldiler, ondan korktular. Microsoft da camiaya yardım olsun diye önceden sadece konsoldan yapılan şeyleri IDE’ye çekti zaman içinde. (Örneğin strong name (sn.exe) meselesi)

Microsoft’ta geliştiriciler için kara konsolu tekrar ana gündem hâline getiren üç ana mesele var: Git, NPM ve evet “bulut”. Evrimleşen web programlama, konsolu unutturan masaüstü programlamanın aksine konsolu tekrar öne çıkardı. Basit editörler ve konsol, güçlü ve konsolsuz bir IDE’den daha çekici olmaya başladı. (Visual Studio Code?)

Hadi Git ve NPM neyse de bulut tarafı, konsolda Microsoft’a radikal bir adım attırdı. Microsoft, Azure ile Linux’a öyle bir bağlandı ki artık Azure’un altyapı tarafında da kendi özelleştirdiği bir Linux kodunu kullanıyor. Yıllardır Hyper-V ile Windows dünyasında zaten Linux makine çalıştırıyor. Şimdi bir adım ötesindeyiz. Windows içinde “doğal”, aracısız Linux uygulamaları çalıştırmak. Linux çalıştırmak demediğimizin farkındasınız umarım. “Linux uygulamaları (ELF)” çalıştırmak. Çünkü hepsi özgür, hepsi olgunlaşmış ve artık Linux’un buluttaki üstünlüğü nedeniyle sizi kendine mecbur bırakmış araçlar.

Düşünün yıllarca Windows’ta SSH bağlantı için Putty’ye mahkûm olduğunuzu. Bir nitelikli GNU uygulamacığın Windows port’unu bulayım diye interneti dolandığınızı.

Microsoft, Ubuntu’nun sahipleriyle masaya oturmuş. Beraber “wine”ı terse çevirmişler. (Wine, Linux üzerinde Windows uygulamalarını çalıştırmak için kasılmış teknoloji).

Burada bir sanal makine ya da konteyner yok; ortada Linux kernel yok. Sadece havada API avlama var.

Teknik olarak Microsoft’un burada ne yaptığını bilmemiz önemli. Bilirsek, imkânları ve planı daha rahat anlayabiliriz.

Önce biraz geri saralım ve geçen senin Build’ine gidelim. Yaklaşık bir sene önce Microsoft, Windows platformunü yüceltmiş ve rakip platformlardan da uygulama getirebileceğimizi söylemişti. iOS ve Android uygulamaları idi hedef. iOS tarafında kodun tekrar derlenmesi gerekirken Android için doğrudan APK’ları çalıştıracağını söylüyordu. Project Astoria olarak adlanırdığı bu teknolojiyle, hiçbir değişiklik olmadan Android uygulaması Windows 10 mobil platformunda çalışabilecekti. Bunun için Microsoft, Android emülatörü geliştirmişti. Uygulamanın yapacağı API çağrılarını Windows platformunda karşılayacaktı. API avlama tekniği yani. Proje fazla sürmeden rafa kalktı. (Muhtemelen Xamarin’i alma kararı o tarihlerde verildi ve bu proje lüzumsuz hâle geldi).

Ama tecrübe ve bilgi rafa kalkmadı. Mühendisler aynı tecrübeyi bu sefer Ubuntu uygulamalarını ve öncelikle “bash” kabuğunu taşımak için kullandılar. İşte elimizdeki imkân bu: hiçbir Linux kernel’i, sanal makinesi olmadan çalışabilecek doğal GNU/Linux uygulamaları.

Henüz daha salınmamış bu özelliğin detaylarını Build’deki konuşmalardan alabiliyoruz. Söylenene göre bilgisayarı “geliştirici” moduna çekip, uygulama mağazasından indirebileceğimiz bir Ubuntu imajı olacak. Bu imaj, Ubuntu’nun ana dosya sistemini barındıracak ve kullanıcı alanına (Local AppData) kurulacak.

Bu imaja giriş noktamız ise, tabi ki popüler bash kabuğu.

Herhangi bir işletim sistemi boot’u olmadan, kendinizi bir Ubuntu dosya sisteminde ve ortamında bulacaksınız. Apt-get ile paket kuracaksınız. SSH uygulaması ile Putty’ye veda edeceksiniz. Vi ile metin düzenleyeceksiniz. Dosya sistemi ise, standart bir Ubuntu ve içinden bir noktadan geçebildiğiniz (/mnt) kendi bilgisayarınız. Tüm bunları sağlayan, yani Ubuntu’nun “native” komutlarını kandıran ise Windows Subsystem for Linux.

Ubuntu imajındaki Linux uygulamaları Windows ile aynı network yığıtını kullanacak. Yani bu demek oluyor ki bu imaj içerisinde bir web sunucu kurup çalışabilirsiniz.

Lâkin çok heyecanlanmayın. Bu Windows’unuzu bir Linux sunucuya çevirebilecek güçte bir şey değil. Öyle olmasını da beklemeyin. Olacağını da düşünmeyin. Linux kernel’inde çalışmayan bir Linux sunucusu, tercih edilecek bir şey olmaz herhalde. Amaç geliştiricileri VM yükünden kurtarmak; bash konsoluyla aralarındaki uzaklığı kaldırmak; GNU/Linux dünyasının birbirinden yetenekli-değerli araçlarına hızlıca ve performans kaybetmeden erişmelerini sağlamak.

Windows-Bash’ta diğer Windows kabuklarıyla etkileşim olmayacağı söyleniyor. Doğal olarak buradan doğal Windows uygulamalarını da tetikleyemeyeceksiniz. Yine Mono’ya ihtiyacınız var. (Zaten ne gerek var burada Windows uygulaması tetiklemeye diyebilirsiniz de senaryonun içine düşersiniz, o zaman sorarsınız). Bash’ten Powershell script’i tetikleyemeyeceksiniz meselâ. Bash aynen Bash gibi çalışacak. Sistemle ortak noktanız, dosya sistemi.

Ayrıca Bash konsolunu ve bütün çalıştırdığı uygulamaları kendine has bir Windows prosesinde çalıştırdığını söylüyor mühendisler. Yani “task manager”da muhtemelen konsoldan çağrılan uygulamaları ayrı ayrı göremeyeceksiniz. Tabi bu tasarım, ileride değişebilir.

Bash’ın ve Linux’un yerli programlarının, “olduğu gibi”, yeniden derleme olmadan Windows’ta çalşabilecek olması… heyecan verici bir adım. Arada Cygwin gibi suni modeller sokmadan doğrudan Linux evrenine erişmek.

Artık bir şeylerin Windows port’unu aramaya gerek yok. Mac’te geliştirme yapanların bir mazereti de ellerinden alınmış oluyor.

Konsola ve “platform bağnazlığıyla mücadele ruhu"na saygıyla.

Kaynaklar:

Bir oğlum olsun; adı Çevik olsun 26 Mar 2016 1:55 PM (9 years ago)

İnsanoğlunun derinleştiği her alanda olduğu gibi Yazılım endüstrisinde de kavramların zemini oynak ve her kavram bir maşa. Meşhur araç - amaç dengesizliği, sıradan gündemimiz.

Elimizde çok kavram var. Bazıları güncel. Bazıları güncelliğini yitirse bile dönüp dolaşıp her bahse giriyor. Güncel olan kavramlar çok çabuk tüketiliyor ve konuşana iyi kazandırıyor. Çünkü önemli olan, konuşmak.

Ama konuşmaya karşı olduğumu çıkartma lütfen sevgili okur. “Bârika-i Hakikat, Müsademe-i Efkâr’dan doğar” şeklinde adeta bir SHA1 hash’ini andıran deyişimiz var: gerçeğin kıvılcımı, fikirlerin çarpışmasından çıkar. Fikirlerin çarpışması için de konuşmamız, yazmamız, mention’lamamız, like’lamamız gerek.

Yabancı dilde buzzword ile karşılıyorlar bu kavram tutkusunu. Teknik olan kavramlar ama teknik olmayan insanların daha çok kullandığı kavramlar. Ya da ehil olmayanların daha çok kullandığı diyelim.

Doktorların kendi alanlarına dalmaya çalışan hasta veya sıradan vatandaşlar için pek müsamahalı olmadıklarını biliyorum. Hastalığının ismini latince söyleyen bir adama gözlüğün üzerinden dik dik bakabiliyorlar. Hiçbir zaman branşlarındaki kelimelerin buzzword hâline gelmesine izin vermiyorlar. Tıp ilmini halkın kendi sınırlı lügatiyle çevirmesinde mahzur değil, maslahat görüyorlar.

Ya bizler sevgili okur?

Biz sözlüğümüzü (Cemil Meriç’in namus dediği şeyi) koruyamıyoruz. Tekniğimizin içindeki her şey, dışarıda biliniyor ve dışarıdakiler bizden çok biliyor onları. Biz proje demeden onlar Agile diyor. Biz kod demeden onlar TDD diyor. Biz kodu derlemeden onlar buluttan bahsediyor. Biz yemeğe çıkalım derken onlar SaaS olmadan asla diyor.

Yazılım geliştirme endüstrisi, yazılm geliştiricilerden daha çok, onları yönetmek ya da İngilizce için affedin, handle etmek isteyen gayri-teknik insanlardan oluşuyor. Gayri-teknik sınıfın içine bir zamanlar teknik olmak ama güncel olarak gayrı-teknik davranmak da giriyor.

…

Çeviklik. Agility. Aslında “Agile Manifesto” çıkmasaydı, cümle içine serpiştirdiğimizde alerji üretmeyecek bir kavramdı. Çevik derken anlatmak istediğimiz bir şey vardı. Çeviklik deyince bizden, hayatımızdan bir şeyler kast ediyorduk.

Oysa ne olduysa oldu, seçilmiş adamlar toplandı ve Agile bildirisini ürettiler. Yazılım endüstrisinde Erzurum Kongresi gibi bir etki yapmış olmalı ki sürekli oraya referans verip duruyoruz.

Manifesto, dogmatik bir yörünge çizmiş bundan sonra üreyecek buzzword’lere.

İtirazım var.

Benim “çevik” kelimesi üzerinde oluşmuş alerjiye itirazım var. Bu kelimenin, aslında lügatimizde var olması gerektiğini ve Manifesto ile alakasının da olmaması gerektiğini düşünüyorum.

Çeviklik, bir organizasyonun, bir takımın hızlı karar verip kararını uygulayabilmesini ifade eder. Biz Şelaleci olsak da çevik olmanın avantajı vardır. Bu bir din veya bir tarikat değil; günlül hayata da tatbik etmemiz gereken bir iş yapış tarzıdır.

Gelelim bizim manifestonun çevikliğine.

Günümüzde “çevik”leşme oranının yükseldiğini görüyoruz. Ülkemizde bile çevik yöntemlere bulaşmayan yazılım evi kalmamış sanki. Üretim tarzına yeni bir soluk geliyor ve ekipler, çevikliğin renkli dünyasıyla “okul öncesi” sınıf ortamının tadını çıkarıyorlar.

Scrum, ritüelleriyle bir pratik inşa ediyor ve yazılım ekiplerine “business drive development”i gururlarına dokunmadan empoze ediyor ya da dayatıyor.

Ve halkın çevikliği.

Hepimiz çeviğiz; çünkü kod yazmadan önce test yazıyoruz. Hepimiz çeviğiz; çünkü her sabah dünü, bugünü ve yarını konuşuyoruz. Hepimiz çeviğiz; sık iterasyonlarla değer üretiyoruz. Hepimiz çeviğiz; sürecimizin yamuk yerlerini sürekli düzeltiyoruz, traşlıyoruz.

Manifestocu çeviğiz somut göstergelere göre. Mükemmeliz.

Ama mutlu bir çevik miyiz?

Proje yöneticileri, kilometre taşlarının tamamlanma yüzdelerine göre mutlu oluyorlar. Scrum Master’lar ekibi her sabah ayakta görünce mutlu oluyorlar. Ürün yöneticileri, iterasyon sonundaki “done”larla mutlu oluyorlar. Müşteriler, kendisine gıdım gıdım akan ürünle mutlu oluyorlar. Üst düzey yöneticiler, tüm bu adamların mutlu olmasıyla mutlu oluyorlar.

Üstad biz ne üretiyoruz? Sucuk üretmesek bile bu kadar jargona ve sürece takılmamız fazla değil mi?

Son zamanlarda “Agile yeni Waterfall oldu” tarzında yergiler görüyorum. Buna en canhıraş cevabı Robert Martin veriyor. “Agile yaptım olmadı” diyene, “sen Agile’ı yapamamışsın ya da hiç anlamamışsın” gibi karşılıklar geliyor.

Yani buzzword’lerin bir özelliği de tenkit edilememeleri. Kafayı takarsanız, üstadın biri sizi tokatlıyor. TDD işe yaramadı diyor bir üstad. Sorun TDD’de değil sende diyor Uncle Bob. DHH “TDD öldü, çok yaşa test” diyor; Kent Beck gönül koyuyor.

Meseleleri daha tartışamıyoruz bile. Önce kavramları özgürleştirmemiz gerek kanımca.

Derim ki çevik olalım. Müşteriye değer üretelim. İteratif çalışalım. Kendi kendini test eden kod yazalım. Müşteri ile birebir çalışalım. Teknik borçlanmaya kaymayalım; borcumuzu çabuk ödeyelim. Sık aralıklarla bir araya gelelim. Ne yaptığımızdan herkesin haberi olsun. Ne yapacağımızı illa kendimizin bilmesi (programmer anarchy) gerekmez; birisi söylese de olur. Birbirimizin kabiliyetlerini, know-how’ını genişletelim, geliştirelim.

Çok kod yazalım. Çok eğlenelim. Makineler çalışsın, sürekli derlesin. Ortamlar sürekli ayakta kalsın, indikatörler ışıldasın. Manifestoya inat dokümantasyonumuz olsun. Blog’umuz ve portalımız olsun. Ortamımızda 3M post-it’leri, iğneler, boncuklar, yol haritaları, takvimler ya da “retrospective” kalıntıları olmayabilir. Ama yeter ki…

Kod da orada yazılsın, manifesto da.

Netice: Manifestonun çeviği olmadan da çevik olabilirsiniz. Biz buna öz-çevik diyoruz. Deneyin.

Kod yazmayı mı unuttuk? 24 Mar 2016 2:15 PM (9 years ago)

Ne oldu bize?

Paket yöneticileri çıktı; mertlik bozuldu. Nerede o eskinin civanmert, delişmen, kod üstadları? Buna benzer bir isyana düşmüş aynı evrenden bir programcı.

Konu belli, farkındasınız. NPM ve left-pad ve Azer Koçulu. Bilmeyenler için özet: Azer Koçulu, Nodejs’in resmi paket katalogunda yüzlerce paketi kullanıma sunulmuş bir javascript geliştiricisi. Kik, bir mesajlaşma programı. Kik’in avukatı Azer’den bir paketin ismini değiştirmesini istiyor; ayağına sıkarız diyor. Azer de muhtemelen direniş kodlu bir ruha sahip olduğu için direniyor. Olay NPM’cilerin Azer’den paketi farklı bir ada taşımasını istemesiyle geri dönülmez noktaya geliyor. Bizim Azer, gemileri yakıyor ve tüm paketlerini NPM’den çekiyor. Kelebek etkisi bu andan sonra başlıyor. Dünyanın prestijli Nodejs projelerinin derlemeleri birer birer kırılıyor. Sürekli derleme ve sürekli entegrasyon ortamlarında adeta bir terör saldırısı paniği yaşanıyor.

NPM, kendine 2.5 saat sonra geliyor. NPM’e bağlı ne varsa kesinti boyunca sürünüyor.

Günümüzün sürekli derleme bağımlılığı yüksek olan noktalarında, bir build’in kırılması demek… yangın alarmı demek. Her yıl geliştiriciler bunun tatbikatını yaparlar.

Bu krizle herkesin alması gereken birçok ders tekrar ortaya çıktı. Aslında mühendisler o kadar da boş insanlar değildir. Bunları neden göz ardı ediyorlar bilemiyoruz. Vendor-lock’ı, dependency-hell’i, single-point-of-failure’u yıllardan beri konuşuyoruz. Neden 2016 mart ayında dünyanın en popüler paket yöneticisi, bu basit yıkıma uğruyor?

İşin en dramatik tarafı, Azer’in NPM’den çektiği kodun işlevi ve boyutu: string’i sağa yaslayan, Javascript’te olmadığı için Azer’in eklediği, NPM’e paket olarak koyduğu fonksiyon. Fonksiyon, evet.

Ve 11 satır:

Bu 11 satırı herkes kendi yazmayıp, paket yöneticisi kültürüne uygun olarak NPM’den çekiyor. Şimdi büyük projeler, bağımlılıklarını bir bir gözden geçirir. Ivır zıvır kodları içerlerine alırlar. Build sunucuları daha fazla kod derleyecek ama olsun, kod benim mülküm. ,

NPM’cilerin kendisi de hayret ediyor ki NPM’deki paketi “unpublish” etmek de bu kadar kolay ve anlıkmış. O da dersini çıkardı. Sürece bağlayacak.

Ama kimse isim hakkıyla alakalı kısımdan bir ders çıkarmıyor. NPM’ciler, Azer’i neden böyle zorladıklarına dair bir öz eleştiriye soyunmuyor. Kik’çiler, biz iyi insanlarız, Azer yıkımcıdır mavrasında. Azer’e yazdıkları kaba saba, küfürlü e-posta ile ilgili özür de dilemiyorlar.

Bu dünyanın sessiz bir kuralı var sanki: kalp kır, build kırma.

SOA - ESB İttifakı Sarsılıyor 21 Feb 2016 12:27 PM (9 years ago)

Birbirinin içinde doğmuş iki kavramdan söz ediyoruz. Benim kurumsal mimari jargonunda çok takıldığım en prestijli üç harflilerden. [Bu üç harfliler o kadar artmış ki artık, çakışmaya başladılar. Örneğin MDM dediğinizde ne anlaşıldığını değişik yerlerde test edin bakalım.]

Zor bir mesele bu. Birbiri içinde doğmuş, adeta etle kemik olmuş iki ana akım BT paradigması, bir ayrılık sürecinde. Her ne kadar iki tarafın yılmaz savunucuları arasında bunu kabul etmeyenler çıkacak olsa da ESB’nin SOA’nın ilk versiyonuna ait “eski sevgili” hükmüne geldiği gerçeği artık daha fazla hissedilecek. Çünkü şahit olduğum kadarıyla ESB profesyonelleri de durumu değerlendirip, ikinci SOA dönemine geçişi konuşuyorlar.

Burada SOA’nın bir ürün olmayıp, bir anlayış olması ve zamana göre daha kolay evrilebilmesi ve hatta yeniden yorumlanabilmesi (“siz onu yanlış tanıdınız; doğrusu buydu”) avantaj olarak gözüküyor. Dezavantajlı taraf, global firmaların elinde bulunan ve üzerinde ağır bir bakiye taşıyan, artık olgunlaşmaktan içindeki çekirdekleri sertleşen ESB ürünleri (ya da ürün aileleri). SOA 2016 için kendine bir yol buluyor. ESB’ler ise, gelmeleri beklenen nokta olan API Gateway’e ulaşmanın arayışında ya da aramayışında.

Sektör profesyonelleri bu satırları işkembeden sallayarak yazdığımızı düşünmesin. Yaklaşık bir buçuk sene önce ürün sahibi olarak bulunduğum Scrum takımımızın elindeki iş buydu: bankaya ESB kazandırmak. Doluya koyduk, boşa koyduk, indirdik, kaldırdık. Takımımız o gün şu çıkarıma vardı: “Bize ESB değil, API Gateway lâzım. Gideceğimiz yer orası.” Bu karar, üst yöneticilerimizin de desteğiyle uygulandı. Bir toplantıda ESB’ler için “kadük” tabirini kullanmıştım. Şu an ESB profesyonelleri aynı sözcüğü kullanıyor. Benim gönlüm rahat.

ESB, kimsenin servis yazamadığı, komşu sistemlere tüketsin diye “host” edilemeyen kodların ve veritabanı prosedürlerinin bol olduğu çağların bize emaneti. Günümüzde büyük ESB teşekküllerine baktığınızda, bu emanetin izlerini görürsünüz. Aslında amacı kod yazmayı ortadan kaldırmak değil, servis katmanı olmayan uygulama silolarına servis arayüzü ve konuşma hattı (bus) sağlamaktır. Elbette kesişen ihtiyaçları (cross-cutting concerns) da kotarabilecek, “kurumsal mimari”nin üzerinde mevzilenebileceği merkezi bir tepe, güç noktası olacaktır.

Gücün tek merkezde toplanması, otokrasi, günümüz BT’sinde sanırım en son istenen şey. ESB’ler, kendilerini ne kadar hafifletirlerse hafifletsinler… konsept olarak güçlü olmaya mahkumdurlar. Eğer taviz verirlerse, ESB olamayacaklardır.

Gelelim SOA’ya.

SOA’nın olgunluk seviyesindeki noktaları bırakalım, geliştiriciye yansıyan tarafını ele alalım. 2016’ya gelmişiz. Servis yazma pratiğinde yediğimiz önümüzde, yemediğimiz arkamızda. Google’ın ayrılıkçı dili Go ile servis yazıp, yine Google’ın oyuncağı Python ile tüketiyoruz. Javascript ile kod yazıp, Node.js ile sunucu tarafında çalıştırıp servis sunuyor: kodu kopyalayıp, internet gezgininde de o servisi tüketiyoruz. Bir REST API yazalım dediğimizde internet sanki fırsat sitesi gibi önümüze birbirinden alımlı framework’ler getiriyor. Her biri yazılan kodun ne kadar “seksi” olduğuna bizi ikna etmeye çalışıyor. [Bu arada yine endüstrimizin cinsiyetçi tarafına denk geldik, eyvah.]

Yani, servis yazmak artık sorun değil. Bir iş mantığını standart protokoller üzerinden tüketilebilir hâle getirmek, en sıradan yazılım pratikleri arasına girdi. SOA’nın temelleri bundan sarsılacak değil. Çünkü o sınırları olan servisler yazmanızı ve hep servisten servise şahin uçurmanızı istiyor. Tek derdi: yönetmek.

Herkesin servisini kendi kendine en olgun şekilde yazabildiği bir ortamda ESB’nin iş kurallarını barındıran, yürüten şef rolünü dinamitlemiş oluyoruz. ESB’ye sadece “yol ver, yeter” diyoruz.

O sihirli kelimeyi müsadenizle söyleyeceğim: Mikroservisler. Bir de onlar var ESB’ye muhalif.

Martin Fowler, uzunca olaya daldığı yazısında REST kitaplarından birinin yazarına ait şu sözle ESB’lere selam çakıyor:

“Be of the web, not behind the web” – Ian Robinson

Buradan her fâni gibi biz de ESB’lere web’in gerisinde kalmış bir yapı dendiğini anlıyoruz. Tahiroğlu efendi “kadük” dediğinde şaşırmıştık?

Web, gayrı-merkeziyetçi bir yapı. SOA’nın “governance” (hükümet) tarafı ise burada onunla çatışıyor. Mikroservisçi yaklaşım web’in gayrı-merkeziyetçiliğini model alıyor. Bizi oraya götürmeye çalışıyor. SOA’nın endişelerini ise (altının dolu olup olmadığını tam keşfemediğimiz) “decentralized governance” vaadiyle karşılıyor. Yani SOA’ya, seni reddetmiyorum, seni seviyorum ve kalkındırıyorum diyor. ESB’ye ise, tahtın sallanıyor diyor.

Smart endpoints, dumb pipes: Belki de ESB’ler için “kadük”ten sonra söylenmiş en ağır laf. Sen kalk milyon dolarlık, hükümet gibi ürünlerin pazarında “bana dumb pipe lazım” de. [Martin Fowler’in neden kurumsal mimari ortamlarında sevilmediğini anlıyor musunuz arkadaşlar.]

Bir mikroservis yazımızda (Türkiye’deki ilk mikroservis lakırdısıdır) şöyle demiştik:

SOA'nın işaret ettiği aşırı merkeziyetçi yapı, Mikroservisin reddettiği şey. Zaten merkeziyetçi değil, güçlü yerel yönetim ekseninde duruyoruz Mikroserviste. SOA'da eli maşalı, ceberrut bir rolde gördüğümüz ESB, Mikroservis yaklaşımında getir götür işlerine bakan bir postacı (haberci) oluyor. ESB'nin feodal ağalığına son veriyor bu sistem bir bakıma. (Mart, 2014)

ESB ile davamızın eski olduğu belli oluyor.

Yol ayrımına gelmiş durumdayız. HTTP’nin ikinci versiyonu, web protokolünün yerini daha da sağlamlaştıracak ve alternatif ham TCP protokollerine olan aşkı dindirecek [HTTP/2 binary abi, daha ne olsun!]. Basit, hafif ve temiz API’ler daha fazla etrafımızda dolaşacak. Bulutun gölgesi camdan içeri, ofise düşecek.

Söylüyorum bakın global üreticilere: API Gateway’e ve açık sistem çalışacak, API desteği yüksek BPM/BRMS’lere verin kendinizi.

Son söz: SOA ile konuştum. Durumu iyi. ACID Transaction’lar ile ilgili konularda endişeleri var. Bir başka hasibahlimizde de oraya değiniriz.

…

Duyuru:

5 Mart 2016 Cumartesi günü Bahçeşehir Üniversitesi’nde DevNot Bulut Bilişim Zirvesi var. Fakirin de bir sunumu olacak. Bu konudan da bahsedeceğiz. Kayıt: zirve.devnot.com.

İlginizi çekebilecek alakalı yazılarımız:

- Mikroservislere sığınmak – 1

- Mikroservislere sığınmak - 2

Cübbeli Martin Hoca 5 Feb 2016 12:30 PM (9 years ago)

“Ekmek paramı danışmanlık ve eğitimle; değişik işletmelerde geçen, 10 seneyi aşkın, nesne yönelimli bilgi sistemleri geliştirme tecrübemi paylaşmakla kazanıyorum.

"Amacım gayet basit: öğrendiğim dersleri ve edindiğim tecrübeleri aktararak kendimi müşterim için gereksiz hâle getirmek.

"Danışmanlığımın ana odağı, iş nesneleri (business-domain objects) geliştirmek. Muhasebe, nakliyat, sağlık ve finans gibi değişik alanlarda bu tarz geliştirmeler yaptım. Bu işleri yaparken analizin, tasarımın, programlanın ve testin her türlüsüne girdim çıktım. Müşterilerimin uzun yaşayan bir yazılım sistemine temel sağlayacak düzgün ve pratik bir domain model oluşturmalarına yardım ettim. Bir domain model, çok katmanlı sistemin anahtar parçasıdır ve bunun kalitesi tüm sistemi etkiler.

"Bu şekilde model tasarlamanın bazı şartları vardır.

"İyi yazılım için iş sahibiyle, müşteriyle ve sistemin kullanıcılarıyla yakın olmalısınız. Geliştirme ekiplerine işi anlamada, gereksinimlerini anlamada ve gereksinimleri karşılayacak nesne modeli geliştirmelerinde yardımcı oluyorum. Geliştiricilere iş insanlarıyla beraber çalışmayı ve hatta iş insanlarına geliştiricilerle çalışmayı öğretiyorum.

"Etkili bir nesne modeli için geliştirici ve iş tarafıyla beraber çalışırım. UML'i faydalı bulduğum bazı teknikleri de ekleyerek kullanıyorum.

"Domain model oluşturmadaki tecrübem, beni pattern'ler konusunda epey hassaslaştırdı. Sonunda bir kitap bile yazdım. (Analysis Patterns) Müşteriyle olan çalışmalarımda, bu pattern'leri nerede kullanacaklarını tespit etmeye, kullanmaya vs. yardımcı oluyorum.

"Evrimsel geliştirmenin koyu bir taraftarıyım. Bunun yanında kendi kendini test eden koda ve refactoring'e de güçlü bir bağlılığım var. Bu tekniklere de geliştiricilere olan aktarımlarımda mutlaka yer veriyorum.” (kaynak)

- Martin Fowler, ~1999

Pattern'ler.

Martin Fowler hocanın hayatını anlatan iki kelimeden birisi.

Diğeri ise bildiniz: Refactoring.

Sizlere bir yazılımcı olarak illaki adını duyduğunuz, yanına koştuğunuz, kafanıza bir şey takıldığında rasgele bir makalesini tükettiğiniz, havalı olsun diye kitaplarını taşıdığınız, şeyh-mürid ilişkisine benzer bir bağlılıkla sevdiğiniz ya da endüstriyi yeni nesil kavramlarla zehirliyor diye nefret ettiğiniz bir kalender adamdan bahsedeceğiz. Martin Fowler'dan.

Britanya'nın Tezenesi

İnterneti bulan adamın (Tim Berners-Lee) İngiliz olduğunu biliyorsunuz. Her ne hikmetse, İngilizler internet üzerinde de sessiz ama hâkim konumdalar. Orta Avrupa'dakilerin ve kuzeyin programlamada, İbrani bölgesinin güvenlikte ve algoritmalarda oluşan görünürlüğü, İngilizlerde masa başında bir sessizliğe ve mutlak hakimiyete dönüşüyor.

Ama Martin'e sessiz bir güç desek doğru olmaz. Mühendislik eğitimini Londra'da tamamlayıp sahaya çıktığı günden beri aynı tempoda koşturuyor. Ekmeğini, kendi de dediği gibi başkalarına bir şey anlatmaktan kazanıyor, 25 yıldır.

1994'te ABD'ye göç ediyor.

Tabi göç ederken muhtemelen memleketine saydırarak göç etmiyor. Tıpkı Linus Torvalds'ın da göç ederken Helsinki'ye saydırmadığı gibi. Niyeyse biz Aziz Sancar o kıtada Nobel ödülü aldığında buradan sancılanıyoruz. Buna karşın Britanya kıtası, ABD'ye uğurladığı nice beyinle gurur duyuyor olmalı.

ABD'ye gelen Martin'in yoğun bir danışmanlık mesaisi başlıyor. Daha sonra sıkı dost olacağı çevik yazılım gurularıyla tanışıyor, dertleşiyor. Yazılım seminerlerine bildiriler gönderiyor. 1996'da büyük bir titizlikle analiz ettiği iş günü - tatil günü meselesi takdire şayan.

Soylu bir eylem olarak “yazmak”

Martin Fowler, danışmanlığının taze yıllarında bildiri yayınlayarak, seminerlere katılarak ve daha duayen programcılarla tartışarak heybesine birçok konsepti dolduruyor ve bir yandan da bunları analiz ederek yeni çıkarımlara ulaşıyor. Yani basit ifadesiyle, zihin taşmaya başlıyor.

Zihni taşan aydınlar, toplum için büyük kazançtır. Yazın ve kültür, onlarla inşa olmaktadır.

Martin de yazmayı öncelikli bir eylem olarak görüyor ve hep yazıyor. ACM'de, DistributedComputing dergisinde, IEEE Software'de…

Sadece makaleler değil, kitaplar geliyor. İlk ilgilendiği konu Analiz Pattern'leri. Sonra -artık çok öncelik vermediği- UML Distilled. Bu iki kitaptan sonra, hayatının sonraki dönemlerini rahat geçirmesini sağlayacak mühim bir kitabı yazıyor: Refactoring: Var olan kodun tasarımını kalkındırmak.

Extreme Programming (XP) pratiklerinin mucidi Kent Beck'in katkıda bulunanlar arasında olduğu, GoF Design Pattern kitabının yazarlarından Erich Gamma'nın da önsöz yazdığı bu kitap, Martin'in eskimeyen, hep güncel kalacak olan nadide eseri.

Refactoring kavramını kendisi bulmamasına rağmen, “Refactoring'i Martin Fowler buldu” inanışının da sorumlusu bu kitap.

Yeni yüz yıl; yeni iş

2000'de Martin hocanın ABD vatandaşlığını kabul edip temelli bir Boston insanı olduğunu… ve evet bir de yeni bir işe girdiğini görüyoruz: ThoughtWorks. O zamanlar küçük bir danışmanlık firması. Tam hocaya göre. Hoca, orada kendine çok vizyoner bir ünvan seçiyor: Scientist. O gün bugün aynı firmada ve aynı ünvanla çalışıyor. Şef Biliminsanı.

Hayatı, yazılım mühendisliği üzerinde düşünmekle ve üretmekle geçen bir endişeli adam için oldukça uygun bir ünvan olsa gerek. Twitter profiline baktığınızda da kendine hâlâ “programcı” diyen bir sıradan mühendis.

Martin hocanın son 20 yılına baktığımızda, davasını net olarak görebiliyoruz: basit, işe yarar, müşteriyi mutlu eden ve gelecekte de mutlu etme potansiyeli olan iş yazılımları üretmek. Bu çok güzel, herkesin hoşuna giden bir üst hedef. Martin'in farkı, yıllardır bunun altını dolduracak şeylerle uğraşması. 20 yıl önce yazdığı yazıda, “yazılımı yumuşak tutalım ki değişimlere hızlı adapte olsun” diyor. Ama nasıl yapılacağını da söylüyor: dinamik tasarım. O zamanlar Agile ya da Scrum gibi ya da Evrimsel Tasarım gibi kavramlar daha uydurulmadığı için kendisi bunu uydurmuş.

Yıllar geçiyor, hoca hâlâ aynı hedefe yönelik şeyler söylüyor. Ama bugün düne göre elbette farklılaşan araçlar, platformlar, manifestolar (hehe, Agile evet) ve imkanları da heybesine katarak. Bugün size container'lardan faydalanın derken dün belki monolitik sistemde bir pattern öneriyordu.

Önemli olan tutarlı olması. 20 yıl önce yazdığı yazıyı, terimleri güncelleyerek hâlâ aynı olgunlukta değerlendirebilirsiniz.

Kurumsal Pattern'ler

Martin Fowler, 2002 yılında, -bence- en değerli kitaplarından birini yazıyor: Patterns of Enterprise Application Architecture.

O güne kadar daha alt seviyedeki pattern'lerle ilgilenen yazılımcılara, kurumsal yazılımların pattern'lerini çıkartıp gösteriyor bir bir. 14 yıl önce yazılmış bir kitap. Şu an baktığınızda %90 oranında günümüze de ışık tutuyor. Güncellenmesi gereken yerleri var fakat hâlâ referans kitap olarak ışıldıyor.

2010 ve 2012'de kütüphaneye ekleyeceği iki kitap, onu yazılım edebiyatında değerli bir konuma getiriyor. Birisi Domain-Specific Languages, diğeri deNoSQL Distilled. İkisi de spesifik bir konuda yazılmış referans kitaplar. İkisi deRefactoring veya PoEAA kadar kapsamlı değil. Ama yine de kitaplıkların önemli bir parçası.

Martin ve insanlar

Söylemiştik ya Martin çok dolaşıyor. Dünya üzerinde nerede bir “iyi yazılım” bahsi varsa, orada Martin boy gösteriyor. İlk zamanlar bildirilerini sunarken, konuşmacı olmaya başlıyor. Şimdi ise, elbette açılış konuşmacısı, keynote speaker.

Sahnelerin tadını iyi biliyor.

Tanışıyor, irtibat kuruyor. (alt resimdeki DHH)

Dinliyor.

Takati yettiğince konuşuyor.

Dinlenirse de yine sahnede dinleniyor.

Onu cross-platform bir adam olarak düşünmek doğru olur. ALT.NET'teki sakallılardan birisi de oydu elbette.

Bu kadar dolaşan hoca, ilginçtir İstanbul'da sadece bir kere göründü. O da bir 2014 eylülünde. “Dünyaca ünlü yazılım dahisi” yağlamasıyla. (Bugüne kadar niye gelmediği ve niye fazla gelmeyeceği böylelikle belli oldu)

Çünkü adama ana akım medyamız Justine Bieber muamelesi yapıp işin suyunu çıkardı.

Aslında Martin Fowler'in Istanbul'a ancak ve ancak Hepsiburada'nın reklam ve gösteriş için hazırladığı etkinlik için gelebilmesi, Türkiye'deki yazılım sektörü için üzücü bir tablo. Hocanın her yıl Prag'daki, Amsterdam'daki veya Kopenhag'taki irili ufaklı birçok etkinlikte açılış konuşmaları yaptığını biliyorsanız… gerisini anlatmaya gerek yok.

Biz Türkiye'ye rock-star dışında bir şöhret getiremiyoruz. Getirsek de ona rock-star muamelesi yapmamız gerekiyor.

İnşaat ve Yazılım ilişkisi

İnşaat mühendisliği ile yazılım projelerinin kanlı bıçaklı ama aynı zamanda aşk dolu bir ilişkisi vardır değil mi? Martin bunu doğrudan özel hayatında yaşıyor.

Martin, bir inşaat mühendisi olan Cindy (Chabot) Fowler ile evli.

Kitaplarında, makalelerinde, Twitter demeçlerinde sürekli bir “eşim Cindy” atfı görürsünüz. Sürekli inşaat mühendisliği prensipleriyle mukayese edip, yazılımı özgür bir disiplin hâline getirme çabasına tanıklık edersiniz. Belki tanışmalarına vesile, bu iki branşın birbirine yakınlığıdır. Ama adamın davası, yazılımı kendi ayakları üstünde duran bir yere getirmek. İnşaatın terimlerinden sıyırmak.

Belki de bu nedenle sabah akşam terim üretiyor ve tutundurmaya uğraşıyor.

Bu yazımızın kapağındaki dalgıç Martin fotoğrafı da Cindy hanıma ait. Tıpkı şu “Kindle'dan gün ışığında kitap okumaya çalışan Martin” gibi.

Kamus namustur

Martin Fowler, yazılımın “namus"u için, kendisine özel bir kamusu, yani terminolojisi olması gerektiğinde ısrarcı. Bu nedenle, ısrarla Kent Beck, Erich Gamma ve Eric Evans gibi kavram makinesi adamların izinden gidiyor; o da yeni kavramlarla bilim dalımızı derinleştiriyor.

Dependency Injection. Şimdi günlük bir "merhaba” gibi ağzımızdan kolay dökülen bu terimi kim bilir Martin ne kadar düşündü değil mi?

Daha birçok kavramın peşinden giden Martin, başkaları tarafından üretilen ama zamanında değerini bulmayan kavramları da cilalıyor ve “hype” hâline getiriyor. Örneğin Refactoring. Ve örneğin, gerçekten örneğin, Microservices.

Kendisi bir twitter demecinde değinmiş fakat benim de kitabı okurken dikkatimi çekmişti. PoEAA kitabında “distributed computing” bahsine şöyle başlıyordu: “the first rule of distributed computing: don’t distribute your objects”. Evet, mikroservislerin temelini oluşturan fikri, sakalı da varken üstelik, yazmış adamcağız.

Dinlememişiz de SOA kaptanı olmuşuz.

Martin'in Öğretisi

Martin Fowler, aslında bir yazılımcıdan daha çok, ünvanına yaraşır bir biçimde biliminsanı. Yazılımcı ile biliminsanı pozisyonları arasına mesafe koymak istemiyoruz ama yazılımın nihai ürününden çok yazılımın kendisiyle, süreciyle ve kalitesiyle ilgilenen bir insan olduğuna vurgu yapmak istiyoruz.

Her yazılımcı bir emekçi. Yazdığı kodla, nihai bir iş ürünü çıkartıyor. Her gün, her saat makineyle mücadele ediyor. Gayesi makinenin makine gibi çalışıp, insanın hayatını kolaylaştırması.

Peki bu üretim nasıl daha hatasız, daha hızlı ve daha bilimsel olacak? Karşılaştığımız sorunları kim çözecek? Biz bu sorunlarla uğraşırken, ürünü kim geliştirecek? Aha da bir pattern yakaladım dediğimizde patron bize küçük altın mı takacak?

Her şeyi aynı anda, aynı kalitede yapamayacağız. O kadar vaktimiz, kaynağımız, enerjimiz yok. O nedenle bizim için dertlenen bu adamlara kulak vermeliyiz. Martin Fowler de bunlardan birisi.

Kodunuzdaki dış bağımlılıkları nasıl yöneteceğinizi mesele yapıp buna eğilen bir mühendis yöneticiniz var mı etrafınızda? Ya da “feature toggle” pattern'lerini çıkartıp önünüze döken. Ya da “business validation"ları nasıl derli toplu servisten döneceğinizi gösteren? Dünya mikroservis mikroservis diye ağlaşırken, konuyu cerrah titizliğiyle masaya yatıran ve deşen bir "mimar"ınız var mı? "Agile Architecture” diye olmayacak işleri “olur olur, bal gibi olur” diye anlatan bir adam?

Adamın derdi iyi yazılım, kendini test eden yazılım, her an üretime geçilebilecek yazılım, değişimlere hızlı adapte olacak yazılım… Ve tüm bunlarla değerli bir iş yaptığının bilincinde, onurlu, Dark Pattern'lere karşı duran başı dik bir yazılımcı.

Devrimci Duruş

Tarihsel notlara bakarsak, Martin'in genelde çalışma alanı olarak herkesin tabu kabul ettiği yerleri seçtiğini görüyoruz. Nerede “bu böyle olmalı, aksi mümkün değil” tarzında bir dogma dillendiriliyorsa, Martin hoca oraya kamp kurup analize başlıyor. Ve sonunda döve döve o işi tersine çeviriyor ve “bakın oldu” diyerek insanları kendi tezine çağırıyor.

Demin de bahsettik. Agile Architecture. Bir mimari kuracaksınız ama aynı zamanda “değişim"e karşı dirençli değil, dost olacak. Değişime bir mimarinin dost olması herhalde "kurumsal mimari” yaklaşımında uç nokta olsa gerek. Çünkü “mimari"ler kolay kolay değişmesin diye ortaya çıkıyor. Hatta mümkünse, değiştirilmesi teklif dâhi edilmesin. İşte Martin için güzel bir hedef. Değişebilen, esnek, çevik bir mimari. Alır mıydınız?

Ya da yazılım dağıtımı. Yazılım o kadar önemli bir şeydir ki ara sıra dağıtılmalı ve çalıştığı sürece dokunulmamalı. Çünkü çalışan yazılıma dokunulmaz. Oynayan çocuğa dokunulmaz. Bunlar örfümüzde var. İşte Martin'in hedefindesiniz. Adam size öyle bir yazılım kurgusu öneriyor ki tek butonla (push-button da diyorlar) üretime geçiyorsunuz. Her an bir başka sürüme geçebiliyorsunuz. Sürekli üretime geçebiliyorsunuz. Sürekli kod yazıp, sürekli geçiyorsunuz. Sürekli, sürekli. Kimse üretime geçmekten, kod yazmaktan, kodunu sınamaktan korkmuyor. Cengaver bir ekip, güçlü kod, sürekli ayakta bir üretim. Alır mıydınız?

Martin Fowler'a ya da onun kafasındaki çağımızın yazılım bilimcilerine tabularla gelin… onlar da o tabuları yok etsinler.

Biz yazılımcıyız hocam.
Devrimci olmalıyız.
Hoca Martin gibi devrimci olmalıyız. Linus Torvalds gibi huysuz, Kent Beckgibi matrak, John Skeet gibi meraklı, Robert C. Martin gibi geveze ve tabi kiDHH gibi artiz olmalıyız.

Cehaletin Maliyeti 27 Jan 2016 8:52 AM (9 years ago)

Kimin söylediği belli olmayan güzel bir söz var: eğitimin maliyetli olduğunu düşünüyorsanız bir de cehaletin maliyetini hesaplayın. Genelde patronunuzdan eğitim yatırımı istediğinizde işinize yarayacak bir bakış açısıdır bu.

Eğitimin işe mola vermek olarak görüldüğü, patronun da eğitim isteyene “işten kaçmak istiyor” diye baktığı ya da eğitim bütçesini harcamak için ilgili birimlerin insanları salak-saçma eğitimlere zorladığı bir iklimde, elbette “eğitim” net bir kavram olmaktan uzaklaşıyor.

Kendi sektörümüze gelelim.

Kaç tane yazılım firması, yazılımcısı için düzenli eğitim planlaması yapıyor? Kaç tanesi online eğitim platformlarına üye? Kaç tanesi Safari Booksonline’a üye? Kaç tanesinin posta kutusuna IEEE Software magazine ya da benzeri bir şey geliyor? Kaç tanesinde çalışanlar, uluslararası konferanslar için yüreklendiriliyor, destekleniyor? Kaç tanesinde yüksek mühendislik için destek var? Kaç tanesi referans kitaplardan oluşan bir kütüphane barındırıyor?

Yazılımcının sadece bir “kas gücü” olarak görüldüğü yerde, sanırım yukarıdaki mevzuları konuşmak, sadece acı bir gülümseme sebebi olur.

Bu mesleğin profesyonelleri olarak… bu gidişata engel olmalıyız. Yazılımcı, kas gücüyle ifade edilen, pazardan tartılarak alınan bir nesne değildir. Hem üzerinde çalıştığı sistemi geliştiren ve hem de kendini geliştiren, tekrara düştüğünde yok olan bir sanat ve fikir adamıdır(*). Sanat adamıdır. Çünkü ürettiği çözüm, onun yaratıcı yönünden etkiler de içerir. Fikir adamıdır. Çünkü çözümünü düşünerek geliştirir, değer katar.

Bir yazılımcının emeğini diğer yazılımcının emeğiyle mukayese edemezsiniz. Tıpkı bir sanat eserini diğeriyle mukayese edemediğiniz gibi.

Bu sanat ve fikir adamının en büyük sınavı, cehaletle gerçekleşir. Kendini tekrara düşen yazılımcı, okuldan mezun olduğu günkü muktesebatıyla duran yazılımcı ya da “yan gelip yatan” yazılımcı… mesleğinin temelini dinamitlemiş demektir. Bu elbette sadece yazılımcının kendisinden kaynaklanmaz. Endüstrinin yazılımcıya bakış açısı da sirkeyi bozar. Güçlü yazılımcı istemeyen, yazılımcıya güvenmeyen, kabiliyetlerini tırpanlamak ve gücü dağıtmak isteyen yönetim yaklaşımı da mesleğimizin güncel talihsizliklerindendir.

Mutsuz, eğitimsiz ve kudretsiz yazılımcılar ile elde edilecek sonuç, herhalde düşük kaliteli, bol “bug”lı ve neresinden tutsan elinde kalan yazılımlardan başka bir şey olmayacaktır. Yazılım dobradır. Yazılım, cehaletle ya da sefaletle yazıldığını bağıracak kadar şeffaftır. Siz yalan söyleyebilirsiniz ama ürettiğiniz yazılım dürüsttür.

Kötü yazılımın birinci sorumlusu, o organizasyonun birinci seviyede karar vericisidir. Çünkü cehaletin maliyetini hesap edememiştir.

(*) “Adam” ifadesini hem bayları hem de bayanları içerecek şekilde geniş kullanıyorum. Cinsiyetçi bir yaklaşım gütmediğimi okura bildirmek isterim.

Microsoft, Node.js’i de seviyor* 22 Jan 2016 11:58 AM (9 years ago)

Bir zamanlar bu sayfalarda, Google’ın Javascript motoru V8′den, onu ortaya çıkaran Danimarkalı dahiden (Lars Bak) bahsetmiştik. Ondan önce de Ryan Dahl’dan, Node.js’in reisinden bahsetmiştik. Node.js ile V8 bir elmanın iki yarısı gibi son iki yılımızı meşgul edip duruyor. Hızla büyüyen bir paket deposu, sürekli gelişen EcmaScript, geliştirici tarafı otomatizasyonu, sunucu tarafındaki Javascript heyecanı… Ve artık HTML üstüne yazılmış çapraz platform uygulamalarda da (Electron) popülerleşme.

Node.js, Microsoft’un da epey ilgisini çekiyor.

Çapraz platform kod editörü Visual Studio Code, Node.js - Electron üzerinde çalışıyor. Visual Studio’nun geleneksel tarafında bir süredir verilen NPM ve task runner desteğini saymıyoruz bile.

Yeni bir şey olarak ne oldu?

Microsoft, daha önceden açık koda çevirdiği kendi öz Javascript motoru Chakra’yı (ChakraCore) Node.js’e entegre etti ve Github’tan pull-request çekti.

4786 dosyada değişiklik yapıp, Node.js’i ChakraCore ile çalışır hâle getirmişler. V8 ya da Chakra seçenek hâline gelecek. Eğer Node.js’çiler kabul ederlerse, bu resmi bir Node.js runtime’ı olarak dağıtımlarda yerini alacak.

Microsoft’un planı ne olabilir?

Bir tahmine göre Microsoft, bu hareketle Node.js’i Windows’ta (Windows’un IoT dahil bütün sürümlerinde) uygulama koşabilecek bir platform hâline getirmeyi düşünüyor. Elbette ChakraCore, V8 ile performans yarışına, testlere girecektir. Her gün ringe çıkacaklardır. Lâkin bunun için bu kadar yatırıma değmez. Microsoft, kendi sahasında da alternatif ve cazip bir Node.js ortamı oluşturmak istediğinde, bu hareketler daha manalı oluyor.

TypeScript’le yazılmış, Node.js-ChakraCore runtime’ında çalışan minik, hızlı ve coşkulu IoT uygulamalarına hazır mıyız ey dünya?

İlave bilgi: https://blogs.windows.com/msedgedev/2016/01/19/nodejs-chakracore-mainline/

* Başlıkta, Satya’nın duyurduğu “Microsoft loves Linux” kampanyasına atıf vardır değerli okur.

Hepimiz JSON’ız; Hepimiz REST’iz 16 Jan 2016 7:15 AM (9 years ago)

Şimdilerde yiğit bir Anadolu kentinde yazılım üreten sevdiğimiz bir arkadaşımız, yazmayışımdan yakındı. Evet, dostum haklısın. Yeni bir iş deneyiminde burayı biraz ihmal ettim. Umarım bu karalamamızla yeni bir frekans ayarlaması yapmış olurum.

Evet, REST’ten bahsedeceğiz. Hepimizin ya içinde ya dışında olduğu çemberden.

REST: Representational state transfer.

Endüstride yaygın olarak REST’in JSON alıp veren Remote Procedure Invocation usulü servislere verilen takma ad olarak kullanıldığını görüyoruz. Bu da ciddi bir sorun doğuruyor. JSON verdim, REST’im demek, REST’in öğrenilmesinin, doğru anlaşılmasının ve yaygınlaşmasının önüne geçiyor. Yani siz REST’i, REST uyguladığını söyleyen ama aslında uygulamayan birinde görüp, “haaa REST bu muymuş, yarın basıyorum prod’a hafız” diyorsunuz ve önlenemeyen geometrik bir seviyeye gidiyorsunuz.

Biz de bir hata yapıp, toptan yargılamak istemiyoruz. Evet, JSON RPC modelinde servis yazmak ve buna REST demek tamamen REST’in dışında değil ama REST’in olgunluk modelinin en alt seviyesi, level-0.

[figürü Martin Bey’in makalesinden alıntıladık.]

Efendim bu olgunluk modeli de nereden çıktı?

Evet, tam 8 sene önce bir QCon seminerinde Leonard Richardson isimli 8 yıllık genç bir bilgisayar mühendisinin elinden çıkıyor bu olgunluk modeli. Adına da Richardson Maturity Model diyorlar ortamlarda. Modelin var olması, bizim için şundan dolayı önemli: bu işte daha ileriye gidiş var. RESTful olmanın koşulları var, âdâbı var.

Genelde SOA’daki olgunluk modeli gözümü korkutmuştur. Merak etmeyin bu SOA’nınki kadar organizasyonu mıncıklamaya varmıyor. Kendi sahasında işini bitiriyor.

Tabi ki tarzım değil, size burada bir belgeyi birebir çevirerek aktarmayacağım. Modeli hazmetmek sizin ödeviniz olsun. Ben birkaç hususu hatırlatayım.

Öncelikle REST’in başında olduğunuzu kabul etmelisiniz. Yani sıfırıncı seviyede. Bu seviye, HTTP’i sadece ve sadece bir aktarım yolu olarak gördüğünüz seviye. SOAP’ta ya da XML-RPC’de olanla aynı. Test yapın kendiniz: eğer aynı mesajları HTTP ile değil de daha genel bir TCP soket üzerinden de gönderebiliyorsanız, aslında REST’in bu aşamasındasınız demektir.

Tamam, HTTP’yi amaç değil araç yaptınız. Entegrasyonu kotardınız. REST’te artık bir sonraki aşamalara geçip, HTTP’yi amaç hâline getiriyorsunuz. Yolun sonuna geldiğinizde hatta meşhur bankacı ifadesiyle günün sonunda, HTTP eylemleriyle (GET, POST, PUT, DELETE) sıkı sıkıya bağlı, “resource”lar üzerinde dönen bir API ortaya çıkarmış oluyorsunuz. Kop desen kopamıyor HTTP’den.

Neden böyle? HTTP ile REST neden bu kadar bağlı?

REST’in ilham aldığı şey doğrudan HTTP ve Web. Şimdi klişe REST ibarelerini tekrarlamak istemiyorum ama bildiğiniz gibi REST bir standart ya da protokol değil “mimari tarz”. Bu size standart dayatan bir müessese olmadığını gösteriyor. Standartları ve protokolleri kullanıp, bir mimari şekil oluşturuyorsunuz. Ama ne kadar REST’e biat ettiğinizi bu ortaya birilerinin zorlamasıyla çıkan olgunluk modelleriyle ölçüyorsunuz.

Bir şeyi atladık. Web, ölçeklenebilir, dağıtık ve en önemlisi “stateless” (durumsuz) mimarisiyle REST’in ilham aldığı şey. O nedenle HTTP dışında çalışan bir REST bulamazsınız. Bulursanız da adı başka bir şeydir ve REST’in mimiğidir.

[REST’i, 2000′de bir Amerikan bilgisayar bilimcisi Roy Fielding, doktora tezinde icat ediyor. Adam HTTP’nin de (protokolün) yazarları arasında. Ve hatta Apache HTTP sunucusunun da. Daha n’apsın söyler misiniz?]

Bu bahsettiğim olgunluk serüveni, kritik ve kolay olmayan bir mesele. SOAP’tan level-0 olgunluğundaki REST’e geçmeye çok hızlı adapte oluyoruz. Çünkü paradigma değişimi “0”. Yıllarca Remote Procedure Call ile aşina olmaklıktan dolayı SOAP’tan JSON API modeline geçiş zahmetsiz oluyor. Ama iş üst basamaklara doğru çıkarken sofistike hâle geliyor. Paradigmayı da değiştirmeniz, API’ya bakış açınızı revize etmeniz gerekiyor.

Bunu işin üstadları şöyle misalliyor: Prosedürel programlamadan Nesne Yönelimli programlamaya geçmiştiniz ya. Hah, aynısı. Şimdi de prosedürel bir entegrasyon modelinden, Nesne Yönelimli bir entegrasyon modeline geçiyorsunuz.

Olgunluk modeliyle ilgili Martin Fowler’in de dahil olduğu (Roy Fielding’in şartına dayanan) bir tenkit var: Olgunluk modeli sorunlu. LEVEL-3 (hypermedia kontrolleri) olmadan, REST oldum diyemezsiniz. Yani bu modeli olmamışlıktan olmuşluğa geçiş modeli olarak görüyorlar. LEVEL-3′te anca REST olursunuz diyorlar. Hypermedia kontrollerini tasarlamaya baktığınızda, API’nizin artık HTTP ile cem olduğunu göreceksiniz. Kendi kendini tarif eden bir API’ye kavuşuyorsunuz.

Evet, REST 16 yıldır var. JSON’la ilişkisi yok, istediğiniz veri formatını alıp verebilirsiniz. İlk REST’çiler, XML kullanıyordu zaten. Ve tamamen bütün noktalarda REST ile entegrasyon yapmanın gereği / imkanı yok. SOAP ve benzeri model hep var olacak. Ama REST’in, buluta taşınan uygulamalarla yani herkesin eninde sonunda HTTP’de buluşacak olmasıyla pazar payının her gün katlanacağı kesin.

Bu nedenle şu olgunluk meselesini öğrenip REST’te kariyer yapmanın tam vakti.

SPOF.TAN 18 Oct 2015 12:42 PM (9 years ago)

Başlığı merak ediyorsunuzdur umarım. SPOF deyince hadi bir şeyler çağrışır. TAN deyince ise tepki yok. Açıklayayım efendim:

Single Point of Failure ve onun Türkçesi, Tek Arıza Noktası.

Her türlü sistemin bir kırılgan noktası vardır. Oraya hani “zayıf halka” derler. Güzel sözler de çıkmıştır konuyla ilgili: en zayıf halka kadar sağlamsındır.

Peki bizim işimiz yazılım. Biz nerede enseleriz bu tek arıza fetişini?

Öncelikle şöyle biraz eskilere gidelim. Bir uygulamanın tüm parçalarıyla sadece bir fiziksel bilgisayarda yaşadığı zamanlara. Herhangi bir bağımlılığı olmayan, sapa sağlam bir yazılım. En fazla diski patlayacak ya da çalınsa geri gelmeyecek bir bilgisayarda yaşıyor. Arıza yapabilmesi için yazılımcının “time bomb” koyması lazım. Her üç ayda “time bomb” kurbanlarına bakım yapıp, çeyiz parası biriktirmesi lazım.

Sonra bağlantılı dünyaya geçelim. Artık yazılımların bir yerinden başka bilgisayarlara, iş ortamı için düşünürsek, ana bilgisayara bağlandığı bir dünya. Merkezi bir sunucu var ki bu çokça veri kalıcılaştırmadan sorumlu veritabanı sunucusu. Etrafında da iş mantıklarını, modeli, her bir unsuru içeren terminaller. Tek arıza noktamız merkezi sunucu. Veritabanı durursa, hayat durur. O yüzden “High Availibility” uzmanlığı oluşur ve size roket yese durmayacak, davasından dönmeyecek bir sunucu çatarlar. İşletme için yatırım hedefi nettir. Veritabanını koru, gerisini salla. Çünkü herhangi bir terminalin, ironik bir şekilde “terminal” noktaya geçip uçması, sistemin umrunda olmaz. Sistem yüksek yüksek erişilebilirliğin keyfini çıkarmaktadır.

Ama bu sistem rüyası da artık mazide kaldı. 2015′te, bağlantılı yüzlerce sistemi konuşuyoruz. Hiçbir yazılım asla kendi başına bir iş yapmıyor. Servisler alıyor, servisler satıyor. Ve bu servisler, gitgide minikleşiyor.

Mikroservisler alıyoruz, mikroservisler satıyoruz.

Granülarite arttıkça, entegrasyon ilminin kıymeti artıyor. Tek Arıza Noktası kavramı, artık Arıza Noktaları gibi bir dramaya dönüşüyor. Sisteminizin ayakta kalması için kaç kişinin el vermesi gerektiğini deftere yazmanız gerekiyor.

Artık konuşmamız gereken, Tek Arıza Noktası’ndan kaçmak değil. Tek Arıza Nokta’larıyla yaşamaya çalışmak. Bunların kısa devrelerini kurmak. Yıkım olduğunda, yaralı da olsa yoluna kendi başına devam edebilecek bir sistem kurmak.

İşte bu işin mimarlarının devreye girdiği yer.

Konuya devam edeceğiz.

Yalanlarla dolu bir dünya 3 Sep 2015 10:28 AM (9 years ago)

Apple, iOS 6′daki saat uygulaması için önceki sürümlerden farklı bir saat simgesi kullanmıştı.

Saati gören İsviçreli tren adamları şaşkına dönmüş, ellerindeki özel tasarımlı kahve fincanlarını düşürmüşlerdi.

Çünkü “daha önce yaptık bunu biz” idi ve Apple aşırmıştı.

Vukuat, medyaya yansıdı. İsviçreli tren idaresi, kendisinde tescilli olan saat simgesi için “hak arama” davasına başladı.

Tartışma, 21 milyon dolarlık paranın tren idaresine Apple tarafından akıtılmasıyla son buldu. Böylece iOS 6 davadan yırttı. iOS 7′de ise daha farklı bir simge kullanıldı.

Evet, sanki her şey normal gibi. Ama burada anormal bir şey var, hiç düşündünüz mü?

Birincisi Apple bu saati İsviçre Tren İstasyonu’na ait olduğunu bilerek kullandı. Bu kısımdan emin değiliz ama tren idaresi de işin içinde olabilir. Saat kullanıldıktan sonra suni gündem oluşturuldu. Ve anlaşma yapıldı, paralar transfer edildi. Kampanya sona erdi.

Çok da kolay fark edileceği gibi bu bir medya kampanyası. Reklamlarla sağlanamayan tanıtımın, yalandan bir olay zinciriyle sağlanması.

Ve bu koca şirketlerin hepsi, koca bir yalancı.

Yalnız iktisadi hayatın vahşi aktörleri, ne acı ki, yalanı içselleştirmiş, pazarlamanın ve satışın enstrümanlarından biri hâline getirmiş durumda. Müşteriler bile kendilerine yalan söylenmesini arzu ediyor.

Sadece iktisadi hayat değil elbet bu yozlaşmanın adresi. Milletlerarası hukuk. Kıyıya vuran bir bebekle başlayan “ah, vah“ sızlanmaları.

İnsanlara söylüyorum. O bebekler 4 yıldır öyle veya başka türlü ölüyor. Her türlü vahşete kulağını tıkayan, her vahşeti bir şeyler uydurup haklı göstermeye çalışan bu insanlık… değersiz bir yok oluş yaşıyor.

Yalanların arasında Yunus gibi düz ve doğru kalanlar varsa… onlar biz olalım ey kaari.

Not: Nereden nereye bağlandı demeyin, kendi bağlandı.

Kızıl havalar 21 Jul 2015 10:59 AM (9 years ago)

Bugünlerde geçmişe dair izler gelip geçiyor gözümün önünden. Her alanda, her yerde, her şeyde.

Visual Studio 2015′in çıkışını haber aldık. Sonra yakınlarda Windows 10′un resmi çıkışını göreceğiz. Edge isimli yeni bir gezgini kullanacağız. O gezginde, evet dikkat, Silverlight olmayacak.

Ah, ah. Sonra bunu duyunca yine geçmişe gidiyorum.

2012 başlarında Microsoft’un Türkiye ofisinde verdiğimiz bir seminere transfer oluyorum. Başlık: Microsoft’un UI Vizyonu. O günlerde hiçbir Microsoft’çunun bilse bile dile getiremeyeceği radikal şeyler söylüyoruz. Bırakın Microsoft’çuluğu… MVP müessesesi için bile ağır geliyor bunlar. Şu an şu aşağıdaki resme bakıp, acı acı gülümsüyorum. Bilmiyorum, bana yapılan o anki seviyesiz tenkitlere mi üzülüyorum? Yoksa bu “MS ile internal bağı” olan adamların şu an bu konuşmanın fersahlarca uzaklara düşüşüne mi?

Halbuki anlamaya çalışabilirdik. Ortada bir yol haritası vardı. Herkesin çok açıkça dillendiremeyeceği, ancak analist gözüyle ortaya çıkabilecek ve kesinlikle MVP’lere ya da RD’lere o çok meşhur NDA’li toplantılarında bile ifşa edilmeyek bir yol haritası.

Biz buna uzgörü diyoruz. Uzgörü gibi uzgörü.

Şimdi elinize Windows 10′u bir geliştirici olarak aldığınızda, tekleştirilmiş bir SDK bulacaksınız. Bu aklın yoluydu.

Bakın “uzgörü” nasıl dökülüyor yine buradaki satırlardan:

(2011 Kasım)
Eğer Microsoft, Silverlight'ın ipini çekecekse, yine Silverlight runtime'ını kullanan Windows Phone 7 ne olacak? …
Windows 8'in uygulama alt yapısı (Metro UI) farklı bir SDK içeriyor. Windows Phone 7 ise ona benzer ama farklı bir SDK. Ancak iki SDK da benzer özellikler içermeye başlayacak. Örneğin WP7 için sensörlerle ilgili kütüphaneler sağlanmış durumda. Microsoft, bunların aynısını, tabletler için düşündüğü Windows 8 WinRT SDK'sına da koymak zorunda veya koyacak.
Yani tablet ve telefon gibi aslında ileride birbirinden çok da farkı kalmayacak, yetenekleri çok yakın iki cihaz için iki ayrı işletim sistemi ve iki ayrı SDK yazılımcıları bekliyor olacak. Siz ürettiğiniz bir yazılımı hem telefon ve hem de tablet için ayrı ayrı derleyip, ayrı ayrı sertifikasyona sokacaksınız.
Microsoft'un yazılımcılardan zılgıt yiyeceği ve kendisinin de operasyon yükünü artıran bir durumla karşı karşıya olduğumuzu görüyor musunuz?
Bu işten mutlaka bir çıkış yolu olmalı. Microsoft da muhtemelen buldu ve zamana yayarak, bu belâdan kurtulacak. Ben kendi tahminimi ya da temennimi ileteyim.
Windows Phone 7'nin tüm API'sini WinRT'ye taşısınlar. Yeni Windows Phone uygulamaları, WinRT API'si üzerine yine XAML/C#/C++ ile yazılsın. Mevcut uygulamalar çok basit bir şekilde XAML değişikliği olmadan, kod dosyalarında ufak modifikasyonla WinRT'ye taşınabilsin. XNA uygulamalarını da bir şekilde halletsinler, onu da ben düşünmeyeyim. Tüm bu geçiş sürecinden sonra elimizde tek bir SDK kalsın. O da WinRT. İstersek C++ ile Windws Phone uygulaması yazalım ve performansın dibine vuralım.
Silverlight'ın cansız bedeni yere serildiğinde, Windows Phone da Windows 8 ile birleşmiş, yek vücut olmuş olacak.
Daha önceki tavsiyemi ileteyim. Microsoft yolunda ekmek yiyorsanız, size en vefalı çıkacak teknoloji XAML'dır. XAML'a yatırdığınızı mutlaka geri alırsınız.
Cross-platform yakınlarının başı sağolsun.

Yek vücut. Windows 10. Silverlight yok.

Eğer çok bilmiş MS ile internal bağı olan gençler… dediklerimize kulak verseydiniz, şimdi EMEA bölgesinin en hızlı Windows 10 MVP’leri olurdunuz.

…

Efendim, kesinlikle narsist sancılar içerisinde değilim. Cahit Zarifoğlu’nun dediği gibi seçkin bir kimse de değilim. Sadece “educated guess” dediklerinden yapmışım. Bir uzgörü sergilemişim.

Ama statükocu ve sadece ticari / keyfi yönlendirmelerden devşirilen görüşlerle her alanda nasıl mücadeleler yaptığımızı görün istiyorum.

Kendime yeni bir dünya kuruyorum. O dünyada, yazılarımı okuyanlara, yani aziz kaarilerime daha yakın olacağım muhtemelen.

Işıkla.

Flaş ölür; halay kalır 15 Jul 2015 1:31 PM (9 years ago)

Jonathan Gay’dan, Flash’tan, Macromedia’dan, Adobe’dan ve HTML5′ten bahsedeceğiz. Çayınızı, kahvenizi alın.

FutureWave isimli küçük bir firma ve Jonathan Gay isimli yetenekli bir Amerikan. İlginç bir ürün geliştiriyor: FutureSplash. Tam da bir programcının verebileceği isim. Pazarlama fikri sıfır.

Jonathan, ürünü Macromedia’nın hantal Shockwave ürününe rakip olarak geliştiriyor. Tahmin edebileceğiniz gibi daha başarılı, daha kaliteli bir ürün. Bu ürün, yıllar sonra SilverLight diye kopyasını üretecek olan Microsoft’un da dikkatini çekiyor. Online TV yayını için kurduğu sitesinde kullanıyor.

Ya Adobe. Jonathan, Adobe’un kapısına bu ürünü satmak için gidiyor. Adobe yıllar sonra daha büyük paraya satın alacağı ve daha çok yıllar sonra da başına bela olacak ürünü, o gün almıyor.

1 Haziran 1997. Türkiye’nin 28 Şubat gerilimleri yaşadığı, Aczimendilerin, Fadime Şahin’lerin türediği, Sincanlıların asfaltta kortej yapan tankları izlediği zamanlar. Macromedia pes ediyor ve Jonathan’ın FutureSplash’ını satın alıyor. Programcının verdiği ismi de hafif kısaltıp, Flash’a çeviriyor. İşte efsane o zaman başlıyor: Macromedia Flash 1.0.

Web’den multimedya içeriği sunmanın “doğal” yollardan mümkün olmadığı bir çağdan bahsediyoruz. JavaScript programlamanın kayan yazı yapmaktan, mouse imlecinin peşine kuyruklu animasyonlar takmaktan ve sağ tuşa tıklayan küfür etmekten başka bir inovasyona yaramadığı zamanlar. Java’nın “applet” ile web üzerinde egemenlik kurduğu ve az çok kod bilen akademisyenlerin damla efektiyle cübbeli fotoğraflarını sergilediği zamanlar.

Flash, zengin grafik sunumu, ciddi optimizasyonlar, ses ve görsel efektler ve de animasyon imkanlarıyla webcilerin HTML’den, JS’den ve Java’dan kaçış limanı oldu bir anda.

Günler geçti. Flash olgunlaştı. Ve olgunlaşan her üründe karşımıza çıkan aşırı iştaha yenik düştü. Hem Macromedia ve hem de geliştiriciler, Flash’ı amacı dışında bir kullanıma sürüklediler. Flash’tan bir Java (veya .NET) yaratmaya çalıştılar. Flash’ı bir uygulama (bildiğin uygulama) geliştirme platformu olarak konumlandırmaya başladılar.

Büyük bir günah. Tarih, cezayı kesti.

Microsoft’un da SilverLight ile aynı hatayı hevesle tekrar etmesini şaşkınlıkla izlemişken, Flash uygulama platformuna evrilmesinin cezasını mobil darbeden dışlanarak yedi. Darbenin Sisi’si, çok da iyi tanıdığımız Steve Jobs’tan başkası değildi.

[Ara not: Microsoft’un SilverLight ile giriştiği maceranın belki mantıklı bir nedeni olabilir. Çünkü burada edindiği tecrübeyi Windows Phone 7 gibi ucube bir platforma taşıdı. Ardından da tümünde edindiği tecrübeyi Windows 10 gibi daha mantıklı bir noktaya getirdi. Belki çok bilinmez ama .NET’in Windows dışındaki bir işletim sistemine kısıtlı düzeyde ilk nakli de SilverLight ile gerçekleşti. Bu bağlamda SilverLight, Microsoft’un yaptığı AR&GE’leri perdelediği yemiydi diyebiliriz.]

2005′te Adobe, büyük gelecek gördüğü Flash’ı, bu sefer kendi arzusuyla aldı ve dev üretim platformuna entegre etti.

Artan web standartları duyarlılığı, JavaScript’in gelişimi ve ayrıca SEO endişeleri, Flash’ın site içeriğinde kullanımına darbe vursa da imdadına yeni bir pazar yetişti: streaming video. İnternet, Flash’ın zamanın ruhunu iyi yakalayan video sunum imkanlarına yenildi. Flash, bir dönem daha tek başına iktidar oldu. [Flash tabanlı oyunlar bu gerilimden daha az etkilendiler; belirtmeden geçemeyeceğiz.]

Apple’ın iPhone ile açtığı düzlükte artık Flash gibi “doğal” olmayan bir internet tarayıcısı eklentisine yer yoktu. Steve Jobs, ısrarla iPhone OS’tan VM’leri uzak tuttu. Java, Flash hepsi. Bunun götürüsü, iPhone’un ilk yıllarında sayfalarda açılmayan reklamlar (bu güzel bir şeydi aslında) ve oynatılamayan video’lar oldu. iPhone’a özel Apple’ca yazılmış Youtube uygulaması olmasa, iPhone’cular Safari üzerinden Youtube videosu izleyemezlerdi.

Adobe, haklı olduğunu düşünerek Apple’a ver yansın ediyordu. Kullanıcılar da bu etkisi büyük Flash noksanlığını dert ediyor ve Apple’ın başını ağrıtıyorlardı. Bir gün Steve Jobs, Flash’ı neden hiçbir zaman iPhone’a koymayacaklarını anlattığı mektup yayınladı. Birden çok açıdan Flash’a vurdu ve bizce de haklıydı.

Sonra ses kesildi. Tarihin doğal akışı başladı. Video siteleri HTML5 / H.264 streaming’e geçtiler. Reklamlarda Flash kullanımı neredeyse kalmadı.

Düşene bir de hacker’lar vurdu. Masa üstü tarayıcılarda hâlâ bir şekilde yer bulan Flash’ın güvenlik açıkları artık geçiştirilebilecek düzeyi aştı ve dünya barışının önünde İran’dan sonraki sorun hâline geldi.

Abartılı bir ifade değil bu. Zira, geçtiğimiz günlerde şahit olduğumuz “Hacking Team”in hack’lenmesi vakasında ilginç bir detay vardı. Hacking Team, Adobe Flash üzerinde kendi keşfettikleri ve kimseye demedikleri bir güvenlik açığını kullanarak hedef makinelere zararlı yazılım şırınga ediyordu. Buna ait dokümanlar sızdı.

Ne olduysa bu Temmuz ayında oldu. Flash artık Mozilla Firefox’un da yasaklılar listesinde.

Şimdi Flash’ın ölmesi için herkes sesini yükseltiyor.
İnsanlar güvenlik endişesinden yılmışlar.
Adobe, durgun, sessiz.
Halay her şeye rağmen devam ediyor.

İlave: Peki tüm bu kaos sırasında öykünün başını yazan Jonathan nerede diye düşündünüz mü? Kendisi her yazılımcının hayali olan çiftlik meselesine girmiş. Doğal besili sığır yetiştirip satıyor; sürdürülebilir tarımsal teknikler deniyormuş. Mükemmel kariyer.

Web’in İşlemciye Diyecekleri Var 18 Jun 2015 3:04 PM (9 years ago)

Scott Hanselman’ın meşhur sözü artık ata sözü kıvamına geldi: JavaScript, web’in assembly dilidir. Bunu doğrulayan da çok çaba oldu. Google “Native Client” diye bir işe girişti. Mozilla, asm.js’i yaptı, kullandı. Her biri, JavaScript’in her seferinde bir metin dosyasından okunup yorumlanan ikliminden makine koduna daha yakın, byte-code seviyesine derlenmiş hâlini hedefledi. Daha hızlı, daha güçlü ve daha doğal web işçiliği için.

Şimdi geldiğimiz yer ise webasm. Herkesin kendi kendine denediği ara JavaScript formuna artık büyük oyuncuların katkı sağladığı bağımsız bir ekip devam edecek. Bu adamların her birinin elinde internet gezgini var. Ve masada olmaları önemli.

Çıkan ürün, ümit edilir ki tüm gezginlerce desteklenecek ve web uygulamaları, daha bir doğal, daha bir semiz olarak mücadelesini sürdürecek.

Geliştiricinin hayatına etkisi ne olacak?

Script’ler gezgine okunabilir metin dosyaları olarak değil, byte-code’a derlenmiş assembly’ler olarak gelecek. Gezgin de üzerinde çalıştığı işlemci mimarisine göre daha az eforla makine koduna dönüşüm yapıp mantığı icra edecek. Geri sararsak, geliştiricinin de uygulamalarındaki script’leri artık bir derleyiciden geçirerek sunması demek bu. TypeScript ve CoffeeScript gibi JavaScript’e derleyen soyutlayıcılarla zaten bu deneyime alışkın olan web emekçileri, tahminimce bu noktada sıkıntı çekmez.

Gezgin tarafında da eğer webasm desteği yoksa, evrenselleşme yolunda giden asm.js’e düşerek durumu kurtarma planı varmış. Asm.js’in Chrome ve IE tarafında desteklenmesi an meselesi.

İlginç bir yoldan geçiyoruz. Web, doğuşundaki yoğun ve güçlü soyutlama ilkesini endüstrideki akıntılardan dolayı kaybediyor ve artık, neredeyse işlemciyle birebir yazışacak yakınlığa geliyor. İşlemcilerin mimarilerinin bu kadar çeşitlendiği ve web’in de bu kadar dallandığı budaklandığı karmaşada bu iki katmanın iletişiminin yükünü yine programcılar maharetli elleriyle üstleniyor ve başarıyor.

Not: Bu yazı Devnot’ta da eş zamanlı yayınlanmıştır.

Build 2015 Halk Günleri 30 Apr 2015 3:05 PM (9 years ago)

Eskiden elektronik ürünlerin tüketici fuarları ilgi görürdü. Geldiğimiz çağda ilgi odağı, yazılım endüstrisinin devlerine yönelmiş durumda. Microsoft tüm yazılım rotasını Build etkinliğinde şekillendirirken, Apple WWDC’yi ve Google da I/O’yu aynı amaçla kullanıyor. Bu etkinlikler, genel program olarak geliştiriciyi hedeflerken, açılış konuşmaları doğrudan tüketiciyi hedefliyor.

Yazılım, cihazların ahengiyle beraber dünyadaki dijital ve siber konforun itici gücü, lokomotifi olmaya devam ediyor. Ve biz buna çok seviniyoruz çocuklar!

Nihayet Microsoft’un ara ara yumurtladığı sürprizlerin sonuncularını duymak için beklediğimiz Build 2015 geldi çattı. İlk açılış konuşması, Satya Bey’in Hint aksanından kurtulmak için belirgin çaba sarf ettiği bölümle başladı. Aynı seansta Scottgu, Hanselman ve Mark Russinovich gibi rockstar’lar da yüzünü gösterdi ve şov tamamlandı.

Şimdi gelelim bu senenin müjdelerine.

Çevik Müjde

İlk olarak bir tespitle giriş yapmak istiyorum ey okuyucu. Apple’da da Microsoft’ta da görülen bir çevik müjde yaklaşımı var. Bu firmalar, yazılım ürünlerinin yeniliklerini anlatmak için senelik etkinlikler düzenlemelerine ve majör versiyonları senelik atmalarına rağmen aslında sene içerisinde de ciddi ilerlemeler kaydediyorlar.

Önceden senelik bir etkinlikte duyacağınız müjde sayısı daha fazla olurken, şimdi beklentiniz ve müjdeler daha az oluyor. Çünkü sene içine sprint’ler hâlinde dağılmış müjdeleri zaten tüketmiş oluyorsunuz.

Yine de illaki hiç duyulmamış ve iyi saklanmış bir şey bu etkinliklerde sizi bekliyor.

Bu seneki Microsoft duyurularının bir kısmı, sene içerisinde duyurulan şeylere güncelleme olarak geldi. O nedenle kalabalıktan her anonsta yoğun bir takdir alındığı söylenemez. Ha hiç mi takdir yoktu? Vardı.

Devam edelim.

Visual Studio Code = Kod Merkezli Hayata Doğru

Reddit’te “Cross Platform IDE” olarak haberleşse de aslında tam bir IDE değil. Editör ve ASP.NET 5 / node.js uygulamaları için de build/debug imkanları getiriyor.

Ama ilginç bir Microsoft ürünü bu. Hem bugüne kadar sır gibi saklanması itibariyle. Hem geliştirilirken kullanılan teknolojiler itibariyle. Hem de bu teknolojilerin doğal sonucu olarak “cross platform” olması dolayısıyla. İçinde Github’un Electron’u var. Node.js var. Typescipt var. Monaco var. Visual Studio’dan aşırılan Intellisense teknolojileri var. Evet, cidden sağlam bir zeminde yaşıyor bu ürün.

“Cross Platform“ ise doğru karar. Tıpkı Sublime Text gibi veya Brackets gibi. Ya da ortak noktaları olan Atom gibi. Ama bu adamlar Microsoft. İllaki diğerlerini bitirecek bir şeyler koyacak ki o da Visual Studio’dan gelen IDE-vâri özellikler olacak. Reddit’çiler “Resharper gelsin” diye ağlamaya başladılar bile.

Editörün ilgi görmesinde ürüne isim veren pazarlamacıların da büyük payı var. Adamlar “Visual Studio” ibaresini hiç alakası olmayan bir ürüne yerleştirerek, Visual Studio’nun sanki diğer platformlara taşındığı gibi sahte bir algıyı oluşturdular. Primi hak ettiler.

Visual Studio Code, güzel bir hareket oldu. Keşke açık kaynak olsa diye iç geçirdi herkes. Yakında o da olursa şaşırmayız.

Windows Store = BİM

Uygulama Marketi diye bir fikir yokken, geliştiricilere IDE’leri ite kaka satan platformcular, market çağında IDE’leri ve platformları bedava yapıp satışa ortak olma gider oldular. Kârlı ve ölçeklenebilen bir seçim.

Yalnız Microsoft’un bir sorunu var: marketi tutmuyor.

Windows’un 8 ile çıkan marketinin ilk günleri bana, yeni açılmış gıcır gıcır bir hipermarketi anımsatıyordu. Raflarda göstermelik ürünler var. Tüm elemanlar kibar ve gereğinden fazla sayıda bulunuyor.

Sonra market tutmuyor. Elemanların sayısı azalıyor. Raflarda kokuşmuş ürünler var. Tozlar var sağda solda. Adam dükkanda yeni şeyler deniyor. Döner tezgâhı açıyor. Soğuk sandeviç. Bardakta haşlanmış manyak bir mısır.

Windows’un uygulama marketi, böyle makus bir öyküyü yaşıyor. Çılgın atan cihazlar çıkmıyor. Cihazlar satmadığı için market büyümüyor. Market market olmadığı için cihaz satmıyor.

Microsoft bu döngüyü kırmak için iki ayrı hamle yapıyor. Satılabilecek bir cihaz üretmek için şu an kendi kendine çalışıyor. Bu sene göreceğiz bakalım Lumia’dan ne gibi bir uç cihaz çıkacak? Diğeri ise market tarafı.

Marketi BİM’e çeviriyor.

Win32 uygulamalarının markete konulabileceğini söylüyor. Burada App-V teknolojisi kullanılacakmış. Bu demek oluyor ki marketten inen Win32 uygulamaları, bilgisayarda sanal (ve izole, mücerret) bir dünyada yaşayacak. ARM işlemcili mobil cihazlarda tabiatıyla bu uygulamalar çalışmayacaktır sanırım.

Win32 girişi ile markette ciddi bir genişleme olabileceğini düşünüyorum. Zaten dünyada savruk ve yayılmış hâlde bulunan, göze bile çarpmayan Windows uygulamalarını, böylelikle daha temiz, virüssüz ve yerinden indirmiş oluruz. Ayrıca ücretlendirme de daha kolay olur. Yazılımcıların ağzına lokma girer.

BİM modelinin en acayip unsuru, hiçbir şey yapmadan çalışacak Android uygulamaları. Yani Microsoft, Android’in marketindeki uygulamaları doğrudan kendi platformunda çalıştırabiliyor artık. Eh. Büyük oranda beceriyor. Eğer Google’a özel API’ler kullanılmışsa Microsoft bunu sağlayamayacaktır.

Tam bir gerilla hareketi. Yine gerilla hareketiyle büyümüş Android’in milyonlarca uygulamasını kendi marketinde ağırlamak istiyor Microsoft. Tüm hepsi marketin büyümesi için. (Detay için bkz.)

Deneyimli kullanıcıların hemen aklına UX, kullanıcı deneyimi geliyor. Ne olacak UX sayın MS? Microsoft bu konudaki sorulara kapalı. Oyunlarda UX çok değişmeyecek ama fonksiyonel uygulamalardaki Android UX’i Microsoft’un tabu gibi koyduğu market kurallarını darmadağın edecek.

Aman abi kim takar UX’i, market disiplinini. Önemli olan büyümek. Koy döneri ön tarafa.

[Android’de çalışan uygulamanın Windows marketindeki izdüşümünün aynı perfomansta çalışacağını ummayınız. Emulasyon imtihanı. Döner sırttan değil, kıymadan.]

Ve bitti mi? iOS da giriyor tezgâha. Bunun işi biraz daha güç. Kodu bir kez daha derlemeniz gerekiyor. Microsoft’un arkada Apple’ın açık kodlu, kamuya mâl olmuş “cross platform” Objective-C derleyicisi Clang’ı kullandığı söyleniyor. Microsoft bu nadide iOS uygulamalarının çalışması için Windows içinde bir katman da geliştiriyor. iOS’un SDK’sındaki her API’yi kendi yetenekleriyle karşılıyor.

Bardakta mısır.

Marketimiz artık daha fazla uygulama içerecek. Android’den getirdiniz olmadı. iOS’tan alıp derlediniz olmadı. E o zaman Universal App. Marketin yerlisi, en son seçenek.

Marketi agresif bir şekilde büyütmek için atılmış bu adımı biraz endişeyle karşılıyorum. Çünkü market çok safken oluşan uygulama kalitesizliği, şimdi “üvey” uygulamalarla daha da belirsiz bir eksene kayacak. Android’in ilk safhalarda uyguladığı sert yayılma politikasının acısını kullanıcılar güvenilmez bir markete sahip olarak ödedi. Mesela benim hâlâ elim varmıyor bir Android cihaza.

Bence marketin nicelikten daha çok niteliğe ihtiyacı var. Bugün Windows’un marketine büyük servis sağlayacılardan doğru dürüst bir uygulama yazan yok. Google bu platforma herhangi bir uygulama geliştirmeyeceğini duyurmuştu. Twitter ve Facebook gibi adamların uygulamaları da kerhen çalışıyor. Apple zaten zorda kalmadıkça başka platforma girmez. Sonunda markette yemek tarifi ve padişah uygulamalarından oluşan içler acısı bir çeşitlilik kaldı.

Nitelik gerekiyor. Bunun da gerçekten iyi geliştiricilerin bu platforma gelmesiyle olacağını tahmin ediyoruz. Eğer Windows 10 platformu ve ona eşlik eden cihazlar tüketicide bir kıpırtı oluşturursa… marketteki padişahlar kımıldamaya başlayacaktır.

Sonuç: BİM modeline kısmen olmuş diyoruz. Üvey uygulamalara şerh koyuyoruz.

Docker = Koyuyorsun Çalışıyor

Her dönem aynı yaşta kalabilmeyi başaran Mark Russinovich, açılış için fazla sert gelen bir demo yaptı.

Adam Windows üzerinde Docker motorunu çalıştırdı. Üzerine uygulama koydu, çalıştırdı. Sonrasında aynısını Ubuntu’daki Docker’a attı. Onu da Visual Studio’dan debug etti. Bu hepsini 10 dakika içinde gösterdi ve klasik sunum esnası çuvallamaları da olmadı.

Sanal makinelere karşı daha cılız konteynerları sunan Docker, Microsoft’un yakın ilgisiyle sıcak ilerliyor. Ancak ben her an Microsoft’tan Docker’a dünyayı en azından Azure için dar edecek bir ürün bekliyorum. Windows Nano’nun çiçeği burnunda. Docker’dan know-how çekmeye devam ediyorlar.

Azure’da Rövaşata

Azure uygulama servislerini daha düzenli hâle getirmiş. “App Service” başlığı altında Web’i, API’yi ve Mobile özel hizmetleri konumlandırırken Logic Apps diye bir yeni hizmet sunmaya başlıyor. [Aslında bu haber yeni değil. Hanselman tekrarlayıp gösterisini yaptı.]

Logic Apps, bulut üzerinden entegrasyon süreci çalıştırmanızı sağlıyor. Servisten servise şahin uçurmak olarak tabir ettiğimiz entegrasyonun zor taraflarını güzel bir arayüzle kolaylaştırmış:

Tüketiciler böyle şeyleri zamanında Yahoo Pipes ile ya da IFTTTile yapar olmuştu ama kurumsal abilerimize web’den modern entegrasyon süreçleri çizme imkanı 2015′te ancak geldi. Buna şükür. Kolay kolay Biztalk’ı yedirmeyecek Microsoft.

Yeter..

Daha irili ufaklı bir sürü şeyden bahsedildi ama benim açımdan kayda değer kısımlar bunlardı. .NET’in “Core CLR” varyasyonunun Linux ve OS X’te “preview” etiketiyle salınması da ilk söylendiğindeki müjde havasını kaybetmiş gibiydi.

Sonuçta alıştık. Microsoft geliştiriciyle ilişkisini tekrar ısıtmak, hareketlendirmek ve güçlendirmek istiyor. Hepimizi markette görmek istiyor gençler. Bu yönde atacağı adımlar da bitmemiştir, devamı gelecektir.

Bizden bu kadar. Build 2015 ve 1 Mayıs 2015, tüm .NET emekçilerine hayırlara vesile olur umarım.

kola fanta ayran ne verelim?

Atölyeye Davet 28 Apr 2015 10:07 PM (9 years ago)

Seminerlerde duyurusu yapıldı ve sosyal mecralardan da bilgisi geçildi. Nur topu gibi bir medyamız var artık: devnot.com. Bu sitenin ileride InfoQ gibi küresel etkinliklerin öncüsü olabileceğine inanıyorum ve bu yöndeki her türlü çabayı gönüllü olarak destekliyorum.

Henüz Devnot çatısı altında bir seminer etkinliği düzenlenmemiş olsa bile, eminim tarih yakındır. Devnot ismini ilk olarak kullanmak bir seminere değil ama bir atölye çalışmasına kısmet oluyor.

Evet, atölye saatimiz 10 Mayıs 2015 Pazar 11:00. Yer Şehir Üniversitesi.

Atölyede fakir, .NET’in asenkron programlama ile ilgili yatırımlarını anlatacak. Tabi Multi-threading, Locking, Immutability gibi çetrefilli başlıklara da girilecek. Multi-core programlama, paralel programlama ve C#’ın asenkron eklentileri yine değineceğimiz konular arasında.

Salt bir konu anlatımı olmayacak elbette. Bu kavramların, yaklaşımların endüstride nasıl karşılık bulduğu ve bunlardan “en iyi” nasıl istifade edileceği üzerinde durulacak. Atölyede herkesin elinin hamura girmesi lazım diyerek bazı örneklemelerle de tatbikat yapacağız.

Kayıt ve gerekli bilgiler için aşağıdaki adresleri ziyaret ediniz efendim:

- http://devnot.com/2015/devnot-atolye-basliyor-net-ile-asenkron-programlama/

- http://www.eventbrite.com/e/devnot-atolye-net-ile-asenkron-programlama-atolyesi-tickets-16666298347

(Hatırlatma: Katılım 25 kişiyle sınırlı tutulacak.)

Github’a Biat 15 Mar 2015 1:14 PM (10 years ago)

Linus’un Git’i mucizevi bir kaynak kod kontrol platformu değil. Ama Git’e adanarak kurulmuş Github, yazılımcıların başına gelmiş en sosyal şey. Tom Preston-Werner’in fantastik öyküsünü duymuşsunuzdur; ben de yazmıştım. Microsoft’un iş teklifini reddedip kuruyor bu Github imparatorluğunu.

Tekrar Github konusuna nereden mi geldik? Google Code’dan. Çünkü servisleri ağlata ağlata kapatmasıyla meşhur Google, Google Code adlı emektar servisini bu sene bir takvim içerisinde kapatacağını duyurdu. Microsoft’un CodePlex’inin bile dayandığı bu Github-egemen şartlarda Google Code kolayca havlu attı.

Geriye ihtiyarlardan Source Forge kalıyor sanki. Bitbucket’i hangi kategoriye sokarız bilemiyorum.

Github, programcıların hayatında çok şeyi değiştirdi. Sosyal ve demokratik bir ortamda kodunuzu açtığınız her şey yürüyor. Twitter’dan nasıl en absürt mesajlar bile yürüyor; Github da en antin kuntin kodları yürütebiliyor. (Yazar burada yürümeyi, rağbet görmek, tutulmak anlamında kullanıyor)

Neticede, linklediğim yazarın dediği gibi… Github, kendini ifade edemeyen Asperger’li kodcuların, sosyalleştiği ve kendini kodla ifade edebildiği terapi merkezi oldu. Normal insanlar da çok keyif alıyor. Çünkü kod evrensel.

Çünkü kod kimseyi yargılamıyor.

Elveda Google Code.

Not: Github’ta hanım personele taciz iddiaları vardı yakın dönemde. Onu da yakın zamanda işleyeceğiz.

muhammed c. tahiroğlu View RSS