Vista - Downgrading the Masses!

The regular non-technical folk around here HATE windows Vista. So I set out to catalog their complaints...

I hang out at low-class food establishments on a regular basis. While that has certain disadvantages, it does give me an otherwise rare opportunity to hang out with "regular" folk... you know, people that don't spend their whole life in front of a computer.

Since I frequently have my laptop with me, this generally sparks a large number of those "so you know anything about computers?" conversations. Mostly these are just plain painful, but I learn about common trends in the mass market this way.

For example, 2 or 3 years ago people would often notice the laptop and ask about it. They didn't know much about laptops and so the questions were basic questions: "Can you go online with those?" or "Does it run Office?". Generally people were interested to know if laptops were actually real PCs since they hadn't had any firsthand experience with them.

These days, the questions have changed. Everyone is either buying a laptop, or has already bought one. Very few people are mentioning the classic desktop PC anymore. These people aren't mobile and don't "need" a laptop as opposed to a desktop, but they are buying laptops anyway. I suppose this is a combination of the falling prices of laptops, and the growing desire for a less "invasive" home PC... something that fits on a desk, doesn't require assembly and wiring, etc.

This trend toward laptops hasn't made most of these people more intelligent or tech savvy of course. The questions are still as painful as always.

One of the more depressing trends over the last year or so has been the nearly universal hatred for Windows Vista.

This isn't the typical mass-media fueled hype, nor the "hate the man" stuff you used to hear... you know, the common wisdom that says that Bill Gates is a rich monopolistic ass-hole and Windows is crap... go Linux!".

Not this time. This is a pragmatic hatred fueled by firsthand experience.

I've been using Vista regularly for almost 2 years now (since late beta days). While I don't "like" it really, I personally would not go back to Windows XP either. I consider it a decent upgrade, but it certainly had a rocky start. I did finally turn off User Access Control though. I tried to get used to it, and like it, but as a developer too much of what I do requires admin access and I grew tired of the constant black screen prompting.

The number of people that report hating Vista or having actually downgraded to Windows XP was staggering to me so I started keeping track of these conversations formally back in mid-April. I created a simple text file to track the opinions as they were offered.

Today that list looks roughly like this:

Had Vista and Downgraded = 61
Has Vista wants to Downgrade = 23
Has XP wants to Upgrade = 5
Has XP refuses to Upgrade = 56
Has Vista and will stick with it = 4
Has Vista and likes it = 0
Bought or will buy a Mac = 5

That's 154 people and not even ONE of them claims to like Vista. Now, I doubt all of the people refusing to upgrade will actually refuse in the long run and I doubt all of the people wanting to downgrade will actually do so. But the trend is still crystal clear.

The largest group actually DID downgrade back to XP, which is a fucking insane number of people. Do you have any idea how difficult it is for an average non-technical user to perform an OS install? Of course most of these had a tech-savvy relative (or child as was often the case) do the downgrade for them. The fact that so many people actually went to the effort to downgrade is a very strong indicator that this is a very REAL dissatisfaction and not just the idle complaint that has always been there since the PC was invented.

Only 5 of the people I've talked to have bought a Mac instead of a PC, and none mentioned any serious intentions towards moving to Linux, though some of the more computer literate did ask me if I had an opinion about Linux (I never recommend Linux to non-technical users though).

What this tells me is that Windows Vista is a colossal failure in the market. Even Windows ME was better received than Vista (and ME was truly a pile of shit).

While people around here aren't running to the competition yet, if Microsoft doesn't get a new and better OS out the door fast, they will be in serious trouble.... if it isn't already too late.

Pack'n less

My XD .40 cal Sub-Compact just wasn't working out... so I've adoped the Walther PPS 9mm as my new choice firearm for conceal & carry.

In the fall last year I bought an XD .40 sub-compact handgun made by Springfield Armory. I had chosen the XD because I really liked the feel of the weapon, had fired a 9mm version and been very pleased, and the .40 offered substantial fire-power in a small form factor. I also loved the features of the XD line.

My intent was to carry it on a semi-regular basis.

That was a little more than 6 months ago.

