Release planning

February 26, 2007

Yesterday was TinyUML’s “Gogo” release day, my first file release of the project and its second milestone (the first being version 0). At the present date (February 26th, 2007), the software is not ready for use, it will take at least four weeks (until the “Quina” release) that the functionality will have reached a state where I can start using it for simple tasks. The reason for my early file releases is to have an additional tool to track the progress over time. Because they do not contain useful functionality, I decided not to give the releases version numbers and not to announce them on any official news board either. All releases will carry code names from “Final Fantasy”, this is a huge repository of names and outside of Nintendo, Square Enix is my favorite video game producer.

The advantage of being the single developer and the first user on the project is that I can focus on what is important to me and I do not have to schedule meetings to discuss the features with myself. The disadvantage is that I have to kick my own butt to push forward. My personal experience is that I work more efficient when there is a schedule, there needs to be at least a small amount of pressure. That’s why sticking to a release schedule is so important for me. Being my own butt-kicker, I can also decide what’s going to be included in the releases (and deliberately move them to a future release if I like, ain’t that great).

The next milestone will be the “Kupo!” and “Moogle” releases, where I will focus entirely on the editing system. It is interesting to see how much ground can be covered just by implementing the two UML elements Package and Dependency, packages are special, because they allow nesting (the Composite pattern instantly pops into my mind). I will add the UML Note to this release, because it will introduce a multiline element to the game.


Project setup

February 23, 2007

I find it good to work in an environment where standard tasks are sufficiently automated. Having a good development environment from the start keeps your head free for the important work.

IDE

My IDE does a lot of the tasks that I do frequently during development: building, testing, running, debugging, profiling, documenting, that is integrated all pretty well. There are a number of good IDE’s for Java, the most popular ones seem to be Eclipse, NetBeans and IntelliJ IDEA. While I used to work mostly with Eclipse, I find myself working with NetBeans more and more. They are both pretty good, but for my personal needs, the overall quality and integration of the available plugins is simply higher on NetBeans.

Version control

Managing the project without a version control system is one of the things I would not even think doing anymore. It serves as a repository to store all changes to the files, and when working in a team, it provides mechanisms to keep the team members work in sync.

A few years back, when I was a consultant, I found some places who had a “human concurrent version system” or H-CVS. It supported a very simple locking mechanism that prevented two users to work at the same time. One developer simply told the other one that he was working on a particular file. Versioning was done by creating archives of the state every day. This of course only worked when the developers worked in the same office. Looking back at it, it sounds like editing source code with Microsoft Notepad. Well, I know several people who even do their editing with Notepad today, so I it is very likely that some form of “human version control system” still exists today.

I practically store all kinds of documents I create in a Subversion repository, it simply makes me sleep better: I can keep track of my changes and I have a central point for backups.

Maven

Once the project has grown to a certain size it becomes more and more difficult to keep an overview. In my opinion, it is a good idea to include code measurements from the start. I usually include these tools

  • Cobertura
  • PMD
  • JDepend
  • Checkstyle

Cobertura is a code coverage tool which measures which parts of your code are covered by test cases. While even a hundred percent coverage is often not desired, reasonable and even does not guarantee a bug-free system, it helps me finding the holes in my test cases. It should be mentioned that Maven includes a standard plugin for another coverage name Cenqua Clover. It seems like a good tool, but it locks you into a 30 day trial period. I don’t like this kind of things, to be fair, they seem to let OpenSource projects use their tool for free. For my purposes, Cobertura is great, I wished it had a project overview (LOC, NCLOC, number of files, packages, classes, methods) that EMMA or Clover do, though.

PMD is a tool for measuring “good coding practices”, in general it helps me spotting potential problems in the code, Checkstyle is similar, but has a focus on code formatting. They both complement each other pretty well.

JDepend measures dependencies between classes and packages and calculates some fancy numbers that are related to these inter-dependencies. This tool supports the developer to create highly cohesive and loosely coupled systems. One of the measurements I find most useful is the detection of cycles between packages.

It is of course possible to include these tools in an Ant build file, but it takes quite a bit of effort to integrate them and creating a consistent output report at the same time.

This is all covered by another great Java build tool: Maven 2. Given a minimal description of the project, it automates the build process and creates a consistent overview in form of a web site. In the past, I had used Maven 1. I hated it. Even though I could clearly see its usefulness, it simply felt clunky and patched together. When Maven 2 came out, I was even more disappointed at first – many of the plugins that I was used to on Maven 1 did not exist for quite a while. The situation has improved a lot since that time, working with Maven 2 “feels” a lot better.

Once the setup is in place, building is as simple as typing in a command or invoking it from within the IDE.

