Remote company - my talk at the 4developers conference

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

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

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) 

or

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

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)