Overall, the XD is a fantastic weapon, and I would recommend the XD line without reservation to anyone that asks. There are a LOT of good guns on the market, but the XD line is truly at the top of the heap.

Unfortunately, I have discovered some problems that have forced me to the conclusion that the XD sub-compact .40 is just not the right weapon for me personally.

After a couple thousand rounds of regular target practice, I just wasn't consistent in how well I shot. Sometimes I'd do well, and others I'd hardly put one in nine rounds on the paper at 5 yards. I'm not naturally a "good" shot. But after that much practice I should at least be consistently bad. The gun itself was fine... other people pick it up and do fantastically well with it.

The other problem was the size of the weapon. I'm 6' 4" tall and weigh in at around 145lbs --tall and skinny. The XD is a sub-compact with a 3" barrel and an overall length of about 6.5". It isn't a large weapon in those dimensions, but the slide is still a 2" wide chunk of steel. No matter how slack I try and dress, the XD sticks out like a brick making wearing it concealed nearly impossible.

But it was the lack of consistent accuracy that forced me to admit that, while I loved the XD, it was not the right weapon for me. Not knowing if you can reliably defend yourself with your side-arm is far worse than just being unarmed in the first place. It's safer for both you, and anyone else that happens to be around when the shit hits the fan.

So reluctantly, I decided to give up my XD and start looking for something that fit me better.

The search was long, and there were a lot of weapons to research and consider. In the end though it was the Walther PPS 9mm that ended up in my hands.

I didn't get to shoot one of these before I bought it. It is a new weapon, and they are very hard to find. Fortunately, one local shop had one in stock, and after seeing it myself I decided it was worth the gamble... well, that and the fact that the shop's owner gave be a reasonable trade-in price on my XD that put the Walther in range of my limited budget (the PPS retails for $650 - $750 when you can find them at all). 

The Walther PPS is thin and light. It weighs in at about 20oz loaded, and is just over 1" wide at the thickest point. And it measures just over 6" long. It is significantly smaller than the double-stack sub-compacts like the XD, but still feels more substantial than the Pocket guns such as the Kahr PM9 or those made by Kel-Tec. The thin design it what makes it conceal well, though it is still a tad largish if you want to use a pocket holster. As thin as I am, the pockets on my Dockers slacks are deep enough to hide it well enough.

What impresses me most about the PPS is the recoil. I've fired a lot of 9mm handguns, and this is the softest shooting one I've yet to handle. While it is very thin, the backstrap is just big enough to spread the recoil evenly over you palm, and the double recoil spring design and the shape of the weapon itself do the rest.

The slide action is smooth, and the trigger action is great, though a bit stiff at the break point until I put a few hundred rounds through it.

Some people have problems getting used to the magazine release, which is integrated into the bottom of the trigger guard. I personally got used to the release mechanism very quickly, but if you have developed a habit of using a standard thumb button release, it might take you longer to get used to.

One of the features I like most is the choice of 3 magazine sizes. It ships with a 6 and 7 round magazine. The 6 round is flush with the bottom of the grip leaving your pinky exposed, while the 7 round adds enough extra grip to give most people's pinky a resting point. There is an 8 round magazine as well which gives even people with large hands pinky support. It also ships with two backstraps... a small one for people with girl hands, and a large one for people with hands designed to break rocks.

The only real complaint I have is the "QuickSafe" backstrap mechanism. Removing the backstrap decocks the weapon and renders it un-firable. This also assists with takedown. If you remove the backstrap you can field strip the weapon by just pulling down on the take-down levers and pulling the slide forward. You do not have to pull the trigger or pull the slide back in any way. This makes it very simple to disassemble. Personally though, I would rather have a grip safety instead of the QuickSafe mechanism. It's a minor point though.

One other minor complain for some people is the somewhat unpredictable direction the ejector will send your spent casings. Mine tends to throw them up and slightly to the right. If you are a left-handed shooter though, it might rain the casing down on your head. I don't have a problem with it as the casing generally fly over my right shoulder, but there have been a couple of them bounce off the top of my head anyway.

I've only put a few hundred rounds through it so far, but I've found that I can shoot much more consistently than I did with my XD. I'm still not a good shot, but I can see improvement on each trip to the range now.

