Keep your methods small and focused

I read this the other day in the middle of an article talking about design. This is one of my favorite programming idioms because it makes reuse of the methods later so much easier. I ran into an example today and it's one of those examples that when you find you can reuse one of your methods you are pleased with yourself and thank your earlier self for helping you out now.

This is a very simple example but it basically involves using a template file and copying it and renaming. Last time I was doing this I had to copy a batch of files each file with a different extension. Instead of making a method which copied the files and mentioned their extension I wrote one method that did that but which called a smaller focused method . The method in question took folder to copy from, folder to copy to, filename, newFileName and extension. The method above just called it four times with different file extensions.

Now because I have a smaller focused method I can use that method today to copy some different files. I think this is one of the key points in being able to write reusable code, small focused methods which are not heavily coupled with other classes or are trying to do more than one task. I have heard this talked about as do one thing and do it well and linked to keep it simple. To put the above rambling in a more concise manner

1. Keep your methods small and focused.

2. Your method should do one task.

If you do the two above then you will probably be keeping the code simple anyway but splitting up potentially larger methods in smaller focused methods. As a bonus these methods are then easier and quicker to test and if a bug does sneak in then because the code is split up into smaller sections any code that needs to be fixed is isolated in it's own method.

Ever tried googling yourself - I bet your employers have

I read this article today about a university professor who was investigating people "googling" his name. He talks about how everyone should "Self Google" apart from sounding a bit rude, it is something which I am sure everyone has done. It is an interesting thing to be aware off because I'm sure that most employers will Google your name before interviewing you, so it is worth trying to manage the results.

I suppose it is not something I really think about when writing my blog but the fact is that unless you take the blog down at a later date then the blog is going to be there and your current or new employees could read it. So is there anything on your blog which your employer might not like, is there anything which says anything about the company you work for or the employees there.

I don't think this aspect worries me but it maybe concerning if you were going for an interview and a prospective employee read the blog. A technical (well some might argue) like this one isn't so bad but what if you had a personal weblog expressing political views or extreme views. This might give a potential employer the wrong impression.

The article talks about a good example where someone accused a company of fraud and then in his next job that company was a customer, so it didn't look good when you googled his name and up popped his blog accusing a customer of fraud.

The article does summarise by saying that writing a weblog can help shape your public online image because then when people type your name they will go to your weblog and see the stuff you have written about. So blogs can have a positive effect on googling yourself but you have to remember that these pages will probably be around for a long time. I keep thinking of the Gladiator quote (slightly changed)

"what we blog today, will echo into eternity"

Actually far more embarrassing than employers potential or current reading your blog is your girlfriend or family. My girlfriend likes to refer to my blog as my Nerdy geeky blog.

Anyway Self google yourself and see what pops up.

The benefits of writing modular code

I got a fair bit of criticism for this putting be modular as my last tip in my blod entry 10 tips on writing reusable code, in truth I couldn't really think of any more tips and I wanted 10. I have been thinking about this recently and thought I would perhaps try and explain what I meant be your code being modular.

I view modular code as code that is like a black box, you know what you what you pass into the module and you know what comes out but you don't know or care how it does it. Similar really to 3rd party pieces of code or code that Sun writes, why bother wasting your time knowing how it works but focus on writing the code that uses it.Modular code has a public interface to a class or classes. I view modular code as being almost stand-alone pieces of code.

Modular code should have few connections to other modules so it should have weak coupling. The effect of coding a module means you are writing a self contained piece modular object is that it doesn't have links to any other modules and hence the weak coupling.

I know that what I am describing is probably just good coding practise by I feel the word modularity does help clarify the overall thinking of design decisions by thinking of each module as a separate self contained piece module, keeping back the tentacles of coupling.

One of the benefits of writing modular code is you will end up with a lots of modules which you will be able to use in lots of different projects and use different modules together.

By using different modules to create your software you will also be able to control the changes needed in the future by managing future change. Modules will naturally result in changes have a smaller effect on your code because you will hopefully be able to isolate the change to just one or two of your modules leaving the rest of the code unaffected by change.

Another good use of writing modular code is when the code is using an external resource like a configuration file, database or some other kind of input file. By accessing the resource from the one module you can then change the input type or the processing of the input without any of the other code being affected because the other code only interfaces with the one module.

Modular coding also uses encapsulation and information hiding built into my definition of modular code

Well I hope I have described what I meant by modular coding and I appreciate that I basically mean using all the good OO coding standards that we are told to use but I see that as a good thing. It also not new but I am just replying to the comments on my blog rightly criticising the vague use of the word modular.

The Code Sermon Podcast - it's here to save your code soul

