Lunar Logic Wroc_love rb 2013

Mirek Wozniak March 8, 2013

Wroclaw is famous for its tiny sculptures of dwarves scattered throughout the city. They’re featured in guides, included in tourist trips and widely loved. For the second year Wroclaw has been famous for the thing we all love – Ruby! :)

Wroc_love.rb started a year ago as a conference organised by DRUG (Lower Silesia Ruby User Group) and amazed everyone. Concise 30m speeches, lightning talks, fishbowl discussions, three (!) official parties – everyone got what they wanted.

This year seemed even better. We’ve gone there six-strong: Adam, Rudy, Tomek, Phillip, Bartez and Mirek. Five programmers and a guy carrying crates of Lunar Kola. Speaking of which…

With the Code Hulk challenge hidden under the kola labels :)

Let the Ruby miners speak!


I’m happy that I had the opportunity to be at Wroc_love.rb. It showed me what are the currently hot&top&trendy subjects/things in the Ruby world.

The four main things raised on the conference were:

Security problems: A few talks and a discussion panel were devoted to this aspect. But definitely the best related talk was given by Richard Schneeman from Heroku who in a very pleasant way described the most common Rails vulnerabilities e.g. Yaml issue or SQL injection.

Concurrency: Referred to in talks by e.g David Dahl – he explained how he dealt with that problem with the help of jRuby. I’ve also noticed “celluloid” library mentioned a few times which brings concurrent actor-based mechanism to Ruby.

Techniques: Lots of talks were about techniques of development. There were talks about DCI by Rune Funch Søltoft, DDD by Sławomir Sobótka, lighting talk about Dependency Inversion by Paweł Pierzchała. There were talks by Brian Morton from Yammer and Bryan Helmkamp from CodeClimate encouraging to use many thin models or even better services, which I hope will be a standard.

From Ruby to other languages: The most interesting talk was given by Jan Stepien, who shown how one language inspired other authors e.g. How Lisp inspired Matz, how Ruby inspired Clojure or Haskell. He concluded: “try to use other languages, at least one”. In that area I have to mention about JavaScript frameworks fight, which was definitely won by Adam Pohorecki. There were no arguments to beat angular.js which he represented.

Summarising: “Try to use different techniques and languages and watch on security”


The first day of wroc_love.rb’s schedule was dominated by hackathon/open spaces, with one presentation and two discussions to follow. The highlight of the day was an impromptu introduction to Haskell by Jan Stępień, who gave us a whirlwind tour of the language features.

During the second day we had a short fight of the JS MV* frameworks, where I defended AngularJS against Ember.js, Hexagonal.js and Backbone.js. Unfortunately because of the time constraints we didn’t even get to discuss some important topics like testing, but I feel that AngularJS blew the other frameworks out of the water anyway;)

The last presentation of the conference was also the best one. Bryan Helmkamp talked about patterns of structuring Rails apps by extracting behavior into different types of objects – value objects, view objects, policies and others. I think every Rails programmer would benefit from watching this talk.

I think that wroclove.rb was one of the better conferences I went to in the last couple of years. I look forward to attending it next year:)


Friday, March 1st, 2013  – Day 1

At first, the location that we were headed to seemed surreal. A set of abandoned looking factory buildings, maybe warehouses. It seemed like we were in the wrong place. But when we arrived, there was a lot of bustle, people sitting around in the signature red wroc_love t-shirt. The Friday venue was a very pleasant, albeit cold, surprise.

The beginning of the day, up until about 6 o’clock was a very open format. Nothing was set in stone, so mini hackathons and improv lectures sprung up. Later in the day, we had our first taste of the scheduled speakers starting with a discussion about functional vs object oriented programming. After the discussion Stephan Wintermeyer spoke about using a Raspberry Pi to test website response time. He used the Pi as a simple baseline and showed a bunch of methods to increase page loading times. He had a test suite that clicked through a web page and used http, page caching, and cache preheating to reduce the page load times by more than 600%. One of the major points he made was to think about caching when you start a project, not when speed becomes an issue.

Next up was a fishbowl format discussion – the overarching topic was productivity with discussion ranging about measuring productivity, choosing the right metrics, and opinions about what the most important thing for productivity is. In terms of measuring, there were a few interesting tools mentioned, including Code Climate, Pivotal Tracker. In terms of the most important thing for productivity, there were opinions stating that happiness, health, and team feedback were among the most important things.

After all these discussions, it ended up being 8 o’clock, and thus, time for a party, which also is an important part of any conference, as that is the time to sit down and talk to fellow developers. To learn their likes, dislikes, and other opinions about all sorts of software topics.

Saturday March 2nd, 2013 – Day 2

Saturday started off with a few good talks in the morning, with topics ranging from how to structure and design software to speeding up page. There was a demo regarding client vs server side work, showing that when doing big IO things like uploading photos, you could display the file instantly on the client side, as if it were already uploaded, and then upload it on the server side to have a much snappier UI.

During this first day there was a lot of talk about concurrency, and the different Ruby implementations out there which include MRI, JRuby and Rubinius. This was a big topic because MRI cannot do concurrency, so the other Ruby implementations are the way to go if you are looking to use all the cores on your machine with your Ruby projects. The Celluloid gem was mentioned every time someone spoke about concurrency, and it sounds like it is very useful in that realm.

