If you haven’t read it yet, you really should. The digressions into software engineering history alone are reason enough to read the book. The Chandler part of the story may strike some as a cautionary tale of what not to do when developing new software, but I found it an accurate description of the kinds of unexpected issues and challenges that crop up in any large software project.

Go out and get a copy from your local library or buy the new paperback today. It is a great read.

Topics at CodeMash are varied and atendees are encouraged to attend sessions outside their comfort zones. I see CodeMash as a valuable way station on the raod from journeyman to master, a place where the pragmatic meets the esoteric and the everyday programmer can be exposed to ideas and practices that illuminate the deeper nature behind and practices of software engineering. I certainly had that experience this year.

The first day was packed with events. Our first keynote was delivered by Neal Ford, Software Engineering & Polyglot Programming. The takeaway was a vision of the future of programming where the language is separate from the platform and we take advantage of solid runtime platforms like the JVM or .NET CLR while casting aside the cumbersome languages traditionally associated with them in favor of more productive, more dynamic languages. For example, Groovy on the JVM or IronPython on .NET. In Ford’s view,

Testing is the engineering rigor of software engineering.

By combining dynamic languages on solid runtimes with rigorous testing practices, software “engineering” can begin to live up to its namesake.

Joe O’Brien’s Ruby Testing Mandatory talk was one of those “outside my comfort zone” talks, as I know very little about Ruby. But, the testing support Joe showed was quite impressive. It is a mandatory practice because:

1. It’s included in the language
2. It’s easy & you can make it easier
3. There is nothing you cannot unit test in Ruby

With a powerful, dynamic language like Ruby, you can easily do stupid things, but testing can help you catch problems earlier, mitigating the risk. This conclusion sounded, unsurprisingly, like Neal Ford’s keynote. But, I was sold on the importance of testing last year. The take away from this session for me was seeing how awesome the Ruby tools are. I think I briefly experienced the Reality Distortion Field that seems to be increasingly turning otherwise rational programmers into Ruby zealots. I’ll definitely be making some time over the next few months to play with Ruby.

Continuing on my non-.NET language tour, I stopped by Catherine Devlin’s, Crash, Smash, Kaboom Course in Python session. It was a very code heavy session and I surprised myself by already knowing much of what she discussed as she introduced Python programming via the development of a solar system modeling program, complete with realistic gravitational forces and exploding planets. It was a fine introduction to the language and I was relieved that the example project was not yet another Web app. Yes, Python can do more than Web pages.

After lunch, I had the great pleasure of seeing the best keynote of the conference, Mashing it up with IIS7, delivered by Scott Hanselman. The talk of the conference was actually the first ten minutes of his presentation which was, basically, stand-up for geeks. When the keynote presenter uses LOLCat slides in his presentation, you know you are in for a good time. The presentation itself was on hosing PHP on IIS7. Despite some technical difficulties during the presentation, it was great. I wish we were upgrading soon because I was sold on the new feature set. I am actually starting to gain a little respect for the IIS folks. I’m not ready to give up my beloved Apache, but IIS7 looks sharp and I hope I get to play around with it soon.

As an aside, the highlight of CodeMash for me was talking with and rocking out with Scott playing Rock Band during the Day 1 party. He seems like a very nice guy, knowledgable, and a quick study on the drums. I actually think many people found Rock Band to be a centerpiece of the event. You could always find the most interesting people hanging out around the game as well as the funniest moments. I have a grainy cellphone video of a “cowbell” incident that I’ll post in the near future for those that were there. The funniest thing about the Rock Band setup was that there was a real band playing next door.

I skipped the first of the vendor sessions in the afternoon due to being really tired by this point. In the afternoon, I checked out Kevin Dangoor’s, Introducing the Dojo JavaScript Tool talk. Being a complete JavaScript novice, I found it very informative. The feature set is huge and the care taken in making the core libraries as compact on the wire as possible really impressed me. The quote of the session:

The great thing about Dojo is that you don’t need to know JavaScript well.

