.NET Developers – Burger Flippers?

This is probably old news to a lot of people, but it was new to me so I’m writing about it.

A year ago, the CEO of startup Expensify wrote a blog post unintentionally bashing professional .NET developers. The entire post was inflammatory and insulting to the .NET world, with gems such as the following quote littering the whole blog:

The right sort of person is so passionate about coding, they can’t be stopped from doing it.  They typically started before high school — sometimes before middle school — and never looked back.  They write everything from assembly to jQuery, on PCs to mobile phones, doing hard core computer graphics to high level social networking.  They’ve tried everything.

Everything, that is, but .NET.

You can’t make this stuff up. He goes on to explain that he makes all people with .NET experience on their resume at ALL defend that position during phone screens. He doesn’t see .NET as a “real” platform and that .NET developers just sit in their “McDonalds kitchen” pressing buttons that spit out burgers. He claims that .NET devs can’t adapt to situations (although, he very notably doesn’t give any examples of things .NET devs can’t do, but rather stays in his metaphor or burgers).

Here’s a slightly out-of-context quote:

See, Microsoft very intentionally (and very successfully) created .NET to be as different as possible from everything else out there…

He goes on to make some valid points about Microsoft getting people entrenched in their platform and their tools – but the same argument can be levied against many other companies as well. But regardless, the above quote is a bit laughable when you remember that .NET was originally Microsoft’s answer to Java. And .NET is very similar to Java in many ways. It was intended to be their version of Java, not something “as different as possible”.

The CEO also describes his developers as in a fairly humorous and confusing way:

Instead, we look for a very different sort of person.  The sort of person who grew up cooking squirrels over a campfire with sharpened sticks — squirrels they caught and skinned while scavenging in the deep forests for survival.  We don’t want a short order chef, we want a Lord of the Flies, carried by wolves into civilization and raised in a French kitchen full of copper-bottomed pots and fresh-picked herbs.  We need people who can not only cook burgers, but cook anything, from scratch.

Once again continuing the McDonald’s metaphor, apparently the devs this guy is looking for hunt and cook squirrels. .NET is push-button development but his guys can adapt to ANY situation, since they’re hunters and can cook their own stuff, right?

This drama comes to a close last month, when Expensify publicly began searching for a .NET developer. They definitely acknowledged the hilarity of them looking for a .NET guy after bashing .NET so thoroughly. However, some good questions were raised in the comments. If they need a .NET dev (in this case, for WP7 apps) why can’t their squirrel-hunting devs just get in that McDonald’s kitchen and press that burger button?

The sad part is that most of the professional .NET community was warned, via some high-profile blog postings, to stay away from these guys. That means the people applying will have a higher chance of being those “burger flipper” devs that he was insulting.

StyleSheetTheme – the Unsung Hero of .NET 2.0

I had an issue today that was not clearly covered in blogs that I found on the subject, so I thought I would write a little post explaining what the problem is and what my solution was.

My issue was on a .NET 2.0 page. As simply put as possible: Using a Theme was causing my browser-specific css to get ignored.

My Masterpage was using a simple IE-conditional to include css written specifically for IE7 (and another for IE<7). We also had a generic basepage that every page inherits.

 For some reason (and I’ll explain why in just a second) my ie7.css file was just not getting recognized by any of my pages. I quickly checked the source of the page and found that the order of css on the page went: ie7.css in the conditional, followed by all my Theme css files located in App_Themes/Themename/css.

Introduction to Themes 

In case you are new to .NET 2.0 and Theming, the general idea behind it is that you have a special folder called App_Themes. Inside this folder, you can make subfolders. These folders should be the names of your theme, so if you want a blue theme, the file structure would generally look like ~/App_Themes/Blue, and then images and css directories under that.

 Why is this useful? .NET 2.0 includes the ability to set a page directive called “Theme”. At the top of a page, there’s some junk thrown in there by .NET, like MaterPage, Title, etc. You can add to that: “Theme=’Blue'”.

What happens next is that all that css is imported automatically. Presumably as well that css should have a relative path to the images. You can have skin files and all kinds of things in the Theme. The magical part is, if you want, you can also set the Theme programmatically. If this is the case, you could have some kind of Session variable, in theory, that “knows” where on the site you are, if you have different areas, and then set the Theme to the appropriate area. For example a Green area that has article.aspx and news.aspx.

In the Green/Blue example, if you used the same css class names (or even the same css FILE, copied in two different directories) you can literally just swap the image colors and automatically have two completely different looking websites running off of the same exact aspx/cs files.

The best part of Theming this way is that all you have to do in a codebehind is say, literally: “Page.Theme=”Green”;” and you get the Green Theme.

So what was my issue?

The Issue

The Theme css is imported automatically. Anything inside the Theme folder gets grabbed and added to the page in a <link rel=…> tag. This is fine. It’s not what it’s doing, but where. These are added automatically at the END of the head tag, by default. Good by IE conditional statements.

The IE conditional statement is supposed to pull in a stylesheet with extra or different definitions that override the current css in the case of IE. However, with css, the last version of a definition is used by default. So it was like my IE files were not even there.

The Solution

