The value of beautiful code

During my rather short period of Pair Programming I have learned something valuable, but there is also something I’ve learned after that. Michal Tehnik left the company and I continued to work on code we wrote and then refactored and polished together several times. It is probably the best piece of code we have now in our code base 🙂 We did not have the time to finish it, so it was my job to that.  I needed to add some need features and fix few bugs. I could have done it in two ways. One way was to do it as quickly as possible by tweaking the code or by introducing some hacks or workarounds.  It is fast but the produced code is then less legible and possible bugs are harder to trace. The other way was to invest more time and mental power to write as good code as I could and then refactor it. That’s important so I will say it again: Refactor your code. It is quite likely that the second or third time you look at your code in order to avoid duplication or badly named functions you will always find something in there to improve. Believe me, its worth it.  (Credit for lesson learned goes to Michal Tehnik)

A couple of days ago I needed to change something in some code I wrote about 3/4 year ago. It was written fast. I was quite new in the company back then and I did not want to look incompetent so I wrote it as fast as I could. So it is not surprising that the architecture is not very good. It turned out it needs complete refactoring 🙂 Partly because of how it is written and partly because of the new features.  I mention it here to encourage you to really invest the time and effort to write as good and generic code as you can. When you are done writing, it’s time to refactor. And then ask someone to review your code. It looks like a lot of work (and it is), but it will probably save you a lot of sweat in the future.

How do you measure the quality of code? Read about the Four Elements of Simple Design to learn more.

Blurry images in html5 canvas

Why <canvas> draws blurry images? Did it happen to you as well? I found fairly simple tutorial, and tried to code according to its advice. The result is shown below. Big blurry cat … Then I tried to copy paste the code, but with almost identical result. Again I got a blurry  image.  Next day I found out that I have to specify attributes width and height directly on the canvas element. It is not enough to set it via css. It doesnt not make any sence to me, because it is good practise to separate html markup and stylesheets. But for some reason it is not good practise for canvas 🙂

Then I encountered similar problem when drawing gradients. When I set width and height via css, then the gradient was always too big to fit into the canvas, only small part of it was visible. My advice is to always specify width/height via attributes on canvas.

<canvas id="myCanvas"></canvas>
<canvas id="myCanvas" height="400px" width="600px"></canvas>

Rotate table cell content with jQuery

Rotating text via CSS is now relatively easy. There is a few of good tutorials and demos out there. But they lack one thing – they don’t explain how to rotate text in a table cell. Few days ago during pair programming with Michal Tehnik we run into trouble. We managed to rotate the text, but it only worked properly in Internet Explorer. (via writing-mode)

Broken table with rotated text in Google Chrome


In Chrome and Firefox the table cells shrinked, because elements rotated via css rotate property are still “placed” in their original position.

Demo of rotated text in

To fix this behaviour we need to calculate first width and height of the element before we rotate it. Then wrap it in a (new) div element and mix width and height for this div. Height goes for width and vice versa.  Now this div has the  same dimensions as the rotated element, which are then copied by the containing cell.

We wrote jQuery plugin for this.

