I finally reach 100 bucks

Ever since I read the small print and realized that having google ad's on your site doesn't really make you any money (the dream of an easy buck slowly fades away) I have been striving to reach the magical $100.

The reason 100 dollars is the magical number is because Google don't pay you a penny until you reach 100 dollars, which is a lot hard than it sounds. Well it probably isn't that hard but unfortunately it takes time to build up regular readers of my blog (thank you all) and it takes a lot of time writing the articles for the blog. As I said recently I have not only now got an extra 100 dollars but I have also learnt a lot writing articles for my blog and learnt just as much from the comments people leave to my articles, so anyone who has left a comment thanks a bundle.

I check my statistics of my blog (which I do because I'm sad) and I have been blogging since April 11th 2006. This brings me onto my next aim which is to get 100,000 page views to my blog. I am currently on 90,397 page views and 73,902 visits. To be honest I'm not really that clear on the different apart from page views is a quick view of the page but a visit if someone's stays for more than 1 second.

In theory it should get easier because I have more pages of my blog for people to look at. So anyway thanks everyone who have read my blog and special thanks to everyone who clicked on an advert.

Are The Principles of OOD out of fashion?

About a year ago or more (time flies pretty quick) I found some articles on Design Patterns and these bad boys blew me away and I have written many blogs about them but here is a more recent blog entry on Why Design Patterns are useful. I quickly looked for more information on Design Patterns because firstly they seemed to be solutions for common problems but I didn't really realize they were common problems e.g. The factory pattern, I didn't realize why it was a good idea to create about objects and assign them to an interface. Not until the factory pattern explained the problem and then the solution.

I will get back on track because I am not here to talk about Design Patterns today, I am here to talk about Principles of OOD. Sometimes I pop articles into a word document to read later and to blog about. Today I dipped into that word doc and found this fantastic article

The Principles of OOD

The reason I am talking about Design Patterns is because recently they seemed to me to have become very fashionable and everyone is talking about them, writing books about them and articles (like the one I wrote) talking about them but it doesn't seem to me that many people are talking about the principles of Object Oriented Programming, which I believe is what Design Patterns are built on. It's like OO has gone out of fashion but Principle of OO are just as important as Design Patterns because basically they give you the tools to create your own Design Patterns but you would struggle to do that without understanding Object Oriented Design.

After I read about Design Patterns it lead me backwards to trying to hunt down articles about OOD and I then read loads of the articles on the Object Mentor site which is where this article points too. It also has the craftsman articles which I just like and have blogged about before here.

It was after reading the OOD articles that I appreciated the Design Patterns even more because I could see what principles were being used in the Design Patterns. The most interesting of the principles is the

The Open Closed Principle

I keep seeing this in my code more and more. It always gives me great delight (in a very sad way) to be able to use a piece of code I have written earlier but without changing the code, just adding my changes around it. Not having to change the tested code gives me confidence that the code is more likely to work without me adding any bugs to it.

Recently I have been searching for Object Oriented books and I am finding more and more but there seemed initially quite hard to bump into (especially good ones) but then this could be my poor book searching ability.

I would like to here what you think, has Object Oriented Design gone out of fashion, is it right to have been pushed out. I often read articles which state OO principles alone will not lead to good code. I definitely think Design Patterns have managed to recently been in fashion and dare I say a bit overhyped, in some ways it is a bit of a short cut but then in other ways it is a good learning tool (amusingly for this article OOD).

Amusing IT Stories is my new funny IT blog and needs contributions from developers, please check it out and contribute.

The Ultimate Blog post

As I have been on a training course all week I haven't been doing much coding so have been trawling the internet a bit and I found this article

The Ultimate Blog post

of course the ultimate blog post would be new comedy IT blog Amusing IT Stories
which gives an amusing Friday spin on the IT and Office environment and mixed in with some rubbish paint pictures and links to other sites makes it a sure fire winner for the ultimate blog post. Okay well maybe not and shameless plug out of the way I will get on with my post.

There is one point I would like to make that sometimes I read articles about generating traffic onto your site. I find it interesting that so many people are just concerned with getting people onto their blog. It is a bit like young un's saying they want to be famous when they grow up. Not I want to be famous for being a good singer, footballer, code hero.

It seems that bloggers in particular aren't so worried about getting traffic through writing good content but just want lots of people there going there. It takes quite a long time for a blog to gain consistent readership, especially when you consider the use of aggregated blogging software and sites which you can just look at those to see what stories interest you. This of course has it's disadvantages because to find the good stories you have to scan over the many stories that don't interest you.

if you are a blogger posting to link popular link sites is a good way to get interest and traffic to your blog. It does mean you have to write almost standalone articles that will be interesting to casual browsers, rather than people who have just subscribed to your blog.

The ultimate blog article mentions the best way to get traffic onto your blog is to tell your friends about it. I have to admit that when I created my new blog this week, I certainly have emailed all my buddies the link. Although I wasn't like this to start with because I found it slightly embarrassing having your friends, familiar and work mates reading your blog, especially as mine was a technical blog. Sometimes I blog about things I am not totally sure about and often make a prat of myself only to be rescued by some excellent comments submitted by readers of the blog.

I think one of the major ways to get readers onto your blog is persistence, you have to keep writing and build up an interesting back catalogue and also people will slowly find your blog. You also probably get better at blogging and more knowledgeable on the subjects you are blogging about, I can say for certain that I have learnt loads from writing a Java blog.

The real reason I decided to blog about the articleThe Ultimate Blog post is because I was interested that the writer has created an average user for each of these popular blogs by writing the ultimate blog post for each blog.

I have to say that one of the best technical link sites is dzone. It hasn't been around a very long time but it's growth has been amazing. I think it benefits from just including technical links which has in my opinion resulted in less rubbish postings. Another good site is Digg, although the users can be quite harsh with their comments.

The value of training courses to employees

I am on a training course this week as readers of my blog will know because I have been banging on about training courses and Linux all week. I was considering the value of training. There is a basic value of learning knowledge, learning a new skill. I think there is a value of going into an external environment and spending an extended period of time studying one topic. You could study the same syllabus at your work desk, 30 minutes a day but I think there is a definitive benefit of studying a subject in detail over one day. Of course you might get the scenario when studying for one day or how ever long the course is that you will forget all the stuff you learned.

Back to the point I was making, what is the value of of a training course. Well firstly you gain some knowledge on a subject which will hopefully mean you are more efficient at your job and if the course is chosen correctly you will come back to the company with added value (than when you left to go on the course) and use the new found knowledge in your job and in an ideal scenario the knowledge will be passed onto your fellow workers.

This of course comes at a cost to your employer. The first cost is usually a monetary cost for the course and the secondary cost is the cost of you not doing any work for your employer whilst you are training.

Above I have talked about what I think are the basic pro's and cons of a training course. There are other benefits which I feel are more important that the benefits mentioned above.

1. By sending a person onto a training course the company is investing in the person and helping the person improve and grow. This is shows the company values the employee and sees them as part of the company in the future. I say that because you wouldn't send someone on training if you were going to sack them or didn't think they were going to be hanging around for very long.

2. Learning can be a habit. The more you learn the more you want to continue to learn and improve. I find it a bit like reading programming books, after you have finished reading or have been on a training course, you have new idea's you want to implement, improvements to the current way of doing things (often to the annoyance of your fellow developers).

3. A break from work is beneficial, even if you are working. The old saying a change is as good as a rest. I find sometimes that work can grind you down, doing the same thing week in and week out can slowly tire you, especially mentally but you probably don't really realize it until you have a holiday or some kind of break.

4. Networking - You can do some interesting networking on training courses and conferences, meeting people doing a similar job but with different ideas and setups. Sometimes you can learn as much in the breaks talking to your fellow trainee's than you do in the actual training.

overall I think it is important to show you value the worker because often work can feel like some kind of war, the workers versus the management. They are trying to squeeze as much work out of you for the smallest amount of money. Sending someone on a training course can change this way of thinking, it shows that they want you the worker to grow, improve and be happy at work (of course they don't mean it, it's just a trick, I'm kidding I'm kidding).

What do you think about training, is it beneficial, does it change your opinion. I am talking about if you are sent on relevant training courses, I'm not really talking about people being sent on training courses they don't want to go on, although even those get you out of the office for a while. Also do you have any other benefits of training courses, please leave some comments on the subject because I am just voicing an opinion and it would be good to hear some other opinions, contrasting opinions welcome because as regular readers of my blog will know I am often wrong but I am not embarrassed about being rescued by some well informed comments.

please checkout my new blog Amusing IT Stories I am looking for people to contribute and the first real entry is out on friday but if you go there now you will see what it is about.

Linux is modular code turned up to 11

I have been on a Linux training course this week, it's not as good as it sounds because it's Linux and security. The Linux stuff is good but the security stuff is a bit over the top for my needs, not to mention.

We were talking about the cat command and the teacher explained that in Linux bigger functions are often made by linking smaller functions together. This was what I was talking about the other week in my blog entry - The benefits of writing modular code. Seeing some of the Linux shell commands is a perfect example, the commands are small and well focused methods which are easily added together to do more complex things.

What made this more interesting and amazing was the fact that a lot of these functions and utilities were written by different people, maybe in different parts of the world but yet all the functions can then be used together. This is indeed the power of the modular code. I teacher said that this modular ethic was carried on from the bell labs who were I am lead to believe the main developers of Unix. This modular self contained code seems part of a logic idea behind a number of the open source developments, Apache being a good example of this. By writing in this fashion it allows people to easily add other modules without effecting the rest of the code to much.

I certainly like this aspect of Linux and the more I use Linux the more I enjoy using it, it seems in way the more I learn about Linux the less scared of it I am. This does seem to perhaps be leading me into some nasty fall where Linux will bite back. Still at the moment I am enjoying learning about it, it reminds me a bit of my university years where I didn't really have a clue how computers worked.

don't forget to check out my new blog http://amusingitstories.blogspot.com this Friday and beyond.

I need your amusing IT stories and I need them now!

I yesterday decided to start a new blog based around amusing stories that happen to us ground soldiers of the IT industry. I will be posting some of stories which happened to me but I also need the help of other people in the IT industry, yes that's you people who are reading this.

I am hoping to create an funny blog which I will send out maybe once a week, maybe twice maybe more, depending on if people email me any amusing stories.

I am widening the net a bit to include office tales as well, mainly because our computers are usually placed in the office, allowing the computer people to observe the others doing weird things and being baffled by their computer.

here is the link to the site

Amusing IT Stories

I appreciate the first few month(s) it will be typing away trying to write something funny by my self. This would be made easier if just one person emailed me with an amusing story, go on, I know you have, everybody has an amusing story. Think if everyone emailed in one funny story we would have many funny stories to read and that my friends can only be good.

The first blog entry will be this Friday so don't forget to subscribe and go to the site this Friday.

Linux Training course, prerequisites no problem

You will probably notice that this week's blogging will have a definite Linux flavor to it and this is because this week I am on a Linux training course which has the title

Advanced Linux Systems Administration and Security

I have to admit that I was a bit nervous about going onto the training course because I am basically a Java developer who has used Linux a bit, installing Java and Tomcat and not much else. It is pretty much a bungling effort when I am installing on Linux. So in one sense I was glad I was going onto the training course because it will give me a chance to build on my meager Linux skills.

On the other hand there are some prerequisites to going on the course, it stated you needed

"A good grounding in the use of the command line and a text editor is assumed, as is some familiarity with the operation of a Linux machine, and basic TCP/IP networking."

Now I sort of fit the criteria and in fact I learnt quite a lot the week before I went on the course reading up about Linux.

It's also quite interesting looking at the various security aspects of a Linux machine and today's stuff was about logging on, log files, passwords and stuff like that.

I found this link tonight whilst doing a bit of homework on Linux and networking and this site has basically the whole 5 day training in some free manuals.

http://www.comptechdoc.org/os/linux/

The manual guides on the left hand side are brilliant, well written without waffilng on to much about boring stuff, gives you the stuff you want to know, no more and no less. So I am reading up about tomorrows lesson so I don't look like a complete Linux plum, left floundering whilst everyone else is off tapping away into their command lines. This is a bit like cleaning before the cleaner comes, why am I looking over stuff I am going to be taught tomorrow, I'll tell you why because I haven't got a clue about it and I'm not systems admin.

The training was timed very oddly, we started at 9.30, had lunch at 11 ! And then finished the day at 4.30. Who has lunch at 11 for gods sake, talking of the lunch it was good and free, hmmm little sandwiches (triangle of course) spring rolls, some fruit and a cake each, just what I normally have, err not.

The training for anyone in the Midlands is at openadvantage, which can be found here and if the company you work for is based in the west midlands then the training is free, woo wooo. They have other training on things like content management, what is web 2.0, Ruby on rails and other stuff so check out if you live in the Midlands, UK.

Right I have got to get back to reading up on Linux.

Linux Newbie Links

I am fairly new into the world of Linux and it can be quite a daunting place to start with. Although there is quite a lot of GUI stuff these days so I am bungling along and learning a bit as I go.

At the moment I am using Linux not very often, only usually testing or installing on Linux machines when a particular projects needs it. So I have basically managed to install Java, install Tomcat and get it starting up on startup and of course play a few games that come with Linux.

I have found a few good links for other Linux Newbies and thought I would post them in case other people were interesting and so I don't lose them myself.

A good source to post Linux questions
http://www.linuxquestions.org/

A nicely named site
http://www.linuxnewbieguide.org/

This site is really good, like a free administration book really
http://linux-newbie.dotsrc.org/html/lnag.html

A Linux Blog
http://linux.weblogger.com/

The site's good, it has a newbie section and tutorials and lots more
http://www.tuxfiles.org/

The site above has something that I bungled along with for ages, unzipping (windows speak) tar files. Here is the answer
http://www.tuxfiles.org/linuxhelp/softinstall.html

The above problem is a typical kind of problem I run into, I know what I want to do, I know how I do it in windows but in Linux is called something different, placed somewhere different and done in different way. It can be quite frustrating but very rewarding once you do something.

If anyone has any better links please post them in a comment

I just found I have been using a Data Access Interface

I learnt a new term today and I talked about this a little bit during my rant on my blog entry

The benefits of writing modular code

The new term I have learnt is Data Access Interface. It is basically the idea of hiding any data you are accessing which could be a config file, an xml file, a database and hide this data away behind an interface. The article I read also stated you can have service interfaces which do things where as Data Access interfaces are used to access a data source.

One example that popped into my mind when I read this was the interfaces used for databases. By putting all the database connection, reading code behind an interface(s) (like hibernate) you can then swap the database later, write some more code using the interfaces and then the rest of your code won't even know about this.

I also use this technique when I am testing. I often create an interface and then write some hard coded class with the data in that extends the interface. I can then use my hard coded class to test my code and when it is passing the tests, I write the code that actually gets the data from somewhere, which is usually some kind of file the user can change. The rest of the code is just working to an interface so it effected by the change of data source. This is also useful because if the source changes later on then it won't result in much code being changed because you have the interface protecting against code changes.

I suppose that also the opposite is true in the circumstances you want to change the output of some code, which might be making a report. If you have an interface for the result you can then easily put in some code which creates a different output, xml, html, csv. As long as the different reports are being encapsulated by an interface the rest of the code won't be affected.

I find it interesting when someone has labeled a practice that you have been doing but didn't really have a name for. Finding the label makes it easier to talk explain to other members of your development team what code you are writing or what practices you find useful.

My first look at J2EE Design Patterns

As part of the SCWCD (Sun Certified Web Component Developer) exam you have to learn about J2EE Design patterns. You of course have the classic MVC, no I can't bring myself to talk about that.

I found at interestingly that Struts is not an MVC pattern but is a Front Controller pattern. It's weird really when people mention Design Patterns I always think of things like the Singleton or the Factory pattern. J2EE design pattern are a lot more centered on Web applications and aren't quite as interesting to me compared to the normal design patterns. They also seem more high level and don't really give you many code examples.

This link to Sun Design Patterns section is a really good overview corej2eepatterns , you can really see how the J2EE patterns fit together. Looking at this picture/layout I think highlights the difference for me between J2ee pattens and classic design patterns, classic design patterns are bits of code that can be used anywhere you are coding, j2ee are just used for web apps. This is probably obvious to everyone else but I though I would just air my dumb thoughts.

Here are another couple of good resources for J2EE design patterns

http://www.whizlabs.com/tutorial/scwcd/index14.html

http://java.sun.com/blueprints/patterns/catalog.html

It interesting to me that although they are not as interesting in a pure coding sense they are still very useful in explaining why struts is so useful and popular. It also gives you ideas and best practices of how to add things to your web app in a scalable and maintainable way.

Why you should use composition instead of inheritance

I have often read that you should favour composition (Interfaces) over using Abstract classes and inheritance. I have learnt myself that this is a better practise for creating reusable and easily maintainable code but I hadn't really come across a reason for this. So I started thinking about it over the weekend.

The one problem I can see with inheritance is that the code will filter down through many classes. Any changes to the Base Class will effect all the classes that extend the class. This might result in each class overriding the base methods. The more methods a base class the less cohesive the base class will be. It would be more beneficial to create individual objects (composition) so you can have cohesive objects doing one task. This would also increase the likelihood of you being able to use these objects in your code else where.

This in my experience is where using inheritance can get tricky. It starts off very well and cohesive but then making changes can effect a lot of code and the code starts to look like legacy code. What I am talking about is the coupling that is involved with inheritance.

I suppose in practise you could use inheritance effectively and most of use do in time to time but maintaining the code can become difficult with the more code you add the less cohesive. This also works against the idea of separating the code into small well focused objects. You should also try and split the code up into small sections, ideally behind a nice interface to reduce coupling and thus allow the ability to hide the effects of change in your code. If you have a number of small classes instead of using inheritance then you isolate the effects of change to one small class rather than changing the base class of an inheritance tree where the coupling is high.

Book Review - Ship it!: A Practical Guide to Software Projects

I finished reading Ship it!: APractical Guide to Software Projects, it's always a good feeling when you finish reading a book, a sense of accomplishment.

Here is a link to some free excerpts to see if it might interest you.

The book itself is not really very long at around 200 pages but in some ways this is good because it means you can read it and there isn't too much waffle. It fits in very much in the pragmatic programmers book style and if you have read any of these books you will know what I mean but unfortunately I can't really describe it. It maybe something to do with the book being on the small side but you can buy the book quite cheaply if you are willing to purchase it second from Amazon, you can pick it up for about 10 pounds.

The book is not about coding as such and avoids being language specific. I think this is a good idea because the ideas it talks about are more generic and can be used in a number of programming languages.

I shall steal Amazon's description of the book rather than type out my version

Ship It! is a collection of tips that show the tools and techniques a successful project team has to use, and how to use them well. You'll get quick, easy-to-follow advice on modern practices: which to use, and when they should be applied. This book avoids current fashion trends and marketing hype; instead, readers find page after page of solid advice, all tried and tested in the real world.

Aimed at beginning to intermediate programmers, Ship It! will show you:

* Which tools help, and which don't
* How to keep a project moving
* Approaches to scheduling that work
* How to build developers as well as product
* What's normal on a project, and what's not
* How to manage managers, end-users and sponsors
* Danger signs and how to fix them

This is one of a growing number of books about what I refer to as Development rather than Programming. This book in particular focuses on developing software projects in a team, this is probably where it is a bit different from similar books. It talks about simple processes to make developing a project easier, things like setting up build automation, a list to work from, quick 10 minute developer meetings, tracking bugs.

In the middle of the book it focuses quite a bit on the soft issues of managers, programmers, salesman. I found this bit a tad boring but perhaps this might be more interesting to managers or people who are running teams. I found the bits about build automation, using a list and other things very interesting and easy to read.

The bit I found very interesting is the tracer bullet technique of programming which is basically the method of splitting up the work into layers and getting different teams to agree on interfaces to each layer, plug them all in with skeleton code and work from there. This and another article I read inspired me to write this blog entry on method stubs and skeleton code

I have to say I did enjoy reading the book as a whole, there are a couple of slow bits, the talking about people, managers etc and the last section on common problems and how to fix them. The other parts of the book I really learnt new ideas and was inspired enough to think about trying to bring them in, which is pretty good going as I am fairly busy/lazy. The ideas are still there and given the opportunity I will be sneaking them in. Some of the ideas in this book I am already using and have my list to work from.

Overall it's well worth £10-15 quid and once you have finished reading it you can sell it or give it some other member of your development.

Top 10 Must-Read Java Programming Books

I read this article - Top 10 Must-Read Java Programming Books today and found the list a bit odd really. I have never thought of 10 books just for Java developers and perhaps some criteria for this list was that they all had to have the work Java in the title. The list is bizarre because why shouldn't books like the complete programmer or pragmatic programmer be included or maybe the GOF book. In fact there are lots of books about programming skills like refactoring, design patterns which I would have thought would have been on the list but perhaps those books are for a different list, so I will look at the books on the list. I have just copied the list if you can read the article if you would like to know a bit more about each book

1) Thinking in Java
2) Java in a Nutshell
3) Effective Java Programming Language Guide
4) Java Examples in a Nutshell
5) Swing, Second Edition
6) Java Servlet Programming, 2nd Edition
7) Enterprise JavaBeans
8) Expert One-on-One J2EE Development without EJB
9) Concurrency: State Models & Java Programs
10) Concurrent Programming in Java

