Using Pull Requests for commercial/private/proprietary development

Developers who are familiar with open source will likely be aware of pull requests, which were created and popularised by GitHub as a way of providing some automation, visibility and social interaction around merging software changes. It replaces the old school notion of emailing patch files to each other as well as providing more visibility and interaction over pushing to the same branch (aka mainline development).

This is a post I’ve been meaning to write for a while. As a Senior Consultant for Readify I find myself spending a lot of time mentoring teams and as a part of that I’m constantly paying attention to trends I notice and picking up / experimenting with techniques and processes that I can introduce to teams to get positive outcomes (improved efficiency, quality, maintainability, collaboration etc.). In my experiences so far I’ve found that the single most effective change I have introduced to a software team that has improved the quality of software output is to introduce pull requests. It also has a positive effect on other things like improved collaboration and collective code ownership.

I can’t claim to have invented this idea – I got the idea from listening to the experiences that my fellow consultants Graeme Foster and Jake Ginnivan had and there are certainly examples of companies using it, not the least of which is GitHub itself.

What are pull requests?

Essentially, a pull request allows a developer to make some commits, push those commits to a branch that they have access to and create a request to a repository that they don’t necessarily have access (but also could) to have their commit(s) merged in. Depending on the software that you are using, a pull request will generally be represented as a diff, a list of the commits and a dialogue of comments both against the pull request itself and against individual lines of code in the diff.

Why are pull requests useful for open source?

Pull Requests are awesome for open source because they allow random third parties to submit code changes easily and effectively to projects that they don’t usually have commit access to and for project maintainers to have a conversation with the contributor to get the changes in a state where they can be merged.

This lowers the barrier of entry to both maintainers and contributors, thus making it easier for everyone involved :).

Why are pull requests useful for commercial development?

On first thought you might think that commercial development is significantly different from open source since the people submitting code changes are on the same team and there will be existing code review processes in place to deal with code quality.

Based on my experiences and other people I know there are definitely a range of advantages to using pull requests for commercial development (in no particular order):

  • If you have enough developers and a big enough project/product then you might actually have a similar setup to an open source project in that the product might have a “core team” that look after the product and maintaining standards and consistency and other developers in the company can then submit pull requests to be reviewed by the core team
  • Pull requests give a level playing field to the whole team – it encourages more junior or shy developers to “safely” review and comment on commits by more senior developers since it takes away the intimidation of doing it in person
  • It provides a platform for new developers to get up-skilled quicker by providing:
    • Easy to digest, focussed examples of how to implement certain features that they can browse easily without having to ask how to find them
    • Confidence to raise pull requests without the stress of needing to know if the code is OK
    • Line-by-line comments to help them identify what they need to change to get their code “up to scratch”
    • This has a positive effect on the new developer themselves as well as the team since the learning is founded in practical application (which in my view is always the most efficient way to learn) and the person potentially needs less time from the team to get up to speed (thus having a smaller “burden”)
  • In much the same way as it helps with up-skilling it helps with learning for more junior developers
  • It improves the safety of making changes to the codebase by ensuring that changes are looked at by at least one person before being merged into mainline
  • It improves the consistency/maintainability and quality of the codebase by ensuring all changes are reviewed by at least one person
  • It makes it more likely that changes that would normally pass code review because they were minor enough that it didn’t warrant rejecting a code review / going back and fixing what was already there are more likely to get fixed before being merged in
  • There is tooling out there (e.g. TeamCity’s pull request integration) that can integrate with pull requests to provide assurances that the pull request is OK to merge (and potentially automatically merge it for you)
  • The ability to have threaded comments on individual lines of code makes it really easy to have a contextual conversation about parts of the code and arrive at better designs because of it
  • Despite what code review processes you might have in place I suspect that most of the time it’s more likely code will get reviewed using pull requests because in my experience code reviews don’t always happen regardless of what development processes exist, whereas a pull request would always be reviewed before merging
  • Pull requests are pull-based rather than push-based i.e. the reviewer can review the code when they are not in the middle of something so there is less context-switching overhead (note: important/blocking pull requests might be a reason to interrupt someone still, but in my experience those pull requests are not the majority)
  • If you are working with developers across multiple timezones then the above point means that code reviews are easier to perform since they are pull-based
  • You can use pull requests to raise work-in-progress for early feedback (reducing feedback cycles :)) or for putting up the result of spikes for team comment
  • If approached in the right way then it helps teams with collective code ownership because there is a lot of back-and-forth collaboration over the code and everyone in the team is free to review any pull request they are interested in

