Screencast: Strongly-Typed Views in ASP.NET MVC

In this screencast I discuss the how to create strongly-typed razor views in ASP.NET MVC. We look at how Models can be used to pass data (both simple and complex) from controller action methods down to razor views. We also look at the concept of ViewModels which hold aggregate data to pass to views. Finally, we cover some of the tooling for generating views in Visual Studio.

Download the code: Kennedy.Mvc.StronglyTypedViews.zip

Advertisements

Correction: Business Analysts & C3 project

In a couple of blog post, and on other occasions in other places I have talked about there being a Business Analyst working on the original Extreme Programming (XP) Chrysler C3 project.

I’m not sure where I picked this piece of information up but I was wrong. One, Chet Hendrickson of the original team read my post and the team actually had direct access to the payroll team to understand what was needed, agree acceptance criteria, etc.

The Wikipedia entry on C3 discusses a “customer representative” on C3 and indeed Extreme Programme suggests you have a onsite “customer”. Somewhere along the line I read, was told, or just got the impression that this person was, on the C3 project a Business Analyst. Now I see I was wrong.

Having set that, I would still suggest that a Business Analyst can fill the role of customer representative and often have experience and training in doing this. I will accept that sometimes a BA doing this might become a block and it would be better for the team to talk directly to the customers.

Unspoken Cultural differences in Agile & Scrum

For a while now I’ve been convinced that a lot of “Agile” is about cultural differences. In particular I believe the canonical version of Scrum, which I often refer to as Hard Core Scrum or Scrum™ is rooted in 1990’s American software management culture.

Unfortunately the role of culture behind many Agile techniques and methods isn’t really stated. This make it even more important to work out what Agile means to you and which tools work in your environment and culture.

I first started paying attention to the cultural differences around teams and Agile after Steve Freeman said something along the lines of “Scandinavian teams just do this, they don’t see much new.” The teams I’ve seen in Scandinavia, and to a lesser degree Holland and the UK, don’t need big lectures in self-organization, left to themselves they do most of it.

I’ve pondered on this for some time and at Agile Cambridge last month I got the chance to talk a little about this with Dave Snowden. We only had a few minutes to talk about this – I was about to present – but it was clear we could have talked for hours.

Take stand-up meetings for example.

When I worked in Silicon Valley I worked in a cube. I hated it. I didn’t even know if my neighbours were in the office, let alone what they were working on or if they had achieved anything that say.

Working in the UK, in open plan offices, usually sitting opposite my co-workers we would certainly know who was in, most likely they would tell me when they had done something.

I believe that stand-up meetings are a good thing in all teams. However I believe they make a much bigger difference in cube and office dwelling environments than in open plan offices. In other words: stand-up meetings have greater benefit in US offices than they do in European offices.

In the original book of Extreme Programming Kent Beck talked of a “sustainable pace” and “40 hour work week”. Beck talks about his experience in Switzerland and contrasts it with the US norm. Although European workers – particularly in the UK – frequently work more than the 40, 37.5 or 35 hours they are contracted for they work hours don’t get excessive for too long. I’m not sure that is the same in the US. Sustainable pace means different things.

Personally I’ve always found “sustainable pace” does not fit well with the Scrum idea of “commitment”. I’ve written before – Two Ways to Fill an Iteration – about the contractions I see. Culturally it isn’t hard to see how “sustainable pace” is easier to do in Europe than the US.

(By the way, I’m limiting myself to the US and European, specifically UK, cultures because these are the ones I have some experience of.)

Now lets talk about the big one: Self-Organizing teams and evil managers.

