Can you spot a good programmer from 50 paces?

My parents often struggle to grasp the idea of me being a programmer, they are always asking

"what is it you actually do"

My Mum sort of understands but my Dad cannot understand that the work I do cannot ever be held/seen physically. My parents do often look for the work Java, knowing that I use this witchcraft in my daily job.

So it was with interest that my Mum sent me the article by cutting it out of the paper and then posting it to me, which in my book means that she has failed the programmer test before she has even taken it.

How can I tell if I'll be any good as a programmer?

The article links to a study that claims it can tell who is going to be a good programmer or not by using just three lines of code or as the study says

"programming sheep from non-programming goats"

Using his 3 lines code his results show that 44% of people who can programs, 39% who can't and 8% who didn't answer.

The actual study is 21 pages long and was done by Saeed Dehnadi and Richard Bornat at Middlesex University's school of computing and can be found here

http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf

and although interesting it's not that interesting or to word it better I'm not that interested. So what are the 3 lines of code that can sort it all out.

a = 10;
b = 20;

a = b;

I can't really understand how this can split the people so efficently. The are about 10 different answers so it's not just chance or selection (ish).

Whether it means you are a good programmer on the other hand is a different question because the people he was testing where doing a computer course and he got them to do this test at the start of the course and then saw what results they got. I'm sure there are people who failed this course but could still turn out to be good programmers.

The question of what is a good programmer, now that would be interesting study? Well as long as the answer wasn't some kind of crazy formula.

Whizlabs SCJP 5.0 Preparation Kit

I have been trying to do more question practice recently and put my SCJP Java 5 knowledge to the test (literally)

I'm sure a lot of you who have searched for SCJP 5 resources would have come across the whizlabs. The free demo is a mixture of being useful but limited. You get 20 exam type questions with detailed answers (if you get them wrong) you also get 15 or so quiz questions which are mixture of true/false or typing in answers. For free y ou can't complain about the price or what you get. I don't know if I would want to be $60 for the full version although you get a 6 exams worth of questions.

It would probably be worth it if there were a few of you doing it. The free demo is really good practice for the real exam because the questions are fairly tricky and I reckon they must be pretty close to the real thing.

here's the link if you want to try it out

http://www.whizlabs.com/scjp/scjp-5.0-details.html

if anyone has any other good resources for the Java 5 SCJP exam please, please, please leave them in the comments and I will check them out

I have also created another blog for myself, a non technical/java blog. The blog witters on about music, dvd's and books and it has a

Hoskinators Voyage into the Center of Culterverse

I'm pretty pleased with the title, I think it words exactly what the blog is about. I claimed the blog in Technorati, claiming it makes it sound like I had to rush to claim it first, it brings up a mental image of hordes (yes hordes) rushing full speed on their keyboards trying to claim the blog first. Where as the reality of course couldn't be further from the truth.

I like the interesting (some may disagree) static thingy, which shows you the blogs ranks, this is the current rank

Rank: 1,669,958 (0 links from 0 sites)

so from this I am assuming their are almost 1.7 million blogs on Technorati which is pretty impressive when you think about it. I wonder in the future if any blogs will become sacred and protected, I will state here I'm not really thinking about mine in this sense but some other blogs. Will they be deemed that they have such useful information on that they shouldn't be deleted like a listed building can't be knocked down.

Anyway if you are bored and fancy a look at the other side of me go and have a look. There isn't that much on their at the moment but I think I will try and put one or two entries a week on. I have mainly created it to put some non technical stuff on their, have more of a laugh, talk even more shit etc etc waffle on, blah blah.

http://hoskysvoyage.blogspot.com/

I never expected this day to come

An interesting turn of events has happen to me. My girlfriend who is baffled about "blogging" and who often tells her mates whislt on the phone that her boyfriend is "writing on his little nerdy blog". Well she is at the same stage of her internet evolution e.g. she has a hotmail account, goggles things, buys stuff of Amazon etc.

My Mother on the other hand has branched out, not only has she left a comment or two on my blog but has started up a blog of her own, called

http://old-gits-wife.blogspot.com/

she was discussing today what she should put in the blog. Initially she was going to put humorous comments and a sort of diary of her everyday life. I think she has changed her mind slightly. My Mother said that after reading a few other blogs she found blogs that just talked about their life bloody boring. So she is going to break it up a bit with some facts. She might include some data about the weather temperature because she has got into a habit of checking the temperature all round the world and bringing it up into conversation. This has it's benefits because it means I don't have to look, the disadvantages are that it can be a tad boring sometimes but then again us Brits do like to talk about the weather, although I did think it was traditionally our own weather.

So there you go, what is the world coming to when your mum is blogging as well. I suppose in the future whole families will have blogs. Soon I imagine we will hear around the dinner table, Mum tell her she keeps blogging nasty things about it.

Anyway I thought I would give my Mum's blog a bit of advertising and give her a link on my blog and it's not to bad.

What functionality would you add in if you were in charge