I'm not sure when this article was written but I would have expected Head First Java to be on the list and that would certainly be top of my list. My other point of contention is the placement of Effective Java Programming. The ideas in the effective Java book are simple but as the title says Effective.

I'm not sure if I can get my head around a list of books just for Java but I suppose reading all these you would be top of the class but a part of thinks that it might be good to read some books on another language or something else.

IT joblessness 'at lowest level since downturn'

I read this article IT joblessness 'at lowest level since downturn' which is saying that the time between jobs for IT contractors is down to it's lowest level since the IT downturn (when ever that was). Here is a direct quote

The number of IT contractors spending more than three months between contracts has dropped to four per cent from 13 per cent in 2002, according to new research.

actually I like the sound of this quote even more

Matthew Brown, managing director of giant group, said: "It's looking increasingly likely that aggressive headhunting of key IT workers, which characterised the last technology boom, will make a return."

Well I like the sound of a technology boom. The article also makes a good point that contractors will soon be in demand because of the release of Vista, where I suppose they will be installing and configuring that. This of course is encouraging news, I have read a number of articles recently which is hinting that IT pay and jobs in IT on the rise. I blogged about Jobs in IT on the rise a few weeks ago.

If it means I get more pay then I am all for it.

The importance of method stubs and skeleton code

I have read a couple of articles recently stating the importance of using stubs and creating skeleton code. There were slightly old articles. I have also read this in the Test Driven development coding ethos, write you code have it return the correct type and correct value.

