How we built Flickr workshop and Web Directions North conference

I just came home after a two-day Web Directions South 2006 conference. This conference was a huge success. I will blog about it more later. What is next? Well, there is going to be a Web Directions North conference in Vancouver in 6-10 February next year. And if you look at the schedule, there is some skiing and boarding planned as well... just get your boss to pay for it :-)

This is a link to the upcoming one-day workshop presented by Cal Henderson on Building Enterprise Web Apps on a Budget - How We Built Flickr organized by webworkshops.

It is scheduled as following:
Brisbane 13 November 2006
Sydney 14 November 2006
Canberra 16 November 2006
Melbourne 17 November 2006

Hope to see you there!

Have you Googled Yourself?

As John DellaContrada an UB Internet-Culture Expert says in his "Self-Googling" Isn't Just Vanity; It's a Shrewd Form of Personal "Brand Management"

"Self-Googling" -- searching for your own name on the popular Google search engine -- may seem like an innocuous act of vanity, but a University at Buffalo communications professor recommends it as a shrewd form of "personal brand management" in the digital age.

I don't do this much, but how can I resist? I write this blog and few other things in other places so I wondered what people find when they search my name. So I googled my surname... I got 7 out of 10 results on the first page.

And as John DellaContrada consludes

"Starting your own Weblog or Web site can help you to shape your public image, and make sure that it accurately reflects your abilities and interests."

So what are you waiting for? Go out there and start writing!

Good Design in Practice

I attended the first day of the Web Directions South 2006 conference today. Some of the topics that were covered today were about the design of the web sites and web pages or the design in general. Since I read The Design of Everyday Things by Donal A. Norman (which I mentioned in one of my previous posts about Good Desing) I tend to look at things in a different way. And I also appreciate the good design of the things we use. A thing can have all it needs but if not designed well it will fail as it will be unusable (see the cover of the book and you'll get the idea at least – or read the whole book).

There was one of the things that I use in my everyday life, but only today I realized how brilliantly it was designed. Derek Featherstone has apparently same eye as me as he showed us the photo that he took the day before. It was a photo of

The pedestrian crossing button

How perfect it is! Not only you can see the big white arrow but if your eyesight is impaired you can touch and feel the smaller raised arrow. And that is not all! If you cannot see it, you can hear it ticking when the green light is on. And that still is not all! If you cannot see nor hear, you can still feel it. The button VIBRATES!!! Derek said it at the conference and was all excited about it. I did not believe. I had to touch it on my way home from the conference. It is true! It does vibrate!

How cool is that?! That is a successful design in practice. Way to go designers!

What is next? Well, as a software developer I will focus a bit more on designing the web applications in a way that all people can access them, even if they have some disabilities. Sometimes we go and design things that are cool, but not usable by all of us...

First element in the List

Imagine this scenario. You are working on an existing application. There is a framework used. One of the benefits that this framework gives you is retrieving and processing parameters coming from the client, let's say a web application. The framework gives you all parameters as a List. Now in this particular case you always get only one parameter, but is it enclosed in the List. How do you get it out efficiently?

The intended method would be described: Get the list of parameters and if not empty, return first element in the list otherwise return null. The code was looked similar to this:

1 public E getSingleParam(List params) {
2     E param = null;
3     if (params != null && params.size() >= 1) {
4         param = params.iterator().next();
5     }
6 }

This code works fine but it has several points for improvement. First is how the code at line 3 expresses the intention of check whether the list of parameters is not null and not empty, specifically the later. List interface defines boolean isEmpty() method that is in most cases more efficient to run than getting the size and comparing it to 0 (greater than) or 1 (grater than or equal). That is if the list implements an internal flag for its "emptiness" state or has an internal counter as opposed to re-counting its elements. In the worst case scenario the efficiency will be the same as getting the size and comparing it with 0. In that case isEmpty() method is still a nice convenience method to call and should be preferred before the size() > 0 alternative. Another reason is that it speaks for itself. All we need to know is whether there are any elements in the list or not. Getting the size should be used to for other purposes (e.g. calculating the width of the table column when displaying the results in a tabular form – 100% / size()).

1 public E getSingleParam(List params) {
2     E param = null;
3     if (params != null && !params.isEmpty()) {
4         param = params.iterator().next();
5     }
6 }

The second point of making the code to perform better and to make it easier to read is the line 4. On this line we are getting the first element of the list. As shown in the example above, this is an inefficient way as we construct an Iterator only for the purpose of one iteration. Constructing new objects and disposing of them is usually expensive and should be avoided. A better way is to access the element directly, such as:

1 public E getSingleParam(List params) {
2     E param = null;
3     if (params != null && !params.isEmpty()) {
4         param = params.get(0);
5     }
6 }

This way no new objects are constructed (no Iterator). Another difference between the two is the exception that could be possibly thrown. The exception would be thrown if we did not have the previous check or in the case of concurrent modification of the list which is very unlikely in this case. The exception thrown in first case would be a NoSuchElementException. In the second way, an IndexOutOfBoundsException would be thrown. Both of them are runtime exceptions and do not have to be declared. In this case getting one exception or the other should not make any difference.