Some notes: While setting up my projects I found some issues with the Maven plugins that I resolved like this:

1. There seems to be a bug in the Cobertura-Reporting plugin, which is used from Maven by default. For some reason, it can not find the instrumention file. However, there is a workaround, simply specify an explicit version number

...
<reporting>
<plugins>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<!-- There is a bug in version 1.8, specify 2.0 -->
<version>2.0</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<targetJdk>1.5</targetJdk>
</configuration>
</plugin>
</plugins>
</reporting>

I use JDK 1.5/1.6 as my default development, Maven’s and its plugins default assume 1.4, so there need to be changes made to the pom.

For the Java compiler :

...
<build>
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
</build>

For the PMD plugin:

...
<reporting>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<targetJdk>1.5</targetJdk>
</configuration>
</plugin>
</plugins>
</reporting>


Roadmap to happiness

February 21, 2007

When starting a new project, I find it important to create an infrastructure first. I avoid the term “framework”, because I think it is used too extensively.

Preparation is everything, this includes proper research. Before I actually started the project, I implemented the UML 2 metamodel core to get a feel. I also wrote a prototype for graphical editing to make sure my skills are up to the task.

After the kickoff, I had asked myself how I would plan the releases. While working actively on the Z-machine preservation project, I had a release every two or three weeks, which worked pretty well, as it kept me focused on the goal and forced me to define feature sets that I could implement in the short periods. I’ll try to adopt this for TinyUML as well and see how it will work out.

Two weeks after the kickoff, I am pretty close to my first source code checkin and preliminary release code-named “Gogo” (see roadmap). I decided to name the releases after characters from the Final Fantasy series. The first three releases will have the purpose to stabilize the project structure and design rather than rushing a lot of features out and introducing a ton of bugs. These three initial releases probably won’t do anything useful to anyone but me, so they will not carry a version number. The “Gogo” release actually will include much more than I expected, a working drawing and event system, an initial user interface and even an SVG export via Batik.

Still some way to go to a “Dog Food” release though, the “Quina” release, which is planned in six weeks will try to deliver something that I can probably start to “work” with. Well, one who played Final Fantasy IX before knows, that “Quina” eats about everything….


Version 0

February 13, 2007

In software development, everything you can learn from means progress. It is important to keep motivation high, so iterations should be small, with goals that can be reached quickly in order to get feedback fast. The goals of version 0 was to learn about the UML 2 metamodel, to establish the foundation of the structures, a basic diagram editor and a preliminary user interface with a working event system:
Version 0 screenshot

UML 2 structure diagrams are complex and include a lot of elements, but in terms of graphical elements, it’s boxes, lines and text. So it’s not necessary to cover a huge set of elements from the beginning, but to include a minimal set that is sufficient to learn from. I decided to include packages and dependencies in this minimal set (even though dependencies are not in version 0). From the view of graphical layout, these two elements cover the main challenges, and from the view of the model, it covers namespaces and nesting.


Kick off

February 13, 2007

For a portion of 2006, I was working on the assignment to my SCEA (Sun Certified Enterprise Architect) certification. This assignment requires to provide the architecture of a software system as a number of UML diagrams.

Needless to say, without a UML tool it is difficult to maintain consistency, so from the beginning, I sketched my design using the “Community License” to a well-known UML tool. “Community License” seems to be a popular euphemism in the UML business, in general these are heavily limited in some way, making the tool practically unusable for projects of reasonable size. In this case, I purchased a license, so I could at least save my work. Unfortunately, I soon found out that the tool suffered from two fundamental problems:

  1. it’s slow
  2. it’s unreliable

As soon as my design reached a certain size, I could barely edit my diagrams because of the slow performance. On top of that, the software had the tendency to crash unexpectedly and write invalid data files. I would not have expected that from a software product where some editions cost thousands. Unfortunately, it is not the only example.

After wasting a month’s work only fighting with the shortcomings (when you pay for it, you try to use it, right ?), I decided to give up on it and to cash out a little more money to buy a different software. I evaluated a total of six software packages and decided to purchase the “Personal Edition” of the one that appealed to me most. It is fast, reliable, powerful and on top of that, it’s written in Java.

My overall experience I gained from the evaluation of free and commercial UML tools was, that there is not a single one that covers what I think a “Personal Edition” should include. Also in my opinion, a “Personal Edition” needs to be free, I do not think it makes any sense to milk users who use a tool for education or private purposes.

After the Z-machine Preservation Project , TinyUML is the next larger spare time project that I am doing. It first and foremost will scratch my personal itches, but if there are a number of people with the same fleas, feel free to use my scratcher.