Andrzej on Software

Typical Rails bugs

2013-06-17T10:09:00.000Z

As part of my research on improving Rails application, I noticed a pattern in the bugs that are quite characteristic to Rails in several applications.

They have certain 'visible' things in common:

often security related, like leaking some information to unauthorized users
they live somewhere in the area of business logic/persistence
they are not so easy to fix in the existing codebase
they tend to exist in groups, similar bugs in different areas
they are easy to miss
often they appear during the requirements changes

Overdose of ActiveRecord

The reasons they exist is a combination of different things. The main common point of the bugs is the over-usage of ActiveRecord. It's easy to fall into this problem, I did it many times, as well.

You start with a new Rails app, adding new features very quickly. New requirements pop up. You use the popular Rails techniques to deal with them:

validations, which often turn into conditional validations
Single Table Inheritance
state-machine
accept_nested_attributes
models callbacks
virtual attributes
external gems that provide value magically, by using ActiveRecord (implicit dependencies)

Every technique is fine on its own. When you start using all of them in the same area, problems appear.

Examples

I started noticing this trend, while reviewing the code of our potential Arkency customers. We sometimes do the "rescue missions" and help with legacy code. I can't use those examples here, so I started reviewing some of the popular open-source Rails applications: Discourse, Spree, Redmine, Gitlab. It didn't take me much time to discover the same bugs.

Just to be clear, all of the projects are awesome and I'm grateful to the people behind them. Most of the times, they deal with this kind of problems very quickly. I don't want to blame them for anything - they just serve here as examples.

Discourse

Let's start with Discourse:

1. Digest mail ignores secure groups

http://meta.discourse.org/t/digest-mail-ignores-secure-groups/7288

People receiving the digest mail can easily read posts not meant for them. That's because the digest mail ignores the secure groups a member has access to or not.
Quite a problem as I unfortunately found out.

2. Non-authenticated users see private topics in 404 page

http://meta.discourse.org/t/non-authenticated-users-see-private-topics-in-404-page-was-mobile-view/7419

Discourse correctly prevented me from seeing the topic and instead showed a 404 page. On that 404 page, the lists of "Latest Topics" and "Recent Topics" showed private topics. I could click those links, which resulted in seeing the same 404 page again.
The 404 page should not show private topics.

3. Auto-suggest topics shows private topics

http://meta.discourse.org/t/auto-suggest-topics-shows-private-topics/7418/3

We've got Discourse running with private categories. When a user without access to the private categories type a new topic, they are presented with topics in categories to which they don't have access.

Comment: Did you notice the pattern here?

Accidentally, I've had a small conversation at HN with one of the Discourse founders. He said:

Those private topic bugs are not the result of ActiveRecord. We added a group layer on top of existing code and missed some places where queries did not respect it.

Had we used raw SQL instead of an ORM we would have had the same issues. All projects are open to this style of bug. The correct thing to do is report, close them quickly and add tests to prevent them from happening again (which we do.)

I have completely no 'science' proof here, it's just based on my experience with hundreds of Rails projects. However, I disagree that all projects are open to this style of bug.

It's very typical to Rails projects.

The temptation of globally accessing every model/record from every place in the project makes it very easy to introduce such bugs. When you add new requirements (as they did) it's practically impossible to find all the places which should be changed.

Do I blame ActiveRecord here? No, ActiveRecord is a good library for persistence. It has its issues, it's huge, even the maintainers consider it a legacy code. Apart from some edge cases, it works more or less ok. I think the problem is relying on ActiveRecord for basically everything.

Spree

Let's see some other bugs, this time in Spree:

1. Fix wrong discount calculation with flat percent promotions

https://github.com/spree/spree/pull/3054

Fix wrong discount calculation with flat percent promotions when there are more than one line item in the order.

This error happened because the order instance here:
https://github.com/spree/spree/blob/master/core/app/models/spree/order_updater.rb#L24

is not always the same instance in memory here:
https://github.com/spree/spree/blob/master/core/app/models/spree/calculator/flat_percent_item_total.rb#L15

Adding the inverse option to the relationship makes sure you have the same object instance in both places.

Comment: Here we have another problem related to ActiveRecord. In more complex situations (cyclic associations), you can have the same 'record' in memory as two different instances, leading to errors.

2. Admin products loads entire dataset to determine the total count when paginating

https://github.com/spree/spree/issues/2679

When kaminary determines the total count of records it runs the following code
@collection.except(:offset, :limit, :order).count

The issue is that this sequence loads entire dataset to determine the count. This makes heavy load when products have large number of items.

The reason of this behaviour is group_by_products_id here https://github.com/spree/spree/blob/1-2-stable/core/app/controllers/spree/admin/products_controller.rb#L94

