The Rails Doctrine Rails Doktrini: Ruby on Rails İlke ve Görüşlerini Anlayın Tayfun Öziş ERİKAN, Genel Koordinatör Lab2023 Bilişim Teknolojileri AŞ [email protected] - @toziserikan

• “Lab2023” Kurucu ortağı & Genel Koordinatör • “Bulutfon” Kurucu ortağı • Ruby on Rails kullanıcısı • Tasarımcı ve programcı • [email protected] • Twitter: @toziserikan Ben kimim?

–David Heinemeier Hansson “Ruby’i keşfetmem, kişisel olarak benim; 'programlara ihtiyaç duyduğum için programlama' yapmaktan ziyade, ‘bir entelektüel egzersiz ve ifade biçimi olarak programlama yapmaya aşık olmamı' sağladı. Bu keşif sayesinde aynı zamanda Ruby yaratıcısı Matz’ın fikirlerini ve Ruby’nin faydalarını yaymak için misyonerlik yapmam gerektiğinin de farkına varmış oldum.”

DHH, Rails’in etkisini ve topluluğunu nasıl büyütebileceğini daha detaylı açıklamak için bir doktrin yazmıştır. Rails'in popülerliği büyük ölçüde yeni trendlere ve teknolojilere doğru zamanda geçişten kaynaklanmaktadır. Zaman içinde teknik avantajlar önemsiz hale gelmekte ve iyi zamanlama uzun vadede tek başına yeterli olmamaktadır. Bu kaynak son on yılda aktif olarak gelişmektedir ancak temel fikirlerin çoğuna dokunulmamıştır. Rails'in başlıca başarısı, programcı ve programcılığın doğası hakkında sıradışı olmayan bir yaklaşım ve dünya görüşüyle güçlü bir topluluğun kendi etrafında birleşmesinden gelir. İşte bu başarının 9 önemli anahtarı…

Programcı mutluluğu için optimizasyon

• Ruby on Rails, Ruby olmadan var olamazdı. Bu nedenle Rails, Ruby’nin yaratılmasındaki temel motivasyonu paylaşır. • Ruby programcı mutluluğunu diğer dillerden farklı olarak bir kural olarak benimsemiştir. • Bazı diller birşeyi yapmak için tek bir yol olduğunu savunurken, Ruby ifade özgürlüğünü savunmaktadır. • Ruby basit gibi görünen karmaşık optik yansımalarla dolu güçlü bir dildir. Programcının duygularını ifade edebileceği bir çok araç ile donatılmıştır. • Ruby yeni bir vizyon, karşı kültür ortaya koymuş ve var olan mesleki programlama kalıplarına kısılmış kalmış tüm programcılar ve meslek grupları için farklı bir yer olarak benimsenmiştir.

• Ruby tanımlamak için sıklıkla kullanılan güçlü bir ilke olan “En az sürpriz” (PoLS - Principle Of Least Surprise) ilkesi bulunmaktadır. Ruby beklediğiniz gibi davranmalıdır. Örn: Python’un aksine… • Bu ilkeye bir örnek vermek gerekirse; $ irb irb(main):001:0> exit $ irb irb(main):001:0> quit $ python >>> exit Use exit() or Ctrl-D (i.e. EOF) to exit • Ruby programcının çıkmak istediğini bildiği için “exit” ve “quit” komutlarını kabul ederken, Python açıkça ne yapmak istediğini bildiği halde çıkmak için doğru komutu yazmasını bekler. • Bu durum ilk Matz’ı şaşırtmış ve Matz’dan daha farklı şeylere şaşıran bir çok kişi ile oluşan ve büyüyen bir topluluğa dönüşmüştür.

• Bu ilkenin Ruby on Rails ile olan ilgisi, Rails’in de aynı ilkeyi geliştirerek kullanmasından gelmektedir. DHH’nin “Daha Büyük Gülümseme” ilkesi. • Her iki proje de benzer şekilde tek bir kişinin zihninden doğmuştur. • Rails öncelikle DHH’in kendisi için tasarlanmıştır. Onu daha fazla eğlendirmek için, yaptığı işten daha fazla zevk almasını sağlamak ve günlük rutin işlerini zenginleştirmek için. • Bu bakış açısı ile tasarlanan API’ler daha fazla gülümsemelere neden olmaktadır. Bu düşüncenin narsistçe göründüğü aşikardır fakat Rails’i tasarlamak başlarda böyle narsist bir çaba gerektirmiştir. • Bu bakış açısından saplantıyla ortaya çıkan ve Rails’de bulunan en temel sınıf Inflection sınıfıdır. Temel dil problemlerini çözmek ve yorumlamak için tasarlanan bu sınıf şu anda Rails’in vazgeçilmez bir parçası olarak algılanmaktadır.

