Thursday, December 6, 2012

What is a framework?

The title question made me struggle for months.

  1. What is a framework?
  2. What is the difference between a library and a framework?
  3. If I use a framework as a library, does it make it a library?
  4. Is Rails a framework?
  5. Is Backbone a framework?
Can you help me with your answers?



Monday, August 27, 2012

Rails legacy applications

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

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

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

What's the reward?

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

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

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

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


Having fun with legacy apps from Michał Łomnicki

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

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

Sunday, August 26, 2012

Is CoffeeScript better than Ruby?

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

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

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

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

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

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

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

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

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

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

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

Monday, July 16, 2012

JS frontends are like desktop apps

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.

Monday, June 25, 2012

From backend to frontend - the mental transition

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 Follow andrzejkrzywda on Twitter and subscribe to my RSS.

Sunday, June 24, 2012

Frontend is a separate application

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 Follow andrzejkrzywda on Twitter and subscribe to my RSS.

Thursday, June 7, 2012

How to waste time on TDD

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:

  1. Write tests after writing the production code.
  2. 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. 
  3. 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. 
  4. 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. 
  5. Make sure all the features are tested through the GUI (by driving a web browser or desktop GUI window). 
  6. Make sure all your tests depend on the database. 
  7. Manually find the corresponding test file and the production code. 
  8. Navigate between desktops, windows, tabs only to find the tests starting script. 
  9. Try to write as few classes as possible to ensure every class has multiple unrelated responsibilities. These are guaranteed to be a testing nightmare. 
  10. 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).

Tuesday, May 29, 2012

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

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 Follow andrzejkrzywda on Twitter and subscribe to my RSS.

Wednesday, March 28, 2012

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.

Friday, February 17, 2012

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.

Sunday, January 1, 2012

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.