Comment: This time we have a combination of ActiveRecord and an external gem - kaminari (paginator). The end result is slowness of admin panels with thousands of products - they all will be loaded to memory. It's not the worst bug I've seen, but it's typical.

3. Default Tax Does Not Calculate Taxes Correctly if there is a Promotion

https://github.com/spree/spree/issues/2493

4. Taxes should be re-calculated after promotion adds an adjustment

https://github.com/spree/spree/issues/1735

Comment: the titles should be enough. This kind of bugs is usually related to the ActiveRecord callbacks usage. In complex scenarios it's not that easy to track all the places that need to be called after some changes.

Redmine

Let's now look at one Redmine bug:

1. Time entries of private issues are visible by users without permission to see them

http://www.redmine.org/issues/12287

Comment: Does it ring a bell? Again, a leak of private information.

Summary

We have seen some of the bugs, that I called typical Rails bugs. They seem to have certain things in common. I've seen them so many times, that they are the first things I look for, when I get access to a new project ticketing system.

Is there any way of defending against them? I think so. The best step to start with is to be aware of such problems. Try to spot them in your projects, see what history is behind the bug, spread the knowledge in your team.

In my next blog posts, I'll focus on techniques that should help decrease the number of such bugs. Stay tuned. In the meantime, you may want to follow me on Twitter and subscribe to the Rails Architectures Guide, that I'm working on.

Single Page Applications fight - video

2013-04-28T10:00:00.000Z

During the last wroc_love.rb conference we've organised a "fight" between 4 different approaches to Single Page Applications. Below is the video (0.5h) and a very short and simplified transcript from this event.

The participants, from the left-side:

Patrick Mulder - Backbone
Piotr Sarnacki - Ember
Andrzej Krzywda (me) - Hexagonal
Adam Pohorecki - Angular

moderator - Jan Filipowski

1m39s

Can anything be a Single Page App?

(and discussion about SEO)

Patrick: only for some apps

Drogus: for interactive apps, not for static apps that need to be indexed by Google

Andrzej: for all the apps

Adam: we need better tools on the backend in order to have a better developer experience

Piotr: Andrzej, would you write wikipedia as a SPA?

Andrzej: Yes.

Adam: What about SEO?

Andrzej: It's a myth that SPAs are not indexable. Google has an official document for that. It is additional work.

Patrick: You can use PhantomJS for SEO.

Adam: We've used PhantomJS for that, took a couple of hours.

8m28s

Can you introduce the framework you're representing here?

Andrzej: HexagonalJS is not a framework, it's an architecture guide. Uncle Bob (OOP) + Raganwald (AOP) + Hexagonal Architecture. It's more like a set of guidelines

Piotr: EmberJS - it does as much as it can for managing your SPA. it's not minimalistic, for good reasons (you don't have to write much code).

Patrick: Backbone, very small, minimal. you don't bring too much dependencies. you can choose what you want.

Adam: Angular, Two-way data binding is the key feature. Synchronization of HTML and your JS. Choose framework with data-binding. Ember is essentially a language, forces its own object model. Backbone as well. Hexagonal or Angular is pure JS.Your application can live outside of Angular.You could use Angular with a Hexagonal app. Backed by Google, more mature than Ember.

Andrzej: Data binding is not as important as you may think. Manual control is not that difficult. Hexagonal doesn't have data binding jilt-in. Apps are not about data changes, but about actions

Piotr: I agree that data binding is important. Both, Angular and Ember are good for big applications. Nested views, zombie views (backbone). Angular has its own compiler for DOM elements. You need to know how the compiler works. Angular uses dirty checking. Angular claims that your UI shouldn't have than 2000 elements. You're screwed if you have more.

Adam: We built a 100 rows, 500 columns table. We managed to do it with Angular. It's not that hard to do the UI part. Directives are like helpers for html.

22m6s

Do you have to take the mindset of the creator?

Adam: Most of the things in Angular are optional.If you don't use the HTML part, you lose a lot.

Andrzej: It's a problem of all of us here, including Hexagonal. We use different terminology for different things. All the frameworks are far from being Rails, we're not mature enough. All the frameworks are in their infancy years.

Patrick: It's easy to work with Rails and Backbone

Piotr: Ember has its own class model. It's done mainly for making it easy to optimise. Ember is about Convention over Congifuration. Rails in JS. Ember is like Rails, Backbone is like Sinatra. At some point you have to use more plugins if you start with something minimal. A lot of pain if you want to write a big app with a small framework.

Andrzej: I disagree. I would use a framework for a prototype or for a small app. Once the app grows, it has its own world. I don't want the framework to go into my way. I want to have the control over the applications. I'd use Ember for smaller apps, not for bigger apps.

27m23s

How to be involved in the community, how to learn the framework?