• Geliştirilmiş olan bir araç bazen ne kadar mantıksız yada performanssız bulunsa da “DHH” ve onun gibi düşünenleri güldürdüğü, hayatını zenginleştirdiği ve keyiflendirdiği sürece Rails’de var olmaya devam edecektir. • Performans optimizasyonunun aksine, geliştirmenin rahatlığını ve programcının mutluluğunu ölçmek mikro düzeyde zor olsa da makro düzeyde çok daha net görülmektedir. • Ruby on Rails topluluğu makro düzeyde mutluluk hedefleri olan insanlarla doludur. • Sonuç itibariyle: Mutluluk için optimizasyon, belki de Ruby on Rails'in en yaratıcı anahtardır ve böyle devam edecektir…

Konfigürasyon konvansiyonu (anlaşması) Convention over Configuration - CoC

• Rails'in ilk dönem üretkenlik sloganlarından biri: "Sen güzel ve eşsiz bir kar tanesi değilsin” olmuştur. Bu bakış açısı bireysellikten sıyrılıp sıradan kararların zorluğuna takılmadan daha hızlı ilerlemeyi mümkün kılmıştır. • Veri tabanında bulunan bir tablonun birincil anahtar adının "Id", "postId", "posts_id" veya "pid" olup olmadığı gerçekten önemli midir? Bu, tekrar eden görüşmelere değecek bir karar mıdır? Hayır değildir. • Rails misyonunun bir kısmı geliştiriciler için sürekli tartışmalara sebep olan bu sorun / çözüm döngüsünü ortadan kaldırarak hızlıca yol almanızı sağlamaktır.

• Örneğin; Person sınıfını people tablosuna bağlayarak has_many: people ilişkilendirmesini Person sınıfına ulaşmak için rahatlıkla kullanabiliriz. İyi konvansiyonlar (anlaşmalar) geniş kullanım yelpazesini yanında getirmektedirler. • Uzmanlar için üretkenlik kazanılmasının ötesinde konvansiyonlar (anlaşmalar) “hızlı öğrenme eğrisi” ve “giriş bariyerini düşürme” gibi avantajlar da sunmaktadır. • Rails’de bir acemi, konvansiyonlardan faydalanarak bir şeyin ne şekilde çalıştığını bilmeden bir çok işlevi yerine getirebilir ve mükemmel uygulamalar oluşturabilir. • Burada en önemli konu konvansiyondan ne zaman ayrılacağına ve "eşsiz bir kar tanesine” dönüşeceğine iyi karar vermektir. Bu sebepler kararı haklı çıkaracak kadar ciddi midir? Çoğu bu ayrılma maliyetini hafife almakta ve üzerine yeterince düşünmemektedir.

Omakase menü

• Bir restorana gittiğinizde neyi sececeğinize karar veremediğiniz olmuştur. “Şefin” sizin için bir tercih yapmasına izin verirseniz “iyinin” ne olduğunu anlamaya başlamadan muhtemelen iyi bir yemek yiyeceksinizdir. İşte Omakase tam da bu demektir: İşi mutfaktaki uzmanına bırakmak. • Programcı için bunun avantajı başkasının sizin yapılandırmalarınızı rahatlıkla kavrayabilmesidir. Bu bakış uygulamayı oluştururken bireysel kararlar alma geleneğinin karşıtı bir görüştür. • CoC bireysel araçları en iyi nasıl kullanmamız gerektiğine dayanırken, “omakase" hangi araçların nasıl birlikte olması gerektiği ile ilgilidir.

• Rails’de bir kişinin araç kutusunda her bir aracı seçmek için bireysel tercihleri kısıtlamaya gidilmiştir; • Bir çok kişi Rails’i aynı yollarla kullandığı için ortak bir deneyime sahip olmaktadırlar. • Yazılımdaki çoğu problem bireysel bileşenlerden değil etkileşimden kaynaklanmaktadır. Rails bu etkileşimler üzerine odaklanarak çıkan hatalara ortak sorunlara çözüm üretmektedir. • Rails bir Omakase yığını olsa da belirli çerçeve veya kütüphaneleri değiştirmenize olanak sağlamaktadır. • Rails’e gelen en deneyimli programcılar bile omakase menü sorunlarına itiraz etmezler ancak alternatifleri titizlikle seçerek toplulukla paylaşmakta ve neyi nasıl yer değiştireceklerine karar vermektedirler.

