Kelemahan dan peringatan Ruby on Rails [ditutup]


25

Ini bukan langkah awal untuk memukul RoR - jujur!

Saya sedang belajar kerangka kerja Ruby dan Rails. Prima facie tampaknya cukup keren, dan pengalaman yang luar biasa dibandingkan dengan PHP. (Bahkan, ini mengingatkan saya pada hari-hari yang lebih bahagia dengan C # dan .NET.)

Namun, ketika membahas hal ini, saya tidak memiliki pengalaman dengan kerangka kerja atau bahasa ini, dan saya ingin tahu - apa kelemahan atau hal-hal saat ini yang ingin Anda ketahui ketika Anda mulai?

(Mungkin ini harus dijadikan komunitas wiki?)


Saya mencoba rel sekali dan berhenti ketika saya menyadari bahwa desain entitas database-pertama tidak mudah.
Falcon

5
avdi.org/devblog/2011/08/22/your-code-is-my-hell layak dibaca. Saya akan menambahkan bahwa dengan bahasa yang diketik secara dinamis, sangat penting untuk memiliki cakupan tes 80% atau lebih, atau refactoring akan hampir mustahil.
Eric Wilson

Menjadikan pertanyaan Anda lebih spesifik dan seimbang (yaitu, "Beralih dari PHP ke Ruby on Rails - Pro dan Kontra) akan menghapus kebutuhan untuk menolak diri Anda untuk melakukan bashing dan keinginan untuk wiki komunitas.
Thomas Langston

2
@ Thomas Tapi itu bukan pertanyaan saya! Pro dan kontra dari PHP sangat terkenal. Pro RoR cukup mudah ditemukan. Namun, kelemahan RoR tidak mudah ditemukan sebagai pendatang baru dan saya menduga mereka hanya akan ditemukan dengan pengalaman bertahun-tahun. Belajar dari pengalaman orang lain yang berpenghasilan tinggi adalah tujuan dari ini. Banyak CW yang saya baca cukup spesifik sifatnya.
Matty

Jawaban:


32

Ini dari pengalaman belajar, terus belajar, dan menulis aplikasi yang relatif sederhana di Rails.

1) Kurva Belajar

Rel itu tampak sederhana. Tutorial, video, dan buku semuanya menunjukkan seberapa cepat Anda bisa mendapatkan aplikasi yang berfungsi (jika jelek), tetapi ini benar-benar hanya menggores permukaan. Mereka cenderung sangat bergantung pada generasi kode dan "perancah" yang diakui adalah alat yang baik ketika belajar tetapi dengan cepat hidup lebih lama dari kegunaannya.

Jangan salah, Rails sulit dikuasai. Setelah Anda melewati dasar-dasarnya (lebih lanjut tentang ini nanti), Anda akan langsung menuju dinding jika Anda perlu melakukan lebih dari fungsi "aplikasi demo" yang sangat simpel yang Anda lihat disebut-sebut. Anda dapat bertahan dengan pengetahuan dasar tentang Ruby saat belajar, tetapi Anda harus segera mengambil Ruby atau Anda akan dibiarkan tinggi dan kering (dan bukan jenis yang baik DRY) jika Anda harus pergi ke luar batasan Rails.

Rails, seperti saya suka menyebutnya dengan cara yang penuh kasih, melukis dengan pemrograman angka . Jika Anda tetap 100% pada konvensi (yaitu tetap di dalam garis dan menggunakan warna yang Anda perintahkan), Anda dapat membuat aplikasi yang layak dengan cepat dan mudah. Jika dan ketika Anda harus menyimpang, Rails bisa pergi dari teman terbaik Anda ke musuh terburuk Anda.

2) Ketika Yang Anda Miliki Adalah Palu ...

Rails menjalankan aplikasi CRUD sederhana dengan sangat baik. Masalahnya muncul ketika aplikasi Anda harus melakukan lebih dari sekedar membaca / menulis dari database. Sekarang, sebagai catatan versi Rails terakhir yang saya gunakan adalah 2.3.4 sehingga hal-hal mungkin telah berubah sejak saat itu, tetapi saya mengalami masalah besar ketika persyaratan bisnis berubah sehingga aplikasi harus memiliki sistem alur kerja kecil yang dibangun di dalamnya, dan berintegrasi dengan aplikasi PHP warisan. Konvensi Rails dari "satu bentuk, satu model" berfungsi dengan baik untuk aplikasi sepele dan aplikasi entri data, tetapi tidak terlalu banyak ketika Anda perlu melakukan pemrosesan logika, atau memiliki alur kerja, atau apa pun yang tidak khas "Pengguna memasukkan data ke dalam beberapa bidang teks, klik Kirim "jenis hal. Itu bisa dilakukan, tetapi tidak berarti "mudah", atau lebih tepatnya tidak

