An Introduction to Threads

A presentation about threads in Java. It is quite a brief presentation of about 12 pages with 2 slides on each page but it is very clear and easy to read and understand. I would probably recommend reading/downloading this slide if you have already about threads and want something to help you recap the main points in preparation for the SCJP Java 5 exam

I have found some other resources on threads if you are wanting more information.

http://hoskinator.blogspot.com/2006/05/threads-some-resources-on-threads-and.html

http://hoskinator.blogspot.com/2006/05/scjp-toughest-topic-threads-and.html

I have heard from people who have done the exam that there is quite a few thread questions and there are often the more difficult questions on the exam, here is the link to the PDF presentation

http://www.se.rit.edu/~jrv/courses/CS3/Threads.pdf

The slide covers this topics under the title "What You Need to Know about Threads"

1. What code does a thread execute?

2. What state can a thread be in?

3. How does a thread change its state?

4. How does synchronization work?

Even if you aren't studying for the SCJP 5 Exam this is quite a good introduction to threads because it covers all the basic points and even has a few thread code examples. It's basically a tutorial on threads without the waffle, which is why I thought it was good for some SCJP 5 Thread revision.

Avoid empty catch blocks

When I was writing code under a very harsh deadline and there was smoke coming off the keyboard, I had left a few exceptions just being caught but without doing anything in them.

This is a really bad state of affairs and it's certainly not something I am proud of. I have been going back through today and deciding what I should do in some of these errors.

In most cases I am just logging out the error message with some information (like class name, method name and additional information). This might not seem that good but it's a whole lot better than having nothing in the catch block and at least you can get the customer to turn on the logger and read out the message to you.

I recently have been the beneficiary of this, I had a problem whilst installing the software at a customers site and turned on the login and although I didn't have a clue what was causing the problem, at least we knew where to look because we logged out the error message with a e.getMessage with the class name and method name in front of it.

Whilst feeling in the exception blocks, I thought how lucky I was that the code (thanks to some unit tests) worked but if it hadn't then I would have had a clue because there would have been no error messages in the log files to look at.

I have vowed not to let this sloppy coding practice continue, it would have only taken me a few minutes when writing the code. It can be easy to do this no code in the catch blocks because they are auto generated by eclipse but don't fall into the trap.

I think I am going to try and get eclipse to fill in the necessary code for me, so I won't forget, now that would be nice.

Interfaces and Abstract Classes - Don't design without them

Although this is a small article, which is some of the time is a good thing. The article won't help you learn how to use Abstract classes or interfaces but it does explain why they are useful, particularly why they are useful when used with Object orientated programming.

It describes the way I view interfaces and abstract classes where the interface or abstract class becomes the type instead of just the class. What this allows you to do is have many classes to become the same type as the interface or abstract class by implementing the interface or extending the abstract class. In other words Interfaces allow you to use Polymorphism but without the hierarchy and coupling that comes with abstract classes. This gives you good flexible points in your code where you can easily change the workings behind this type thus making your code easily changed in the future. The use of interfaces also allows you to separate the code via the interface and decouple the code.

I have blogged about Abstract classes versus Interfaces http://hoskinator.blogspot.com/2006/04/interfaces-vs-abstract-classes.html

but this articles takes a different approach by just describing the benefits and strengths of both. It finally talks about the collections frameworks as a good example of interface and abstract class usage.

here's the link

http://javalive.com/modules/articles/article.php?id=15

I really enjoyed reading the article, especially the part about interfaces because although it wasn't very long it explained the benefits of using interfaces very succinctly

April 2006 search engine market shares: Google - 43.1%, Yahoo! - 28%, MSN - 12.9%

I find this interesting statistic and I have to admit I do like a completely unscientific fact to tell my mates. I have often wondered about the which search engine people use. I did also find another stastic about hte top sites

http://hoskinator.blogspot.com/2006/05/top-web-sites-in-april-2006-yahoo.html whcih Yahoo where top, microsoft and MSN 2nd and 3rd and Google coming in 4th.

The statistic for April shows that Google is by far the most popular search engine but are probably losing out on services supplied like MSN and Yahoo groups. I reckon though the figures will change in the future with google offering more service type programs like Google maps etc.

April 2006 search engine market shares: Google - 43.1%, Yahoo! - 28%, MSN - 12.9% by ZDNet's ZDNet Research -- In April 2006, Google gained in search market share for the 9th consecutive month and maintained its status as market leader with 43.1% of all US searches conducted on its sites. Yahoo! remained in second place with 28.0%, while MSN ranked third with 12.9%. Americans conducted 6.6 bln searches online in April, up 4% from [...]

150 SCJP Questions And Answers

This page has 150 SCJP java questions. I am not quite sure whether they are for Java 1.4 or 1.5/5 SCJP exam but questions are questions and questions are good practise.