The biggest disadvantages to owning the PPS actually have nothing to do with the weapon itself. It is such a new weapon that it is very hard to find accessories for it. There are a few decent holsters on the market now, but not as many as with other more popular weapons. Magazines are the biggest problem as the cheapest I've been able to locate are in the $50 (each)  price range. And if you want lasers or custom sights you'll find these even harder to come by. This makes the PPS an expensive weapon to own.

But the weapon is gaining popularity fast, and so more and more accessories are coming out for it every month.

If you are looking for a CCW weapon, I highly recommend you consider the Walther PPS.

I'm not advertising for you...

The South Carolina DVM expects to use my car's license plate to advertise for the state... we'll see about that!

Every few years the state of South Carolina sends me a new license plate. For some reason, they just can't pick a color and design and stick with it. But this time... they have really managed to pissed me off.

Here is the new license plate that arrived in the mail yesterday.

First of all, I don't give a rat's ass about the plate being pretty. I was fine with the plain white & blue plates with the high-visibility red font they used to use in the 80's. The purpose of the plate is to give police a way to identify the car. That's all it has to do. But if they want to spend my tax dollars making it all pretty then that's OK with me.

What gripes my ass though is that "TRAVEL2SC.COM" written at the bottom of the plate.  Never mind that it's in all upper-case... it's the idea of having it there at all that pisses me off.

I don't mind branding to some extent. If you make some physical thing that I buy and you want to have your name on it then that's fine as long as your branding isn't over-the-top annoying and doesn't negatively impact the usefulness of the thing you brand. Take my car for example... it has the Toyota logo on front and back, and on back the word "Toyota" and the model of the car. That's fine with me. If someone looking at my car likes it, they might find it useful to know what kind of car it is so they can see about getting one themselves. I always like to be able to look at other people's car and know what kind it is too.

Same with most things and branding... as long as you keep it kinda subtle, tactful, and out of the way.

Advertising is a different matter though. I fucking refuse to advertise for you, especially not for free.

Take my car as an example again. I went to several car lots before I bought my car. One of them had a car that I liked, but it had a big-ass steel logo for the car dealer bolted onto the back. The dealer logo was actually larger than all the Toyota logos combined. I asked them if they could order me the car without the logo or remove the logo and "repair" the hole that the bolts would have left.

