The online home of John Pollard

A whole load of useful dev resources

I've been thinking hard about which out of my long list of half-baked ideas to commit to next. I do have a reasonable plan now - more of which next week - but this week has been more about learning about several very useful open source frameworks I'll be using in the future.

Windows Phone Resources

Most useful of all was a fantastic post by Scott Hanselmann on his first Windows Phone app, which had loads of interesting tidbits, in particular the following resources:

Little Watson

A great generic error handling library to help report issues in the app, as the error reports on the Create MSDN site can be a little obscure sometimes.


A beautiful framework for creating simple but useful about dialog pages. Will definitely be using this.

If you're doing any Windows Phone development at all, you should definitely check out the whole of Scott's post.

Agfx App and Data Caching Framework

Many of the ideas I've had involve using data from the Internet in some way, and the occasionally connected nature of such devices means a reliable caching layer essential.

I'd been thinking of writing my own such store, but happily before I really got started I found the AgFx Windows Phone App and Data Caching Framework on Codeplex, which looks like exactly what I need. I'll let you know how that works out in later posts.

Other Cool Things I've Learnt This Week

Bootstrap Update

The Brave Location website is built using the Bootstrap Framework, an excellent set of resources built by some developers from Twitter.

The only downside I found was that the layouts weren't particularly responsive, so didn't look fantastic on mobile phones.

However the latest version (2.0) has added much better support for adjusting the page based on the current size, and apart from a few ongoing glitches with the navbar, the site now works very well on smaller resolutions now.

Markdown and MarkdownPad

I also just realised that Posterous - where I'm hosting this bog - supports Markdown, an easy text-based way of writing than can easily be turned into simple HTML.

My posts both on here and on my personal blog are tending to be a bit longer than usual, and to be honest I haven't found a web-based HTML editor yet that isn't a bit painful to use.

Therefore using Markdown makes it much easier to use any text-based editor to write the posts offline, and I'm also trying out the so far very useful MarkdownPad to do my writing in (using it right now for this post)

Week 5 Summary

To be honest I'm finding it hard - as expected - to keep up the momentum of an app a month when I'm pretty much maxed out in my day job. However I do like my next app idea - especially as it could provide a framework for a whole class of similar apps going forward.

Version 3 of Bedside Clock App Shipped

So we're still on target for shipping an app a month, but January was always going to be an easy month as I've just shipped v3.0 of my Bedside Clock Windows Phone 7 app.

The cliche says that the 3rd version of Microsoft software is always the good one, and I'm hoping that my background will mean this is true here too.

To be honest the first two versions have been more about me learning the capabilities of the platform than shipping something with a massive amount of value to anyone but myself - and in particular v2.0 had an application bar control in it mainly because I wanted to see how it worked.

What I did learn was that user feedback is invaluable, and I received some great (if slightly negative) feedback from users that the new design didn't work very well, especially when the user has chosen the light theme. The problem was the application bar control can't be minimised in a satisfactory way, and it always takes the theme color - which somewhat clashes with the rest of the app if not using the dark theme.

Anyway I'm really happy with v3.0. The UX issues mentioned above have been addressed by moving all the settings to a separate page, and the big addition to the functionality is adding in weather information from Yahoo! Weather. This has already been useful a couple of times last week as I knew the forecast was for rain before I left for work early in the morning.

I'd also like to give credit and thanks to Gavin Elliott for the nice weather icons he generously made available for free.

I'm not intending on doing any more development on this app right now - unless some horrible bugs emerge after it's made it's way out via the Marketplace - but I'm always looking for feedback so please let me know what you think.


Planning about Planning, and Planning

Been a reasonably slow start to the year of code, mainly because I've been in the US for the day job. However the first couple of weeks have been reasonably productive, mainly in me figuring out the best way forward.

First of all I refactored the Brave Location website a little, to make it look hopefully a little more professional and clarify what Brave Location is all about.

