At Red Ant the main thing we sell is time - project manager time, designer time, developer time - so keeping track of time accurately is paramount. For this we use Harvest, and while we've seen other web apps come and go Harvest seems to have stuck around. (This might be the highest endorsement we can offer - it's one of the few tools we haven't replaced.)

Part of the appeal is the wide range of ways we can access it, and we use them all - a nice web interface, desktop widgets, mobile apps, a robust API. In some respects the API is the nicest part, though, because that means that any feature it doesn't have, we can build.

As they say, these things usually start with an itch. For me, the itch was that when confronted with a technical problem, I tend to jump right in - and I regularly forget to start a new Harvest timer when I start working. If I'm concentrating on the problem, I'm neglecting my timers - if I'm mindful of my of my timers, I'm distracted from the task at hand. 

What seemed called-for was a simple, highly visible display of my current Harvest status. Seeing as my primary browser is currently Chrome, a Chrome extension was the logical choice.

Google maintains a series of tutorials on developing extensions for Chrome, so I was soon up and running. After a refresher course on XMLHttpRequest, my only two real challenges were securely storing the user's Harvest credentials, and defeating Javascript's 'same origin policy' security restrictions so that my extension could reach Harvest's RESTful API.

The former is a challenging problem - Chrome doesn't currently offer API access to it's 'saved passwords' system, so I had to fall back on the security Chrome uses to protect personal user data on the file system. The latter is a serious problem for normal JS development (with hacky fixes like JSONP) which prompted Google to include a 'permission' facet to their extensions API, allowing users to accept a whitelist of domains that the extension is allowed to access.

After tackling those challenges I had a 'badge' (a Chrome UI icon able to display a small image and/or a few characters of text) that turned an an eye-catching red when I was neglecting my timers. 

Usually a feature demands the manner in which you implement it, but equally sometimes the implementation suggests new features. To test whether a timer was active I was collecting all the timer information for the current day, so it seemed natural to display that information (if only while testing the main purpose of the extension.) An extension 'popup' (a small pane that folds out when a badge is clicked) seemed a natural place for this, so that was the next feature added. Showing timers in the popup naturally suggested that you should be able to click on them (thus switching timers) so that went in next. I stopped short of adding a full interface for creating timers because that seemed more natural to leave in Harvest's web interface, but while mulling that over I stumbled on to another use case that isn't quite natural for me while using Harvest.

I log time every day on maintenance tasks like reviewing the status of our servers, triaging my ticket queue and otherwise staying responsive to customers, project managers and other stakeholders. Harvest offers a mechanism to clone tasks from one day to another, but this isn't analogous to what I think of myself as doing (interacting with a 'default timer') and is a bit click-intensive for my likes. So, could I come up with a mechanism that was natural for users to create these default timers and and start/stop them?

Creating them was relatively easy - Chrome extension options pages are just HTML so with a little jQuery I could work up an dynamic form with all the necessary fields. (The only complication is that the options available in the defaults are sensitive to the user credentials provided - my solution for this is a little hacky and I think I might rework it in the future.) My initial efforts to manage them was a bit of a misstep though - creating timers in Harvest also starts them (a sensible default) meaning that 'creating' them new each day meant that they were running for the moment I set them up, regardless of the user's actual behaviour. So I switched tacks and implemented them as a kind of 'ghost' timer - featured in the list of daily timers, but not created until the user actually clicked on them to switch to them. (They're blue in the interface, for those playing along at home.) Works like a charm, and feels very natural.

As my first Chrome extension, I found the learning curve pretty gentle. I'm an experienced front- and back-end developer, though, so YMMV. Certainly my previous Javascript experience stood me in good stead - particularly my knowledge of a handy Javascript library (jQuery) and it's availability via Google's hosted option leapfrogged me through the development pretty quickly. Google's documentation for extension development is clear and accessible, and my only real frustration was the lack of access to Chrome's password safe - hopefully we'll see that added in the future. 

Ultimately, while some might argue against developing browser-specific extensions (given the ebb and flow of browser popularity) I'm confident that the productivity gains from this will make it well worth the time it took. 

If you use Chrome and Harvest, feel free to get Harvest4Chrome from GitHub and try it now - I'd love to hear what you think.

So now my desk looks like this ←

...as I conduct repairs.

Important lessons include:

• Shapeways aren't kidding - thin prints are problematic to say the least. Frustratingly, I think the legs would have looked better made thicker, but there's some things you can't tell 'til you're holding the finished product. Which is really the whole point of rapid prototyping technology like this.
• Interlocking pieces should be designed with actual margins - 3D printing is an additive process (unlike, say, laser-cutting, where kerf actually shrinks your pieces) so components are more likely to be too big than too small - margins should be added to compensate.
• Blender's boolean modifiers worked really well for both throwing the legs together really fast, and hollowing out the chassis - favourite feature so far. :)

All in all, though, I couldn't be happier. Although the perceived risk was much greater (Building something in 3D versus 2D, shipping from the other side of the world versus other side of the city, or from NZ) I feel like this tops all my laser-cutting experiments in terms of success. In terms of cost versus reward, I think I can count myself a convert. :)

The good news is that it wasn't too hard to change the model into something could be printed - and in the process I learned a valuable lesson about baking Blender modifiers into a mesh, versus leaving them unbaked. :)

So while my print slowly wends it's way across the globe, I can reveal that I sent one to David too (the guy who got me started on this with his recent Enterprising print, so I sent this to him as a surprise.) He blogged the process of trying to get my ambitious design put together, but the real pay-off are these photos:

While helping out a local business with their Flickr integration, I hit some gotchas regarding JSON and the Flickr API, so I thought I'd put up my code for anyone in a similar situation.

The main issue was Javascript origin policy - because I was collecting the data from Flickr's servers jQuery's normal getJSON mechanism won't work - you need to break out the 'jsonp' mechanism, and that means digging down to the 'ajax' method.

The other useful thing to know is that Flickr's default JSONP callback is called 'jsonFlickrApi', so make sure to drop that in the parameters for the ajax call.

Here's the example I used for testing. (Replace the api_key with your own - get one from Flickr's developer site.)

Inspired by a cute animated film called Burning Safari, I spent a few hours hacking around in Blender - here's the result:

• Talked about art style, and looked at what tiles my team mate can make. I recommended some I saw on Deviant Art as a good starting place.
• Started brainstorming levels, and created a basic idea for one.
• Set up a Subversion repository and dropped a few files into it...
• ...including a PyGame demo file, to make sure we're both set up for PyGame development.

DNJNLY, or 'Dungeonly' was inspired by researching 'Roguelike' games, and Desktop Dungeons. It looked like one of those deceptively simple game ideas - something easy to make a basic version of, but with lots of opportunities for complexity.

My language of choice for this project is Python, for a couple of reasons. Python combines great readability with great library support, meaning that we'll be able to build quickly and easily, while experiment along the way. 

Particularly, we'll be making the most of PyGame, the famous Python library wrapped around SDL. PyGame has a strong established community, and is particularly friendly to newbies, so it's perfect for our purposes.

Something people often underestimate when building games is the amount data involved. To keep manage and share our level assets and other structured data, we'll be trying Google Docs.

We'll need something to keep track of our code and art assets, particularly because we're working from different countries (The Netherlands and Australia.) Google Code has served me well in the past for basic Subversion project hosting, and TortoiseSVN is a solid, newbie-friendly tool for accessing Subversion. (For a more advanced project I'd probably use Git/Github, but I find that a little less friendly to new users.)