//TODO: finish this blog post

1. Allow the client to define CSS styles and generate a flat file based on what is in the database when the web application loads (if no file exists, write one -- reference that for every subsequent request).  The downside is that I have to write to the filesystem, which means at least one publicly exposed directory must be writeable by some process.  The upside is that browsers will cache the file, so no subsequent requests are needed.
2. Allow the client to define CSS styles and write them to the output stream using a specialized instance of IHttpHandler.  The upside is that, well, this appeals to the code monkey in me.  The downside is that I'm not sure if a browser will cache this since it's not a CSS file per se.  I suppose some experimentation is in order.

If anyone has experience with this, please let me know what solution you settled on.

Also, Illinois, I have not purposefully left you out.  I just don't know what goes on over there in those corn fields!

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!

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.

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.

"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."