Another article was talking about mock objects, start off splitting your the code you want to write into layers, work out an interface for each layer or object, return the correct type and a successful value e.g. true or a agreed value and then connect up all the code.

Although I think I picked up this idea by reading articles like the ones above I do it naturally now without thinking about, as soon as I am writing a method or class I get a test up to make sure I am connecting to it correctly.

Maybe with the progression of IDE's it doesn't happen so much these days but I remember coding and everyone do different bits and then all hell breaks lose as soon as you try and use each others code and connect/put them all together.

When working by yourself it's not to bad because you can steps to combat this. The reason I think it's important to connect to all your methods and objects before you start writing the code for them is so you know you are connecting to the correct piece of code. Once you know you are connecting to the code you think you are connecting to you can build the other code up which connects to the stub and also build the stub up, safe in the knowledge that it won't break anything and everyone's code can currently compile.

Another advantage of building a stub method is that you can quickly find out if you the variables passed in and returned are the variables you need. Earlier this week I was writing a method and when writing the stub I realized I needed another variable to calculate the variable returned from the method.

Obviously I could have spent more time designing the method but writing the stub made me think about the method in more detail, which in this case effected some other methods in the class which I needed to change to get the extra variable to pass into my stub method.

So the stub methods benefits are

1. You can make sure all the code is connecting to the correct methods and it is returning the correct value
2. All you code compiles
3. You can code around the stub method because it is returning a correct value
4. It's a good platform to build on
5. It helps you spend a bit of extra time thinking about the design of your methods and how it is all going to fit together, you could put a whole skeleton code of the project you are doing and slowly fill in the stubs. This gives you a holistic view of the project and allows you to see if you think it is going to work or if there are any areas you think there could be trouble in.
6. Stub methods are a great place to leave comments for yourself or others who will be working on the method/class. You could leave rough plans of how you think you are going to code the method.

