I like Lego: An abstraction about Design

In my experience, there is always one family that always gives the good Christmas and birthday presents, the ones that you remember into your adulthood.

For me, that family was my mum’s brothers family, and apart from their enormous generosity they showed our family, there are two things that came from them that I can say had some influence on my development as a computer geek. The last one was an Amiga computer which just helped me stay in touch with the rest of the computing world whilst everything had moved onto PC’s and the regurgitation of Windows 95 and this new ‘multimedia’ buzzword that these PC’s could do. Pfft.

Anyhow, the other gift, was a huge Lego set when I was about 3 years old. As you know Lego is modular, each piece does its specified task, and if you ever had to unit test a Lego block, it’d have well defined behaviors to make this a straight forward task (we’d hope).

Now when you start considering the connections Lego pieces can have with each other, there are a number of permutations possible. Lego’s are blocks that form structures in our space and have to live by the rules of gravity and laws of ‘building strength’. We can shape (and even force) these structures to take somewhat unusual shapes that challenge the contract that each lego block has with its neighbours by trying to squeeze the sides of piece into itself (to allow a triangle or odd shape piece to fit). Or we can challenge the laws of gravity by arranging the pieces one on top of the other until the slight variations in each piece cause the stack to start arching over to one side and eventually fall.

Such problems are unforeseen during the design of the Lego piece. Where do we go from here? Do we enhance our existing Lego block with new means to cope with these conditions? Such as a fan to keep the piece in an orientation when the promiscuous falling condition is met, or a removable lego side to allow for those hard to fit pieces to overlap somewhat.

Google’s internal code review tool

http://www.niallkennedy.com/blog/archives/2006/11/google-mondrian.html

Recently at my work, someone asked, why do we keep lacking unit tests? Now there are many varied reasons for this and the discussion can go on forever, but I should say, that there is an understanding amongst us that unit tests as well as other tests (ie user acceptance) needs to be done after an item is completed.

The problem as I see it, is the lack of review at the end of the completion of the item. If we do not review each others work, not just the code, but the process, the checks have been followed, verify the user has reviewed and is happy with the work, verify the work against the user spec, SUFFICIENT TESTS EXIST, etc, then we cannot ensure quality.

We are a small team, there is no assigned quality manager who is responsible for the above quality controls being followed.

The point of this blog then, is to introduce a tool Google wrote for themselves, they name Mondrian. It’s purpose is to do web based code reviews. Ok, so my intro above was a little disjointed to the subject, but it does reduce the barriers in doing code reviews, in my opinion, what should be a strong quality control feature. It provides an audit trail of these said features also.

Look at the attached video of the presentation of Mondrian. The first 15 mins serve as a great introduction into the problems of code review (emails flying around, finding someone to do the review). I like that the presenter makes the distinction: Some places do pair programming, others do code reviews. Both are in XP, but it seems that one or the other are both strong quality controls and in a place where there aren’t the staff to devote to pair programming, increasing the importance of code reviews sounds like a pretty sound manoeuvre.

Java Fun and Games: Tips from the Java grab bag

http://www.javaworld.com/javaworld/jw-01-2007/jw-0102-games.html?fsrc=rss-index

I’m sure these will come in handy from time to time.

  • The simplest sound API
  • Window centering
  • Drop shadows
  • Hyperlinks and browser launching
  • Status bars
  • Image grabber (website)

How null breaks polymorphism: or the problem with null

http://eureka3d.com/blog/?p=21

Do you find yourself constantly checking for null

Does your clever little method now look like a small mess after you’ve incorporated your null checks? Do you find yourself asking, ‘how is anyone else going to ever follow that now’?

If so, then how is this for a neat idea? Write a language with a keyword that tells the compiler that a parameter you are passing or expecting to receive from a method cannot be null, and as a result of this checking, know that you can code the method with a lot more clarity and an immunity to null pointer exceptions.

Steve Riley’s 2 part blog on this subject poses the above scenario and some solutions even for those of us stuck in a language we cannot neuter the nulls. It’s a very enjoyable read.

Kon likes reading so much, he doesn’t get time to read

Here are some good software development links to various sources regarding a variety of different things:

My Favorite Java Developer interview questions – No, I’m not looking, but it would be useful to have in future.

4 Ways to Scare Off Good Devs – Just entertaining, what not to go for guide.

Getting Real – HOWTO: Build and market your own software and get a realistic million bucks in return. And a guide to a good project in general.

Mocks Aren’t Stubs – Everyone loves TDD

Test Driven Development : A party drug

My good friend Scott recently got into Test Driven Development, essentially pointing out that the crossover to understanding why TDD was important basically sat between the fact that TDD was essentially misnamed. If you took out the references to Testing, which is generally seen as a dull chore to many new and experienced coders, then you are left with a development process which is much more interactive than producing UML diagrams and can tell other developers a lot more about your design (and hopefully less open to interpretation.)

The process of writing tests before you develop in TDD is to explain the behaviour of a class rather than actually testing it. He pointed me to some links that explained the very position and how some are considering the name Behaviour Driven Development in place of TDD and frameworks to help interface with such a thing.

So thanks to Scott, here are some great links about TDD where you can hopefully understand the why’s behind it.

Jean-Paul Boodhoo – Behaviour Driven Development
James Kovacs’ Weblog – A Tale of Two Epiphanies: TDD and Mocking
NSpec Homepage
And a great site that talks about testing of all sorts on all different platforms – testdriven.com

Oh, and if you are wondering the crazed title of this blog came from… Once I’d been preaching TDD to Scott for the past few weeks and he finally got the exact why when he actually did it and what benefits you experience from it, I likened the experience to a drug user explaining to a non-drug user why they perceive rave music to be the most enthralling thing they’ve ever experienced, the non-user will never get it till they’ve tried it.

Java Online Training and Tutorials

http://java.sun.com/developer/onlineTraining/index.html

The following appears to be a more mature version of the Java tutorial and makes reference to tutorials outside of the basic Java Tutorial. (ie JavaBeans 101)

HowTo: Change the Autonumber start value and increment in MS Access

http://support.microsoft.com/kb/202121/

Here was a problem that was perplexing us with MS Access. You can only have an autonumber field begin at one. The attached MS Support site shows you how to get around it. Basically, JET has an IDENTITY() operator used in its CREATE TABLE function that takes parameters on the seed (first value) and the increment amount.

Whilst a bit late for my current uni assignment, I will be sure to implement this in part 2.