Selain itu, Rails tidak suka bermain baik dengan aplikasi lain yang tidak menggunakan metode akses data yang disukai; jika Anda harus berinteraksi dengan aplikasi yang tidak memiliki API gaya "Web 2.0", Anda harus menggunakan Rails alih-alih menggunakannya; lagi saya berbicara dari pengalaman di sini karena inilah yang terjadi pada saya.

3) Ini Baru

Akhirnya, Rails masih menjadi "anak baru di blok" di banyak daerah. Ini tidak masalah untuk penggunaan pribadi atau jenis skenario "Saya pikir itu keren dan ingin mempelajarinya," tetapi berbicara sebagai seseorang yang lebih suka menggunakan Rails di pekerjaan saya, jika Anda tidak berada di lokasi di mana Rails berada luas, bisa jadi sangat sulit untuk menemukan pekerjaan penuh waktu sebagai pengembang Rails. Ini masih sebagian besar domain "pinggul, startup baru" dan bukan pemain utama di sebagian besar wilayah metropolitan. Jarak tempuh Anda mungkin berbeda dalam hal ini, tetapi saya tahu Rails area saya (Tampa) pada dasarnya tidak ada.

4) Api dan Gerak

Rails selalu berubah. Ini adalah hal yang baik dan buruk; itu baik karena komunitas berevolusi dan merangkul konsep-konsep baru. Itu buruk karena komunitas berevolusi dan merangkul konsep-konsep baru. Ini bisa sangat luar biasa bagi pemula Rails karena biasanya ketika Anda mengalami masalah, dan melihat-lihat, Anda akan melihat salah satu orang merekomendasikan permata ini-dan-itu untuk memperbaikinya, atau mengatakan bahwa cara itu buruk dan Anda tidak seharusnya melakukannya. t menggunakannya, inilah cara yang lebih baik ... dan Anda akhirnya memiliki daftar cucian alat tambahan untuk belajar bersama dengan Rails untuk mengikuti kognitif Rails. Hal seperti Git, BDD/RSpec, Cucumber,Haml/Sass, dan banyak hal lainnya semuanya melayang dan didorong sebagai "cara yang tepat untuk melakukan sesuatu" di Rails-land, dan berbicara dari pengalaman Anda mungkin akan dibanjiri dengan mencoba mempelajari selusin atau lebih teknologi selain Rails, karena menggunakan toolkit Rails standar terasa "salah".

Ini sekarang semakin diperparah oleh Rails 3.1 menjadikan Sass dan CoffeeScript dari semua hal sebagai default, sehingga pemula total Rails tidak hanya harus belajar Ruby dan Rails tetapi Sass (bisa dibilang sederhana jika Anda tahu CSS) dan CoffeeScript (tidak gila sulit tapi pasti cukup berbeda dari JavaScript mentah) minimal untuk memulai, plus itu dapat diasumsikan Git. Bahkan tanpa memperhitungkan RSpec dan teman-teman, dan selusin permata yang biasanya Anda dapatkan, itu adalah 4 hal berbeda yang harus Anda pelajari sebelum Anda serius dapat mulai menulis aplikasi Rails. Bandingkan ini dengan bahasa seperti C #, atau Java, atau bahkan PHP di mana pengetahuan HTML / CSS / JavaScript / SQL Anda tidak akan berubah dan Anda hanya perlu mempelajari bahasa itu sendiri dan mungkin nuansa kerangka kerja.


3
WRT Rails 3.1 Sass & CoffeeScript adalah default yang dapat dengan mudah dimatikan. Faktanya, CSS "normal" hanya akan berfungsi karena Rails 3.1 menggunakan sintaks SCSS dari SASS. Anda bisa menggunakannya tetapi Anda tidak berada di bawah paksaan apa pun. WRT Git Saya pikir Linus menjelaskan lebih baik mengapa Anda benar-benar harus menggunakan DVCS seperti Git, terlepas dari kerangka apa yang Anda gunakan. youtube.com/watch?v=4XpnKHJAok8
Shreyas Satish

