We’re going to Railsberry!

Mirek Wozniak April 8, 2013

7-strong! Tough! Ready for action! Lunar Crew is going to Railsberry.

We couldn’t miss a Rails conference in our own, beautiful Krakow.
And a conference for curious Rails devs? We were unable to resist!

This masterpiece comes straight from our Applicake mates and we can’t wait to dive into the world of Rails, especially served in such a scientific manner :)

Railsberry 2013 teaser

What’s more? Check out the railsberry blog and  meet us in the cheerful, Ruby-coloured crowd! And expect a mission report after the conference :)

The Space Rocket Kola Experiment

Mirek Wozniak April 2, 2013

What’s the easiest way to grab the attention of a Rubyist on a big, long conference?

With cola.

Well, not only with cola, to be honest. Firstly, it’s Kola, like in Fritz-Kola. Secondly, it’s a hand-made Rocket Edition, as one guy dubbed it. Thirdly… oh, well, just decipher the code below:

Lunar Kola Base64 encrypted messageForgive me the eerie fingernail – it’s due to me getting high on glue. That tiny bit of Base64 is an idea by our scrum master and it leads to a website that might ring a bell in a tabletop Warhammer games –

http://codehulk.lunarlogicpolska.com/

If you’re already bored, skip to the space coder section. If not – I need to confess that being a kola craftsman is utterly ridiculous.

Here’s where the /b/ sections starts. Fingernails are nothing compared to my flip-flops.

Gruesomely Grisly Grind

Lunar Kola preparations

I purchased 96 bottles of Fritz-Kola, had a printing shop prepare diamond-shaped rockety stickers for the bottles’ necks as well as unfortunately not sticky front labels. What else was left to do?

I had set my shoulder to the wheel: I put the Kola in a bath full of ice-cold water for an overnight; ungluing them was a thrilling experience!

Then I tempered the glue with water, stuck the diamond embellishment to the bottle’s neck and began inhaling the glue… that is, carefully sticking the front labels to the bottles, wary to preserve the code underneath. I even checked the code on the first bottle by looking at the sun through the glass! Slowly, the Lunar Kola army ranks began to increase as my strength started to wither and the flip-flops were more flop than flip.

Finally, dazzled and exhausted after more than four hours of gluing alone, the batch of hand-made Lunar Kola was ready to go and amaze the Ruby people of Wroc_love.rb 2013. I’ll touch on this matter later on, but before that I wanted to explain a bit more about the whole hidden challenge.

Howdy, Space Coder!

Codehulk homepage screenshot

Code Hulk is basically a web app that checks your coding awesomeness. The texts & concept are mine, Mariusz did the design and Adam‘s code propels the whole app. It’s loosely based on the Space Hulk game, the Iron Sky film and some of our own internal exercises. It ruthlessly checks your programming skills.

In space. Versus space Nazis. We built it in around a week of non-full-time work and even got a nice test coverage.

The app consists of five phases with original, fast-paced story line full of unexpected twists and without any cliffhangers. The audience was thrilled and begged for more.

Erm… where were we? Let’s get back to the Ruby folk and their reaction to Code Hulk…

Kola! Kola! Kola!

I must admit: I was anxiously anticipating the outcome. Would they notice the code? Won’t they get frustrated going through the seemingly endless exercises? During the first day of the conference I’ve deployed the Kola, opened up Google Analytics with its real-time monitor and waited. Like a flak operator at the radar, looking for that one blip.

Blip!

Huzzah! Allright! Someone found the code! It wasn’t really an epidemic spread, but some folks took the bottles home and tried to crack the app there. During the second day we run out of kola in less than a minute. Handing it out just after dinner break was a tiny bit Machiavellian, I suppose. We laughed demonically during the break. All in all, it seems that for every bottle we had at least 2-3 visitors without much aggressive marketing on our side (the conference-induced traffic only).

All in all, I think that the idea was fine, yet the execution lacks polish. Maybe the code should be exposed more? Fewer exercises? More bottles? Well, that calls for some conference testing. I’m sure of one thing – I really enjoyed doing it. Even while being half-submerged in ice cold water or getting increasingly intoxicated by glue.

Ruby-coloured Krakow

Mirek Wozniak March 25, 2013

Well, to be honest, we don’t know. But there’s an easy way to measure that – just go to the Krakow Ruby User Group’s meeting!

Krakow Ruby User Group

The formula is simple – people meet, talk and discuss topics from the Ruby world. For the most of the time, there were only Kraków-based programmers, but just lately we had two visitors from DRUG (Lower Silesian Ruby User Group), including one of the organisers of Wroc_love.rb – Paweł Pacana and his Webmachine (Ruby) presentation.

KRUG meeting on 8.12.2011

KRUG is quite an old bunch – they’ve been active since 2006 and mined the rubies during RailsDay-like workshops, met in various venues  and even visited some of Krakow’s universities. They’ve already talked about Backbone.js TDD with Jasmine, Crawlable Ajax Applications or automating boring tasks with Chef. And more, Ruby everywhere! We sometimes drop a beer or two at the meetings, but certainly don’t push our marketing tentacles inside. Kraków’s Ruby User Group has been independent and thus should remain.

This Autumn we’re going to celebrate the 7th anniversary of KRUG and it’s more than certain that it calls for a serious Ruby fest.

