Software developer blog

The Bowling Game Kata with commentary

I have just released a code cast in which I do Bob Martins version of the bowling game kata in php, but take it further with a refactoring.

Web app crash course (Part 4)

In the previous part we have built a very simple chat application, but it stored messages in memory. Every time it was restarted, all messages were gone forever. In this part of the series we will look at MongoDB, a document database. There are many other database technologies, some of them are more frequently used than MongoDB, but for our purposes it is the best choice.

If you haven't read the previous parts, click here.

Web app crash course (Part 3)

In the first two parts we have examined how to create web pages using Sinatra and Mustache templates. In both cases we fed a small amount of data through the url, and then we returned something that was based on that data. However having to type input data into a url is not necessarily a good user experience, especially if we wish to send a larger chunk of data. In this part we will learn how to send user inputs properly.

Another problem we haven't addressed yet, is storing that data, so that we can show it later, and show it to other users, but that will be the topic of the 4th and final part of this series.

If you haven't read the previous parts, click here.

Web app crash course (Part 2)

In the previous part we dipped our toe into git, bundler, sinatra and mustache. In this part we will first explore how to add some interesting logic to our web application, while keeping that logic unaware of the very existence of the web. In fact we will go as far as to create a web app and a command line application that will do the same thing through different user interfaces. In the process of creating these applications we will also explore the realm of test driven development, a practice that can lead us to better software.

If you haven't read the previous part, click here.

Web app crash course (Part 1)

This is a beginner tutorial that shows you how to build a Ruby app using a certain set of technologies that I prefer to use. It will not make you a web developer right away, but it will show you the basics, and serve as a starting point for further reading. I assume that you already have basic knowledge ruby, HTML and CSS, or at least have read a tutorial that introduced you to them. If not, visit Codecademy. Another assumption I make, is that you are using Ubuntu (or possibly another Debian derivative) as an operating system. If not, you can download it free, and install it next to your existing operating system.

The approach I have taken is to show you most of the tools at once at a very low level, so that first you get the big picture, and then we will drill deeper later. This may be overwhelming at first, but bare with me, slowly everything will unfold.

By the end of the first part we will have a web page, that can say hello. Not much, but it's not the the goal we reach that will be of importance, but the way we get there. I will show you the tools developers use from day to day. We will look at how we manage gems, the building blocks of software development. Then we will look at some of those gems, most importantly Sinatra, that is designed to respond with web pages for requests of web browsers. We will also take a quick look at git, a tool, that is designed to store source code, and keep several versions of it around, so we can go back, when something goes wrong. Finally we will look, at how you can make your page look better with a Mustache.

Test driven mockery

This year I have talked at different Hungarian venues about software development related topics several times. Although these presentations are captured on video and are available on the internet they are in Hungarian, so I decided that the next few posts will explore some of them in English, and in more depth.

I gave the Test Driven Mockery talk at the April event of PHP Meetup Budapest. Although code examples and frameworks are in PHP, the talk is basically language agnostic, and it's just as useful for PHP programmers as it is for Java, C#, Ruby or even C++ coders. After all: it's about test doubles in general.

At the time of writing this blog entry more and more software developers and companies decide to adapt test driven development as one of their primary practices to avoid code rot and fear of change. Of course there are crowds who still haven't even tried TDD either because they haven't heard about it, or it sounded too weird for them to try. However there is another lot more interesting group of educated professionals who after practicing TDD for a considerable amount of time decide to abandon it. As I was talking with a group of these people I recognized that most of the time their disappointment in the technique is easily tracked back to their misunderstanding of a very important related topic: test doubles and mocking. On one hand if you completely avoid using them you end up with a slow and fragile test suite that's hard to maintain, but if you use too many of them the promise of ease of change, well tested and flexible code becomes a lie. Finding a good balance is kind of an art.

How to find maximal cliques

