So for the past month, I decided to learn Ruby and also its popular web framework, Ruby on Rails (or just “Rails”). The motivation behind this learning spree was the creation of my own website that I could use to help me study better (as a sort of drop-in replacement for MS Word for writing outlines of law school subjects). First, let me say that learning Ruby was great and really fun. However, Rails was really, to be honest, a pain in the @ss for pretty much everything.
I’m not going to go off on a long rant here (like what this ex-Rails core contributor did); instead, let me just point out some of the biggest weaknesses of Rails:
- Its documentation is pathetic. The Rails API doesn’t really mean anything to me–it’s just an index of every feature of Rails with short tidbits that are often sorely lacking in coherence. Or at least something that a newbie programmer like me can understand. And, I don’t know why, but the Rails community decided to put together a Wiki that is, at least for everything I was interested in, either obsolete, or poorly organized. It’s like reading a IRC chat log, except with prettified code blocks. Like this page.
- Somewhat related to #1, Rails has few, if any, tutorials that work. This is because Rails changes every 2 weeks. For some reason, every book I’ve used on Rails so far had to be modified by myself to work on my Windows XP box (I’d like to get into the world of Linux and open source operating systems more, but the last time I tried to install Ubuntu 7.04, it refused to work with my dual LCD monitor setup). And that means every time I want to do something–say, add a feature to my Rails app–I need to first google some vague description of it, and hope that someone on the Rails mailing list has it figured out. And about 75% of all useful tutorials on Rails seem to come from blogs. This gives me the impression that Rails developers don’t want to share clear, concise knowledge with other people in general. That’s why crappy sites like the Rails Wiki I mentioned above pops up in the top ten search results on google so often.
- Aside from horrible documentation and a sore lack of working tutorials, Rails seems hypnotized with its own mantra of “do everything in 20 minutes or less!”. By this I mean–so many articles about Rails are caught in the hysteria that it’s always better to write less lines of code, that it’s so great to do something in 5 minutes. There’s a common thread running through these tutorials/blog articles about Rails–they’re concerned first about quickly implementing something instead of creating something that is sturdy, reliable, and is general enough to work in a wide variety of situations. Usually, many of the Rails “solutions” or “recipes” that I encounter across the web while googling for Rails developer wisdom are too specialized to be of any use to anyone but themselves. If you’re going to share something with other people, it better be easily adaptable/changeable so that people can actually make use of it, and hey, perhaps make it better.
- In line with what I said in #3, I really despise how so many tutorials make use of Rails’s “scaffolding” feature. Good grief–I don’t want auto-generated code flying around in my Rails app to add just one little feature. You know what, I think the whole “scaffolding” feature is retarded. It’s only good if you want to create shit-looking websites that look as good as the tutorial’s scaffolded views. Seriously–do people really use scaffolding? I think it’s just a big joke–a marketing scheme. Scaffolding only lets you create something really fast–so that the Rails community can boast about development speed. And why is it that every tutorial out there on scaffolding is concerned about creating a weblog? With “Posts” and “Comments” as models? What if I don’t want to create a weblog? What then?
- Some features that should be really, really, really simple and built-into Rails don’t exist at all! For example, there is no simple way to upload files. Just google “rails upload files” and you will see. The answers do not converge to same/similar solutions. This is madness! Rails wasn’t built yesterday. It’s been several years since DHH became an international figure. And yet, all through that time, it has failed to create a simple feature that allows users to upload files to a basic Rails app! Also, did I mention that Rails migrations do NOT support the creation of MEDIUMBLOB/MEDIUMTEXT or LONGBLOB/LONGTEXT types in MySQL? Why? Why do I have to execute ugly SQL code inside my Rails migration files? Apparently, Rails likes to think that everything should be smaller than 64KB. What a joke!
That being said, I’ll still say that Rails has taught me a lot about web design and what it could be (my last foray into website design was in 2001 with pure HTML and Notepad). But it leaves a lot to be desired. I’ll keep playing around with Rails on my windows box for now, but my desire to learn the deeper intricacies of Rails has all but died out. The bad news is that Rails is the only heavily-developed framework out there based on Ruby–my favorite scripting language. Yes, I know of other alternatives like Merb, but bad documentation is better than no documentation (the only reason why I decided to learn Rails for what it was worth was because no other Ruby-based framework had a similar amount of documentation). And for the record, I did end up creating a decent website to suit my needs (a replacement for MS Word). But it could have been better, and more pleasurable, had it not been for the 5 annoying-as-hell points I listed above.
My advice to those wanting to learn a web framework is this: wait a couple years! Hopefully, either Rails or some other alternative will be mature enough to be easily digestible. But if you have countless hours to burn reading blogs and googling for things–you have my blessing.
UPDATE March 25, 2008: I see that people are visiting this blog for Rails tips (like what I was doing 3 months ago). If you want to learn Rails without the crappy feature called “scaffolding” that I ranted about above, try “Build Your Own Ruby Applications” by Patrick Lenz. It’s outdated, yes, and it has its share of typos, but once you get through at least the first few chapters (especially the ones where he builds from scratch how to make editable text input boxes and do the basic CRUD features on them), you should be able to make some basic but still functional (and not “scaffolded”–ugh) websites. The SitePoint publisher forum for this book is quite helpful for common typos, etc (Lenz even has a page dedicated to errata/corrections).The key is to copy code and modify them to your liking.
I also recommend the NetBeans IDE. It’s superb. Also, get the HAML ruby gem (which comes with SASS support), and the corresponding NetBeans HAML/SASS syntax highlighter (google it), and you’ll be on your way to some mad-quick development. HAML will save you quite a bit of typing–hours of typing in the long run (no closing tags!). Oh, and I highly recommend the FireBug Firefox extension if you don’t have it already. The SASS + FireBug duo is probably 10 ~ 15 times quicker than plain CSS editing (I can’t believe there are actually sites that still talk about CSS, when SASS is ultra fast for development (you could, if you want, use SASS for development only and just copy/paste the resulting CSS generated by SASS, statically, on your non-Rails sites).
Oh, and lastly, use XAMPP (or any other similar package). Why? No need to type in MySQL commands, if you’re using MySQL (like me, b/c to me it seems that MySQL has the most dominant presence right now). I worked through Lenz’s beginning chapters without typing in any unpalatable MySQL commands. 
Just use the phpMyAdmin web app that comes with XAMPP on localhost to browse through database entries and do CRUD operations on them with intuitive, easy mouse-clicks. (And since you’ll probably be using FireFox for phpMyAdmin, this means that you can keep your prototype Rails app on the tab next to it (and while you’re at it, a tab with FireBug enabled on another part of the site you’re fixing up, etc etc)).
And finally, if you’re NEW to Rails and am just starting out from almost no programming background (like how I was), DO NOT bother with creating unit tests, functional tests, or any other tests. It is a waste of time when you’re trying to create a simple, ultra basic web app for learning purposes. I cannot tell you how many hours I spent trying to fix typos in Lenz’s book (either that or the test code in the book was outdated by the time Rails 2.0 came around) to get every unit test to work. Besides, Rails by default will present you with EXACTLY where the source code encountered a problem. I still haven’t written tests for my app–but I made sure during development to try out bogus input and to purposely make my app break for every method I wrote. And now my app has reached a point where it hasn’t displayed any errors (or anomalies) for the past month or so of continued usage. It’s actually better this way, in my opinion, because you’re FIRST learning to write good, reliable code from the get-go, instead of getting into the mindset of (“I’ll just test it later”). Writing function tests are not easy (just look at Lenz’s book–he has like 30-something tests for his super basic web app… I mean, how does he know that he only needs 30, and not 31? Or 29? So to sum up: don’t bother with test code if you’re starting out in Rails. Get the “feel” of Rails down first, and how the app behaves/responds to input, and then implement tests if you wish (…to work as a Rails developer, that is, and not just as a hobby).
UPDATE April 25, 2008: OK, people are still visiting this page to find out about LONGTEXT/LONGBLOB types for migrations. Here is my SQL-command that I used for my migration (in the full context of my 001_create_articles.rb migration file:
class CreateArticles < ActiveRecord::Migration
def self.up
create_table :articles do |t|
t.string :title
# and some other stuff that look like t.text or t.string
# or whatever else
end # END create_table
execute 'ALTER TABLE articles ADD COLUMN body_text MEDIUMTEXT'
end # END self.up
def self.down
drop_table :articles
end
end # END class definition
You can replace mediumtext with longtext or longblob or anything else. The command above adds a new column called body_text to the articles table that already exists on the database.
UPDATE March 11, 2009: I don’t want to give out bad advice. I should have stated a long time ago that you should NOT use any IDE, even NetBeans. IDE’s and their GUIs and all that baggage slow you down a lot. Personally I use Vim, but any solid text editor should do.