The next KRUG meeting will take place on the 9th of April 2013 @ Google for Entrepreneurs Kraków (Rynek Główny 14). Ania Leśniak will speak about couchdb synchronisation and Paweł Pierzchała will cover the Hollywood Principle. For more info, stay tuned to the KRUG Meetup!

Git and GitHub for daily code reviews

Kuba Suder March 19, 2013

I like to do code reviews. I can’t say that I always like the activity itself; it depends of course on who writes the code and on the quality of the code. But I like to make sure that the code I’m going to work with later is reviewed. This might be my perfectionism or some obsession with control, but what’s important is that reviewed code will in general be better than not reviewed code, and no one will argue with that.

Reviews let you catch obvious bugs before they even reach QA (“extra comma here, this will break IE”), or potential bugs that would only reappear 4 months later when no one remembers what this code does. They help you make sure that everyone follows similar practices and coding guidelines, and let you transfer knowledge easily (“you know, there’s a new method X in Rails 4 that you could use instead”).

In smaller projects I usually use Gitifier, a git commit notifier for OSX that I wrote some time ago. It lets me review the work of others almost in real time, just minutes after it’s pushed to the repository.

But in my current project (~10 developers) this is physically impossible – new commits and branches are created so often that the constant distractions drive you mad pretty quickly. So I started using GitHub’s web interface instead, and I made a habit of reviewing latest commits every day before I start coding. But the process of finding which commits exactly were new wasn’t perfect. I was never sure which commit was the last one I’ve seen, and having multiple branches didn’t help either, since GitHub shows them all on one list, mixed together.

At this point I decided to write a simple tool to automate this. The result is a Bash script which I called git-code-review.

Here’s how it works: it creates a review subdirectory inside .git in your project’s working copy; in that directory it creates one file for each branch in the repository, and each file stores the hash of the last commit from that branch that you’ve reviewed. (If you know how git branches work in practice, you might notice this is exactly how git stores branch references in .git/refs – that’s true, except these change every time you do git fetch or git pull, and the review data only changes when you do a review.)

The script is extremely simple to use: there are no options, you just need to run git code-review in your project directory. The first time you do it, it will just remember the current state of the branches. Then you can run it again every morning (or once a week, or whenever you want) – and it will tell you how the branches have changed since then. You don’t need to remember or track the commits anymore, it will do that for you. It will also show you GitHub compare links, so you can just click on them:

Fetching latest updates...
remote: Counting objects: 365, done.
remote: Compressing objects: 100% (147/147), done.
remote: Total 270 (delta 213), reused 176 (delta 119)
Receiving objects: 100% (270/270), 92.89 KiB | 97 KiB/s, done.
Resolving deltas: 100% (213/213), completed with 74 local objects.
From github.com:jsuder/holepicker
abc0825..0a711db master -> origin/master
Branch origin/master updated: 313a63b..0a711db
-> https://github.com/jsuder/holepicker/compare/313a63b...0a711db

So far it’s been very helpful in my daily reviews, so I hope it will be of use to someone else too. As usual, feedback / pull requests / issue reports etc. are very welcome.

Agile Improved - AgileDevPractices 2013

Paweł Brodziński March 11, 2013

I’ve just came back from AgileDevPractices conference that was held in Potsdam. As for the first edition of the event I must say it worked out well. Meeting people from different organizations and discussing different issues is always a learning opportunity.

This time it was also an opportunity to do a bit of marketing too, making people aware of this awesome Ruby on Rails software shop in Krakow. In fact, given that people at AgileDevPractices understand what agile approach to building software is, they should like working with us even more.

Anyway, the event started with a workshop day and I had a chance to run a full-day Kanban workshop for a small, but awesome group of people. Instead of making this simply an introductory course to Kanban, I decided to focus on Kanban being a driver of continuous and sustainable improvements. It was a lot of fun and, basing on feedback I’ve received, a decent occasion to learn, too. By the way, if you want to see a summary, here are Peter Saddington’s notes: part 1 and part 2.

There was quite a good mixture of topics among conference talks, and one thing I specifically liked was a strong focus on testing and quality assurance stuff. Interestingly enough, the talks I liked most were those that were neither about agile nor development nor practices. My personal highlights of the event were Hass Chapman’s session showing how strongly we are rooted in hunters / gatherers history of homo sapiens and Peter Saddington’s keynote on behavioral patterns and understanding what makes us tick.

I will be boring with this one, but the best part of any conference is always networking, and this time it wasn’t different. Hours of talking about different topics, trying to chew trough new ideas and make them fit into a bigger picture of current experience is like sharpening the saw. Everyone should do that.

Then there is this awesome experience when you finally meet people you knew from Twitter or blogs for years, but this time they are in their real form, you know, humans, not avatars. The group of friends is bigger again. And I have a couple of ideas concerning who we should invite to the next year’s ACE! conference, too.

On the top of that I carved some time out to meet a couple Lunar Logic alumni in Berlin: Olga and Marek. In fact, it was even better as I flew with Olga to Berlin so we had even more time to chat about good old times at Lunar. It seems that if you worked in Lunar some time ago you can expect me stalking you some time in the future.

The last day of the conference started with my keynote on efficiency and busyness. It went very well both in terms of feedback I got and the number of questions, which is always a good indicator whether people got involved. If you’d like to see slides, here they are:

All in all, the trip to Potsdam and Berlin was definitely worthwhile. I already have a couple of fresh ideas that I want to try out in Lunar. And I hope to see that crowd there next year.