Rails is still cool

There are many discussions recently on things that suck in Rails. Specifically, it's about how people misuse Rails. I think we need more OOP in Rails.

Let me explain.

Disclaimer: I started using Rails in 2004, now I run a Rails consultancy and I've been more or less involved in about 30-35 Rails projects. I'm also involved in building a"social games for brands" product called GameBoxed, which proudly runs Rails 3.1 under the hood.

Rails history and background


When Rails was released in 2004, I don't remember that DHH was saying it was perfect for everything. He showed us Rails and said: "look, this solves many problems of a typical web app". He was right. Somehow, it was assumed that the Rails way is the only way. This led to some people complaining about how Rails doesn't fit well into their more complex apps - I was one of such complainers, shame on me.

Rails is awesome for starting an app


Let me repeat - Rails is great for starting an app. Do we want it or not (I want) we will see new Rails apps being created every day. The mainstream future is still before Rails, because it's really easy to start and new people will keep coming in.

Why do you complain about Rails?


It's not complaining about Rails, it's complaining about the current "best practices" and how we (me included) use Rails. In every project I worked on, choosing Rails as the platform was a good decision at the beginning. It's just that at some point we not always realized that we should find our way, not the Rails way to implement the requirements. We had a hammer, so we looked for nails everywhere. It doesn't mean that we should drop Rails. Projects evolve. What starts as a typical Rails app, evolves into something bigger, more complex at some point. Maybe it should be 5 small Rails apps cooperating together with some APIs?


Why don't you write your own framework?


Someone asked me this question recently and I realized that my Rails critics is presented in a way that put Rails in a bad light. It's not true. Rails is awesome. It has almost everything right. I don't want to create a new framework. It's too much work and there's no point in it. What I want, though, is looking for ways how to improve the apps that were misusing Rails at some point. In our company we sometimes inherit projects from other teams and that's my main area of research - how to maintain and refresh legacy Rails projects.
Another argument is that I haven't seen such an awesome community anywhere else. It's a community extremely open for new, good suggestions.


But you criticized ActiveRecord so often, what about that?


ActiveRecord is a great persistence layer. It was never my favorite part of Rails, because I never really liked the persistence part of projects. It's kind of an implementation detail to me.
Somehow, I misused Rails in this area. Instead of treating ActiveRecord as a persistence layer I started treating it as a domain layer as well. It was so tempting to do so...
Actually, at the beginning of a project it can be fine, to make AR you domain layer as well. Just for quick prototyping. But later I think that you should have a separate OOP domain model. I will come back to this point.


ActionController is the problem


There's a valid argument that Steve Klabnik and others talk about. The way Rails handles the communication between controllers and views by default is awful. I suppose you all know what I mean. Note that Rails doesn't force you to use it this way. You're free to make it better. My suggestion? Use cells and research the presenter-based gems for views.


ActionView is the problem


The problem is not ActionView itself, it's how some people misuse it. Rails community does a lot to discourage putting logic inside views and I think it goes well. We could go with Mustache or other logic-less templating systems, but it's assuming that we can't trust programmers. Welcome back to Java? BTW, stop hating Java ;)


MVC is the problem


First of all, Rails is not MVC. Second, the Rails MVC (Model2) is fine for monolithic apps that are (yay!) going to the past. The future is in viewless, API-based backends with rich clients like mobile apps and CoffeeScript apps.


Rails for bigger apps


The first thing to remember is that Rails is not your application. Rails helps you as a delivery mechanism. Once it's bigger, you should consider:

• breaking from the monolith application into backend+frontend
• implement a separate (from AR) domain layer

It all assumes that you have tests for your project. If not, then you're screwed anyway. There's no chance for refactoring if you don't have tests.


Future?


I see the future in separating backends from frontends. This alone makes the architectures simpler and easier to maintain.
Extract your domain layer. It's something that I'm experimenting with. It's hard, but it's not about Rails making it hard. Surprisingly it's hard because of the way we deploy Rails apps.

Domain layer


The point in separating the domain layer is that we want to implement some classes that have nothing to do with ActiveRecord classes. Yes, they may be similar. Maybe some names will be duplicated, but that's another layer. It should be framework-free, pure objects. PORO.

The deployment way leads to the question - What's the point of building an object model in memory, just to run one use-case and it all disappears? It's a waste. That's what happens when you build a domain layer based on database (ActiveRecord) data in a typical mongrel/passenger/heroku environment.

I'm experimenting with running Rails in a threaded environment (Thin allows it). It means that Rails is run in a single process and all requests come as threads. It's promising and very liberating - you can have your own Ruby objects, without being restricted by the ActiveRecord problems. I will blog more about it, soon.

There are problems, though. This approach requires a different scaling mechanism (but it also move the scaling need further to the future by speeding things up - your data is now in memory). Another problem is that you need to synchronize your domain layer with the ActiveRecord layer.

