Yesterday the .NET Rocks! Roadtrip came through St. Louis and local developers were treated to a very special live broadcast of the .NET Rocks! podcast by Carl Franklin and Richard Campbell, two tech heads who are just south of sane and a whole lot of fun to hang with! The roadtrip is a fifteen-city trek across America in a large RV, sponsored by Microsoft product teams and many .NET component, control, and tool providers. The roadtrip team can be tracked in real-time with a feature-rich Silverlight app that integrates Bing mapping technology, live tweets featuring the hashtag #dnr_roadtrip, and Flickr image posts of the roadtrip team and RV. During the first hour the podcast was recorded live with special guest Kate Gregory–developer, writer, professor, and computer science PhD. The discussion began with some brief overviews of Windows 7 development features and .NET Framework 4 enhancements that leverage them. The banter was lively and the dual of wits commenced when Kate revealed that her two favorite languages are C++ and Visual Basic. (A confession which, in a room of C# developers, is tantamount to heresy!) She was quick to point out that Microsoft’s MFC libraries have received a hefty update in .NET 4, so people who write “trivial” applications like game engines, device drivers, and operating system libraries have finally received some love. I had never heard Kate speak before, and it was quite an entertaining and enlightening hour. I hope she will continue to be a guest on future .NET Rocks! podcast episodes (hint, hint). To listen to the full 41 minute podcast, and read a more robust description of Kate Gregory’s accomplishments, check out the podcast page for show #551. Richard took stage for the second hour and demonstrated the new load testing features in Visual Studio 2010 Ultimate Edition. He totes a “datacenter in a bag” which consists of four mini microcomputers, a switch and a bunch of network cables. In the mix were two Windows 2008 web servers, an SQL Server 2008 database box, and a Windows 7 client machine running Visual Studio 2010 Ultimate for load testing. Richard started with the price tag: ~$12,000 for 2010 Ultimate, which is not a bad investment considering comparable load testing suites are typically priced in the 10k range. And 2010 comes with an IDE as well! (joke) He fired up his web servers (both running a mock storefront ASP.NET web application), created a load testing project in Visual Studio, specified the testing parameters (there are many testing scenarios to choose from), connected the IDE to the target web server’s performance monitor, and let the test run for about sixty seconds. When the test finished, Richard showed us many colorful graphs and explained that a) colorful graphs are a good way to convince your boss that you are being productive, and b) each colorful graph actually has extremely valuable data that can help pinpoint bottlenecks in hardware and software. One thing that I was particularly impressed with is that Visual Studio also monitors the machine *performing* the load testing as well. This is important because if the machine performing the testing can’t keep up with the rigor of the test parameters, the data might lead to wrong conclusions. When Richard was finished I found myself wishing I had a spare 12k to drop on Ultimate, but all the loose change in my couch only amounts to about $0.70, so it will be a while. For the third hour, Carl showed off pictures of his amazing recording studio, audio and video equipment, and the plethora of musical devices he keeps stashed away in his home. Truly a man of many talents, Carl plays just about any instrument and sings too. After making us wish we were all artists and not code monkeys, he showed us some hot features of Silverlight 4 and the Expression suite of tools, specifically video encoding and playback. He demonstrated how Silverlight video had been leveraged during the Olympics to provide coverage for the duration, and how it is being used to provide an interactive experience with Sunday Night Football. He pulled up the latest copy of Expression Encoder and demonstrated how videos can be “tagged” at certain time stamps with a piece of data (think CommandArgument in ASP.NET), and those tags could be intercepted during playback in a WPF or Silverlight application with a special event handler. The data that each tag contains can then be used to instruct the application to respond to that moment of video playback (maybe show a slide, cause UI controls to change state, go to a URL in a browser, etc.). For the grand finale, Carl demonstrated a Silverlight application that interacts with an attached webcam, which can identify a specific artifact that the webcam is “seeing” (in this case, it was a piece of paper with a specific symbol on it), and then replace that artifact with another image, a video, a textbox–essentially anything that could be rendered in Silverlight. Carl held the paper up to his face and his face was instantly turned into a giant textbox that could even accept input from the keyboard. Whenever he would move his face, the textbox would follow the plane of his head and adjust itself accordingly. While textboxes are great fun, he mentioned that real-world applications already exist for such technology, such as on-screen annotations during a football game (the yellow highlighted line of scrimmage superimposed over the field, for example). Once all presentations were complete, swag was distributed to lucky attendees by random draw. The kicker was that they had to answer a trivia question before they received their prizes. Question topics ranged from obscure facts about the .NET Rocks! podcast to identifying incorrect regular expressions for email validation. Most people were fairly nervous at first but special “clues” were present in each question that made guessing lots of fun. Special thanks to Carl, Richard, Kate, and the local St. Louis .NET attendees and sponsors who worked hard to make an enjoyable evening. You guys are the best!

