Google - lessons learned

Mirek Wozniak July 15, 2013

Google is an internet behemoth, isn’t it? A single G team is bigger than whole Lunar. And it’s Google. They know everything. Yet they’re still interested in smaller companies than theirs.

We’ve met a gang of Google’s Product Manager freshmen last Friday. They came to our office to learn how Lunar Logic works. Why?

Imagine that you finish your college and get employed by Google. Straight away. As a product manager.

That’s more or less what the Associate Product Manager programme is about. Google wants young people unsullied by the traditional management approach. You’ve got to excel at maths etc., but you get loads of perks. One of them is travelling across the globe to visit other software companies. To learn & compare their approach with that of other players. Simple!

Google’s management freshmen learned about our flat structure, resulting in having only one PM of our own (Paweł Brodziński). Also being a scrum master and CEO as well.

We’ve told them about our smashing parliament watch app that never got released due to a revolution in a certain middle eastern country… that was quite philosophical, actually!

And we found out that Google is more technocratic than it seems. It manifests in the technical people having more to say in product development than e.g. marketing depts. Which doesn’t mean they’ve got nothing to say, of course.

It’s a pity we didn’t have more time, for the visit was very inspiring. Hope we get more of such in the future :)

How to declutter your lib directory

Kuba Suder July 8, 2013

If you’re working on a Rails app, let’s do a quick test: check how many files you have in the lib directory of your project. If you have less than 10, it must be a fairly new project. Most projects I’ve seen have at least 20-30. In our current project we had over 200 of them a few months ago…

The problem with the lib directory is that there are no official guidelines of what we should do there. Rails has a well-defined directory structure, which is great because you don’t have to think of how to organize your code since all the directories covering controllers, models, views, etc… are set up from the beginning. The downside is that once you start creating files that don’t fall into any of the predefined categories, it’s hard to decide what to do with them. So they usually end up in lib, which becomes a real mess over time.

I started searching for a solution – I asked on Twitter and looked for any relevant blog posts. The best idea I found was the one presented by Bryan Helmkamp:

I recommend any code that is not specific to the domain of the application goes in lib/. Now the issue is how to define “specific to the domain”. I apply a litmus test that almost always provides a clear answer: If instead of my app, I were building a social networking site for pet turtles (let’s call it MyTurtleFaceSpace) is there a chance I would use this code?

That makes perfect sense: the app directory is for your app’s code, as the name implies. All of it – not just assets, controllers, helpers, mailers, models and views, just because these are the subdirectories that Rails creates by default. You can always make your own.

So what exactly did we find in our lib directory?

Resque jobs

If you use any background queue library such as Delayed Job or Resque, you probably have a collection of classes for the tasks performed in the background. In our project we have a whole directory tree consisting of Resque job files – guess where we had to put them? In lib of course, specifically in lib/queues.

But the background jobs are an integral part of the app, they perform work that would normally be done by controllers or models, and usually call in some other models, except they do it asynchronously. So, according to the rule mentioned above, they should be put somewhere inside the app directory. Of course there was no pre-configured directory where we could put them all, but that doesn’t mean we can’t add one, and that’s what we did – so the Resque classes were moved to app/jobs.

Decorators & presenters

We also have quite a large directory with decorator or presenter classes, which we have put in to app/decorators. These are all support classes for rendering views that present models to them in some way; most of the time it’s about rendering model data to JSON which is used by API controllers. We also have some presenters used by standard HTML views, which organize records into some specific type of hierarchy that a particular partial requires, in order to move the logic out of ERB partials (or models).


Concerns are with modules that are intended to be included in other classes and are used for sharing code between a group of related classes, e.g. models or controllers. This concept was popularized by DHH and 37signals and is now officially supported in Rails 4 – Rails now auto-generates app/controllers/concerns and app/models/concerns directories and adds them to the autoloading list.

This feature is a bit controversial and there are some people who say that there’s no place for such thing in good Rails apps. I disagree – I think concerns are OK unless they’re overused.