Tek bir paradigma yok

• Rails’de mimarinin temelini oluşturan tek bir kural bütünü bulunmamaktadır. • Rails pek çok farklı fikir ve paradigmaya ev sahipliği yapmaktadır. Hatta bazılarının birbirleri ile çeliştiği de görünebilmektedir. • Varsayılan olarak MVC’yi ele aldığımızda ilk bakışta tek bir işlev kümesi gibi görünebilir. • Bu durum bazen görünüm çıktıları oluşturmak için daha fazla OOP yapma ihtiyacı duyulmadığı anlamına gelmez ancak bazen basit bir Presenter, bağımlılığı yüksek OOP çözümlere alternatif üretebilir. Nadiren de olsa.

• Bu kadar ideolojik açıdan esnek olması Rails’in bir çok şeyi çözmesine olanak tanımaktadır. Bireysel paradigmaların çoğu kendi alanında çok iyi iş çıkartmaktadır ancak kendi alanının ötesine uzanmaya çalıştığınızda zorlanacaktır. • Çakışan bir çok farklı paradigmayı uygulayarak Rails yan ve ön saflarını korurken kendi çekirdeğine bireysel pradigma ve çözümleri dahil etmeyecek kadar güçlü ve işlevseldir. • Bu kadar çok paradigma ve ilişkiyi bilmenin maliyeti programcıya kavramsal bir yük getirmektedir. Rails ile iyi vakit geçimek için için sadece OOP tek başına bilmek yeterli olmamaktadır. • Öğrenme bir engel olarak değil bir çeşitlilik ve sevinç kaynağı olarak kabul edilmelidir. • Bu öğrenme yükünü hafifletmenin bir yolu da yanlızca projeye hızlıca başlamaktan geçer. Evet Rails hızlıca başlamada çok iyidir.

Güzel kodu yücelt

• Rails’de sadece bilgisayar ve programcılar tarafından anlaşılacak kod yazılmamakta, estetik açıdan doyurucu ve kendine özgü bir kod çıktısı sağlanmaktadır. Elbette ki kodun güzel olması diğer kaygılardan daha fazla öne çıkmamaktadır. • Peki güzel kod nedir? Ruby doğal yöntemleri ile tüm diğer DSL’in kesiştiği özel bir yerdir. • Aşağıda ActiveRecord için bir örnek yer almaktadır; class Project < ApplicationRecord belongs_to :account has_many :participants, class_name: 'Person' validates_presence_of :name end • Yukarıdaki kod bir DSL’e benzemektedir ancak aslında temelde Ruby işlevlerini kullanmaktadır. Çok güzel, basit ve sade bir kod bloğudur. Ne yapmak istediği açıkça ifade edilmektedir. • Veri tabanı yapıları oluşturma için başka bir örnek; class CreateAccounts < ActiveRecord::Migration def change create_table :accounts do |t| t.integer :queenbee_id t.timestamps end end end

• Bu örneklerde de görüldüğü gibi programcıya yazmak için çok az kod bırakılmaktadır. Örneğin migration kodu aynı zamanda tabloyu oluşturmak, kaldırmak, düzenlemek gibi bir çok işlevi içerisinde barındırmaktadır. • Bazen güzel kodlar daha kısa olabilir. Örneğin; if people.include? person if person.in? people • Yukarıdaki örnekte, akış ve odak arasındaki fark gösterilmektedir. İlkinde koleksiyona odaklanılırken ikincide konu kişidir. İkincisi daha çok gülümestiyor değil mi :)

Keskin bıçaklar sağla

• Ruby kazayla değil tasarım gereği içerisinde çok fazla keskin bıçak bulundurarak size varolan sınıf ve yöntemleri değiştirme gücü sunar. • Bu durum bir çok programcı için tehlikelidir ve ölümcül sonuçlar doğurabilir. • Ruby’de bu tarz tehlikeli bıçakları kullanmayı engellemek için bir şey yoktur ancak bu araçların doğru bir şekilde kullanımının öğretilmesi mümkündür. Örnek olarak bir mutfaktaki tüm bıçakların kullanılması yasaklanarak insanlardan domatesi kaşıkla kesmeleri istenemez. • Bu esneklik 2.days.ago gibi güzel kodların oluşmasını sağladığında bir çok kişi bu bıçağın kendisine zarar vermesini göz ardı etmektedir. • Bu durum deneyimsiz programcıların mutfakta ellerini kesmelerine de sebep olmaktadır ancak öğrenme ve kendini geliştirerek usta birer “şef” olmalarının da önünü açmıştır. Bu durum yazılımcıların kendilerine olan güvenlerini de pekiştirmektedir.