The ability to err early and often is essential to getting real work done. We are taught this in school when teachers tell us to write a rough draft of our final paper, store it away for a day or so, then revisit it several times refining and correcting as we go. Unfortunately most of us always waited until the last minute to write our first (and final) draft, and produced something frightening as a result. Writing software is not so dissimilar.

Like most web developers, I write markup and Javascript that will work on both IE and Firefox, and if I’m particularly ambitious, Chome and Safari. I’ve been writing a lot of Javascript lately, which has been a good learning experience but frustrating at the same time. I don’t have the luxury of using jQuery on my current project – I am pretty much restricted to Prototype for legacy reasons. I was in the throes of reconciling a piece of code that copied values from one set of input fields to another, then accessing the innerHTML property of the target fields’ containing div. I was doing simple value assignments ($(“textBox1”).value = $(“textBox2”).value), and in IE everything worked like a peach. Then I tested in Firefox and, to my amazement, the target input fields remained blank, even though FireBug assured me that the values were in fact being copied. I was certain I was making a mistake somewhere in code, and spent an hour or so meticulously pouring over every line of Javascript, attempting to find the roadblock. In desperation, I turned to the Google in search of an answer. What I found surprised me enough that I felt compelled to write this post. Firefox does not reflect dynamic DOM changes in the innerHTML property of a given DOM element. This means that if you set the value of a text box to “123”, then call the innerHTML property of the DOM element that contains the text box, the value of the text box according to innerHTML will appear to be whatever it was prior to your alteration. In practice, when the page posts back to the server, the value will actually be “123” and not what innerHTML reports, but the fact that Firefox ignores the change gives me yet one more gray hair. To get around this glaring oversight, I had to use the setAttribute() method on the DOM input element: $(“textBox1”).setAttribute(“value”, $(“textBox2”).value); This accomplishes both tasks – updating the actual input value and changing the innerHTML property accordingly. You’ve won this round IE… you’ve won this round.

Lutz Roeder scored major points with developers the world over when he released his .NET Reflector software, a tiny package of TNT that lets the user examine compiled .NET assemblies, and even disassemble them (for debugging purposes). I know it’s a tool I couldn’t live without. I’ve used it countless times to examine APIs of core .NET libraries, as well as third party, ill-documented assemblies. (What? No documentation? Perish the thought!) In 2008, Red Gate acquired the rights to enhance and publish reflector, and so their first polished incarnation has wandered into the wild. .NET Reflector 6 is still free, but an optional “pro” version may be purchased for a paltry $195.00. Reflector has been upgraded to support the new .NET 4.0 framework, and both versions come with Visual Studio integration. Reflector Pro includes the ability to decompile from within Visual Studio, and debug step-through capabilities as well. (You know, for those times when you’re certain that Microsoft has screwed something up in their base class libraries because your own code is pristine.) Add-ins for Reflector can be found on the Reflector Codeplex site in case the gun just isn’t big enough for you out-of-the-box.

I just love days of lost productivity. You know, the ones where you pine away at some problem, retracing every change you made, every source control update you performed, attempting to track down the offending bug in code. Days like yesterday, for example. I was working on a fairly nondescript ASP.NET web page, but every time I would attempt to run it I would get the following error:

Parser Error

Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately. Parser Error Message: Ambiguous match found. Source File: /Default.aspx Line: 1

The only thing that is typically on Line 1 of any ASP.NET web page is the Page declaration, which specifies the CodeBehind and Inherits properties, so naturally my first thought was that perhaps the class name for the page conflicted with another class in the same namespace. But this was an erroneous assumption, and after renaming the file several times I decided that was probably not the case. After a few hours of searching, I realized that I had a button on my page declared something like this:

<asp:Button ID=”cancel” runat=”server” Text=”Cancel” />

and an event on the same page (in CodeBehind) declared like this:

public event EventHandler Cancel;

As it turns out, when ASP.NET parses a page’s controls, it does so in a case insensitive manner, which means that the two “cancel” properties (a button is really a protected property declared in the designer) conflict. This, of course, is completely contradictory, since the code will actually compile (case matters; there should be no name conflict) and only crashes at runtime. This reeks of FAIL, especially since the whole point of ASP.NET is to make web pages more “object-like”. All the more reason to use MVC.

<asp:Button ID=”cancel” runat=”server” Text=”Cancel” />

A friend sent me a link to this website, which has a disclaimer and the bottom that wins the gold in two categories: 1) side-splitting humor, and 2) caustic diatribe against inferior technology. I reprint it here in its full glory.

“Hi, if you are coming to this site via Internet Explorer 6, you might not be getting the best experience possible. Honestly, I can’t even begin to think about what your entire experience on the internet must be like? (…probably like riding a bike on the highway while cars blow by you on their way to Costco to get gallons of mayonnaise and 60-inch plasma TV’s). How will you ever be able to use this website?????? You wont. You’re an asshole and your browser is an asshole. So look, I’m going to be honest: I kind of hate you. BUT we c-a-n make this work. Here is what I am going to need you to do: fire up your Toshiba ShitBook© that weighs about 45 pounds, wipe the Cheeto dust off the screen, download Safari, delete Internet Explorer from your computer, punch yourself in the face, and get me a pulled pork sandwich.”