If you have 200-lines-long concern modules that are included everywhere, or if you have as many concerns as you have models, you’re probably doing something wrong – any bigger and isolated pieces of functionality from concerns should be extracted to some separate, independent classes. But if you have a few short modules with just a couple of short methods each, that doesn’t do any harm at all and can make your code shorter and more DRY. One example could be when a few models have a field with the same name (e.g. enabled) and you want to share some setters, scopes or finders that deal with that field, which would look exactly the same in all of those models.

The concerns support added in Rails 4 is really just a change to generators and the autoloading list, so you can add this yourself easily to your Rails 3 apps. We’ve also added app/decorators/concerns which holds a couple of shared modules used by presenters.


Another non-standard directory that we’ve added is app/services, in which we keep a group of classes and modules that don’t belong to any other category such as models or presenters, but are still specific to this project’s domain. This is a pretty broad category, though not as broad as the old lib directory (right now we have about 40 files and directories in it). Some services are classes that you make instances of, some are modules that you use directly and some are whole directories of a few cooperating classes grouped in a namespace.

The name “service” comes from a pattern called Service Object which is gaining some popularity in the Rails community recently, and it’s basically about extracting pieces of specific functionality that would be normally written in a model or a controller to a separate class or module. The reason is that if you put everything that a user can do into the User model, as is often the case at the beginning of a project, this model can grow to hundreds or thousands of lines of code over time (user.rb is often the most complex class in a Rails project).


A few files from lib actually ended up in the app/models directory. The purpose of app/models seems to be clear, until you start thinking about it: what is a model really? Is it just for subclasses of ActiveRecord (or ROM/Mongoid/etc.), which represent tables in your database, or is it for all classes which are part of your model layer, regardless of how they’re implemented? At what point it’s not a model anymore, but rather a service?

We’ve decided not to restrict app/models only to ActiveRecord models, but instead just use common sense to decide what should go there. Some rough guidelines that we’ve used were:

  • AR models go to models
  • classes whose purpose is to store and fetch data from Redis structures also go to models – after all, the only difference from AR models is that they use a different storage backend
  • classes that are mostly about storing and accessing data, validations, calculations etc. should rather go to models
  • classes that are about interaction, doing, changing or sending something (often with names like “Creator”, “Handler”, “Uploader”, etc…) go to services
  • groups of classes in a namespace usually go to services (e.g. Auth module that implements various kinds of authentication or an ABTesting module which handles A/B tests)

Monkey patches

The Ruby open classes feature that allows you to monkey-patch other people’s code is a great thing. Even though it’s considered dangerous, it’s often hard to resist because it’s so easy and gives you power to change anything you want. We also had a bunch of monkey patches for other classes scattered over the project, mostly somewhere in lib and in config/initializers. Now we’ve moved them all to lib, divided into two groups.

The first one, lib/ext, is for extensions to core Ruby classes such as Array or String. There aren’t a lot of these, but sometimes you really want that core class to have that particular method instead of having to wrap the objects with something. The other directory is lib/hacks and it’s meant for, well, hacks; the files that should ideally not exist at all, and will hopefully be removed in the future, but for now they have to be there because the world is not perfect and sometimes you just have to hack something to make it work. At least this way we clearly see how many of those we have – this is similar to the idea of having a shame.css stylesheet that keeps all the ugly CSS you aren’t proud of, isolated from the rest of the code.

What stays in lib

The lib directory should ideally contain only those files that are generic and reusable (those that could be useful in the turtle social networking site). Things like a basic interface to some web service, database tools, asset processors or compressors definitely belong there. On the other hand, things that use words like “user”, “game”, “event” or any other words that appear in your model names probably don’t belong in lib.

Here are my guidelines for a proper lib file:

  • it should not access any of your models, services or anything else from the app in any way
  • it can only access other libs, Ruby core libraries or stuff from gems
  • it should not rely on any global variables, constants or ENV variables to be defined
  • it should be easily extracted to a gem and put on GitHub and RubyGems without too much effort

