How we work pt. 2: 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.


How we work pt. 1: A portable boss.

Mirek Wozniak June 19, 2013

We’re agile here at Lunar Logic. We didn’t invent gunpowder, these times _everybody _is agile. And that’s a good thing. But not every company has got a portable boss, has it?

Meet Paweł. A laptop desk, a bean bag and a recycled cardboard box – that’s all he needs to set up a flying office. He can usually be found in a few rooms in our office, shifting his spot couple of times a day. Or a week. The pattern changes. Not only because of a possible back pain – there are several reasons for him being in motion. Some of which have already changed our company.

I’ve decided to present this method of floor-rule from the viewpoint of the crew of our hierarchically flat company. It’s worth noting that he’s also been the scrum master for some months now and a project manager of one inside work of ours lately, so the working relations between him and various people at the company vary.

Paweł Brodziński flying office

Why am I writing this, and not Paweł? Firstly, because he already wrote about his flying desk. Secondly, he’s still the boss and the answer’s he’d receive could be a bit biased. His opinion is here, nonetheless.

So – do you like having a portable boss?

Mirek (marketing guy)

I’m in two minds here. On the one hand, it’s grand when the boss’s your buddy sitting next to you, going together for your daily caffeine fix, cracking jokes and ridiculing one another. He doesn’t feel so detached as if he was confined in his office, behind a massive slab of a desk. More… human? I’d say.

On the other hand, I can’t fully feel at ease when having him around. My harmless slacking over yet another TechCrunch article I must read makes me uneasy, for it doesn’t yield palpable results. Somehow I experience a state of a constant standup – it feels bad to say “I haven’t done anything today” even though I know I was busy.

However, the more tangibly productive I am, the less I’m aware of the boss in the room and the more of a peer, who just decides about things.

Hania (coder)

Paweł is a scrum master in my project. I grew so accustomed to him being around that when he’s not present, I’m wondering what’s the reason. His presence in our room makes him aware of the problems on the spot and not only at the retrospective. It also levels the traces of hierarchy that exist in our company to nil.

Grzester (QA)

I don’t have to run around to find the boss when he’s needed. He’s not tucked in a room, sheltered behind a desk and closed doors. There is no artificial barrier between us and him.

There is no “boss” – just a member of the project, who also is the project manager. I think that the integration does the trick – a “traditional” chief with all the trappings of a big leader wouldn’t be able to mold with us so easily.

Tomek (coder)

I’ve finally witnessed what CEOs do. This role was overlapped, however, by his actions as the project manager. Deliberately, Paweł has become our peer, whether he liked it or not (and he rather liked it ;).

Paweł (the culprit)

I can grab my flying office in my hands and move it to the place where I’m needed or I feel like I can be helpful. I need just a bit of space in a corner or by the wall and done – a new office set up.

Surprisingly, sitting in the corner and almost on the floor has a few unexpected advantages . First, you need very little physical space, which means you will fit to almost any room (unless it is already packed beyond any healthy limits). Second, this way you become almost invisible, which definitely helps if your goal is to understand how the team functions, and not just scratch the surface.

Third, and arguably most importantly, you strip yourself from status symbols. Instead of a huge desk dubbed by your colleagues as the airstrip, a leather armchair and a locker just the simplest set that does the job.

All in all, you’re way more accessible and much less intimidating. Isn’t that something every single leader should strive for?

It’s a big step

I’ve been very cautious not to say that something “depends“. I believe that this word strips a thought of its power. Truly, being a portable boss takes guts. Be prepared to experience uneasiness and awkward looks and situations.

Of course, it is easier for an accomplished extrovert to become a flying Dutchman in his office. It doesn’t mean, though, that, given favorable company culture, a timid number cruncher shouldn’t change his working place every once in a while.

Especially if they used to live in their office, behind a huge desk and closed doors.

Stay tuned for How we Work pt. 2. You’ll see our happiness measurement system.

Synchronization using CouchDB

Anna Ślimak June 3, 2013

Why is synchronization so important?

More and more web apps have their mobile equivalents; it is prudent to add offline functionality to mobile apps. Here’s where the real problem unravels – how to optimally synchronize data saved on the mobile with changes in the web app?

What if a mobile user saved some data offline which was being simultaneously edited online? Which version should be selected as the up-to-date one? How to implement solutions for such conflicts?

Implementation of the above mentioned synchronization isn’t easy – there’s a lot of edge cases, it requires a well-thought-out protocol, special metadata (e.g. revision tree) and it has to be able to resolve conflicts. And there aren’t any shortcuts like “the simplest” synchronization type. The implementation of even the least complicated version requires an awful lot of work and causes many problems.

We’ve tried to introduce such “simplest” type in Kanbanery and it really got on our nerves. I’ve started to wonder back then: “Isn’t there a better way to achieve the recently much-wanted functionality?