I’m pouring through the NUnit documentation to get a better grasp on the robust unit testing API. I tend to learn quickly if I reproduce whatever I read (whether in written form, in passing conversation, with diagrams or drawings, etc.), so I decided to compile the NUnit assertions and constraints into a single “cheat sheet” for quick reference. You can download it here, if you’d like. If you find any errors, please shoot me an email (my email address is at the bottom of the cheat sheet).

Ever since Google Maps showed us that rich internet applications were not only possible but pretty damn cool, developers have been striving to streamline the process of communicating with web application servers without refreshing the browser. Initially this was done by writing JavaScript to work directly with the XMLHttpRequest object; but this was tedious and not at all elegant. Then some smart folk came up with the Prototype JavaScript framework and made everyone’s lives easier by abstracting AJAX functionality, making it easier to work with. jQuery dazzled developers by simplifying the process even more. XML began leaving a bad taste in everyone’s mouths, so other smart people figured out that instead of passing tagged markup data back and forth, these JavaScript frameworks could transmit and receive JSON. Because JSON is the native way to serialize JavaScript objects, and because it is significantly less bloated than XML, it was the natural choice for future rich internet applications. Now, I have a real passion for simplicity and elegance, so any web application framework that makes AJAX easier to write and maintain is my friend. Since I’ve been learning ASP.NET MVC, I decided to see how it stood up to the challenge. Like most everything else in MVC, AJAX/JSON support is cake, not a lie. A JSON driven AJAX call in MVC consists of:

1. the page that makes the AJAX call, which sends and/or receives data;
2. a custom MVC action on a new or existing MVC controller that will handle the AJAX call, do the heavy data lifting, and return a result; and
3. a custom MVC Route that maps to the controller/action in Global.asax

It’s easiest to start with the controller/action, so here we go. There are a few things to note here, namely the return type of the Authorize() method (JsonResult instead of ActionResult), and the method called to render the data (Json() instead of View()). Also, while any pre-defined, strongly typed object could be passed into the Json() method, an anonymous object works marvelously for simple values. (As an aside, best practice dictates that the user repository be retrieved from an IoC container, but for the purpose of this demonstration and for space considerations, I have hard-coded it here.) The logic in the action is very simple; we fetch a user based on credentials and return a value indicating if the user exists and if they have proper login access. Because the action here is a simple method in a controller class, it is also possible to write automated unit tests to make sure that the method behaves as expected under a variety of conditions. The Route for this controller/action is likewise very simple. The route does not define any parameters for username or password. This is because jQuery will append arguments to the route using the normal query string notation. I suspect, but have not verified, that if a route was specified with parameters such as /{username}/{password}, and a dynamic URL was constructed in JavaScript and no arguments were passed to it, the functionality would be identical. The actual view contains the most involved code. The form at the bottom contains two fields, Username and Password, and a simple input button that is used for submission. The click event of the login button calls jQuery’s built in getJSON() method, which takes the following arguments:

1. the URL that will be used to submit the AJAX request (the URL defined in the MVC routing table);
2. an anonymous JavaScript object with properties identical to the method arguments of the action I am calling; and
3. a callback method that takes the return result of the AJAX request as an argument. This result will have identical properties to the object we returned in our action method.

Based on the return value from Authorize(), I show a popup dialog indicating whether the user should be allowed to log in. (Best practices dictate that authorization and authentication be performed by two distinct services, but I have consolidated them here for brevity.) Because AJAX calls are asynchronous, it is important to remember that the click() event will likely exit before the getJSON() function has completed. If you add an hourglass or twirling Web 2.0 spiral (probably not the technical name), you will want to display it before getJSON() is called and hide it in the callback function instead of at the end of the click() event to ensure that it is displayed for the duration of the request. That’s all for now. I will post more on MVC later, but I think we can all agree that:

This was a triumph. I’m making a note here: HUGE SUCCESS. It’s hard to overstate my satisfaction. –GlaDOS

I fondly remember the old days when games only came in 640x480 with cheap MIDI soundtracks and ugly enemy sprites. One such classic game (a personal favorite of mine) is Rise of the Triad, which featured a pretty kick-ass God mode in which the player could hurl orbs of energy from his or her hand and watch with glee as enemies dissipated into the aether. [caption id=”attachment_115” align=”aligncenter” width=”450” caption=”Way better than Windows 7 “god” mode”][/caption] Well, according to a recent cnet article, Redmond has added its own flavor of divine power to Windows 7. The hidden trick is to create a folder (anywhere on the file system) with the following name:

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

The folder is magically transformed into a mega control panel with tons of power-user options for tweaking your favorite operating system. Although it lacks the certain malevolent satisfaction I get from Triad, the hack is still pretty neat. It does raise the question, though: why didn’t Microsoft make this a standard shortcut for a vanilla Windows 7 install? I will leave you to draw your own theological parallels.