Facebook used to have this awesome list of programming puzzles that were freely available. One of them was peak-traffic, which can be rephrased as the maximal cliques problem pretty easily. Unfortunately a graph can have exponential number of maximal cliques, so it's not surprising that we can not find a polynomial algorithm for listing all possible maximal cliques in a graph. However there are output sensitive algorithms: as long as the number of maximal cliques is relatively low each can be reported in a short time.

A complete sub-graph of a graph is called a clique, much like we call a group of friends a clique if they all know each other.

I knew that I was looking for such an algorithm, but it was kind of hard to find a detailed enough description on the Internet.  At the time of writing Wikipedia does provide a short description of the algorithm devised by Tsukiyama et al. but there are a number of details omitted, making it kind of hard to come up with the right implementation.

My aim is to provide a simple to understand description of the algorithm (without proof that it works correctly) and share my implementation in C++. (Type `make smoke` to compile and test.) The source I've been using - apart from Wikipedia - was a 2004 paper written by Kazuhisa Makino and Takeaki Uno: New Algorithms for Enumerating All Maximal Cliques.

Hungarian Web Conference 2012

Last week I have attended a free conference in Budapest themed around web development. Here is a quick recap. Unfortunately the conference was held in Hungarian, so most of the resources I link to are in Hungarian.

János Pásztor described how they built up the infrastructure for a tiny start up called His talk was recorded on video, and a short lecture note is available. It's a very good starting point, and contains a lot of information on tooling. The most important part for me was where he talked about configuration management: with the right tooling it can become almost automatic to add a new server to your system. Definitely worth a bookmark if you plan to start your own web based service some time in the future.

László Merklik talked about test driven JavaScript development. His point was that although one is tempted to believe that we only write the user interface in JavaScript, usually a lot more logic ends up on client side than we have bargained for. Having a decent test suite for JavaScript not only helps in developing the client side code as it does in other languages. It also provides an easy and automated checking mechanism for compatibility with any number of browsers, a challenge that doesn't even make sense in other languages.

@ //

Snake cube

Few weeks ago one of my colleagues showed me this puzzle:

Snake cube

Snake cube puzzle

It's basically composed of 27 cubes, which are linked together by their faces. Each pair can be rotated around their common face. The aim is to fold the snake into a cube like this:

Solved snake cube

The snake cube once it is solved

Needless to say, my first thought was to write a backtracker that solves the cube for me. After all it's more fun to write the program, than to play around with it for hours. It didn't take long. After I was done with that, I started to ask myself questions like:

  • Are there other combinations with a single solution?
  • Are there combinations with more than one solution?
  • Are there palindromic snakes, that are solvable?
  • How many different solvable snakes are there?

I quickly found the answers to those on Jaap's Puzzle Page. I won't repeat the results that are available there, go and check it out if you are interested. On the other hand, it did not contain the source code for the backtracker, so I decided to show you how something like that could be done.

@ //

Postponable iterator

When I started this blog I had no idea how hard it will be to post useful things without revealing too much about the "top secret" projects we are involved in. 🙂 This time though I've been allowed to release an entire class that turned out to be useful in an application we were developing a while back. The piece of software below was created with a financial support by Uratim Ltd. and can be used under the terms of the GPL license. YAY for free software.

Postponable Iterator source

The iterator pattern is one of the most frequently occurring patterns used in software design. Even before one learns about design patterns inevitably implements an iterator without actually realizing. The problem I came across not so long ago was that I had an iterator that was returning  jobs from job packets that would have to be processed but there were a number of constrains I had to keep in mind:

  • For each job there is a resource assigned for the job. It can only be executed using the resource assigned to it.
  • As long as possible certain resources should not be accessed too frequently. (But they can be accessed more frequently when it is necessary.)
  • Packages are processed semi asynchronously: all jobs in one package are returned at once, but there may be more that one pending package. The maximal number of packages under simultaneous processing is a parameter.
  • When there are too many jobs waiting for a single resource than access times should be gradually decreased to avoid too long waiting times for jobs.
@ //
Next Page »