IIS 6.0, Compression, and Classic ASP Pages

The incompetent with nothing to do can still make a mess of it.   - Laurence J. Peter

Well this one is a hoot. Enabled HTTP compression in IIS 6.0, and suddenly Classic ASP pages (yes, we still have a few) that required Integrated Authentication just wouldn’t work.

With Anonymous Authentication unchecked, and Integrated checked, and ACL’s on the folder permitting only Adminstrators, you would get a Windows Login prompt as expected but when you would provide credentials, it never went through.

As luck would have it, we duplicated the pages on another site where compression was turned off, and those worked fine. On a hunch, I disabled compression on the includes folder, and that fixed it!

Seems for some reason that Classic ASP include files don’t like HTTP compression at all.

And a thanks to Rick Strahl for reminding me that you need HTTP KeepAlives turned on to use Windows Auth with classic ASP.

Compression will reduce our bandwidth to around 25% of what it has been. That’s good!

In IIS 6.0, getting compression completely enabled is tricky. Tools like ZipEnable from Port 80 can make it a lot easier, and they provide the kind of fine-grained control that lets you disable compression on  a single directory.

Windows 7 Upgrade path from a Beta: No can do?

The RC (Build 7100) versions of Windows 7, which will be available to human beings shortly,  will not upgrade over a pre-release version of the same OS. But, not to worry! The Windows 7 Engineering Blog provides an explanation and instructions on how to do it. They acknowledge that tens of thousands of people at Microsoft alone have been using Windows 7 pre-release builds as their primary OS.

Essentially it is as simple as copying all the files from the burned DVD to a folder on the target machine, then editing the file CVersion.ini in the Sources folder to have a MinClient value lower than the down level build. For example, you would change 7100 to read 7000. Save the file in the same place and run setup from the folder on the  hard drive itself, and you will be allowed to upgrade.  As always, there are a number of cautions and caveats in doing this, so read their blog post carefully. These same steps will be necessary when going from the RC to the RTM milestone.


The Twittification of Live Messenger

I’ve noticed this new “Groups” thing in the latest version of Windows Live Messenger, and it seems that the kind folks at Microsoft have really  started to “get it” about what “Social” is.

If you enable the “What’s new” display at the bottom of the Live Messenger window, you will see people in your “group” (that you have started) who have joined other people’s networks. If you click on the links, you can view information about that user and their network, and you can invite them to join (or, ask to join).  It’s not that intuitive at first, but if you play around with it using people that you know, you’ll start seeing new Contacts in your contacts list – most likely people you didn’t know were using Messenger, and / or you probably never thought to invite.

I’ve already made a few new friends with this – people I always wanted to be able to have on Messenger, but I either never thought of it, or I didn’t know how to invite them.

When “Groups” first was started, I started a “.Net devs” group just for fun, and invited a few of my Messenger contacts. Several people joined. The concept of getting your Twitter friends to join a Messenger group or network is powerful. Think about it.

The key thing – like any other new “toy” – is to use it to join networks of people you are really interested in (in my case other MVP’s and .NET developers). This will keep the signal-to-noise ratio at an acceptable level. I get followed on Twitter by all kinds of strange folks – who are obviously following a search on some keyword in a Tweet of mine. I check them out, have a look at who’s following them, and only then do I decide.

“Social” means different things to different people. To me, it means developing meaningful relationships with like-minded people where I can help them, and they can help me. To others, it’s just collecting names. You have to decide what “social” really means to you.

Kudos to Microsoft for thinking social and “getting it”. I think it’s a step in the right direction vis-a-vis “unification of social”.


Some facts about Silverlight 3 and where it’s going

“Being an expert means having credibility. It doesn’t matter how much you know if people don’t trust your answers.” – Brent Ozar
Silverlight 3 was first announced at the IBC 2008 show in Amsterdam on September 12, 2008. It was unveiled at MIX09 in Las Vegas on March 18, 2009. A beta version was made available for download the same day.

Silverlight 3 includes an increased number of controls - including but not limited to DataGrid, TreeView, various layout panels, DataForm for forms-driven applications and DataPager for viewing paginated data. Some of these controls are from the Silverlight Toolkit. In addition, Silverlight 3 includes a navigation framework to let Silverlight applications use the hyperlinked navigation model as well as enabling deep-linking (linking directly to specific pages) within Silverlight applications.