Pragmatic Programmer sample chapters

I found a very interesting article - 5 books every developer should read on DZone it's of a type you will have no doubt seen before but no doubt couldn't help clicking on again,

the "random number" of books a developer should read

Of course reads these articles to see how many they can tick off. I find these articles more useful the more I read because it then isn't just one persons opinion but a number of people and I can then see what books appear more than once. Although saying that I also find it interesting seeing a book that hasn't made it onto a previous books list.

I will say that this list is very well done, it's short so it's quick to read and it has sample chapters of the five books he lists, he finishes off with a five more just titles that didn't make the list.

below is an example of the one of the entries and useful to me because it lists all the Pragmatic programmer free excerpts in one place (and hence I have put in my blog so I can find it again)

The Pragmatic Programmer
The pragmatic programmer provides invaluable advice to those who are just starting to program, and those who have been programming for years. By following the authors' simple rules you should have gained some programming wisdom that a programmer would realize in a decade.

Extracts from the book
The Preface
Software Entropy
Programming by Coincidence
Evil Wizards
Balance Resources
Summary of the book's tips
Contents

I really like the pragmatic programmer site and articles it has on there and I have read some of these free sample chapters before but there are a few I haven't read.

Whilst I am talking about the pragmatic Programmer here is list of all the tips on one html page