Adam: Angular has really good docs. All development happens on github.

Andrzej: Hexagonal has just started. It got the name just recently. We've used it for over a year. We have a strong team behind it. Our goal is to show the guidelines.

Piotr: Ember is 1.0RC now. Docs are better now. IRC is very active. Google Group.

Patrick: JavaScript and Ruby devs can help.

END

If you're interested in Single Page Apps, you may want to follow me on Twitter.

Why do projects take so long?

2013-02-23T16:36:00.000Z

Some projects take a long time to develop. In different contexts, the definition of "long" may vary. It was always interesting to me, what are the reasons for it. Recently, though, it became my obsession.

I've started collecting some thoughts on this topic.

Ask yourself and your teammates about the last project you've been working on. "Would we be able to implement the same result in 1 month? In 1 week?".

Surprisingly often, I'm answering to myself - yes, that would be possible, given some assumption. I've had similar answers from my colleagues.

Where does it come from?

Is it the known tendency to underestimating a problem by developers? I don't think so, as we're talking about a project, that has already happened. We know what is to be done. We are aware of edge cases.

"This is time it will be different, faster"

This is another popular trend among us, developers. Most of us are optimistic, even the experienced ones. It's not some kind of a student-syndrome (I'll do it tonight), but a well-thought statement. Is it really different and faster? Not always…

Where does this optimism come from? Good developers become better at solving technical problems. With each problem solved, we know that we solved the problem forever. We love solving problems, every day we're smarter by this attitude. We're progressing and the optimism may come from that.

It's almost impossible to get a second chance of working on the same project. What would that even mean from a business perspective? We rarely get that chance.

Is it the technology that let us think, that we could do better this time? That's a serious candidate. Every time, I switched to better technologies or to better architectures, I noticed the speed increase. I was more confident. I saw the results.

I remember a situation, back in 2004/2005. I was involved in preparing an estimate for a new project. The estimate was about 6 months for 4 developers (assuming ASP.NET). Very shortly after that I learnt Rails. I realised, that the project is perfect for Rails. It was a CRUD-based web app. I kept convincing the management to give it a try. No luck. Finally, I had a chance of coding live in front of some managers. I implemented the main path in about 1 hour (I was well prepared). That convinced them. We've finished this project in 1.5 month, with one junior programmer and me being mostly a PM and a Rails mentor.

What's the lesson? It's hard to tell. I'm not trying to say that only Rails was the reason. Motivation? The passion behind it? Trying to prove something? The focus? I think it was a combination of all of the above aspects.

Is it easy to repeat those aspects? Do they sound familiar?

Have you ever attended a hackathon?

There are many kinds of hackathons. What's most important in this context, is how much can be done in a very limited time. If you look at the results of Rails Rumble, some of the apps are quite big. Many features, everything is polished.

Hackathons are proves that we are able to develop apps quickly.

How can we apply hackathon lessons to our every-day projects? Is it possible?

What else can help us developing software faster?

I would love to know your opinions.

Angular or Ember? Congratulations, you've already won.

2013-02-23T10:06:00.000Z

At the wrocloverb conference we've decided to have a Single Page Applications "fight". (The format of fight worked pretty well last year for the JRuby vs Rubinius battle).

We're having Ember, angular, Backbone and hexagonaljs representatives. As I'm representing the last one, during the last few days, I've did more research on the other alternatives.

There are huge differences between all the choices. Some of the frameworks are like Rails, some are more like Sinatra. Hexagonaljs is not even a framework.

I have been making notes on the differences, collected jokes on each of the opponents. It's going to be a great fight :)

Anyway.

I realised one thing. If you're wondering which of the frameworks, non-frameworks to choose, you have already won. You are already in the world of Single Page Applications. There's no wrong choice in here. You will be fine with any of the frameworks.

There's a warning, though. I know many people who entered this world and they don't want to come back to the non-SPA reality.

Congratulations, that was a good choice!

Non-framework approach to JavaScript apps - hexagonal.js

2013-02-22T14:09:00.001Z

This week we have officially launched and announced hexagonal.js.

The announcement was welcomed with a fair amount of interest. Jan Filipowski at the Arkency blog did a great job of explaining the basic ideas.

I'd like to cover the topic of hexagonaljs not being a framework.

What is a framework?

Some time ago I asked "What is a framework?". I liked the following answer:

In the case of a framework, your code is called by it. In the case of a library, your code call it. Rails is a framework, and provides libraries too.

I have a love/hate relationship with frameworks. That's why I struggled for months, what to do with the ideas that we're now calling hexagonal.js. I didn't want it to be a framework. That would ruin the whole experience.

Let me tell you a story on how it all started and why we didn't want it to be a framework.

The technical story of haxagonal.js