Despite the problems, I think that this approach has some potential. Contact me, if you would like to help me with this research.

Avdi also has some interesting ideas about the ActiveRecord separation in his book - "Objects on Rails".

Use cases

The synchronization part can be done using the use-cases layer. Read about it here: http://blog.firsthand.ca/2011/12/your-rails-application-is-missing.html

The use-case object can synchronize the two parts together, but you need to remember about keeping it consistent (either by transactioning it or by having a synchronizg thread).

Use cases alone are an awesome idea. Imagine that all the changes to your system that are triggered by a user or another actor come through a use-case object. This way, you're nicely exposing all the actors playing together and you can expose your real architecture.

ActiveRecord is changing in Rails 4


Look at this commit: https://github.com/rails/rails/commit/00318e9bdfc346a57cab34b2ec3724f3e9605ac1
It seems to be a small change, but it will allow extending your objects with the persistence responsibility runtime with DCI. Wouldn't that be cool?

DCI


You knew that I would mention DCI, didn't you? :) Yeah, I'm a big fan of DCI, just for the use-cases alone. They call it contexts, but it's the same meaning. The idea of DCI spreads nicely in the Rails world, but what worries me it's only the idea of extending objects runtime that is being spread. Runtime extending can easily bring you to a mess if you're not controlling who can extend any object. It's the context. If you're extending model objects inside other model objects, then you're doing it wrong, I'm sorry. Lessons learnt, trust me.

Read more about DCI on my blog posts:
http://andrzejonsoftware.blogspot.com/2011/12/dci-for-dummies.html
http://andrzejonsoftware.blogspot.com/2011/02/dci-and-rails.html

You should also read "Lean architecture" book which is a deep introduction to the DCI way of thinking.

Summary