http://www.codinghorror.com/blog/archives/000103.html

whilst makes it easier to print out

\n - newline saves the day and formats all my troubles away

I had an interesting problem today. I was reading in a file line by line and when a certain line came in I was catching it and replacing the line with a changed version. The problem I then had was when I was writing the file back out, the code supplied by the excellent Java Almanac helped with this

The java.io stuff is really easy to use and saved me loads of time recently. Actually looking at the Almanac I could have used a regular expression on the file, it may be quicker that way but I already had the code to read in files and change them so I went with what I knew.

Anyway so I was reading in the file, doing a switch on some of the values and then writing the String to a file. The problem I was having was that it just came out as one great big long line and I wasn't sure how to format it. As people who read in Strings and make them into File's will know you have to double up on the backslashes. Recently when studying for my Java exam they make you learn a small amount of Regular expression stuff and the reason you have to double up on the back slashes is because regular expressions have a lot of constructs which use a backslash and then a letter or number to mean something else. These special \ enabled regular expression values I think are called meta-characters. You can find more about the Regular-expression constructs here

So why am I talking about this it's because what I needed to add to the end of each line when I read it in was a \n which a character literal for newline. I added this baby in and boom the whole document was formatted again. Below is what I added

\n The newline (line feed) character ('\u000A')