They looked at me funny and said they couldn't do that. So I told him that the only way I'd buy his car is if he gave me $100/month each month I owned it or knocked off $7200 off the price ($100/month times the 6 years I'd financed the car for). He laughed thinking I was joking... so I got up and walked out of the sales office.

I ended up buying the same car from a dealership that had a simple "sticker" logo that I could remove. I made sure they knew that the only reason I bought their car instead of the other guy was because I could remove the logo.

Its just a thing with me. I will allow you to brand my stuff if you can do it tactfully... but I'm not running around throwing someone else's name in everyone's face. That's why I don't buy a lot of name-brand clothing lines. If your logo is the prominent feature of the shirt, then fuck-off! You aren't charging me $20 to $40 for a shirt AND getting me to do your advertising for you.

But in this case with the license plates, it is even more offensive to me. The state requires that I have a license plate, and I have no alternative vendor I can go to get a plate from. I could buy a "custom" license plate from the state that doesn't have advertising on it... but why should I have to pay $50 more for the "privledge" of dodging having to do the governments dirty advertising.

In the end... duct tape came to the rescue:

I'm serious... I will not advertise for you. I don't give a damn if you are the government or my mom. If you want me to advertise for you.... pay me!

ASP.NET: web site vs. web application project - Part 2

My previous article about web sites vs. web applications seems to be a popular article, generating about 1/2 of the total traffic for this site. Most of that traffic comes from searches. Unfortunately, I doubt the old post really contains what people are actually looking for. So I'd like to spend a little text describing these two project types and how they compare.

A little background:

Visual Studio 2005 introduced the asp.net "web site". Not only was this the only project type for asp.net when VS 2005 shipped, is was also major change from the old VS 2003 web project. In web sites the code is compiled on the fly by asp.net and there are no visual studio specific project files or auto-generated classes involved. This makes web sites simple and easy to deploy (just copy source to a web server and browse). 

Not long after VS 2005 shipped, MS released the Web Application Project. This was an add-on initially, but has since been folded into VS 2005 with SP1 and shipped with VS 2008 out of the box.

The Web application project is an updated version of the old VS.NET 2003 project type. It organizes the project using the familiar VS project files and such. It requires you to compile the application before you can run it, but you gain more control over how the application is compiled.

I'll omit a detailed technical description of the differences between web sites and web applications. This territory has been better covered elsewhere on the web, and the MSDN documentation that ships with VS 2008 covers it in detail too.

What most people want to know is, which is better?

The answer does depend a little on personal preference and what kind of application you are building.

I write and maintain several web applications. Some are very small personal sites with mostly static content, while others are huge data entry applications. My largest solution includes about 22 different class library and database projects that support a single web site project.

The web site project has always disappointed me, even with my smaller applications. The Web Application project type has become my preferred approach for all new projects, and I've since converted most of my older web sites to web applications as well.

Web site projects:

Web sites are a little simpler if you are doing inline code instead of code behind. Web sites also reflect changes in code files without needing to be manually compiled. That means you can edit a file and just refresh the browser.

If you need to explicitly "build", so you can ensure your code doesn't have errors for example, you can still do so. However, the "build" command doesn't really compile the project... it just verifies it using the dynamic compiler. While 99% of the time this is fine, I have come across a couple of minor cases where the verification compiler didn't find an error, but attempting to run the site for real did.

Major advantages of web sites:

• Everything in the project's folder is part of the project. This makes it easy to use other editors or tools with web sites. If you add files outside Visual Studio, they will still be part of the project. If you edit a file outside VS it will still be compiled and the changes visible when the site is viewed in a browser.
   
• You can deploy without having to compile... just XCOPY and go. Web sites do support pre-compilation if you choose to use it.
   
• Files don't have to be written in the same language. VS will support having a mix of VB and C# code on a file-by-file basis. Sounds good, but I've never found this useful personally. Maintaining a site is much easier if you stick with one language.
   
• The add "item" dialogs in Visual Studio are more intuitive for web sites. I'm not sure why both projects don't use the same dialogs, but they certainly don't.
   
• Profile's design time compilation is automatic. The ProfileCommon class is created dynamically making it easy to work with the profile provider in a strongly typed way.

The biggest annoyance for me with web sites are:

• No way to really "exclude" a file without renaming it. Refactoring tools and the "compiler" have to crawl through every file in your application. This can get slow if you have a lot of files. For example, I often use FCKEditor, which has a dump-truck load of files. Most of them are not asp.net files. But just having to scan through them when I build or refactor can really slow things down. This has gotten a little better in VS 2008, but not fast enough for my tastes.
   
• No control over your namespaces. Sure, you can manually add namespaces to pretty much anything, but visual studio will fight you every step of the way. With generated code such as ADO.NET DataSets and such, this gets very hard to control. Eventually you will give up and just let VS put everything in the default namespace. In large applications this gets very annoying, especially if you like a well structured application.
   
• It is hard (read, nearly impossible) to reference pages, user controls, etc from custom classes in the app_code folder. This produces some interesting problems if you are doing anything fancy like dynamically loading pages or controls and such.
   
• The application compiles to the asp.net temporary internet files folder. This is a drop location for all that dynamically compiled code that the asp.net compiler will produce. This is a fine mechanism until it breaks. When it breaks you can get really weird errors from the compiler that don't make obvious sense. These are pretty easy to cause by accident. For example, if you tell VS to "build" then refresh a browser pointed at the site at the same time.... the two compiles often conflict in some bizarre manner corrupting the temp asp.net files. When this happens, assuming you figure out that this is the cause of the problem, you have to shut down VS and the web server, manually remove the files from the temp folder, then restart everything.
   
• No ability to product XML comment output files. I use the crap out of XML comments, so this is the big deal breaker for me.
   
• Not much control over build outputs. In most projects you can set whether a file is compiled, copied to the output directory, and such. But not with web sites. If a file is in the project's folder structure, it is part of the project.
   
• Team Build hates web sites. Lacking a project file, you can use the web deployment project add-on to help out, but even still I've found that trying to automate a build for any significantly complex web site is a disaster and time-sink.


• Disconnected Source Control. VS supports working disconnected from source control these days, but I find that it often has problems keeping web sites in sync when you reconnect. This is a sporadic problem, and hard to reproduce, but seems to be more common with delete, rename, and add operations.

The web application project:

The web application project is a little more formal than web sites. You get an actual project file by which Visual Studio tracks the files that are in your project. Web applications do generate "designer" files for your pages that link the code-behind to the controls you've put in the markup, but unlike old VS 2003 projects these are much simpler and leverage partial classes and such.

The drawbacks are:

• The site has to be compiled/built before it will run.
   
• Your project is specific to only one language.
   
• No automatic support for a Profile class. You have to use a separate tool to generate ProfileCommon or write one manually.

The major advantages are:

• Compile and refactoring is much faster since VS has a way to track what is in the project and doesn't have to scan everything in every folder. Also, you can have stuff in the folders that aren't part of the project (I find this useful sometimes).  


• You can control namespaces, assembly names, and build behavior for various files in the project. Namespaces are also automatically managed by VS based on the application's folder structure. This includes a real "project properties" editor too with all those familiar things like build options, references, settings, etc.
       
• You can generate XML comment output files.
       
• You can exclude files from the project without having to rename them.
       
• MSBuild and Team Build work much smoother with web application projects.
       
• Custom code files don't have to be in a specific folder, you can put them anywhere and organize them however you see fit.
       
• Classes can refernce pages and controls.
       
• You can split the site into multiple projects.
       
• Include pre and post build steps to compilation.
       
• Disconnected source control seems to work more consistently with web application projects.

The bottom line:

Web applications scale better and are just plain smoother than web sites assuming you plan to do most of your development directly in Visual Studio. The only major difference is that you have to build manually... so get used to CTRL + SHIFT + B. At least it's pretty fast in VS 2008 and it won't blow up the temporary internet files folder like web site projects can.

I can't say that web sites are inferior to web applications overall. There are cases where web sites do work very well, especially with smaller and simpler projects. I just personally don't find that having on-the-fly compilation is really much extra value, while more control over the application's compilation is always a good thing.

C Snobs

Recently, I ran across one of the many little spats that develop between bloggers. This time it was between Alastair Rankine of girtby.net and Jeff Atwood of Coding Horror.

It's the typical spat.

One blogger decides that another blogger is no longer writing what they want to read. Rather than just unsubscribe, they write a big public post about why they have decided to unsubscribe and why the other blogger sucks.

And, as is typical of these kinds of spats, the blog post starts by talking about how they don't normally slam on people they unsubscribe from... then they slam on them anyway.

Sigh....

Anyway... you can read the spat at the two links below if you want... but the details aren't that important to what I have to say.

Rankine's post:

Atwood's reply:

What really got my attention in reading Rankine's part of this train-wreck (this is the nerd version of Jerry Springer right here) was that Rankine jumped Atwood's shit for not knowing C. In fact, he went as far as to say that by not knowing C, Atwood was not credible as a programmer.

Every time I see this opinion put forth by otherwise smart programmers it makes me foam at the mouth in rage and frustration.

This isn't a minority opinion in my experience.

I see this "must know C" prejudice all the time. I've even been passed over after a job interview had revealed my lack of a C background. There isn't any telling how many interviews I didn't even get to attend because my resume lacked C/C++ (even though I've never applied for a C/C++ dev position).

