Nick Carroll

Estimation Deck is now back in the App Store. Estimation Deck saves you from carrying around a deck of cards for your next Agile estimation session.

Estimation Deck provides a set of fibonacci numbers that can be used during an Agile estimation session. This application allows the Agile professional to swipe through the deck of cards until the desired estimate is found for the proposed story. Tapping on the estimate card will flip the card to hide your estimate from your colleagues. Tapping the back of the card will flip the card again to reveal your estimate to the group.

Use the settings to switch between Fibonacci, t-shirt sizes, and powers of 2 decks.

Find out more about Estimation Deck

Checkbox has been unleashed upon the masses and is now ready for sale in the App Store.

Checkbox allows you to take a photo of your task list, add checkboxes to the photo, and track the tasks that you have completed.

Use Checkbox to quickly capture your shopping list on your fridge, the meeting actions jotted on your notebook, or the menu of your favourite restaurant. Then turn the photo into a checklist by adding checkboxes to items in the photo that you want to track. Simply tap on the checkboxes to keep track of tasks that you have previously completed.

Find out more about Checkbox

Core Data natively supports attributes that are of type NSString, NSNumber, or NSData. You can however use other types with a bit of extra work. If you have an attribute that is a scalar value such as BOOL, you can have your managed object persist it by first converting it to a NSNumber. For example, CheckBox is a NSManagedObject with an attribute called checked that is of type BOOL. BOOL in Objective-C can easily be converted to and from a NSNumber.

The header file contains the BOOL attribute for CheckBox.

// CheckBox.h
#import 

@interface CheckBox : NSManagedObject {
}
@property(nonatomic) BOOL checked;

@end

The implementation file contains a PrimitiveAccessors category for the underlying primitiveChecked value, which stores the checked value as a NSNumber. We then override the accessors and mutators for the checked attribute to convert the BOOL value to and from a NSNumber.

// CheckBox.m
#import "CheckBox.h"

@interface CheckBox (PrimitiveAccessors)
@property (nonatomic, retain) NSNumber *primitiveChecked;
@end

@implementation CheckBox

- (BOOL)checked {
    [self willAccessValueForKey:@"checked"];
    BOOL isChecked = [[self primitiveChecked] boolValue];
    [self didAccessValueForKey:@"checked"];
    return isChecked;
}

- (void)setChecked:(BOOL)isChecked {
    [self willChangeValueForKey:@"checked"];
    [self setPrimitiveChecked:[NSNumber numberWithBool:isChecked]];
    [self didChangeValueForKey:@"checked"];
}

@end

I have recently joined a newly formed team developing Android applications at a large telco, and I am pleased to announce that we are using Gradle for our builds. We are using Gradle with the Android plugin, and instantly we managed to build a simple application, run tests, and have it installed on a device. Our build script simply looks like the following, which is all that is necessary to use the Android plugin.

buildscript {
  repositories {
    mavenRepo(urls: 'http://jvoegele.com/maven2/')
  }
  dependencies {
    classpath 'com.jvoegele.gradle.plugins:android-plugin:0.8'
  }
}
usePlugin com.jvoegele.gradle.plugins.android.AndroidPlugin

Of course this is a rather simplistic script, but it does everything I need it to do right out of the box. The Android plugin provides a number of tasks that allow you to build, test, package and sign your application. You can even install the packaged application on a device or emulator by running gradle androidInstall. Make sure to set the property “adb.device.arg” to “-e” for a running emulator or “-d” for a connected device.

There is also support in Hudson to trigger a Gradle script. Hudson has a Gradle plugin that can be installed from the Admin console, and allows you to directly trigger a Gradle script in your project. Otherwise you can create a simple shell script to call the Gradle tool from the command line.

It is also worth noting that both IntelliJ and Eclipse provide support for Gradle and the Groovy syntax. That is if you don’t like using the command line to trigger your builds.

Gradle has allowed us to spend less time setting up our build and continuous integration environment, and more time on actual Android development. Our team has benefited greatly from this boost in productivity.

My latest iPhone app called Illuminate is now available at Apple’s App store: http://bit.ly/bByrgy.

Illuminate is a free application that turns your iPhone’s screen into a light source. I generally use it when trying to read a menu at a dimly lit restaurant. Hopefully you will find it useful too!

A while back I wrote about achieving continuous deployment with one-click deployments. I didn’t provide an example for that post as I mostly wrote about why you need to achieve continuous deployment. Here I will follow up with a simple example of how you can achieve continuous deployment.