Me and a buddy were down the pub this week talking about software products and what we would do. We were discussing what we thought about the current position of certain software products and the fantastic drunken question of what you would do if you were in charge.It's a good question, a big question but a good one. The first part of the question is what do you think of a product at the moment, compared to it's competitors and also how will it compare to future competitors hiding just over the hill.

I think the products themselves in corporate selling are really the most important part anyway. The most valuable asset customers buy is the expertise of the company, the comforting safety net that they can raise any problems to and which they have to sort out. There is also the advice, work and knowledge of the company and in these aspects I think we are very good.

An interesting point is would it actually matter if I had any idea's to improve the product, not really I would get paid the same anyway, so I could sit quietly at my desk and do the work I have been given and don't worry about thinking of ways to improve this or that part of the product/way we do things.

but.....

where would be the fun in that, finding new processes and adding new bits of code is where all the fun is. I would also say that a lot of these things you can take to other jobs because you are learning and learning new hopefully better ways of completing common tasks.

The one thing I would be critical off but this is only my opinion and I'm sure every thinks differently but I think there in software it's critical that you develop the software and focus on the most valuable thing to add into the software.

The creating passionate users recent blog is about Ignore the competition and you shouldn't just put functionality in because you competitors have added it. I think this is a very good point because the time you waste putting in that piece of functionality is at the expense of some other piece of functionality and I think you should think long and hard about what you are going to add because in most areas of software you will have a competitor adding in new functionality all the time and if they choose more useful functionality than you then the your software will be slipping behind.

The worrying thing is, in software you might not have long before someone like google will release a free version of your software, so get adding the USP's in pronto.

polymorphic podcast - OO podcasting

I found a good resource for Object Orientated information and some of it is in podcast style. I am quite fond of podcasts, I often put them on when I am in the car and have almost been driven insane by the morning DJ who constantly talks about himself, man those guys are annoying.

I also like listening to a podcast when food shopping, I slowly plod about whilst my girlfriend scoots about looking at all sorts of stuff she isn't going to buy. I sometimes have the podcast on at work but I find that I get engrossed with what I am doing and then somehow don't hear the podcast.

if you are interested as to why I like podcasts I blogged about it before here

Also here is a blog about the podcasts I like to listen to here

I found this resource before but lost it again so I was happy to have found it again and thought I better blog about it again so if I need to find it I can just search my blog. I sometimes use my blog as a bit of resource/brain dump

here is the link to the site called polymorphic podcast

http://polymorphicpodcast.com/

it has some very tasty looking topics, the only downfall is that it's for .net but I think some of the topics are broad enough to be useful to Java developers as well. Here are some of the more interesting topics that they podcast about. Also it sometimes useful to here from developers from different languages because they some times do things differently.

Tips on Developing Yourself as a Programmer More O/R Mapping

Separating Presentational Code in Web Apps

Unit Testing and Test Driven Development

Practical Unit Testing Part 1

Ajax & URL Rewriting

Building a Professional Resource Library

Writing "Real" Production Code : Interview with Kent Alstad - Part 1

Interview with Carl Franklin Part 2 : The Importance of Object Oriented Development

What is a Good User Experience?

Object Thinking - Interview with Dr. David West

SCJP 5 - Constructor revision sheet

As I was reading my Java SCJP book tonight, it kept mentioning things that I should definitely learn and read a few times. I often find that writing things down helps me to memorize bits of information so I was going to write down some of the more important points which I didn't already know. Then I thought I might as well do a blog entry on it, then not only would I benefit but I would also know where to retrieve the information again and it might help other people studying who stumble onto my blog.

I also thought that if I blog about something that will be on the exam I will be still learning stuff for my exam rather than just blogging about something interesting. This way I will be learning stuff for my exam and blogging.

It might not be that interesting to readers of my blog who aren't studying for the SCJP Java 5 exam or those who have already done the exam but I'm sure there will be a few facts here that you will have forgotten so give it a read.

I was reading about Constructors this evening, now this is a fairly straight forward topic or so I thought because there are quite a few tricky little rules, which I certainly raised an eye brow to a few of them.

The information below isn't a comprehensive guide on Constuctors but it's a sort of cheat sheet of the more tricky or must know stuff about Constructors. In my mind it's a sort of cheat sheet of quick facts about constructors, random facts for some quick revision.

Constructors

1. Key points about constructors.
- They have no return type

- Their names must exactly match the class name (yes it is case sensitive)

2. Every class, including Abstract classes must have a constructor but you don't always have to type one, if you don't type any constructor then the JVM will automatically give you a no arg's constructor.

3. Constructors can use any access modifier which includes private.

4. You can have methods with the same name as a constructor. It is legal to have a method the same name as the class and the constructor

5. If you don't type in a constructor the compiler will automatically add one in for you, this will always be a no argument constructor.

6. If you have typed in a constructor the compiler will NOT add in the default no arg constructor, so don't try and call it.

7. Every constructors first line of code is either super() or this(). If this isn't the first line of code the compiler will automatically add this in