I found this useful little podcast yesterday called the Code Sermon. It's basically tackles one development best practise each week. The good thing is it's only 10-15 minutes long so it's easy to listen to. Here is the link to the website

http://www.codesermon.org/

Below are the current podcasts available, I liked the topics because they are useful everyday things.

CodeSermon Episode 1: The Virtues of Unit Testing
CodeSermon Episode 2: Perils in File IO
CodeSermon Episode 3: Application UI Responsiveness.
CodeSermon Episode 4: Optimization.
CodeSermon Episode 5: Deployment
CodeSermon Episode 6: Error Handling
CodeSermon Episode 7: Post Deployment
CodeSermon Episode 8: Memory Management
CodeSermon Episode 9: Warnings
CodeSermon Episode 10: Robustness
CodeSermon Episode 11: Platforms
CodeSermon Episode 12: Naming Conventions
CodeSermon Episode 13: Concurrency
CodeSermon Episode 14: Strings
CodeSermon Episode 15: Loops
CodeSermon Episode 16: Constants
CodeSermon Episode 17: Premature Optimization
Episode 18: Release Mode Debugging

Why Design Patterns are useful

I was thinking today about Design Patterns and I not only do I find them interesting but they are very useful as well. I thought I would note down the reasons why

1. A tried and tested solution to a common problem

2. Other programmers can understand what you are talking about and if they don't understand then there is information out there

3. Examples of code to aspire to

4. A good way to learn

5. They aren't the solution to every problem but they can still help you

1. What you get with Design Patterns is a lot of common problems and then a lot of common solutions. Not only have you got access to the code but there is also lots of data with detailed explanations to help you understand it. Also the code you see with Design Patterns is not only tried and tested but has gone through numerous interactions.

2. If another programmer also knows about design patterns then you talk about code with complex structures by using a quick word instead of explaining the idea by talking about each class and then drawing uml diagrams etc etc.

3. One of the main reasons I like Design patterns is looking at the code. The code is so lean and mean. I am always amazed that there is just so little of the code and personally it is the type of code I would like to be writing.

4. Reading about design patterns and looking at the code is a good way to learn because there is a lot of Design pattern resources out there, so if you can't understand one persons explanation then you can read another which might be more suited to your learning style.

5. Sometimes using Design patterns is not the best solution because they might be too complex or just not suited to the task at hand. There is a danger that people who have just learnt about Design Patterns go about putting them in the code at every available opportunity. Don't do it. What I find sometimes thought is that looking at various design patterns can give you an idea, you can borrow some of the Design Pattern and apply it to the code you are currently writing or looking at the design patterns might give you an idea of how to structure the code. The examples that accompany Design patterns aren't usually anything like the problem you are looking at but you can always adapt the design patterns into your own creation and who knows you might even create another Design Pattern in the process.

Jobs in IT on the rise

Although once again based on one set of data and in a not very scientific format here is an article stating that jobs in the IT sector are on the rise.

This isn't the first time I have heard this fact either my Mother read something about a lack of young un's studying IT at university, which means there is going is starting to be a shortage.

Although this study is based on a world study as well it does say that 60 percent of the new posts advertised our looking for new staff rather than replacements.

So lets all hope it leads into the dream scenario of a bidding war for my employment with employers desperately fighting each other, offering more and more perks.

or I will just get back to work but at least the future could be bright. What I think the IT sector needs is another Y2K problem, which should just all agree on creating some bizarre bug, all the programmers join a union to make sure everyone puts it in. Then in 10 years we can bring the world to it's knees, all get paid triple time to fix an easy bug and then all go out celebrating with a pockets full of cash.

IT bosses: focus on staff retention

This article although based on a small section of data is an interesting comment. I often wondered why employers let experienced staff go to another job, when the only reason they have left is for a small pay rise.

Of course it isn't always easy to give someone a pay rise without rocking the boat for the rest of the developers.

I suppose I am wondering is how much the value of company knowledge. This sort of knowledge is about knowing how all the company systems, software and people work. These things take usually about six months to work out because each company has it's own way of doing things, usually a different collection of software used to do it. This isn't really going into detail about customer knowledge and in depth knowledge of particular projects.

It always strikes me as a loss when a developer leaves to go somewhere else for a £1000 pay rise but often the employer won't give him that extra money.

Still I would perhaps see it differently from the other side of the fence. Also when people do leave things continue, someone else struggles along to begin with but then 3 months later everything is working as it was before.

It's an interesting issue on how employers try to retain their staff and it's not all down to wages, it could be sending their employees on training courses or giving them moreresponsibilityy etc.