For the site I'm using Twitter's Bootstrap framework, which I'm very happy with except thatit isn't particularly adaptive to mobile browsers. I'm considering trying out Skeleton at some point to improve the experience for mobile users, but think I've spent enough time on it right now.

However my main progress has been figuring out how (or even if!) I can achieve my goal of shipping something every month.

I'm a reasonably big proponent of agile software development processes, having followed them in varying degrees of militancy in the most of the teams I've worked on in the last few years. However, I'm going to follow something that sounds more like a waterfall approach in that I'm going to have 4 weekly sprints, and have the following milestones/checkpoints:

  • Week One: Planning and Prototyping
  • Week Two: Main development
  • Week Three: Stabilisation/Testing
  • Week Four: Release/Deployment

My rationale for doing it this way is simple - I need a clear goal every week to inspire me to press on with my side projects after a hard day at work.

Now obviously in a team of one I don't think it really matters much what development process I follow, as most methods are designed to maximise clear communication between the development team and the business, and to extract maximum value for the business by focusing on the most important work that can be done in a short period. With me being all of the product owner, scrum master and development team I would hope communication won't be a problem.

Anyway, despite all this planning about planning, what I have been doing so far in month one is working on v3.0 of my Bedside Clock Windows Phone app. It may be slightly against the spirit of the "ship every month", but it's a good way for me to get into the swing of things. I've completed most of the dev work except a few new ideas and bug fixes inspired by being in a different time zone last week, so hopefully it will be ready to ship by the end of next week.

My other pledge is to blog about my progress at least once a week, so details of what the third and hopefully final version of the app will have to wait until next week.

2012 - Year of Code (and Shipping!)

So this is the plan.

I was inspired during my personal Something New Every Day project to ship a new piece of software every month for a whole year.

I really got the idea from hearing about the Dollar App project, which is essentially the same idea, although from their website it's not entirely clear how well they did.

The reason I'm doing this is that like many people I have lots of ideas for apps to build, but having a day job means it's often hard find the incentive to do other things in my spare time. I figure if I publically commit to doing something it's more likely I might actually follow through on it.

It would be great if something good comes out of the project. I'd be happy if just one app is reasonably successful, and who knows if that will happen, but the only way to find out is to give it a go!

I'm not going to restrict myself in anyway on what I develop, but my main interests are in location-based software, Windows Phone 7, Facebook apps and Windows 8, so almost certainly the apps will be some combination of one or more of those areas.

I'll also try to post regular updates on this blog, both on what I (hopefully) ship and what I learn along the way. You can also follow along on Twitter (@bravelocation) and I may get around to setting up a Facebook page too.

Here we go....


Changing the type of a Visual Studio project

Originally posted on my old MSDN blog

The reason I’m blogging about this is that I was trying to do this the other day and I struggled to find the relevant information from ALL of the major search engines – including the one I work on. Now it could be that I was using the wrong search terms, but I wanted to capture the solution just in case I (or someone else) needs to do the same.

My problem was this. We were upgrading some Visual Studio project files from 2008 to 2010, although we wanted them to continue to use the 3.5 .Net runtime. This wasn’t a problem and all went pretty smoothly, except for one project that contained some NUnit unit tests which insisted it could now only build to 4.0.

After a bit of pondering, I finally realised what had happened. Initially the project was a Visual Studio test project before we’d switched to NUnit, but because it was now an upgraded “test project” it had also be compiled against the presumably updated test functionality in VS2010/.Net 4.0.

So the solution should be simple right? Just change the project type to be a “regular” project that compiles to a DLL and everything will be OK? Well yes, but as far as I could see there was no obvious way in the project settings in Visual Studio to fix this. Now it could be that I’m stupid - please let me know if I am! - but I had to resort to hacking the XML in the project file itself.

Unfortunately the project types are stored in the XML as GUIDs. Why? Very hard to say. However after much searching finally I found this very useful page which had a list of project type GUIDs that I needed. A big thank you to the author of that page - Carlos J. Quintero! I changed the GUID and was now allowed to compile to the runtime I wanted. Job done.