Building Blocks

As I mentioned in a previous post I’ve been working on getting the Android application, Shuffle to synchronize with Tracks.

Now that the work has continued this post describes how this feature of Shuffle works. This feature is released with version 1.4.0 of Shuffle and will be available on the Android Market. Special thanks to Andy whom put up with my loads patches.

This feature affects no other features in Shuffle, it simply allows the synchronization between the two systems. If you never configure the synchronization feature it will never affect you.

Configuration

To configure Shuffle to synchronize with tracks start the Shuffle application.

Press menu, and select settings. Select the option called “Change synchronization”

This will open the settings file. Here you can enter the URL to your Tracks installation, username and password. You can also specify the settings for the background synchronization. Simply change the combo box between the different settings.

There is some validation in the settings screen. If you enter a invalid URL the text will change to red to display this.

When you save your settings they are validated by trying to download the contexts from Tracks. If Shuffle cannot get any content from Track with the specified settings it will not save them, but instead display an error message saying that something is wrong with them. You can always cancel.

The Synchronization

Once Shuffle is configured to synchronize with Tracks. You will have an extra button available in the menus across Shuffle. Pressing this will start the synchronization process. To notify that a synchronization is in progress Shuffle will also add a notification message during the synchronization. This is to notify the user that Shuffle synchronizes when doing background synchronization. If you click the notification Shuffle will display the synchronization view.

The synchronization synchronizes the entities in Shuffle in the following order: Contexts, Projects, and Tasks. During a synchronization Shuffle will look at the modification date and select the version of the entity that was latest modified, and merge this entity with the local entity or remote entity, which ever is updated.

Tracks only accept Tasks that have a context set, currently these tasks are excluded from the synchronization process. If you have such task a message is displayed at the end of the synchronization process.

I did some open-source work last week. I created a synchronization option in the Android program called Shuffle. Allowing it to synchronize with the web tool called Tracks.

Here is a description of how to use the synchronization in Shuffle.

Configuration

Open the settings menu, select the Change Synchronization option.

Specify your Tracks installation URL, username and password.

Make sure that the URL is correctly formatted and that there is no ending slash in the url:

this is wrong: http://my.gtdify.com/

this is correct: http://my.gtdify.com

Usage

On the menu available in most screens there is a button called synchronize. Click it and the synchronization starts. It will first synchronize the contexts, then project and last the Tasks.

Details of the synchronization

The synchronization will try to reduce duplicates that might occur between Tracks and Shuffle. This is done by looking that the description of tasks and the names of contexts and projects.

The synchronization works with a server wins, modification date oriented approach. Should there be a conflict the latest version will win, and in it will try to take as much detail it can from Tracks.

Also, using the “Delete completed” option removes the tasks from Shuffle. This means that the synchronizer wont find them and can’t mark them as finished in Tracks. If you use this synchronization I recommend letting the synchronizer take care of the “cleaning up”. This will be done the second synchronization that a task is complete on.

That is, if you complete a task and synchronize, both tasks will be in both systems as completed. Synchronize again the the task will be removed from Shuffle,  but maintained as completed in Tracks.

Happy new year everyone!

To celebrate I’m posting this screenshot.

I’ve been using Shuffle on my HTC Hero for a while now, and been lacking the ability to synchronize it with a online desktop-enables solution.

Well, the above screenshot is the result of what I’ve been doing these last two days. It’s Shuffle that’s synchronized its contexts with a Tracks installation. Still a lot to do, probably a day or three at least. But it’s looking promising.

Happy new year!

Funny thing. Some might remember my how I work with code, where you keep a list of issues you figure out as you work with the code.

Apparently Kent Beck presents this as a pattern called Test List.

I’m trying to embed it below, we’ll see how it goes.

Btw- if this embedding thing is more annoying then helpful, please let me know.

Roughly 1½ year ago I produce a plugin for team-system to allow me to report bugs quickly though as I’m working with the code. The idea behind it was from the Fogbugz intoruction video where I think its Joel Spolsky who says something along the lines of “it should take less than 30 seconds to report a bug, else the lazy developer wont do it.”

The resulting plugin was a short-command that started up a UI with a single textbox on it. I wrote the “bug”, and it created an bug item in Team System with my specified title. It also made sure to “record” the context of where I was in the code when I wrote the item. In this case, file and line-number.

In a previous post I discussed how to get things done with teams.

