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!

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.

People will start to use four distinct types of “computer”.  Roughly in order of usage, they are:

1. A Smartphone.

New ones are already being released with dual-core CPUs, and the specs will quickly get ridiculous.

New smartphones are quickly becoming a legitimate replacement to a laptop. If you’re like me, you’ll use your phone for nearly everything, all the time (I already do). The only reason you’ll use a tablet (and you will) is for the screen size.

2. A Tablet.

Internet-connected tablet PCs will sprout up everywhere with all sorts of resolutions and sizes.  The iPad was just the first, but it certainly won’t be the last.

For people in my industry, that means something new to consider when writing websites. If you have a menu on your site that drops down on mouseover, change it. Seriously. There’ll be no mouse for most of your visitors.

I’m going to go out on a limb here and suggest that if you have a website, by the end of the year more people will visit your website using a phone or a tablet than a traditional computer. If you don’t cater for those devices, people will stop visiting altogether.  Don’t wait, do it now.

3. A PC or Notebook.

They won’t go away, but you’ll notice I put them at number three. That’s perhaps a bit unfair as they’ll continue to be the “main” computer in workplaces, but I predict that a lot of people will find they don’t really use their home PC any more.

4. A Gaming Console.

Purely a gaming machine, so obviously this depends greatly on the person. If you’re spending 20 hours a week with your Xbox, you’re probably not going to stop. On the flipside, there are people like me – I have a Wii that never gets used.  That probably won’t change either.

And that’s it. Short and sweet.  Feedback welcome as always.

His main observation is that content syndication websites are starting to outrank the original content source in search results. He’s right to suggest that this is a problem; for everyone except content syndicators of course.

While I appreciate his disappointment, far from being upset by this, I’m impressed that it’s taken this long.  It also wouldn’t surprise me if this was a short term thing. As Jeff mentions, Google could probably “tweak a few algorithmic knobs” to make the problem will go away for a while.

It’s clear that Google does a lot of work to try to give you useful results to your queries.  But Google is only one company.  A single (albeit massive) company fighting to provide relevant results against an army of hundreds of millions (billions?) of sites trying to get to the front page of Google search results.

So why should we be surprised that it’s finally becoming a problem?  There are striking similarities in the history of DRM, or computer viruses, or spam detection. One protagonist against millions; all looking for ways to game or cheat whatever system they’re trying to defeat. In my opinion, Google has been orders of magnitude more effective in staving off attacks than the three prior examples.

Effective DRM is really only renowned for pissing people off (those links took mere seconds to find – in Google coincidentally), and we’re always being subjected to new viruses and spam techniques.

I hope that this trend is halted by the twiddling of knobs, but either way I’m impressed by how long Google has largely held off this threat.