The first ideas were created when we were working on social web games at GameBoxed. Given the scale we were operating on (sometimes 4-5 social apps/games a month) we needed a high degree of reusability. Reusability requires good modularity. Often, we've had apps that have the same "logic", but they had much different GUI, sounds, FB integration etc.

We got the idea of use cases as objects from the DCI approach (DCI is much more than that!). We've experimented with the concept that it's the use-case that drives everything. Driving something (like playing sounds) meant calling it. Calling it directly meant creating a coupling between the use-case and the SoundAdapter, which didn't sound like a good idea.

One approach was to use events. The use case would trigger an event and the adapter would bind to it. It resulted in less coupling. It wasn't bad. To me, it wasn't yet the final solution, though. I didn't like the fact, that the use-case objects were full of "trigger someEvent" statements.

When I looked at the events, I realised that they happen usually at the beginning or at the end of a method in the use case.

Before, After....

Wait, wasn't that what AOP was about?

Introducing some simple AOP techniques (thanks to awesome Raganwald's library!), we have achieved exactly what was needed. This is what we currently call a Glue code. It's almost like a configuration, in most cases. No logic, just declarations.

Hexagonal architecture

We started with MVC in mind. The most basic rule of MVC is that when the model changes, the views are notified about it. After some time, we've realised that it's not only about views, unless you try to fit "playing sounds" into the View layer ;)

In a hexagonal architecture, GUI is just one of the adapters. It's usually the most important one, but technically, still, just an adapter.

In many apps, the GUI is the only adapter.

ServerSideAdapter, PusherAdapter, SoundAdapter, FirebaseAdapter, FacebookAdapter, LinkedInAdapter - those are just examples of the adapters, that we used so far.

It's not a framework

Given all of the above, we were struggling on how to bring this idea to people, without making them depend on any framework. The whole idea is a bit anti-framework.

Hexagonal.js is not even a library. It's mostly an architectural style adapted to JavaScript apps. We provide many examples (and more in progress..), that can guide you. You can copy them, fork them and have a good starting point.

It's probably a slightly unusual approach to deliver some ideas to you. It's not a framework, not a library.

Hexagonal.js is a set of good patterns that are extracted from real-world production apps. It was used to build dozens of apps, with a good speed of development.

You can look at the examples we already have. Look at the use case object, the glue and the adapters. It's a pattern that reappears in every hexagonaljs app. There is also an example of using it from a Rails app.

Tell us what you think about this approach. We've published it to bring more ideas. We're open for suggestions!

Thanks for reading.

Frontend first

2013-02-14T14:39:00.002Z

Some time ago, I blogged about the different phases of mental transition when working with JavaScript frontends. Here's the shorten version:

1. No-JavaScript phase

2. JQuery explosion

3. Page and Widget objects

4. Single Page Application

Once you're in phase 4 and you create apps this way, you realize that you don't need the backend in order to create the Single Page App. Even more, you shouldn't start with a backend.

Frontend first

This is the additional phase. Frontend first. In most of the typical situations, it's much better to start with a Single Page Application and use LocalStorage or some kind of a InMemoryServerSideAdapter for the first phases of the development.

Only after you know how the frontend works and what kind of server interaction it requires, it actually makes sense to start working on the backend.

We've tried this approach in several Single Page Apps and it worked great for us. It now seems like the most natural way of working.

to learn more about Single Page Applications.

What is a framework?

2012-12-06T15:36:00.001Z

The title question made me struggle for months.

What is a framework?
What is the difference between a library and a framework?
If I use a framework as a library, does it make it a library?
Is Rails a framework?
Is Backbone a framework?

Can you help me with your answers?

Rails legacy applications

2012-08-27T21:26:00.000Z

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?

2012-08-26T16:44:00.002Z

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 :)

JS frontends are like desktop apps

2012-07-15T23:17:00.000Z

I noticed a trend recently, among developers, that we need to learn how to work with JS frontends. Obviously, it's great that people want to improve their skills, but is it really something new that we need to learn?

I suppose, that many of us at some point have been working on a desktop application. Was it a Java Swing app or a .NET Windows Forms or maybe Delphi app, doesn't matter that much.

What's important is that a JS frontend is very similar to a desktop applications.

Yes, they are not completely the same, we can do a few things that are easier in the browser than on the desktop app. Those differences don't influence the way we architecture the JS apps.

If you haven't had a chance to work on a desktop app then you're missing a lot, but still, it's much better to read about the desktop patterns, than to try the new shiny JS framework.

From backend to frontend - the mental transition

2012-06-25T20:23:00.001Z

Recently I blogged about my thoughts on the idea that frontends are in fact separate applications.

Today, I'd like to describe the transition of my mental model in thinking about views and frontends.

