• Performans ve scalability
• Komunite desteği (Yazılımcı ararken ya da takıldığınız noktayı sorarken lazım olacak)
• Geliştiren ekibin güvenilirliği (Kullandığınız framework’ün gelişmesinin durması kabus olacaktır)
• Kolay öğrenilebilirlik
• Kolay geliştirilebilirlik
• Yeterlilik / Esneklik
• Sunduğu özellikler
• Desteklediği PHP versiyonları

…

Zend Framework’ün Felsefesi

Özellikle Ruby on Rails’den sonra artan framework talebi sonunda birçoğu rails’den çok ciddi olarak esinlenen bir sürü framework çıktı. Arkasından Zend mühendisleri de framework ihtiyacına cevap vermek üzere çalışmalara başladı.

Code Igniter, Kohana, CakePHP, Symfony vb. projeler Rails’in izinden giderken Zend Framework kendine daha farklı bir yol çizdi. Rails ve türevleri tüm yapı için kesin kurallar koyup işe başlamayı hızlandırırken Zend Framework birbirinden bağımsız çalışabilen ama aynı zamanda birbirleriyle “iletişim kurabilen” modüller programlamayı tercih ettiler.

Zend Framework modüllerin yalnız başına kullanılabilir olması eski ve benim hala çok güvenemediğim PEAR kütüphanesinin yeniden yazılması ve Zend ile IBM gibi iki devin bu yeni kütüphaneyi (!) desteklemesi gibi yan bir misyonu da tamamlamış oldu.

Ancak bu yapının önemli bir dezavantajı oldu: Karmaşıklık. Yazılım kısmını geçtim, dokümantasyon kısmı çok karmaşık… Avantajı ise, örneğin konfigürasyon ayarlarınızı farklı bir şekilde tutmanız gerekse örneğin CodeIgniter’da hiç şansınız yok ama Zend Framework ile sorunsuz…

Dokümantasyon Problemi

Şu an Rails ve izinden giden framework’lerle birşeyler gerçekleştirmek çok daha kolay çünkü dokümanlarına baktığınızda son uygulamanızda deneyebileceğiniz şekilde anlatılmış vaziyette. ZF dokümanlarında ise hem tüm yapıdan bahsedilmeli hem de modülün tek başına nasıl kullanılabileceği anlatılmalı. Bu da iletişim konusunda zaten kazma olan Zend’i biraz aşıyor bence.

Sanırım Zend’in beklentisi komuniteden bu konuda tonla “tutorial” ve kitap çıkması idi ama pek de hızlı birşeyler çıktığını söyleyemeyeceğim.

Alt Framework

Rails ve türevlerinin yapısı yazılım mühendisliğinde “tight coupling” olarak adlandırılırken ZF’ninki “loose coupling” oluyor. Her ne kadar “loose coupling” yazılımlarda tercih edilen bir kavram olsa da web framework’leri için çoğu durumda tight coupling’in daha uygun olduğunu düşünüyorum. Küçük ve düşük bütçeli yazılımlar için ihtiyacımız olan “hızlı geliştirme”, bu da Zend Framework’ün şu anki haline hiç uymuyor.

Düşününce kapsamlı projeler için ZF, küçük projeler için diğer bir framework kullanmak öğrenme süreci nedeniyle mantıklı gelmiyor. O yüzden bence ihtiyaç olan ZF’nin bir alt framework’ünün olması.

Önceki bir yazımda demiştim ki “Zend Framework on Rails istiyorum!”
Eğer şu anda Rails tadında işleri çok hızla sizin adınıza yapacak bir yapıya ihtiyacınız varsa Zend Framework’ü tercih etmek için kendi “ZF on Rails”inizi yapmanız gerekiyor.

1. İndir,
2. zip’i aç
3. Konfigürasyonu yap
4. Controller ve modelleri hızla ekle
5. Teste aç ve pragmatik programlamaya devam et…

Bu paketin ZF’nin son versiyonuyla uyumlu olması gerektiğini düşünürsek paketin de sürekli geliştirilmesi gerekecek demektir.
Eh, bu da başlı başına bir framework gibi birşey oluyor.
ZF üzerine inşaa edilmiş bir alt framework…

Özellikle “Common tasks” kısmı çok başarılı olmuş zira framework’lerle oynarken birşeyler kapıyorsunuz yine ama iş uygulamaya gelince insan aptallaşıp kalıyor.