• Rails is cool, if combined with classical OOP. 
• Remember about TDD and testing. 
• Separate backend from a frontend. 
• ActiveRecord is not your domain layer. 
• Learn DCI. 
• Think in use cases. 
• Attend the wroc_love.rb conference in Wrocław, Poland. There will be many Rails OOP related talks. 
• Send us your ideas for talks (you have my vote if it's Rails OOP related :) ) - I'm one of the organizers.

Bonus


Uncle Bob talk from RubyMidwest
http://confreaks.net/videos/759-rubymidwest2011-keynote-architecture-the-lost-years


It's one of the most important talks I have seen recently. You must watch it. It will change the way you think about Rails apps.

Thanks!


 If you read this far you should and subscribe to my RSS.

Small, deployable commits

We've had an interesting discussion at our stand-up today. The discussion was triggered by Jan Filipowski post on "early commiting in TDD".

The main questions are:

• Should I refactor before every commit?
• Should a commit pass all tests?
• What units of code should be code-reviewed?

It got me thinking about my current approach and about my "ideal world" approach.

I'm a big fan of the idea of continuous deployment. It means that every commit, after passing all tests, can be automatically deployed. 

I'm not there yet. I try to work with very short commits, often it's only 2-line changes. However, I still miss an infrastructure which could automatically push this commit, test it and deploy. It's not that it's difficult to prepare, it's just some kind of a psychological bareer. It's definitely something I want to improve as soon as possible.

Sometimes it's hard to have deployable commits. Recently we've been upgrading our app to Rails 3.1 and it's not something that can be done in one commit. 

Going back to questions:

Should I refactor before every commit?

Refactoring is part of a workflow, but I wouldn't say it should part of every commit. Sometimes a commit can be just the red-green part, and it's the next commit that does the "refactor" part.

Should a commit pass all tests?

This is a tricky one. In my ideal world - yes, because it should be deployable. Is it hard to achieve in practice? I'm wondering if there's a conflict between a deployable commit and one that fails on some tests.  Maybe it's fine to have some tests failing, if they are not part of the code that is being used in production?

 What units of code should be code-reviewed?

We tend to make code reviews using GitHub commit comments. They're fine, but sometimes I comment on something that was changed 3 commits later, which makes my comment irrelevant. 

Obviously it all depends on a project. In most cases I think we shouldn't be too serious with the code reviews comments. In my opinion code reviews should help us triggering some coding/architecture discussions, they shouldn't be too formal. I don't like proceses which require code reviews before the code goes into production - we should trust each other that nothing stupid gets deployed. If we treat a code review as a tool for better communication then it's not that important if a comment is about a code that changed later or not.

How about you? How often do you commit?

args, opts, params

It's quite popular, especially in Ruby code, to see methods like this (note the method arguments):

def show(args)
  some_other_object(args)
end

or

def show(opts)
  .. lots of code
  bar = opts[:foo]
  opts[:bar]
end

and also:

def show(name, params)
  some_other_object(name, params[:foo])
end

I see some problems with such code:

1. It's hard to tell, when you call the method, what is really required/expected to pass in.

It's less of a problem, when you can see in the method body what is used. But it's not always the case. Often the params are passed further, so you have to look around and think hard how the params are used.


2. (args, opts, params) as names sound very generic, they don't tell me too much.

I understand that hashes are quire useful sometimes. But it's a similar situation like the one where we would call a variable a var_1.
Why don't we, at least, give them good names, like address_hash or html_options or maybe game_configuration?

3. It's a missing object smell.

Very often, to me, the examples above are code smells. There's a missing object somewhere. Especially when this data is passed further. Maybe it's Address object, maybe PopupContent, whatever sounds good in your domain.

What's your opinion?

DCI for dummies

The metaphor of DCI is a theatre. The context is the director. Chooses who plays what, instruct them how to do it and then let them play.

Theory:

1. Expose use-cases (context) as first-class citizens of your code. 
2. Each use-case selects which objects are needed for this use-case. 
3. Extend the objects only with the roles that are needed in this use-case. 
4. Start the interaction. 

Example:

Buying a product.

1. UserBuysAProduct object, that can be executed. 
2. Objects/actors needed: user, shop 
3. Extend user with a Buyer role and shop with ProductCatalogue and OrderManager. 
4. call shop.buy_product(user, product) 

Continuous integration - some tips

Continuous integration server is a must for every non-basic project.

Here are some of my tips for working with CI servers.

Notifications


IRC, email, campfire - use what fits best for you. Ideally, the notification should come with some info about the code changes that triggered the build. We use IRC - we've got an IRC channel for every project we work on, so the notifications go to the correct channel.

Build time

It's a huge topic. It's so difficult to keep the build time short for every project. I have to admit we've got projects where build time takes 20 minutes. My goal is to get down to below 10 minutes for existing projects and try to keep the new projects below 3 minutes. Slow builds have a very bad impact on so many things. The feedback is late. People tend not to run builds on local machines.

Local builds


It's great that you have a CI server, but the goal is also that all tests can be run on every developer machine in a decent time.

Architecture decisions


That's the most surprising effect of using tests and CI. Once we got to the point where many of our projects have the slow build problem we investigated our technology choices. In many cases the slowness came from using Selenium. Selenium is the only "right" tool when you have an app that is a mix of server-side logic and client-side code (JS). It seems, surprisingly, that many of our projects could be turned into one-page CoffeeScript apps. Obviously it's not an easy goal (and not always possible). It's changing the way we architecture our apps. If the split is achieved you can test the CS code in isolation from the server-side and then test the server-side API, also in separation, but without Selenium.
Selenium is cool, but it has the drawbacks of being slow and unreliable.

Unreliable tests


If you're using Selenium, then you already know what I mean. I hate this fact but sometimes we've got build failures which shouldn't appear, they're most of the time timing issues. It's a hard situation to have. The important thing to remember is that we (the team) are all in it. Every team member should investigate the problem and try to fix them - sometimes adding a sleep (a hack, I know) solves the problem.

Who's responsible for failures?


I like the idea that the last person who triggered a failing build is responsible for fixing it. It's hard to get to this point, especially if your build is unreliable. This leads to:

Never leave a broken build


This is the biggest sin when working with CI servers. If I want to start coding and I see that a build is broken and no one seem to care then it's very depressing to me. In practice, it means that you should commit your changes some time before you finish your work, so that the CI can run it and get you the result back. If it's broken, try to fix that as much as you can. It's less of a sin when the failure comes from unreliability, but leaving a broken build caused by your changes is unforgettable :)

Summary


A green, fast build run frequently on the CI server is a sign of a healthy project. If there's anything broken with the build process, look at it. It's often a smell showing you that something can be wrong in your process. Don't ignore that.

Any tips from your experience?

CoffeeScript is the fresh air

When I started using Ruby and Rails in 2004 I immediately knew that Rails is going to be huge. At that time I was working mostly with Java.

Ruby and Rails brought so much joy to my programming world that it was kind of a revolution in my programming passion. This revolution is still going on, I'm still happy with Ruby and Rails even if I sometimes criticize some aspects of it.

There is however a new thing that triggered a new (r)evolution in my programming world.

This thing is called CoffeeScript.

I know that Coffee is only a "patch" to JavaScript, but for me this slight change is huge. The syntax is the prettiest combination of Ruby and Python that I have ever seen.

The code written in Coffee is so pretty that it almost allows you to think at new levels of abstraction. Yes, it's that huge to me.

I never especially liked working with JavaScript on the front-end. I preferred to focus on Ruby backends. Now it's harder to me to switch from frontend code to server Ruby code.

I still love Ruby, but CoffeeScript is officially becoming my new passion, equal to Ruby. If you haven't given it a try, then you should. It's so worth it.