The Rails-way and bigger projects

The whole idea of having a data-structure that you retrieve from the database and carry through all the layers to the UI makes the development very quick at the beginning.

The coupling it provides, at the later stages of development makes it very difficult to split the app into any kind of modules. It's also difficult to test anything in isolation. That's why Cucumber, Capybara, Selenium are so popular, as they help you in writing integrated tests.

Integrated tests have their place, but it's impossible to test everything through all the layers. This results in slow builds - a typical syndrome in Rails projects.

The Rails way makes sense for smaller projects. What I'm disagreeing with is using "The Rails way" in bigger, serious projects.

The Rails itself has nothing inherently wrong. I'm not attacking Rails, I'm only attacking 'the Rails way'. You can use Rails for bigger projects, if you know what you're doing.

What I'm teaching at my Rails class

It's now the 4th time, I'm teaching the Rails class at the University of Wroclaw. The main goal of this class to prepare people to work in a Rails-based company. The students are the best of the best, so the goals can be high.

Every year, I introduce some changes to the program of teaching to reflect better what is happening in the Rails community.

This year I'm going to focus more than before on the integration with mobile, native apps and on the art of dealing with legacy projects.

We start with extremely quick Ruby lessons, based on the Ruby koans exercises (students do it on their own).

The first 3 lessons are about "the Rails way", which I make it clear - is good only for toy projects. This is where I teach about ActiveRecord-oriented programming, coupling everything with everything, making things impossible to test - you know, the usual Rails stuff.

Once we know the enemy and know the pains it provides, we learn how to avoid that.

This is where good, solid OOP lessons come in, service objects, repositories, domain objects, etc.

After that, we enter the "frontend" module. We learn how to create Single Page Apps using the dominant JS frameworks (Angular) and some no-framework techniques (HexagonalJS. This also includes techniques like Pusher to have server->client communication possible.

We also talk a lot about the way, a Rails backend can expose data through the API to the JS or mobile app clients. Mobile apps will take more time this way, as I want to show how to best cooperate with mobile developers.

There's a lesson about proper Rails deployment, things like Chef, Jenkins, Continuous Deployment etc.

Throughout the class, we'll not only create new Rails apps (lots of them), but I also want to teach how to find yourself in a legacy codebases, like Redmine or Discourse, how to refactor out from the mess, fix bugs, add new features - that's probably the hardest part of the class.

Testing is an ongoing topic in the class, as well. We'll learn about unit testing of different layers, integrated tests and their pains.

I hope it will be fun, as always :)