Otomatikleştirme ve pratiklik konusunda CakePHP Rails’e iyice yaklaşmış ama debugger’da kodu incelemeye başladım az önce, insanın kullanası gelmiyor wallahi. CakePHP’nin yavaş olduğunu duymuştum, bu kodun yavaş olmasına hiç şaşırmadım.

Zend Framework’ü ise çalışır hale getirmek bir eziyet, çalışır hale getirdikten sonra da etkin olarak kullanmak için yine üzerinde epey bir çalışmak lazım.

Ruby on Rails’in hayranıyım halen ama ne yazık ki gerçek hayatta Rails’i kullanmak hiç akıllıca değil: Toplum desteği (community support) zayıf, işe almak için yazılımcı bulmak zor, ileri seviye çözümler gerektiğinde ve yüksek yük altında Rails’in ölçeklendirmesiyle uğraşmak getirdiği avantajları geri götürüyor. Bazen şüpheleniyorum, Signal37 hakkaten KISS (Keep it Simple Stupid) felsefesinden mi yoksa işi karmaşıklaştırmamak için mi özellikleri kısıyor…

Zend Framework on Rails isterim!!!

Daha sonra Zend Framework çıktı (Symfony ve Cakephp de var framework olarak ama onları seçmeme nedenim ayrı) ama açıkçası ZF benim için hep “hiç yoktan iyidir” framework’ü oldu zira şu haliyle ZF’yi anlamak için bol bol araştırma yapmak ve debugger’ınızı açıp adım adım nasıl çalıştığını görmeniz gerekiyor.

21 Aralık’ta ZF ekibinin duyurduğuna göre ZF v1.5′te bence en büyük eksiklik olan “programcıyı yönlendirme” işine eğilmiş gözüküyorlar. Zend Framework’ün diğer framework’lerden farkı programcıyı kendi altyapısına uymaya zorlamaması. Kütüphaneleri veriyor ve programcıyı istediği yapıda kullanmakta özgür bırakıyor ancak MVC Model 2′nin karmaşıklığı, framework’teki kütüphanelerin çokluğu öğrenme zorluğu yaratıyor. Özellikle projenin organizasyonu hakkında (modeller nerede duracak, kontroller yapısı nasıl olacak vs.) Öğrenip kullanmaya başladığınızda ise birçok şeyi kopyala – yapıştır yaptığınızı fark ediyorsunuz.

ZF v1.5′te opsiyonel olarak proje yapısını otomatik sunma betiklerle işlemleri kolaylaştırma üzerine yoğunlaşmışlar gibi gözüküyor. Rails’i inceleyenler bu tür betiklerin getirdiği kolaylıkların farkındadır zaten, ZF’de de artık bu kolaylıkları görebileceğiz gibi duruyor.

Benim öngörüm ileride framework’lerin etkisiyle web tabanlı yazılımların üretilme zamanları oldukça kısalacak. Rails, ZF, Django, CakePHP, Symfony derken bunların IDE’lere entegrasyonu önplana çıkacak. Biz web2.0 geliştiricileri performans, güvenlik ve stabilite kaygılarıyla kendi yapılarımıza bağlı kalacağız belki, ancak web tabanlı servis veren diğer yazılımlar için bu altyapılar geliştirme sürelerinin azalmasına ve dolayısıyla maliyetlerin düşmesine destek olacak…

Diğer taraftan Javascript framework’leri de büyük bir hızla gelişiyor. Katmanlı yapı sayesinde birçok geliştirici artık projelerini en az 5-6 katmanda düzenliyor: CSS, Javascript, (X)HTML 3 ayrı katmanda semantik webi de destekleyerek önyüz mühendisliği adı altında gelişirken arkada template sistemi ile önyüze bağlanan page/interaction logic, application logic, data store gibi katmanlar birbirinden ayrı ve düzenli bir yapıya giriyor.

Javascript framework’leri RUI (Rich User Interface) oluşturulmasını hızlandırıyor, hatta biraz iddialı olacak belki ama birçok kişi için mümkün kılıyor. Javascript IDE’leri bile yavaş yavaş ortaya çıkmaya başladı: Bkz. Aptana

Sektör artık framework’lere doğru yönlenmiş vaziyette. Kullanmayacaksak bile altlarındaki çözümleri iyi öğrenmemiz gerek…

1. Sürekli değişim
2. Hibrid tasarımcı kavramı

Sürekli Değişim

Eskiden sağlam bir planlama, tüm fonksiyonlara karar verip analiz etme ve ürünü çıkarma şeklinde işliyordu projeler.