On the media front, Silverlight 3 supports AAC audio decoding as well as hardware-accelerated H.264 video decoding. The native multimedia pipeline is also programmatically exposed, so that other formats can also be supported by third-parties using managed code decoders. Silverlight 3 supports perspective 3D which enables 3D transformations of 2D elements. These transformations, as well as many 2D operations like stretches, alpha blending etc are hardware accelerated. Custom animations, including transforms and blends, can be created on Silverlight elements using HLSL to make use of pixel shaders. A Bitmap API is provided to let Silverlight 3 applications manipulate bitmaps. Silverlight now uses the GPU to accelerate the composition of Visual Trees (like WPF, Silverlight elements correspond to Visual elements, which, when coupled with the layout information, forms a Visual Tree which is then rendered to form the final display). Visual trees can now be cached; this increases performance in cases like transforms, which create lots of throw-away intermediate states, by not making the state transitions on the main Visual tree. Silverlight 3, on release, will support ClearType text rendering.

UI elements in Silverlight 3 support element-to-element binding - which allows one element to be bound to the state of another element, including  a validation mechanism for data binding. Unlike Silverlight 2, which allowed the applications to save files only to the local isostorage, Silverlight 3 applications can save to any location on the file system via the system Save File dialog. However, the path where the file is saved will still be hidden from the Silverlight application. Any external assemblies used by Silverlight applications are cached to so that they need not be redownloaded for subsequent instantiations of the application.

Silverlight 3 also includes a LocalConnection API to communicate (using a named pipe style model) among multiple running applications on the same machine, irrespective of the browser  and can monitor for network connectivity events. Silverlight 3 can optionally use Binary XML to communicate with WCF services.

Silverlight 3 supports Out-of-Browser deployment, i.e., Silverlight applications can be installed to the system for offline access (provided the application manifest is modified to allow local installation) where they run outside the browser. They are launched using the Start Menu or desktop shortcuts, similar to ClickOnce installations, and run without the browser window. Applications can check whether they are running inside a browser or not. When running out of browser, HTML interop is disabled. In addition, access to the Function Keys is  enabled. Locally installed Silverlight applications still run in a sandbox.

Installed Silverlight 3 applications automatically check for updates asynchronously on every launch and updates are automatically installed. Running instances of the applications are informed when updates are available.

The current Silverlight 3 beta does not support a “go live” license, so developers cannot currently put their Silverlight 3 beta applications on the public internet because there is no publicly available runtime to download.  You can find out more about Silverlight 3 here.


You’re Fired! – Redux

I walked into the office this morning and was called “downstairs”. The official line was “Due to the economic downturn, blah blah”… You get the idea. I know better. I was working on a project that was grossly underbid as a fixed-price deal by a company - designated  “architect”  -- which consequently forced a few of us  developers into an impossible position, under extreme time pressure, on a new technology that nobody in the office had ever used before. The schedule was virtually impossible to meet. Anyone with an above room temperature IQ could easily see this, and I had been vocal about it from the beginning, so what happened to me was no surprise.  Management was in a state of denial.  One developer who was brought on decided to quit in the very beginning. Then, they scrambled to bring on two other developers from another office and another project.  The client was not very helpful, although they could not be blamed, really. This particular  project was destined for problems from the beginning, in my opinion. Of course, one could make the case that the company was in a position of attempting to do anything to keep business in the pipeline, “due to the economic downturn”. Still, when you are bidding a project, you don’t want to shoot yourself in the foot, but it seems to me that’s what they did.

To add insult to injury, the “architect” person refused to allow the developer team to use multiple checkout in TFS (that’s the default) –- causing hour upon hour of delays, and on top of that – refused to allow us to include the client’s base class library project  in the solution so that we could debug through, claiming it would “add complexity” – which makes no sense, since it was the  identical source code the client gladly  provided us with and used to  build the assembly to start with! It actually got so bad that developers started working offline to be able to get stuff done. I have never – I repeat NEVER – been put into this kind of arbitrarily restrictive environment in developing an application!  Developers were not consulted in advance about this project and its risks. Only after I got involved did I realize that one of the scope requirement our “architect” had included -- of WCF enabling the client’s entire library-- was virtually impossible, and I successfully got them to remove this requirement after screaming bloody murder about it. What am I talking here, Greek? I said what I believed was right, and i got shot down! We had an environment where you were supposed to be able to provide input – but when you did, it became a “good old boy” network and you would be quashed. Not cool at all! What’s more, if you are the architect on a project, you have NO BUSINESS tinkering with the codebase and checking in untested code that breaks the application and causes even more hassles for the developer team!

This is a key fallacy in presenting and proposing a project to a client – when somebody who has been designated  the “project architect” decides to do  everything “on their own” -- without prior consultation with the actual coders who will be tasked with building it—intelligent people  who can usually offer valuable input. This is “Ivory Tower” development proposal methodology, and it’s just wrong. Since when is the “architect” supposed to be the guy that tells the developer team how to handle their source control? I think that when people get into a position of “defending turf” – they can become extremely threatened by other people who question their authority, even in the slightest way.

