I spent my evenings on learning Rails through this fine tutorial by Michael Hartl. (Miklós, thanks for recommending it.) I really enjoyed doing some web development again. Gosh, it changed so much during the last five years!
1. What can you learn from this tutorial?
So I spent my free time on this tutorial. What did I get out of this? That probably doesn’t matter for you. What could you get out of it?
Well, it teaches you a bit of everything: pure ruby, RSpec, Capybara, CSS (with bootstrap), SQL, HTML. It’s suitable for beginners so it’ easy to follow. OK, sometimes there’s a bit too much explanation – if you are already a professional programmer. Let it be the worst of your worries.
The single most useful thing about this tutorial is that it gives you keyboard-time with rails. Although you could copy-paste its code fragments into your editor I recommend not to do so. I think that the typing itself forces your brain to think about the details so you are more likely to remember stuff. Moreover, trying to find and fix typo errors is also a great learning opportunity. Finding your way to test and verify your ideas about what happens in rails is invaluable. E.g. it’s my second nature now to write spike-code into the rails console just to see why a test fails.
The asset pipeline
The single most important gotcha was how Rails organizes the View items. The asset pipeline is a genius solution for generating HTML with other dynamic content. Using nothing but plain erb is genius too. Automatically finding partials by their name and assigning them variables – that’s really simple. It’s like JSP scriptlets on steroids. Well, in the Java world folks don’t like scriptlets – maybe they even don’t know why.
A little discipline helps us writing maintainable JSP with scriptlets. However, some of the standard JSTL libs are, by design totally messed up. (Hello, JSTL SQL!). Since you can provide your own taglibs you can provide more sophisticated ways for abusing your webapp. More on this scriptlet-JSTL thing here.
The second most important thing was that Michael Hartl wrote this tutorial in a Test First fashion. Although some of these first tests require preliminary knowledge on the implementation, writing tests first is a Good Thing. It (looks) simple and its benefits are innumerable. Check the 8th Light blog for further explanation.
2. Is it really so easy?
Of course, not.
When skimming the tutorial, one could say, ‘Hey, this is easy! You just add respond_with, and now you have ajax responses! Moreover, writing RSpec with Capybara is just like writing English sentences.’
They might be easy to read, however, they aren’t that easy to write. Each of the tools, like Ruby, Rails and Capybara has a very rich vocabulary. It’s the Ruby syntax that makes them easy to read. Nevertheless, they all have their tricky parts. This tutorial is to Rails the same as a five-minutes trailer for a weekly TV show: it demonstrates what’s it going to be like when you already master the techniques. But, it’ll take much more than that five minutes.
For now I have more questions than answers. I know how to create certain type of DB migration with Rails (and Google). I also know how to create one-to-many and many-to-many relations. How Rails handles the HTTP session is still unclear to me. I don’t know either how to write low-level unit test with RSpec (or with any other tool in the ruby ecosystem).
3. What did I not learn yet?
I’ll ask tons of questions here. These are the questions that Hartls tutorial don’t answer. Of course it doesn’t have to: it’s a beginners tutorial to Rails. Anyway, you’ll see here lots of questions. All answers based on your experience are welcome. So:
What are the pivotal Rails components? I know about the asset pipeline and the ActiveRecord. What else must I know about? If I want to reuse something outside of this list, how do I do that? E.g. how do I select the new ruby gems? How do I decide which gem version will be right for my app?
What’s the Rails threading model? In this tutorial we added per-request instance fields to the controllers. In Java it’s like adding per-request instance fields to a Servlet – which you’ll have to fix after the first code review. For some reason it’s OK in this tutorial. Why is this? How handles Rails concurrent requests? What are the typical bottlenecks?
How goes the basic unit testing? While this acceptance testing is great for testing the UI, it’s not-so-great for providing meaningful code coverage. On the one hand, acceptance testing is slow. On the other hand, it cannot test every important aspect of every feature. Yes, I’m talking about the Test Pyramid. So, really, how do you write unit tests in Ruby? Which Rails components do you cover with unit tests? Which are too simple to break?
4. Does it change your life?
Maybe. This tutorial makes me wonder: why do people use technologies like Java when they are concerned about delivery time? Actually, most of the projects I’ve been working on had a constant time pressure. A RAD framework like Rails can significantly cut development time.
However, if developers start to rush then it’ll raise maintenance costs up to the roof. OK, I understand why folks write projects in java: if it gets messed up then it’s easier to deal with. E.g. the compiler provides 100% coverage for certain kind of errors. More on this static-vs-dynamic debate here.
Still, for any greenfield project my advice would be: recruit professional programmers and let them use a RAD framework like Rails. They’ll kick ass.