The final session of Day 1 was Dustin Campbell’s Putting the Fun into Functional with F#. This was my favorite session and I heard many other atendees remark that it made their head spin. As Dustin explains, F# is a HUGE language developed by Microsoft Research that fully implements the three major programming paradigms we have today: functional, imperative, and object-oriented. The talk focused on the functional aspects. I think I learned more about functional programming from this one talk than from all the intermittent reading of Lisp websites I’ve done over the past few years. Since the language comes with the full source code, I’m really excited to download and play around with it. Dustin also appears on the latest Hanselminutes podcast and does a good job explaining some of the points he made in the talk. I listened to it on my way home tonight. I think F# is going to be a big deal in the .NET community once people wrap their minds around the functional aspects. There is so much power there, yet the language is also very accessible to current .NET/C# programmers.

After dinner, the Attendee Party commenced where the aforementioned Rock Band rocking out occured. Great times were had by all. I was originally going to summarize my entire CodeMash 2008 experience in this entry, but as it is already getting late, I’ll end it here. Stay tuned for my summary of Day 2, which included an utterly fascinating keynote by Brian Goetz on concurrency programming and some Perl bashing from Bruce Eckel.

Gotcha #1: iTunes U. Signature Must be Lowercase

One issue I encountered when trying to debug my code was that despite generating the proper signature string, iTunes U. would reject it as invalid. The reason? The string I was generating was uppercase. To fix it, I simply called ToLower() on my generated string before returning it. The HMAC-SHA256 algorithm is already implemented in the .NET libraries, so it is trivial to write the signature algorithm. It is so short, here it is in its entirety:

public string HMACSHA256(string message, byte[] key)
    {
        UTF8Encoding ue = new UTF8Encoding();
        HMACSHA256 hmac = new HMACSHA256(key);
        byte[] hash = hmac.ComputeHash(ue.GetBytes(message.ToCharArray()));

        // Convert the bytes to hex
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < hash.Length; i++)
        {
            sb.Append(hash[i].ToString("X2"));
        }

        return sb.ToString().ToLower();
    }

Gotcha #2: iTunes U. is Picky About URL Encoding

Even after I had the signature algorithm working properly, iTunes U. would still reject my requests. After some investigation, it turns out that the iTunes U. server is very picky about how you URL encode your credentials and identity strings. If you don’t do it just right, the signature will not be valid. There are two issues with the URL encoding that I needed to fix to get everything working:

1. The HttpUtility.UrlEncode() method does not encode ‘(‘ or ‘)’ characters. But, iTunes U. expects that these characters are encoded as %28 and %29, respectively.

2. Also, in a reverse of Gotcha #1, the HttpUtility.UrlEncode() method outputs entity codes in lowercase, but iTunes U. expects uppercase. For example, a token data string like,

   credentials=foo&identity=<jdoe@example.edu>"jdoe"&time=1139331600000

   needs to be encoded as:

   credentials=foo&identity=%3Cjdoe@example.edu%3E%22jdoe%22&time=1139331600

   Notice the ‘%3C’ instead of ‘%3c’. It makes a difference.

I worked around the problem by first URL encoding my string and passing that string to a function that fixed these two above problems. Since this is another short function, I reproduce it below:

private string FixURLEncoding(string UrlEncodedString)
        {
            StringBuilder s = new StringBuilder(UrlEncodedString);
            for (int i = 0; i < s.Length; i++)
            {
                // Find an encoded character and make the letter
                // part upper case because the iTunes U algorithm
                // is very sensitive.
                if (s[i] == '%')
                {
                    if (Char.IsDigit(s[i + 1]) && Char.IsLetter(s[i + 2]))
                    {
                        s[i + 2] = Char.ToUpper(s[i + 2]);
                    }
                }
            }

            // Encode '(' and ')' b/c UrlEncode doesn't do it and iTunes U
            // is sensitive to this
            s = s.Replace("(", "%28");
            s = s.Replace(")", "%29");

            return s.ToString();
        }

Gotcha #3: iTunes U. Timestamp is in Unix Epoch Format

This is a minor gotcha. You need to convert your time to UTC and then format it as Unix time. This is mentioned in the documentation, but I think only very briefly. If you are unfamiliar with Unix time, Wikipedia says it is “the number of seconds elapsed since midnight UTC of January 1, 1970, not counting leap seconds.” You just need to take your DateTime object and create a new TimeSpan object that is equal to your time (in UTC) minus the epoch date. Then, take the TotalSeconds of the TimeSpan and you have your timestamp for the iTunes U. request.

Gotcha #4: Keep Your Clock Synced

