Driving sites

This entry contains a list of sites about driving. It is a bit different from the rest and I'm not sure if a better place to post this is Bits of Reality blog... but what the heck: it doesn't make sense to spend too much time thinking where should I post this. The list.

• Modern Racer tips
• Driver reaction time
• Smart driving
• Driving on the left side
• Aims
• Performance driving
• Safe driving
• Drive and stay alive is a small encyclopedia
• Reaction time

That's enough.

My political views

I have recently tooked a test. My results are here. You can also view an explanation. Politicians with views similar to my views are Dalai Lama and Nelson Mandela.

Law of Demeter

I am curently reading the book The Pragmatic Programmer, which was recomanded on Eric Gunnerson blog. I have just read a section about The Law of Demeter and realised that I often break it. This law says that a class method should only call methods of: (1) this object, (2) objects passed in as parameters, and (3) objects locally created (including on the stack). This means that code like obj.f().g() or A* objA = objB.GetA(); objA->DoIt() are breaking the law. The authors suggest two possible solutions.

1. [look at first example] If obj is passed in as a parameter then it might be possible to simply pass in obj.f() and simply call g(). This might not be possible in some circumstances, for example if you also need obj.h(). In these cases you...
2. [look at second example] Write a wrapper function DoIt() in the class of objB that simply forwards the request to objA. This way you can write simply objB.DoIt().

Why bother? Well, from a theoretical point of view you minimize the coupling between modules. Why? Well, let's look at the second example. The class of objB looks like this:

class B {
   // ...
public:
   A* GetA() const;
};

In other words it is already coupled to class A since it contains a function that returns a pointer to A. Adding a wrapper DoIt method does NOT increase the number of classes on which class B depends.

// B.hpp
class B {
   // ...
public:
   A* GetA() const;
   void DoIt() const;
};

// B.cpp
void B::DoIt() const
{
   GetA()->DoIt();
}

However writing such a wrapper will decrease the number of classes on which the client of class B depends. In the original version it depended on class B and class A. With the DoIt wrapper in place it depends only on class B. But writing such wrappers is cumbersome and boring. Does it really pay off? I think that it is a situation very similar to writing properties (C#) or acessors (Java/C++) and accessing members thru them. If you found situations in the past when you said "Why didn't I used an accessor here?" then you are likely to find the Law of Demeter useful. Avoiding call chains like obj.f()->g()[3].h() makes the code more readable. It also brings down compilation times. I wish there were some tools to help with this by automatically doing the refactoring illustrated above.

Name on OEIS

The Integer Sequences entry has a link to OEIS. Now I have my name immortalized there :)

Integer Sequences

Remember high school days with all kinds of integer sequences? Do you remember a closed form formula for the sum of the first N integer numbers: 1+2+...+N? Do you remember the sum of the first N squares: 1+4+9+...+N^2? If you ever need to answer such questions some possible approaches are:

• Use various sum manipulation rules and (maybe) some sums whose closed-form you already know to find the answer by "construction".
• Compute the first few numbers of the sequence, guess the answer by using various heuristics and prove by induction. An example "heuristic" is transforming the sum into an integral, computing the integral and then search for answers with a similar form. Eg. by knowing that integ(x^n) is proportional to x^(n+1) you can guess that 1+4+9+...+N^2 has the form a+bN+cN^2+dN^2.
• Or, if you are in a hurry, use the On-line Encyclopedia of Integer Sequences to find the formula from the first few terms :). As a bonus you will also get references to articles and/or web sites that give more details.

Best Language

The Great Computer Language Shootout has a makeover and an upgrade. According to the importance I assigned to CPU/memory/LOC these are the rankings (higher score = better). The funny thing is that I'm just beginning to like Ocaml. In any case, you may notice that C++, unlike Java, has a honorable rank.

Fail with whistles

Today I have spent almost 5 hours trying to draw some useful UML diagrams using Poseidon. I was aware that it is a very slow and memory hungry beast but, in general, I can live without speed; even if I don't like it. Anyway, the lesson I have learned today is: if the input of your routine is not meeting the preconditions then fail and do so with bells and whistles. Tell your client what is wrong with the data. Do not try to $quot;correct" the situation by second guessing what the he really meant. This will only annoy him further. Let me give you an example. Three out of those five hours were spent trying to convince Poseidon to write a constructor with the signature WordDictionaryEnumerator(dict : WordDictionaryTemplate, initialNode : LexicalTree). For some (yet unknown) reason every attempt of mine to create such a constructor resulted in the creation of the contructor WordDictionaryEnumerator() and no error message to hint me to what exactly Poseidon doesn't like. I will never use it again! I'll try Visual Paradigm to see if it is better.

Broken window theory

I have just read a paragraph from The Pragmatic Programmer that I really enjoyed so I want to share it. On the net there is an interview with the authors on the particular subject of broken window theory. It resonates well with my thoughts on software development.