Continuous deployment is quite easy to setup if you are using a typical Maven project structure and Bamboo as your continuous integration tool. Also I am assuming that you want to deploy your application to a tomcat server.

In your pom.xml file add the following configuration so that you use the Tomcat plugin for deploying your application to http://hostname.com/app. Change the path, url, and server configurations to suit your needs.

    


                org.codehaus.mojo
                tomcat-maven-plugin
                
/app
                    http://hostname.com/manager
                    deployment.server
                
            
        
    

Also make sure that your .m2/settings.xml file contains the following for authenticating with the Tomcat manager.

  
    
      deployment.server
      tomcat
password
    
  

In Bamboo create a new pan for your project. I tend to give this plan the name “Promote to Production”. Configure the Builder goal for Maven to run clean tomcat:redeploy. I also only allow a specific user to trigger this plan so that not everyone has permission to deploy into production. Finally, configure the build strategy to run manually, so an authorised person can click on the Build plan button in Bamboo to deploy the application.

Once set up the above instructions will allow an authorised person in Bamboo to click on a single button to deploy into production. Leveraging your continuous integration tool for deployment allows you to archive deployment artifacts such as your WAR files in the case where you have to revert to a previous version.

My most recent consulting gig brought me back into contact again with Maven. I have this love-hate relationship with Maven. I love using Maven for simple projects, that generally have only a development environment, and I hate using Maven for more complex projects where you have to create profiles for multiple testing environments. Maven is just too restrictive for the latter case.

If you have your own internal Maven repository setup and you want to deploy reusable modules to it then follow these instructions. It took me a while to figure them out as there is something wrong with Wagon’s internal ssh implementation. Using an external scp tool will save you a lot of grief.

1. Setup your local .m2/settings.xml as follows:

  
    
      internal.maven.repos
      maven
location of your ssh private key
  
  

You’ll need to create an ssh key. And provide a reference to your private key using the element. This is simple to do in OS X, or linux, and can be done by running ssh-keygen. If you use Windoze then you’ll have to use Putty.

2. Log into your server hosting your maven repository and add the contents of your public key (id_rsa.pub) at the bottom of the authorized_keys2 file. You should create a generic maven user that everyone on your team can log into, this is because when you deploy your module it will be written to the filesystem with read/write permissions only for that user. Exit your server.

3. Go to your project and add the following to your project’s pom.

        
            internal.maven.repos
            Internal Maven Repository
            scpexe://maven@hostname.com/home/maven/.m2/repository
        
    
...
  
        
            
                org.apache.maven.wagon
                wagon-ssh-external
                1.0-beta-2
            
        
    

4. Run mvn deploy.

5. You should now see your project deployed to the maven repository on your server.

Here is a simple and effective approach to cloning objects in Java using XStream. The process uses XStream to serialize your object to XML, and then using the XML to create a new Java object that is a deep copy of the original.

Sheep dolly = new Sheep("Dolly");
XStream xstream = new XStream();
String xml = xstream.toXML(dolly);
Sheep newDolly = (Sheep)xstream.fromXML(xml);

I’m back at the University of Sydney doing some independent Agile and TDD coaching. The first thing that I wanted to set up was a CI server. My initial recommendation was Atlassian’s Bamboo product, which may come as a surprise given that I used to work for ThoughtWorks – the makers of Cruise – for the last three years. But I must confess, I have never actually used Cruise on a project, it was always Bamboo, Hudson, or Luntbuild. So I figured stick with what you know.

I thought the research group would be strapped for cash and considered setting up Hudson, but Atlassian’s Starter license gives you access to their products for an amazingly low price of $10 per product. It was easy to convince the group to use Bamboo for that price. Best of all the proceeds of the purchase price go towards a charity called Room to Read. Thank you Atlassian for your generosity!

This is just a quick guide to setting up a remote Git repository on a Joyent shared accelerator.

Log into your Joyent server and create your remote git repository.


ssh host.joyent.us
cd ~/git
mkdir project.git
cd project.git
git --bare init
chmod -x hooks
exit


Now on your local box create your project directory and push the source files to your newly created remote repository.


rails project
cd project
git init
git add .
git commit -a
git remote add origin ssh://host.joyent.us/home/username/git/project.git
git push origin master


Now get your collaborators to clone your repository and push their changes. Assuming you have added them as users via virtualmin.


git clone ssh://host.joyent.us/home/username/git/project.git