Building Blocks

I just set up a build server for my Grails project. I chose Hudson since it was the one mentioned to work well, and it did. I’m quite happy with Hudson thus far. It hasn’t crashed (actually it crashed my browser once, more on that later), and been very easy to work with.

First of I installed it on my Ubuntu machine in the closet. It was straight forward installed using apt-get as per instruction. This was a clean install and the first use of that Ubuntu installation for any kind of development work.

With Hudson installed I started going through its configuration. I knew there was a Grails plug-in so I figured I had to install a lot more software to get things going.

I found the plug-in page, marked the Grails plug-in and installed it.

I created a job, configured it to fetch the code from my subversion repository. Already I could run the job, and watch the output from my normal development machine.

I love the console out page, compared to watching the build-logs and build progress in MSBuild this page gives good feedback, doesn’t crash that much, and works as both progress and log all wrapped up in one.

With the job running I pinpointed the missing parts in the job. Running the grails targets. So it was time to configure the Grails Hudson plug-in. It required the Grails installation path, so time to set up the libraries. Download and install Grails, update the plug-in with the path.

When running a Grails job the first time you need to run the “grails compile –non-interactive” command. This will install all other plug-ins as it is the Grails way. This will make plug-in specific commands available.

I ran it first without the –non-interactive flag, which caused the app-engine plug-in installation to ask questions. Hudson didn’t mind, but my browser in which I was looking at the console out didn’t like it. It kept updating the page with “do you want to use JPA or JDO” questions, until it finally crashed.

In my case I wanted my build to upload the compiled application to Google AppEngine. I added the APPENGINE_HOME environment variable to Hudson’s main configuration. With the APPENGINE_HOME variable set to my newly downloaded SDK.

This is what my grails build target looks like:

To get the deploy command to work I needed to add the login details for app-engine. After some research I found that the details are configurable. All you have to do is add the following to you Config.groovy file in the grails project.

google.appengine.email = "email"
google.appengine.password ="password"

But with the correct email and password of course. In my case I used the user I’ve created for sending emails as the user that will deploy using the build.

I now have a working build that deploys to AppEngine. What I’m currently missing are running tests, as I’m still searching for a functional testing framework that will run as a Grails plugin with the AppEngine plugin. None of the two (easyb, functional-testing) Grails plugins I’ve tried so far have worked.

So I’ve started some experiments on VS2010 RC1. I plan to post more about them later (MVC.Net 2 things mostly). But I noticed when I was going through the different project types that there is a F# tutorial with VS2010.

I though Great! Really nice idea to have an easy accessible introduction to the programming environment and language available directly in the product.

However I was let back when I started it this weekend. It’s not a tutorial, its not even an introduction. It’s just a cheat sheet for the F# language syntax.

It’s not a bad cheat-sheet. I got mostly everything I needed from it. But I just wish they did more with this. Or just move the cheat sheet online, and reference it. This is just something in between.

So I’ve done my first programming for Android phones and thought I’d write a blog post about the experience.

Programming for Android is a bit different from working with the Compact Framework. The abstraction level for the Dalvik applications is somehow high than the Compact Framework application. One difference for example is that there is no main() method to start your application from.

Central for an Android application is its Android Manifest file. This file describes all services and activities available in the application. This is an XML file that helps describe your application to Android, what it’s capabilities are. Each Activity can then be used as an Entry point, but the manifest also describes Services, Content Providers and Broadcast receivers.

What this gives you is a set of loosely coupled components that interact with each other using Intents, that are passed on a system wide message bus. This allows applications interact not only with central parts of the phone, but also with other applications. Which is quite interesting.

Developing in this manner gives you a set of conventions to follow. I feel that they have managed to find a set of conventions that gives direction in the design of the application, but doesn’t confine you.

The SDK also gives you a set of base classes (template method pattern style base classes) that helps you develop common tasks in a standardized way. An example of these are the Task classes that provide threading and scheduling support. I quickly fell in love the the AsyncTask for example.

Android protects the foreground UI thread quite extensively, making these constructs for doing background work important. For example your not allowed to construct or access any UI elements on background threads. This can be handled by using a special Looper construct that effectively divides your Thread code into different parts. One setup part that’s allowed to access, or setup UI components. And one Loop part that does the actual work.

I worked mainly in the Emulator. The emulator feels fast at first, it takes a while to boot up but is quite responsive once booted. That is until you start typing using the computers keyboard. When you do this the emulator feels slow. Apart from a few issues with the emulator loosing “internet connectivity” when my computer Hibernated.

Now it’s time to mention a tool that’s quite helpful when working with Android applications. It’s the adb.exe logcat tool available in the Android SDK. This tool allows you to watch the result of log statements in runtime, and shows stack traces for those errors the occur but you’ve partially managed to take care of (ignored).