I also see this idea put forth by people that I otherwise respect... even Joel Spolsky, a hero of mine, makes a big deal out of knowing C. In his legendary advise to college students article  #2 on his list is "Learn C before graduating".

He even gives an amazing (in terms of stupidity if you ask me) example:

"...if you can't explain why while (*s++ = *t++); copies a string, or if that isn't the most natural thing in the world to you, well, you're programming based on superstition, as far as I'm concerned"

So how does knowing this help me write better C#? This doesn't directly apply in C#. Wouldn't it be better if I knew how C# does string stuff, which mechanisms are more efficient in specific cases, and why?

I could take Joel's advice and go off wasting my time learning C. Then, like him, I'd be able to translate my C# concepts into C in order to understand how it all works under the hood... or I can just learn how C# works and skip the C translation step. Both are valid approaches, but I think it's unfair and narrow minded to discount my ability to understand what goes on under the hood just because I lack a formal C background.

I'm not saying that knowing C would hurt me. In fact, I've often wished I had the patience to go back and learn C. But honestly, writing in C makes me want to die. How did any of those old C guys actually get anything done?

Besides, if everyone based their understanding of higher level languages on C then where is the diversity? In some ways, my understanding of some areas of C# is actually better than that of people with C backgrounds precisely because I DON'T have a C background.

