Rails legacy applications

The topic of Rails legacy applications is becoming more popular recently.

We, at Arkency, sometimes receive questions whether we can take control over an existing application. It's never an easy decision.

Legacy apps contain legacy bugs, which can quickly become "our" bugs. They often have no tests, or just failing tests. If you're very unlucky, you can find some really shitty code.

What's the reward?

This is a story of one such project. We can proudly say that we successfully fixed the mess, not only that, we also created some beauty on top of that.

Let me just say that it was such a pleasant experience that we decided that Arkency should do more such projects.

Challenge accepted! We're looking for more such challenges, email me if you have an old Rails app that needs to be fixed.

Read the slides of Michał Łomnicki to learn the details.

Having fun with legacy apps from Michał Łomnicki

Thanks to Michał and Paweł Pacana for the awesome work!

Let me know if you want to learn more about what we did and I will convince Michal to blog about it :)

Is CoffeeScript better than Ruby?

If you are subscribed to our Arkency newsletter (we send an email every week or two with some interesting links and our comments), you probably noticed that there is an ongoing debate in our team - whether CoffeeScript (actually JS) has a good standard library.

I have recently watched an interview with DHH about his opinions on Single Page Applications.

DHH was explaining why they don't go the SPA way with their new 37Signals applications. They chose to generate JS and HTML on the backend and send it back to the client.

One of the DHH's arguments was that they prefer the Ruby stack (with Rails) than the experience of writing CoffeeScript application, with the server being just for JSON API.

Overall, I think that DHH makes some good points, but I don't agree with the assumption that it's better to work with the Ruby stack than with CoffeeScript. Sure, the patterns are not so mature as with a typical Rails app, so sometimes it takes more time to do the same thing, however their approach of sending JS is also not the most trivial one and it creates a complex architecture, IMO.

First, the syntax of CoffeeScript is better to me, than the Ruby syntax. This is subjective and I'm not expecting everyone to agree. To me, it's enough that the code is mostly shorter while still very elegant.

Second, the libraries. Yes, JS stdlib is almost non-existing. It's almost always better to avoid the existing stdlib and rely on sugarjs or underscore. Ruby is winning here. Now. With the growing JavaScript communities, we'll see a huge improvements very soon. The sugarjs library is already awesome and I don't feel I'm sacrificing anything by using it, compared to the Ruby libs.

You can improve the libraries, but it's hard to improve the syntax.

I may agree with DHH, that the SPA environment is not yet at the same level as Rails is now. Even DHH says that the situation happening with JS MVC is a huge shift. In my opinion (and not only mine), we see a revolution that can be only compared to Rails in 2004-2005. Back then, Rails also wasn't that mature, but we were able to use it and have a really well working applications (my first production Rails app was released in April 2005 and was used by hundreds of users every day).

Back to the title dilemma. Is CoffeeScript better than Ruby? 

We need them both. The trend of SPA will be growing and we can't use Ruby there. On the other hand, it's not easy to use CoffeeScript on the backend (nodejs based solutions are nowhere near the stability of Ruby solutions) and Ruby is a great choice in there. In most of the apps that I'm currently working on, I spend like 80% of my time with CoffeeScript on the frontend and 20% on Ruby on the backend. That's my answer :)