The bare except statement is something I often see in the main loop of a
script that should run indefinitely. Pylint will
warn you about this
problem, but in my opinion we should start to treat this as an error.

We caught the KeyboardInterrupt exception and just carried on. But we catch
more which we should not. Let’s try to exit the program from the business
function, maybe because the user asked for it or we got signaled.

Pylint will still warn you
about this line, because catching Exception is still very broad and you
should only do this when you have a good reason, e.g. the reason mentioned
above (to keep a service running even if it could not handle a certain input or
request).

So next time you see a bare except statement in your code, take a moment to
reconsider if you really want to catch SystemExit, KeyboardInterrupt (and
GeneratorExit which I did not mention above). If that is the case, you might
want to make it explicit so that the next person reading the code does not have
to check again.

tl;dr: Puzzle had to be solved. Did it in Haskell. Had fun. Code is here :-)

Last week one of my colleagues, Marco,
brought a so-called Minotauros cube to work and left it on the counter near the
coffee machine. You might call it an obvious attack on the productivity of the
whole company.

At least for me it is hard to tolerate to be unable to solve a puzzle.
Unfortunately, it is a quite tricky one. Here is a picture; there is only one
way of putting the parts back into a cubic shape.

While I am sure that there are solutions and algorithms to solve this kind of
puzzle, I wanted to think of something myself. Thus, I abstained from searching
and started to think about a way to solve it. I immediately decided to build
the solution in Haskell. I have done quite a bit of programming in Haskell in my
first year of university but not much recently. But at
Polyconf 2015 I got some inspiration to do more
functional programming again (I am playing with elm
(talk at Polyconf) at the
moment, more on that in another post).

It took me some time and fruitless tries experiments until I had a good idea
how to structure the solution of the problem. I decided to use a backtracking
algorithm which tries to find dead ends as quickly as possible.

During the implementation I decided to change the algorithm slightly: It now
starts out with a full solution (a shape in which all the coordinates are
“occupied”) and consequently “subtracts” instead of “adds” in line 05.

Another problem was the data structure to represent shapes. My first try
featured the following type using Data.Array:

importData.ArraytypeShape=Array(Int,Int,Int)Int

It is a quite obvious choice for somebody who lives most of the day in the
imperative world, but I also noticed quite quickly that the Array type is
a little cumbersome to work with.

I then reconsidered what a truly functional way of representing spatial data
would be. I came up with the following:

dataShape=None|PointShapeShapeShapeShapeShapeShape-- North South West East Above Below

I planned to use this as a three-dimensional doubly linked list. I thought it
might be nice to traverse this using pattern matching. While Haskell’s
laziness enables us to do so I
quickly noticed that using this kind of structure is too much for my mind.

I use wicked pdf for PDF generation in my rails app foxtrot mike.
Wicked pdf has a helper method which copies the content of CSS files into the generated HTML. This does not work in Rails 3.1 because CSS files are generated by Sprockets. Fortunately it is possible to access the compiled asset files.
When the asset pipeline is enabled, the application object has an attribute assets which returns a Sprockets::Environment.

The following code includes the contents of application.css in my layout which is used for PDF generation.