I really liked this quote I had found on GitHub:

Some mobile developers have waded into ad-hoc sync implementations and found themselves over their heads, with delayed or canceled products. It’s better to use a solution that already works.

It turned out that the “solution” mentioned was CouchDB and the person cited, Jens Alfke, is the co-author of Couchbase Lite, a library that implements CouchDB protocol on iOS.

Why use Couchbase Lite?

Mainly because it’s lightweight. It has small code size, quick startup, low memory usage and good enough performance.

It is using sqlite as the database engine instead of real CouchDB embedded on mobile because it’s more efficient. There used to be an implementation using CouchDB, but it was impossible to optimize it so the library was completely rewritten. However, due to its use of an efficient and reliable REST-based protocol pioneered by Apache CouchDB it is fully able to synchronize with real CouchDB instance.

This synchronization can be on-demand or continuous. Conflicts can be detected and resolved. Synchronization is handled using the replication feature of CouchDB.

Conceptually, it’s very simple – just take everything that’s changed in database A and copy it over to database B. Replication has several properties – there are push and pull replications (depends on if the source is remote or not), continuous (keeps connection opened and waits for changes) or one-shot, persistent or non-persistent.

Everything sounds great,

but what if you don’t want to download all the users with all their data to your small mobile app (which is kind of pretty common)? Use filters!  Just define a method which will decide which data you want to synchronize :]

To get everything working on iOS side you need to have the Couchbase Lite framework.

Next step – database setup:

An example of a model definition:

To retrieve user records by email, you have to define the view:

And then you can make a query like that:

CBLQuery has also property called rowsIfChanged, which returns new rows values if they’ve changed, so you can register observer to that property and watch for changes that way.

But if you want to just display your data in some kind of UITableView there is a more handy solution – CBLUITableSource. It refreshes data as soon as it changes – an instant gratification!

To use it you have to:

  • put one in the same xib as your table view,
  • set its tableView property to your table view (it’s IBOutlet so you can just wire it up),
  • set its query property to live query:
  • set its labelProperty to text that you want to display or use CBLUITableDelegate protocol:

Can I finally start replication?

Yes, all you need to replicate is to run the following code:

Meantime in the Ruby world…

There is the couchrest_model gem that you can use in Ruby side to communicate with CouchDB.

It is very straightforward to use. Here you have an example of a model definition:

Because of views defined in design section you can retrieve records like this:

A defining filter that tells the protocol to synchronize only the documents which describe posts and belong to the requested user would look like this:

The only thing left to do is to send these definitions to the CouchDB instance. It should be done as quickly as possible, as mobile application also should be able to use it when connecting to the CouchDB instance.

The best way to do that is put the code below to config/initializers/couchdb.rb.

The code is iterating through your CouchRest::Model’s and pushing it’s designs definitions to CouchDB server.

But what about conflicts?

If document is edited both offline and online, so if there is a conflict, it will have the have _conflicts key.

So on iOS you can create a view to retrieve conflicting documents:

The document usually has one current revision, but when a conflict occurs, the protocol is keeping all conflicting revisions in order to give you a chance to resolve the conflict manually.

Below there is an Objective-C example of retrieving conflicting revisions properties:

If you’re going to create some kind of UI displaying these conflicts and let user decide what should be chosen, then you should not delete needed revisions and optionally merge contents from them to one chosen by user. However, if you don’t want to resolve conflicts manually, the protocol will preserve the illusion that there is no conflict by arbitrarily choosing one of the current revisions for you (the one with lexicographically higher revision ID).

Example projects

You can find both the web application and the iPhone client example projects on my github account, demonstrating all the things I mentioned here.


CouchDB *just* works and a bunch of people is working on it trying to make it more and more efficient. Don’t go mad implementing such complicated thing from scratch. Use CouchDB.

Do you prefer Rails to holidays? Is being cool in a cool room more appealing to you than sitting on the beach? Here’s a recipe for doing something awesome in the upcoming summer:

If you’re still wondering whether you should apply, here are some words from our last year interns – Ania and Artur. You can meet them at our office, busy doing great design/front-end and RoR work.


Ania Migas The internship was superb – I’ve learned a lot more within 3 months here than within 3 years of studies. I had a chance to learn from the best – our designers really rock! – and use the most recent technologies. Every day I had an opportunity to get feedback on what I was doing and to hear useful tips. I was shocked when I received a Kudos just after a week of work and amendments in a commercial project only after 1,5 month!


Artur Trzop The summer internship @ LL made me realise how important testing software is. I’ve learned about lots of useful tools and technologies and became a decent Vim user :) The help and experience from older workmates is invaluable – pair programming and code reviews helped me learn faster and cooperate better. What is more, developing projects along the Scrum and Kanban methodology lines allowed me to learn them from the practical side.

So, what are your plans for this summer?

Railsberry 2013 – a Curious Mission Report