Another minor issue that was caught early on was that if your computer’s clock is not synced with an accurate external time source, your timestamp can be off enough to cause iTunes U. to reject your request. This happened during the initial testing of credentials with the supplied Java test script. It only takes a minute or two inaccuracy in your computer’s time to cause requests to be rejected. It is something to remember if you are deploying an application that implements the iTunes U. authentication algorithm.

I am forced to use this abominable framework at work and today I was once again reminded of why I hate it so much. My biggest problem with it is that it seems to have been designed without any real thought put into what Web programming entails. I suppose it sounded like a great idea at the time to design a framework that mimicked desktop application development. But, the majority of the serious programming I have done in my life has in some way touched on the Web, either directly as a traditional Web application, or using Web-related protocols. I am a Web native and I don’t need my framework getting in my way all the time. Working within the Page model of ASP.NET feels like both my hands and feet have been shackled while I’m in the middle of a competitive sparing match. Today, I lost the fight.

On the plus side, I can dive into the HTTP Pipeline, which is nice. HTTPModules saved me when I was trying to create a big part of the next RMCP release. But, still, it wasn’t as easy as if I just used Python with Django or Ruby on Rails, or even, sometimes, straight up Perl CGI.pm! Today, I encountered a particularly nasty bug/feature of .NET 2.0 that has caused development of a simple implementation of an iTunes U login system grind to a screeching halt.

I have a form, lets call it Login.aspx, that iTunes U will redirect users to when they try to access an iTunes U page that is not public (i.e., requires you to be authenticated). So, their system simply causes iTunes to launch the users browser and hands it a URL with a simple query string like http://mydomain.edu/Login.aspx?destination={$SomeITunesUrl}.

Simple, right? My Login.aspx page displays a Login form and in the background will check LDAP to authenticate the user and then a custom database to authorize the user and decide what specific iTunes U credentials are assigned. Then, there is this whole iTunes U authorization algorithm that I ported today from their Java example that just builds a HTTP request with a special authorization token that is sent to iTunes U and what I get back is a special HTML page that I am supposed to forward back to the user’s browser, wherein the user’s browser will open back up iTunes and, as if by magic, the user will be logged into iTunes U.

The problem comes after I have the HTML page. How do I get that page back to the user? You can’t do it from within a regular ASPX page, as far as I can tell. Because of the way the HTTP Pipeline processing works for ASPX pages, no matter what I do, even if I directly mess with Application.Response within the page, it will be overridden by the time the HTTP pipeline event, OnEndRequest(), is called. So, what I want to do is just redirect the request, after I have done the authentication and authorization, to a custom HttpHandler that will do the actual request to iTunes U and return the HTML to the user, since within the handler, I can completely control the HTTP response sent back to the client. Okay, still with me? Great.

The problem is that I need do the transfer to the handler while passing it some context variables, specifically, information about the user and the destination URL within iTunes U. So, I thought, hey, that’s a perfect job for Server.Transfer()! WRONG! If you try it, you get a nice error message that explains nothing.

Even though the documentation explicitly provides a method signature that would lead one to believe that you can transfer to a HttpHandler, you apparently, can’t. Well, at least not unless it is another Page handle. So, Microsoft says that this is by design, but then why have it in the documentation!

I wasted at least half of my day on this and now I am going to need to figure out how to do this completely differently. I think this Server.Transfer() “feature” should be considered a bug. I could use Response.Redirect(), but that doesn’t help me because I need to transfer context items and I can’t do that with a redirect. I can’t pass the data as a query string because then you’d be able to just see the query string params and bypass the whole login form! I guess I could build some elaborate system that encrypts my data as a string with a time stamp that is decrypted by the handler, but I shouldn’t need to do something like that for such a simple task.

Plain and simple: ASP.NET drives me crazy. There are just things that seem easy to do in other frameworks and languages, but force one to jump through incredible numbers of poorly documented hoops to do in ASP.NET. It is sucking the life out of me. Maybe v3.0/3.5 will help? I don’t even care. I’m so sick of ASP.NET and .NET in general, that I just want to dump the whole enterprise and I would, if only I could.

Oh well, maybe I’ll have better luck tomorrow. If anyone has any ideas on a workaround to the Server.Transfer() with HttpHandler problem, let me know. My frayed nerves would appreciate it.