once again the fuzzy knowledge learnt by studying for the SCJP exam has come to help me out.

The Craftsman articles from Uncle Bob

I was reading the Craftsman articles from "uncle Bob" Robert C Martin I have read quite a few articles from uncle Bob but I always liked the Craftsman articles. I think it was because I didn't know about half of the things he was writing about so it was an interesting introduction and a good starting point to go and read up about the things he mentions.

On the other hand the craftsman section is completely weird and like nothing I have seen. A story about a programmer on a space ship, now that is some crazy stuff.

I noticed recently that all the 48 craftsman stories are in the one place, I'm sure before they were half placed somewhere else and in word format.

I think I read somewhere that he is planning a comeback for the craftsman.

Here are the articles I am blabbing on about

http://www.objectmentor.com/resources/listArticles?key=topic&topic=Craftsman

to give you a hint of what the Craftsman is about here is a small bit of the first episode

Dear Diary,
13 February 2002,
Today was a disaster – I really messed it up. I wanted so much to impress the
journeymen here, but all I did was make a mess.

It was my first day on the job as an apprentice to Mr. C. I was lucky to get this
apprenticeship. Mr. C is a well recognized master of software development. The
competition for this position was fierce. Mr. C’s apprentices often become journeymen in high demand. It means something to have worked with Mr. C.

