Programlama Dilleri

Epey zamandır Ruby notlarımın (özellikle de Amazon’dan getirttiğim kitapların) yüzüne bakmadığımı gördüm de…Pişmanlık hissettim (İtiraf ediyorum bu aralar biraz tembellik yapıyordum) Sonra onunla uğraşmayı özlediğimi fark ettim. Onun sadeliğini, yalın yazımını, gücünü, pratikliğini. Pasımı atmak için bir şeyler araştırmam gerekiyordır. Derken kendimi her zaman ki gibi Google’da Ruby standart kütüphanesi ile ilgili faydalı kod parçalarını ararken buldum.

Bazı günler şirketten geç çıkıyorum. Özellikle el ayak çekildiğinde ofis ortamı bir şeylere çalışmak için son derece ideal oluyor. Tam da istediğim ortam. Kendi çalışmalarıma vakit ayırabildiğim hoşuma giden zamanlar. Hele de akşam güneşi camdan içeri giriyor ve en sevdiğim sarı rengi masamın üstüne bırakıyorsa.

Üzerinde çalıştığımız ve uzun süredir canlı ortamda yaşamakta olan eski bir ürünümüz geçtiğimiz günlerde kod kalite taramalarından birisine girdi. Vaktinde her zaman olduğu gibi alel acele yazılmak zorunda olan kodlar bir kaç ana kategori altında çeşitli tipte ihlallere yakalandı. Bunlardan birisi de Strongly Typed DataSet kullanımına ilişkindi.

Web tabanlı çalışan uygulamalar genellikle IIS (Internet Information Services) ve benzeri ortamlar üzerinde barındırılırlar. Aslında IIS basitçe TCP soket haberleşmesi gerçekleştiren bir ürün olarak düşünülebilir. Üzerinde konuşlandırılan kaynaklara olan erişimde ise genellikle HTTP protokolü ve Get, Post vb metodları kullanılır. Gelen taleplere göre uygun servislerin devreye girmesi söz konusudur.

Artık belli bir platforma bağlı kalmadan farklı uygulamaları bir araya getirip konuşturabiliyor, büyük ölçekli sistemleri uçtan uca bağlayarak süreçler işletebiliyoruz. Burada programlama dillerinin üzerine oturduğu çatıların (Frameworks) büyük avantajlar sağladığı ve işleri belirli ölçüde kolaylaştırdığı aşikar.

Sanıyorum bir programlama dilini öğrenirken en çok merak edilen konulardan birisi de veritabanı işlemleridir. “Hani bir uygulama yazabilsem de bilgileri veritabanına kayıt edebilsem ve oradan okuyabilsem süper olur” benzeri bir cümleyi eminim hepimiz kurmuşuzdur. Günümüzde geliştirilen uygulamalar mutlak suretle verileri kalıcı olarak saklamaya ihtiyaç duyar.

Bildiğiniz üzere.Net Framework çatısı altında bir çok arayüz (Interface) vardır. Özellikle plug-in tabanlı geliştirmelerde sıklıkla başvurduğumuz bu arayüzleri zaman zaman inceliyor ve nerelerde kullanılabileceğine bakıyorum. Yine bu araştırmaları yaptığım bir gün IFormattable arayüzünün kullanımına ilişkin örnekler ile karşılaştım.

Geçtiğimiz günlerde uzun süredir görüşmediğim bir arkadaşımdan mesaj aldım. Bir projesinde Levenshtein Distance algoritmasını kullanmaya karar verdiğini ve internette arama yaparken daha önceden yazdığım şu makaleye rastladığını dile getirdi. Hem kafasına takılan bir konuyu dile getirmek hem de bir hal hatır sormak istediğini belirtti.

Çalışmakta olduğumuz projelerde zaman zaman bizi zorlayan vakalar ile karşılaşıyoruz. Bu gibi durumlarda Google abimiz en büyük yardımcımız olabiliyor. Hatta pek çoğumuz sorunların çözümünde Stackoverflow gibi kaynaklardan yararlanıyor ya da daha deneyimli birisinden yardım istiyor. Ne var ki bazı vakaları kendimiz çözmeye çalışsak çok daha yararlı olabilir.

Geçtiğimiz günlerde üzerinde çalıştığımız bir projede, sıkıştırılmış metinsel içeriklerin açılması ile ilgili bir ihtiyaç doğdu. Cümle biraz karışık gelmiş olabilir. İfinim müsadenizle senaryoyu anlatayım öncelikle;

Günümüzde geliştirilen yazılım ürünleri çoğunlukla farklı uygulamalar ile de konuşmak durumunda. Sistemler sürekli birbirleri ile konuşan parçalar bütünü halinde genişlemeye devam ediyor. Akıllı cihazlar büyük ölçekli sistemlerin birer parçası olup çeşitli iş süreçlerinin işletilmesinde rol alıyor. Bu iletişimde servislerin de yeri var.