The one critism is that the quesitons are spread out in 65 html pages and the question has the answer right below it so you sometimes see the answer before you have a guess at it but looking at this in a positive light at least by spreading out the questions you can tackle 2 questions a day (2 Q's on each page) and get into a good habit like that.

http://www.geocities.com/online_java_certification

SCJP 5 - Autoboxing, Regular expressions and serialization articles

I have found some really useful links for the SCJP Java 5 exam. This article is well written and covers quite a few of the tricky areas of the Java 5 SCJP Exam. Even if you aren’t studying for the exam these article’s might still be of interest to you because they cover topics like Autoboxing, serialization, printf and regular expressions.

Part 1

This link has information on the Wrapper classes added in Java 5 and the very useful Autoboxing and unboxing now make them a lot easier to use with literal variables (int, double, char etc)

Part 2

Concentrates on the Java.io packages and reading files and using the BufferedWriters and readers. This is can be quite a tricky area in the exam because you need to know what order you use the classes.

Part 3

This is all about serialization. I found this very useful because I don’t use serialization in my daily programming life, so it was a completely new subject and the more information I could read about it the better.

Part 4

Is about using the Java.text package and formatting number, dates and Strings. Learning how to use the locale class so it transforms the data into the correct locale.

Part 5

One of the nightmare areas for the exam, the fearsome Regular Expressions section. It also talks about the C style printf, which allows you to format you System.outs.

SCJP 5 : Chapter 3. API Contents (Part-1)

SCJP 5 : Chapter 3. API Contents (Part-2)

SCJP 5 : Chapter 3. API Contents (Part-3)

SCJP 5 : Chapter 3. API Contents (Part-4)

SCJP 5 : Chapter 3. API Contents (Part-5)

How FireFox got it's name

Here is Friday why is. Today as I haven't got much time I thought I would find out how firefox got it's name. The actual reason isn't that interesting although it has had a lot of other names and it's history is quite interesting.

Taken from the Mozilla FAQ website

September 2002 the browser was called Phoenix.

April 14 2003 they changed the name to FireBird
they at some time changed it to Mozilla FireBird then February 9 2004 they changed the name to FireFox.

The reason for the numerous name changes was that the company kept choosing names that other people were already using, mostly open sourced projects. I quite like the fact they keep choosing animals, it seems like a popular pastime amongst developers to name their software after an animals.

if you wonder what a firefox is on the mozilla FAQ http://www.mozilla.org/projects/firefox/firefox-name-faq.html they have the answer

A "Firefox" is another name for the red panda. It's basically the little red animal thing at the top of the page.

once again someone complained saying that they already had that name, so they finally plumped for FireFox because no one had that name as a trademark, well not in America. Of course someone had in England but they gave up the rights to Mozilla and Firefox was the name that has stuck.

according to Wikipedia there is also a phrase coined at FireFox in their early releases to describe cookies

"Cookies are delicious delicacies"

if you are interesting in finding more information about Firefox then I would recommend you go over to wikipedia because they had the most interesting information and not to much

http://en.wikipedia.org/wiki/History_of_Mozilla_Firefox

Interactive Programming In Java

I found this good page today which basically has the whole book in chapters for you to read and download.

here's the link check it out http://www.cs101.org/ipij/

I don't think I am going to read the whole book but it has some tasty chapters on inheritance, Designing with Objects and Encapsulation.

This blog entry has the added benefit of now that I have posted here I won't forget where the website is.

Hiding the Implementation and separating the things that change from the things that stay the same

I have recently been thinking of my code as a public API and being careful what I show to other classes using my classes. Viewing classes in this light also help to reduce coupling with other classes. The big benefit this has also is it hides the implementation of a classes methods from the users of the class.

The real benefit of this is that you can then change how the methods do what ever they are doing with the user worrying or knowing (assuming it still works the same way)

This is where Interfaces come into play, where methods hide the implementation of one method, an interface can be used to hide numerous classes implementing that method.

The reason why I am talking about this is because I saw this quote today about one of the goals of Object-Orientated design is

"separating the things that change from the things that stay the same."

someone was looking at my code yesterday and laughed because I had a class called

"HardCodedClientValues"

The deadline for a customer project was brought forward by about a week and I had to write an initial version of the code in 2/3 days. They said hard code everything and just get it done. Knowing that I would have to write it properly a few days after I decided to hide the implementation of the hard coded values behind an interface. Basically there are a number of values that I have hard coded but I think the user would like to have the ability to change them in the next release.

So I created an interface called LLPGSearch and have initially then created a new version of the HardCodedClientValues class and then the rest of the code works using the values it gets from the interface. So now when I have some more time and improve the code, instead of using the HardCodedValues class I will collect the values from some property or xml files but fit them into a class which implements the LLPGSearch Interface which should hopefully mean the rest of the code will work not knowing that I have changed what's behind the interface. Basically showing that by hiding the implementation using an interface I have separated the things that change from the things that stay the same.

I liked this code because firstly it seemed funny to me and other developers to see someone write a class called "HardCodedClientValues" and I don't think they understood what I was doing. It was also interesting for me because it was hiding the implementation but I wasn't thinking about that by name but realised that I had done that when I read this good explanation of Hiding the implementation from Thinking in Java 3rd

Every time you fix a bug you risk introducing another

I read this article today called Why we all sell software with bugs, I actually read the article in the newspaper which had a link to his site where I found the full article http://software.ericsink.com/articles/Four_Questions.html

if you have read my blog recently (hello, is there anyone out there listening, looks like I'm blogging to myself again) you will know that I have recently been stopped abruptly by bugs other developers have put in. The bugs recently have been added whilst fixing other bugs, so the title of this piece and a quote from the article is entirely accurate in my experience.

The most dangerous bug is the what I call the unwanted side effect bug. It involves the changes you have made to fix one bug have unwanted side effects which then makes one or more bugs pop up else where in the system.

In my experience everyone knows there are some bugs in the system and sometimes they aren't high priority merely because they are not effecting the fundamental use of the software. Bugs can also be ignored if there is an easy work around for them, some times is safer to do this rather than wade in the code and fix it. The recent group of bugs have been because a developer has bravely/foolishly changed some of the core classes. It goes without saying that if you change a class that is used all the time then it increases the chances of you putting in a bug. Basically more interaction a class has in your software the increased chance of a bug popping up after you change it's code. The article explains why the company he works for would release code with bugs in (apart from not having any choice because code will always have bugs in, surely?)

1. You release with known bugs because you care about quality so deeply that you know how to decide which bugs are acceptable and which ones are not.
2. You release with known bugs because it is better to ship a product with a quality level that is known than to ship a product which is full of surprises waiting to happen.
3. You release with bugs because the alternative is to fix them and risk introducing more bugs which are worse than the ones you have now.

The article says that basically it all boils down to the title of this blog

"Every time you fix a bug you risk introducing another"

The article has a good section on Should we fix the bug, this is the criteria they use to grade if they should fix a bug

Question One	When this bug happens, how bad is the impact?	Severity
Question Two	How often does this bug happen?	Frequency
Question Three	How much effort would be required to fix this bug?	Cost
Question Four	What is the risk of fixing this bug?	Risk

It's amusing reading the list because a lot of bugs, minor unimportant bugs get fixed merely because the developer thinks its going to be easy and an easy win for the team, whilst at the same time some important bugs aren't fixed because people think it's going to be really difficult.

Why Ships Software with Bugs in it

I think there are more reasons you ship software with bugs in here are some of mine

1. You have put in some new features, the new features are overall worth more to the customers than the new bugs

2. Sometimes you have to release the software because of a deadline

3. The new release of the software fixes some old bugs

The article does have a small section on regression testing, you would think after the cock up of releasing 3 version in a week he would expand this section of the article. I'm going to try and get the developers to improve are practices. I am going to try and get them to write some unit test (junit) and I also want to get the process of a weekly build and test on a Friday maybe. I know this doesn't sound much but from nothing (which we currently have) to this two steps I think it is on the right road. It's also quite difficult to introduce testing procedures because developers don't like them. Also I work for a very small company where we don't have code cut off's and show by this blog entry Code Changes whilst installing - now that is last minute

but every journey has to start somewhere

Code changes whilst installing - now that is last minute

I'm out on site up in cannock chase again, it is has gone pretty well today. They seem happy, the installation process has gone okay.

The problem I had today was some of the features work in the last release but when I upgraded them it didn't work in the current release but the new feature they wanted and the reason for me being here did work. A real case of you can't have your cake and eat it.
To get round the problem I have rung up base camp and explained the problem and they are going to have a look at it and see if they can resolve it and send me an update by before the end of the day, the error is

ERROR 2006-05-25 10:25:37,828 :: : Map : renderMap - Unable to set map grid
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(Unknown Source)

The error looks suspiciously like a Mickey mouse bug where the problem is due to a search in a string which they are expecting to always return a value. I bet its something like they have been passed a blank or a null and then the search hasn't found anything and you get an error like this.

This is also a good excuse for me to bang my unit testing drum because this might have been caught if we had been testing for it because I find that writing Junits often finds lots of silly bugs like this because when writing the tests you tend to think what would happen if I passed a null, what should happen if the method doesn't find anything.

I think I am going to suggest to the developers that we bring in a daily or maybe to start with a weekly build and then quick test of all the front end functionality. At least armed with this I will have a very persuasive argument, I have evidence that we need to stop putting bugs in before the customers get the software.

I wrote the above in the afternoon whilst waiting for the boys back at HQ to send me an update to fix a few bugs (yes we were still coding whilst I was on site installing). The chaps back in the office did a very good job today, I think I had three updates and at the end of the day the application was look pretty sexy and customer was happy. It had a few bugs but the main thing was it worked and I did explain that it was pretty much a prototype but it's a good opportunity for them to help improve the product and have their say how the final improvements should be made.

Strategy Pattern vs. Case Statement

I have seen this mentioned in a lot of refactoring articles. I find it quite difficult or maybe difficult isn't the word but it's not appealing to make such a change to code. It's one of those when you refactoring and it takes quite a while to refactor the code just to get it doing what it already did.

The benefit will come when you have to come and change the code again. Adding the strategy pattern allows you to really separate the code and dependencies. The main benefit of this is that when you have to add a new strategy or type then you can add it in and it doesn't effect the other classes because it is decoupled through the use of the interface or abstract class.

The one thing I would say is that I don't often see much code using large case statements, I find that people usually use big sprawling if statements.

Using a strategy pattern instead of a case statement I found is quite difficult to explain to people, it can be difficult to justify especially to programmers who don't know what the strategy pattern is (by name if not by logic). Initially it seems like you are needlessly creating etc classes to do what they could do by using an if or case statement. The problem I find with if statements is that they tend to grow and start sprawling in one method and then the same logic starts appearing in another method and the dependency on different classes grows, especially when you add a new case or if statement.

The real sign you should consider replacing those case/if statement is when adding one new type or if/case selection takes ages, ending with lots of similar changes.

If you are thinking or wanting to use the strategy pattern it can be added a lot easier when you are writing some new code or a new piece of code. I have used it recently and not just because I wanted to use the strategy pattern (put down that golden hammer) I did it without really remembering it was the strategy pattern until I saw an article on it tonight. The benefits are that the code seems a lot simpler to read and the different code is split up very efficiently.

Of course you do need an if/case select somewhere to know which of the classes to create but the benefit is, it's in one place and attached to as little code as possible.

Anyway you have heard me ramble on about this topic for quite a while, this was the article I found which explained it very nicely, especially as the article/discussion isn't actually very long but then as I have blogged about before you should do the simplest thing that could possibly work

here is the link to the article that provoked this blog http://ootips.org/strategy-vs-case.html
I hope you found it as interesting as I did and please leave some comments on the subject as I'm sure you have guessed it's one that I enjoy waffling on about, probably without out that much insight (that's where you commenting on it help me out)

Last minute coding can't squash all the bugs

Well I have had one crazy day of programming. I came in early and left late. It was as all last minute dash coding, hectic and time going past at double the speed.

It's funny but usually when you are at work time slowly ticks by, it seems to take about three days just to reach lunch and I won't even mention the afternoon. If you have a deadline looming, it's the complete opposite, it seemed as soon as I got it was lunch time.

When you are trying to squeeze a week's worth of programming into two days it does get tricky. In this particular piece of work I was working on the back end and my manager was working on the front end which was done in flash. My code was taking a while but I had done it in a way that once I got the first bit done then the other bits should be easy to add in. We connected up the code just before lunch. A bit of ironing out with variable names and what he was expecting to receive what I was expecting to send. Success.

Then during the afternoon we added the rest of the code and as usual there were some minor bugs to iron out but it seemed to go okay.

It was only during the last part of the day that we noticed some bigger bugs. This is basically what I warned them would happen, if we don't have time to test then we are basically going to give them a problem with some bugs in. The work was a database search for postcodes. I didn't realise that there are about 6 columns to do with the number. If there isn't a number it has a name and the name has a prefix and affix. This was a project that we had done before but on an old application, so some people knew this but I didn't so I only put the number in. Earlier in the project I had said I am going to put a null in for columns which have no data, yes this was fine everyone said....Until today when now it isn't. The other major problem is I had to hard code a lot of the parameters, fine they said. This will probably be fine until I get out on the customers site tomorrow and they want to change something.

On the plus side doing things in a rush does give you something to show for your hard work and showing the customer something early does have benefits because they can tell you what they like and what they don't like and you haven't wasted too much time doing it. It's also pretty exciting working to a tight deadline (not all the time though). The only thing I am not that pleased about is having no time to test the code, there are quite a few bugs which given an extra half a day or day would be sorted.

Tomorrow is going to be a bit of magic show, a lot of slight of hand and getting the customers eyes on the other features and not to focused on the buggy new postcode search. Oh well at least I get my expenses paid.

Head First Design Patterns - free pdf Decorator chapter

I noticed that the Head First Design Patterns book has a free chapter on the Decorator pattern. I actually own the Head First Design patterns book but because this chapter was free I read it again.

The decorator pattern is quite a peculiar pattern to look at, it almost works as if by magic, it has a kind of beauty that tends to come from simple idea which is incredible effective .

The decorator pattern should in theory be quite simple to understand e.g. it decorates an object with some functionality, it does what it says on the tin. In reality the code didn't seem that simple to me and I had to read it and the examples about three times. This chapter helped a lot because the examples were fantastic and they were worked was amazing but then reading the explanation and reasoning took me a while to understand how the code work.

so if like me you half understood the decorator pattern then read this chapter I think it will help you a lot. Of course it's a free pdf on the Decorator pattern so it's well worth downloading for later use.

The chapter is always very good because it shows how some initial code worked and then how they refactored it to use the Decorator pattern. This is a very good application of the decorator pattern and in a similar scenario to many of the people reading the chapter.

I almost forgot to actually past the link so here it is

http://www.oreilly.com/catalog/hfdesignpat/chapter/ch03.pdf

Once again if you don't own this book its well worth the investment and really helped explain the tricky world of design patterns using easy to follow and amusing examples.

Hiding change behind an Interface

The powers that be (my manager and above) decided that instead of the week I had to write the code for my program that they are only going to give me 3 days. I explained that to do this is going to mean that I am going to have to hard code a lot of stuff and rather than extend the current code, it is going to be a one off and not very reusable piece of code instead.

Well the customer is desperate, they want it now.

So we have had to drop everything and work full steam a head on this project. What makes this extra interesting for me is that I am going to have to go there and install and run it this Thursday as well. It's going to be an interesting day to say the least, the code is going to have minimal testing and hardly any other than my development environment.

Still it's quite exciting all this rushing around in the code and there is nothing like a looming deadline to motivate you.

My plan was the first draft, e.g. maximum hard coding and then once that is working then I am going to try and link it up to some XML files so they can change some of the variables and allow a bit of flexibility.

I have been coding it so that although there is hard coding, I have put the hard coding inside a class which generates the variables needed. In some ways it's a bit like a mock object. I have also hidden this behind an interface. Hopefully once I get to try and read it off the XML files I can just add a different set of data behind the interface and all the rest of the code will work just the same.

I am still learning how, when and where to use interfaces. Sometimes I struggle to think where should I use an interface because they are so easily added in with no benefit. I was surprised in the end how useful the interface is going to be. Actually I wouldn't say surprised by pleased how well the interface is going to work in this scenario. It also high lights the power of the interface and it's ability to hide change, to create flex points in the code where you can literally hide different varieties of classes behind the interface.

Interfaces are quite an unusual beast, I don't feel Sun's tutorials and most books actually describe what interfaces purpose are very well. Granted they write very clearly how they work but I felt they never told you the why of interfaces. It has only since I have been reading some design patterns and Object Orientated articles that I have realised their real value and purpose.
Anyway the race is on for me to get the coding done by Wednesday evening, well it's not a race as such it's code as much as I can and then I'm taking out to the customer on Thursday, Rock and roll.

Creating passionate users enters the technorati top 100

Congratulations to the creating passionate users blog they have made it into the Technorati Top 100. Which is pretty amazing when you see the numbers of people linking to their blog (like me).

They are currently 84 with 6260 links from 2733 sites, holy moly that's a lot. My poor little blog only has 105 links from 8 sites and I am rank 362,427 but I have only been blogging for just over a month so it isn't to bad.

Whilst I was on the Technorati website I wondered what people with excellent taste in blogs had linked to mine (yes I really am that sad). The blog was

http://blog.360.yahoo.com/blog-L8FHhfglaafunnJdDw4-?cq=1&p=317#comments

and he had this quote

"... often you don't see other peoples code unless there is a problem with it." -- the Hoskinator

I have to admit I thought I sounded pretty good, apart from the ultra sad Hoskinator title I have given myself, still it helps me not take myself to seriously.

The blog from Passionate users blog was about how and why they have made such a popular blog so that it made it into the top 100 at Technorati. Personally I think it's because their blog is always interesting and even if it isn't it is written in a witty amusing way (which is where I am aim at and sadly fall below). I think their blog also benefits from not always being technical it's about life as a developer, like learning, reading articles. There is a lot of technical information out there and often these blogs just contain cold hard facts and not much fun or interesting comments from author. The problem with these blogs is that there are so many about why would you become loyal to one.

One of the most important things in a blog is to put your imprint on the blog, put your opinions, thoughts, fun, so that your blog is different because you wrote it. This really comes across from their blog, it's very different from the other blogs out there and it's very original and most importantly they tackle interesting topics in a friendly interesting way so it's very enjoyable to read.

Another good feature from the Creating passionate users blog is the number of comments that their blog entries get, the \nwhat makes a popular blog had over 100 comments to the article. Comments can add a completely new dimension to a blog entry and reading different peoples thoughts and experiences always helps me to understand the problem because you get to see all the different arguments regarding the blog.

Another good feature from the Creating passionate users blog is the number of comments that their blog entries get, the what makes a popular blog had over 100 comments to the article. Comments can add a completely new dimension to a blog entry and reading different peoples thoughts and experiences always helps me to understand the problem because you get to see all the different arguments regarding the blog.

SCJP 5 Resource - Flow Control

This is probably one of the easier topics on the Java 5 exam because if you are programming in Java then you will have had to use the flow control (IF and SWITCH statements etc).

The code also deals with the enum. This can be an exam nightmare because of all the extra things you can do with enums and the fact that it acts like a special class in many ways. It has the potential to provide some very tricky Java 5 exam questions so any information on this topic is welcome to me.

The Enum is also allowed in switch statements, this can be an exam gotcha because you might think that this isn’t allowed and they are trying to catch you out, in fact they are using the double bluff.

Enums are one of the new features added in Java 5 that are both simple and complex at the same time. As soon as you see them you think cool, this is going to be really useful and then you see the examples or Exam questions on Enums and you think, oh my god look at all the possible syntax errors I could run into. Unlike some of the other features added into Java 5 Enums was done excellently and doesn’t seem as much of a hack as the other features.

The tutorial also explains the new enhanced for loop which is a piece of cake but you have to make sure you understand what is on each side of the enhanced for loop.

Anyway here are the links, enjoy

SCJP 5 : Chapter 2. Flow Control (Part-1)

SCJP 5 : Chapter 2. Flow Control (Part-2)

SCJP 5 : Chapter 2. Flow Control (Part-3)

SCJP 5 : Chapter 2. Flow Control (Part-4)

SCJP 5 : Chapter 2. Flow Control (Part-5)

1 mln US jobs to be outsourced by year-end 2006

I saw this on ZDNet today, jobs being outsourced to India is a bit like global warming melting more bits of the antartic, it's not something you are to worried about until it starts to effect you. I wonder how long this will go on until people really start to get concerned about it.

1 mln US jobs to be outsourced by year-end 2006 by ZDNet's ZDNet Research -- The number of jobs offshored from the US to India and elsewhere has tripled since 2003, to a projected total of 1 mln in 2006, with roughly 25% of them in high tech.

Of course I am only talking about my experience their may be people already concerned and people who have lost their jobs. I was made redundant once and although it's not very nice, well actually I didn't mind being paid off to go and find another job. I wasn't too worried because I still felt that there were plenty of jobs out there

Of course if this rate of outsourcing continues I'm pretty sure we will all be concerned. It's just an interesting fact (I'm a sucker for a good fact) I thought I would blog about

How should you deal with null's passed into methods

another day, another bug put in the system which has halted what ever development I was doing. This is a classic case of putting a fix into solve one problem and in it's place is one if not more bugs.

This is a slightly interesting bug. Basically we have a Utils Static/helper class and it has a removeFraction function. The function itself is pretty dodgy but basically you pass a String into the function but you know the String is really a number but as a String. This isn't to bad because a lot of variables are passed around as String or a good example is that the main method in Java accepts an array of String but the variables could be anything waiting for you to convert them.

The function then finds the index of the "." fullstop and then takes what's on the left (no rounding here). Although it's a tad dodgy it's not to bad .......Except when you pass a null into it. Now it is difficult sometimes to know what to do if some code tries to pass a null into your method, a lot of the time you could just say, well if you are stupid enough to pass me a null I am going to throw an exception and this is fair play at least you are warning code that calls your function what you might do. I thought of catching the null and passing it back as null but then this is not a good thing to do and more than likely you are just passing the bug on, unless the class you are passing back to has better exception handling.

I was disappointed that this problem had occurred because for this class I had created a unit test, so the developer added this method he could have easily added in a test. A good reason why you should add unit tests (along with all the others) is that when you are testing a function/method when you think about how you should test the function you often think about what should happen if some fool passes in a null but often when you don't write a unit test you never think that anyone would pass in a null, why would they do that.

I have read in effective Java and by a presentation on API both by Joshua Bloch that you should validate the values passed into a method and I think this is a prime example. By validating and dealing with wrong values and nulls inside the method it means that you will only have to have this code in once instead of all the code calling the method having to validate it.

In this example I have chosen to put a try and catch block around the code which tries to remove the fullstop, so if it is a null an error gets thrown and I have decided to return a zero which seems a fair trade a null for a zero. The one problem I did have was I wasn't quite sure where this badboy got called and the effect returning zeros might have. I have tested it and all seems to be working but you never can tell.

To fix my problem, I did nothing

I had a interesting few days trying to fix this bug. We are not quite sure which of the millions of changes is responsible for the overview map not working. The overview map is a small zoomed out map of the current map. The piece of functionality works 2 releases ago but now doesn't. Obviously there have been a lot of changes that have been put in. I have spent the last few days trying to fix this problem but in the end I told someone who has changed quite a few things and he snuck off and then said he had changed something. It now works a lot better.

I can tell the code is in poor state because regardless of code smells http://hoskinator.blogspot.com/2006/05/smells-to-refactoring-cheat-sheet.html is that I'm terrified to change any of the code. A lot of the code is complete voodoo magic with bizarre activity going on all over the place. There are a couple of instances where functions are called twice and I'm not entirely sure why and when you ask anyone else they are not sure why either. I'm afraid I'm too much of a wimp to take it out (this late in the week) because it is in some core classes used by often
.

At the moment all map objects are treated the same, this has it's advantages with no need for lots of if's etc. I thought about trying to find a way to treat the overview map differently but in the end it would involve a lot of if statements or a major refactoring. In the end I have had to give up on the. Idea, which is a bit unsatisfying but I haven't got the time. The positives I can take from this is that the bug is fixed now and I feel like I have had a warning for some coding to come and at least I will be better prepared for the challenges that lie ahead in the legacy code jungle. Right I'm off to sharpen my machete.

So after a few days bug fixing I have made zero changes but feel glad that I have got out alive and without putting any more bugs in. It's probably only in programming that you can get stuck like these for a few days.

At last I have finished reading all 800 pages of the Sun Certified Programmer for Java 5: Study Guide Exam 310-055

I have finally finished reading the Sun Certified Programmer for Java 5: Study Guide Exam 310-055 (Certification Press S.)

I have reviewed this book

but basically if you are going to take the Java 5 SCJP exam buy this book, end of story.

Right as I was saying I had finally finished this beast of a book, yes 800 pages and many hours reading this big old text book whilst all my mates were out playing down the pub, ooohh what a cruel cruel world we live in.

Still I am in good shape regarding the Java 5 SCJP exam, apart from the fact it has been so long since I started the book I can't remember the first five chapters and I feel that if I go back and read them I will stuck in a constant loop, like a dog chasing his tail.

So now armed with my queue cards (spelling!!?!) I shall be reading and testing myself with those badboys. I will also be reading some final notes that I have a link to on my site (which means there are too many for me to link too). I shall also start doing some practise exams and just get up to stratch on exam questions and finding where my knowledge is weak.

It is another step in the right direction, I feel now that my goal is in sight or I'm on the last few miles of a Marathon

Become a Java Black Belt

I thought I would write a blog entry to big up the Java black belt. I passed my yellow belt the other day and you can choose to send the congratulations email to other people, so I sent it to my fellow developers.

If you want to know what Java black belt is, well a proper description rather than just my blog entry, they have a presentation here

http://www.javalobby.org/eps/javablackbelt/

but to be honest I think you can pretty much guess what it’s about. You have a load of tests and the more your pass the higher belt you get. They have recently been expanding the things you can test yourself with, Ant, JDBC, Struts, Spring and loads more.

For people studying for the SCJP 5 exam there actually have some beta tests on the Java 5 features as well as an exam on OO and your basic Java features. Which all add up to some good exam practise. I don’t think the level of difficulty is not as high as the proper Java 5 exam, so maybe it’s a good place to start.

http://www.javablackbelt.com/

The site says it’s

“With JavaBlackBelt, we want to give each Java developer an alternate way to measure and demonstrate his/her technical skills.”

Personally I see it as an interesting way to test your knowledge and get one over your fellow developers by being a higher grade. I don’t really see the belt grade as much value, I won’t be putting it on my CV (well I am only a lowly yellow belt). The other frustrating thing is that you have to contribute to gain points so you can take the tests. I know this isn’t in the spirit of things but I just want to take the tests, I don’t want to mark and suggest improvements, I’m sure there are many people who don’t mind helping, this is probably mean spirited of me but bah humbug

I have noticed that recently they have been putting a lot more adverts on the site but they are tucked away and quite a few for Amazon which has me tempted to click on them and buy those lovely developer books in a Homer Simpson after a donut way.

Anyway go and check them out and start getting your Java belts.

Another reason it appeals to me is because I attend a Taekwondo class (when not hung over) at Aston science university (no I’m not a student) like all things martial arts watching and doing. I am currently a red belt, which means

“danger – to myself and others”

This also probably sums up my coding style :-)

The Simplest Thing that Could Possibly Work

For a long time I never really understood this comment or this way of thinking. It seemed such an odd thing to say to advocate. It is similar to Test Driven Development where you have a test and then you do the simplest thing to make it pass. I believe their is also something similar to this idea in Extreme Programming which one of the key principles is

Simple Design.

"A program built with XP should be the simplest program that meets the current requirements. There is not much building "for the future". Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design, and in XP this is brought about through "refactoring", discussed below."

I have for a long time suffered from putting in overloaded methods in case people in the future might need it or adding in functionality that wasn't needed to solve the current problem but might be useful later. About six months ago after reading something like the principle above and hearing other people say similar things, I have tried to give this waste of time up and just do the simplest thing needed

It wasn't until I tried writing a junit test first that I really started to understand what the real meaning was. I did a test and then just passed back what ever value I expected. Then when I tried another test I added in the functionality to make that pass. When I tried some other tests to try and break the code I found I had just enough code to allow the code to do what I wanted and no extra code. It was at this point I realised what the this statements means, just do the simplest thing to make the code work, anything else is just wasting your time.

I also take it to mean that do the simplest thing on this piece of code because there is another challenge waiting for you to write some more code. It means you end up writing more useful code that people are going to use rather than extra methods that people don't need but might in the future (but who says they will)

The statement doesn't mean you should just wedge in any old code, I take it to mean that you should just code enough code to solve your current problem but the code should be easy to extend, it's just that you are not going to that now.

The reason why I am blogging about this is because I saw this article on Artima today about the topic in the title, this is actually the last part in a series of articles. I recommend you read the article as it explains the idea in a much better way than my interpretation.

One good reason the article recommends you should do the simplest thing is because you often don't understand the problem fully when you are starting out and doing it this way means you don't waste to much time and code when you realise the problem is different to what you thought.

This quote really gets to the heart of the statement

In programming, a lot of simplicity comes from knowing what matters and what doesn't matter. A lot of times a program is made complicated because it's attending to details that aren't needed, or could have been avoided, or could have been relegated to something else.

Everyone has probably come across the actions the quote describes by accident. There have been times when for some reason I have lost the code I was writing, I had spent a week writing the code but when I found that it was gone it only took me a day to rewrite it and do it differently and more efficiently than before. The reason is when you tackle a coding problem the solution comes into investigating the problem, write some code that works and some code that doesn't and then refactoring it to be more usually more simple. All the knowledge is in your head through all the work you have done trying to solve the problem and knowing what you need to do to solve the problem.

Here's the link, enjoy

http://www.artima.com/intv/simplestP.html

I would be interested to read other people's interpretation of the doing the simplest thing that could possibly work because recently it's something I have been trying to remind myself of when tackling tasks.

Comment spam - beware Anonymous bearing compliments

I got my first comment Spam yesterday, well I think it was comment spam. The spam had one line of random sentence and then a link to some searching type site. It embarrassingly took me a while to understand that this was spam because they were very cunning and hide the spam amongst a compliment. Initially I was thinking, yeah people are digging the site, they just couldn't read the blog entry and not say how good the site was, you know what I don't blame them.

so the first message was

"Anonymous said... Interesting website with a lot of resources and detailed explanations."

I was thinking well it was okay, I could do better, well no perhaps he has a point and then this anonymous reader had to write another comment praising my blog

"Anonymous said... Your site is on top of my favourites - Great work I like it."

okay calm down old boy, you embarrassing me now, I'm English we don't compliments very well. Then this comment popped up

"Anonymous said...Nice! Where you get this guestbook? I want the same script.. Awesome content. thankyou."

What guest book, I haven't got a guest book. Could my secret admirer meant to put this comment on another website, the two timer. I was at this point a bit confused but my spidey sense was starting to tingle. The Anonymous started to add the same comments to other blogs and then double comment certain blog entries. I then noticed there was a little blue link and then realized that there wasn't really someone out there with big love for my blog, he was just a user, I felt used and dirty, my Mother had of course warned me about people like this but I thought this Anonymous commenter was the one. Bah.

So I had to rustle around and turn on the word verification do dah, which will hopefully stop this sort this flatterer.

Worse followed when I went to sleep I had nightmares about evil commentators attacking my blog.

Top Web sites in April 2006: Yahoo!, Microsoft.com, MSN, Google

I found an interesting IT fact today. As someone who looks at his blogs miserly figures, it's quite staggering the numbers of people. It's actually quite shocking to see how many people use ebay. I actually thought google would have been above Yahoo. Maybe next month my blog will get into the top billion ;-) Here's the link

Top Web sites in April 2006: Yahoo!, Microsoft.com, MSN, Google by ZDNet's ZDNet Research -- In April 2006 Yahoo!, Microsoft.com, MSN and Google received over 90 mln unique visitors. Yahoo! was the only one to break the 100 mln unique visitors barrier, according to Nielsen//NetRatings data.Top Web sites in April 2006Web siteAudience, 000Time spentYahoo!105,4443:10:02Microsoft95,7770:45:25MSN92,7861:38:53Google92,1200:52:48AOL70,4336:11:06eBay53,4651:53:00MapQuest40,8010:10:53MySpace38,3592:06:46Real.com38,1830:47:48Amazon37,8540:19:37Source: Nielsen//NetRatingsITFacts also published Web traffic findings for top sites in March 2006, top sites in February [...]

the actual figures on the site our

Top Web sites in April 2006
Web site	Audience, 000	Time spent
Yahoo!	105,444	3:10:02
Microsoft	95,777	0:45:25
MSN	92,786	1:38:53
Google	92,120	0:52:48
AOL	70,433	6:11:06
eBay	53,465	1:53:00
MapQuest	40,801	0:10:53
MySpace	38,359	2:06:46
Real.com	38,183	0:47:48
Amazon	37,854	0:19:37
Source: Nielsen//NetRatings

http://blogs.zdnet.com/ITFacts/wp-trackback.php?p=10912

Head First Design Meditations

this is a good link to mediation links from the creators of Head First books, it's just a link to some good programming quotes.  It basically follows on the master/pupil theme that is used in the Head First Design book.  You click on the get Meditation and it puts out a new programming or interesting quote

http://headfirstlabs.com/books/hfdp/dm.html

with classics like

"Don't have good ideas if you aren't willing to be responsible for them."

-- Alan J. Perlis

 

"We cannot solve our problems with the same thinking we used when we created them."

-- Albert Einstein

 

"Motto for a research laboratory: What we work on today, others will first think of tomorrow."

-- Alan J. Perlis

 

There are many more good quotes for you to have a look at, quite interesting and it is friday after all.  I call this positive time wasting :-)

Information overload - Blog meltdown

I read this article from called the Myth of keeping up there is also an article from Coding Horror which is on the same thing but called Just in time Learning if I was to give it a chirpy name I would call it Technical Blogdown (instead of meltdown).

There is obviously more information that you can read floating around the internet and more blogs than you can shake a stick at. It is a battle to try and read the stuff you will find interesting but without having to wade through loads and loads of blogs, articles, podcasts, presentations and books.

I think one thing that makes things easier is blog aggregators, you can just have a quick look at the title of the blog entry to see if you want to read it. I have recently been trying to unsubscribe from things I need and are just clogging up my rss reader. I think you need a zero tolerance approach, if an rss feed gives you an excuse to unsubscribe do it. I think you need to look at the emails you have signed up to and the blogs and podcasts and think do I really get much from this. Any ones you aren't sure about, get rid of it, you can always subscribe again later on.

This is the same with articles, don't just print any one you think might be useful, wait until you find one that is really useful. Only print one article out at a time and put then put any new ones into a delicious or something similar.

I have been using Delicious recently to help me put things I think might be interesting. For some reason it doesn't seem like as much of an effort to log it in delicious and delete it or read it. Don't fall into the trap of putting to much junk in Delicious or some other link holder.

One of the best pieces of advice from Kathy Seirra is

"Unsubscribe from as many things as possible"

This is something that I have been trying to do to try and get rid of the clutter and information overload.

good luck with your mission if you choose to accept it.

SCJP 5 : Declarations, Initialization and Scoping aritcle

I found this brilliant link to basically a sample chapter on the topic of Declarations, Initization and Scoping. There are six articles so it is a fairly comprehensive on the topic. If you are thinking about doing the SCJP 5 Java Exam then reading this is a really good way to understand what is involved studying for the exam. You suddenly realise how many things you let your IDE just do and how tough the exam is going to be. So if you want help taming the Tiger and get prepared for the Java exam CX-310-055 (Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0) this article will set you on your way

SCJP 5 : Chapter 1. Declarations, Initialization and Scoping (Part-1)

SCJP 5: Chapter 1. Declarations, Initialization and Scoping (Part-2)

SCJP 5 : Chapter 1. Declarations, Initialization and Scoping (Part-3)

SCJP 5: Chapter 1. Declarations, Initialization and Scoping (Part-4)

SCJP 5 : Chapter 1. Declarations, Initialization and Scoping (Part-5)

SCJP 5 : Chapter 1. Declarations, Initialization and Scoping (Part-6)

Method overloading sample chapter - Free PDF

I found this good Java SCJP 5 resource today. I am nearing the end of reading my Java exam book Sun Certified Programmer for Java 5: Study Guide Exam 310-055 so at this point I am trying to keep an eye for test questions on topics in the exam. I like free pdf files and sample chapters so I was happy when I saw this free chapter on

I found this sample chapter from JavaTM Programmer Certification Mock Exam by Dan Chisholm on Method Overloading. I think this chapter was for a book intended to be a mock exam for the Java 1.4 exam but most of it if not all will still be applicable for the Java 5 exam. Plus it is a few questions with explanations so it's good practice.

Here is the link to the pdf file http://www.danchisholm.net/book/chapter12.pdf

Even if you aren't taking the exam you can still learn about Method Overloading in more detail or answer the questions to see how much you do know.

Company away days can be fun

I went on a company away day on Monday and it was good fun. We did some kaiyaking in the morning which was very amusing and quite tiring. I was at the front and I'm sure the my Kayaking partner wasn't doing as much paddling as me. The highlight was two people falling into the cold water.

The afternoon was okay we had to do a number of team building exercises, things like crossing an imaginary "acid lake" which was just a concrete road using rubber tile things and getting a ping pong ball out from a pipe without touching and using water. This were actually a bit more fun than I was expecting.

The final challenge was where we all came together and build a big gutter really using bamboo and gutter, I'm the one in the brown top and combats or with my Tractorboys (Ipswich Town FC) top on.

Smells to Refactoring Cheat Sheet

I saw on William C. Wake's blog http://weblogs.java.net/blog/wwake/archive/2006/05/smell_to_refact.html 

 

Joshua Kerievsky has put on his a pdf file up for download called "Smell to Refactoring Cheat Sheet" http://industriallogic.com/papers/smellstorefactorings.pdf

 

this is a two page quick reference guide to Refactoring and the code smells you should be looking for.  It's a good sheet to have on your desk or pinned up because you can glance at it quickly just as a reminder.  It wasn't until only recently that I have read articles about refactoring and then joy of joys I found the eclipse refactoring tools which are top banana.

 

The comments on the code smells are quite humorous, check this one

 

"Inappropriate Intimacy: Sometimes classes become far too intimate and spend too much time delving into each others’ private parts. We may not be prudes when it comes to people, but we think our classes should follow strict, puritan rules. Over-intimate classes need to be broken up as lovers were in ancient days. [F 85]"

I found this cheat sheet really interesting, especially as I am fixing a bug in some code which smelling stronger than someone who has just came back from Glastonbury

Design for Extension

I have checkstyle turned on in eclipse and it's always moaning about something, especially when I am in the legacy code jungle. Normally I don't mind it because I change a few things and try and put things on the right path but this rule I found weird and couldn't make go away.  It is the rule called

 

"Design for Extension"

 

this is the text describing the rule

 

"Checks that classes are designed for extension. More specifically, it enforces a programming style where super classes provide empty "hooks" that can be implemented by subclasses. The exact rule is that nonprivate, nonstatic methods of classes that can be subclassed must either be a) abstract or b) final or c) have an empty implementation.  Rationale: This API design style protects superclasses against being broken by subclasses. The downside is that subclasses are limited in their flexibility, in particular they cannot prevent execution of code in the superclass, but that also means that subclasses cannot corrupt the state of the superclass by forgetting to call the super method."

 

Normally I don't mind checkstyles rules because for the most part they are getting you to do is make you code better by making variables that aren't going to change final, making me put JavaDoc notes in now so I don't end up just before we release the software having to go back and write out the all the JavaDocs for the classes I have changed, which is a really boring task if there are loads of them.

 

Anyway back to the Design for Extension rule.  I realise you don't have to implement all the rules checkstyle has and there are some I have turned off but I was wondering whether I should turn this rule off or not.  This rule seems a bit over the top.  I suppose I think this is a bit over the top because our code is only used internally I don't feel I have to protect against people extending this class and then overriding this method and breaking the code.  If they do that then it's there own stupid fault

 

but...

 

If I adhered to this rule then this couldn't happen, it would stop a bug occurring which might be done by accident.  The interesting thing about this rule is now that I thought about it, it does have some merit, it is a good ideal.  Alot of the code that is written doesn't design classes to such an extent and there are many legacy classes that are written without thought about whether they are going to be extended or not and probably very unlikely they would be extended.  So when this rule pops complaining it seems slightly absurd, why am worried about people extending this class and overriding this method.  The other problem I have is that although I like writing final variables and trying to make classes final I'm not so keen on making methods final.  I don't really know why this is but if perhaps I do want to extend this class do I want this method final and not.

 

It's interesting with the checkstyles rules they really help you to decide how a class should work and you spend more time thinking of the design of the class.  I started writing this blog entry with the idea of saying that I didn't like this rule but after looking at the idea behind the rule I actually am in favour of it now.  So I think I will leave the rule on just because it helps me think about the design of the class

 

 

Should you comment code

I was recently talking to my fellow programmer and saying that I read somewhere that your code shouldn't have any comments in because it should be self explanatory.  if there is a piece of code that you deem so tricky it needs comments then you should change the code to make it easier to understand and named better.  I believe it was an Extreme Programming article I was reading with this advice.  It is an interesting thought and what is the right level of commenting in your code.

 

Personally I think it has a good ideology but in practise I don't think adding a few comments is such a bad thing but I think to many comments in the code is a definite code smell and you should refactor the code.  A lot of comments is usually found in a big long method. 

 

There are a lot of comments in the code where I work and one of the main reasons is because they don't write unit tests which takes away one level of documentation of code.  Usually you can see what a class or method should be doing by looking at the unit test and seeing what it's testing it for.  I think a decent amount of documentation should be in the JavaDoc comments.  If the code needs a lot of commenting or has a lot of commenting then I am guessing the methods are too long and it should be split up into more well named methods. 

 

I find well named methods document the code really well because if you are looking at the code with well named methods you feel as if you don't have to look in the method to see what it's doing.  I can see that sometimes you are going to need documentation if you use a lot of classes or the classes have complex hierarchies. 

 

I don't think you should get rid of comments in code, I think this is a step to far and what's the real benefit of having no comments.  I also think that every time you are thinking about putting in a comment, you should look at the code to see if you can make it more transparent because over commenting is a definite sign that the code could be refactored and made simpler.

 

 

Why I like podcasts

The Bileblog was slagging off off podcasting, giving it the amusing title of poocasting, have a read if you fancy it. Off topic slightly I find it quite amusing reading the bile blog as his ranting hits a crescendo, I have an image of Basil Fawlty slowly getting angrier.

The bile Blog is an interesting phenomia to me really, some things are crap and worth slagging off. To have a whole blog on it seems like stretching the idea a bit far. Reading the Bile blog often has the opposite effect on me. Instead of agreeing with the rant I usually find myself taking the opposite view, particularly when I read about podcasts.

The main critiscms of podcasts from the bile blog are

"From what I understand, it's basically audio RSS. Whereas before you could happily subscribe to a feed and read it at your leisure, skip the boring parts, scroll down to the conclusion, or simply copy and paste the useful bits elsewhere, the format does work."

This can be true and you do have to listen to most of the podcast. They are also quite a few rubbish podcasts out there but there are also lots of crap blogs.

The reason why I like podcasts are

1. You can listen to it whilst working and doing something
I can put on a podcast at work and do some coding. You can't really do this with RSS feeds or articles because you have to stop to read them.

2. You can listen to podcasts in the car or walking the dog etc
I often find myself totally angered to bile blog proportions to radio stations in the morning. Why for the love of God don't the bloody presenters just play some records and stop talking shit. I find it quite interesting listening to a Java podcast whilst driving to work, especially when you are driving the same way to work every day, it's easy to listen to a podcast.

3. Better Explanations some times
Some times in a podcast people talking describe something in more detail or in a number of different ways, which can help understand it. It is also interesting if people are discussing something technical because the different points and arguments can help me to understand the point one of them is trying to make.

4. Interviews are better in podcasts
It's interesting sometimes having one of the big influential developers (Gosling, Bloch etc) being interviewed but I don't find these interviews very interesting to read because it's boring to read people just talking normally, I don't find reading conversations very interesting. Listening to conversations on the other hand I don't mind to much. I'm not really sure why but they just seem to flow better.

5. Podcasts can be funnier
you can put jokes, gags and impressions into podcasts which can give it a lighter feel than a blog. Although you can put a lot of those into a blog I suppose and Visual. I dunno we can call that a draw.

6. You can hear what the famous developers sound like
It's good to hear that these famous developers you have read about so much actually sound like geeks, it helps give you a sense of balance in the universe. They might be able to write shit hot code but they are still a geek, which hopefully means I should score with more chicks :-)

I know there are lots of pro's and con's with podcasts and everything else but I thought I would blog about why I like them

Doesn't not compile - What happens when people only check in half their code

I had a very frustrating day at work today. Someone had only checked in half his code so I couldn't compile. It is really annoying because I was in two minds do I try and fudge the code I have got out so that it compiles and work or wait for them to check the rest in. In the end I half fudged it but then the code wasn't working, was it something I had done or was there a problem put in by someone else. In the end I decided to keep cursing them every half hour, I have to admit it did help quite a lot.

I'm not really sure what the policy should be because I think it is good that you check code in, so if your computer melted you know that the code would safely tucked away in source control but I don't think you should check in half the code so anyone who gets out the latest code can't compile the damn thing. I felt it was a bit of a poor show, it just gave me an unnessary headache.

In fact I think this is probably the reason why people have nightly builds to stop this kind of thing happening and to catch any bugs that your "enhancements" or code might have put in, side effect styleee.

You also don't want to get so you become a code hoarder, I have discussed why code hoarding is bad before

To cap this off even now we have most of the code checked in, now other parts of it don't work and I'm stuck wading around in the code to find out what is going on. I had a completely un productive day just treading water and going no where. By around 3pm I was beaten and didn't have the stomach to fight the code any longer and had to work on something. I hope to go in tomorrow with renewed vigour and give the code a right thrashing until it gives in and starts working.

Why you should use coding conventions

I have been arguing with my fellow programmer today about coding conventions.  The argument is based around the placing of the curly bracket he likes to do it like this

 

if (boolean statement)

{

    //do something

}

else

{

    //do something else

}

 

and I am now (I had to be made to do it to start with ) do it like this

 

if (boolean statement) {

    //do something

} else {

    //do something else

}

 

 

I think the curly brace argument is one that rages all over the uk, now I used to put the curly braces in the style of the first example because it's easier to see them match up but then our development team call a meeting and we had to choose one way or another but all stick to the same method.  We decided to go with what ever convention Sun recommended in their coding standards document  http://java.sun.com/docs/codeconv/ 

 

The real reason why I am making so much fuss about this is because when ever I have to read his code it looks different than compared to mine and means that the style of the code changes dramatically from class to class.  The reason I want to stick to a coding standard is so all the code looks the same and I can then just worry about what the code is doing rather than where the braces are.  I also thinks it's important to be coding to industry standards because if you change job then it's more than likely the new company will be writing code to the industry coding standards, so you might as well get in the habit now, the longer you leave it the harder it will be to change.  If you really want to stick to the standard I would recommend using checkstyle to help warn/nag you to change the code to fit the standards. 

 

Sun says code conventions are important because

 

 

• 80% of the lifetime cost of a piece of software goes to maintenance.

• Hardly any software is maintained for its whole life by the original author.

• Code conventions improve the readability of the software, allowing engineers to

understand new code more quickly and thoroughly.

• If you ship your source code as a product, you need to make sure it is as well packaged

and clean as any other product you create.

a more important point about all using the same curly bracket convention is that it means when I look at the code I won't have to go through it putting the brackets in the right place, whilst my fellow programmer is putting them all back the other way in an evil catch 22 situation.