As you can see – it’s a pretty convincing list of points and this summarises pretty well why pull requests are the most effective change I’ve made to a development team that has affected code quality.

So, nothings perfect; what are the downsides/gotchas?

There are only a few I’ve noticed so far:

  • If there is a lot of churn on the codebase from a lot of disparate teams/developers with potentially conflicting, high-priority tasks and there is no “core team” looking after the project then there is a tendency for developers to:
    • Work with other developers in their team to quickly merge the pull request without much inspection
    • Worse still – developers might just merge their own pull requests or bypass them completely and push directly to the branch
    • Acknowledge the review comments, but claim that their work is too high priority to not merge straight away and never get around to making the changes
  • If there is someone in the team that is particularly picky then it’s possible that team members might try and avoid that person reviewing their pull requests by asking someone else to review it
  • If there are a lot of changes to be made based on review comments it can sometimes get tricky to keep track of which ones have and haven’t been applied and/or the pull request could drag on for a long time while the developer completes the changes – there is a balance here between merging in the potentially important work in the pull request and spending time fixing potentially minor problems
  • If pull requests are too big they are harder to review and there will be less review comments as a result and things might get missed (this would be a problem without pull requests, but pull requests simply highlight the problem)
  • The diff UI on GitHub and Bitbucket frankly suck compared to local diffing tools. Stash’s pull request diff UI is actually really good though; this does make it a bit more difficult for bigger PRs (but then it’s still easy to pull and review the changes locally so you can get around this limitation)
  • Comments on controversial code changes (or sometimes not so controversial changes) can sometimes get a bit out of hand with more comments than lines of code changed in the PR – at this point it’s clear that the back-and-forth commenting has taken the place of what should be an in-person (or if you are remote video) conversation next to a whiteboard
  • You end up with a lot of local and remote branches that clutter things up, but there are techniques to deal with it

These behaviours are generally unhealthy and are likely to be a problem if you don’t have pull requests anyway (and in fact, pull requests simply serve to visualise the problems!) and should be addressed as part of the general continuous improvement that your team should be undergoing (e.g. raise the problems in retrospectives or to management if serious enough). Hopefully, you are in a situation with a self-organising team that will generally do the right things and get on board with the change :).

Pull requests and continuous delivery

I’m extremelly passionate about Continuous Delivery and as such I have been in favour of a mainline development approach over feature branches for quite a while. Thus, on first hearing about using pull requests I was initially wary because I mistakenly thought it was a manifestation of feature branches. What I’ve since learnt is it definitely doesn’t have to be, and in my opinion shouldn’t be, about creating feature branches.

Instead, the same mindset that you bring to mainline development should be taken to pull requests and the same techniques to enable merging of partially complete features in a way that keeps the code both constantly production-ready and continuously integrated should be used. The way I see it developers need to have a mindset of looking at a pull request as being “a set of changes I want to merge to master” rather than “a complete feature ready to be integrated”. This helps keep pull requests small, easy to review and ensures all developers are regularly integrating all changes against the mainline.

Introducing pull requests to the deployment pipeline adds another step that increases the confidence in your production deployments (the whole point of a deployment pipeline) as well as helping make sure that code in the mainline is always production-ready since the reviewer can (and should) review the changeset for it’s likely effect on production as well as the usual things you would review.