Oh saya setuju, hanya mengatakan bahwa standar Rails biasanya banyak hyped sehingga pemula akan merasa tertekan untuk menggunakannya (Saya tahu saya merasa seperti itu)
Wayne Molina

3
+1 untuk # 4 ... jika Anda meninggalkan Rails selama setahun, ketika Anda kembali semua orang akan terbang di sekitar dalam pesawat ruang angkasa dan Anda akan berada di perahu dayung Anda berpikir wtf? Sintaks Rails 2 terasa tua sebelum Rails 3 dirilis.
cacing gelang

-1 Pos bashing rel yang bagus tetapi Anda bahkan tidak menyarankan alternatif. "Bentuk bersarang" adalah masalah yang sulit dan Rails mungkin memecahkannya lebih baik daripada siapa pun.
scottschulthess

13

Dokumentasi.

Sementara Rails Guides adalah sumber belajar yang bagus, referensi perpustakaan Rails (dan Ruby, umumnya) tidak mudah dinavigasi. Katakanlah, Anda ingin mempelajari lebih lanjut tentang belongs_tometode. Meskipun digunakan pada ActiveRecord::Basesubclass (model seseorang), itu tidak didokumentasikan dalam ActiveRecord::Basedokumen, tetapi dalam campuran yang diimpor kelas. Pada dasarnya, Anda tidak dapat melihat daftar lengkap dari semua metode yang dapat Anda gunakan pada suatu objek di satu tempat (kecuali ketika Anda menyalakan irbdan memeriksa objek itu sendiri).

Dengan bahasa yang sangat dinamis seperti Ruby, tidak mudah untuk mengetahui dari mana metode yang Anda gunakan berasal. Ini bisa menjadi masalah, terutama bagi pemrogram belajar yang mencoba memahami teknologi baru.


Ini adalah pembunuh bagiku; setiap kali saya perlu men-debug beberapa kode Ruby / Rails kami, saya selalu menghabiskan terlalu banyak waktu untuk mencari tahu di mana metode yang diberikan didefinisikan; dan bahkan kemudian, selalu harus menyimpan ide di belakang kepala saya bahwa hanya karena saya dapat melihat definisi metode, itu mungkin telah didefinisikan ulang di tempat lain.
joev

9

Ruby on Rails memiliki kurva belajar yang signifikan. Pertama, Anda harus mempelajari keanehan bahasa, kemudian mempelajari kerangka, kemudian mempelajari Cara Rails dalam melakukan sesuatu, kemudian mempelajari tentang banyak Permata yang umum digunakan.

Namun, ketika Anda telah mempelajari hal-hal itu, itu memang terjadi secara alami. Bahkan kerangka kerja lain mulai terasa seperti beban.

Rails sangat berorientasi pada TDD / BDD, jadi jika Anda tidak melakukannya maka itu dua hal lagi yang harus Anda pelajari sebelum Anda menjadi programmer Rails yang kompeten. Anda tidak memiliki kompiler dan IDE untuk mendukung Anda, jadi cakupan pengujian sangat membantu Anda.

Banyak pendukung TDD, termasuk saya, akan menganggap ini salah satu kekuatan RoR, serta kutukannya. Setelah Anda mulai menulis TDD, Anda menemukan bahwa keamanan yang ditawarkan oleh cakupan tes lebih baik daripada keamanan yang ditawarkan oleh kompiler. Maka harus menulis kode HANYA untuk menyenangkan seorang kompiler menjadi beban.

TDD tidak terasa seperti tugas tambahan dalam RoR, rasanya seperti satu-satunya cara untuk bekerja.

Rails memiliki satu masalah kinerja yang serius: setiap permintaan diantrekan di belakang yang sedang aktif, sebagai kebalikan dari threading seperti yang dilakukan sebagian besar kerangka kerja atau memungkinkan pemblokiran acara untuk membebaskan permintaan lain seperti yang dilakukan Node.js dan Twister. Ini berarti Anda harus membuat kode untuk membuat waktu respons cepat, tetapi itu cukup mudah dilakukan dalam kebanyakan kasus.

Rails juga sangat dirancang untuk menangani sistem konten dengan sangat baik, yang pada kenyataannya adalah banyak internet. Melakukan sesuatu yang sedikit lebih rumit, seperti permainan web atau sistem e-commerce, berarti mempelajari permata baru. Anda dengan cepat mengetahui bahwa semua permata ada di sana, tetapi semakin tidak jelas hal yang ingin Anda lakukan, semakin sulit untuk menemukan dokumentasi yang baik.