(Apologies if this comes across as Scrum bashing, I believe Scrum works, or at least Scrum-lite works, and I believe self-organization is best. I just don’t believe hype.

Some Scrum courses and advocates make a big thing out of self-organization. Personally I don’t. In my courses I I talk about it a little, more if people want to, but I focus on giving people experience of how it works. My style of Agile – yes I’m slowly writing up Xanpan – believes that self-organization is the result of the right approach not a stating point.

Self-organization goes hand-in-hand with an attack on Managers, and in particular Project Managers. Again this theme runs through all Agile but in Scrum is particularly strong. Hard-core Scrum really has it in for Project Managers but then replaces them with Scrum Masters which most companies think is just the same job with a different name. I’ve written about Scrum’s contradictions with Project Managers before so I won’t repeat myself, When did Scrum start loving project managers?

But Scrum’s dislike of managers only goes so far. After all, Scrum is the management friendly version of XP – see Scrum has 3 advantages over XP.

Now I’m not a big fan of Project Managers, in my programming days I too suffered a few managers who tried to hand out tasks and impose their way of doing thing. And I’ve been told No when I want to spend a little money – I once threatened to leave the company if they didn’t buy more RAM for my development box.

When I look back over my career I have to say most of the (project) managers who behaved like this made themselves irrelevant. We worked around them. Certainly removing them would have made us more effective.

But, most of my experience is that managers, even project managers, didn’t behave like this. They may not have been the most empowering of people but generally they left me, and programmers I worked with, to get on and do it. We worked out what needed doing, we divided the work up amount ourselves, we scheduled at the micro-level.

In other words: we did self-organization on a day-to-day level.

Again I think there is a cultural difference here. In my experience America is a more hierarchical culture than Europe (with the possible exception of Germany). Please, I’m not talking class systems here, I’m talking command and control.

I think Europeans are more likely to question their managers to their faces – perhaps it was the 1914-18 experience – or just plain ignore them.

National characteristics are not the only basis for culture. Industries have cultures too. Here again I’ve written before: Agile will never work in investment banking – one reason being that investment banks are very hierarchical.

Most of the managers, even project managers, I meet when delivering Agile training courses and consulting, like the Agile approach and want to work with it for the benefit of their teams. Few seems to be the whip-cracking project managers of folk lore.

Jon Jagger tells a story about one of his clients in Norway. The company was bought by an American competitor. When the engineers started to work together they would convene a teleconference. The American programmers would arrive with their managers while the Norwegians would arrive by themselves. The American’s would ask “Where is your manager?” The idea that the Norwegian could talk and make decisions by themselves was a new idea.

I had a manager in California – Irish as it happened – who used to practice “management by walking around.” Every morning he would appear in my cube and chat. Took me months to realise he was my manager and when I did I wished I had been more guarded with some of my remarks.

This all begs the question, why would American management be such a hinderance to software development? (Note I’m not saying European management is better, that has its own faults, I’m just exploring different cultures.)

For many years the USA was the world foremost manufacturing nature. Part of this success was the superior management practise implemented by the Americans. Such practices made a difference on the factory floor but even here they have been .

I can, and should, write more about managers and their role in the software team. Suffice to say for now: there is an awful lot of bad management out there. I believe good managers, good management practices, can be help companies massively. But on the whole, in the IT industry, there is a lot of poor management.

Bringing this back to Agile.

I think Agile’s anti-management slant is really a reaction to bad management. Hard-core Scrum is the Extreme in this respect. Scrum-Lite, as practiced by most teams, is less so.

Agile, and particularly Scrum, is the product of 1990’s culture, and particularly American work/management culture. Since American culture spreads the fact that Europe never suffered from quite these ills may down to the fact that we were not that good at copying American ways.

There may be a silver lining here: if America adopt Agile, Scrum, self-organization, etc. then we should see it spread out to the rest of the world.

If you disagree with me I’d love to have your comments on this blog. And if you agree I’d love to hear your stories to. Please, leave a comment.


Dialogue Sheets feedback and stories

Retrospective Dialogue Sheets continue to be a popular download, and I’m off to Sweden in a couple of weeks to present the sheets at Oredev. Unfortunately I haven’t had time to review the downloads to extract any useful information from the several thousand downloader details but I do continue to get some interesting feedback.

A few months ago Gail from Siemens Healthcare e-mailed me to tell me how she had used the sheets to conduct a distributed retrospective. The team in India had one sheet and conducted their retrospective in their work hours. Several hours later when the US team arrived at work conducted their own retrospective using another sheet. Gail then gathered the findings and reviewed the two sheets and conclusions which were complementary.

More recently I heard from a Scrum Master at Stattnett in Norway about their use of the sheets. What follows is a (slightly edited) account which nicely describes why many people like the sheets:

“thank you for the sheets! We’ve now used them in two retrospectives, and we will continue to use this technique for the future.

My main reasons for applauding their use:

  • The sheet stimulates equality among team members during the discussions, by the fact that all must be seated around a table (no one standing up and facilitating the discussions).
  • The sheet rules demand at least some contribution to the process from each team member during the session, by reading out questions loud – and also decide for themselves what is needed to read (and not to read).
  • The sheet is very physical and with few/no barriers for participants to express themselves on the sheet for everyone to see – even if it is only by drawing “stick men” on the edge (next time, maybe even the stick-man-painter will write some words on the sheet).
  • The sheet and rules (when followed) prevent the Scrum Master from falling into a “team leaderish” role when the rest of the team gets lazy and wont’t bother to involve in the process – they all have to take their part of a common responsibility for getting through the questions and to the end of the “game”.

These characteristics make our retrospective sessions less bureaucratic and more inspiring than with our old technique. We have been using the more traditional technique for several years, with each team member preparing notes before the meeting, writing successes and suggested improvements (often as complaints…) on green and pink paper memos.

The notes were then collected on a whiteboard and discussed and voted on at the end – with the Scrum Master (me) as facilitator. This preparation of notes [was rushed] and no one really likes to do this. Going through each and every note was time-consuming duty with debatable value. [In the end] the retrospective meetings became quite uninspiring form for all of us.

But with the dialog sheet, we now have a better, more inclusive and more constructive climate in the meetings. We spend our time on issues of real value to the team instead of ceremony parts no one really likes, and more in line with the original intentions for this session.

The sheet can be put directly on a wall after the meeting, for everyone to see. I don’t have to make any kind of additional summaries anymore (as I did, even if core scrum doesn’t prescribe this). I can instead take a photo of the sheet for the record, if needed.”

I regularly hear that of teams who hang the completed sheet on the wall as a reminder of the discussion and conclusions. I have also heard of a team who hung a blank sheet on the wall at the start of an iteration and team members filled in the timeline as they did the work.

Finally, I recently discovered a blog posting from University College Dublin which used the Dialogue Sheets as part of student retrospective exercise. I don’t believe these are the first College to do so, University of Central Lancashire might have that honour.

Since I learned about the sheets from Cass Business School in London I like the idea that the sheets are going back to college!


Integrating Claims and OAuth2

I just created a sample library that illustrates how Claims can be easily integrated when using OAuth2 identity providers for authentication. I created the OAuth2 library from scratch (it was quite straightforward). In this library I wanted to hide as much of the OAuth2 protocol and claims mapping as possible so that a consuming application would just have to say which OAuth2 provider to use and what page/URL to return the user to once all the login and claims magic has happened.

Is very easy to use from MVC (these client IDs and secrets are throw-away):

static void RegisterOAuth2Clients()
{
    OAuth2Client.Instance.RegisterProvider(
        ProviderType.Google,
        "421418234584-3n8ub7gn7gt0naghh6sqeu7l7l45te1c.apps.googleusercontent.com",
        "KDJt_7Rm6Or2pJulBdy0gvpx");

    OAuth2Client.Instance.RegisterProvider(
        ProviderType.Facebook, 
        "195156077252380",
        "39b565fd85265c56010555f670573e28");
            
    OAuth2Client.Instance.RegisterProvider(
        ProviderType.Live, 
        "00000000400DF045",
        "4L08bE3WM8Ra4rRNMv3N--un5YOBr4gx");
}

Here’s my view to give the user a choice as to which provider to use:

<h2>Login With:</h2>
<ul>
  <li>@Html.ActionLink("Google", "Login", new {type = ProviderType.Google})</li>
  <li>@Html.ActionLink("Live", "Login", new {type = ProviderType.Live})</li>
  <li>@Html.ActionLink("Facebook", "Login", new {type = ProviderType.Facebook})</li>
</ul>

And then you just have a Login action method to choose the OAuth2 provider you want to use:

public ActionResult Login(ProviderType type)
{
    // 1st param is which OAuth2 provider to use
    // 2nd param is what URL to send the user once all the login magic is done
    return new OAuth2ActionResult(type, Url.Action("Index"));
}

And that’s it. Once the login has happened claims are available viaClaimsPrincipal.Current.Claims (which is where they normally are).

If you’re familiar with using OAuth2 you’re used to seeing a authorization code callback endpoint. This is a detail of the protocol I wanted to encapsulate so that the consuming application didn’t have to “deal” with that. To hide this I use an AreaRegistration internally in the library to define the callback endpoint. In this area when the OAuth2 callback arrives with the authorization code, the library continues the protocol to exchange the code for a token and then uses that token to obtain the profile information for the user. Once that profile data is acquired, it is converted into claims. Then the WIF Session Authentication Module (SAM) is used to log the user in. We then redirect back to the URL indicated in the OAuth2ActionResult above. Magic!

Code is up on GitHub. Library is up on NuGet. Feedback is welcome.

I Use This

At usesthis.com they interview a bunch of people to ask about their current computer setup and their dream setup. Most of them are using aged machines, ultraportables (Mac Air is popular), and Emacs/VIM for editing (a few slickedit fans). Most of them have little to add in their dream setup (more battery life, better cloud sync). Are our tools finally good enough? Not for me.

Current setup: A 4 year old Sony Z laptop, 8GB RAM, SSD. I have a 6 year old homebrew desktop w/ a few terabytes of storage and 2 old monitors. I use Windows 7 and do most development in Ubuntu within VMware player (using Unity). When I need it, I’ve got instances running in AWS. I’ve got an ancient jailbroken iPhone, an iPad 1, and an older Kindle. Everything I own is old and works just fine. I use Emacs, bash, Chrome, and the usual grab-bag of software. I even use Visual Studio.

Dream setup: We all own a suite of devices that work OK in isolation. Each device does some things well for certain use cases. But when those devices are together, they should work together much better. Bluetooth and AirPlay are steps in the right direction, but ad-hoc and incomplete. When I sit in my car, my music and phone calls are routed through the car’s sound system. However, I can’t sync the map, listen/send text messages with my voice, nor ask Siri for help. AirPlay is really nice if you have Apple TV. You can send music, video and photos to the TV when you wish. You can send music to the stereo w/ Apple’s AirPort. Google Voice has a feature that allows you to move a call to another phone without hanging up. The Kindle can sync my current location in a book to every device, but I have to move papers and articles over manually.

I want more of this sort of slick integration between my devices. I’d like to group my work into virtual workspaces that have the same intention. Development stuff in one workspace, entertainment in another, communication in another, and so on. If I have 3 monitors, it should spread my workspaces across them. If I get a call while at my computer, I should be able to route the call to my computer’s speakerphone. When I’m reading something in Chrome on my desktop, I should be able to move it to my iPad. When I set my laptop down next to my desktop, it should allow me to move my work seamlessly to my desktop (and vice versa). File syncing is only the first step. I want my activities synced and moved across devices based on what I want, what the device is capable of, and what my work modality is (reading, typing, watching, listening, talking). Some of this can be done now in an ad-hoc way, and I’ve tried to glue the pieces together. But there’s enough friction to still make it fail in irritating ways.

We’re all going to accumulate more and more smart devices. We need to them work together better.

Teaching Kids Programming update from Molokai!

View from the balcony of our condo in Molokai

We’re on Molokai for 10 days, teaching kids to program.  We are here due to a travel grant (we are donating our time) from the MONA Foundation.  So, what are we up to here?

We are teaching both kids and teachers.  Each day our schedule is to either train teachers on how to use our TKP courseware with their kids or to directly train kids.

We have a busy schedule – today alone we taught 100 8th graders at Molokai Middle School for their second hour of Java.  Tomorrow we’ll be starting with a total of 60 K-3 students.  We’ll introduce them to programming using the visual game building environment of Kodu.

We also made some changes to our TKP website to support our work here and in the future.  I made a quick video (<2 min. recapping those changes).

CORS, IIS and WebDAV

The most common problem encountered when trying to get CORS working in IIS is WebDAV. WebDAV is installed as both a module and a handler. It wants to process OPTIONS requests but doesn’t know what to do for CORS (especially if you’re using the CORS support fromThinktecture.IdentityModel). The fix is to remove both the module and handler in web.config.

The other common problem when using the CORS support from Thnktecture.IdentityModel is that the handler for .NET code (the ExtensionlessUrlHandler) by default only allows GET, POST, HEAD and DEBUG methods. We want it to also process OPTIONS, so this needs to be configured. Fortunately in the MVC 4 templates this is configured automatically, but if you’re doing something other than MVC 4 then you will have to configure it yourself.

Here’s what your web.config should look like to disable WebDAV and allow OPTIONS for the ExtensionlessUrlHandler:

<system.webServer>
    <modules>
      <remove name="WebDAVModule" />
    </modules>
    <handlers>
      <remove name="WebDAV" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%Microsoft.NETFrameworkv4.0.30319aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%Microsoft.NETFramework64v4.0.30319aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
  </system.webServer>

HTH