This is the second post in the behind the scenes look at what it is like to build and ship a product as an ALM Ranger. The product is the ALM treasure map & this video on channel 9 gives a good insight into what is going on.
It should also be noted that these posts are meant as a more brain dump than an actual learning reference.
What to do with a
drunken sailor (with capacity)
In our last sprint, I got all my work done quickly (no walking the plank here) – but I still had capacity and since the crew all did their work quickly too I couldn’t steal work items to keep me out of trouble… so what to do?
- Step one: create some work items for myself.
- Step two: do said work items
- Step three: ?
- Step four: profit!
Hopefully these changes put us in a better starting position for v2 dev which really kicks off in the sprint starting today!
What did those work items contain?
To create some work items I started by just swabbing the deck, so to speak – just cleaning up the solution, removing old folders & code.
Starting with the tiles, I went through the assets we have and removed icons we do not used & renamed the existing ones so the right tiles load at the right resolutions. This is much easier to get right thanks to the improved manifest designer in Update 1 of VS 2012. This also helped me find a bunch of missing resolutions which have been sent to Anisha to create the artwork for.
Our DB load method used async but didn’t implement the conventions properly, so that has been changed to return a Task (I didn’t do that, but I am glad it was done) & renamed to have the async suffix on the name.
For some reason we had an old category.cs file in our view models, so in v1 we named our view model categoryviewmodel.cs which bugged me. So removed old file, renamed & fixed class name. Hopefully makes it easier to navigate & also helps with another tasks I did below.
One of the aspects in our MVVM implementation was that the view was responsible to load the correct view model it needed. So every view either had code in it’s OnNavigate event or in the XAML, which was not bad. The performance issue here was that if you moved from full to snapped views, for example, the view would change & thus we would recreate the view model too! So performance could be better there. We haven’t hit state issues yet, but it could’ve lead to that (think typing in text box, switch to snapped & the stuff you typed is gone since we have a new view model instance).
The solution here was to have the navigation system control this, so using conventions again, it looks for the matching view model for the view we want and if we already have that view model available we use that, if not we create a new instance. The navigation system then injects the view model into the views data context property automatically cleaning up the code in the views too!
This added about sixty lines of code to the navigation code, but means the views & view models are simpler to work with!
VS has a great code analysis feature and it is part of our quality gate to ship the release so I took the time to bump it up to full rules (we normally use recommended) and see what that could find. It found a lot and I went through those and did cleanup to the parts that made sense such as removing unused code & cleaning up the AssemblyInfo.cs file.
I have also switched on code analysis (with recommended rules) as part of the VS debug build options so that while we are developing we are also thinking of our quality gates, so hopefully our final sprint is quickly done!