Mengenai masalah kinerja - Saya sepertinya ingat pernah membaca bahwa banyak dari masalah itu sebagian besar telah diselesaikan dengan v1.9 penerjemah, tetapi saya bisa salah total. Apakah ada cara untuk mengatasi batasan kinerja ini?
Matty

1
@Matty: Seperti yang saya tambahkan, kode untuk membuat waktu respons secepat mungkin. Apa pun yang bisa dibiarkan menjadi proses backend, lakukanlah. Tapi kemudian Anda harus melakukannya dengan kerangka kerja apa pun - mudah saja tidak. Juga, jRuby di utas secara berbeda, tetapi ia datang dengan masalah sendiri dan jawaban saya sudah cukup lama.
pdr

7

Dalam pengalaman pribadi saya, sakit kepala utama adalah tentang kompatibilitas .

Kapan:

  • ada xproyek rel dikerahkan,
  • setiap proyek menggunakan ypermata.
  • sementara ada nversi rel,
  • mversi plus permata diinstal,
  • dengan severalversi ruby,
  • pada satu kotak Linux sebagai mesin produksi.
  • programmer bekerja pada notebook pengembangan OS X lain.

Sebagai freelancer, yang tidak memiliki kemewahan untuk update / meng-upgrade sebagian besar hal-hal, akan menghadapi banyak masalah kompatibilitas dari variabel di atas ... sementara rails, gemsdan rubyterus berubah / berkembang.


7
Semua yang Anda sebutkan diperbaiki dengan menggunakan RVM (atau rbenv ) dan Bundler . Anda dapat memiliki versi Ruby tertentu dan set permata terisolasi untuk setiap proyek.
Ashley Williams

Jawaban ini (sekarang) sama sekali tidak relevan. RVM untuk mengelola versi Ruby, Bundler untuk menangani versi permata; Capistrano untuk menangani penyebaran ke server produksi dan Figaro menangani variabel rahasia aplikasi / lingkungan. Saya mengembangkan aplikasi saya di [Cloud9] (c9.io) (IDE web), dan proses penyebaran saya secara harfiah bundle exec cap production deploy. Capistrano menangani versi aplikasi di server. Seperti kerangka kerja lain yang muncul (mis. Node.js), alat ditulis untuk memecahkan masalah Anda .
Chris Cirefice

5

Kecepatan jelas merupakan masalah. Fleksibilitas ekstrim Ruby hadir dengan hit kinerja yang signifikan.

Penskalaan secara horizontal adalah tugas yang tidak jelas, kecuali untuk teknologi yang dirancang khusus untuk tugas itu, yang biasanya menukar kesederhanaan dengan skala dengan baik.
Jika Anda dapat menangani 100 kali lebih banyak permintaan per mesin dengan teknologi A daripada dengan teknologi B, menggunakan teknologi A patut dipertimbangkan jika Anda memiliki alasan untuk percaya bahwa Anda dapat menayangkan data dari satu server untuk jangka waktu yang memungkinkan Anda menambahkan paralelisasi sesudahnya.
Pada tahun 2009 stackoverflow masih dilayani dari satu server web . Tentu saja ini bukan lagi pilihan. Tapi saya kira itu baik mereka mulai dengan teknologi, yang dapat meningkatkan banyak pengguna pada satu contoh, sebelum mereka harus khawatir tentang scaling out.

Dibandingkan dengan itu, RoR sangat lambat. Waktu untuk menangani permintaan sederhana sangat penting dan oleh karena itu merupakan masalah untuk menangani banyak klien (ini semua harus dilihat dalam kaitannya dengan alternatif yang lebih cepat).

Demi orientasi yang tidak jelas, berikut adalah beberapa angka, membandingkan berbagai bahasa lain yang cocok untuk pengembangan web dengan Ruby:

  • Pergi
  • Clojure
  • JavaScript V8 ( node.js )
  • JRuby (alternatif yang tidak akan dilupakan - tergantung pada area masalah Anda JRuby mungkin merupakan pilihan yang lebih baik atau lebih buruk untuk mendapatkan beberapa kecepatan keluar dari aplikasi rel)
  • Scala
  • Jawa
  • C #

