What about? Glad you asked.  The title is “Building Mobile Websites with ASP.NET MVC 3 and 4“.

It sounds fairly self-explanatory, but I’ll be covering more than just the obvious in this talk.  In addition to actually showing how to write mobile-targeted sites in MVC 3 and 4, I’ll be discussing:

• Why it’s important to think about mobile sites, and why people aren’t,
• How smartphones actually render a desktop site and what you can do about it,
• How mobile and desktop sites can coexist beautifully, and
• Why ASP.NET MVC is the perfect technology to deliver sites that look great on any device
• What libraries and packages are available to give you the best results

So if you’re in the Melbourne area on Monday, I’d love for you to come and check it out.  Just RSVP on EventBrite and I’ll see you there.

UPDATE: The slides are now available at http://brdy.in/mobilemvc

Most (good) developers talk about using the most appropriate technology for the job.  At its most basic level that means choosing Objective-C for a resource-hungry iPhone app, or writing your latest facebook-killer application for the web rather than the desktop.  That stuff’s obvious.  The more idealist polyglot programmers will take it further and push Ruby on Rails for web apps with a small budget, or they’ll suggest using RavenDB and deploying to AWS because all you need to do is store and retrieve documents across the web. If you’re in a Windows environment with a team running Scrum, choose TFS, C#, and SQL Server.

So “Horses for Courses” right?

The aim is valid and noble, and it’s certainly one I strive for.  But one thing frequently gets overlooked, and that’s the people on the team (or to stretch the metaphor – the jockeys).

If you have a team of programmers who are very used to writing software using certain technologies, think very carefully about advising them to move to something else. I’m not saying don’t do it (in some cases you really should), but there comes a point where the benefits to be gained by using language X on platform Y with source control Z just aren’t worth the trouble.

Unfortunately, most programmers write code in one way. They use one language, they know one data storage mechanism, and they’ve only ever written applications for one environment.  Maybe in a past life they tried out some other language, and maybe they dabble in HTML occasionally, but they’re only experts at one thing.

You, on the other hand, might look at a set of requirements and decide a NoSQL data store running behind RoR is the “best” solution for this project. Similarly, you recommend using git as the “best” source control system to use. Great. Unless you’re the only one who knows this stuff – then you’re dreaming.  If you have a team of C# developers, you’d want to have a pretty good reason for suggesting they program in a different language. If every other project they’re working on uses TFS, learning git is going to introduce a lot of overhead (initially).  Sometimes, the current way of doing things is the “best” way, even if the idealist in you disagrees.

Now, that’s not to say it’s never a good idea to force a shift within a team.  Consider a team of VB 6 developers who, for the last 15 years, have been dutifully writing VB windows applications with an Access back-end. At what point do you tell them it’s time to move on? (Ideally it would have been at least 5 years ago, but that’s clearly not an option). Assuming you don’t outsource or “refresh” the team, you should strongly suggest they change, but acknowledge that the extra effort they’ll have to put in will increase the work. Also be aware that you’re unlikely to get a quality solution from them if they don’t yet know what they’re doing.

My point is, when choosing the right technology for the job, consider everything, and that includes the skillset of the developers.

With that in mind, blog posts encouraging everybody to stop using .Net because it sucks, or telling them they should never use pure HTML and JS for business apps are just ridiculous. Yes, you might have had an overnight change of heart and now realise language X is the worst thing in the world, but you’re thinking about the specific situations you’ve been in, and developers with specific skills (usually just the individual author). If your whole team can just up and move to Ruby, then fantastic! Say hi to the rainbow coloured unicorns for me!

It’s always good to encourage teams to learn new technologies. It’s occasionally good to force a team to move on, but sometimes the “best” way isn’t the “ideal” way.

How to be a Good TFS Master

I recently gave a talk at the Qld ALM User Group on the topic of “How to be a good TFS Master”.

Hopefully those who turned up got some great tips on how to use TFS more fully, but the main points I hoped people left with were:

Most people only use about 20-30% of the capabilities of TFS

In our experience, the majority of companies using TFS are using it for source control only.  SSW helps teams get closer to using 80 or 90% of TFS where the real advantages can be felt. There are some fairly significant infrastructure costs associated with getting to 100%, and we find most organisations don’t want to go that far.

TFS is much more than source control

