Çoğunlukla bir yerden kazanırsanız diğer bir yerden kaybedersiniz. Mühendislikte bir kaldıraç “dünyayı kaldırabilir” belki ama kaldırabilmesi için kaldıracın uzun tarafı kilometrelerce yol kat etmesi gerekecektir, yani kuvvetten kazanırken yoldan kaybedersiniz. Ekonomide risk yönetimi prensibidir belki ya da Murphy’nin kanunlarında her zaman kazandığınızdan çok kaybedersiniz ama sonuçta birçok durum için geçerlidir bu kural.

Programlamada da işini ne kadar kolaylaştırırsanız o kadar performans kaybedersiniz. Veritabanı işlemleri için bir “wrapper” kullanmak, ayrı dili olan şablon (template) kullanmak ve hatta bunların hepsini bir arada sunan bir framework kullanmak performansı azaltacaktır. Bu konuda sanırım hepimiz hem fikiriz.

Performans konusunda bir kriter fizibilite. Yani performans kayıplarını daha güçlü ya da paralel çalışan sunucularla gidermek performanslı bir altyapıda daha uzun sürede proje tamamlamaktan daha ekonomik olacaktır, bundan daha önce bahsetmiştim. Ama tabii ki performans optimizasyonu olmasın, sıkıştıkça donanıma abanalım demiyorum.

Standart optimizasyonların dışında birazcık hile yapmak da gerekli…

Ruby iyi güzel de çok yavaş

Bu blog ağırlıklı olarak Ruby on Rails’e değiniyor çünkü Rails’in sonuca odaklı hızlı geliştirme yeteneği, yıllardır tercih ettiğim PHP’ye baskın çıkıp kafamı karıştırıyor (!) Ancak ruby’nin php’den yavaş çalıştığı bir gerçek olarak önümüzde yer alıyor.

Tabii hemen şunu da belirteyim ki mesela bir C programı da mutlaka PHP’den hızlı çalışacaktır. İşte bu noktada biraz “hile” yapmaktan zarar gelmez diyorum.

Mesela FotoKritik’in “çöp toplama” işleri için cron’da çalışan programları tercih ediyorum. Ya da günün fotoğraflarını her gece çalışan bir cron betiği seçiyor ve seçilmişleri gösteriyorum kullanıcıya. Şu an fotoğrafların küçük hallerini yükleme sırasında PHP’yle oluşturuyor olsam da günün birinde fotoğraf yükleme miktarı bugünkünün 10 katına çıkarsa fotoğraf işleme işlemini PHP yerine C’ye yaptırmakta hiç çekinmem.

Bu yazıyı yazmaya aslında Loud Thinking‘deki bir yazı sayesinde karar verdim. Rails, ilk gördüğüm günden beri kafamdaki karman çorman düşünceleri derleyip toparlaması nedeniyle hayran olduğum bir teknoloji ve bir felsefe. Rails’in yaratıcısı, ruby’nin performansı ile ilgili düşüncelerini yine her zamanki gibi %100 katıldığım bir şekilde özetlemiş aslında.

David yazısında, Yahoo’nun sayfalarını PHP ile sunarken arkaplanda C++’a dayalı bir sistem olduğundan, amazon’un C++ ve Java tabanlı altyapısının Perl ve Mason ile sunulduğundan bahsetmiş. Kendisi de basecamp’te imaj işlemlerini rails’in rmagick eklentisi yerine shell üzerinde yaptığını itiraf etmiş. Kendi deyimiyle bu hile yapmak, evet. Ama hile işe yarıyor demiş. Eğer fayda sağlıyorsa iyi birşeydir bence de…

Sonuçta amaç takım tutar gibi rails’i tutmak ya da zamanında yaptığımız gibi PHP ASP’yi döver demek değil. Amaç kaliteli bir ürünü, hızlı, sistematik, geliştirilebilir, genişletilebilir ve bakımı kolay bir şekilde ortaya çıkarmak…

Yazının sonuç cümlesi hoşuma gitti, paylaşmak isterim:

“… So please don’t let bottlenecks (real or imaginary, usually the latter) dictate your choice of software development environment. “

… Dolayısıyla lütfen bottleneck’lerin (gerçek ya da hayali, genellikle de hayali) yazılım geliştirme platformu seçiminizi etkilemesine izin vermeyin.

Ben platform olarak PHP’yi tercih eden bir insan olarak “15 dakikada weblog yaratın” screencast’ini izledikten sonra sinir oldum. Tecrübeli bir programcı olarak neredeyse haftamı alacak bir işin 15 dakikada bitmesi gerçekten de moral bozucu :) Bu kadar zamandır haybeye uğraşıyormuşum diyor insan kendine.

İlk şoku (!) atlattıktan sonra daha önce incelediğim otomatik kod üreteçleri gibi mi acaba diye düşündüm. Bu tür yapıların ortak sorunları

• Yeteri kadar kişiselleştirilememesi
• Kişiselleştirmenin kodu sıfırdan yazmaktan daha çok vakit alması
• Çok karmaşık olması nedeniyle güvenlik açığı içermesi ya da bug’lı olması
• Performans kaybı

olarak özetlenebilir.

Ama rails ile ortaya konan ürünlere baktığımda etkilenmemek imkansızdı o yüzden derinlemesine araştırmaya başladım rails’i.

Öncelikle Ruby on Rails, web uygulamalarını geliştirmenizi, yayına sokmanızı ve geliştirmenizi kolaylaştıran bir framework, “acemiler için kod üreteci” değil. Dolayısıyla hedef kitlesi profesyoneller. (Bkz. “Bizim yiğen de yapıyor web sitesi“)

Framework, yazılım projelerini geliştirmenizi kolaylaştıran, bunun için size bazı metotlar, şablonlar ve kütüphane sunan, çeşitli komponentlerle esnekliğinizi arttıran sistemlerdir. Programcının navigasyon sistemi nasıl çalışacak, mail nasıl atılacak gibi teknik detaylar yerine doğrudan ihtiyaç ile ilgilenmesine olanak sağlar.

Aslında Ruby on Rails birçok programcı tarafından kullanılan pratik uygulamalar ve programlama paradigmalarını bir araya getirmiş ve gerçekten detayları bırakıp uygulamaya odaklanmayı sağlayan “rapid application development” (hızlı uygulama geliştirme) konusunda, bu sistemin dezavantajlarını azaltarak önemli bir aşama kaydetmiş bir platform. Tabii ki bu aşamalarda ruby betik dilinin obje odaklı, pratik yapısının katkısı büyük.

Ama “hızlı” tek başına birer kriter değil. Profesyonel geliştiriciler modern, profesyonel tekniklerle geliştirilmiş uygulamalar üretmeyi hedeflerler. RoR bu imkanı sağlıyor bize…

Rails’in fark yaratan özelliği, web’i gerçekten anlayan geliştiriciler tarafından yaratılmış olması.

Ruby on Rails’in yaratıcısı David Heinemeier Hansson “agile software development” (çevik yazılım geliştirme) manifestosunda da imzası olan, DRY (Don’t Repeat Yourself), pragmatik programlama gibi felsefeleri takip eden yaratıcı ve ödüllü bir programcı.

Hansson’un railsde bir araya getirdiği teknik ve paradigmalardan bazıları:

1. MVC – Model / View / Controller (JSP kullananlar bilirler)
2. ORM – Object Relational Mapping veritabanı arabirimi (Rails’de ActiveRecord olarak geçiyor)
3. REST – REpresentational State Transfer
4. DRY – Don’t Repeat Yourself
5. Agile Programming
6. Pragmatic Programming

Profesyonel programcılar yazılımları için test programları yazarlar, böylece kodda bir değişiklik yaparken başka bir yeri bozup bozmadıkları otomatik olarak test edilir. PHP’de uygulamasına pek rastlamadığım bu yaklaşımın altyapısı RoR’da mevcut.

