Apa Manfaat Ruby on Rails? Setelah Dua Dekade Pemrograman, Saya Menggunakan Rails

Terkadang saya mendengar orang mengeluh tentang klien mereka, mengatakan bahwa mereka bersikeras menggunakan Rails, bahwa mereka memiliki terlalu banyak Kool Aid. Jika mereka adalah perekrut, mereka hampir merasa mual karena harus menemukan pengembang 'primadona' Ruby on Rails lagi. Kemudian mereka mengeluarkan sesuatu yang mirip dengan perbandingan bodoh yang luar biasa antara Git dan PHP ini untuk membuktikan pendapat mereka. “Mereka bahkan tidak tahu apa yang mereka minta,” kata mereka.

Bagi kami sebagai programmer, terkadang memang terlihat seperti klien kami tidak memiliki petunjuk. Kami senang membesar-besarkan kasus seperti ini. Ketika Anda sedikit memikirkannya, sepertinya tidak benar untuk berpikir bahwa seseorang yang memberi saya uang untuk membangun sesuatu entah bagaimana terbatas dan 'tidak mengerti'. Faktanya, saya percaya bahwa sebagian besar klien mengetahui pilihan mereka dengan baik, namun mereka masih memutuskan untuk menggunakan Rails.

Saya akan mencoba menjelaskan apa, menurut pendapat saya, yang membuat Rails cukup bermanfaat untuk dipertimbangkan secara serius untuk sejumlah besar proyek dan kebutuhan.

Manfaat Ruby

Mungkin saja tidak ada yang tahu tentang manfaat Ruby jika bukan karena Rails itu sendiri. Beberapa orang suka meremehkan Ruby dengan mengatakan bahwa "sangat mudah bagi Ruby" dengan "ksatria berbaju zirah yang disebut Rails" dan bahwa tanpa Rails, "Ruby tidak akan relevan". Saya tidak bisa mengatakan dengan pasti apakah itu benar atau tidak, tetapi saya tahu bahwa akan sangat disayangkan jika dunia melewatkan bahasa yang luar biasa ini. Faktanya adalah: penulis Rails memilih Ruby dengan sengaja, dan taruhan 'liar'-nya terbayar dengan bunga yang sangat besar. Apa yang dia lihat saat itu, banyak orang lain bisa lihat hari ini. Ruby entah bagaimana memungkinkan pemrogram dengan cara khusus yang sangat sulit untuk dijelaskan kepada 'massa yang tidak bersih'. Jadi, mengapa menggunakan Ruby on Rails? Ruby membuat programmer senang, seperti yang diiklankan.

Sementara sebagian besar pengembang setuju bahwa Ruby berguna, beberapa melihatnya terlalu banyak . Mereka khawatir tentang apa yang mungkin terjadi dengan semua kebebasan yang diberikan Ruby, semua potensi penyalahgunaan. Mari saya ilustrasikan dengan beberapa patch monyet:

 "1".to_i #=> 1 class String def to_i raise 'foobar' end end "1".to_i #=> RuntimeError: foobar

Semudah itu: hanya dengan lima baris kode, kami telah mengambil kelas yang ada dan mengganti perilakunya. Tidak ada yang suci–bahkan sebuah String pun tidak. Kesalahan khusus ini akan mudah dikenali, tetapi hal-hal bisa menjadi jauh lebih menyeramkan:

 class String def to_i self.to_f - 1.13 end end "2".to_i #=> 0.8700000000000001

Sama seperti itu, kami telah memperkenalkan kesalahan ke dalam kelas String yang dapat dibungkus dan dikaburkan oleh lapisan demi lapisan kompleksitas.

Jadi, Anda mungkin berpikir: Bisakah semua orang dan ibu mereka mengacaukan lamaran saya yang berharga? Meskipun perilaku ini memang terlihat menakutkan—sebenarnya tidak. Dalam lima tahun menggunakan Ruby, saya sama sekali tidak memiliki masalah dengan perilaku ini. Ini mungkin tampak berlawanan dengan intuisi, tetapi sekali lagi, mengemudi mobil dengan kecepatan 60 MPH dalam arah berlawanan hanya dipisahkan oleh garis putih tipis di tengah jalan. Dalam praktiknya, keduanya bekerja dengan sangat baik.

Manfaat lain adalah bahwa Ruby adalah alat yang serbaguna. Dengan demikian, ia memiliki ujung yang tajam seperti pisau. Saya suka berpikir bahwa orang dewasa dapat menangani pisau dengan baik – pemeriksaan anak adalah untuk, yah, anak-anak (Tweet). Dan diperlakukan seperti anak kecil di TI membuat Anda menjadi korban paradoks Blub Paul Graham: Anda pikir Anda lebih baik tanpa fitur tertentu yang tidak Anda pahami atau seseorang yang mengatakan bahwa Anda terlalu berbahaya. Tentu saja, hari ini kita bertanya “mengapa menggunakan Ruby on Rails”; jadi, ini adalah perdebatan untuk lain waktu. Memang, Ruby melewatkan beberapa fitur yang dimiliki bahasa lain (Lisp hmm, hmm). Secara keseluruhan, Ruby dekat dengan puncak 'kesinambungan kekuatan bahasa'.