Side note: I love this git branching model description.


  • Keep PRs small (I think I’ve explained why above well enough)
  • Keep PRs focussed – a PR should contain one logical set of changes – it makes it easier to review and means if there is a problem with one set of changes that it doesn’t block the other set of changes
  • Delete a remote branch after it has been merged (if using Stash/Bitbucket then always tick the “close this branch after PR is merged” box)
  • Keep commits clean – having a PR isn’t an excuse to be lazy about your commits; use good commit messages, keep related logical changes together in a single commit, squash them together where relevant, use rebasing rather than merge commits and think about the history after the PR is merged – don’t make it harder for yourself or your team in the future
  • Don’t let PRs get stagnant – if you are finished with a task take a look at the PRs and merge a couple before moving on; if everyone does this then there will be a constant flow of merges/integration – if a PR is open for more than a day there is a problem
  • Where possible have one PR/branch per-person – you should be able to clean up your commits and force push to your pull request branch and it encourages the PR to be smaller
    • Be incredibly careful when doing a force push that you are not pushing to master
    • If you can turn off the ability to force push to master (e.g. Bitbucket allows this) then do it – better safe than sorry
  • For those situations where you do need to work closely with someone else and feel like you need a PR across multiple people there are two techniques you can use:
    • Identify and pair together on at least the blocking “integration” work, put up a PR, get it merged and then work in individual PRs after that
    • If necessary then put up a pull request and contribute to the branch of that pull request by individual pull requests (i.e. create a featurex branch with a pull request to master and then create separate featurex-subfeaturea, featurex-subfeatureb branches with pull requests to featurex) – try and avoid this because it increases the size and length of time of the integrated pull request – also, consider rebasing the integrated pull request just before it’s pulled in
    • If you plan on submitting a pull request against someone else’s pull request branch then make sure you tell them so they don’t rebase the commits on you (can you see why I try and avoid this? :P)
  • Make sure that PR merges are done with actual merge commits (the merge button in all of the PR tools I’ve used do this for you) that reference the PR number – it makes it easier to trace them later and provides some extra information about the commits that you can look up (this is the only thing you should use merge commits for in my opinion)
  • If your PR is not urgent then leave it there for someone to merge at their leisure and move on, if it’s urgent/blocking then ask the team if someone can review/merge it straight away (from what I’ve seen this is not the common case – e.g. one or two a day out of 10-15 PRs)
  • Tag your PR title with [WIP] to mark a work-in-progress PR that you are putting up for feedback to make sure you are on the right track and to reduce feedback cycles – [WIP] indicates that it’s open for people to review, but NOT to merge
  • In those rare circumstances when a PR is ready to be merged, but isn’t production-ready (maybe it’s a code clean-up waiting for a successful production release to occur first to render the code being deleted redundant for instance) then tag the PR title with [DO NOT MERGE]
  • Unless you know what you are doing with Git never work off master locally; when starting new work switch to master, pull from origin/master, and create and switch to a new branch to describe your impending PR – it makes things a lot easier
    • I almost never do this – I generally just work on master unless editing a previously submitted PR because I find it quicker, but it does require me to constant be very careful about what branches I’m pushing and pulling from!
  • Call out the good things in the code when reviewing – reviews shouldn’t devolve into just pointing out things you think are wrong otherwise they develop negative connotations – if the PR creator did a good job on a bit of complex code then give them a pat on the back!
  • Similarly, avoid emotive phrases like “ugly”, “gross” etc. when describing code; when I’m reviewing code a technique I use to try and not sound condescending is to ask a question, e.g. “Do you think this should be named XX to make it clearer?” – make the pull request into a two-way conversation; work out the best solution collaboratively as a team
  • If you aren’t sure about something don’t be afraid to ask a question; quite often this will highlight something that the author missed or at the very least help you to learn something
  • Have fun! Use funny gifs, use funny branch names – just because we are developing serious software doesn’t mean we can’t enjoy our jobs!

Getting started

I’ve found that the following helps immensely when first getting a team started (but after a while the team is able to sustain itself easily):

  • Having at least one person experienced with Git is really helpful as inevitably people will get themselves confused when first using branches and in particular with rebasing
  • Have at least one person that knows what they are doing ensure that in the first week all PRs are reviewed and merged quickly – this will alleviate the team from needing to worry about keeping on top of merging PRs and instead will concentrate on the semantics of creating pull requests, responding to review comments and updating PRs. Once they get the hang of it then stop reviewing/merging all, but the most important PRs and the team will start to notice there is an increase in PRs and will hopefully self-organise to get them merged and get into the habit of doing that
    • It’s possible this technique might not always work, but it has when I’ve tried it and it assists the team to slowly get the hang of using pull requests rather than dropping a huge change on them all at once
    • If the team doesn’t self-organise then bring up the fact PRs aren’t getting merged in retrospectives and suggest a possible solution of reviewing open PRs directly after standup and team members volunteer to review/merge each of the open ones
  • Developers will naturally approach pull requests like feature branches even if told up front to treat it the same as what you would originally push to mainline with mainline development because of the natural human desire to get things “right” / finished
    • This will lead to enormous PRs that are constantly conflicted and a real pain in the ass for the developer
    • Let this happen and when the PR is finally merged sit down with them and ask them how they think it could be avoided in the future
    • Hopefully they will come to the realisation the PR was too big themselves and because they have made that realisation based on experience they are more likely to keep PRs small