In fact, if you’re using TFS purely for source control, you’re doing it wrong! You might even be better off using Git or Mercurial.  The best option (of course) is to start using TFS more fully to help you get the best out of your team.

TFS supports your Scrum process beautifully

TFS has some awesome capabilities that allow you to manage and support your entire scrum process. The integration story is compelling; allowing you to tie code changes directly to user stories, produce genuinely useful reports for your managers, and enforce your policies and coding standards allowing you to tick items off your Definition of Done without any effort.

For more information or some reminders of what I spoke about, have a look at the slides on Slideshare - http://www.slideshare.net/damovisa/how-to-be-a-good-tfs-master

However, I really don’t want to write 50 methods to return lists for each of these objects.  Thankfully, the solution is relatively simple – write a generic method to return the appropriate data.

Implementing this wasn’t quite as easy as I thought, but I got there after a bit of experimentation and, I’ll be honest, a fair bit of googling.

To demonstrate, let’s look at an Entity Model with a subset of the AdventureWorks database.

An Adventure Works Entity Model

In particular, look at the red outlined objects.  These are likely to be referred to frequently throughout the application as simple lookup tables.

We want to write a single generic method that will return an IEnumerable of these objects so we can use them quite simply as lookup tables.

Here’s what I ended up with:

AdventureWorksEntities adventureWorksEntities = new AdventureWorksEntities();
 
public IEnumerable<T> GetLookup<T>() where T : System.Data.Objects.DataClasses.EntityObject
{
    try
    {
        var key = typeof(T).Name;
        // 1. we need the container for the conceptual model
        var container = adventureWorksEntities.MetadataWorkspace.GetEntityContainer(
            adventureWorksEntities.DefaultContainerName, System.Data.Metadata.Edm.DataSpace.CSpace);
        // 2. we need the name given to the element set in that conceptual model
        var name = container.BaseEntitySets.Where((s) => s.ElementType.Name.Equals(key)).FirstOrDefault().Name;
        // 3. finally, we can create a basic query for this set
        var query = adventureWorksEntities.CreateQuery<T>("[" + name + "]");
 
        return query.ToList();
    }
    catch (System.Data.EntityException ex)
    {
        throw new ArgumentException("Invalid Entity Type supplied for Lookup", ex);
    }
}

Now we can use the following code to return a set of all items of the appropriate type:

AdventureWorksRepository repository = new AdventureWorksRepository();
var states = repository.GetLookup<StateProvince>();
var addressTypes = repository.GetLookup<AddressType>();
var territories = repository.GetLookup<SalesTerritory>();

This has saved me countless hours of writing boring plumbing code.

Hopefully, some of you are already looking at this thinking, “couldn’t I take this a lot further and provide a set of generic data access methods for everything?”. The answer of course is yes.  I haven’t gone quite that far yet, but I wouldn’t be surprised if it was down the track.

The problem was that this was a live site that received several thousand hits a day. I wanted to be able to quickly find my specific requests in the IIS log.

My solution?  Give my browser its own User Agent string.  That way I can search for my specific entry in the appropriate log file.

I was using Firefox for this investigation.  It’s fairly easy to change your User Agent string:

• Go to about:config in the address bar of Firefox
• Right-click in the window and choose New | String.
• Call the Preference Name, “general.useragent.override” and set the Value to something you’ll recognise.  It’s usually safer to take your existing User Agent string (which you can find at http://whatsmyuseragent.com/) and just append something unique.
• Go to http://whatsmyuseragent.com/ and make sure your change has persisted.

To undo your change later, just return to about:config and delete your override entry.

Now when looking through the IIS logs, you can just search for your specific User Agent string to find your entries.

Tip: See here for instructions on changing your User Agent in Chrome, and here for some help in IE 8.

Using WebcamViewer to show a webcam on your computer desktop

I went along to see Leon Bambrick and Joseph Cooney at the Queensland MSDN User Group meeting last night. The attendance was amazing – they had to open up a partition to the adjacent room and every seat was filled.

Leon and Joseph spoke about ASP.NET MVC 3 with a particular focus on the tooling around it, and delivering sites for mobile devices.

One slightly off-topic tip I did pick up was from Joseph when he needed to show his MVC site on different mobile devices. It’s a simple tip, but very effective.

Tip: To show a mobile device, use a webcam:

1. Hook up a USB webcam to your presentation laptop
2. Point the webcam at the mobile device on your desk
3. Show the webcam screen on your computer/projector (I recommend WebcamViewer)

Pretty easy, huh?

The key point for me is that using a camera pointed at an actual device gives maximum believability.

You can use an emulator or a browser with a spoofed user-agent string, but it won’t engender as much trust with the audience. In particular, using a browser or emulator with the full power of your computer behind it can make things appear nicer than they actually are; particularly when it comes to site performance and demonstrating a touch device with a mouse.

For more presentation tips, see the SSW Rules to Better Powerpoint Presentations.

You may remember me briefly talking about this topic in an earlier post, as it’s something that I’m fairly excited about.  The general idea is that most software just does exactly what the user asks.  You give it some explicit input, it gives you some output.  Participative Software is my name for software that makes suggestions and “participates” without explicit input.

Watch the video for more details.

The five minute time limit meant that I didn’t quite get my point across as well as I’d hoped.  I’d like to present the topic over 20 or 30 minutes so I can really drill down on the subject and include a bit more of a call-to-action.

As always, feedback is more than welcome – especially if you’d like to hear a 30min version!

Day 2 begins

Adam exercises his negotiation skills and saves us 25 cents

Day 2 started a lot smoother than Day 1 because we now knew the way to the venue.

Bonus 1: Today, we made it to the training venue in only 3 minutes vs. 1.5 hours yesterday. Talk about continuous improvement!

Today’s agenda saw a lot more interaction with the lovely Team Foundation Server (TFS).  It was time to see Scrum in action with the Microsoft tools.

Impediment 1: We were expecting a room full of cables to a switch, but unfortunately the training venue only had wireless.  There was no way for students to connect!  Matthew Hodgkins spent some time setting up laptop for us to bring along to the course.  It was set up with domain server and a TFS Virtual Machine ready for all the students to connect to.  With a lot of help from Matthew and Parmod Kumar (one of the Sysadmins working with the students), we got the server reconfigured so everyone could connect.

Parmod Kumar and I setting up TFS over wireless

Work Items in TFS

Adam Cogan started the day by cracking open TFS and walking through the work item world:

• Creating a Team Project
• Team Collections
• Areas and Iterations
• Managing Sprint Work Items
• Creating some Product Backlog Items
• Creating and Linking a Task
• Creating and Linking a Test Case
• Creating and Linking a Bug
• Managing Impediments
• Adding Check-in Policies

Adam C professed his love for Story Overview reports and also Priyanka Chopra – in his opinion the most beautiful girl in India.  He also spoke about his “tough” guts and what a “handbreak” Adam S and I were for not eating street food with him.

He let the teams have a quick break while he introduced them an awesome tool called Debugger Canvas.

Then it was on to TFS integration with Microsoft Excel and Project 2010, TeamCompanion, and UrbanTurtle.

Adam C introduced the first sprint of the day by telling everyone that there was a new Product Owner. He talked about all the things this new PO might want, so they would be well prepared when he arrived.

A new Product Owner arrives

The new Product Owner (this PO was a bit of a sweetie)

This new Product Owner was a bit odd.  He talked about his new wife, the new Tailspin website he purchased, and the Chinese developers he had sacked.  He told them about the bugs some people had told him about, and asked them to:

• Connect to TFS
• Log in to the SQL database
• Create a Team Project
• Add the 2 check-in policies he had heard about at a Microsoft seminar (being the “comments one in the Powertools”, and the “work items one that comes out of the box”)
• Check that the code from the Chinese developers compiles
• Tell him where he stands, and whether those Chinese guys were truthful when they told him it was “99% done”

The girls (Shilpa and Pomey) instructing the boys

The students had been given so much new information that morning, we were interested to know what they actually “heard”.

Review

All of the teams did OK considering this was their very first technical presentation.  We all know the human brain starts working when you’re born, and doesn’t stop until you stand up to speak in public.

Interestingly, they were very keen to show the Product Owner *all* of the work items they had created.  They had a very different idea of what they had to do.

There were a few impediments this time, however.  The teams found that they needed to install TFS Powertools in order to add the Check-in Policies.  Due to frequent power outages (apparently rampant in summer), this seemed to cause a lot of problems.  “Team Masters” had even added an impediment to TFS saying that TFS was down and was blocking them!  The Product Owner looked at them very incredulously.

“Team Scrumsters” actually fired up the new application and showed it working.  They were the only team that got the Product Owner jumping up and down with excitement.

The new Product Owner getting excited when he saw his new app Tailspin running

Before the Product Owner left, he played a video to introduce the students to some of his “American culture”. He played a Charlie Sheen video and talked about the importance of “winning”.

Retrospective

The big lesson that came out of the acceptance criteria was that the teams didn’t clearly understand what the Product Owner wanted.  Every team had a very different idea of what was required:

What Team A heard:

• Create a Team Project
• Create a SQL Server
• Create a Product Backlog
• Create some Test Cases
• Q: How many PCs do you need to get the code working on?
  A: 3 PCs
• They forgot their backlog and their burndowns (they worked from their standups)

What Team B heard:

• Create a Workspace in TFS
• Create a Check-in Policy
• See if we can increment items in the shopping cart
• Q: How many PCs do you need to get the code working on?
  A: 2 PCs
• They forgot their standups, backlog and burndowns

What Team C heard:

• Get Latest, and Build
• Fix the code for multiple items
• Make a Burndown chart
• Q: How many PCs do you need to get the code working on?
  A: 4 PCs
• They forgot their standups, backlog and burndowns

What Team B heard:

• 7 clear items were heard from the PO
• Get TFS going
• Get the TFS Power Tools installed
• Create the Tasks
• Create the Test Cases
• Q: How many PCs do you need to get the code working on?
  A: 1 PC
• They forgot their standups and their burndowns (they worked from their backlog)

Lunch

Once again, lunch was delicious.  Adam Stephensen asked heaps of questions about the selection of traditional Indian foods, the answers being fascinating.  He’s on track to come home with some new recipes!

Selection of traditional Indian dishes for lunch

After lunch, Adam C treated the group to some Australian culture in the form of an ad for Fosters.  He followed this up with a (remarkably similar) Canadian Molson video and was disappointed when the group preferred the Canadian version!

Example meetings

During lunch, Pradeep requested they see how the Aussies do their planning and standup meetings.

Adam C asked Adam S and I to stand up in front of the class and start work on a new sprint.

• We started with the creation of a backlog, estimated tasks (using the “Fist method”), and created a burndown
• We started and finished day one, and just as we finished,
• Adam got us to do a day 2 standup, complete with a burndown update

Adam S and I estimating tasks in our Planning meeting

Bonus 2: This ended up being quite worthwhile.  Some of the students said it was the highlight as they got to see how it was “meant” to be done.

Adam C played the students a Karate Kid video to highlight the point that following the Scrum process is like developing muscle memory. If you follow the process, it starts to become second nature and you reap the benefits.

Sprint 2

Sprint 2 saw the teams get deeper into the solution.  They were asked to enter some more Product Backlog Items and make sure each person raised a bug.

One of the teams estimating tasks using the "Fist method" estimation method

Bonus 3: This sprint, every one of the teams did a standup and one team implemented the “fist” estimation technique.

The Review and Retrospective meetings were are lot more impressive this time.  All teams did a great job with their presentation and the Scrum process was finally in action in all its glory.

To close off the day, Adam C played a video showing how Emperor penguins work as a team for survival in Antarctica.  He emphasised the importance on the team in the Scrum framework.  If everyone is prepared to give their bit for the team, it will benefit everyone.

Retrospective Day 2

There was a lot of great feedback from the students on how the day went.  Some of the many highlights the group mentioned were:

• Learning to focus on what the Product Owner wants, not the process
• Seeing the tool (TFS) was much different to just knowing the theory
• The demo of the “Aussie” planning and standup meetings
• The Karate Kid story – the group now knows this is something to follow day in and day out
• Learning what Scrum terms map to what TFS work items
• The Excel and TeamCompanion demos
• Working as a team
• Doing the exercises
• Learning about Check-in Policies
• Moving from theory to practical implementation
• The story of the Antarctic penguins and the importance of working in a good team

Tomorrow will see us delve deeper into Scrum using TFS and we’ll look at using Microsoft Test Manager to help run tests and raise very rich and repeatable bugs.

It was such a fun day, we decided to sit down and write a blog post together.

Pre-day one

We decided to catch a couple of tuk-tuks to the venue.  Adam Cogan somehow managed to send emails on his iPad while cramped in the back.

Setting off on our way…. little did we know that the driver had no idea where he was going

One of the important things you learn about in Scrum is an Impediment.  Even before day 1 started, we had our first one.

Impediment 1: The distance from our hotel to the training venue was about 2km.  The 1.5 hour journey (yes, one and a half hours) to this venue on the first day included three lost taxis (two independently finding their way to the same wrong address) and several near-death experiences.

Tip: Don’t think about complaining to your tuk-tuk driver or else you will find him try to make you happy by driving the wrong way down a busy main road.

Our tuk-tuk driver saving time – you have no idea how we felt.

Getting Started with “Scrumdementals”

Impediment 2: Day 1 officially started with Adam C noticing that only one of the 24 students had read the Scrum guide. To bring everyone up to speed, he was able to give a succinct rundown of the Scrum user guide with the help of a few SSW rules (The importance of a team, Reading the Scrum Guide, and Physical Task Boards) and the awesome “Scrum Master in Under 10 Minutes” video by Hameed Shojaee.

The “guts” of Scrum was covered, with particular reference to short iterations, multi-skilled teams and timeboxing.  Adam C also told a story about his years in the army, and pressed  the point about the “inspect and adapt” tenet of Scrum which got a laugh.  The army tends to plan a mission, watch it all go very differently, and then debrief so they can adapt.

Adam C telling the team what they "said", but what the Product Owner really "heard"

Adam C talked about the burndown and asked which time fields in a User Story mattered for the burndown.  Two of the 24 students already knew that the only time field that Scrum cares about is the “remaining time”.  He went on to explain why this was, and why the “original estimate” and “actual time” spent fields aren’t as important.

User Stories

After a morning break, Adam Cogan spoke to the group about User Stories. Everybody loved his quintessential example with accompanying story:

As a marketing manager
I want to search for customers
So that I can call them up

He followed this up with a discussion about Acceptance Criteria and why they were so important.  Referencing the SSW rule on Acceptance Criteria, it was pointed out that you should never assume “gold plating” for a User Story.  The group appreciated the clarification on acceptance criteria and agreed that it was important for clarity.

Adam C’s next instruction was for each student to write one of their current working items in the form of an SSW story card.  Some were good, and some were not so good.  I reviewed my favourite ones and shared them with the class.

Rohit Arora’s great Story Card

Manish Yadav’s great Story Card

Sanjay Saini’s great Story Card

Amit Choudhary’s great Story Card

Sprint One

After lunch, the group was asked to self-organise into four teams of six.  Initially, the groupings weren’t ideal (all the developers with MVC experience were in the same team), maybe the ‘multi-skilled’ point was forgotten… a quick bit of shuffling was required.

The teams really worked well together

Bonus 1: Even though team members were being split up, the new teams worked really well together.

Next, the Product Owner entered the room and scared everyone with his tough requirements. He is a Product Owner you don’t want to mess with.

The Product Owner giving his requirements

He spent 10 minutes (timeboxed) giving out requirements for the first one hour sprint. The task was to create a poster for his boardroom.  The sprint was split into four 15min “days”, after which the teams presented the results in the review meeting.

Impediment 3: Every half hour or so, a “black room event” occurred.  No, not a “black swan event” .  Apparently power outages are fairly common in Delhi, but every time it happened, the laptops switched to battery and all network connections were lost.

Adam C saw this message pop up on his PC quite a lot:

The all-too-common Battery Monitor message

The post-sprint Review meetings were fun with the teams presenting some different results in their work.  The Product Owner was hard to please, but we think under that tough skin, he was generally pleased with the work.  The same can’t be said about the process.  In the end, he chose his favourite diagram to hang on his boardroom wall.

The Product Owner’s favourite diagram had some excellent artwork

The Retrospective meeting was even more fun and the teams learnt some very valuable lessons.  However, Adam C explained that every one of the teams was naughty:

1. Only 1 of 4 teams took up the invitation to speak to the Product Owner about what he wanted
2. 2 teams did a User Story for the task (despite Adam C giving several “Printed Story Cards” to each team)
3. None of the teams kept a Backlog
4. None of the teams did a Daily Standup, and
5. Only 2 teams followed the brief and included pretty pictures (this was very important to the Product Owner)

Later on, Adam C presented his ideal Scrum diagram and spoke about how it clearly shows the Scrum process from start to finish.

Adam Cogan’s ideal Scrum diagram

Retrospective

The day ended with a retrospective where each student talked about what they liked and disliked about the day.

The top two highlights of the day – repeated multiple times – were:

1. Writing User Stories and learning about why the wording was important
2. Learning about effective acceptance criteria

The students said they were very happy with the course so far. They wanted 2 things improved for the next day:

1. There weren’t enough videos (we’ll fix that on day 2!)
2. Lunch was too early

Can’t wait for Day 2.

Taking a job at SSW as a Senior Software Architect is an exciting move for me. I’m expecting Adam Cogan and the rest of the team at SSW to coach me to be a better developer, trainer, team leader and Scrum Master.

I will work for a wide range of customers and I’m sure I’ll face many challenges, which I look forward to solving using ALM and a good Scrum strategy to find the best solution.

What does this mean?

This new job will bring a few new things:

1. I’ll be running the Brisbane office for SSW. This means meeting new customers, leading teams, and getting some SSW branding out there (probably by implementing some Rules to Better Branding)
2. Rules and standards. These are part and parcel of working for SSW.  It’s something they’re known for as a company and I will play a part in many of the new rules.
   Some of my favourites at the moment are:
   • Rules to Better Email
   • Rules to Happy Clients
   • Rules to Successful Projects

   And there are some I like but I can see myself contributing to in the near future:

   • Rules to Better Unit Tests
   • Rules to Better Interfaces – Mobile
3. Scrum and ALM. This will be a very big part of my work.  I’m looking forward to continuing to learn and implement effective Scrum at SSW and for a lot of clients. I’ve long had an appreciation for effective Scrum but, even in my first month, I can see even more that it is imperative to being able to deliver good software. In the next 6 months I will become both a Certified Scrum Master and a Professional Scrum Developer Trainer.
   In particular, I’ll be focusing on
   • Scrum
   • Automated Functional Testing
   • TDD (where appropriate)
   • BDD
   • Continuous Integration
   • Continuous Deployment

   These are all pieces of the same puzzle and with the right combination, you can ship solid code quickly that really meets the customers’ needs.

4. Cutting-edge technology. Keeping up with cutting-edge technology is something SSW really values. They have two Microsoft Regional Directors and three MVP’s so it’s hard to argue with their expertise.
   I’m looking forward to working a lot more with the following technologies:
   • Visual Studio 2010
   • Dynamics CRM 2011
   • SharePoint 2010
   • ASP.NET MVC
   • Orchard CMS
   • Team Foundation Build 2010
   • Microsoft Test Manager and Telerik Test Suite
   • All things Microsoft .NET 4

   But there are some technologies I’m happy to leave to the other guys at SSW:

   • Silverlight 5
   • DotNetNuke

   I’m planning to delve deep in a lot of technologies to work out which are the best to use.  It’s important to have a wide skillset with expertise in a few key technologies.

5. Working with Telerik. SSW has a good relationship with Telerik and while I do use other 3^rd-party tools, Telerik is by far the most common at SSW.
6. Effective Communication. One of the first things I noticed with SSW was their attention to effective communication. If I took nothing else from SSW it would be the Rules to better Email which, if followed sensibly, helps me function really well as a member of a team.  Email can be a very effective tool and the last thing you want is a “What did you mean by that?” reply.
7. My blog. I expect my blog to get a lot better with posts about the things I’m working on.  In the foreseeable future I anticipate posts about:
   • Setting up an effective remote work environment
   • Upgrading customers from VB6 to .NET
   • Upgrading customers to TFS 2010
   • Migrating customers from onevTFS Process template to another using the TFS Integration Platform
   • Upgrading SharePoint from 2007 to 2010
   • Upcoming Public and Private Professional Scrum Developer courses
8. Training (on both sides of the podium). I’m looking forward to both learning at courses and running courses for others.

What’s next?

First things first. If you are in QLD and you are looking for a MVC/SharePoint/CRM/TFS/ALM consultant/team, give me a call!
Having an office in Brisbane means that SSW is much better equipped to provide these expert services.

Keep an eye out for me at the Brisbane user groups, conferences, and any tech event.  I’ll be even more active than before in the Australian tech community.  I look forward to having chats with other Brisbane-based techies.  And if you’re sick of the technology talk, feel free to branch out.  As a long-suffering St Kilda fan, I’m always happy to talk about all things AFL.

I’m excited about this next chapter in my professional life, and I’ll be sure to keep this blog up to day with all the challenges it brings.