Ek olarak Ruby on Rails’in test, development ve production versiyonlarını bir arada tutabilmesi ve aralarında kolayca geçiş yapabilmesi çok başarılı bir özellik.

RoR’un sayfasına giderseniz, kitaplar kısmında “Agile Web Development with Rails” isimde bir kitap göreceksiniz. Kişisel tavsiyem paraya kıyın ve RoR’u ister kullanın ister kullanmayın bu dokümanı baştan sona okuyun. Sadece Ruby on Rails’i tanımayacak, çalışma sistematiği de göreceksiniz adım adım.

Ben bu kitabı okuduktan sonra FotoKritik’in php kodlarını yeniden düzenleyerek v3′ü yayına soktum. Railse geçiş yapmadım ama bana gerçekten de büyük bir esneklik ve scalability (Türkçesini bilmiyorum) sağladı.

Performans

Grafik tasarımcı bir arkadaşa yine ballandıra ballandıra railsi anlatırken “iyi de yavaşmış be abi” diye bir yorum aldım. Evet belki PHP’den yavaş ama unutmamak lazım ki PHP de C’den yavaş, hatta C de assembly’den yavaş. Assembly mi kullanalım yani?

Aslında genel kural olarak işinizi kolaylaştıran her ek kod bir performans kaybı demek. Dolayısıyla yıllarca örneğin bir database wrapper kullanmayı reddettim, zorunda kalıncaya dek…

Bu konuda kendimi eleştirdim yıllar önce, konuya bir de şu açıdan yaklaşmak lazım. Her zaman en büyük maliyet işçiliktir. Kullandığınız sunucu bilgisayarın kaç brüt maaşınız ettiğini bir hesaplayın. Yanına aynı sunucudan bir tane daha koyun ama daha az performanslı bir framework sayesinde programlama hızınızın 4 katına çıktığını hesaplayın. Birkaç ayda yeni sunucunuzu amorti edeceksiniz.

Tabii bu demek değil ki performans optimizasyonu yapılmasına gerek yoktur, sıkıştıkça ekleyin bir sunucu. Performans optimizasyonu çok kritiktir ve bir noktadan sonra istediğiniz kadar donanıma yüklenin verim alamayacağınız gibi maliyet katlanarak artmaya başlar.

Ancak RoR da o kadar yavaş değil, içerisinde caching mekanizması mevcut ve hiç de küçük sayılmayacak projelerde başarıyla kullanılıyor.

Sonuç: Kullanmalı mıyım?

Ruby on Rails, screencastlerindeki çalışma hızıyla inanılmaz bir ilgi topladı. Birçok ödül aldı, Web2.0 ile özdeşleşen bir teknoloji oldu, teknolojinin yaratıcısı dergilere kapak oldu, kitabı ödüller aldı. Ruby’den başka platformlarda da birçok kopyası çıktı. Hatta Zend bile RoR’dan sonra Zend Framework‘e hız verdi. Bunca ilginin bir nedeni olmalı…

Rails gerçekten de öğrenmesi zor bir framework, asıl faydasını ise gerçekten öğrendikten sonra görebileceğiniz bir platform. Aslında tüm frameworkleri öğrenmek biraz vakit alır o açıdan gözünüz korkmasın, aslında demek istediğim şuydu:

PHP’ye hakimim, kendime göre bir sistem oturtmuşum, muhtelif yerlerde muhtelif şekillerde sakladığım hazır kodlarım var ve bunları kopyalayarak yeni projelerde kullanabiliyorum ve yavaş sayılmayacak bir hızda proje geliştirebiliyorken tam hakim olmadığım, iki de bir “şu nasıl yapılıyor” diye araştırmam gereken bir framework’e geçmekte zorluk çekiyorum, üşeniyorum diyebilirim.

Ama birşeyi çok iyi biliyorum, bu platforma geçersem bana faydası büyük olacak. Neden mi:

• Oturmuş bir ORM yapısı. ORM ile sql cümleleriyle boğuşma derdinden büyük ölçüde kurtulabilirim
• Railsin konfigürasyon dosyaları “varsayılan” ayarların değiştirilmesi temeline dayanır. Dolayısıyla javadaki kocaman xml dosyaları yerine pratik bir konfigürasyon yapısı vardır.
• RESTless url’lerim olması için parametreleri, rewrite kurallarını ve url’yi nasıl parse edeceğimi düşünmeme gerek yok
• Scaffolding ile CRUD operasyonları ile ilgili kodlamanın %90′lık kısmını birkaç saniyede üretebilirim
• Var olan versiyon çalışırken ve aynı zamanda yeni bir versiyonu geliştirirken, var olan versiyon üzerine bir ek yapmak istediğim zaman pratik bir şekilde “test” versiyonunda çalışabilir, stabil olduğundan emin olunca var olan versiyona bunu aktarabilir ve “developer” versiyonunda geliştirmeye devam edebilirim. Bunu yaparken test sunucumdaki konfigürasyon dosyasındaki küçük bir değişiklik yeterli olacaktır.
• script.aculo.us kütüphanesi varsayılan olarak var, dolayısıyla şık DHTML etkileri ve AJAX implementasyonu çok pratik
• Oturmuş bir MVC yapısı, helper fonksiyonları, kısmı şablon (partial template) gibi kolaylıklar
• Şablonlar (templates) ve hatta otomatik üretilen kodları kişiselleştirebilirim.
• Webrick sağolsun, sunucu tanımlamakla uğraşmama gerek yok. Özellikle RadRails üzerinden kontrol edebilmek çok pratik.
• Uygulamamı otomatik test edecek test uygulaması yazabilirim.
• Uygulama, geliştirme ve test versiyonları için farklı hata kayıt kuralları tanımlayabilirim. Versiyonlar arası geçişin çok pratik olduğunu hatırlatırım.
• Basit ve kısa kodlar ile daha hızlı kod yazabilirim. Mesela: “function () {” yerine “def” yazmam yeterli.

Peki hiç mi dezavantajı yok railsin? Var tabii ki:

• Framework öğrenmek her zaman zahmetli bir iştir. Railse geçmek biraz vakit ayırmayı gerektiriyor
• API dokümantasyonundan railsi öğrenmek neredeyse mümkün değil. Öğrenmek için rails sayfasından erişebileceğiniz kitapları satın almanız gerek. En azından ben bu yazıyı yazarken durum böyle.
• Yeni sayılabilecek bir yapı olduğu için halen yeterli kaynak bulmak zor oluyor.
• Stabil bir IDE’si yok. RadRails çok iddialı geliyor ancak daha vakti var.
• Hosting konusunda nispeten sınırlı kaynak var.
• Genel olarak çok kısa kodlar yazarak projenizi geliştirebiliyorsunuz ama MVC yapısı, helper dosyaları, yönlendirmeler derken özellikle yeni öğrenirken hangi kod neredeydi kafa karışabiliyor o yüzden frameworkün nasıl çalıştığını gerçekten iyi anlamak gerekli.

Bu durumda Ruby on Rails’in hız ve sistematiğinden yararlanmak için Mac almak dışında bir seçeneğimiz daha var: RadRails. Java tabanlı eclipse altyapısına sahip olduğu için birçok işletim sisteminde çalışıyor. Bu editörle ilgili ilk izlenimlerim şöyle…

Var olan fonksiyonları ile RadRails textmate’e göre bile birçok avantaja sahip. MVC yapısındaki controller ve view arası geçiş kısayolu (Shift + Ctrl + V) çok kullanışlı. Programa entegre generator ve server yapısı sayesinde rails elemanları oluşturmak için komut istemcisine mecbur değilsiniz. Ayrıca test ve hata logları da editöre entegre edilmiş. SQL görüntüsüne de sahip. Biraz doküman okuyarak RadRails’in etinden sütünden faydalanabiliriz, ancak…!

Bazı sorunları var RadRails’in. Öncelikle windows kullanıcıları için java’nın “Regional and Language Options”la ilgili sorun. Daha önce Oracle kurulumunda da karşılaştığım bu sorun nedeniyle Regional and Language Options Turkish seçili iken hata mesajı vermeden editör ölüyor. O yüzden English (US) seçebilirsiniz. Windows’unuzun tarih ve sayıları amerikan formatında vermemesi için kişiselleştirerek kullanılabilir hale getirebilirsiniz. Bu durumda ne yazık ki windows’ın takviminde gün ve aylar ingilizce gösterilecektir.

İkinci sorun ise ruby installation’ı ile ilgili. Normalde RadRails ilk kurulduğu zaman ruby.exe path’te yer aldığı için yarım yamalak çalışıyor ve server generate etmek isteyince hata vermediği gibi hiçbir şey de yapmıyor. Bunun için RadRails’in ayarlarından Ruby başlığına girip tüm gerekli olan yerlere ruby.exe’nin yerini belirtmek gerekiyor.

Bir başka not: Varsayılan encoding CP-1252 gelir, proje özelliklerinden (properties) UTF-8′e çevirmezseniz türkçe karakter yüzünden dosyayı kaydetmemek gibi huysuzluklar yapabilir. RadRails ayarlarını biraz kurcalarsanız tüm projeler için varsayılan encoding’i seçme imkanı da mevcut. İsterseniz encoging’i proje bazında da ayarlayabiliyorsunuz.

RadRails’in 0.6′dan 0.7.2′ye kadar sürümlerinde kod tamamlama işlevini tam ve doğru bir şekilde çalıştıramadım, o da ayrı bir konu… İlk stabil versiyonu hevesle beklemekteyim…
Şimdilik bu kadar…

Ruby on Rails’i türkçe projelerde kullanmak için birkaç noktaya dikkat etmeniz gerekli. Bunlardan ilki encoding.

Diğer bir nokta, Ruby on Rails’in scaffolding özelliği ve tarih formatlama özellikleri amerikan formatına göre hazırlanmış. Ancak biraz kurcalayarak bu özelliklerden türkçe projeler için de yararlanabiliriz. Türkçeleştirme işleminden sonra proje hazırlama hızınız daha da artacaktır.

Bu yazıda bahsettiğim dosyaları biraz kurcalayarak scaffolding ile oluşturulan sayfalar için kendinize özgü bir tasarım da yaratabilirsiniz. Özellikle yönetim arabirimleri için ideal olan scaffolding sayfalarına kendinize ait bir tarz oluşturduktan sonra tasarımıyla hiç vakit kaybetmeden müşterilerinize sunabileceksiniz.

Ayrıca RadRails için de iki önemli ipucu. RadRails hiç çalışmıyorsa ve RadRails’in encoding desteği ile ilgili…

Encoding

Benim gibi PHP tabanlıysanız muhtemelen latin5 (iso-8859-9) encodingi kullanıyor olabilirsiniz. Artık UTF-8′e geçmenin zamanıdır. RoR’un varsayılan encoding’i zaten UTF-8. UTF-8 karakter seti aslında tam bir türkçe desteği sağlıyor o nedenle değiştirmeye gerek yok, zira çok uğraşırsınız. Ayrıca Ajax kullanacaksanız zaten diğer encodingleri kullandığınızda karakter sorunu yaşamanız muhtemel, çünkü javascript de utf-8 kullanır. O yüzden iyisi mi siz baştan UTF-8 çalışın.

Burada dikkat etmeniz gereken nokta, veritabanını da UTF-8 kullanacak şekilde ayarlamanız gerekli. Ayrıca UTF-8 desteklemeyen bir text editörü ile dosyalarınızı açarsanız türkçe karakterlerin bozuk gözükmesine neden olmanız muhtemel. Neyseki günümüzdeki editörlerin çoğunluğu UTF-8 destekli.

Scaffolding ve Varsayılan Tarih Formatı

Varsayılan tarih formatı da ingilizce. Ancak bunu değiştirmeniz mümkün:
Önce, tarih formatını düzeltmek için config/environment.rb dosyasına:

[source:ruby]

ActiveSupport::CoreExtensions::Time::Conversions::DATE_FORMATS.update(:default => ‘%d/%m/%Y %H:%M’)
ActiveSupport::CoreExtensions::Date::Conversions::DATE_FORMATS.update(:default => ‘%d/%m/%Y’)
require ‘overrides’

[/source]

satırlarını ekledikten sonra az önce require ettiğimiz overrides dosyasını lib/overrides.rb adı altında yaratıp içerisine gün ve ayların türkçe karşılıklarını yazabiliriz:

[source:ruby]

Date::MONTHS = { ‘Ocak’ => 1, ‘Şubat’ => 2, ‘Mart’ => 3, ‘Nisan’ => 4, ‘Mayıs’ => 5, ‘haziran’ => 6, ‘Temmuz’ => 7, ‘Ağustos’ => 8, ‘Eylül’=> 9, ‘Ekim’ =>10, ‘Kasım’ =>11, ‘Aralık’ =>12 }
Date::DAYS = { ‘Pazar’ => 0, ‘Pazartesi’ => 1, ‘Salı’ => 2, ‘Çarşamba’=> 3, ‘Perşembe’ => 4, ‘Cuma’ => 5, ‘Cumartesi’ => 6 }
Date::ABBR_MONTHS = { ‘Oca’ => 1, ‘Şub’ => 2, ‘Mar’ => 3, ‘Nis’ => 4, ‘May’ => 5, ‘Haz’ => 6, ‘Tem’ => 7, ‘Ağu’ => 8, ‘Eyl’ => 9, ‘Eki’ =>10, ‘Kas’ =>11, ‘Ara’ =>12 }
Date::ABBR_DAYS = { ‘Paz’ => 0, ‘Pzt’ => 1, ‘Sal’ => 2, ‘Çar’ => 3, ‘Per’ => 4, ‘Cum’ => 5, ‘Cmt’ => 6 }
Date::MONTHNAMES = [nil] + %w(Ocak Şubat Mart Nisan Mayıs Haziran Temmuz Ağustos Eylül Ekim Kasım Aralık)
Date::DAYNAMES = %w(Pazar Pazartesi Salı Çarşamba Perşembe Cuma Cumartesi)
Date::ABBR_MONTHNAMES = [nil] + %w(Oca Şub Mar Nis May Haz Tem Ağu Eyl Eki Kas Ara)
Date::ABBR_DAYNAMES = %w(Paz Pzt Sal Çar Per Cum Cmt)

class Time
alias :strftime_nolocale :strftime

def strftime(format)
format = format.dup
format.gsub!(/%a/, Date::ABBR_DAYNAMES[self.wday])
format.gsub!(/%A/, Date::DAYNAMES[self.wday])
format.gsub!(/%b/, Date::ABBR_MONTHNAMES[self.mon])
format.gsub!(/%B/, Date::MONTHNAMES[self.mon])
self.strftime_nolocale(format)
end
end

[/source]

Aktif hale geçmesi için web server’ın restart edilmesi gerektiğini unutmayın…

Kişiselleştirme

Her proje için bütün bunları tekrar etmenize gerek yok aslında. Ruby on Rails’in yeni proje yaratırken baz aldığı template dosyalarını bir sefere mahsus güncellemeniz yeterli olacaktır. Windows kurulumunda ilgili referans dosyaları aşağıdaki dizinlerde mevcut.

C:\ruby\lib\ruby\gems\1.8\gems\rails-1.1.6\environments

Scaffolding ile yaratılan dosyalara kendinize ait bir tarz vermek için şablon dosyalar ise şu dizinde:
C:\ruby\lib\ruby\gems\1.8\gems\rails-1.1.6\lib\rails_generator\generators\components\scaffold\templates

Bu dizinlerdeki dosyaları güncelledikten sonra her yeni proje yaratışınızda, projeniz belirlediğiniz ayarlarda yaratılacaktır.

RadRails

RadRails kullanmadıysanız ya da kullanmak isteyip windows üzerinde bir türlü çalıştıramadıysanız daha önce RadRails ile ilgili yazdığım kısa yazıya bakabilirsiniz.