12 Nov 08 That thing about CI – Continous Integration

Challenging Business requirements and the need for software development teams to remain agile and competitive while managing parallel development and releases requires a system which is adaptive to these demands.

Our approach to SCM enables unlimited and adaptable process models, which are ideally suited for parallel, distributed, and agile software development. Using state of the Art technologies from various vendors to automate processes such as branching, merging, build, and release keeps you a click away from software delivery.

The real matter then is the sanity of your application and that’s the challenge we all need to address. We can have cute products right of the shelf to get it up and going but the whole challenge lies in the statement “up and going”. It takes a ton of energy and effort to come up with the right process and the right tool. I have not seen alot of CI projects failing strictly. But I do have seen extra efforts into things that should not be really there. failure would then mean the amounts of efforts spent on doing not so trivial stuff and on the other end if you are spending alot of time doing the major flows then definately something is wrong.

Automation does solve most parts of the problems but things that really need to be taken care of to get it right in the sweet spot are the ones Martin Fowler described in one of his articles.

* Maintain a Single Source Repository
Keep everyone together, at the end of the day we all work together dont we?

* Automate the Build
Automation of the build helps you.

* Make Your Build Self-Testing
Self testing build tells you exactly what you did and what you broke. So I can come up with this statement to my Lead. “If I commit this, it might break alot of stuff”. Well Sir, try running the Unit Test, You will know for sure! But then again honesty on the test cases really doest matter!

* Everyone Commits Every Day
Typically in a Agile environment helps alot, and forces you not to break the build. Better organization I must say.

* Every Commit Should Build the Mainline on an Integration Machine
Sanity checking of your commits. So often we commit without realiazing that we break something else.

* Keep the Build Fast
I usually commit before leaving for home. It helps great deal when you get the feedback within 5 mins. kind of a benchmark but depends.

* Make it Easy for Anyone to Get the Latest Executable
Keep all the build results and one sharable place. We did that on one of the http servers some time back

* Everyone can see what’s happening
Importantly that all results are published for all of us to know.

* Automate Deployment
Deployment automation means that my buddy X on the other side doesnt screw up the server for even a 1 min. Only deploys when build successfull.

Hope this helps.

Resources:

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

Tags: build, CI, continous, engineering, integration, Software

31 Oct 08 How to read a file from the JAR?

Someone just asked me this question today. And I thought might as well put it down for info.

1
2
3
4

 public TestReadFileFromJar() throws FileNotFoundException, IOException {
        InputStream is = getClass().getResource("txtData/states.properties");
        read(is);
}

In the case above txtData is placed in the jar on the root. Remmember to add the path with the /

Tags: HOWTO, jar, Java, Programming, Software, Software Development, tips, utils

31 Oct 08 Command

By using the command pattern you are seperating the operation from the invoking object. And just because of that it becomes easier to change the command without chagning the caller/s.
This means that you could use Command pattern when you might have the following situation

You want to parameterize objects to perform an action
You want to specify, execute and queue requests at different times.

Just to quickly start you need a command object, An interface will keep it easy going in this case, thus providing you with the option of extending other classes e.g. Swing MenuItem or Button.
Below the execute Method is the one invoked to do something when this command is called or asked to do its stuff.
Where as the getCommandName is assumed as a unique name how ever I am sure we can always come up with a better implementation for uniqueness.

1
2
3
4
5
6

public interface Command {
 
    public void execute();
    public String getCommandName();
 
}

And example implementation of the Command should look as follows
A Command Name, and and execute Method to tell what happens when this command is called.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class ForwardCmd implements Command {
 
   private String COMMAND_NAME = "Back";
 
   public BackCmd() {
       super();
   }
 
   public String getCommandName() {
       return COMMAND_NAME;
    }
 
    public void execute() {
        System.out.println("Your wish, my command");
    }
}

The command manager is the controller in this case. It registers command objects. the “registerCommand” will simply take a command and store it in a list or something alike. This means you could load it out of a jar file, or an xml or path and just pass the object to the “registerCommand” AS a command offcourse.

the “execute” Command will simply execute the Command passed to it.

And the “getCommand” returns a command by looking up a COMMAND_NAME. So if you provide a name to it through you system it should give you an object of type Command and simple pass it to execute. Again this would be a controller logic and not the client one.

1
2
3
4
5
6
7

public abstract class AbstractCommandManager {
 
    public abstract void registerCommand(Command command);
    public abstract Collection getAllCommands();
    public abstract void execute(Command command);
    public abstract Command getCommand(String name);
}

Tags: command, Computers, Design, Design Patterns, GOF, HOWTO, Java, Patterns, Programming, Software, Software Development