Perhatikan bahwa ini tidak berarti, bahwa jika Anda menggunakan framework X untuk Java, itu akan menjadi 200 kali lebih cepat dari RoR. Tetapi perbedaan kecepatan yang diukur dalam tolok ukur ini memiliki dampak penting pada keseluruhan kinerja aplikasi Anda.


4
Jawaban ini hanya berbicara tentang "kecepatan" saat runtime. Ruby (dan Rails) dioptimalkan untuk kecepatan pengembangan.
Nicolai Reuschling

5
Ini bukan perbandingan yang bagus. Sebagian besar waktu yang dihabiskan dalam permintaan web adalah melakukan I / O dari database. Menautkan ke tolok ukur intensif-CPU menyesatkan.
ryeguy

3
@ pdr: Banyak masalah twitter adalah mereka menggunakan ruby ​​untuk semuanya , bahkan proses backend mereka yang sangat intensif. Area seperti itu adalah bahasa yang diketik secara statis. Mereka menggunakan Scala untuk itu sekarang. Jujur saya, sungguh, percaya bahwa menggunakan RoR jauh lebih cepat dalam hal waktu pengembangan daripada C # atau Java. Saya akan menggunakannya untuk sebagian besar aplikasi web, dan kemudian menggunakan C # atau Scala untuk pekerjaan latar belakang cpu intensif.
ryeguy

3
+1, untuk poin yang valid. Yang sedang berkata, Anda dapat melakukan banyak hal untuk mengoptimalkan aplikasi Rails. Rack menjadikan dirinya sebagai sistem yang agak dapat diperluas yang memungkinkan banyak fleksibilitas dalam bagaimana segala sesuatu dipanggil. Belum lagi, Ruby 1.9 lebih cepat, JRuby lebih cepat. Saya pribadi penggemar berat JRuby, bisa menggabungkan kekuatan JVM adalah kemenangan yang luar biasa (hanya berhati-hatilah dengan permata yang menggunakan pengecualian untuk kontrol aliran -> overhead besar)
Xorlev

2
@Nicolai Reuschling: Nilai apa yang ada di Ruby atau RoR yang "dioptimalkan untuk kecepatan pengembangan"? Dapatkah Anda memberikan diverifikasi , kuantitatif data yang bagaimana Ruby sebenarnya menyediakan kecepatan pengembangan lebih tinggi dari alternatif (Lift misalnya)? Yang lainnya hanyalah klaim batal. Juga, pertanyaan ini adalah tentang kerugian RoR . Kecepatan pengembangan yang tinggi adalah keuntungan dan dengan demikian di luar ruang lingkup pertanyaan ini. Performa runtime yang buruk ada dalam cakupan pertanyaan ini, karena ini adalah kelemahan.
back2dos

3

Rails memiliki satu masalah kinerja yang serius: setiap permintaan diantrekan di belakang yang sedang aktif, sebagai kebalikan dari threading seperti yang dilakukan sebagian besar kerangka kerja atau memungkinkan pemblokiran acara untuk membebaskan permintaan lain seperti yang dilakukan Node.js dan Twister. Ini berarti Anda harus membuat kode untuk membuat waktu respons cepat, tetapi itu cukup mudah dilakukan dalam kebanyakan kasus.

Saya pikir ini sangat salah arah. Anda dapat menjalankan Rails dalam mode multithreaded. Saat menjalankan dalam mode multithreaded, Anda hanya harus menggunakan pustaka IO yang melepaskan GIL (misalnya, permata 'mysql2') jika tidak menjadi hal yang sia-sia.

Jika Anda menggunakan jRuby, maka Anda bisa menjalankan proses rel tunggal dalam mode multithreaded dan sepenuhnya memanfaatkan semua daya CPU yang tersedia. Namun, jika Anda menggunakan MRI (Ruby 1.8.x atau 1.9.x), Anda harus menjalankan beberapa proses untuk dapat menggunakan CPU sepenuhnya, yang juga demikian halnya dengan node.js.


Pertanyaan klarifikasi di sini - apakah ada cara mudah untuk menemukan perpustakaan IO mana yang mengeluarkan GIL?
Matty

Saya pikir cara terbaik untuk mengetahuinya adalah dengan membandingkannya gist.github.com/35d4769d8c8c0dfafc56
Pratik Naik


Senang mendengar dari salah satu devs inti! Informasi ini tidak tercantum dalam dokumentasi apa pun, bukan? Agak membosankan (walaupun kegiatan yang menarik) untuk mulai menguji perpustakaan untuk mengetahui hal ini.
Matty