I thought I was going to meet him today, but instead a journeyman named Jerry took me aside. He told me that Mr. C always puts his apprentices through an orientation during their first few days. He said this orientation was to introduce apprentices to the practices that Mr. C insists we use, and to the level of quality he expects from our code.

This excited me greatly. It was an opportunity to show them how good a programmer I am. So I told Jerry I couldn’t wait to start. He responded by asking me to write a simple program for him. He wanted me to use the Sieve of Eratosthenes to calculate prime numbers. He told me to have the program, including all unit tests, ready for review just after lunch.

This was great! I had almost four hours to whip together a simple program like the Sieve. I determined to do a really impressive job. Listing 1 shows what I wrote. I made sure it was well commented, and neatly formatted.

I can tell that you are already hooked and hungry for more adventures from the young programmer.

A long day of unit testing

I was writing some code which archived a list of files into a specified directory. As a supporter of unit testing and Junits I was keen to get some tests to see if my code was working. I actually wrote the test before coding the method. I won't bang the unit test drum today but needlessly to say if you haven't worked by writing the unit test first and then writing your code, I highly recommend it. The one thing that always amazes me is the amount of small syntax and silly code the tests catches and it's a lot easier to catch when you are just testing one method at a time rather than trying to find the problem in a piece of code which nips in and out of 30 methods

