Hudson: a Continuous Integration System

Software Engineering, a term that brings to mind many words. Easy is not one of those words. That's because programming is a tedious process that requires many steps, from testing to debugging. That's why there are many tools out there that are created to help the process along and keep programmers a bit more happy.

I was just introduced to a tool that tries to do one thing very well, Continuous Integration. Hudson is online software that updates software for a project site and maintains the integration process so that users are taken out of some of the frustrating parts. I certainly don't want to keep making distribution files and uploading them.

What makes this an improvement from subversion you may ask? Well, subversion is still part of the system. A user can still use subversion as the updater, but Hudson takes a step further and checks for errors as well as maintaining different projects. Hudson is a system that does not require installation. It's cloud computing or something similar to it. This makes the system very easy to use.

I made one commit to the package and Hudson was able to determine if my package was working or not. When an error was detected, I fixed it and was able change my configuration in a few seconds and the project was updated as well in even fewer seconds.

Hudson is another tools that can help developers work faster and with less human error. It does this because I believe packaging software, updating it and integrating it with other software are all trivial tasks. "Work smarter not harder"

Hudson Wiki Site

Some fundamental Questions

Here are some questions I think software engineers should know. These are also important because they are part of the topics I've been studying this semester in class.

1. What are some things you can do to prepare for a question about problem in the forums?
Answer:
Research and understanding the problem beforehand can better clarify your problem to responders to your post.

2. Why must your first statement in a method or class documentation comment be written in a complete sentence?
Answer:
Documentation about your program is derived from the first sentence of your documentation comments. If it is not in a complete sentence, it may be ignored.

3. What is one of the things an Ant build.xml file must do first to ensure software congruity?
Answer:
The version of the users current package software must be check so that problems may not arise later on. It stops the process there, to alert the user to update first.

4. What character must never be written into programs?
Answer:
The hard tab is a bad character to use. Using it is a bad practice.

5. What is wrong with this statement and why?
try {
FileOutputStream outputFile=new FileOutputStream("good.txt");
OutputStreamWriter outStream= new OutputStreamWriter(outputFile);
for (int i = 0; i < accounts.size(); i++)
{
Object outputAcct = accounts.get(i);
String toWrite = ((Account)outputAcct).fieldData();
outStream.write(toWrite + "\n");
}
outStream.close();
} catch (IOException e) {
}
Answer:
-no indentation
-the catch statement implements no action should the exception be called

6. Why are the anti-pattern happy tests inadequate?
Answer:
Testing for a "happy test" does not check for errors in your methodology. This type of test, does not
account for errors that may result from bad programming.

7. If a problem comes up during the commit process in subversion
what will happen to the changes already made and why?
Answer:
There will be no commit. Any error in any of the transactions will result in a fail for all transactions.

8. The following can cause problems if it is not instantiated.
Which of these programs will find an error with this statement below during an Ant
verify run and why only this program?
PMD/FindBug/CHeckStyle
String foo;
Answer:
FindBug looks for errors such as this in the bytecode of your program.

9. Open Source Software is a recent term. when was it first used?
What group coined it?
Answer:
In 1998 the Open Source initiative created it to differentiate it from the more ambiguous term "free."

10. Give a couple of disadvantages to Open Source Software.
Answer:
-Testing is not as rigorous, and only at the pleasure of the developer; for those that are not working for monetary gain.
-The quality may suffer from bad documentation and hard to understand source code.

Project hosting = effective communication

The internet sure has many uses. But Google groups is not a utility many people know about. I started a project this week to better organize my work with Bato 1.1. If you've been following my blog so far (and you should), you'd know that Robocode is open source software that was created to help programmers get better at coding in java. I've also used different software for packaging my code so that it can be better distributed and for others to modify and improve it if they so wish. Ant the packaging was able to package and debug my code in a very short time. This week the focus was on software updates and project hosting.

Subversion is a system that allows users to update their project without too much hassle. This program updates as you change the code. If you change just one line, it's no big deal. Just commit that one file and Subversion can update it. There's no need to upload the entire file again. It was easy, but it takes time to get used to. I used a client called TortoiseSVN. It does not have a GUI. Instead you create a repository in which you upload or download files. This allows anything within the repository to be uploaded and changed in a short time.

At the other end of the upload is the project site, which I created on Google groups. It's a site that I haven't known about until this course in ICS 413. It's a very valuable development. Because it's free! Through Google groups I was able to create a site in which to explain the development for Bato. The initial setup was really easy. I added members and a discussion group to talk about the topic at hand. It was also easy to create pages for visitors to look at and learn about my project.

A problem I encountered was with the email. I was not able to enable an email send-out to the discussion group in the event that I was to change my package and let members know about the change. These are the links to my project and discussion.
(http://code.google.com/p/robocode-wcm-bato/)
(http://groups.google.com/group/robocode-wcm-bato-discuss)

SVN and Google groups allows users to effectively and cheaply host a project. They are tools that can be very beneficial in maintaining communication between different developers and the public. One thing I know about open source software is this, you have to effectively document you code, as well as provide a package for users to easily download. These two mediums allow for that and makes life so much simpler.

JUnit testing

The experts say that writing tests for your program will probably take more time than writing code for the program itself. I now know that, the experts are right.

This week I started writing JUnit tests to check certain aspects of my Robocode robot. What seemed like a simple task turned out to be a major challenge. Up till now, I've little experience using JUnit. It's almost like learning a new programming language. There are syntax to learn and different ways of doing things. What made it even more challenging was that my robot was limited in ways that made my imagination grasp at straws when the time came for writing the tests. My robot was very simple and that made testing very difficult. What could you test for if there were no calculations to verify?

I found that writing good tests required a look at three different types of testing. They were acceptance testing, behavioral testing, and unit testing. These three types are essential for testing different aspects of a program. For instance, acceptance testing is a process that requires you to check that the main objective of a program is fulfilled. The behavioral testing requires that an intended action of the program be executed and work reliably. And the unit tests are to check if a certain block of code (like calculating the hypothenuse) correctly outputs the right values.

This was my mindset when I started writing tests for my Bato.1.1. Here are some of the tests I wrote and an explanation. The package with these tests and my robot source code can be downloaded here.


TestBato1

This is an acceptance test to check whether Bato can defeat the robot Crazy ten times in a row.

TestBato2

This is another acceptance test that checked if Bato can defeat the robot SpinBot at least half the time.

TestBato3

This is a behavioral test that checks if Bato is too close to the enemy. It determines through ten rounds if Bato is ever at least 20 pixels away from the enemy robot.


TestBato4

This is another behavioral test that checks if Bato is stuck in a corner. Based on my fighting strategy, I have observed that this could be a problem. So this is a useful test.

With my robot being so simple and lacking in calculations I could not come up with anymore test cases to writeup. The final step was to verify my tests and see if I covered all the possible cases. It was up to the program Emma to tell me if I could do any more. Here are the results.
Emma Coverage summary
class: 75% (6/8)
method: 80% (35/44)
block: 65% (440/682)
line: 64% (112.8/176)

Would any developers out there like to comment on these percentages and how I did?