3
  • Rails memiliki banyak kenyamanan yang menyembunyikan kompleksitas dari Anda. (Asosiasi ActiveRecord, seluruh siklus validasi / penyimpanan, interpretasi data permintaan berdasarkan header yang disediakan) Saat Anda baru memulai, ini luar biasa. Ketika Anda tumbuh, Anda akan menemukan bahwa Anda mulai menyesuaikan aplikasi Anda dengan "cara Rails" dalam menangani berbagai hal - kadang-kadang ini baik, kadang-kadang ini tidak berbahaya, dan kadang-kadang itu sebenarnya berlawanan dengan hal yang Anda coba lakukan. Tidak semua tabel basis data harus dimodelkan sebagai objek, langkah validasi mungkin perlu terjadi di tempat lain, dll. Banyak programmer Rails menghindar dari tidak melawan kerangka kerja (yang biasanya bijak), tetapi efek jangka panjang dari ini adalah ... Anda akan membawa kebiasaan Rails bersama Anda ke tempat-tempat di mana mereka belum tentu diminta.

  • Komunitas memiliki kebiasaan menulis perangkat lunak yang disebut sebagai "sihir" - caching lib yang bekerja secara ajaib! I / O yang terjadi secara ajaib membuat Anda lebih cepat! Sihir ajaib! Apa yang biasanya terjadi di sini adalah bahwa API yang sangat menarik disediakan untuk solusi teknis yang kurang, dan Anda tertipu oleh contoh-contoh yang sangat cantik bahwa hal itu melakukan apa yang Anda inginkan, dan hanya kemudian menemukan bahwa itu mencakup solusi yang tidak lengkap. Siklus ini cukup konstan, dan Anda belajar untuk menggunakannya, tetapi Anda harus terbiasa dengan gagasan membaca banyak dan banyak kode yang Anda andalkan (hal yang baik!). Solusi sulap komunitas rel tidak hampir sama ajaibnya seperti yang README sarankan, kataku.

  • Akibat di atas: Semakin banyak Anda menggunakan Rails, semakin banyak Anda harus membaca sumbernya. Semakin baik Anda memahami kerangka kerja internal, semakin bahagia Anda dalam jangka panjang. Tidak benar-benar Rails spesifik dalam hal ini, tetapi saya hanya memberi tahu Anda dari pengalaman di sini. Nama-nama metode terkadang menjanjikan sesuatu yang sebenarnya tidak Anda dapatkan.

  • Kultus muatan adalah masalah dengan Rails, tapi itu mungkin benar di semua komunitas / kerangka kerja. Tampaknya lebih jelas (bagi saya) di Rails, dan karena itu cenderung memberikan tampilan generasi aneh ke kode Rails - saat Anda bekerja pada proyek Rails yang berbeda, Anda akan melihat kecenderungan tertentu yang cenderung mengkhianati periode waktu di mana mereka dibuat . Seperti yang bisa Anda tebak dari pernyataan itu, komunitas cenderung bergerak cukup cepat dalam mengadopsi solusi baru dan mencela yang lama. Anda harus benar-benar berada di atas berita Ruby Anda, hanya untuk memahami beberapa kode yang akan Anda alami setiap hari.

  • Secara umum, saya pikir masalah konkurensi data biasanya tidak ditangani dengan baik oleh komunitas - saat Anda mengembangkan aplikasi, ketika Anda mencapai titik di mana Anda perlu membuang data, mengembalikan perubahan fisik jarak jauh dan mengunci akses ke data, solusinya menjadi sedikit lebih tangan disetel, yang membuat beberapa hal Rails tampak bagus Anda mendapatkan semua berlumpur dengan kebutuhan teknis akurasi. Rails tidak menyelesaikan setiap masalah yang Anda miliki dengan aplikasi web, saya kira saya katakan, dan sementara pencipta tentu tidak memberitakan pesan itu, mudah untuk dibodohi dengan berpikir bahwa itu tersirat.


2

Tergantung pada bagaimana Anda melihatnya, kecepatan perubahan Rails mungkin atau mungkin tidak menjadi peringatan bagi Anda. Banyak hal berubah secara radikal dari tahun ke tahun karena semakin banyak yang tersedot dari solusi yang menyebalkan dan membutuhkan.

Namun, jika Anda sedang dalam pengembangan aktif, Anda akan merasakan denyut nadi ini.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.