Consider having such a plugin to your IDE that will report the item generated to a central inbox, central for all developers. The item could be a bug, it could also be a suggestion for refactoring, request for more tests, idea for a new feature and much much more.

With such tooling in place, a team could quickly shed some light on issues that aren’t directly related for the delivery of the current iteration. But more related on the values of the team or the ongoing quality of the code product. The issues can be reviewed and managed during a weekly meeting, resulting in product backlog items, sprint backlog items, discussions, meetings. Or just a sense of common values within the team.

I wrote a blog post about how I work with code. The basic idea is that I record actions that I need to take as I work with the code in a format that is readable by the other developers in my team. In case I get run over by a truck they can see where I took off. Also its a way to record what and why I’m doing as I’m progressing through code written by someone else.

I got a response from a former colleague Anna who claimed I wouldn’t need to do it if I had automated tests. Even though Automated tests doesn’t have much to do with personal productivity at first glance, a recording of something that needs to be fixed could be a unit test. If developers run the tests often they are in my shelveset and they can see which pieces of the code I perceive bugs in.

In fact this is exactly what is being done as I work with TDD. Giving support to the fact that TDD can increase the productivity of a developer, following the same ideas presented in Getting Things Done.

Tests however doesn’t record suggestions for design improvements or actions such as “Ask x about icon y”. At Least not as far as I know.

With this concept of quickly creating new tasks and with the GTD and How I work with code ideas. An idea for a new tool popped up in my head.

The tasks that I create based on working code, are cluttered with my own opinions. With the Getting Things Done approach we could have an inbox with Action times created as team members work with the code. In a Weekly review each item in the Inbox could be manage, prioritized, discussed. Some items result in items on a sprint backlog, others simply result in other team members explaining parts of the system to each other.

This weekly review could be conducted outside the normal delivery cycles, as they are partially meta tasks for achieving a common mindset of how and what should be developed. The result could be new features, refactoring, extra testing, reduced bugs etc.

In Getting Things Done, David Allen discusses a work flow of how to handle things you need to-do. Now when I work at a coding task I often find places that could need some refactoring love, or needs to change in some way. There might be potential bugs, violations of DRY and all that.

What I’ve seen so far is that some developers tend to fix these “issues” as they find them, working towards a sort of zero-deficiency or a “if I cant read the code, chances are someone else wont be able to either”  motivation.

Working with code in this manner can have some interesting side-effects. To name a few.

• It takes longer to resolve a specific task
• It could result in team conflicts a some developers perceive written code as “theirs”
• It could introduce bugs, if the original intent of the code isn’t captured by tests (not even 100% code coverage will guarantee this).

What I like to do is to finish the task I’m holding as fast as possible. The reason for this is simple; others are relying on it. But while I finish the task I notice these things that needs to be changed, fixed, or clarified. Code items that require attention in someway. What I tend to do instead is to create a new Task to represent this change.

Creating a new task as several benefits.

• It allows delegation and parallel execution of code changes
• It allows the task to be discussed by the team
• It allows me as a developer to finish my current task, without having to fill up my brain with new things to-do
• It allows me to finish the task faster
• It allows the new tasks to be prioritised by the team
• It reduces the chances I need to context switch
• It allows me to work on just one task

Now or the last one I recommend reading Eric Brechners blog post about making your world easier

In Getting Things Done there is a work flow describing how to work with Actions. I found a copy of it at Metamagazine.

Getting Things Done Workflow

Im not going to get into the details, read the book instead, but what I want to do is throw out a thought. Most code items come into the “Do It” category of items.

I just started reading “Getting things done” – by David Allen. I’m roughly 25 pages in, but now I have to stop to write this blog-post just to clear my mind.

The reason for why I started reading the book is that I found Tracks though mor.ph and started looking at their system earlier this week. The goal was to get some inspiration for creating more productivity enhancing features in RemoteX Applications. Tracks was interesting enough but I wanted to read the book to get some better insight into the ideas behind it.

The way Scrum, Kan-ban works is similar in the sense that it is a way to organize Actions, things need to be done.

What I miss so far from Getting Things Done is that the items on the team boards that I’m working on is also a part of the things I need to get done. It feels as if I’m missing a dimension. I felt the same way about the Tracks software earlier this week.

The book it self has already resulted in 5 blog posts, this included. Ill add one when I’m finished to summarize.