If it needs some small amount of project-specific configuration (e.g. an API key for a web service), make it possible for external configuration, just like you’d do if you wanted to put it in a gem, e.g.:

# lib/twitter_poster.rb

module TwitterPoster
mattr_accessor :api_key
# config/initializers/twitter.rb

TwitterPoster.api_key = 'qwerty'

At the moment we have just 46 Ruby files in lib, including the extensions and hacks.

Other approaches

This list is clearly not a complete solution that covers every possible case in every Rails project; every project is different, each has a different set of features and is built slightly differently. Not everyone agrees that the Rails conventions are something that you should try to stick with, and some people in the community argue that you should build your whole app separately from Rails and only use the app directory to build an interface between Rails and the core of your app. I wouldn’t go that far, but I’d agree that you should only treat the default directory structure as a starting point and then modify it according to your needs – where you end up will depend on your application’s complexity, architecture and your team’s preferences.

WebVisions 2013

Julia Jacobs July 4, 2013

¡Hola! I saw the future of the web and it was mobile, user-centered and fun to develop. I also saw Barcelona and it was loud, sunny and amazing, but you don’t want to read about that, right? So let me share some of my thoughts after WebVisions and a few ideas that seem most important to me as a web developer.

Park Güell It seems like by now everyone knows the importance of responsive design. This is an old idea. Yet a lot of developers – and clients – just don’t care enough. Mobile devices are still something to consider only after the desktop version of a web app is ready and rolling. Contrary to common sense, responsive web design still isn’t the default way of doing things. Why? Let it finally be the rule, not just a feature.

Both from a materialistic, business-like point of view and from a moral, open-sourcey perspective, taking mobile devices into consideration is worth it. As Dave Shea pointed out, it’s super-safe to say that mobile design increases sales 2 times. In fact it is usually much more, closer to 3, 4 or even 5 times. But also – think of everyone, think of Africa, target new markets where there’s just no good desktop base, but a pretty good mobile infrastructure is emerging (Chris Heilmann).

Yes, creating responsive layouts is hard, and that’s why new cool web standards are being developed to make our work easier and more fun. At WebVisions we could hear about them straight from the friendly hardcore-looking blokes that are making it happen.

For example, check out flexbox. It’s only partially supported at the moment, still difficult to use and may hit performance, but man, it will rock when it’s sorted out! Imagine easily reordering and resizing elements with a few lines of CSS instead of resorting to time-consuming workarounds and dirty hacks.

WebVisions Venue - CCCB We know that devices lie – that’s why we have to remember about meta viewport. But like Bruce Lawson said, forcing the way of presentation in HTML is what Satan does and that’s why there’s a proposal of a @viewport CSS rule.

Soon we will be able to use much more precise media queries, such as @media (hover) for detecting if a device can hover, or @media (pointer: none/fine/coarse) that would tell you whether a device has a fine mouse pointer or rather limited pointing accuracy, as with touch screens.

And how cool are viewport units? Very cool. And you can almost use them :)

Just one more thing: FirefoxOS is out and if you haven’t heard about it yet, you should read why Chris Heilmann is so psyched about it. It’s awesome because there are no native apps – they are written in the same web technologies we use and love. This new system’s goal is to provide high quality experience while being accessible to everybody, with regard to both users and developers.

Here are some beautiful, beautiful slides from the conference that are totally worth checking out:

Kanban Leadership Retreat

Paweł Brodziński July 1, 2013

The crucial part of running a learning organization, and this is definitely one of key principle we live by in Lunar Logic, is actively looking for new ideas and new sources of inspiration. Of course we don’t shy away from adopting proven techniques or improve our current practices but to stay a cutting edge company we need fresh ideas every now and then. This is the fuel of our organizational evolution and as we know

It is not necessary to change. Survival is not mandatory.

– W.E. Deming

That’s why we’ve sent our whole management team (OK, it’s only me and Paul) to Kanban Leadership Retreat. For those of you unfamiliar with the event it’s an unconference for leaders of Lean Kanban community that is held twice a year. You can find my impressions after the first edition here.

