Welcome to RoboTracker

1. The User may define stories; each story is a high-level description of something that needs to be done.
2. The User may define tasks; each task is a low level description of something that needs to be done in order to complete a story.
3. Each task has a name, an estimated completion time, and optionally a parent story
4. The User may select a "current task" (system tracks time spent on each current task).
5. The User may view how much effort has been expended on each task, and the percent of actual effort relative to estimated effort.
6. Report type: load-factor: calculated for a subset of tasks over a specified period.
7. Report type: activity log: lists user's task-switch events
8. Report type: expended effort: total time spent on each task, per day, or within a user-defined period.
9. User may choose a subset of tasks for inclusion in a report.
10. Hierarchical view of stories and tasks.

Screenshots are available, and you might even be interested in a UML overview of the internals of the system.

The "grand vision": Subsequent versions will become a comprehensive tool to assist the Tracker role on an XP project, allowing the creation of projects, iterations, stories, and tasks in a sensible hierarchy; role-based access (developer/tracker/customer); developers assign tasks to themselves after creating and estimating them; reporting on every aspect of a project, using gathered data to attempt predictions about the future of the project.

RoboTracker is hosted at http://savannah.gnu.org/projects/robotracker/. It is released under the GNU General Public License.

Contact: robotracker@conandalton.net.

• The whole task estimated-time/actual-time comparison concept was Luis' idea, although he wanted me to do it on paper, which horrified me; therefore this project is largely his fault ...
• Thanks to the people at Savannah for hosting this project
• All editing is performed using Emacs. The One and Only
• UML diagrams are produced using ArgoUML
• Screenshots and diagrams are caught with The GIMP, a.k.a. the Emacs of image editors
• This project would be no fun at all without Linux
• Or without Java, for that matter
• RoboTracker also uses The BeanShell, a java-based scripting language; JUnit (essential if I want to claim to have anything to do with XP); both of these are used in the test subsystem.
• If it wasn't for Ant I would be using hopelessly tangled makefiles instead

version 0.7.8: 2002-08-22

• Fixed division-by-zero error in Load Factor Report when total effort is zero.
• Reports now include the task which was selected at the time of the beginning of the report. This task was previously ignored, and the report would only consider tasks that were selected after the beginning of the report.
• Added "Task Status Report" - gives estimate accuracy results for closed tasks.
• Added "Effort Per Day Report" - like Expended Effort Report, but broken down per day.
• Closed tasks are not shown in the task list.
• No hard-coded database URL in unit tests.
• Created separate "How To Build RoboTracker" page.
• The tests invoked from robotracker-test now create the database schema. Previously, they assumed the schema was there, so it was necessary to run the application before running the tests ... thus confusing everything and everybody.

version 0.7.3: 2002-08-10

• uses BeanShell for scripting functional tests
• removed silly "Stories" dialog, "create story" button is now in TaskList window
• Big internal refactoring. No new features. The refactoring was needed so I could make UML diagrams that were reasonably (a) honest, and (b) unembarrassing. In fact, the refactoring was needed anyway, but the sense of embarrassment with the previous state of the code was the primary motivator.

version 0.7.2: 2002-07-30

• Create Task Dialog allows user to select a parent for the new task from the list of all Story objects.
• Popup window shows hierarchical relationship among stories and tasks. Although this is nice to look at, it does not offer any useful function yet.
• Removed Castor JDO. Using Castor was not the simplest thing that could possibly work, nor was it certain that I was going to need it. Castor introduced the following complexities:
  1. No support for sql type "TEXT", and with MySQL not supporting CLOB, there was no way to save large text items (ie, Story text) without an annoying hack to serialise the String into a byte array, making Story.java ugly and cluttered.
  2. Obliged to support yet another database connection info file ("database.xml") ... either the user has to write this or the system has to create it from the other file that the user had to write anyway ... more work for you or more work for me!
  3. Obliged to support a mapping file. Two descriptions of the data are essential: the Java objects and the database schema. The third is either the SQL to access the db directly, or a "mapping.xml" file to let Castor access the data. Old fashioned SQL seems to be simpler and to offer fewer restrictions.
  4. The long-term transaction issue resulted in some messy code. When I wanted to save a TaskSwitch, I had to (a) open a transaction, (b) get the task from the task switch and tell Castor to load it explicitly in this transation, (c) set the loaded task as the task property on the task switch, (d) tell Castor to create the TaskSwitch, (e) close the transaction. It seems that steps (b) and (c) should not be necessary; the force me to load an object that I already have, unchanged, in memory. I want to use the object that's already there ...
  5. The mapping file is specified as a URL within the database file; I don't understand this, because although the user needs to supply database connection information, the user doesn't care about, and shouldn't need to know anything about, the mapping information. The mapping should be a separate JDO initialisation parameter.

version 0.6.4

• Ability to create a report based on a subset of tasks
• Uses Castor JDO instead of custom SQL to access the database. In theory, this makes future development much simpler. Let's see :))
• Added "Load Factor" report.

1. RoboTracker uses Java version 1.4. Make sure you have a Java 1.4-compatible JVM installed on your system.

2. create a database for the application using your favourite database application (for example, MySQL).

3. Note the jdbc string used to access the database. For example, if you create a database called "robotracker" on your own machine using MySQL, the jdbc string will be "jdbc:mysql://localhost/robotracker"

4. create a subdirectory of your home directory called ".robotracker"; this directory will be referred to below as the init directory.

5. in the init directory, create a file called "init.properties" with the following content (change the values as appropriate):

         db.driver=org.gjt.mm.mysql.Driver
         db.url=jdbc:mysql://localhost/robotracker
         db.user=robotracker_user
         db.password=robotracker_password
       

   RoboTracker uses this file to connect to the database.

6. unzip the RoboTracker distribution file anywhere you like

By default, RoboTracker looks for its "init.properties" file in the ".robotracker" directory you created in your home directory. If you specify a command-line parameter, however, RoboTracker will interpret it as the name of a directory to use instead of the default. This may be useful

... anyway, the feature is there.

There are two sets of tests - the unit tests, and the functional tests.

The Functional Tests

The Unit Tests

1. From the shell prompt type

   mysql -u root

   (note that you don't have to be root on your system to do this; MySQL users and system users are separate entities; if this is the first time you have used mysql on your system, you won't even have to supply a password; please "info mysql" at your shell prompt to learn more about securing your mysql installation)

2. From the MySQL prompt type the following:

   create database robotracker;
grant all privileges on robotracker.* to robotracker_user@localhost identified by 'robotracker_password';

3. To verify the database was created, type show databases; - MySQL will draw a single-column table listing all existing databases on your system.

4. To verify the user was created, type

   use mysql
select * from user;

   - you should see a line containing "robotracker" in the "db" column, and "robotracker_user" in the "user" column.