lets just hope it's true and my employee starts showing me with training, that etc monitor I wanted, a big pay rise, overtime, sky tv, a secretary, etc etc,

Use interfaces to protect against change

This is one of the more challenging areas of programming. It doesn't really involve doing much extra work at the time but the correct design decision can make your life so much easier in the future. It reminds me of one of the more memorable saying's

"closed for change but open for extension"

It is known (having just looked it up again) as the open closed principle and there are many articles linking to it but I first read about it here

and I found the objectmentor site a brilliant resource for OO topics and well worth checking out if you are interested in that kind of thing.

This saying encapsulates what I try and do. I want to write code that won't have to be changed in the future but if at a later point we need to add some changes in like a different algorithm or add a new report then you should be able to extend the current code and add in a new report. That's what happens in a perfect world.

To achieve this result you need to think about what areas which are likely to change and in these areas you need modularise the code so it is in small components. This means that you will be able to reuse these code components. You also need Design an abstract interface to your code. I often call this base classes and these can be abstract classes or interfaces but the purpose of the class is hide the change behind the class and reduce any coupling to the classes behind it.

An example of this would be if you were working on a piece of software which does reporting. You currently support report formats of html. You then want to add a pdf report. If you planned ahead you could have a put in place reportFormat interface. The rest of the code would still interact with the reportFormat. So the reportFormat interface means the only changes will be behind the reportFormat interface and the other classes outside of the reportFormat package won't know that a change has taken place.

So the interface is used not only to hide the information of what report format classes implement it but it also hides the changes from other areas of code that use it. We have also haven't changed any of the code that was already there.

Obviously this is a simple example using an interface where you think the code would change in the future is going to make it a lot easier to maintain and extend this code.

I found I had difficultly writing this type of code earlier in my programming days and it was because I wasn't thinking about information hiding and loose coupling because I didn't know about them, all I was thinking about was writing the code to do what the spec wanted it to do. I didn't have any code reviews either so no one really told me that their was a better way until I found out for myself. Writing the code to do what the spec says is half of the solution, keeping one eye on the future so you will easily be able to maintain and extend the code is the other half of the solution.

Log once, read anytime - Why logging issues is important

Although this sounds obvious it's still something we don't always do and the only realreason is sheer lazyness. The only real disadvantage is that it takes a few minutes to do but the benefits completely out weigh this.

Where I work currently didn't have a method of storing customer issues. This resulted in all the developers keeping emails all over the shop. What this means is that the same developers could all find the same issue, all resolve the issue and all store what the issue is and how to resolve the issue without telling any of the other developers unless the developer happens to ask someone.

I have personally fixed an issue myself and then couldn't find the email with the answer on. Even today I had an issue but managed to find the email with the answers and put it into bugzilla.

Bugzilla for those who haven't heard of it, is a nifty open source for storing and searching your bugs

http://www.bugzilla.org/

The main benefit of logging your bugs into a database is the fact that you and the othe members of your team can search the database and find details on what the bug is, how to recreate it and most importantly how it has been fixed or a workaround. This way the solution is safe from data hiding or people just forgetting how to resolve a bug. You can even see who delt with the bug before and ask them about it.

Having a bug database is even more useful to people who have just joined the company and don't have a clue about certain parts of the system, let alone fixing them. They can search the bug database, read the answer and then get back to the customer as if they have just fixed the problem themselves.

Having a bug database also allows the development team to see what bugs are currently outstanding and need to be fixed. Sometimes people are changing a certain piece of code for another reason and whilst they are there they can fix another bug. Sometimes people need a small bit of work before they start another project, boom they can look in the bugzilla and find something to get their teeth into.

It's also useful to see what customers have raised what issue's and how many they currently have waiting.

Lastly and quite importantly it creates a system where everyone knows where to look for information about bugs, everyone logs bugs in the same place and all the information is stored in central location. The knowledged is shared.

So remember next time you have got an issue which you have solved, put it in the bug database one day you will go back there and give yourself a good pat on the back for doing it

Why I want to use CVS and automated builds

We currently use Visual Source Safe at work and it is a bit of an old clunky thing. It might be because we are using an old version of it or whether it's just rubbish but I want to change to CVS.

I tried (all to briefly) before to look at setting up CVS but I gave up because I had to finish some work and I couldn't find any documentation to tell me how to easily install the thing.

I also want to move to CVS is because you can easily integrate it with Eclipse.

I have been thinking recently that it's about time I tried looking at it again. The main driving force behind my ambition to change to CVS is so I can create an automated build. The build at the moment has improved a lots and it's almost automatic except everyone runs it in their own development environment and it points to their own code. It also doesn't manually check out the code from repository. These has meant we are not always working with the latest code and we also tend to have our own files mixed in with the latest files which can often hide dependencies, which we don't find out about until someone else tries to build the code.