I thought that it was only me who went that path, but this excellent Backbone introduction slide deck helped me realize that it's a common process for backend developers.

This process consists of the following steps:

1. No-JavaScript phase

No JavaScript at all, or using it through some kind of backend plugins (like the ones Rails gives - link_to_remote etc.)

2. JQuery explosion

This happens when you use straight JQuery, there is lots of JQuery plugins updating different views, replacing html and using some simple Ajax.

3. Page and Widget objects

It's basically the same as phase 2, but this time you wrap all the JS code into nice objects/classes, so that you start unit-testing them. You also start packaging them as "pages, "widgets" or "components". You're still rendering the html on the server side and the data is either in the html or in some pre-rendered JavaScript files. You're switching to CoffeeScript. This phase can be "fine" for many applications.

4. Single Page Application

Single page application is the phase in which you move all of the html generation from the server to the client. There are no full page reloads. Of course, there might be phases between 3 and 4, where some of your html is rendered here, some is rendered there. Luckily, you prefer consistent solutions, so you end up quickly in phase 4.
It's this phase where you think about the frontend as a separate application. All the data you get, come from API requests. You know the difference between MVC here and Model2 on the backend. You explore the different techniques for designing the domain - gui communication.

Any other phase?

In the Sarah's slides you will also find a next phase here - Frameworks. I'm not putting it here, as I think we choose frameworks too early. It's a topic for another blog post.

I'm in the 4th phase for quite a while now and I don't feel any need of a framework.

There's also an interesting area to explore, where you have several mini-application in your web app.

In my next blog posts I'm going to help you learn how to solve typical frontend problems without using a full framework.

Just to be clear, I'm fine with Backbone or AngularJS or others. It's just that I think, that those frameworks can be limiting to our projects very early on.

Which phase are you in?

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

Frontend is a separate application

2012-06-24T11:44:00.000Z

Despite my experience with working on desktop applications, I've been avoiding any frontend (here meaning JavaScript/html) for years.

It wasn't because I didn't know JavaScript, it's just that I am a developer who cares about code quality and JavaScript coding was far from any "quality" areas (in my mind).

I felt safe with programming backends and I was more than happy with Rails. Rails is a framework that is really good at abstracting the frontend problems. It gives you a set of view helpers, so that you can do almost everything in Ruby.

Whenever I had a project that involved more JavaScript (because the UX designer required it) it was a painful experience to me. I just couldn't find a good way of structuring the JS code. I didn't know how to test it well (and yes, I knew Selenium, thank you).

Now I love working on frontends.

Why the change?

I realized that my mental model of a web applications, that I had in my mind, was wrong. I'm guilty of not thinking it through harder in the past. The Rails framework created an illusion for me that the frontend is the View part of the MVC architecture. It's not and Rails is not MVC. It's not only a Rails problem, I think that in most web frameworks we see a similar illusion.

The View part is another application, that Rails happens to generate quite nicely.

The mental process of moving the View from the backend app to a separate application is quite interesting and I hope to cover it another blog post if anyone is interested [UPDATE: I blogged about this process]. I see a similar pattern of transition among my fellow developers.

Once I realized that the JS is in fact another application it was like a whole new world of programming opened to me. With the rise of CoffeeScript it became even more cool. I'm able to use all the patterns from my desktop apps experience (I've been working a lot with Java/Swing apps and on an .NET Windows Forms app with IronPython).

A CoffeeScript (or JS) application can embrace the original vision of MVC. There are new architectural patterns like DCI, which put use cases in front of everything, that fit perfectly well into this kind of apps. There are some concepts from AOP that come back (even Twitter uses them) and are great for domain - gui separation.

Even more, the backend is now an optional part (a plugin) of my project, it's possible to run the frontend application without a Rails backend.

We live in exciting times. The Single Page Applications are becoming more and more popular. I'm no longer a backend-only programmer and I am very happy with that!

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

How to waste time on TDD

2012-06-07T21:33:00.000Z

This blog post was originally written by Piotr Włodarek on his TheSingularity.pl blog. I liked it so much that I translated it to English, so that it can reach a broader audience.

Some people argue that TDD slows down the development process. If you want to follow this opinion here's what you should do:

Write tests after writing the production code.
Waste no time thinking about designing, simply jump straight into the TDD loop and do 100% of the design work there. You'll have a chance to change your code and tests structure over and over again.
Learn how to write test scenarios completely on your own, don't bother watching any screencasts and don't read any books on the topic.
Make sure your tests load at least half a minute before they actually start testing anything. You can easily achieve that by loading the whole framework and working with your old crappy HDD.
Make sure all the features are tested through the GUI (by driving a web browser or desktop GUI window).
Make sure all your tests depend on the database.
Manually find the corresponding test file and the production code.
Navigate between desktops, windows, tabs only to find the tests starting script.
Try to write as few classes as possible to ensure every class has multiple unrelated responsibilities. These are guaranteed to be a testing nightmare.
Write beautiful step definitions in Cucumber even if your customer doesn't care about reading your specs (or perhaps you don't even have a customer yet).