StyleSheetTheme! This is a second kind of theme that differs from the “Page.Theme” version of .NET 2.0’s theme system. (Geez the word Theme is starting to lose all meaning to me at this point… sorry 😦 I didn’t name these things!) A StyleSheetTheme differs from the regular theme in two ways:

1) The way it is added to a page programmatically

2) Where it positions the css on the page

StyleSheetThemes are specifically designed so you can alter the css with other stylesheets. Instead of placing everything last, it places it FIRST. This is incredibly useful for things exactly like browser-specific css files, or small little inline things you may want.

The reason I think so many people ignore this theme type is because of how it is implemented. On an aspx page you can statically declare it similar to the other theme, in the @Page directive, just by saying StyleSheetTheme=”Green”.

Programmatically, though, things are different. There is no Page.StyleSheetTheme. Instead, you have to override a property. That code would look like this:

protected override string StyleSheetTheme

{

           get { return “Green”; }

}

This can happen in the basepage, which makes the most sense, honestly. You might notice that this is also static. Using a variable won’t help much, either, since it’s not executing at preInit or onLoad, it’s a separate method. What you CAN use, though, is a Session variable, as long as it’s not null.

Conclusion

This simple solution saved me a LOT of hassle today. I recommend more people check out StyleSheetTheme instead of Theme, since Theme requires hacks in order to get it to work well with alternate css paths.

.NET 3.5: A LINQ to the Past

With the release of Visual Studio 2008 comes .NET 3.5, the newest iteration of the .NET framework. Unfortunately, .NET users are also greeted with a rise in popularity of the age-old question: Stored procedures or in-line SQL?

I won’t bore you with the details of LINQ (Language INtegrated Query) itself, as nothing can beat Scott Guthrie’s nice introduction on his blog. Something I’ve noticed about these new piece of technology, though, is that debate seems to rage up about how exactly to use it.

 LINQ has the nice ability to eliminate the need for many data layer projects and simplifies everything down significantly. To put it rather succinctly, you have the option to make a database object and call pre-made stored procedures like methods, or perform “in-line” LINQ to SQL commands.

The temptation to use in-line calls is tempting. That eliminates any database work besides initial creation and relationships. No more creating stored procedures and then calling them from code. Everything is contained in one place. You can even view your entity relations from inside of Visual Studio 2008.

However, many people point out that in-line SQL is not very efficient. The database optimizer doesn’t get a chance to be run on the query, not if it’s created dynamically. Therefore, traditionally stored procedures have been the “optimal” choice for database calls.

With LINQ, however, this may not be the case, or at least not as much as would be expected. Visual Studio magazine explains that LINQ can use eager or lazy loading to run its queries.

Eager loading loads up a ton of data at once, entire entities and relations. Lazy loading is a more “on-demand” type loading. What this means in more simplistic terms is that with lazy loading, there are many many roundtrips to the database, each one retrieving a smaller amount, whereas eager loading makes fewer trips for more data.

It seems that with LINQ, the hot topic is performance, and how to maximize it. Ultimately, you will probably take a slight performance hit from switching to LINQ. Is it worth it? That’s the question many many people around the world are asking themselves right now.

There are many methods of optimization, though, like pre-compiling in-line queries and just sucking it up and using stored procedures (which, as I mentioned earlier, can still be added to Visual Studio as methods of an entity object).

If anyone has some comments about LINQ I would be happy to hear them!

What .NET going Open Source really means

Microsoft and Open Source are two terms that are almost never seen in the same headline, unless it’s a negative one.

And yet today Scott Gu’s blog announced that .NET 3.5 is going open-source … kind of.

First of all, it won’t be fully open-source. At least, not at first. The move to open up .NET will be gradual, but eventually all class libraries will be open. Eventually.

Second of all, it is released under MS-RL, Microsoft Reference License. This is the most restrictive of all of the Microsoft shared source licenses. Essentially this means you can look, but not touch. The license is for reference only, accordig to Redmond.

This news will be disappointing to the many of Open Source gurus out there hoping Microsoft will jump on the open source bandwagon. It’s not really in the spirit of open source to release something that cannot be changed or touched at all.

So what does this news really mean?

For .NET developers this means that the code they are running their programs on can be debugged. An integrated debugger for .NET built into Visual Studio 2008 will allow devs to step into the .NET code and view the stack calls there.

Useful in some situations. Definitely a good PR move for Microsoft as well. The appearance of embracing open source without actually having to go through with it.

In all seriousness, what harm would it do to allow users to alter and redistribute their own additions to .NET? Microsoft releases the framework for free anyway, it’s not like it is a product in and of itself. You would think that they would appreciate the extra hands that would work on .NET for free.

Ultimately though, another added benefit is that more eyes can now look at the source and identify bugs. Right now it is somewhat difficult to report obscure bugs, as you need to get a tech support agent to reproduce the error. Then you generally get the message that your problem will be relayed to a developer, and that’s the end of it.

Now, with all eyes on Microsoft, hopefully they will see that people appreciate the gesture, but ultimately crave more.

Questions? Comments? Feel free to contact me, James Martin.
Email me, or leave a comment below!