The unconference format is tricky. I’ve seen many of such events going terribly wrong, failing to attract enough people or deliver value for those who attend. Not this time. Kanban Leadership Retreat (or klrat) is a safe bet. One can be 100% sure that the right people will show up.

And when I say the right people I mean that you can learn from every single attendee. Virtually everyone. People would bring their own unique experiences to find patterns or coherence with the experience of others. They’d share their genuine ideas to validate them or bring them to a new level. There’s no default assumption that someone is right and there’s agreement to disagreement.

If it wasn’t enough you’d meet people like Troy Magennis who’d blow your head out in 15 minutes showing you how your assumptions on e.g. estimation are totally wrong. And it’s not only a chance to sit on Troy’s session. It’s a chance to spend hours with him discussing your own context and problems.

You’d meet awesome fellows from TLC (probably the only company on planet Earth that could steal me from Lunar right now): Jabe Bloom and Simon Marcus. It’s a chance to exchange experiences with other people sharing your mindset who also work in the trenches and aren’t afraid of getting their hands dirty.

You’d have a chance to bounce off your ideas of people are interested in the same subjects as you are. In my case this role was neatly played by Andy Carmichael (among others) as he shares my passion toward Portfolio Kanban.

Finally, you’d be able to challenge the very leaders of the community whenever your experience is not aligned with the concepts they share.

After two days I’m coming home with better understanding how we should manage work in our context, whole set of new ideas around Portfolio Kanban, a handful of experiments to try out, especially around estimates, and even more ideas that will influence the way we work. A short version is: my mind has been blown away.

This is why every senior manager who cares about evolving their organization should be there. If they have a chance, that is. Don’t forget that Kanban Leadership Retreat is limited to 50 people, which is one of the reasons of its high quality.

I just don’t know whether I should be happy or sad seeing how few company leaders care to learn on that level. I mean, this is a clear competitive advantage we do have. We understand how the work gets done and what it takes to be effective and build trust with our clients. Interestingly enough it seems that such an approach is very rare in our industry.

At the same time I feel for all the people stuck in the common ways of building software. Clients wasting their money on ineffective work, having limited visibility what is happening in their projects and getting low-quality products. Vendors building the wrong stuff, being squeezed to work overtime as they can’t keep their promises, compromising quality of their work and their own pride in workmanship. That’s just sad. Yet oh so common.

It won’t change unless we go out of our boxes to see what is happening in management methods. It won’t change unless we move ourselves out of our comfort zones of “we are unique.” It won’t change unless we invest enough effort into learning new things.

Kanban Leadership Retreat is the event where you can do all of that (and more). All the learning that I experience there helps to bring me as a leader and the company to another level.

This is why I wouldn’t hesitate a second to sign up for the next year retreat if only was an option to do so. Neither should you if you have a chance to be there next year.

Measurable Happiness

Mirek Wozniak June 27, 2013

Hello! Please, tell us how you feel.

We do this in many ways: send Kudos, submit a topic during the weekly lean coffee, have a real coffee in our comfy kitchen or…

Draw a smiley on a whiteboard.

Happiness Chart

Or beer. Or Pacman. It’s up to you.

The Happiness Chart is a kind of universal mood indicator. We draw shapes on our whiteboard after each stand-up to tell others about our day. Green goes for “happy”, blue for “so-so” and red means “sad”.

That’s it! And it works – a couple of :( in a row show that something’s wrong. Get up and do something about it.

If paired with a project management tool (we use our own Kanbanery), you may evaluate which tasks your team drudged through and which made their day.

The chart is 100% transparent, just hanging on the wall for everyone to see. Maybe a passer-by got a solution that the whole team was looking for last week? Or a cute cat picture to lighten the atmosphere?

There’s another reason why we use happiness charts. According to some stereotypical belief, programmers aren’t very keen on talking about their emotions.

Writing them down, compressing into three “states” (happy, so-so, sad) – that’s a different story.