If we can get CVS in we can then setup an automatic build of the latest code which if nothing else should see if the code compiles and then I can setup Ant to run the few Junit tests we have to make sure the code passes that test. Anything which finds problems earlier is a good thing in my mind. Recently we haven't been putting much code into the main product and have been working on smaller projects but before that there have been times where someone has put in code which compiled on their machine but without the special files they had on their machine wouldn't compile for anyone else.

The reason why I have become interesting in this was because I was reading this massive article on Continous Integration, I say article it's more like the size of a book

http://www.martinfowler.com/articles/continuousIntegration.html

Anyway he puts forward a very strong argument why people should a continuous build and the first step towards that is getting CVS used here.

Managing Complexity - The aim of Designing Code

I was reading Code Complete and the chapter was talking about Design and it was saying one of the most important parts of Design is managing complexity.

This makes perfect sense really, the whole process of designing is breaking the problem into smaller more manageable bits. He states that humans struggle to comprehend one massive complicated piece of software but can understand it easier if you split it down into small subsections.

If you think about the way you start designing you work with large abstract ideas and then slowly work down into smaller and smaller sections, until you end up with lots of small sections.

What I like about the idea of Managing complexity is that it means you start with something simple and then battle with it to keep it simple. It reminds me of seeing the code for a design pattern or a piece of code my some Java ninja, it always strikes me how simple it looks (and then you think, I could have done that).

I also like the word complexity because it's at the heart of making reusable code, reducing the complexity using encapsulation, and cohesion. I also think of complexity as being directly linked to the number of classes linked to a class. e.g. coupling. A simple class/package has loose coupling and is linked to the smallest amount of other classes as possible.

This is easier to understand, maintain and test.

What strikes me about linking Design with Managing Complexity is it is explaining simply what you are aiming to do when designing your code and just having that in my mind will help me focus on the objective of managing complexity.

This chapter is actually a free download on the Code Complete site, so if you would like to read more, firstly I would suggest you buy the book because I am finding it very useful and interesting but if you would like a taster to see if you would like the book here is the link

http://cc2e.com/docs/Chapter5-Design.pdf

I have talked about this book before and given links to two sample chapters, if you want a rough outline of the book a list of the contents, check out my previous blog entry

http://hoskinator.blogspot.com/2006/06/design-in-construction-code-complete-2.html

expect to see me talk about more of the topics mentioned in this book

Is it time you tried some new programming habits?

This is something my Taekwondo instructor is always going on about, we practice TKD twice a week so if we are attacked then we will just react out of habit. It's important you must practice hard so that when it comes to the crunch you hit full power outside when you are being attacked.

That isn't really that relevant to the point I was going to make but it's a slightly interesting story so I thought I would put it in. I

Ship It!: A Practical Guide to Successful Software Projects

It is a book about development and I am always quite interested in these books because it's like getting the advice from an experienced programmer about how you work. Not about coding but about the whole programming concept.

In the first chapter they are talking about Habits and people just get into the habit of doing things because that's the way they were shown or that's how people do it at a certain company. I am always keen to try and improve my development process and if someone with a lot of experience is going to give me some advice (via a book in this case) then I am going see what they have to say.

Talking of habits reminds me of when I first became a Java programmer I would often do things that I would know worked but without really knowing what they're doing. The more experienced programmer showed me how to solve my problem but didn't really tell me how it solved the problem or why.

It's always interesting when you work with new developers to see their work processes and code. Everyone is usually very different, everyone does bits of some methodologies whilst excluding other bits. The main person to benefit is you when working with different people because you can see how their way of doing things is different and then you can take bits and put them into your own style. One person I worked with was very into preparing things at the start with a requirements documents, UML diagrams and then after all that he would start coding. Initially I thought this looked like a lot of work but he did it and his code always worked very well, so I thought I would give it go. Now I do it all the time and find it very useful and I was even blogging about it the other day

Planning cuts time bug fixing

So back to my point. The chapter starts off by saying, try a bit of a new methodology, try it for a week and if you like it, try it for a month. It's true, if it turns out to inefficient then you can go back to your old style knowing that it's quite good and if the new method turns out to be beneficial, well you have benefited.

Pragmatic programmer list of tips

I found this today and it's a really quick but useful list of tips on the pragmatic programmer website. It's a simple idea but a good one, I'm sure everyone has a few tips which they use when programming. I wrote 10 tips on writing reusable code so I could jog my memory when coding to try and make sure that I thought about trying to make the code reusable. In fact a lot of my blog entries are tips to myself on practices and methods which make it easier to write good code.