While Joel has good reasons for preferring C experience in his employees due to the kind of development his company does, that doesn't map well to other areas of the programming field.

I do asp.net web applications. When I'm hiring, I'd MUCH rather you have a solid understanding of how IIS works internally. I don't care if you can write a fancy-pants sorting algorithm in C. I trust that the .NET framework guys will work out most of that anyway. As long as you understand the internals of C# or VB and the .NET framework you'll do fine in my field without knowing any straight C at all.

When someone like Rankine makes such a prejudicial assumption about an otherwise competent person based just their lacking a C background... well... it strikes me about the same as the racial prejudices I've had to hear all my life.

See, I live in the Deep South of the USA where all Mexicans are illegal, all black men have 15 kids by 5 different women, and all Arabs are terrorists. Here most narrow minded ass-holes blame their minimum wage income on the irrefutable fact that non-English speaking illegal Mexicans have stolen all the jobs. While everyone here complain that Mexicans should be wasting their time learning English instead working, the Mexicans are working their asses off, getting shit done, and getting paid.

I guess it's fair that all you C snobs can watch those ignorant non-C speaking savages steal all your jobs too.

while (*bigot++ = *asshole++);//see, natural isn't it?

Linq to SQL Bug - "System.FormatException: String must be exactly one character long."

Ran into a very annoying bug today. When I tried to use Linq to SQL to read values from a rather unexciting table, the site threw up with

System.Web.HttpUnhandledException: Exception of type
     'System.Web.HttpUnhandledException' was thrown. ---> 
System.FormatException: String must be exactly one character long.

 It took a while to narrow it down, but it turned out to be a field in the table that was defined as NVARCHAR(1). The LINQ to SQL mapping was System.Char. All the other NVARCHAR fields were mapped to System.String.

Not much out there on the forums about it when I did a casual google search either so I thought I'd post about it here.

I did find it listed as an active bug on the Microsoft Connect site here.

The problem is that Visual Studio's LINQ to SQL designer incorrectly maps this to char instead of string. Since char types cannot be "empty" you will get an error at runtime if any of your columns contain empty values. Null will work fine though.

The easy work around is to just manually toggle the type to System.String in Visual Studio's property window. If that doesn't work for you, you could change the column to char(1) in the DB instead and just not put empty strings in there.

In my case, I'm using a middle initial field. I like to treat null in my database as "undefined"... meaning that no value was specified at all or the question hasn't been answered. This is different from empty... empty would mean that the question was asked, and the answer was "no value". The difference is subtle, but important sometimes.

TicketDesk 1.1 released

I've released an update  for the TicketDesk  issue tracking application over at CodePlex.

TicketDesk is an issue tracking system for IT Help Desks and support centers.

TicketDesk is efficient and designed to do only one thing, facilitate communications between help desk staff and end users. The overriding design goal is to be as simple and frictionless for both users and help desk staff as is possible.

TicketDesk is an asp.net web application written in C# targeting the .net 3.5 framework. It includes a simple database with support for SQL 2005 Express or SQL Server 2005. It can leverage SQL server for membership and role based security or integrate with windows authentication and Active Directory groups.

TicketDesk 1.1 contains some bug-fixes and a few important new features. You can learn more about TicketDesk at the TicketDesk project home at CodePlex, or you can read my previous post about TicketDesk's origins.