account.transfer(..) - is it good OOP?

2012-05-29T10:37:00.002Z

There is this famous example, that you can find in almost every OOP-related book:

Let's say that account is an object, and you have:

account.transfer(200, target_account)

For some time now, I've had issues with this example.

Is it really a responsibility of the account object to transfer money to another account?

Is it not one of the responsibilities of the Bank object? It just feels weird that an account knows how to do the proper stuff about the complicated transferring use case.

The topic of DCI is really popular recently, which is cool, as it's a very fresh approach to object oriented architectures. The .transfer example in DCI is usually implemented as injecting the SourceAccount and TargetAccount roles to the basic account objects. We change the implementation, but the effect is the same - the account object has the knowledge about the transfer stuff.

Wouldn't it be better if we have this as a responsibility of the Bank object? It could work as a use case or as a role, but both fit better in the bank, in my opinion.

What do you think?

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

Remote company - my talk at the 4developers conference

2012-03-28T11:45:00.000Z

Remote work and remote collaboration are topics that I have experience with for 5 years now.

During that time I started Arkency, the Ruby consulting company that I'm really proud of. There are now 9 Ruby experts in the team and most of the time we collaborate remotely, even though most of us are based in the same city (the beautiful Wrocław, Poland) where we have an office.

Together with my business partners I also started GameBoxed, a company focused on building and selling social games for brands. There are 6 developers in the IT team, but here we also have sales, marketing, design and support teams. Most of the collaboration is done remotely, even though we do have offices in Wrocław and in Warsaw.

Remote collaboration is not a piece of cake. We made some mistakes along the way and we learnt our lessons. There are however huge gains in this way of working, if it's done right.

I want to share the lessons with you. I will be speaking about this topic at the 4developers conference in Poznan, 17-18 April.

How we ended up organizing a Ruby conference

2012-02-17T00:23:00.003Z

It started with a Ruby User Group in Wrocław

It all started with the DRUG meetups. DRUG is a local Ruby user group in Wrocław. As the natural WRUG name was taken by our friends from Warsaw, we have decided to go with D as Dolny Slask, our region in Poland. That's how the awesome name was chosen :)

We gathered together for more than 2 years now. At the start there were about 10 people coming every month. Now it's closer to 20.

The interesting fact about our meetup is that we almost always have like 5-6 talks submitted. Compared to meetups which end up with 1 talk that's quite a difference.

We like to call DRUG a 'conference every month'.

We love sharing opinions and discussions, so we started inviting people from other cities.
We've had guests from Krakow, Silesia, Kopenhagen, Cologne and many other places, we've visited Silesia, Poznan, Trojmiasto, Krakow.

Apart from DRUG meetups there are also DRUG dinners, events at which we just drink beer and discuss, no presentations.

There are also regular DRUG hackathons during which we develop quite a lot of interesting libraries. Bbq and Exceptioner are the ones we're most proud of.

Every day, during our work we like to discuss recent Ruby stuff in the #drug.pl irc channel (freenode).

At some point it was getting quite clear where it's all going to.

We want to organize a conference!

Once the idea came up about a year ago, I don't think there was any discussion if we want to do it. The focus was on "how". Everyone was very excited and the core organizing team set up very quickly.

At first, we decided on the name, date and the venue.

We did a lot of research on what was good/bad on other conferences like Euruko, RuPy, RubyConf etc.

The spirit.

The decision needed to be made if we want to be similar to other conference or shall we go another route.

At some point it was clear that the spirit of our DRUG meetups should shape up the conference. We want it to be about discussions as much as possible. We want it to be about how to make the Ruby world even better than it is.

The idea of fights came up pretty quickly and we're very happy that we kept insisting on it. That's the main conference idea - let's confront different ideas on stage. Let's make it a major part of our conference.

I'm happy to announce the main fights of our conference:

Fight 1 - Rails and OOP

This is all about the recent OOP movements in the Rails world. There are quite a few problems that people focus on and quite a few proposed solutions. We want to cover topics like:

Persistence and domain logic separation
DCI
Backend/frontend separation.
Objects on Rails
TDD
@unclebob ideas - Rails is not your app.

I'm really excited about this "fight". I'm going to blog about this fight more, so stay tuned.

Fight 2 - JRuby vs Rubinius

Which one is better?
Which has the better "support"?
We invited people from both worlds, so the discussion will be of good quality.

Fight 3 - Testing