Also a new implementation that is in the works was demoed called Topaz. It is a Ruby implementation based on Python, and looked pretty promising in terms of speed. There was a very interesting four person discussion about various Javascript frameworks including Ember.js, Hexagonal.js, Backbone.js, and Angular.js. Our very own Adam Pohorecki defended the merits of Angular.js and definitely made it obvious that it is very useful and intuitive.

After all the talks came the lightning talks – the most interesting ones talking about Code Climate, software that statically analyzes your Ruby code and grades it based on a bunch of metrics, Chef, a gem that lets you write deploy scripts for quick, automated server deploys, and BitCoin, an interesting peer to peer currency.

Sunday March 3nd, 2013 – Day 3

Sunday started off with a fantastic talk by Jan Stępień showing how other programming languages influenced Ruby, and then in turn, how Ruby influenced other programming languages. The overarching point of his talk was that the language we use influences how we think, and thus, know a lot of programming languages gives us all new perspectives on various problems.

Before lunch there was another awesome talk about security and secrets by Richard Schneeman. He went through a lot of common security issue including DDoS attacks, memory exploits, parser exploits, and the recently discovered YAML issues. He very clearly explained how each of these work and what to do to avoid having your Ruby app be threatened by these types of attacks. He also talked about where to keep your private information needed for you app (database passwords, third party service authentication info, etc). One of the best ways to do it is using environment variables so that these secrets are never in your repo.

The second to last talk of the conference was very interesting in that it was a very philosophical talk. It compared the ideas in philosophy with the ideas in programming and how they are very similar. Steve Klabnik explained, with his professor’s jacket on, that the ideas in philosophy have been passed on for thousands of years, and even though they are related to natural language, the principles can be used in the computer science world.

The last talk of the day was by Bryan Helmkamp, creator of Code Climate. He went through seven very useful refactoring patterns to try and refactor all those fat models each project has floating around. This talk went into detail about each pattern, when to use it, how to use it, and why it helps. All seven of these patterns I could see using in every project. This was definitely one of the best talks give, and is definitely going to be very useful in the future. After the talks were finished, there was another round of lightning talks, where LL’s Pawel Pierzchała gave a talk on Dependor, a gem that him and Adam created to facilitate dependency injection in Ruby.

Final Thoughts

All in all this was a very awesome conference. Great people, lots of knowledge, a beautiful city. What more could you want? I am already excited for next year!


I really enjoyed the wroc_love.rb, it was one of the best conferences I attended. The talks were more concerned about practices than frameworks and that was a good thing!

First day started with a promising FP vs OOP discussion, but in my opinion it drifted away a few times, for example when FP was blamed for being hard to use. I would rather say that all new languages, especially with a different paradigm, are hard in the beginning.

However, the second day discussion, Angular vs Hexagonal vs Backbone vs Ember was great, pros and cons of those technologies were covered, arguments were concentrated on the technology. Our very own Adam Pohorecki did a great job fighting for Angular. Conference ended with an amazing design talk – Refactoring fat models with patterns, delivered by Bryan Helmkamp, I couldn’t agree more, I have codeclimate badges in all open source projects I work on. :)

Lastly, I gave a lightning talk about dependency inversion –

It seems that the Lunar crew will frequent wroc_love.rb 2014 :) See you then!

The idea of this article is to show you the new possibilities of creating web components for your own pages. It”s not always a requirement to add a bunch of JavaScript code and third party libraries to your project just to create a new component. Depending on the component, you can find new solutions to implement it. After reading this article I hope that you will be able to see a new world of possibilities right in front of you.

Most of the components we can see around the wide web requires some kind of interaction by the user. Take as an example a very common type of component that we can see in many websites, a carousel. The basic functionality of a carousel is to show a content block allowing a continuous interaction through all the content blocks. Below is an example of a carousel using YUI3.

image slider example
Image slider example

To use this widget on your website you need to add the YUI3 library (21.71 kb), a small CSS code for the look-and-feel (3.12 kb) and then fire the framework to build the widget using your HTML structure. If you are a performance addict you would get crazy with the amount of code your page will need to load. But what if I tell you that you can build the same component with no need of any JavaScript code? It”s perfectly possible if you use a little imagination and the tools which you already have.

Shut up and show me the code

To start I will introduce you to the basic concept which we will use to develop our sample code and that can be used for you in the future to develop your own widgets.

Thinking about carousels we know that the user needs to click on a kind of button which will fire an event that will make the carousel show the next content block. Then we have states that will change in response to the user”s interaction. So, we need something to handle the click event of the user and store the current state and then the interface needs to change to represent the new state. Below there”s an example of everything we need in a carousel: states that change in response to the user”s interaction and update the component on the page.

The most important part of this example is how it changes when we activate the different radio buttons. Below is the HTML structure of the example.

Each rectangle is called a page element and is 100px wide. In the code fragment below it”s clear that we use only CSS selectors to define the different states and what visually changes when each radio button is activated. I”m omitting the CSS code needed only for styling the elements, but you can see the complete example later.