Back to my unit tests. To correctly test the code was working correctly I had to do a fair bit of ground work creating a small directory structure and then putting a file in it and finally archiving the file into another directory. This is where sometimes you question all this unit testing stuff but I stayed with it and then I got it working and found a few bugs and then felt my code was in good shape.

The only nagging problem I had was that the tests weren't working every time and if one of the tests broke it was effecting the other tests. It was linked to the way I was deleting the folders and files I was creating for the tests. If it failed one of the tests then it wasn't cleaning up after itself or wiping it's feet on the way out. Damn I was close but not close enough.

I started off making the File(s) of the directory's I was using and then doing a File.Delete() and testing to make sure they didn't exist but I didn't feel this was the right way to go about it because it was then the next test, testing the previous test had worked correctly. I knew this was bad so I went for a tea break and then came back determined to sort this test out. I decided that each test should clean up after itself, the reason why I didn't do this before was because if any of the tests failed it didn't always reach the bottom of the test where the cleaning up code was. What I needed was a finally block to do the cleaning up and remembering some stuff from SCJP exam (who would have thought it would actually be useful). Remember some information about try and catch blocks, I remembered I didn't need the catch block and could just put in a try and finally block. So this is what I did and now all the tests are happily cleaning up the files they used. Success.

So once I got the main test working I added a few more which caught some more bugs and I finally I had my code and had it tested. Another interesting nuance of writing unit tests is that I tend to write smaller methods test them and then use a few smaller methods to create a bigger methods, which fits in with my recent blog entry

keep your methods small and focused

One of the by products is that I write a small method test it and then write a bigger method using a few smaller methods. When I then need to write a method which does something similar but different I can often quickly build it up by using some of the smaller tested methods and just a change a few methods. Writing smaller methods gives you building blocks.

So that was my battle with unit testing yesterday and one point it did feel that I was doing quite a lot of work and not actually writing any production code but in the end of the day I felt it was worth it. Firstly I created some tests which are independent of the correct folders being on a machine that runs them and secondly I tested the code and found a number of bugs, which I was glad that I found them early on when I was only testing one method and hence quickly found the problem. Once you test a method and are happy that it does what it should it gives you confidence that any other problems are unlikely to be caused by that bit of code.

The way I think about writing unit testing is it's better to spend the time writing tests than spending time debugging the code later because writing unit tests is 99 percent of the time quicker than debugging the code at a later date.

Why Abstract Data Types are useful

I recently blogged about using Interfaces to encapsulate code changes in this blog entry. I seem to write about interfaces and Abstract class

Interfaces and Abstract classes - don't design without them

Why Interfaces are better than Abstract classes

Why I found recently is that the idea I was writing about in using Interfaces to encapsulate code change is really talking about Abstract Data Types. The idea being you have an abstract data type (ADT) which then means you don't need to know what the actual data type is, so you code is not linked to any one data type. One of the main benefits of using ADT's is you can then swap the actual data type being used and the rest of your code won't know or care about it because it will only be using the Abstract Data Type.

I have recently come across a good example of this whilst working. We have a piece of software which draws images of maps, recently we created some interfaces so that we could use an interface lets say called mapEngine. By using the mapEngine interface we now have the possibility to use different map drawing engines without any of the code knowing or worrying about it.

The important point was that code had to only use the mapEngine and not access the different drawing engines directly otherwise we would be coupling that code with a specific map drawing engine. The important point being made here is that any new code would need to change the mapEngine interface (which is an ADT) so to avoid coupling to a specific data type.

Other popular ADT's are things like List and Java Collections are a good example, you have the ADT of List but really this list could be a LinkedList, ArrayList etc.

here is a link to wikipedia if you are hungry for more information and another quick link I found

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

http://www.zib.de/Visual/people/mueller/Course/Tutorial/node4.html

I'm sure there are many other better resources and just typing in Abstract Data Types should get you on your way to finding more information.