Here are few of the more interesting

Make It Easy to Reuse
If it's easy to reuse, people will. Create an environment that supports reuse.

DRY---Don't Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Write Code That Writes Code Code generators increase your productivity and help avoid duplication.

Minimize Coupling Between Modules
Avoid coupling by writing ``shy'' code and applying the Law of Demeter.

here is the link so you can go and read them all yourself

http://www.pragmaticprogrammer.com/ppbook/extracts/rule_list.html

I might even pin it the rules up somewhere on my desk

Auto Starting Tomcat on Linux

I have been looking at Auto Starting Tomcat on Linux the final piece of my adventures with Tomcat and Linux. The other parts of my Linux Journey are

Idiots guide to Installing Java 5 and Linux

installing two versions of Tomcat and finding out what ports are being used

Increasing the memory allocation for Tomcat

Anyway so back to autostarting Tomcat on Linux. I have looked at various articles telling me how to do it and I have basically taken the best bits of a few them. Here are the more helpful ones

http://www.sitepoint.com/article/jsp-quick-start-guide-linux/3

http://www.option-c.com/xwiki/Jakarta_Tomcat#Auto_Startup

http://www.informit.com/articles/printerfriendly.asp?p=336708&rl=1

I read the articles above and then went my own way stealing a bit from each of them

My understanding of Linux is very poor as you can guess by reading this document. Basically to auto start tomcat you need to copy a file into a directory where Linux will look for it on startup. I believe Linux looks in the directory

/ect/rc.d/

in here there are a number of number directories from 0 to 6 and these are run in numerical order with 0 being the highest priority. It seems to be standard practise to put your actual shell script into the folder

/etc/rc.d/init

Then you create a link file into the other relevant directories and then this file is automatically run when Linux starts. Let’s start by creating the file we are going to run. You could probably put the Catalina.sh file in here but I preferred to create a new one called tomcat, below is the tomcat shell script I created. You make put this into text editor and save it as tomcat into the /etc/rc.d/init directory.

#!/bin/sh
#
# Startup script for Tomcat
#

case "$1" in
start)
echo -n "Starting Tomcat "
JAVA5_HOME="/usr/java/jdk1.5.0_07" ;
JAVA_HOME=/usr/java/j2sdk1.4.2_04;
JRE_HOME=/usr/java/jdk1.5.0_07;
CATALINA_HOME=/usr/local/tomcat;
export JAVA5_HOME && export JAVA_HOME && export JRE_HOME && /usr/local/tomcat/bin/startup.sh
;;
stop)
echo -n "Stopping Tomcat "
JAVA5_HOME="/usr/java/jdk1.5.0_07" ;
JAVA_HOME=/usr/java/j2sdk1.4.2_04;
JRE_HOME=/usr/java/jdk1.5.0_07;
CATALINA_HOME=/usr/local/tomcat;
export JAVA5_HOME && export JAVA_HOME && export JRE_HOME && /usr/local/tomcat/bin/shutdown.sh ;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac

exit 0


I'm not exactly sure I need to create the JAVA5_HOME, JAVA_HOME, JRE_HOME, CATALINA_HOME but I know the Catalina.sh file uses these parameters and that file is usually called on startup so I thought I would play it safe. The start and the stop code as you can see calls the startup.sh and the shutdown.sh and this is pointing to my tomcat installation directory. I have the JAVA5_HOME because I have OC4J installed which uses the JAVA_HOME directory so I had to create a different variable.

Once I have created this file and named it tomcat, I then need to create the file links and place them in the correct directories and below is the instructions for that which are run inside a Linux terminal.

# chmod +x /etc/init.d/tomcat
# ln -s /etc/init.d/tomcat /etc/rc0.d/K91tomcat
# ln -s /etc/init.d/tomcat /etc/rc1.d/K91tomcat
# ln -s /etc/init.d/tomcat /etc/rc2.d/S91tomcat
# ln -s /etc/init.d/tomcat /etc/rc3.d/S91tomcat
# ln -s /etc/init.d/tomcat /etc/rc4.d/S91tomcat
# ln -s /etc/init.d/tomcat /etc/rc5.d/S91tomcat
# ln -s /etc/init.d/tomcat /etc/rc6.d/K91tomcat

This creates the file links which will be run automatically by the Linux system on startup and shutdown. You should check the file links have been creating correctly by going into the directories specified above and looking for the relevant files and making sure the file doesn't say link broken. Hopefully when you restart the machine tomcat will automatically be up and running.