Python Seferberliği
Python, dinamik dillerin itibarının tekrar yükselmesiyle gündemin baş sıralarında. Dinamik programcılar, şimdi dillerinden bu esnek dilleri düşürmüyorlar. Akademik camianın heyecanı zaten hep bu kanalda devam ediyor. Herkes bir şekilde bu dillerden öğrenmeye çalışırken Türkiye’deki uzmanlarımız da boş durmamışlar, kaleme sarılmışlar. Size iki ayrı Türkçe başvuru kaynağını haber vereceğiz.
İlki internetten görülebilir: Bilgisayar Bilimcisi Gibi Düşünmek. İngilizce bir metinden çeviri yapılmış güzel bir çalışma. Biraz sözdizim referansı tadında.
İkincisi ise www.istihza.com adresinde ikamet eden PDF belgeler ve şimdilerde yeni çıkan bir kitap: Herkes İçin Python.
Fırat Özgül‘ün site ismi “istihza” olsa da yaptığı işte herhangi bir müstehzilik görmek mümkün değil ve aksine çok ciddi çalışmış. Python öğrenmek isteyenler için güzel bir kaynak olur, umarız. (Tenkit: “yılan” istiaresi figür ile de yapılabilirdi. Ürkünç bir vesika olmuş kapaktaki.)
Dinamik diller, dördüncü .NET’in de olaya müdahil olmak istemesiyle (DLR, IronRuby, IronPython) bu yıllarda daha da çok konuşulacak gibi gözüküyor. Konuşmanın ötesinde, bu diller üzerine yazılan framework‘ler artıyor, ham olanlar olgunlaşıyor meyve veriyor. Programcının birçok platformda birden hareket alanının genişlemesi, pek sevindirici!
Bir Programcıya “Loose Coupling” Anlatmak
Ocak 9, 2010 by mucit · Yorum bırakın
Adamın biri dert yanıyor, programcıma “loose coupling” ve “infromation hiding” gibi meselelerin ehemmiyetini nasıl anlatırım diye. Gelen cevaplar, gerçekten iç açıcı. Örneğin “hayatın içinden” bir resme bakın:
Eğer “gevşek bağlılık” prensibi olmasaydı, fişler, prizler de olmazdı. Tüm bağlantıları elimizle, lehimimizle kendimiz yapardık.
İşte programları kodlarken de bu tarz prensipleri titizlikle uygulamak gerek. Lehim yapmamak, elektriğe karşı yiğitlenmemek gerek.
Ya “bilgi saklama”? Ya yazdığınız nesneler, transparan sahne kıyafetiyle ortamlarda salınıyor ise… Ne kadar ciddi bir problem değil mi? Ciddiyetini anlamayan adama anlatmak için bomba misâl, Boris Pavlović’ten geliyor:
“Senden, cüzdanını isteyip kendi kendime içinden 10 lirayı borç almam hoş olur muydu?”
Ve buradaki “ben”i, “herhangi biri” olarak değiştirin. Cüzdanını veriyorsunuz, herkes kendisi alıyor istediğini. “Information hiding”i böyle anlatırsın demişler.
Yine de hiçbir programcıya bu kavramları, bu prensipleri damdan düşer gibi öğretemeyeceğiniz, kafasına çakamayacağınız kesin. İşin anahtarı dinamik “tecrübe”. Karpuz gibi yatan tecrübenin elbette, bir hocamızın dediği gibi, geminin arka tarafını aydınlatmaktan başka yapacağı yok.
Fiziksel tecrübe, soyut tecrübelerle kıyaslanamayacak kadar değerli. Bu tecrübe de ancak öğrendiğini tatbik ederek kazanılır. (*)
Pattern İdeolojisi
“Pattern“ler birçok iş sahasında karşımıza çıkıyor. İş değişiyor, insanlar değişiyor ama pattern’ler sabit kalıyor.
Mesele de bu zaten: pattern’ler sabit kalan şeyler demek.
Yazılım geliştirme literatürü de birçok pattern’in buluştuğu, kaynaştığı ve dev voltran‘ları vücuda getirmek için el ele verdiği bir meydan. Kod yazıyorsanız, bir pattern duvarına çarpmamanız ya da bir pattern polisinin sizi kovalamaması işten değil.
Bu yazımız, size Bulutlararası penceresinden sunacağımız “pattern” serimizin başlangıcını oluşturuyor ve birkaç genel bilgiyi sunmayı amaçlıyor. Önce isterseniz kitaplığa bakalım.
Yazılım tasarlarken ve tasarlanan yazılımı kodlarken bin türlü “yoğurt yeme şekli” ortaya çıkar. Bu binlerce şekilden bazıları kendine bir ad ve kitaplarda yer bulur. İşte bu müstesna yoğurt yeme şekillerini görmek, öğrenmek için de bilginin evrensel taşıyıcısı, aziz kitaplara başvururuz.
Birinci kitap, hakikaten birinci kitap: “Design Patterns: Elements of Reusable Object-Oriented Software“. Kitaplığın olmazsa olmazlarından.
Ama yeterli değil. Bu kitapla beraber tüketilen başka bir şey daha var: “Pattern Hatching: Design Patterns Applied“.
Elbette, pattern kelimesine sponsor olmuş bir adamın, Martin Fowler‘in kitabı var sırada: “Patterns of Enterprise Application Architecture“.
Düz yazı mide bulantısı yaptığı taktirde size hiyeroglif önerimiz var, hazırda bekleyen: “Head First: Design Patterns“. Pattern ideolojisine kafa göz dalmanız için, O’Reilly’den.
Son olarak MS kulvarındaki programcılara daha çok hitap eden bir eser rafta duruyor: “Code Complete“.
Hepsi yazılım geliştiricinin kitaplığını ağırlaştıran ve anlamlılaştıran eserler. Eğer tasarım ve kodun bilfiil içindeyseniz, bu kitaplar da içinizde olmalı. Dünyadaki en güzel yoğurdu siz yiyebilirsiniz ama en güzel “yoğurt yeme şeklini” bil(e)miyor olabilirsiniz.
Pattern’ler dar vakitlerde geniş çözümler sunan, hayat kurtarıcı, zaman kazandırıcı, el yapımı mucizelerdir. Bu mucizelere ne kadar yakın olursak, onlardan o kadar fazla istifade ederiz.
Kitaplıktaki raflar doladursun, Bulutlararası yazıları da hazırlanacak. Fanatiği ve gönüllüsü olduğunuz bir pattern ve onu anlatacak mecaliniz var ise, müracata gelin, konuşalım.
Programcı Özdeyişleri
Aralık 26, 2009 by mucit · Yorum bırakın
Biliyorum, özdeyiş kelimesini en son ilkokulda duydunuz. Dilerseniz aforizma olsun. Birkaç taneyi topladık burada.
“JavaScript, The Good Parts” kitabının yazarı Douglas Crockford:
Bir şeyin standart olması, onu her uygulamada kullanacaksınız anlamına gelmiyor. (XML gibi.)
Ruby geliştiricisi Yukihiro Matsumoto:
Açık kodlu proje, köpek balığına benzer. Hareket etmelidir, yoksa ölür!
ObjectWatch yöneticisi Roger Sessions:
İyi bir BT mimarisi çoğunlukla anlaşmazlıkların anlaşmasıdır. İyisi ve kötüsü de anlaşmazlık içerir fakat kötü mimariler, nasıl olacağına dair anlaşmadan mahrumdur.
Büyük adam, Donal Knuth:
Her şeyi optimize ederseniz, hep mutsuz olacaksınız.
Phil Karlton:
Bilgisayar biliminde sadece iki zor şey var: ön belleği geçersiz hâle getirmek (cache invalidation) ve bir şeylere isim vermek.
Deli İcadı Sanal Makinalar
Eylül 24, 2009 by mrok · Yorum bırakın
Başlıkta her ne kadar “makinalar” desem de, aslında bahsedeceğim iki adet sanal makina var: JVM (Java Virtual Machine) ve CLR (Common Language Runtime). Bu iki ortamdan en az birisi için kod yazmış olduğunuzu tahmin ediyorum. (Öyle değilseniz ve sanal makinalar hakkında bir fikriniz yoksa endişelenmeye başlasanız iyi olur 
) Java programlama dili JVM için, C# ise CLR için ipi göğüsleyen diller gördüğüm kadarıyla. Fakat sanal makinalar için bildiğiniz gibi yüksek seviyeli dillerin hiçbir önemi yok, çünkü yazılan her kod parçası CLR için IL’e (Intermediate Language), JVM için Java bytecode’a dönüştürülüyor ve sonrasında JVM ve CLR bu ara dilleri bulundukları işletim sistemi için çalıştırıyorlar.
Aramızda Java veya C# dilini kullanmak istemeyen ama bu iki sanal makinanın bize sunduğu bir çok nimetten (hafıza yönetimi vb.) faydalanmak isteyen bünyeler olabilir. İşte onlar için bu ortamları hedef alan birçok dil kullanılmayı beklemektedir. Aşağıda bu ortamları hedef alan örnek birkaç dili görebiliriz:
Programlama Dillerini Anlamak
Yıllarca forumlarda, usenet ve bilimum mecralarda programlama dillerinin, geliştirme ortamlarının fanatikliğini yapıp, tartışıp durduk. Ruby ve Python taraftarları, C# ve Java müdavimleri ve diğer dil sevdalıları birbirlerini yediler, yüzlerce blog yazıları yazıldı. Bir zaman böyle geçti gitti. Daha sonra sahneye Ruby on Rails açık kaynak web geliştirme framework’u çıkıverdi birden, Martin Fowler dayının “P of EAA“ kitabında bahsettiği pattern’ler bu framework ile birlikte ağızdan ağıza dolaşmaya başladı. İnsanlar 1995 yılından beri sahnede olan Ruby‘nin adını ilk defa duydular. Daha önce tartışmalarda hiç denk gelmemişlerdi halbuki. Rails ile birlikte Java dünyasını kasıp kavuran Struts, Spring gibi framework’ler eleştirilmeye başlandı, “Convention over configuration“ kavramı insanların gönlünü fethetti. Rails’in farklı platformları hedef alan benzerleri çıktı. Güneş batıdan doğmuşdu bu defa, insanlar yepyeni bir akım ile karşı karşıyaydılar.
Bu yeni akım programlama dillerinin bir amaç olmadığını, sadece bir araç olduğunu ifade ediyordu. Nitekim Rails ile, Ruby gibi bir dilin web uygulamaları geliştirilmesine nasıl da yatkın olduğunu ve Ruby ile hızlı bir şekilde nasıl prototip geliştirilebileceğini gördük. C# ve Java kıskacından biraz olsun kurtulduk bu yeni akımla. Sonra blog sayfalarını Google’ın Python kullandığına ilişkin haberler doldurmaya başladı. Evet dünyada arama motoru pazarı birincisi, insanların günlük hayatının vazgeçilmez bir parçası olan Google’dı bu. Nasıl olur da Google Python gibi bir dili kullanabilirdi? Halbuki Python sade ve basit bir dildi, içerisinde öyle kocaman özellikler barındırmıyordu. Yeni yetme programcıların kafası karışmıştı. Fakat sonra anladık ki Python kullanmasını bildiğinde çok kullanışlı, okunabilirliği yüksek ve hızlı öğrenme eğrisine sahip esnek bir dildi. Google, testlerini, test harness’ını yazmak ve sistemsel görevleri yönetmek için bol bol Python kullanıyordu. Aslında eski toprak system administrator arkadaşlar için Python veya Perl çok yabancı diller değildi. Fakat yeni nesil, Python dilini hafızasına kazımış oldu böylece. Django, Pylons ve TurboGears ile Python daha çok pekişti kafalarımızda. Bu gelişmelerle insanlar farklı amaçlar için farklı araçların olduğunu ve uzun zamandır da kullanıldığını net bir şekilde görmüş oldular.
Web servislerinin günlük hayatımıza girmesiyle beraber Flickr, Wikipedia veya Facebook gibi sitelerle tanıştık. Flickr gibi muhteşem bir servisin PHP ile kodlandığını biliyor muydunuz? veya Wikipedia’nın? Evet ikinci sınıf bir dil gibi görülen PHP (şahsen öyle olmadığını düşünüyorum) böyle muhteşem servislerin kodlanmasında kullanıldı ve kullanılmaya devam ediyor. At binenin kılıç kuşananındır prensibiyle asıl dilden daha çok, bu servisleri yazan sağlam geliştiricilere bakmak gerekiyor. Biliyoruz ki bu servislerin arkasında muazzam framework’ler var, bu framework’lerin belirli yerlerinde belirli diller kullanılıyor. Örnek vermek gerekirse Facebook, PHP dilini arayüz kodlamada kullanırken, Erlang‘ı chat altyapısında kullanıyor, Twitter arayüz geliştirmede Ruby (Rails) kullanırken, servis tarafında Scala kullanıyor. Farklı amaçlar için farklı araçlar kullanılıyor yani. Çünkü tek bir dil, framework veya teknoloji her hedefe uymayabiliyor.
Tek bir teknoloji bilmek ve onu iyi bir şekilde kullanmak elbette çok güzel bir meziyet fakat gerçekçi olmak gerekirse tek bir teknoloji, dil veya framework içerisinde sıkışıp kalmak, bize yeterli ufku ne yazık ki sağlayamaz. Hiç görmediğimiz farklı güzellikler bir yerlerde keşfetmemiz için bizi bekliyor olabilir. Bu yüzden sadece önümüze bakmak yerine arada bir etrafımıza bakıp yeni diller yeni ortamlar tanımalıyız. Farklı problemlerle karşılaştığımızda, İsviçre çakısında olduğu gibi uygun aracı (dil, framework vb.) bulup, o problemin çözümünde kullanmalıyız. Böylece hayat bizim için daha kolay olacaktır.
* Sevgili mucit’in yazmış olduğu “Web Programlamanın Şaşkın Paradigmaları” yazısı nedense bende böyle bir yazı yazma isteği uyandırdı Hem tarihin tozlu sayfalarını karıştırmış olmak hem de programlama dilleri üzerine bu seriyi devam ettirmeyi istedim.
YAGNI Prensibinin Püf Noktaları
Ağustos 27, 2009 by mrok · Yorum bırakın
Kullanmasını bildiğinizde hayat kurtaran YAGNI (You Ain’t Gonna Need It) prensibi, kullanmasını bilmediğinizde başınıza büyük problemler açabilir. Gereğinden fazlasını yapmama prensibine dayanan YAGNI, bir anlamda günü kurtarma gibi düşünülebilir. Ancak bu prensibi kendinize hedef edinirseniz, günü kurtarayım derken yarını berbat edebilirsiniz. Alan Skorkin tarafından yazılan “Does YAGNI Mean You Ignore The Obvious” makalesi, işte tam bu noktada güzel tavsiyelerde bulunuyor. Detaylı bilgi isteyenlere duyurulur.
Okunası 11 Kitap
Ağustos 25, 2009 by mrok · Yorum bırakın
Geçen hafta şirketimize sipariş edilen kitapların gelmesiyle beraber, tekrar kitap okuma furyasına dalmış oldum. Bugün, gelen kitapların yorumlarını incelerken bir arkadaşın yayınlamış olduğu kitap listesi gözüme çarptı. Kitaplar farklı konularda ama genel bilgi sahibi olmak açısından okumakta büyük fayda gördüğüm kitaplar. Özellikle “Secret of the JavaScript Ninja” henüz tam olarak yayınlanmamış olsa da şimdiden favorilerim arasında diyebilirim. Bu kitap JQuery‘nin geliştiricisi olan John Resig tarafından yazılıyor olup, kasım 2009 gibi piyasaya çıkması planlanıyor. JavaScript konusunda kendini geliştirmek isteyen profesyoneller için biçilmiş kaftan diyebiliriz. Umarım liste sizler için faydalı olur.
Scheme Aşkına
Ağustos 21, 2009 by mrok · Yorum bırakın
Bugün bir konuyu ararken Don Box‘ın bir makalesine denk geldim. Makale başlığı “Scheme Is Love” olunca dikkatimi çekti. Scheme üniversite yıllarımda oldum olası kullanmak istediğim fakat bir türlü ilgilenme fırsatı bulamadığım bir dildi. Bilgisayar mühendisliğinde özellikle eğitim amaçlı kullanımı çok yaygın bir dil olan scheme, yeni başlayanlar için de güzel bir alternatif. Konumuza geri dönersek, Don Box 2005 yılında yazdığı makalesinde scheme’in “Simple But Powerful” konseptine tam anlamıyla uyduğundan, scheme’in basit ama güçlü yapısından bahsediyor. Gerçek aşkı scheme ile bulduğunu söylüyor. Ufkunu genişletmek isteyenler için bu kısa makaleyi okumanızı tavsiye ederim.
Hata Yakalama ve Iskalama Kültürü
Mike Hodlow‘un başlığını Fight Club’tan esinlendiği “Hata Yakalamanın İlk Kuralı: Hatayı Yakalama!” yazısı, programlamada bir “exception handling” yani Türkçesiyle “hata yakalama” kültürünün olduğunu ve programcı / yazılımcı etiketindeki kimselerin de bu kültüre mutlaka aşina olması gerektiğini bana tekrar hatırlattı.
Yıllar evvel bir programlama aracı anlatan kitapta hatalardan “istisna” olarak bahsedildiğini görmüş ve oldum olası bu kavramdan uzak durmuştum. İstisnalar hem kaideyi bozar hem keyfi kaçırırdı.
Ancak zaman içinde anladık ki bir programcının bilmesi gereken şey aslında her insanın bilmesi gereken şey. Hayatta hata yapmak, yapmamak kadar doğaldır. Bir programın akışında hatalar oluşması da oluşmaması kadar olağan. Ve bu hatalar, yani arızî durumlar her seferinde farklı sebeblerden ortaya çıkabilir. Bir hata, başka hatalardan silsile yoluyla gelmiş olabilir (“Bir exception var exception’dan içerü” prensibi).
Evet, hatalar ne kadar normal dediysek yazıyı bu şekilde bitirip gideceğimizi sanmayınız. Anormal olanı demeden gitmeyiz.
Anormal olan şey, hatayı hesaba katmamaktır veya hataya karşı lakayıt kalmaktır. Bir program kodu oluşabilecek arızî durumlar akılda tutularak yazılmalıdır. Yazılmamışsa bile geri dönüp refactor (adam) edilmelidir. Akılda tutulmuşsa bile formaliteden değil yerinde müdaheleler yapılmalıdır.
Hata yakalama ile ilgili şu altın prensipler, umarım programcı arkadaşlarımız için faydalı olacaktır.
- Programda üç tip arıza oluşur: 1- Programlamadan (sizden!) doğan arıza, 2- İstemciden doğan arıza, 3- Kaynaklardan doğan arıza. Hangi tür olursa olsun, hepsinde program hataya karşı hazır olmalıdır.
- Programlama hataları ölümcül hatalardır. Programınız çakılır, devam edemez. Bir bug‘ınız vardır; siz çözene kadar öyle duracaktır.
- İstemciden doğan arızalar daha çok doğrulama şeklinde yorumlanır. Örneğin kullanıcının size girdiği sayı, alfanumerik karakterler içeriyorsa bir ihlal vardır. Veya gönderdiği bir XML dosyası elinizdeki şemaya göre valid değildir. Bu tip hataları hiçbir şekilde ıskalamamanız ve yakalamanız gerekir.
- Kaynaklar, kullanıcı ile aranıza giren üçüncü şahıslardır. Örneğin bellek dolmuştur. Ya da diskte yer bitmiştir. Bu tür durumları da titizlikle yakalayıp, ayırd edip mantıklı mesajlarla (vmware’yi kapat, biraz divx sil gibi…) kullanıcıyı yönlendirmek lazımdır.
- Genel Exception sınıfları yerine özelleşmiş Exception‘lar yakalanmalıdır. .NET için konuşursak, System.Exception denen hataların babası, sadece tek bir noktada ve global olarak yakalanmalıdır. Bu tek bir nokta, genelde proses sınırı ya da daha anlaşılır bir tabirle Meksika sınırıdır. Kodun hiçbir iç noktasındaki try/catch bu baba hatayı tutmamalıdır. Hiyerarşiye uyulmalıdır. Kimse hatadan anlamadıysa, en son noktada yakalanmalı, log’lanmalı ve mağrur bir şekilde kullanıcıya işlemin devam edemediği bildirilmelidir.
- Herkesin bildiği kural: mantıksal akış için Exception’lara yaslanılmamalıdır. Bu yapılar “iş” amaçlı değildir.
- Herkesin çok ihlal ettiği kural: Exception’ların StackTrace‘i yutulmamalıdır. Eğer catch’lerde yakalayıp “bu yoluna devam etsin” dediğiniz hatalar olur ise onları mutlaka “throw“ ile gönderiniz; eğer “throw new” ile gönderirseniz o zor bulunan, kimi zaman değerine paha biçilmeyen “Stack Trace” sıfırlanmış olacaktır. Özetle “throw new” çok dikkatle kullanılması gereken bir kalıptır. Stack Trace muhafaza edilmesi gereken değerli bir madendir.
- OOP mevsimine aldanıp yeni nesil Exception tipleri icad etmek yerine sistemin sizin için sunduğu öntanımlı olanları kullanınız. .NET size genel ihtiyaçlar için birçok tip sunuyor.
- Exception’lar CLR için pahalı ve ağır lokmalardır. O nedenle mümkün olduğunda onlara bulaşmadan adımlamak lazımdır. Bunu yapmanın en güzel yolu da pattern’lere yani kullanım kalıplarına başvurmaktır.
- Dokümantasyon: Her işimizi belgeli yapmalıyız. .NET’in kod içindeki XML dokumantasyon şeması, Exception’ları yazmaya da imkan veriyor. Eğer düzgünce yazarsanız, kod dokumantasyonunda metodlarınız için “taş düşebilir, ayı çıkabilir” nevinden notlar görülecek. Hoş değil mi?
- Montaj yasası gereği hiçbir şey işe yaramıyorsa övülen pratiklere bakılmalıdır.