Actually, I like this person – but it became “political” because I opened my mouth and said the obvious.  I don’t  care at this point;  I’m blessed because I’ve built up a substantial income with my eggheadcafe.com partner over the last nine years (to his credit, he seems to be able to put up with my idiosyncrasies just fine…).

When companies are stressed, managers often make bad decisions -- it’s the guys who are making six figures that get chopped first, even though they are often the people who can help the most – but only if they are asked to do so. I certainly was not asked.  If companies do not take concrete  steps to have a proactive policy of LISTENING to the people who will be  producing the product,  then  they will fail.   Managers  don’t always think logically – they are too often motivated by the concept of “protecting their ass” – and it degrades into  a political “good buddy network” process. I’m sure if you’re reading this post that you may have already been exposed to this.

When I see a process that’s flawed, I’m gonna speak my mind about it. When you stick to principles and do this, it may get you branded as a scapegoat and then you’ll be the first to go, illogical as it may seem.  So be it – I can sleep well now. I’m so relieved that I no longer have to spend 2 hours of my day driving into Orlando and back to put up with this B.S. every day.  Now I can focus on what I do best – writing good code and articles, making presentations, building the business. If I find another “day job” – you can bet I’ll choose it carefully.

The bottom line is, “To thine own self be true” --  I would likely have been out of there looking for a better spot  anyway. As a friend and co-worker said, “They have kicked out an excellent developer and team member”.  That’s comforting to hear, but in this case it just wasn’t working for me –-I now believe the company  actually did me a favor. Thank you! (BTW – here’s my current resume!)


ASP.NET MVC: Is it worth it?

You talk to God, you're religious. God talks to you, you're psychotic.  - Doris Egan

Catchy title, eh? I’m asking it because I think it’s a legitimate question. I’ve been working with ASP.NET MVC for a couple of reasons:

1) Peer pressure: Developers who I know and respect have been telling me its “very cool” and beats “classic” ASP.NET WebForms by a mile. Some of these people are pretty smart. Some of them are a lot smarter than I am.

2) I have no choice. The current project I’m working on for my “day job” uses ASP.NET MVC along with other “very cool” things like StructureMap, Castle.Validator and a few other alt.net type goodies. (Side note: alt.net may not be so cool. I tried to sign in at their site with my OpenID and it wouldn’t accept it. I got some bullshit about not having a valid email address… Folks, that’s the FIRST TIME I’ve ever been denied an OpenID login!) Correction: a commenter below  correctly stated that I needed to enable my email on my OpenId profile. Usually, what people do is that if your email is not provided, they ask you to enter it. Oh, well….

So anyway,  over the last month or more, I have had no choice but to struggle my way along with two or three other developers who are more or less equally “Into the shark pool: now ‘swim!’”. Today things got so bad that I started pair programming with another guy. You know the concept: One PC, One Driver, One Navigator, and (hopefully) Two Brains. Actually we got a lot done mostly because the other guy was familiar with certain aspects of the framework (its the client’s framework) and I was familiar with other aspects. So in about 3 or 4 hours, I’d say we got about 15 hours worth of what a single developer would be able to accomplish – and most importantly, both of us learned new “stuff” in the process.

But here’s my take on ASP.NET MVC so far:

1) I think it’s very cool. I like the idea of separation of concerns. I like the more "OOP” approach to web development. You can do a lot with it –- but!

2) It has a steep learning curve. ASP.NET MVC is NOT the kind of framework that you want to have to use if you’ve been arbitrarily thrown into a new project where you must use it, especially if you’ve been handed a highly customized codebase from a client that you must use and which cannot be changed for both contractual and architectural reasons.

And – especially – if the project you’ve been handed has a short fuse, for whatever reason.

3) There’s a lot of buzz about avoiding ViewState and the “old” Postback model. I’m just not sure how valid all that stuff is. ViewState is a perfectly OK concept, it’s just that developers don’t understand it and consequently it is prone to abuse. ViewState, additionally, can be stored on the server very easily, so at least a part of this objection is moot.

4) “No Postback model”. OK, that’s fine. But have you looked at what hoops you have to go through to make MVC work? Why do you think they stuck TempData in there into the MVC Framework? And why do you see developers building custom server-side Session for their MVC projects?

5) Complexity: What you get in your View is almost totally dependent on what you do in your Controller. If you need to do “extra stuff”, then you need to write “extra code” in Controller methods. There just isn’t any way around it. Purists will say that’s the way it’s supposed to be (“separation of concerns”). I’m just not so sure I like that – yet.

Bottom Line: The jury is still out for me on MVC. I know there are a lot of purists out there who will call me a traitor. Too bad, guys. I’m not saying I won’t use ASP.NET MVC, I just believe at this point that if I had the luxury of crummy old WebForms I would have been able to produce the same quality app a lot faster, and it’s performance would be the same – or better – than in ASP.NET MVC.   I still think MVC is cool but frankly, I don’t like going home from work with a splitting headache.