Shall we keep loving/hating Cucumber?
What about the new tools, like bbq?
Object oriented acceptance testing?
Stubbing or mocking?
TDD - does it make sense?

Agenda and speakers

We didn't just want to invite random famous names from the community. We were focusing on people that fit well with the spirit of our conference. Every talk was carefully chosen. The choice was very difficult as we've had many talks submitted.

What we ended up with is the best Ruby conference agenda I have ever seen. Really.

There's a mission in this conference. We have strong opinions on how some of the Ruby/Rails issues need to be solved. We chosen speakers that are known of their quality and of their strong opinions. We have invited people known of their passion.

Let's have a quick look at some of them:

Apotonick is famous for his REST passion and monolithic apps hate. We share many of his opinions and he is a perfect fit for our conference (also for the parties in the evenings :) ).

Avdi Grimm is the author of the "Objects on Rails" book. This topic makes an important part of our conference.

Steve Klabnik knows a lot about REST and creating API, we're really excited to have him speak on this topic.

The idea of the real DataMapper library that comes with the DataMapper 2 sounds really cool to us and we have Piotr Solnica, its author talking about it.

We have Drogus (Piotr Sarnacki), the Rails commiter, the author of Rails engines.

We believe in distributed apps as the solution to monolithic problems with typical Rails apps. That's why we invited the author of 0MQ - Martin Sústrik. There's also Florian Gilcher talking about "the fear of processes". Krzysztof Kowalik is going to talk about his lessons learnt from the world of distributed apps.

An important track of our conference is the "frontend apps" track. We have Roy Tomeij speaking about creating reusable frontends with CoffeeScript, sass etc.

We have only one talk about testing, but it will be delivered by Michał Czyż, a developer whom I consider an expert in the topic of acceptance testing. I'm looking forward to his talk.

There's also an original talk planned by Michał Taszycki, "the programmer workout".

There's more to it, so just look at the official agenda.

Don't forget that we have an open space planned, so more talk ideas may come up later :)

Do you want to be part of it?

It's going to be a historical event. You don't want to miss it. 5 years from now people will mention the wroc_love.rb 2012 as the breaking moment for the Ruby/Rails community. Watch it live :)

Although the conference didn't start yet, we already know that the wroc_love.rb 2013 is going to happen as well!

For now, let's focus on this year event. It's only 4 weeks from now, March 10-11.

Make sure you have the ticket, book the hotel and travel. Invite your friends.

Check out the conference website.

It's a community-organized conference. Non-profit. Be part of this community.

Let's make it awesome. Thanks!

BTW, Wrocław is one of the nicest cities in the world, ask anyone who has been here.

DCI and Rails, lessons learnt

2012-01-01T19:51:00.001Z

I first learnt about DCI almost one year ago. After some research and experiments, we decided to try it in production projects. Mostly in the GameBoxed project.

My overall summary is that DCI is really awesome. It simplifies the way you think about architectures. Keep in mind, that our research is still in progress, it's not always clear what's the best solution.

At GameBoxed we have one backend application (API) that runs many social games (CoffeeScript frontend applications). Each game can be different, but they share some common things together. The base object/class is a Player. In every game, though, the player can have different behavior. At the controllers level we have a filter that does the main specific-to-game extension, like:

current_player.extend(ItemCollecting::Player)

current_player.extend(Monopoly::Player)

I'm not saying that this is hugely better than using inheritance, but for me it's a "lighter" way of object design. We can now test Monopoly::Player totally on its own, without all the base player responsibilities.

At the level of the CoffeeScript applications we also use some DCI ideas, like constructing habits and use-cases (invite-friends, start-game, choose-prize). We're still in the process of finding the best design, but in my opinion the DCI way of thinking really helps in designing all of that.

DCI reduces the number of objects in your project, but increases the number of roles they play. For me, it's easier to understand and think this way. In our case (the social games) the main objects interacting with each other are: Player, Game, Prize, Friends. Many other things *could* be a role (it doesn't have to). In the monopoly game, the Board can just be a role of the game object.

The idea of use-cases, habits (as explained in the "Lean architecture" book), can make your architecture more explicit.

It's not only roses, though. Here are some problems and my comments about the problems.

1. If not all of your team is truly convinced to DCI, then don't start with that. Even if only one person in a team doesn't get DCI it can make it very hard. As with every "new" thing, it requires more education. Experiments are fine, but at some point the whole team needs to have a common "mental model" of the system you're working on.

2. Using DCI at the level of ActiveRecord classes is wrong. We felt into this trap. DCI makes more sense at the OOP level. That's why I'm focusing so much about separating the two. One problem we've had was that, even though we extended some objects in "contexts", the same objects retrieved from AR again (without Identity Map) didn't have the roles. Thus the need for extending them again, deep in the models.