• Rails’de bu tarz keskin bıçaklar Ruby’deki kadar çok olmasa da bulunmaktadır. • Rails’in bir çok özelliği “çok fazla özgürlük” olarak eleştirilse de bu araçları kullanarak (örneğin ActiveSupport) kullanıcılara faklı imkanlar sunmaktadır. • Keskin bıçakları kullanmayı öğrenmemiş programcılar henüz tam yeteneğe sahip olmasa da bir gün bu araçları kullanarak Ruby on Rails programcıları dahi olabilirler. • Ruby on Rails, şefler ve şef olmak isteyenler için bir ortam sunmaktadır. Yemekleri yemeye de başlayabilirsiniz, mutfakta çalışmaya da. Rails size her iki yolda da eşlik edecektir…

Katma değerli sistemler

• Rails bir çok farklı şekilde kullanılabilir. Ancak ana hedefi monolotik entegre sistemlerin oluşmasıdır. Javascript’ten, veri tabanı katmanına kadar tüm ihtiyaçlara yönelik bütünleşik bir sistemdir. • Bu yapıda elbette bir çok sorun olabilir ancak bunun aksine bir kişinin rahatlıkla herşeyi yapabilmesini sağlayacak yapıyı sunmaktadır. Tek bir uzman yada bir geliştirme takımının tam bir sistem oluşturması için özel olarak tasarlanmıştır. • Yapılacak çalışma zaman içinde bölünmeyi ve dağıtılmayı gerektiriyorsa, Rails bu bölünmeye de izin vermektedir ancak bunun yönetilmesi gereken bir çok küçük uygulama parcası olacağının unutulmaması gerekir. • Rails olarak benimsenen felsefe: Dağıtık bir sistemin tüm faydalarıyla mükemmel, basit, kullanışlı ve anlaşılır olarak tek bir entegre sisteme hizmet ediyor olmasını sağlamaktır.

İstikrar üzerinde ilerle

• Uygulamalar yıllar geçtikçe büyümektedir ancak bu durum geriye uyumluluk konusunda iyi tasarlanmış bir araç üzerine inşa edilmiş uygulamalarda büyük bir sorun oluşturabilir. • Rails belirli bir seviyede muhafazakar davranarak aynı zamanda yeniliklere de açık kalmayı başarmıştır. • Bu anlaşılması kolay ancak pratikte uygulaması zor bir kavramdır. Bazen eski sürümler ile yeni sürümlerin uyuşmadığı noktaların ortaya çıkması bu kadar büyük bir sistemde çok doğaldır. • Rails, Ruby’i en eski sürümlerinden beridir kullanmakta ve Ruby’de meydana gelen köklü değişikliklere adapte olarak gelişimine devam etmektedir. • İlerleme ve sürekli adaptasyon Rails topluluğunun gücünden ve ceşitliliğinden gelmektedir. Rails’in topluluğunu sürekli büyütmek ve çeşitlendirmek istemesinin sebebi budur.

Büyük bir çadır altında topla

• Rails ekosistemi bir çok farklı ideoloji ve düşünceye sahip kişiler tarafından benimsenmiş ve sürekli büyümektedir. • Bu çeşitlilik sayesinde sorunlara daha farklı açılardan bakarak daha özel çözümler üretebilme avantajını sunmaktadır. Bir özelliği uygulamadan önce üzerine tartışma ve değerlendirme imkanı sunarak en doğruyu bulmayı kolaylaştırır. • Burada örnek olarak Rails API’nin sisteme dahil edilmesi verilebilir. Kişisel olarak DHH tarafından karşı çıkılsa da topluluğun çeşitliliği sayesinde bu araç çekirdeğe alınmıştır. • Büyük bir çadıra sahip olmak herkesi bir partiye davet etmek ve kabul etmek gibidir. Davetliler kimi zaman “kendi içecekleri” ile de partiye gelebilir ve Rails topluluğu bunu ustalıkla kabul eder. • Rails bünyesindeki çok büyük ve çeşitlilik içeren topluluğu tek bir çadır altında toplamayı başarmıştır.

http://rubyonrails.org/doctrine/ The Rails Doctrine

Teşekkürler Soru-cevap Tayfun Öziş ERİKAN, Genel Koordinatör Lab2023 Bilişim Teknolojileri AŞ [email protected] - @toziserikan