Beberapa tahun pertama saya dengan Ruby sangat rendah hati. Saya belajar banyak hanya dari membaca kode orang lain. Terkadang, saya kagum; kadang-kadang, saya marah; tetapi akhirnya, pengetahuan ini memungkinkan saya untuk berkomunikasi dengan komputer saya jauh lebih efektif daripada sebelumnya. Saya hampir merasa kasihan pada beberapa bahasa 'pita merah' lain yang membuat Anda melompati rintangan hanya demi melompatinya, sambil memberi tahu Anda "Saya hanya melakukan yang terbaik untuk Anda, itu untuk kebaikan Anda sendiri!"

Pragmatisme

Ada rasa hormat yang mendalam terhadap pragmatisme yang dirajut ke dalam DNA Rails pada tingkat serendah mungkin. Dikombinasikan dengan manfaat Ruby, pragmatisme ini menghasilkan solusi yang elegan dan mendorong/mengilhami komunitas pengembangan Ruby on Rails untuk melakukan hal yang sama. Pragmatisme sering diiklankan sebagai tenda Rails, jadi klaim ini bukanlah hal baru, tetapi saya diingatkan akan kebenarannya baru-baru ini ketika seorang teman saya mencoba menunjukkan betapa "keren" Hibernate sebenarnya. Dia sedang berjuang. Saya bisa merasakan rasa sakitnya karena dia tidak dapat mengatur segudang opsi dan parameter konfigurasi yang seharusnya menjadi default kerangka kerja sejak awal.

Seiring bertambahnya usia, standar saya untuk kompleksitas buatan telah tumbuh lebih tinggi dan lebih tinggi. Menimbang bahwa saya mulai menulis kode produksi pada tahun 1989 pada usia 11 (dimulai dengan proyek untuk tetangga sebelah saya di Clipper Summer '87), saya hampir tidak menoleransi komplikasi yang tidak perlu. Dan nilai Rails sangat tinggi di departemen itu. Ini lebih dari sekadar 'konvensi atas konfigurasi'; Saya berbicara tentang seluruh pola pikir pragmatis yang sangat dihargai di dalam dan meresap melalui komunitas Rails.

Ekspresi

Rails sedekat mungkin dengan bahasa Inggris (kecuali jika Anda menggunakan COBOL). Ia menggunakan apa yang dikenal sebagai DSL internal, memperluas Ruby dengan semantiknya sendiri. Membangun DSL selalu berbahaya karena Anda secara efektif mengembangkan bahasa baru. Karena bersifat internal, Anda tidak perlu menggunakan parser eksternal, tetapi dalam artian terasa seperti bahasa baru. Tim Rails mencapai keseimbangan yang baik dengan DSL-nya, menggunakannya di tempat yang masuk akal dan jarang berlebihan, menunjukkan pengendalian diri yang sangat baik. Saya pikir programmer mana pun, terlepas dari pengalaman Rails, (dan bahkan beberapa non-programmer) dapat memahami ini:

 class User < ActiveRecord::Base devise :database_authenticatable, :registerable validates_numericality_of :years_of_experience, :allow_blank => true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => "240x240>"} has_attached_file :cv ...

Sebenarnya, jika Anda tidak terbiasa dengan Ruby, ini mungkin terlihat aneh—hampir seolah-olah ini bukan bahasa pemrograman. Setelah Anda menyadari bahwa itu hanya pemanggilan metode tanpa tanda kurung, Anda siap melakukannya. Namun, Rails DSL terasa seperti bahasa khusus ini untuk menjelaskan persyaratan padahal sebenarnya itu hanya penamaan yang cerdas dan penggunaan sintaksis Ruby yang sangat baik.

Masyarakat

Rails memiliki pasukan pembuat komitmen yang memastikannya tetap dalam kondisi prima. Banyak proyek membara seiring bertambahnya usia, namun dengan Rails, percikan masih terbang ketika keputusan perlu dibuat. Rasanya seperti pengelola (masih) benar-benar peduli dan ingin orang menggunakan Ruby on Rails dan memahami manfaatnya.

Di bawah Rails itu sendiri, sebagai ceri di atas, berdiri Ruby dengan manajer paket yang tangguh, RubyGems, sebanding dengan CPAN dalam hal jumlah paket-dan mempertimbangkan usia CPAN, klaim itu (secara halus) sangat mengesankan. Rails mengalami kegagalan singkat ketika mencoba membuat "plugin Rails" sendiri. Untungnya, ini tidak bertahan, jadi RubyGems tetap menjadi sumber terpadu dan luar biasa untuk kode yang diprogram oleh individu yang sangat cerdas.