This being said there are some things I’m missing when comparing to working with the Compact Framework. For example, working with XML is much easier in the Compact Framework. I hate having to write my own parsing and serialization code, and there are more tools to help me generate code for doing this in the .Net framework.

Also using the HttpClient in the Android SDK is unnecessarily hard. Https works only with some special glue code. And as far as I can tell everyone seems to simply accept any certificate instead of providing support for showing a UI where the user can accept an unknown (self-signed) certificate.

This is all I can think of right now (this is the second time of writing since I had a crash when I tried to post it…). If there are any questions, please ask them. Hopefully they’ll help generate more knowledge about Android development.

Given my recent combining of Tracks and Shuffle. An interesting thing happened. Something that happens when you combine two products so that they inherit features from each other.

On Shuffle’s issue list there are a few items currently regarding repeating tasks, and the ability to hide a task for a period of time. Tracks has these features, since Shuffle can synchronize with Tracks, Shuffle now also have these features. That is if you choose to synchronize with Tracks.

I’ve done a few integration projects thus far. And the ones that are truly successful are when they take the aspects and features of both applications into consideration, to create a win-win scenario between the two applications.

Here is another recent example. At RemoteX, we recently integrated a system that handles the ordering of materials, goods, equipment etc. In essence this integration feature means that you can go to a retailer, order goods, specify the order they should tag the invoice with. End result, RemoteX automatically adds the goods to the application and if possible attaches a copy of the invoice to the case. Ready to be billed to the customer. Since the other system has integrated with almost all resellers of service equipment in Sweden, the daring customers running this set-up can, at least in theory, eliminates the need for keeping stocks of equipment or goods in house.

If you understand where these synergy effects can show up you can also align the integration so that both applications maximizes the gain of integrating with the other system. This is important to think of when designing an integration, how do we achieve the maximum win-win?

My girlfriend has downloaded a solitaire application to her HTC Tattoo. While solitaire isn’t anything revolutionary it has an interface feature which got me thinking.

Se what the interface does is move those cards that it is sure that the next step is to move. So if I for example get an Ace, it moves it to it’s correct place at the top four card stacks.

This feature got me thinking about mobile phone interfaces. In applications in general, but even more so in the mobile context, you want to reduce the amount of interaction done with the user interface.

What if we can “guess” the input of the users input in the interface even in business applications?

We have hints in the domain, such as if you select this type of project you cannot register this type of time on it. You don’t register vacation time on a customer’s bill if your a consultant. Well, at least not that often.

These hints are common constraints, you might not want to enforce them by disabling the alternatives available. But you can check them and see if for a given input if there are any “assumptions” you can make about the next input to be made.

To take this one level further. We have the application data. We can order things in the UI according to a statistical analysis. Given this value in a combo box, this other value has more than 80% chance to be set in the other combo box. In such a case we can “guess” that this is the input the user would want to enter, and worst case is that he has to change it.

The cost of changing a value in a combo box is equal to setting one in the first place.

Now statistical analysis of data can often be costly, and typically not something you would want to do in a UI scenario. But what you can do instead is to calculate the statistical values into a decision graph (I think of it as similar to a Markov process for those whom have studied them). We can calculate this graph every evening and have a graph available for all input for the next day. Traversing the graph is now a simple algorithmic exercise.

Regarding the previous post, Shuffle 1.4.0 with Tracks synchronization is now available on the Android Market.

I had it pointed out to me at the end of last year that I use Mocks too much. I isolate the class under test more than I might need to do. Isolation of a class has the most value at service boundaries. If other classes can safely be included in the test without side-effects, I’m actually testing more than jus the class under test.

This is a bad thing, right? No. Not necessarily. The tests purpose is to prove that the code solves it’s intended purpose. If by including more of the system that this piece of code interacts with, the test will be more tightly coupled to the actual use of the class.

If I isolate the class, non-API breaking changes in other classes might cause the requested system behavior to fail, but my test which tests the class in isolation will still pass. The purpose of my tests should naturally be to detect defects earlier.

As I considered this I went back to the places in our code-base where I feel TDD has really really helped me. And sure enough, almost no mocking in those tests, relying instead on actual objects. For me, this was sort of an eye opener.

How do I work without mock’s then?

One example is to use inheritance. If I isolate all calls to system-boundaries to a single method, I can inherit from the class under test and override that system-boundary specific piece of code. This allows me create “mocked” version of the class without the need for mocking libraries.

This is called Test-specific subclass. Thank you Patrik!

This method is even applicable to legacy code where mocking isn’t applicable.

Another example would be to use actual objects all the way, if possible. For databases for example you could create a temporary testing database if you have access to a database server. Depending how you access your data you might even be able to have an in memory database instead of an actual database. While this might mean you need to implement a test-class instead of mocking it. If the API doesn’t change all to often it might save you time compared to mocking.

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!