Takip edenlerin bildiği üzere bir süredir Ruby programlama dili üzerinde çalışmaktayım. İlerledikçe öğrendiklerimi kod parçacıkları halinde paylaşmaya çalışıyorum. Ne kadar faydalı oluyor bilemiyorum ama arada sırada takip ettiğim kaynaklardan geriye dönerek acaba atladığım bir şeyler var mıdır diye de bakıyorum. İşte bu düşünceler ışığında çıktım yola ve gerçekten de atladığım bir çok şey fark ettim. Bu kod parçacığında kısaca bu konulara değinmeye çalışacağım. Önce kod parçamızı ele alalım.

Bir önceki kod parçacığında geliştirici tanımlı bir sınıf koleksiyonunun JSON formatından nasıl serileştirilebileceğini incelemiştik. Ruby dilinde dahili (built-in) olarak gelen serileştirme kütüphaneleri de vardır (YAML ve Binary) Tahmin edeceğiniz üzere duruma göre bu serileştirme çeşitlerinden birisinin kullanılması tercih edilebilir. Aşağıdaki örnek kod parçacığında bu biçimdeki serileştirme ve ters-serileştirme işlemlerinin nasıl yapıldığı ele alınmaktadır.

Aslında bu kod parçasında temel dosya giriş çıkış işlemlerini (IO operasyonları diyelim) ele almayı planlamıştım. Ancak konuyu araştırırken dosya içerisine ne yazabilirim sorusuna denk geldiğimde, bir nesne koleksiyonunu aktarmanın uygun olacağını düşündüm. Hal böyle olunca ortaya “hangi fortmatta?” sorusu çıktı.

Ruby tam anlamıyla nesne yönelimli (Object Oriented) bir dildir. Bunu her fırsatta vurguluyoruz. Bu nedenle bünyesinde temel OOP özelliklerini taşır. Kalıtım (Inheritance) bunlardan birisidir. Ancak Ruby dilinde bir sınıfın aynı seviyede birden fazla sınıftan türemesine izin verilmez (Single Inheritance söz konusudur).

Module’leri sınıf değişkenleri, sınıflar, metodlar ve sabitleri (Constant) içerisinde barındırabilen isim alanları (namespace) olarak düşünebiliriz. Özellikle projelerin büyüdüğü durumlarda kullanılan tip veya metodların çakışmasını engellemek, kod tekrarlarının önüne geçmek (DRY-Don’r Repeat Yourself), bakım maliyetlerini azaltmak ve özellikle aynı iş alanına (Domain) özgü operasyonları anlamlı isim alanlarında konuşlandırabilmek maksadıyla tercih edilirler.

Malumunuz hata yönetimi (Error Handling) oldukça önemli bir konu. Bu amaçla.Net/Java gibi çalışma zamanı motoru olan ortamlarda genellikle Exception yönetim mekanizmaları kullanılmakta. Benzer durum Ruby programlama dili için de söz konusu. Aşağıdaki kod parçacığında hata yönetiminin Ruby tarafında nasıl ele alındığını temel anlamda incelemeye çalışıyoruz (Aslında beni benden alan rescue, retry ve ensure kullanımlarıdır. Söylemeden geçmek istemedim.)

Daha önceki kod parçacıklarımızda Block ve Proc kavramlarına değinmiştik. Benzer kavramlardan üçüncüsü de Lambda’dır. Hatırlayacağınız gibi kod parçalarını Block şeklinde tanımlayıp metodlara parametre olarak geçirebiliyorduk. Bununla birlikte tekrardan kullanılabilirliğin öne çıktığı ve kod parçasının bir değişken olarak kullanılmasının istendiği durumlarda Proc örneklerinden yararlanıyoruz.

Bir önceki kod parçacığımızda Ruby dilinin önemli özelliklerinden birisi olan Block kavramına değinmiştik. Bu kod parçacığında ise Proc kullanımını anlamaya çalışacağız. Kod parçalarını metodlara taşımanın yollarından sadece birisi Block’lardır. Ancak block’lar bir nesne olarak ifade edilemezler. Oysa ki Ruby dilinde her şeyin bir nesne olduğu öne sürülür. İşte bu noktada devreye Proc ve Lambda enstrümanları girer.

Ruby’nin güçlü olmasını sağlayan pek çok özellik vardır. block’lar bu güçlü özelliklerden birisidir. (Block’lar dışında Proc ve Lambda kavramları da mevcuttur ki bu konuları ve aralarındaki temel farklılıkları sonraki kod parçacıklarında ele alacağız)