There are various tools that can help you use pull requests. The ones I have experience with or knowledge of are:

If you are interested in semver and you want to use pull requests (or you don’t and you are using mainline development) then I encourage you to check out the GitHubFlowVersion project by my friend Jake Ginnivan.

On myself and FluentMVCTesting joining TestStack

I’d like to announce that I’m joining TestStack and my FluentMCVTesting library will become a TestStack library.

What is TestStack?

I think it can be summed up nicely by a post from one of the core TestStack team, Michael Whelan, in the blog post he wrote. tl;dr: TestStack is a collection of open source projects which mainly focus on making the left side of Marrick’s Agile Testing Quadrant easier!

Why am I joining TestStack?

I think that the libraries in TestStack are awesome and the core team are a group of people I trust and respect. It’s a pleasure to be invited into the core team and I think it’s really great for the FluentMVCTesting library to be present alongside the other awesome testing libraries.

What will happen to FluentMVCTesting?

The nuget package and namespace is changing to have a TestStack prefix for consistency with other TestStack libraries, but other than that nothing much – the library is the same library, but it’s more likely to have additions made to it and hopefully more people using it.

If you update the existing FluentMVCTesting package then it will include the new package as a dependency and wrap around the new classes, but mark the old classes as deprecated. This should provide a smooth transition to existing users of the package as well as letting them know there is a new package out there.

I’m also dropping the strong signing support for now to keep consistency with the other TestStack libraries. We will add that in due course to all the libraries if we feel there is enough demand for it.

Azure Web Sites: Paid shared hosting, custom domain names and continuous deployment

There was a set of announcements about Azure Web Sites today, which give some insight into how the feature is developing and the focus areas for Microsoft with this particular service.

The Announcements

In short:

  • A new paid shared hosting model to supplement the free one
  • Based on what Scott said in his post it looks like you can have an unlimited number of web sites in reserved mode (with the initial release it was 10)
    • I suspect this also applies to the paid shared hosting, but regardless at a point you would upgrade to reserved anyway since it’s not a per-site cost so it becomes cheaper than a whole heap of shared hosting sites
  • You can now use CNames against the (paid) shared hosting model
  • You can now use A records against (paid) shared hosting or against reserved hosting!
  • Support for doing continuous deployment from a Github or Codeplex account
    • This means you don’t need to push your changes to azure explicitly and can instead use azure as a bit of a CI server (although you can’t ensure tests pass first, but the TFS integration allows for that!)
    • This mimics similar functionality in App Harbor
    • There isn’t support for private keys yet so public repos only, but Scott did say that it will be supported soon 🙂

Note: today’s release supports establishing connections with public GitHub/CodePlex repositories.  Support for private repositories will be enabled in a few weeks.

  • Support for multiple branches, which can be used to provide test and production deployments from the same repository (pretty cool!)


The thing I’ve been waiting for the most with Azure Web Sites is the ability to use SSL with your custom domain name. Whilst it was unfortunately not announced today mention was made of it; more specifically:

We will also in the future enable SNI based SSL as a built-in feature with shared mode web-sites (this functionality isn’t supported with today’s release – but will be coming later this year to both the shared and reserved tiers).

This is particularly exciting because it’s the main reason I haven’t used Web Sites much yet!


The announcement of the new paid shared hosting model is really interesting, but it makes a lot of sense. It does two things:

  • Provides an accessible service for people that need a custom domain name and more than 165MB/day of bandwidth, but can’t afford a small instance
  • Provides a monetisation strategy for Microsoft for people in the above situation that places them on-par with most standard hosting companies ($113.88/year), but of course the service they are providing and the performance is really great so it’s something that could really take off. That can only be a good thing; the more popular Azure is the more it can grow! Bring it on!

The continuous deployment announcement is cool, but not surprising; it’s more of the same stuff that has been coming out in releases and blog posts by the awesome people that are currently driving a lot of this stuff. It’s great that Microsoft is supporting Github as a first class citizen rather than just their own platform (Codeplex).

Interestingly for me is that yet again there is a set of features in Web Sites that aren’t exposed in Web Roles either. It’s still unclear whether Web Sites will eventually replace Web Roles. I don’t think that’s likely to happen at least in the short term because there is too many things that are different about them and all the documentation clearly places them as filling separate needs (Web Roles is for when you need more control / advanced use cases).