Sonraki versiyon uzun bir süre sonra, yine benzer aşamalardan geçtikten sonra çıkıyordu. Çıkana kadar kimsenin bilmediği, gizli kapaklı hummalı çalışmalar sürüyordu.

Yeni yaklaşımda ise planlama yapılırken detaylara gömülmek yerine:

- ilk versiyonu çıkar
- kullanımı analiz et, ihtiyaçları belirle
- yeni versiyonu çıkar
- kullanımı analiz et, ihtiyaçları belirle
- yeni versiyonu çıkar

şeklinde ilerliyor herşey. O kadar çok versiyon çıkıyor ki, versiyon diye bir kavramı kullanmıyor bile bir çok proje… Versiyonlamamayı “sürekli beta” olarak adlandıranlar bir ara çok modaydı.

Bu, tasarımın defalarca değişmesi demek… Veritabanına eklenen/çıkan yeni alanlar, yazılımın arada bir tepetaklak olması demek.

Buna tasarımcıların ve yazılımcıların kendini hazırlaması ve sürecin doğal bir parçası olarak kabullenmeleri gerek.

Bu “yap-boz”ların hızla gerçekleştirebilmesi açısından framework’ler çok büyük şeyler kattı dünyadaki büyük projelere.
Ya da belki de tam tersi, büyük projeler framework’lere ilham kaynağı oldu. Framework kullanmayan büyük projeler de framework’lerin getirdiği avantajları sağlayan altyapılarını kurarak ilerlediler. Kendilerine özgü frameworkler kurdular diyebiliriz belki de…

Kibrit Tasarımcı!

Ne demek hibrid?? Ah be TDK yetişemiyorsun ne yazık ki gelişen teknolojiye…

“Wepçi” arkadaşlara dedim ki,

….. web tasarımcısı diyelim de ayıp olmasın

Web tasarımcısı arkadaşlara dedim ki, unutun o firmalara sayfa hazırlarken “ben fotoşop’ta yaparım, htmlci sayfa haline getirsin çünkü ben programcı değil sanatçıyım” laflarını…

Artık öyle bir şey kalmadı üzgünüm. CSS’i sevgilisinin yuvarlak hatları kadar bilmeyen web tasarımcısı 5-10 sayfalık kurumsal site tasarlamaktan öteye geçemez. Ajax’ı nerede kullanmaması gerektiğini bilmeyen, actionscript’in kabiliyetlerinden bihaber olan tasarımcı anca “bizim yeğen de yapıyor web sitesi” cümlesinin öznesi olabilir…

sevgi kelebeği

Web tasarımcısı, grafik tasarımcısından farklı olarak, internet gurusu olmalı. Programlamaya, daha doğrusu analitik düşünceye çok ters olmaması lazım. Uçuk kaçık hayal dünyasında yaşayan, sanat kim içindir geyiklerine giren entellektüel sevgi kelebekleri yerine, estetik duygusu güçlü olan ve tasarım ilkelerini bilen, CSS’te organizasyon yapabilen, javascript’te 3-5 satır if-else cümleleri kurabilen programcı-tasarımcı arası ortaya karışık web tasarımcıları hayatta kalacak web2.0′da, web3.0′da ve hatta ‘web9.0.1rc1 build 3425′te…

Sonuç

Yazılar giriş-gelişme-sonuç şeklinde olmalıdır. Buyrun size sonuç (lisedeyken de nefret ederdim edebiyat derslerinden, öys’de türkçeden top çekmiştim o ayrı…)

Arda Kutsal şu yazısında Türkiye’deki geliştiriciler olarak global ürün çıkarmamız gerektiğinden bahsetmiş.
Altına 3 sayfa huysuzluk yaptım, muhtemelen gıcık oldu Arda bana :)

Global ya da lokal, dünyadaki projelerle yarışacak boyutta proje çıkarmak istiyorsak üşenmeyeceğiz….

Framework’lere geçmek için üşenmeyeceğiz,
2 günde bir tasarım mı değişir canım demeyeceğiz,
Ben sanatçıyım kardeşim kodlama benim sanatımı öldürür diye kendimizi kısıtlamayacağız,
script.aculo.us neymiş ben de yazarım ne var ki’lerle vakit kaybetmeyeceğiz.

Bu iş teknik bir iş… Hem de çok teknik bir iş. “Fikrimgeldi”den öteye geçebilenler Türkiye’nin internetini ayağa kaldıracak olanlardır.

Benden söylemesi
(evet, hem huysuz hem de ukelayım!)

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.

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.