8. One of the constructors will always call the super class constructor (e.g. super()) if you call another constructor in the class then the super() will be prosponed until it go's into constructor that doesn't call another constructor.

9. You cannot call any non static variables/methods until after the super() constructor has run. You can use static variables/methods before this.

10. Interfaces do not have constructors

11. You can only invoke a constructor from inside another constructor

12. Abstract class constructors are called when the concrete subclass is initialized

13. The default constructor includes a no-arg call to the super constructor

14. Constructors are never inherited

15. Constructor cannot be overwritten but they are often overloaded.

The Constructor Exam gotcha's

Constructors cannot have return types, so if you see one with void, int, String etc, it isn't a constructor it's just a method. This is often used with tricky overwriting questions. They can be sneakily name the same

Constructors MUST be the same name as the class. They are also case sensitive so watch out.

If you have typed in a constructor the compiler will NOT add in the default no arg constructor, so don't try and call it. This is a sneaky exam trick, they show you a class with a compiler that has a constructor that takes some arguments and then they call a no arg constructor, bang error.

You can only invoke a constructor from inside another constructor. If you see any method calling a constructor you know it won't work.

The default constructor includes a no-arg call to the super constructor, this might be cause a problem if the super class doesn't have a no arg constructor, which means you will have to change this and add your own super constructor with parameters. So if you superclass doesn't have a no-arg constructor you cannot use the default constructor added by the compiler

Learning UML diagrams and how to use them