With this we can evolve the example to a more elaborated version hiding the radio buttons and allowing the user only to click to move to the next page of the carousel. For that, we can style content inside of a label element that targets each radio button in our controls as you can see in the example below.

For that example we”ve created simple elements to represent our buttons. When clicked, they will check the radio button and switch to the next state.

Then we hide all the radio buttons and define the state of each next button that will appear in every possible state.

The complete example 2 is also available to you.

Now we can create the possibility to move left and wrap around. For that we just need to duplicate the control elements to have some control focused only on moving left. We also need two containers for our pages, one which moves left and another which moves right; each button moves the respective container.

Then update the CSS selectors to handle the new states.

After that, we can see our example working like below.

Finally, after adding styling and some little effects we have our amazing carousel with no single line of JavaScript code.

Creating widgets only using CSS can reduce considerably the size and loading time of your pages and is a task full of creativity. Others are creating interesting things using similar techniques. Create your own widgets to amaze the world.

Smooth CSS transitions by forcing GPU rendering

Mariusz Cieśla February 18, 2013

Let’s say you have a CSS transition that takes an element and scales it two times on mouseover. Your code probably looks like this:

It’s all good in the hood until you come across a really complex DOM with a lot of things going on – then things usually get choppy and slower in older WebKits. That’s because your browser takes your 2D transition and forces it through your CPU. What to do in order to make it smooth?

Fortunately, there’s an extremely simple hack that allows you to force the browser to enable GPU rendering for CSS transitions – just take your code and tell the browser it’s actually a 3D transition even though it isn’t. The code after the change would look something like this:

(See this example on JSfiddle)

It has its drawbacks, of course – the screen might blink or lose colour profile when starting a transition, but hey – hacks aren’t called so without a reason :)

Kudos for Kuba :) “Kudos” US[ˈkjuːdɒs], UK[ˈkuːdɒs] – 1. Fame and renown resulting from an act or achievement. 2. Praise given for achievement.

Here, in Lunar Logic, we love to give people random geeky gadgets or long-lasting cinema vouchers. Immediately after that I take a photo of the gift recipient and post it to our Facebook, saying nice things about that person. Sometimes they are so corteous that I’ve got to be deliberately nasty later on. Just to keep the balance, you know.

Seems wacky, isn’t it? Yet, it’s our way of expressing gratitude and respect. We’ve even got a strange, outlandish word for this activity: Kudos.

Kudos may take very different forms. Some people get straight to the point, while others laud the overall performance of the person they value. The goal is simple: to tell a person that they’re great. And not (only) by the boss – a Kudos expresses a real high five by a peer!

All Kudos are anonymous and thus far we haven’t experienced any mutual admiration societies. However, people sometimes grant Kudos to themselves. No one sees you fixing that cranky server after hours or extinguishing fire in a project during Christmas :)

Ok, some of the Kudos are purely out of kindness, but… Lunar Logic is not only about coding. We love the fact that instead of having a coffee break we might as well have a song break, play fussball or meet for board gaming after work :)

Paweł, Lunar Logic’s leader, loves to give out Kudos:

It’s fun to get Kudos. After all, who wouldn’t love to hear supportive feedback on their work and then get an awesome gadget chosen from a wide range of utterly useless but irresistibly funny stuff. On the top of that one can play a celebrity with all those photos, publicity and what have you.

Receiving Kudos isn’t the best part of the story though. The best part is this warm fuzzy feeling you have when you give someone Kudos. I mean, they’ll never know it was you who started it. It just feels great to execute your power of doing something nice to someone who deserved that.

Oh, and by the way I love my job as a messenger. Thanks to this, I just know I’m in a business of making people happy. A dream job if you ask me.

Paul, LL’s owner, wrote this beautiful post about spy network in Lunar that’ll also give you some insight into our eerie custom.

* according to Merriam-Webster web dictionary,

Ignoring local changes to a file in git repository

Kuba Suder February 4, 2013

Let’s say you want to modify a file in your repository locally and don’t commit that. For example, you might want to use a different .rvmrc than the rest of the team, or you might want to disable a non-essential gem or a part of the system that has some problems on your OS.

Of course an ideal way would be to fix it in the repo so that it works for everyone, but sometimes that’s not possible. You could make the change and just remember not to commit it, but you can be sure you’ll forget sooner or later.

In this case, the solution is to mark the file as ignored in your local repository. There is something like a “local gitignore”, which is located at .git/info/exclude, but that won’t work if the file is already in the repository. You need to use the update-index command instead:

git update-index --assume-unchanged .rvmrc

The file will just disappear from git status and will behave as if you didn’t modify it at all. If you change your mind, this is how you remove that “unchanged” flag:

git update-index --no-assume-unchanged .rvmrc

If you forget which files you’ve marked as unchanged and you want to see a list, it seems the only way to do that is by using this command:

git ls-files -v | grep ^[a-z]

This works because files marked as unchanged show up in ls-files marked with a lowercase character. (If you know a less hacky way to print that list, let me know…).

P.S. Don’t forget about the Krakow Ruby User Group meeting tomorrow!