(function ($) {
  $.fn.rotateTableCellContent = function (options) {
  Version 1.0
  Written by David Votrubec ( and
  Michal Tehnik (@Mictech) for

		var cssClass = ((options) ? options.className : false) || "vertical";

		var cellsToRotate = $('.' + cssClass, this);

		var betterCells = [];
		cellsToRotate.each(function () {
			var cell = $(this)
		  , newText = cell.text()
		  , height = cell.height()
		  , width = cell.width()
		  , newDiv = $('
<div>', { height: width, width: height })
		  , newInnerDiv = $('
<div>', { text: newText, 'class': 'rotated' });



		cellsToRotate.each(function (i) {

And the css

/* Styles for rotateTableCellContent plugin*/
table div.rotated {
  -webkit-transform: rotate(90deg);
  -moz-transform: rotate(90deg);
  white-space: nowrap;

thead th {
  vertical-align: top;

table .vertical {
  white-space: nowrap;


//Basic usage

//specify class name of cell you want to rotate
 .rotateTableCellContent({className: 'whatever'});

You can download this plugin at github.

Try the demo here.

Git productivity tips

During pair programming with my colleague Michal Těhník I watched him using git. Here are few things I learned from him.

Use git number

Git number allows you to use numbers instead of file names. If you for example need to diff some file, or add it to commit, you no longer have to copy paste the filename or type it by hand. You just type something like “git add 1“. Git number can be combined with other git commands.  For example: git number diff 1

Use of git number

Installation Instructions (Windows)

  • Download files from Github
  • Extract to desired folder
  • Add that folder to $PATH variable! or in the git/cmd folder

Use aliases

  • instead of git status use git st
  • and instead of git st use git number 🙂
  • instead of git number diff use git d
  • instead of git commit use git cm

My config file then looks like this:

  cm = commit
  st = number
  d = number diff
  na = number add

Further resources:

Streamline your git workflow with aliases

20 commands for everyday use

Včelí medvídci a (ne)vyměnitelné baterky

Baterky ve Včelích medvídcích oficiálně nejdou vyměnit. Výrobce (prý z bezpečnostních důvodů) baterii zašil dovnitř do hračky. Nám baterie vydrželi zhruba půl roku, pak začal čmelda zkuhrat hlady 🙂 Sice se ještě snažil zpívat, ale znělo to skoro strašidelně 🙂 Naštěstí se dá na zádech rozpárat a baterie vyměnit. V jednom místě je na zádech trochu jiný šef, stačí nit přestřihnout a vyndat malou krabičku, ve které je zároveň mikrofon i baterky. Baterie jsou typu LR44 a jsou potřeba 3ks. Můžete je koupit například v DatArtu, mají je tam za 10 Kč (psáno 7.2011). Pozor: nekupujte je v hodinářství, tam je mají 5x dražší.

Včelí medvídek – Výměna baterek

Pokud se vám článek líbil, nezapomeňte ho sdílet na Facebooku, Twitteru či jinak 🙂

On pair programming

Several times I programmed in pair and I want to share my experience with it.  What are the main benefits of pair programming?

  • The code is of better quality, because there is always the other person watching over your shoulder and seeing what you have overlooked. Wikipedia says that defect rates are about 15% to 50% lower.
  • There is a synergy of ideas. When you work on your own, you might get stuck easily. This rarely happens when working in pair. When you don’t know how to do something, the other probably knows it. Or you start talking about it and one idea leads to another, and soon enough you will come up with a solution.
  • Increased team morale. By working closely with someone, you get to know him. And you share responsibility. The code is no longer yours, it belongs to both of you.
  • Learning from each other. Chances are that each of you is more experienced in some area than the other one. By working together on a problem, you share that knowleadge. There is always something you can learn from your colleague. Be it high usage of keyboard shortcuts to increase productivity, or different way of thinking, better coding techniques, different set of tools.
  • Maintaining focus. When you work with someone you just can’t browse the internet or pretend that you are working 🙂 There is always something happening, either on the screen or between you when you talk about the problem at hand. It naturally helps you to maintain focus.
  • Time management. Set alarm clock to 20 minutes and then change places. 20-25 minutes is recommended time to maintain concentration. (But of course you don’t have to work in pair to use it.) See Pomodoro technique for more info.

These were the main positive points. What is the downside?

  • Pair programming is noisy. Unless you decide not to talk (I have never tried that), there is no way how to avoid being noisy, which might be distracting for your colleagues. It’s also easy to get excited over some idea or to get into a kind of friendly argument (which is OK 🙂 )
  • It might be more exhausting, simply because there is more things to pay attention to. Beside your usual IDE there is that other person. He talks, he takes “your” keyboard, he disturbs you by pointing out possible future bugs. He will almost certainly spot weak points in your code. And you might start rather a heated discussion quite easily.
  • Less code. But that might is actually a good thing :). Quality of software doesn’t count in lines of code, does it?
  • Sometimes you get stuck when working in pair too. Then two people are stuck instead of one. But it is not very often and usually for significantly shorter time then when the both of you work individually.

Some people love pair programming, some hate it. Someone is even scared of it. Let me quote Michael Dowling in comment section:

That’s NOT the reason I *really* hated it, though. The reason I hated it is because – are you ready for this? – I might be wrong. Yes, there is a slim chance I could be wrong – dead wrong, stupid wrong, or better yet, absolutely completely “WTF were you thinking of implementing it this way you dumbass!” wrong – and my pair would find it and point it out to me. In other words, I was afraid of being naked.

The fear was being critiqued. But then I did it. And sure enough, I may – MAY – have done a few things in a less efficient manner. But something amazing happened – I learned. I learned a lot faster with someone at my side than I could ever have learned alone or during/after a formal code review. My pair helped me organize my thoughts – and funny enough, I helped my pair as well. My pair helped me get up to speed QUICKLY on the new system being developed. Faster than I could ever have done it alone.

I learned new development techniques that have stuck with me, even today. Things I’m not sure I could have learned on my own.

It’s not practise what makes perfect. It’s perfect practise. I believe that pair programming fits into the perfect practise category. It helps me to write better code.



Why to write a blog

This is rather a quotation than a regular blog post. It is a paragraph from book Getting Real by 37Signals. I could not say it better.

Hire good writers

If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn’t matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.

That’s because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else’s shoes. They know what to omit. They think clearly. And those are the qualities you need.

An Organized Mind

Good writing skills are an indicator of an organized mind which is capable of arranging information and argument in a systematic fashion and also helping (not making) other people understand things. It spills over into code, personal communications, instant messaging (for those long-distance collaborations), and even such esoteric concepts as professionalism and reliability.

—Dustin J. Mitchell, developer (from Signal vs. Noise)

Clear Writing Leads To Clear Thinking

Clear writing leads to clear thinking. You don’t know what you know until you try to express it. Good writing is partly a matter of character. Instead of doing what’s easy for you, do what’s easy for your reader.

—Michael A. Covington, Professor of Computer Science at The University of Georgia
(from How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily)


Simple inheritance via jQuery.extend

Spoiler warning:

This is not true inheritance as we are used have to in static languages. It is not even prototypal inheritance. It is merely an experiment to find out if it is possible to achieve (mock) inheritance using jQuery.extend() method. And yes, it is kind of possible.

JQuery.extend basically copies properties from one object onto another. So in order to mock inheritance you have to extend instance (or instances) of ‘parent class’ with properties of another objects.

Here is how I did it:

$(function() {
  var Parent = function() {
    var that = this; = 'david';
    this.getName = function() {
       return 'name is: ' +;	 };
  var AnotherParent = function() {
     this.doSomething = function() {
       return 'I am a test...';	 }
  var SomeStaticClass = {
     staticVariable: 'I am static'
     , staticFunction: function() {	return 'some static value or whatever' }

  var result = $.extend(
    //read properties from instance not from function definition
    , new Parent()
    , new AnotherParent()
    , SomeStaticClass
    //read properties from some anonymous object -> overwrite properties from Parent
    , {tryIt: 'try it', getName: function() {return 'Name also is: ' +}}


This is only simple case. If you are building a complex project and need inheritance, then it is probably better to use Dojo framework.

Inspiration from books

Recently I started to read a lot (thanks to Kindle text-to-speech feature) and I can see how books are broadening my mind. There is a lot of inspiration in (good) books, ideas and concepts you would not otherwise think about.  I want to share some of these great books. They are:

There is no need to comment on Rich Dad Poor Dad, as there was already written a lot. Even thou I don’t agree with everything Kiyosaki says, I recommend everyone to read it. And if possible to play the CashFlow game.

Moonwalking with Einstein is about memory and it’s history. It is very well written and raises few questions about quality of our current educational system. Most of what we have to learn in schools is shortly forgotten afterwards. We don’t know how to use our brain and it’s memory capacity. Nobody teaches us that. Is it really possible to remember everything? After I read this book I believe it is. Question is if it really worths the effort 🙂

Road to Serfdom. To put it in one sentence:  How the nice idea of equality and socialism turns into dictatorship. There is probably no other way. Once there is one central authority which plans what will be produced, in what quantity and for what price, then it necessarily leads to oppression. It is book about economics, but economics has actually its roots in psychology too.

Lucid Dreaming. Well… this one is very interesting. This is the only book I write about even before I have finished it. I added it to the list because it is really fascinating, but I will write about it later. I haven’t got any lucid dream yet, so I can’t really write about it. Anyone experience it?