For instance, I don’t ever see them giving RDP for Web Sites given it’s multi-tenanted and your web site could be hosted on one of a whole heap of random servers at any point in time and that can (probably) change over time too.

The whole point is Web Sites is simple and abstracts all that complexity away from you. For that reason Web Sites is well targeted at less technically inclined people and thus is more accessible to more people (all of the tutorials and presentations and marketing is around how easy it is to get up and running with minimal code and configuration!) – a great thing!

So, given that Web Roles probably isn’t going anywhere I’m surprised that they haven’t released A Record and better deployment support to Web Roles.

Windows Azure High-level diagram

I recently stumbled across the Windows Azure Solution Cookbook by Clint Edmonson from Microsoft. It’s a pretty awesome set of reference architectures for solving a few different scenarios that Windows Azure is a natural fit for solving.

One of the things I noticed is that on the lead-in page there is what I can only describe as the most amazing high-level diagram of Azure that I’ve been able to find to date. It wasn’t quite up to date though, having been done before the release of Web Sites and Mobile Servies. I recently asked Clint if he could do an updated version via the magic of Twitter and he has come through.

If you need to give any presentations about Azure or frankly, just want to see an example of all the different (and many!) components that make up Azure these days and how they fit into each other than take a look!

Azure Architecture Overview


Lately I’ve been having a bit of fun learning ASP.NET Web API and I’ve been working with Jake Ginnivan to come up with a library that allows you to follow the HATEOS principle of REST using it. We’ve been doing this by implementing a specification that allows you to specify hypermedia for JSON and XML called HAL.

Jake did some awesome work to start it off and more recently I came along and tried to make the specification of the hypermedia as unobtrusive as possible.

It’s very rough around the edges, and definitely a work-in-progress, but if you are interested feel free to check out the latest work that I’ve been doing on it at:

To see it in action simply fire up the site, the homepage is a HTML page that allows you to interact with the dummy API I created via a set of HTML forms (the actual requests are made with JavaScript). If you inspect the PersonController class you will see that I barely had to add anything to it to get the hypermedia in there.


Using a FlipView with SemanticZoom in Windows 8 Metro-style application

This post outlines how I managed to get a FlipView control working inside of a Semantic Zoom when developing a Windows 8 metro-style application using C# / XAML.

An aside about XAML vs HTML for Windows 8 development

As anyone following me on Twitter would have seen I’ve found myself fortunate enough to be in a situation where I’m not only (finally) learning XAML, but also creating a Windows 8 “metro-style” proof-of-concept application.

While I come from a web background I was recommended to use C# XAML rather than HTML 5 to create the application. While creating the application I’ve come across a fair bit of documentation and sample applications using HTML 5 / JavaScript rather than XAML / C#. While I haven’t done any windows 8 apps in JavaScript yet, I suspect that using XAML is more powerful and expressive, even if it’s a little bit more verbose and slightly less convenient to style. Regardless, at this point that’s just pure conjecture on my part.

What I wanted to achieve and why

Back to the point: One thing I wanted to demonstrate in my proof-of-concept application was the use of semantic zoom because I think it’s a very powerful user interface concept and led quite naturally to provide that little bit more convenient and natural navigation to the application I was creating.

At the same time I was adamant that I wanted to use a flip view because I had a small number of discrete items that I wanted to each take up a page. While there is a concept of providing a context indicator control I wanted to also have an app bar and felt that the semantic zoom provided a cleaner way of providing that high level navigation (as well as there were few enough items in the list and they were always the same that the user always knew where they were so didn’t need any indication).

The problem

SemanticZoom only allows you to use a GridView or ListView within it and while there are posts out there about how you can come up with custom controls they only seem to apply to HTML / JavaScript and not XAML.

As explained above I didn’t want a continuously scrolling control, I wanted to use the FlipView Control. Initially I tried this by nesting a FlipView directly inside a GridViewItem and a ListViewItem, but that looks really ugly because of the default hover, selection and click semantics on those controls. As well as that, the items weren’t being bounded to the parent and thus my content was being cut off.

The solution