3. Extending objects with roles should be at the context level. We've had some extending at the model level (due to the lack of IdentityMap in Rails 3.0, now that we've upgraded to Rails 3.1 this problem disappears). This quickly leads to a mess. It's also a problem of using ActiveRecord "objects" with DCI. Use ActiveRecord only for persistence, not for domain logic.

4. DCI without contexts/use-cases is useless. We were not disciplined enough to have contexts everywhere and problems appeared quickly. I need to stress it more - DCI is not (only) about dynamically extended objects. It's much more than that. You need to start thinking in use cases.

Let me know if you're interested in other lessons from using DCI.

Rails is still cool

2011-12-30T21:45:00.000Z

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

2011-12-30T00:55:00.000Z

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

2011-12-18T21:16:00.000Z

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

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

2011-12-16T18:54:00.000Z

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:

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

Example:

Buying a product.

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

Continuous integration - some tips

2011-12-06T00:48:00.001Z

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

2011-12-04T20:34:00.001Z

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.

Rails is not MVC

2011-09-25T10:36:00.000Z

There is a terminology problem in the Rails community.

Everyone promotes Rails as a MVC framework. I did that as well. However, the truth is that Rails represents the Model2 architecture. It's not MVC.

I know it's just a definition issue. Maybe we shouldn't care. It wasn't really a problem until recently. We see the rise of the JavaScript MVC topic, which is an awesome thing. The browser clients with its JS engines can have a real MVC, as opposed to Model2.

OK, so what's the difference?

In short, we're talking about MVC when a model can notify (through the Observer pattern) the views about the changes. It's not possible in a classical Rails app (it's possible when you use WebSockets, Pusher or a similar technology, but it's not so popular yet.). MVC was popular in desktop apps.

On the other hand, Model2 is exactly what we do with Rails. We don't notify the views from the model, the controller simply passes the model data to the views and handles the html generation which is then sent to the browser.

There's an interesting pattern evolving recently that a Rails app simply serves as a backend for a mobile app and all it does is exposing a JSON/REST API. It's similar to Model2, but instead of generating HTML it generates JSON. Still, it's not MVC.

You can read more about UI architectures in this article by Martin Fowler

Why is it important?

It's becoming an issue now, because we start talking more about the JavaScript MVC. The JavaScript MVC is a real MVC. The models can easily notify the views. Often, when you talk to people being introduced to the JS MVC they seem to be confused and try to implement the Model2 pattern on the client side, which in my opinion is ridiculous.

What shall we do about the Model2 and MVC confusion?

I see three choices.

The first one is to say that MVC changed its original meaning and Model2 can also be called MVC. In that case we can start using terms like "classic MVC" or "real MVC" for the old MVC. This is what is happening now, but I don't think that changing definitions is a good idea. It brings even more confusion.

The second way is to promote the fact that Rails represents a Model2 architecture and MVC is reserved to, well, MVC. It's going to be hard, but we will keep the definitions stable.

The third way is to just ignore the confusion. Who cares?

I decided to go with the second option. What's the best way in your opinion?

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

3 steps to MVC in JavaScript

2011-09-24T19:12:00.000Z

Read this article MVC Architecture for JavaScript Applications by Peter Michaux. It's a must-read and it nicely explains how the observer pattern works in the classic MVC. (Keep in mind that the MVC that you know from Rails/Django is a limited MVC, that's a topic for another post).
Use Backbone and Underscore to handle events or roll your own observer mechanism (as described in Peter's article).
(optional) Use CoffeeScript to make your code prettier.

Let me quote Peter Michaux:

In a nutshell the classic MVC architecture work like this. There is a model that is at the heart of the whole thing. If the model changes, it notifies its observers that a change occurred. The view is the stuff you can see and the view observes the model. When the view is notified that the model has changed, the view changes its appearance. The user can interact with the view (e.g. clicking stuff) but the view doesn’t know what to do. So the view tells the controller what the user did and assumes the controller knows what to do. The controller appropriately changes the model. And around and around it goes.

In the GameBoxed platform, we have a Monopoly-like Facebook game. There's a concept of a player (this is the model). A player, after rolling a dice, can receive points and when he does we need to update the player-details box.

When the page is loaded (our games are one-page apps, no full reloads), the Monopoly object is initialized. It's a facade object responsible for initializing models, views and controllers and wiring them together.

At some point thanks to some users actions the player.addPoints method is called which triggers the "player:updated" event with some arguments. Thanks to the controller (the bind method), the PlayerView object is notified that something interesting happened and the view updates the html (with some jquery helpers).

This pattern is very useful and can be used in most of the typical UI scenarios. Let me know what you think about it.
If you read this far you should and subscribe to my RSS.