On Developer Wisdom

Don't you wish there was a knob on the TV to turn up the intelligence? There's one marked 'Brightness,' but it doesn't work.  - Gallagher

Wisdom. The “Wisdom of the Ages” -- wisdom  is an ideal that has been celebrated since antiquity as the knowledge needed to live a good life. What this means exactly depends on the various wisdom schools and traditions claiming to help foster wisdom. In general, these schools have emphasized various combinations of the following: knowledge, understanding, experience, discretion, and intuitive understanding, along with a capacity to apply these qualities well towards finding solutions to problems. These concepts, as one might guess,  apply equally  well to software developers.

For a software developer, however,  wisdom is a much narrower concept that comes from learning from one’s mistakes, from studying what others have done, from learning accepted and proven patterns of good software design. And above all, from being willing to change, endure the pain of mastering something new,  and then to be willing to refactor those old patterns and techniques as new and better ones are discovered.

Wisdom can mean learning Lean Programming, which teaches us to eliminate wasted effort by focusing on vertical design that only satisfies the needs of business requirements instead of building out entire layers of an application in advance. It can also come from learning to employ Agile development methodologies, most of which promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. Not to forget TDD – Test Driven Development – an integral part of Agile methodology.

I believe we, as .NET developers who have been primarily taught a data-centric approach to enterprise application development from back in the “Windows DNA” days, are expanding into the epiphany of more open-source, domain-driven design modalities. You can see this from some of the kinds of frameworks that are now being embraced by mainstream .NET Developers – NHibernate and other open source ORMs, ActiveRecord, StructureMap, Spark MVC View engine (as well as ASP.NET MVC), and others. These frameworks haven’t been lost on the Microsofties, either. I distinctly remember Scott Guthrie uttering the word “NHibernate” during his MIX 09 keynote presentation. And recent issues of MSDN Magazine have featured articles by such notables as Jeremy Miller, a C# MVP who espouses Fluent.NHibernate, StructureMap and similar frameworks. Do you read this stuff? I do, and when MSDN Magazine agrees to publish this kind of content, I take notice. It’s not just that I’ve already been following this — it’s because a major publication that any .NET developer possessing an above-room-temperature IQ will read -- has just said, “We’re cool with this, and we want you to know about it”.

The concept of designing one’s POCO classes first and then creating the database persistence layer from that domain only after the domain is feature-complete is still quite foreign to many developers who otherwise envision themselves as “mature” or “senior level”.

I still see developers who insist on creating an entire database schema for their application before they’ve created even the beginning of their domain model. Often they dismiss “top down” development as being inappropriate for their particular “modality” – even in the face of overwhelming evidence that it is the business domain model and logic that should be dictating the eventual persistence schema, not the other way around.

I am by no means saying that developers who start by designing their persistence schema and then build up from that are wrong. What I am saying is that if this is the only way they can / will develop an application – something may very well be wrong.  You can show them how to do it the new way, but if they refuse to be open to a new concept, you should move on. Let somebody else be the evangelist!

Developers are learning how to simplify software development by applying the DRY (Don’t Repeat Yourself) principle using various frameworks and tools, most of which are readily available for the .NET Platform and many of which come via ports from the JAVA space, which has been around a bit longer than .NET. Isn’t it interesting that as .NET has matured, you don’t see the old JAVA vs .NET flame wars anymore? The JAVA guys have provided us .NET kiddies quite a bit to chew on.

One of the most difficult challenges to obtaining “wisdom” in the developer space is the natural tendency of developers to avoid (or simply be ignorant of)  lateral thinking techniques  and to be reluctant to “do things differently”.  It is easy for a developer who has a technique or a tool that they’ve engineered to unwittingly force themselves into a restrictive programming paradigm simply because they are unwilling to accept the fact that better tools may now be available to them. I call this phenomenon “coveting thy code”.The learning curve to master a new framework or concept is often dismissed with the thought that “I just don’t have the time”, or “nah - my ‘thing’ is better than that thing”.

One strategy  I have found is that if I make an honest assessment of what frameworks and tools I believe are really important to my development career future, and only focus on these, I can gain a lot of extra time to get the job done. I used to jump at every CTP and BETA of this, that and the other thing. Now I don’t – I’m focused only on  some core technologies. You won’t see me messing with Azure Services,for example,  because it’s not “baked” yet. And frankly, I don’t really need it just yet anyway. In fact, ASP.NET MVC 1  only recently popped out of the oven as “done”, and I didn’t even begin with it until it was already at the RC1 level. Is that “wisdom”? I say it is.

Sometimes I think of myself as an “old dog who’s  learning new tricks”. Yes, it’s hard. But I wouldn’t have it any other way. What about you?