Sinergi antara bahasa yang keren, kerangka kerja web pragmatis, dan komunitas yang luar biasa memberi Rails hasil yang jauh lebih baik daripada jumlah bagian-bagiannya.

Kematangan

Rel telah ada di sekitar blok. Dalam gaya hipster, itu bahkan tidak keren lagi. Ini adalah hal yang baik dalam memilih tumpukan teknologi: Anda menginginkan sesuatu yang terbukti. Dan Rails hanya itu. Kami baru-baru ini menulis sebuah artikel yang berbicara tentang berbagai macam interpreter dan runtime Ruby yang sekarang tersedia.

Pemasaran

Saya tahu saya tahu. Sebagai seorang profesional IT, saya harus benar-benar menghargai hal-hal 'serius' dan mengabaikan 'glitter' . Ini mungkin tampak dangkal, tetapi mari kita hadapi itu:

1. Dibandingkan dengan kompetisi, situs Rails terlihat bagus .
2. Pemeran layar pertama Rails, pada hari itu, benar-benar menakjubkan. Ini mungkin tidak terlihat mengesankan hari ini, tapi ingat bahwa satu-satunya alasan kita semua tahu tentang Java adalah bahwa semua orang begitu bersemangat tentang kemungkinan menjalankan Applet Java di browser. Ini ternyata tidak terlalu penting, tapi tetap saja, ini menempatkan Java di radar. Demikian pula, screencast mesin blog 15 menit ini menjadi hit besar yang membuat banyak orang bersemangat.

Ini bahkan bukan tentang kesombongan; ini tentang melibatkan sebanyak mungkin orang pintar untuk memasukkan air ke dalam penggilingan. Ketika kerangka kerja dipertimbangkan, tempat terbaik adalah di keramaian. Memilih kerangka kerja yang menjadi fokus orang-orang pintar ini berarti bahwa lebih banyak landasan sudah tercakup untuk Anda. Dan ini membawa saya ke poin saya berikutnya.

(Tidak) Menemukan Kembali Roda

Saya memiliki titik lemah untuk kerangka kerja kecil. Saya suka ketika saya dapat memahami apa yang dilakukan kerangka kerja tertentu dan mengapa. Dalam hal ini, Rails agak membengkak, dan bahkan terkadang berlebihan.

Dilema di sini: berapa kali Anda ingin menulis hal yang sama berulang-ulang? Beberapa di antaranya dapat ditulis ulang dengan lebih baik, saya yakin, tetapi itu membutuhkan waktu—banyak waktu. Semakin banyak Anda mengizinkan Rails melakukannya untuk Anda, semakin sedikit Anda harus khawatir tentang menulis ulang atau mengimplementasikan kembali fungsionalitas Anda.

Rel adalah (seperti yang mereka katakan) 'termasuk baterai'. Ini bukan hal yang baik jika Anda tertarik pada sparsity atau jika Anda merasa perlu memiliki pengetahuan luas tentang cara kerja semuanya. Dalam praktiknya, jika Anda melepaskan ketakutan Anda, itu tampaknya berhasil. Rails memiliki default yang masuk akal untuk hampir semua yang Anda butuhkan dan cukup modular untuk menghindari memojokkan Anda ke tempat yang sempit.

Kesimpulan

Tanyakan pada diri Anda lagi, mengapa menggunakan Ruby on Rails? Rails cocok untuk situs web publik canggih yang bersaing dengan aplikasi JavaScript Halaman Tunggal, dan aplikasi sistem inti perusahaan yang kompleks yang biasanya terlihat sedikit 'lebih jelek' (dengan UI fidelitas yang lebih umum dan lebih rendah), tetapi mengimbangi ini bernoda dengan banyak aturan dan logika bisnis yang rumit. Manfaatnya adalah serbaguna dan mampu bersaing dengan yang ramping dan kuat.

Untuk sebagian besar masalah umum, Rails memiliki komponen siap pakai dengan dokumentasi yang secara konsisten di atas rata-rata (entah bagaimana, tim inti Rails meyakinkan kontributor bahwa menulis dokumentasi itu keren (walaupun kita semua tahu itu tidak), mengarah ke dokumen yang ditulis dengan baik, ringkas, dan menghemat waktu).

Saat Anda mengesampingkan unicorn dan pelukan Jumat, Anda akan mendapatkan kerangka kerja yang hebat yang dapat Anda gunakan baik untuk pengubah permainan masa depan Anda dan situs bisnis tengah jalan Anda berikutnya. Dan dengan kumpulan permata top-of-the-line Anda, Anda memiliki gudang senjata yang mengimplementasikan beberapa ide paling cemerlang dalam pemrograman komputer. Dengan tidak ribut-ribut.