I set out to "learn" uml late last year. It was one of those things that when you see someone create a uml diagram you think, hey cool, that looks really good. sets out what is going on in the class and the dependencies between each class etc. A fellow developer often use to draw some class diagrams and if you don't draw any uml diagrams they seem quite impressive and you have an opinion that the other developer is very professional. What you don't realise when UML diagrams are hazy dark art (you don't know them) is that they aren't really that difficult and they are basically just your notes and design doodles put into a standard format, especially the class diagrams. Uml diagrams to me are just way for everyone to doodle and design their code in the same way, so when you show you developer buddy he will understand what everything is.

I was also reading about design patterns at the time so I found that it helped me to learn uml because when explaining a design pattern a class diagram is a very useful visual aid.

It can be a bit overwhelming to start with because their are so many different diagrams but you probably won't need to learn all of them. What you can do is learn them well enough to read them so if anyone does show you a uml diagram you don't write or use yourself then at least you will be able to understand.

I basically only learnt the class, sequence and use case diagrams and really only learn those three because they were the ones I thought would be most useful. I would say that I do have a piece of software to draw these diagrams but I often find it easier and quicker to draw a diagram on paper, especially the first few drafts because you can quickly find that a design idea has a major flaw. I see it sometimes as similar to writing a unit test before you start programming because you design the class to do something and then you realise it has to do something else, this can then cause problems for your initial design. The most important result that comes out of doing a class diagram is that you have thought about the design and looked into the problem in a bit more depth. I find design idea slowly start to grow and then I do a quick class diagram and then slowly bits of it change.

The downside of not using some software to draw a uml diagram is that it isn't going to hang around after you have finished the project. It would be a useful aid to someone who then had to do some work on the project. Whether the diagram is quickly sketched or done using software depends often how big the project is and importantly how long I have got to do it.

class diagrams

I use class diagrams to try and work out the design of program and see what kind of dependencies the classes have. The main benefit of this I find is that by spending a bit of time roughly doing a class diagram then you can see the strengths and weaknesses of your design idea, which often completely different when written on paper. The visual aid of a class diagram is very useful, it offers a more holistic view of the code I am trying to write, it also makes it easy to explain to other developers what you are trying to do.

I often use Class diagrams as a rough plans jotted on a scrap piece of paper, I am never worried about sticking religiously to the class diagram because design evolves. The greatest benefit of drawing a Class diagram is the learning process you have done through to create it, all the ideas that didn't work help to fortify the idea that works, similar in many ways to writing some code, you learn about the nitty gritty of the problem and what parts are needed and what bits you can chop out.

Sequence diagrams

I like sequence diagrams to help show me the sequence (err yeah). If I have written some code for a customer then showing them a sequence diagrams is an easy way for them to understand how the program works from a user point of view but without having to explain any of the code.

Use case

I have to be honest I don't use these diagrams very often. Thinking about it now I would say it's probably because the work I do tends to be smaller scope and the customers want a web application so I don't really have to worry to much about gathering information about their processes and what information is being recorded here and there. Plus I don't really like them or find them that useful.


So what prompted me to blog about Uml diagrams. Well I have a found a good resource of information today about UML diagrams. I looked at the time and there are certain links to free UML resources but they tend to vary in quality. This link is fairly comprehensive but without going over the top, it's not a 30 page chapter on each diagram, it has enough information to quickly describe the major UML diagrams but not to bog you down. I think that when you are initially learning something, it's always good to have the end of the chapter in sight, especially if the subject is a bit confusing and hard going. Here is the link

http://www.agilemodeling.com/essays/umlDiagrams.htm

What I like about this resource most, is the layout and the fact he (Scott W. Ambler) has put a learning priority on each of the UML diagrams, so you can learn them in order of how likely they are to be used. So if like me you lose your enthusiasm you will have least learnt the more important/used diagrams. I think I am going to have a read of the medium priority uml diagrams just to get an idea what is involved and to see if they might be useful. Uml diagrams suffer from one of the classic learning difficulties. When you read them they seem easy and straight forward and the examples they use are easy to follow but then as soon as you get to using the technique on your code it call becomes very difficult. Some times there is only one cure to this, practise.

Why you should check method parameters for validity

I was reading one tip from Effective Java today, item 23 check method parameters for validity. It was talking about why you should check method parameters for validity. This is often something which you can forget about because you are usually using the class and method yourself and when testing the code you pass in a correct value. Perhaps if you are unit testing you pass in some unusual values, given some confidence that you method has passed the other expected value tests.

This is a classic Effective Java tip, very simple but yet very .... yes I can't resist it Effective.

Implementing this tip and checking methods parameters for validity would help to eradicate one of the classic programmer/developer blind spots and probably the main reason for QA teams. Before you get angry with my preaching, I too have been guilty of this. When developers test their own code they often get into a kind of groove and only pass in a few different valued variables. They usually test something some many times they keep putting in the same value over and over until the code finally passes this test.

If we were writing a (as it's a boiling heat wave in Birmingham) method which converts Fahrenheit to degrees then the developer would pass in a few number 21, 10, 90 and usually write some code with just one of those value say 50 and keep testing the code with this until it works. After that a few different positive numbers, bingo the method is tested, give it the rubber stamp. The example I am using is without unit test code which was the way I used to work (before I had an epiphany and saw the light ).

Without checking for validity you are underestimating the sheer stupidness of the users. There is obviously the argument that you make your code idiot proof they will go and create an even greater idiot but we will leave that. Users love doing stupid things, sometimes to see if they can break it !!!!! It would be long before a user/customer would put in a negative number or perhaps even 1 million (dollars MWHAHHAA - doctor evil laugh) and then they would complain it wasn't working.

Of course the real nightmare scenario is that you would put in a dodgy/invalid value but this would only show up as an error ten classes down the road, leaving you with a puzzling bug hunt and some slow debugging back up to the method that has caused the error.

By checking the methods parameters for validity you can throw up an error as soon as possible so as to stop any more code running when you know it wouldn't work with the values passed in.
It also makes sense to test for validity inside the method because it keeps the logic all in one place and can be then the validity checking code is not repeated by all the classes that use this method, keeping your code nice and DRY (Don't Repeat Yourself).

Usually you can test for values being positive, not null, certain values and then use the @throw tag to document the restrictions to this method. Popular exceptions to throw are illegalArguementException, NullPointerException and indexOutOfBounds, this exceptions tend to do exactly what they say on the tin and anyone using your class will know what to expect.

There are some occasions that you can't check for validity but most cases you can probably validate the parameters passed in and this small amount of work will hopefully stop any bugs occurring inside or from using the method. I have found that I have been validating the parameters more now that I have been writing more unit tests. When I am writing a unit test I think more about the restrictions I should place on the parameters values

Why Interfaces are better than Abstract classes

I have recently begun to understand where a lot of the books/articles/blogs I have read recommend Java programmers to use Interfaces and composition and this has come about because recently I have been using a interfaces a lot more. I noticed this has been a definitive change because before I used to always think of using Abstract classes.

I think as you progress as a developer you move away from using inheritance and then start to favour composition. I think the key area of this change is you start to understand the benefit of interfaces and abstract classes and through practice you get better and using them.

I initially could never understand the point of interfaces, the idea of them seemed like extra work. You have to create an interface which has no code in, except some empty methods. I used to think why would I want to do that when I can create an Abstract class with some methods which have code and then all the classes can extend that and get some code for free. This would mean I have to write less code. Interfaces use to seem like a terrible idea, every class that implements it has to write all the code again for each class that implements an interface.

I have discussed before Interfaces Vs Abstract Classes I have also blogged about why you should use interfaces and abstract classes, I didn't really write that much but I linked to a good article http://hoskinator.blogspot.com/2006/05/interfaces-and-abstract-classes-dont.html

I have moved away from using abstract classes as much because I am using interfaces more and the way I am using Interfaces more. Recently I have been using Interfaces to hide change behind. If there is a piece of code which has an algorithm or recently I was writing some code which checked a directory for a file. I was able to use an Interface and check for a certain file. The interface I created had two methods, one method to check the directory and one to perform an action if it found something. By using an interface I was able to write the code to resolve the problem I was trying to fix but also hide the change behind the interface. If later I need to search for a different file or search for files I can make another class that implements the interface and change the method to check the directory and the action and the rest of the code will work just fine. Here is the blog entry if you would like to read about it in more detail

http://hoskinator.blogspot.com/2006/06/function-pointers-in-java.html

I think the change from using Interfaces from Abstract is the change in thought. I have been thinking about trying to write simple code and nothing extra but also where change might come in the future. If I think the code might change, I bash a interface in allowed a developer in the future to add a different implementation behind the interface but without effecting other parts of the code.

I suppose what I am trying to say is that Interfaces allow you to use polymorphism and benefits that associated with it.

What other benefits are there, well I think interfaces encourage Single_responsibility_principle
in your code because you can make interfaces for smaller tasks. When you use abstract classes they often start off this way but then as you extend them with different flavours the classes seem to start growing and sometimes you need to alter the super class and slowly the code seems get harder to maintain and extend. I think abstract classes and the concrete classes which inherit from them do become more difficult to maintain is the different extending classes start to change the focus of the class and they become less cohesive.

One other weakness I find with inheritance and abstract classes is that any methods you want to overridden or to be able to use you have to make public. Although there is no reason why you don't use the extended class with composition but for some reason I don't. With inheritance and the blog about function pointers I pass in the interface. I like this use of interfaces as instance variable, this is where interfaces are really powerful and useful you can use them as a set of behaviors inside a class. The real advantage is classes using the class which contains the interface rather implements it, don't even know there is a interface being used.

Another weakness of Abstract classes is that you can extend any other classes.

Increased dependency. Abstract classes by their very nature create a fundamental dependency with the subclass and the superclass.

Interfaces seem more comfortable when making an interface with just one or two methods. It seems easier to create a small interface and the interfaces I write seem to be a lot more cohesive and focused on one particular task/behavior. The Benefit of small concrete classes is they are not coupled with other code and have few dependencies. This means it's easier to use the concrete class implementing the interface in other parts of the code.

There are situations when Abstract classes are useful and the right choice, they do have advantages that each class can inherit some general methods used by all extended classes. It's just in my experience recently Abstract classes seem a lot harder to maintain and extend, especially with the more classes that extend the Abstract superclass.

I don't know what other people think about this but it seems to me that after starting off using Abstract classes you get a bit more savvy and then start to use Interfaces a bit more and composition. Interfaces seem to make it easier to write code that cohesive and focused on one thing, this has the result of making the code easier to extend, maintain and unit test before another class implements the interface or uses it like an instance variable

Deadline helps motivation SCJP Java 5 Exam Studying

I have been studying for my SCJP Java 5 exam for about 5/6 months but I am still a bit scared of taking the exam.

The thing is I just don't want to fail the beast. I think I probably have learnt the stuff for the exam, well I have learnt it well enough to pass I think.

I read the whole of the Sun Certified Programmer for Java 5: Study Guide Exam 310-055 (Certification Press S.)

and blogged about it here, a couple of months ago

http://hoskinator.blogspot.com/2006/05/at-last-i-have-finished-reading-all.html

since then I have been taking 10 practice questions most working mornings (mon - fri) and going over my que cards/notes.

It's a bit odd the SCJP 5 exam, its something I feel you can never be too prepared for. I have made a bit of a mistake but taking my foot off the gas quite a bit the last month or so ( I have been buying a house which took my mind and time away) but in all honesty it's a bit of an excuse, I'm just putting it off.

After reading the book and reading plenty of articles and now answering lots of questions, if you want to see the questions read this blog entry

http://hoskinator.blogspot.com/2006/04/java-5-310-055-practise-exam.html

I have also gone onto Java Black belt and tested myself on their questions although they can be a bit oddly laid out, which might be good practice for the exam.

My knowledge of the basics of Java and the new features has gone up loads and I basically think I just need one more big push of revising to be ready.

To encourage this I am going to set myself a deadline of 4 or 6 weeks and give myself a date and stick to it. Deadlines are great mind focusers, it gives you a target and should hopefully stop all this fluffy wimpy putting off the exam nonsense that has taken hold of me. So I am going to pick a date in August and put this exam to sleep.

The last thing that motivated me was I better do it soon or other wise I will have to change and study for the Java 6 SCJP exam.

Are You Interested in writing a Head First book?

The authors at Head First team are looking for more authors to write in the Head First style.

here is a link to what they want

http://headfirstlabs.com/writeforus.php

what is the Head First style. This is how they describe it

"Head First requires a sense of narrative and pacing, a pinch of humor and a dash of hipness."

I have read two of the books and the description above is very true. They focus on making dry academic subjects into amusing stories but still has the important facts and learning in place.

I found it slightly surprising that they want you to also design the layout of the pages with pictures and placement of text. I suppose you would get into the swing of it. Another thing which I found quite shocking is that they would like there books written in 6-9 months, which sounds a bit like hard work but if you have a deadline then you get it done to the deadline.

If you are interested you have to pass an audition, which the details are here

http://headfirstlabs.com/Audition/audition.pdf

good luck to anyone who enters and I hope you are accepted because I love the head first books and hopefully I will be reading a new one in about 9 months time.

Where do you put the class creating code?

I don't know what you call it but I had an interesting programming dilema

I was writing some code which read in a text file and in this file it had six sets of data, with a name, date and then an int array. I decided to create a POJO (plain old java object) to hold the data.

The next question I had was where to put the code that split up the data. I had got it to a point where I had read in the file and put it into a String, then Tokenized the string into an array of strings, each block had the data to create the data bean.

I had created a DataBeanFactory in case I need to do something like this in the future but I was wondering if I should put the code which takes a String object and converts it into the correct variables either

1. In the DataBeanFactory
2. Or in the DataBean

Did I want to keep the DataBean purely as a data object and don't add in any creation code. I was thinking about the coding advice

"only give an object one reason to change"

Also Reusablability comes into play, if I were to put creation code in the DataBean it might reduce it reusability because it was totally dependent on getting this one set of data.

The other side of argument I felt was where better to put the creation of the DataBean but inside of the DataBean thus allowing the object to know how to create itself. It would also reduce dependency and coupling for the DataBean which I suppose would make it more reusable. It would allow the DataBeanFactory to just concentrate on working out which DataBean people want created.

In the end I put the code inside of the DataBean as it seemed the neatest place for it. Putting it inside the Factory class would have made it too messy. It struck me that there wasn't any guidelines on such things or I will correct myself any guidelines or articles that I have read. I suppose this is because you have to weigh up the setting of the bean etc and how you are going to initialize it, some times you might slowly fill up a POJO other times it might be in the constructor.

I wonder if anyone had any rules on the subject, when should you put self creating code inside a DataBean.

3 long days on site and unfinished business

I have been out on site for 3 days and it certainly was 3 long days.

It can be tricky when you are out on a clients site, I tend to feel I have to justify all of my actions. In reality the customers probably really don't care how I do what ever it is I have to do as long as it gets done.

I am always conscious of trying to pass on the knowledge in a

"Give a man a fish, he can feed his family for a day day, teach him how to fish and he can feed his family forever"

Although I try to show the user what I'm doing, it's not just because I am lazy and hope they will be able to do it for themselves next time. This of course can have it's draw backs as well because "with great power comes great responsibility" and the power to create an even trickier bug. I have seen customers really bend the rules of the software we have supplied them but the same users also did a lot of the donkey work in narrowing the bugs down for you as well.

I think it's important not to just show the customer/user what you are doing but why you are doing it, the hardest part of using other peoples software is working out how all the pieces fit together.

Back to the story. I was out on site trying to upgrade their software, well upgrade everything, version of java, version of Tomcat and all the software that we supply. I managed to get into a right pickle. The installation of the software went fine, the configuring of my employers software went horribley, problem after problem. Usually I try and keep to keep a slow methodical systematic approach and tick off what isn't causing the bug as well as things that our. I think in the end I suffered a bit of from computer sickness and couldn't really see the "woods from the tree's" I had been working at it for so long.

I had a lot of errors and the error messages I were getting were real red herrings. In the end I had to roll back to the numerous backups I made. Funnily enough just as I was packing up the solution struck me but I didn't have quite enough time to try out my solution, so first thing tomorrow I have some un finished business to sort out. This problem is certainly person now and I am determined to slaughter the beast. It was an infamous missing jar problem, I had two system - the old working version and the new not working version.

To make things a bit more interesting I was working on a Linux machine. I am pretty rubbish with Linux and all the command line typing. The worst bit is trying to remember the directory structure in my head. This time I found that Linux has got an GUI front end called Konquer. It was well cool, I could see directories, edit files (when I had the right user). I struggled copying and pasting values for some reason and had no idea how to start and stop Tomcat but found that dragging the bat files onto a command line type screen did the trick.

Three days of wearing a shirt and tie has taken it's toll on me, no more neck stranglers for a while.

even though I have spent 3 days on the problem, I am now feeling eager to finish the job, the plan is go into work, try my solution and then get on the phone to tell the customer what to do

What is Defensive Copying

I was wondering what to blog about and then I saw the term defensive copying. I have heard this term mentioned a few times but wasn't sure quite what it was. So I thought it was time for a bit of investigation.

So what is defensive copying, also sometime known as object copy.

Defensive copying is concerned with protecting mutable objects e.g. objects who's state can be modified by the user. If you were pass back the reference of an object any changes a user made to that copy of the object would effect your object because you are only passes a reference to the object and not the actual object itself. This is known as a shallow copy.

To avoid users being able to change the values of your object you can pass back a defensive copy. This means that instead of passing back a reference to your object it passes back a new object but with the same values. This means that any changes the user makes to that copy of the object doesn't change the value/state of your object.

It's an interesting idea but I can't think of a use for this at the moment but I'm sure one day this will come in useful.

Here are a couple of links to some probably better explanations with an example

http://www.javapractices.com/Topic15.cjp

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

The first site Java practices has lots of useful articles and well worth checking out

The Benefits of Test Driven Development

I read these articles about Test Driven Development, This first article is quite short but very succinct and explains the process very simply, which I suppose it is, This is how the article breaks down TDD (Test Driven Development), the article is reviewing a book but does also go through some of the basic tenants of TDD in an easy to understand way

http://www.ddj.com/showArticle.jhtml;jsessionid=4ZJIVDR5CAOCGQSNDLPSKHSCJUNN2JVN?articleID=184416004

1. Red: Write the minimal test code to break your implementation.

2. Green: Write the minimal implementation to pass your tests.

3. Refactor: Clean up any code duplication introduced by the above.

I also found this link to an introductory article on TDD development

http://www.agiledata.org/essays/tdd.html

I have used this system of programming a few times and it certainly has a few advantages. I won't list the advantages here because you can get those by reading one of the two good introductory articles on the process. What I will do is write how I found the process when I used it.

My first point is this is the easiest way to write unit tests or should I say the most painless way to write unit tests for your code.

Writing unit tests is a bit like writing java docs in terms of "things I don't like doing but have to be done". If you are going to write a unit test you have to do it before you write the code, other wise writing the unit test is a real slog of pointlessness. If you write the unit test after you have written the code then you have probably already tested the code using system out's or stepping through the code and seeing what it returns.

The benefits of writing the tests before the code is that you first think about what you are testing, e.g. what should this piece of code being doing. The article states that

"small steps, test first, clean as you go"

This is one of the key points, you write a test and then write some code to pass that test. Then you write another test and get the code to pass that. I have jumped ahead of myself a little bit here, you initially start writing with a failed test. This unusual process often is confuses and annoys people who don't like writing unit tests. The reason for this in my opinion is just to make sure you testing the correct class, you are confirming that this is the code you are going to be testing by putting in some stub code which does nothing and fails the test. Then you write some code to just pass the test you are running,

Although it sounds sad but when you get the green bar and the test passes you do actually feel like you have accomplished something, it's a small win but a win none the less. It is for want of a better word - Progress. Each time your code passes a test you feel like you can see the code improving, gaining functionality.

The benefits of Test Driven Development from my experience are

You write only the code needed to pass the tests and don't waste time writing functionality which isn't used

You write code which is easier to test, which tends to be more modular with low coupling, this code will be easier to reuse in other parts of the software.

The unit tests can be run at any time to test the code is still working

The unit tests can be read by other developers and will help them understand what the code is trying to do

Any refactoring of the code can be run against the tests to make sure it is still working

You have confidence in the code because you know it passes all those tests and works


I don't know if this is really a benefit but once you have tests that you can keep running over and over you can change the code safe in the knowledge that any changes will have to pass the tests you have written. The allows an emergent style of development. I think it is easier to write code, get it to work and then look at the code and see where you can improve it. In the act of writing code to pass certain tests you learn more about what you need to resolve the problem and then you can refine and refactor the solution you have created but with the safety net of the new code having to pass your unit test.

You also benefit from a short iterative steps so if you try something that doesn't work then you haven't lost to much time.

I don't know now if this blog entry is about TDD or just talking about the benefits of unit testing but my advice is too give it ago. I often hear people say they haven't got time to write unit tests but you have to test the code you write anyway but if you do it with system out's or comments you are just testing your code in a none reusable way. I am often surprised by the amount of daft silly bugs I find in my unit tests but when you are just testing a small piece of functionality the mistake is easy to find but if you were testing it at a higher level it might take you a long time to track down the problem.

One of the best reasons I have read to justify why you should write unit tests is

"you know how long it takes to write a unit tests, how long does it take to debug the same piece of code"

by writing a unit tests you are trying to guarantee you won't need to debug that code and if you did need to then you can use the unit test to take away a lot of the possible problems that could occur.

I have written a couple of blog entries on unit testing before if you are interested, they are worth looking at because they will have some links to some more resources like most of my blog entries.

why I like unit testing
http://hoskinator.blogspot.com/2006/04/learning-to-love-junit-and-test-driven.html

about trying to persuade by fellow developer to unit test
http://hoskinator.blogspot.com/2006/05/how-to-persuade-java-developers-to.html

a good link to a journal with some TDD articles
http://hoskinator.blogspot.com/2006/04/test-driven-development-and.html

Blog Copyists do not prosper

I while ago I read a blog complaining that a blog copied other people's blog entries and not changed some of the words and written practically the same thing but this blog had literally copied complete blog entries. The discussion was on a Joel on Software forum

http://discuss.joelonsoftware.com/default.asp?joel.3.354719.75

I was a bit shocked because I saw my blog was mentioned and was saying that a blog entry on my blog was a copy

http://elsinga.wordpress.com/2006/06/06/a-tip-on-writing-software-documentation/

compared to:

http://www.jroller.com/page/hoskinator?entry=a_tip_on_writing_software

when I read it initially I was shocked, so shocked that I didn't read it properly and thought someone was accussing me of copying. I was writing a comment then I read it again, properly and found out that they were saying that the blog http://elsinga.wordpress.com was copying mine. Not only mine but many many many others.

After looking at the site in more detail I found the site had copied loads of my blog entries, just pasted them in whole and didn't even reference my site.

I'm glad to say that the site has now been taken down.

The weirdest thing about the incident is that why would someone bother to just paste other blog entries in, what did they get out of it


Anyway when you go to the page

http://elsinga.wordpress.com/

you now get this satisfying message instead of copies of other people's blogs

"This user has elected to delete their account and the content is no longer available."

Sex and Java combined to teach OO concepts

pornymorphism - porn + polymorphism

I have created a new word today, a worthy feat on a Friday. I found this article/tutorial on polymorphism titled OOP Concept explained: Polymorphism. I am always keen to read about some OO concepts.

The writer explains that textbooks can be a bit dry which makes the ideas hard to understand sometimes

"The problem with most computer science texts is the examples aren't interesting. Polymorphism isn't really hard to understand, but the examples are usually boring or difficult to understand. This is an alternative text which attempts to use a problem space that's already familiar to the college student to make the concepts of programming simple."

The way the person describes polymorphism is hilarious, here is a sample

"Let's say for example you want to fuck a hole. You f*ck all holes the same. You don't care if that hole happens to be a mouth, an ass, or a pussy, you're gonna f*ck it the same way regardless. However, the mouth, pussy, or ass may respond differently to the f*cking."

Anyway I urge you to read the article because it's brilliant mixture of sex and Java

http://www.kuro5hin.org/story/2006/3/14/175929/544

See doesn't that make learning easier and every else user sex to sell their idea's so it's about time Java followed and programming languages as whole followed.

Object Referencing gotcha's

the title of this blog entry sounds like a pussy cat dolls song (mmmmm pussy cat dolls).

I have bumped into a few cheeky gotcha's recently.

Firstly we had a problem with the wrong data appearing for different users when using our web app that served maps. It was a subtle problem that rarely occurred so it took us a while to actually catch it and then work out what was going on. I talk about it a bit in this blog entry

http://hoskinator.blogspot.com/2006/06/action-class-design-guidelines.html

I wasn't aware that Struts only creates on Action class and then uses it again and again. We had written some code with out reading design guidelines and used some instance variables with user information in. This lead to problems because this information was always being refreshed or a Struts action might be using an instance variable created by another users. The result was a confusing mix up of variables. We solved this by removing all the instance variables and passing in the objects that were needed.

Another problem I had last week was using a third party jar file. I was retrieving an array of objects, looping through them and assigning object into my new array of objects which I was going to change and then save back. To save on memory (for their code) they only used one object. The result of this was instead of copying a new instance each time in my loop, my array of loops was only pointing to instance repeatedly. So when I went on to the next feature in array retrieved from 3rd party jar it used the same instance but with a new value. I ended up with an array all pointing to the same instance and all having the same value which in this case was the last instance retrieved.

loop {
array [i] = thirdpartyArray[i];
}

What I need to do was to create a new object in the loop, something like this

loop {
array[i] = new object(thirdpartyArray[i]);
}

I wasn't sure whether there method of using the same instance whilst returning an array of objects was standard practise. The documentation said it was done this way for efficient memory usage. I don't know whether this is true either because I had to create new objects, someone has to, so maybe they saved on memory but all they did was pass it on to me. This was a fairly simple gotcha to find although it did take me about half an hour to pinpoint where my code was going wrong.

CheckStyle also complained that I shouldn't create new objects in a loop. I suppose I can see it's point because creating objects in a loop can go drastically wrong if the loop goes wrong.

my final gotcha of the day was using the final keyword. I am not totally sure what happened as it happened to a work buddy but it was something to do with the final keyword on a File class. I was opening a file and reading it in into a String and basically process it. The final keyword resulted in the File object not being garbage collected. This is a bit of flaky one to add because I am not entirely sure what happened but I think it was something to do with a File being Final and then it not being garbage collected and we couldn't then move the actual text flie because we still had it open inside our program.

The first two are probably fairly straight forward and most the people reading this are probably aghast at my buggling and the third one is something which I am not quite sure what the hell was going on. If anyone has any Object Referencing gotcha's please add a comment.

Object Orientation and Design Pattern articles

I found a good resource for Object Orientated programming and a bit of design patterns. Like all of my favourite resources it's free.

http://csis.pace.edu/~bergin/

What I liked about the articles on this site was that there seemed better than a lot of articles you read on OO and design patterns. The reason for this was because they were longer. The articles also seemed like they were written with a definite goal in mind, not only that but they were written with a start and a finish and in-between they slowly increased the new facts learnt. I found this made them easy to read and understand and you slowly learnt another idea.

If you already have a good knowledge of the Object Orientation and Design Pattern's then you will probably not find many of the links that useful but I think you will find a few.

The site is from Joseph Bergin, Ph.D. who is a Professor of Computer Science, have a look here if you want to see a picture http://csis.pace.edu/~bergin/bio.htm

I have read a few the links but still have some more to read but the sections I found most interesting were

Java, Object-Orientation, and Design Patterns -- Examples and Commentary
Elementary Patterns (Patterns Intended for Novices)
Java Related
Extreme Programming (XP)

This sections on the page have a number of links to interesting articles and well worth checking out