Mirek Wozniak April 30, 2013

The most curious Rails developers invaded Krakow last week, so we led an invasion party of our own :)

Words of Jul:

Railsberry was my first conference for developers and it set the bar really, really high. It was incredibly well organized, the sun was shining, people were happy, speakers were amazing, there were swings and a DJ, yummy food, sunbeds and good parties. And gadgets, gotta love the gadgets ;)

Here are 3 of the many thoughts that stuck with me after the event:

Sometimes it’s better to use direct queries and take full advantage of the features of your database instead of always doing things the Rails way – from Agnieszka Figiel’s presentation about Słonik.

Overdoing usability can be dangerous. When a login form tells the user that their password was incorrect, the bad guys know that the login exists and can brute-force it away. It’s obvious to me now, but it’s easy to miss when you’re designing a user friendly interface… or when you’re a forgetful and irritable user ;) – from Paolo Perego’s presentation on security.

We associate creativity with being human (or maybe the other way around), but if we accept the fact that the processes involved are often unconscious, we might want to consider attributing creativity to machines. True, machines can only generate things from what we put into them, but isn’t this true about us as well? Especially if you’re an empiricist that isn’t afraid of determinism ;) So maybe being unpredictable, beautiful and cool is enough to call something creative – from Joseph Wilk’s talk about creative machines.

As you can see, the talks were very diverse and I loved it. After all, we’re an agile, poly-skilled, curious bunch. I will definitely be at the next Railsberry.

Fred George on stage #railsberry

A post shared by railsberry2013 (@railsberry2013) on

Hania & Ania L.’s report:

A pink unicorn, lots of baloons and two interesting presentations were the highlights of the first day:

“Experiment”Chad Fowler presented very curious thoughts, approach to life and to coding :)  It encouraged you to treat everything as an experiment, without the fear of failure. A big refactor or keeping fit is way easier with this in mind :)

“Agile is the New Black” – a nice presentation about methodology by Fred George, though a bit too radical. Isn’t Agile meant to be resistant to changing circumstances?

Besides that it was great to learn why you should use PostgreSQL and that it’s sometimes better to let the database do its work rather than limit yourself with ActiveRecord. Yes, we admit it – we had our share of fun gossiping with @agnessa480 :)


I was especially enthralled by Joseph Wilk’s talk, especially because of the fact that I still think about connecting what I do with the world of music (Creative Machines).

Joseph Wilk

A post shared by railsberry2013 (@railsberry2013) on


Gregg Pollack gave a very motivating presentation. I had already heard about the e-learning sites he enumerated, yet it took this presentation to convince me to use them.

All in all, the presentations were of high quality and the place abounded in attractions and ways to have fun. The conference itself was neatly organised and we think the Stara Zajezdnia (the venue) had an awesome feel; extra decorations, such as swings and deckchairs made us feel like being on holidays. The conference ended with an awesome flying drone show – the harmless drones, mind you :)

#railsberry crowd getting ready for the start!

A post shared by railsberry2013 (@railsberry2013) on

Ania Migas says:

Railsberry was like a kindergarten for programmers and all kind of people connected with IT – there were augmented reality workshops, swings, flying robots, muffins and all kinds of fun stuff you could imagine.

I really liked the talk by Gregg Pollack – I learned a lot more about e-learning than I had already knew. The Joseph Wilk’s talk about Creative Machines just blew my mind – he presented something that could be called artificial thinking – the computers were creating their own melodies. Of course, as a part of a super-agile company I couldn’t miss the opportunity to check how agile actually we are during Fred George’s talk – we did pretty well! :)

Artur’s thoughts:

The first day of the conference went on really well. The first talk by Chad Fowler was a experiment on its own, for it was created in tpp. The second talk was probably the best presentation that day – Fred Gorge elaborated on “Agile is the New Black” idea: what struck me the most is the idea that bug tracking systems are bad, because they they make bug fixing in apps longer. It’s so easy to put something aside knowing that it’s saved somewhere. But is leaving bugs for later such a good decision?

The second day met us with sun and another dose of experiments. Marcin Bunsch & Antek Piechnik riveted audience’s attention with their “Shipping Post-PC” breakfast conversation. They staged an interesting show, with  used as a example of a model Post-PC app. The second presentation that captivated us was “Programming Flying Robots With JavaScript” by Felix Geisendoerfer. The flying robot received a storm of applause :)

Lucek speaks!

Boredom was prohibited; there was not a single too long or wearisome presentation in the agenda. Fred George proved that Lunar Logic is the most agile of the agile companies and Agnieszka Figiel shown us magic tricks while searching for records in the PostgreSQL base. Katrina Owen and Pablo Perego put forth ways of maximising the benefits deriving from application tests and Greg Pollack touched on the subject of the lately popular e-learning platforms (Vim Adventures FTW :D).