What I ended up doing was the following.


                    <ListView HorizontalAlignment="Center" VerticalAlignment="Center">
                                <StackPanel Orientation="Horizontal" />
                        <ListViewItem Background="#E30000" Style="{StaticResource SemanticZoomListItem}" Tapped="Category1Selected">
                                <TextBlock Text="Category1" Style="{StaticResource SemanticZoomListItemTitle}" />
                                <Image Source="ms-appx:///Assets/Category1.png" Style="{StaticResource SemanticZoomListItemImage}" />
                        <ListViewItem Background="#FF6400" Style="{StaticResource SemanticZoomListItem}" Tapped="Category2Selected">
                                <TextBlock Text="Category2" Style="{StaticResource SemanticZoomListItemTitle}" />
                                <Image Source="ms-appx:///Assets/Category2.png" Style="{StaticResource SemanticZoomListItemImage}" />
                        <ListViewItem Background="#009600" Style="{StaticResource SemanticZoomListItem}" Tapped="Category3Selected">
                                <TextBlock Text="Category3" Style="{StaticResource SemanticZoomListItemTitle}" />
                                <Image Source="ms-appx:///Assets/Category3.png" Style="{StaticResource SemanticZoomListItemImage}" />
                        <ListViewItem Background="#006BE3" Style="{StaticResource SemanticZoomListItem}" Tapped="Category4Selected">
                                <TextBlock Text="Category4" Style="{StaticResource SemanticZoomListItemTitle}" />
                                <Image Source="ms-appx:///Assets/Category4.png" Style="{StaticResource SemanticZoomListItemImage}" />
                    <GridView ScrollViewer.HorizontalScrollMode="Disabled" ScrollViewer.VerticalScrollMode="Disabled"  SelectionMode="None" IsItemClickEnabled="False" IsHoldingEnabled="False" IsSwipeEnabled="False" CanReorderItems="False" CanDragItems="False" ItemContainerStyle="{StaticResource ZenGridViewItemStyle}">
                            <FlipView x:Name="FlipParent">
                                <FlipViewItem x:Name="Category1FlipView">
                                    <Controls:Category1 />
                                <FlipViewItem x:Name="Category2FlipView">
                                    <Controls:Category2 />
                                <FlipViewItem x:Name="Category3FlipView">
                                    <Controls:Category3 />
                                <FlipViewItem x:Name="Category4FlipView">
                                    <Controls:Category4 />


                <ResourceDictionary Source="Common/StandardStyles.xaml"/>
                <ResourceDictionary Source="Common/ZenStyles.xaml"/>
            <Style x:Key="SemanticZoomListItem" TargetType="ListViewItem">
                <Setter Property="Padding" Value="4" />
                <Setter Property="Width" Value="128" />
                <Setter Property="Height" Value="128" />
                <Setter Property="Margin" Value="0" />
                <Setter Property="HorizontalContentAlignment" Value="Stretch" />
                <Setter Property="VerticalContentAlignment" Value="Stretch" />
            <Style x:Key="SemanticZoomListItemTitle" TargetType="TextBlock" BasedOn="{StaticResource BasicTextStyle}">
                <Setter Property="FontSize" Value="20" />
                <Setter Property="FontWeight" Value="SemiLight" />
                <Setter Property="HorizontalAlignment" Value="Left" />
                <Setter Property="VerticalAlignment" Value="Bottom" />
            <Style x:Key="SemanticZoomListItemImage" TargetType="Image">
                <Setter Property="HorizontalAlignment" Value="Center" />
                <Setter Property="VerticalAlignment" Value="Center" />
                <Setter Property="Width" Value="64" />
                <Setter Property="Height" Value="64" />


Copied from The taming of the Metro GridView.


This bit is the bit I like the least and I’m sure there is a less verbose way of doing it, but I’m happy enough with it for now. This is to get around the fact that we aren’t using the ListView or GridView so we need to manually set the correct FlipViewItem to display when the top level category is selected. I’ll be honest this part is a bit of a hack, but hey – it works!

        private void Category1Selected(object sender, TappedRoutedEventArgs e)
            FlipParent.SelectedItem = Category1FlipView;

        private void Category2Selected(object sender, TappedRoutedEventArgs e)
            FlipParent.SelectedItem = Category2FlipView;

        private void Category3Selected(object sender, TappedRoutedEventArgs e)
            FlipParent.SelectedItem = Category3FlipView;

        private void Category4Selected(object sender, TappedRoutedEventArgs e)
            FlipParent.SelectedItem = Category4FlipView;

Edit 27/08/2012: Changes needed for RTM

I just tried this out in RTM VS 2012 and Wind 8 SDK and noticed that it was broken. The fix was to change from the PointerReleased event to the Tapped event.

… A year later

