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.
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.
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 :)
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.
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:
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
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.
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.
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!
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:
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.
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.
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 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
Objects on Rails
@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.
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:
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.