It seems rather funny that it was exactly one year since I’ve done a post on my blog. Usual story of course, I started out with good intentions to regularly blog about all the cool stuff I discover along my journey, but time got the better of me. I guess they were the same intentions that I originally had to skin this blog :S.

One thing I have learnt over the last year is that prioritisation is one of the most important things you can do and abide by both personally and professionally. No matter what there will never be enough time to do all the things that you need and want to do so you just have to prioritise and get done all you can – what more can you ask of yourself. With that in mind I guess I haven’t prioritised my blog 😛

I really respect people that manage to keep up with regular blog posts as well as full-time work and other activities. I find that writing blog posts is really time consuming because the pedantic perfectionist in me strives to get every relevant little detail in there and ensure it’s all formatted correctly. Combining that with the insane number of things I seem to find myself doing and trying to get some relax time in somewhere isn’t terribly conducive. It’s a pity really because I enjoy writing posts and hopefully I contribute some useful information here and there.

So, that aside, what have I been doing for the last year. If you are interested feel free to peruse the below list, which has some of what I’ve been doing and is written in no particular order; it’s really just a brain dump ^^. There are a few posts that I have been intending on writing along the way with particularly interesting (to me at least) topics so I’ll try and write some posts over the next few days 🙂

  • Worked with out Project Management Office at work to come up with a way to use PRINCE 2 to provide high level project management to our Agile projects without impacting on the daily work that the teams perform under Scrum. Despite my early scepticism about PRINCE 2 it’s actually a really impressive and flexible project management framework and has worked well.
  • Learnt PowerShell – it’s amazing!
  • Wrote some interesting / powerful NuGet packages (not public I’m afraid) using PowerShell install scripts
  • Attended a really great conference
  • Discovered and started living and breathing (and evangelising) continuous delivery and dev ops
  • Started thinking about the concept of continuous design as presented by Mary Poppendieck at Yow
  • Created a continuous delivery pipeline for a side-project with a final prod deployment to Windows Azure controlled by the product owner at the click of a button with a 30-45s deployment time!
  • Started learning about the value of Lean thinking, in particular with operational teams
  • Started evangelising lean thinking to management and other teams at work (both software and non-software)
  • Started using Trello to organise pretty much everything (both for my team, myself personally and at work and various projects I’m working on in and out of work) – it’s AMAZING.
  • Delivered a number of interesting / technically challenging projects
  • Became a manager
  • Assisted my team to embark on the biggest project we’ve done to date
  • Joined a start-up company based in Melbourne in my spare time
  • Joined Linked in (lol; I guess it had to finally happen)
  • Gave a number of presentations
  • Became somewhat proficient in MSBuild (*shudders*) and XDT
  • Facilitated countless retrospectives including a few virtual retrospectives (ahh Trello, what would I do without you)
  • Consolidated my love for pretty much everything Jetbrains produce for .NET (in particular TeamCity 7 and ReSharper 6 are insanely good, I’ll forgive them for dotCover)
  • Met Martin Fowler and Mary and Tom Poppendieck
  • Participated in the global day of code retreat and then ran one for my team (along with a couple of Fedex days)
  • Got really frustrated with 2GB of RAM on my 3 year old computer at home after I started doing serious development on it (with the start-up) and upgraded to 6GB (soooo much better, thanks Evan!)
  • Participated on a couple of panels for my local Agile meetup group
  • Got an iPhone 4S 🙂 (my 3GS was heavily on the blink :S)
  • Took over as chairman of the young professionals committee for the local branch of the Institution of Engineering and Technology
  • Deepened my experience with Microsoft Azure and thoroughly enjoyed all the enhancements they have made – they have gone a long way since I first started in 2010!

Of course there is heaps more, but this will do for now.

iPad: Seven weeks on

So I’ve had the privilege of having an iPad for almost a couple of months now and I’ve spent a fair bit of time experimenting with a few different apps and thinking of ideas for uses of this interesting UI. I’ve also had numerous discussions with various friends and colleagues about some potential use cases for the iPad.

With that in mind I wanted to summarise my initial thoughts and ideas; nothing too prolific, but maybe over time I can refine my thoughts. I should also note I haven’t done a lot of research into innovative ways the iPad is currently being used apart from what I have observed within apps that I have used. If anyone has any good links to content then feel free to post them in the comments; in particular I am interested in any research being undertaken at Universities.

Continue reading “iPad: Seven weeks on”