Server Error 402

Lets say you're building a database that lets you search for file names.  During the planning phase, we want to figure out the average file name length, so that you can optimize our algorithms.  If the average length of your files is say, 12, you optimize your database for strings of length twelve.  Fairly simple.  I wrote a simple console program to recurse through directories and calculate the average file length.  On my Vista system, the average length on my system drive is twenty-seven.  The naive approach is to use this number, and optimize everything for strings of length 27.

For argument, you were able to make your string comparison algorithm faster for lengths of 20 or greater, but slower for anything shorter.  Given the average, this seems like a good decision.  (You pre-alloced the arrays or something).  However, given the more data, this would actually result in a decrease of performance. I've made a program that gives more exact numbers.  I've uploaded the C# code for here.

What the code does is create a file, named lengths.csv with the number of files of every length, from length 0 to 254.  Example output from my system, clipped because it's 256 rows.

We can see some irregularities.  The length of files seems increase rapidly until you hit 12 (the length of 8.3 compliant), then decrease.  There are some irregularities in the output, with some file lengths.  Files of length 160, 107, 108, 99, 50, 42 (hah!), and 32 are shown to have higher numbers of files.  I've uploaded the full csv file here.

Now, with this CSV document, we can do some basic analysis using Excel (or whatever the Open Office equivalent is).  To predict the changes of a file being any one length, we can simply calculate the percentage of each file being a certain length.  Since that sentence was wonky, i'll do it with math: 

Files of Length Y / Total Number of Files = Chance of File X being Length Y

Or, in Excel, the formula =B2/SUM(B$2/B$256).  Given our input data, we can calculate that any given file has an 8% chance of a filename length of 11, and a 14% chance of it being 12.  Now, going back to our algorithm example, and out sample input, we can tell that 48002 files would benefit from our optimization, and 72273 would have a decrease in performance.  So on any given set of input, there is a 60% chance a performance decrease, and a 40% of performance increase.  That's a giant boatload of fail for any optimization algorithm.

But this method imprecise.  For instance, given our limited data, there is a 0% chance of a file having a length 166 and greater.  This simply isn't the case, but due to our limited sample size we don't see any evidence of it.  We'll address this in Part 2.

From james h hall, who probably ganked it from someone else.

How old were you when you started programming?

First attempt?  13.  I failed.  Miserably.  I picked up C++ for dummies using my hard-won lawn mowing money and fired up the gcc compiler that came on the CD.  My longest program was the first 'full program' from the book, which was converting Fahrenheit to Celsius.  That's as far as I got.  I just couldn't grasp the concept, so I delved into 3d modeling instead. 

How did you get started in programming?

After I got into college as an Information Technology major, I promptly switched to CS when the associate dean told me that there was fiber running directly to the back of every lab computer.  So that's my real programming start.  Doing IT work also led to writing batch files:  a lot of the stuff I was learning at the time was easily automated, and I was pretty lazy.

What was your first language?

C++, which was standard for CS majors at my university.

What was the first real program that you wrote?

A website, written in PHP.  It was my first blog (long outdated and pulled down because I was an angsty teenager).  I originally set up a newspro blog while all my high-school friends were busy playing with livejournal, but I wrote my own system after I took my first class in C++ at uni.  It was up for four years and only got hacked once.  SQL injection.  D`oh.

What languages have you used since you started programming?

C++ to PHP.  My first internship was doing VBA in excel, which morphed into ASP.NET 1.1 with VB.NET.  After that our university switched to Java (making the first year of C++ and pointers worthless), and I switched to C#.  After tasting the raw power that was the .NET framework, I couldn't go back to Java and it's shitty calendar classes.  I bummed around ASP.NET for a while in C#, then switched into WinForms applications, using C#.  My current job is in VB.NET, which I found out the day I showed up for work, not during the interview.  Whoops.  I would currently pick VB.NET as my language of choice.

If you knew then what you know now, would you have started programming?

Hell yes.  Programming is awesome.

If there is one thing you learned along the way that you would tell new developers, what would it be?

You don't know anything.  Nothing.  Zero.  If you're an arrogant prick, like I was, you will get slapped down and humiliated.  Which was a fantastic learning experience, btw.  Once you realize that you don't know anything, you can really start to see what the world of programming has to offer.

Wax is the hardest thing to clean ever.  It's water-resistant, cleanser doesn't work on it, and it sticks to everything when melted.  Sinks, toilets, pots, pans, screwdrivers, pliers, scissors, and pipes.

Let me explain how I got into my pipes-being-full-of-wax situation.  I have a large double-sink bathroom in my apartment.  His and hers, even though it's only me.  In between the two sinks is a large red 4-wick candle.  Mine happened to be strawberry-cheesecake flavored.  Or so the cashier at Walmart informed me.  I lit it up yesterday evening and then went to go cook dinner.

About twenty minutes later, I go back into the restroom. The candle, which was almost new, is gone.  The center has been completely de-waxed.  There is a beeline of crimson from the candle, over the candle holder, over the countertop, directly into the sink.  And down the drain.  It's totally clogged, the wax is slightly hot, and the candle has extinguished itself.  Fuck.

I broke the dried wax off the sink and threw it away. Which leaves me with the hard wax in the drain and pipe.  I ran some water, just to be sure:  yep, it's 100% clogged.  The toolbox came out and the pipe underneath became disassembled.  Well, almost.  The U at the bottom of the pipe came off, and was fine.  The straight metal pipe coming out of the sink, which is about a foot long, was completely packed with red, strawberry-smelling wax.  It's also screwed on with a fitting about a millimeter larger then my biggest wrench.

At this point, I made myself a gin and tonic.  I wasn't planning on drinking, as it was a Sunday, but fuck it, I have waxy pipes.

A quick google revealed nothing.  Apparently wax isn't supposed to get into your plumbing.  I'm was on my own.  I figured my best bet was to melt the wax, so I started boiling two pots of water.

This is where it gets interesting.  If I poured a pot of boiling water into the sink, and the wax melted, I would suddenly have a gallon of boiling water and a large amount of liquid wax coming out into my cabinets.  That's fine, I could put a bucket there.  Now if it didn't melt, I'd have a plugged sink full of boiling water.  I didn't think about it much in advance, and in went the water.  Thankfully, the wax melted.  Kind of.  About a drop at a time bubbled up from the drain to the surface of the water, and then slowly hardened.  I had an epiphany.  That's right!  Wax floats!  So all I'd have to do is keep pouring boiling water into the sink and slowly melting the wax, and it would simply float to the top to be removed!  Score!

What I didn't realize is that as soon as the wax left the water, it hardened.  So when I pulled it out using another pot, the pot became covered in wax.  And when I took a screwdriver to the drain, to try and loosen up the clog, it become covered in wax.  And I was working about a centimeter above boiling water, which wasn't pleasant.  I lost two screwdrivers and a pair of scissors to boiling wax puddle.  I eventually got amost of it out, and was stuck with a method of disposing the semi-hardened wax.  I dumped it into the toilet, which was a mistake.  Now the inside of my toilet is coated in wax.  At least it smells nice.

I decided to start attacking the wax from the other end.  I poured two more pots into the sink and went underneath, shoving another screwdriver up into the pipe. The clog suddenly cleared and two gallons of boiling-hot wax-water rushed out at me.  Thankfully, I had a bucket under the pipe, so my cabinet was protected; my hands were less fortunate.  I wouldn't feel so bad about it, except the entire time I was thinking to myself "Wow, this is a really bad idea.  Oh well."  Poke poke poke.

I ran more hot water, and eventually put the pipes back together.  I then had to clean my tools.  They're all covered in wax.  Google recommended using an iron or hairdryer.  I'm male and have access to neither.  So I go with the next best thing: freezing them.  Which seems to be working remarkably well.  It's just odd to see a freezer full of pots and screwdrivers.

Lesson learned:  don't put candles near sinks.  And that melting wax in your plumbing is an excellent way to make it smell fresh.

Skip my personal experience and go right to the list.

I realized, last week, that I am a contract coder.  I never intended to be one; I wanted a job with a regular boss and a 401k and a health insurance plan.  Sure, contractors earn more, but they also deal with a lot more instability in their daily lives.  As of right now, I'm not sure if I'll be employed next week.  I have a job lined up, but it's only a temp deal for around $1500 total.  That covers about a month of my living, if I stretch it thin.

Right now I have a desk and a job and an employer.  My employer doesn't seem to exist sometimes; I have very spotty (once-twice a week) contact with my boss, and I deal mainly with the customer over the phone.  My paychecks are irregular; I work 40ish hours a week and get my pay at intervals ranging from 6 to 42 days.  Right now my paycheck for the 1st was received on the 16th.  Over the past few months I've accrued over $600 in late fees due to instable pay.  This has all been on the same job with the same contract.  Well, contract is a funny word; I didn't sign anything.  Right now I go to work and do some stuff and then get paid an agreed-upon amount.  If myself or my employer ducks out at anytime, I've got no legal reprisal.  I doubt I'll even get 1099ed.

This life sucks.  Sure, my friends are making around $7-10/hour, and I'm getting ~$30, but I lose tons of my money to extras.  I have to buy my own computers, my own IDE (and add-ons), I have no automatic tax withdrawal, I have to get health insurance through a third expensive party.  I'm not guaranteed pay at all.  This is, by far, the worst possible career choice right out of college.  If I was at a startup, that'd be something different.  That'd be a common goal with the allure of hitting it big.  No, the best thing I have to look forward to is a slightly bigger paycheck that might on time and not getting nailed by the IRS.

I repeat: do not start contracting for yourself right out of college.  Unless you like the adventure and the unknowns or you just have a lot of extra money lying around (Like, taking out loans instead of paying them back, like I start next month), I would not recommend it at all.  If you do it on the side to get some extra cash?  That's fine; that's extra.  But when you first get on the scene and are trying to make some money to eat more then hot-pockets and beer, get a stable job.

If you decide to ignore my above advice, I have some other, possibly more helpful advice that I've learned (and wished I'd followed) as a contractor.  I've only been doing this about half a year, but I think it's worth it's salt.  It's born out of sweat and tears (well, not tears, but a nervous breakdown or two.  Well, the salt that would have been in the metaphorical tears, so lets go back to tears). 

Enough with the intro shit, lets get right to it*.

1. Get your taxes done professionally.  There is a ton of stuff you (and I) don't know about that you can get money back on.  Well worth it.
2. Sign contracts with your employers.  Starting out it's easy to use the line "Oh, sure, I'll write up that program for $15/hour."  Don't do it.  Nothing sucks more then bugging somebody for money when you don't have a written agreement.
3. Don't write code without signed specifications.  Write your specifications jointly with your clients and agree what the program will and will not do.  Software Requirements from Microsoft Press is a great book, and a must read for any independent contractor.  Even if it's a simple list of 'This software will/this software won't', it's better then nothing.
4. Make sure your employers give you the right tax forms.  In GA, if you do over $700 of business with somebody, they need to send you form 1099.  This may be a bigger issue with some people, but I find it pretty important.  I don't like living in fear of huge fines.
5. Understand how software licensing works.  When I first got out of school, I had my wonderful MSDNAA academic licenses of Visual Studio, SQL Server, Visio, Windows Server, Access... well... every Microsoft product but Office.  Pretty much everything you do now will be under the 'unacceptable' category.  There's probably a few good resources on the web, but actually going through and reading the EULA before clicking Next does wonders too.
6. Don't spend money until you actually have it.  If you send out an invoice for $1000, don't spend the money until it's back in your hands or in your bank account.  Don't assume all clients will pay prompt; calling them on the phone and telling them how you have to pay rent is remarkably unprofessional.
7. Know when to say 'no' to new features and additional work.  Most customers do this unintentionally, but think critically about every little 'change' made to the software.  Even something as trivial sounding as upper-casing everything in the application can turn into a hassle; make sure they know it's billable.
8. Keep track of your miles.  Start writing down all of your odometer readings when you drive to and from customer sites.  This is tax deductible/See #1.
9. Track your finances and save all of your receipts.  For everything.  Get a filing cabinet.  Get some financial software.  I use MS Money (it's... decent.)  Another guy I know uses Quicken.  Apparently they both kind of suck, but you need to keep track of everything.  Hell, use ledger paper if you have to.
10. If possible, use a separate email address for work purposes.  This makes categorizing everything when it sinks into your inbox.  Don't get client emails intermixed with forwards of forwards from relatives who just got the Internet.
11. Keep business and friendship as separate as possible.  When you start out, chances are a lot of your customers will be friends, or friends of friends.  Remember, this is a business and your livelihood.  If they can't make pay that's acceptable to you (or want something for a ridiculously low price), don't do.  Friendship be damned, you have to eat.
12. Know when a project is too big.  Don't agree to do something unless you're sure you can do it.  Right out of college, everything seemed easy to me.  I estimated a 6 month job at about 1 month.  Whoops.  Chances are, when you agree to do a small website for a local business over lunch one day, you're biting off a huge project.  The line 'I'll have to know about the project more in depth before I commit to anything.' has served me well.
13. Make sure you have some sort of health insurance.  Car problems suck, health problems suck more.  One ambulance ride can set you back a few thousand.  Nothing will cut your profits faster then a trip to the hospital.  It is well worth the $100-$200/month.  (Monthly rates may vary, mine are much higher.  Damn accident-prone-ness.)
14. Never ever ever ever ever stop learning.  I know this goes for programmers and IT guys and computer people double, but it goes quadruple for the self-employed.  Not only do you have to keep up with technology, but you have to keep up with running your own business and everything about your life.  You have no handy HR rep to go to.  Always be on the lookout for information.
15. Keep your clients costs in mind.  All of the clients I've worked with are fond of fixed-price contracts.  Fixed price contracts are hell on developers.  We like hourly, in case unknown stuff pops up or your client keeps making changes over time.  If your client has a set budget, keep it in mind.  Bill hourly, but only work hours that will meet your clients budget.  If they have $2000 to spend on the program, and you bill at $10/hour, work 200 hours.  Cut the extra stuff, like input validation, and any other crap that doesn't fall into the primary use cases.  Yes, there is a matter of personal pride, but presenting a large bill to your customer with excellent software is probably worse then presenting the expected bill with some average software.
16. Make sure to discuss long term client support options.  You might not be contracting forever; who is going to take care of the application after you move off across the country?  Not saying that anything needs to be decided, just make sure that all parties know how support is going to work.

* Bonus points for identifying the quote.

Edit:  A few days later, some guy on reddit posts this: 10 Absolute "No's!" for Freelancers

Last Thursday I was given the okay to write a company bug tracker.  It was pretty clear that we needed a tracker, but I never got the okay to do it.   I've been playing with the idea of using SubSonic, but my other project is sitting at 85% completion and I didn't want to introduce new technology until it was delivered.  Now was the perfect opportunity to use a rapid development tool to build a new bug tracker.  As of today, it's functional.  Users can file bugs, read bugs, upload files, assign bugs, etc.  All in the span of about 14 hours of development.

SubSonic accounts for a lot of the speed in development.  Since I wasn't worried about SQL or SPROCs or database side stuff, I could focus solely on the business logic and HTML.  (I must admit that about two hours were spent tweaking stylesheets; I'm a horrid designer.)  The project got up fast and I only used the generate command of SubSonic.  No Scaffolds or ManyMany lists or Sugar module.  To be honest, I didn't deal with the scaffolds until the last hour.  I was simply amazed by what they could accomplish in such little code.  I had been writing the CRUD pages for my tables, but after I learned of this super-easy method and how well it worked, I deleted my pages and replace them all with Scaffolds.

Huge mistake.  (Like, revert huge.)  One of the pages I was deleting was one for editing a basic Users table.  You know, name, email, address, social security number; the usual.  The scaffold worked beautifully for everything in the database.  The problem was that the DB table was synced with the ASP.NET SqlMembershipProvider to do security.  Whenever a user is added to the system, they get added to the aspnet_Users table by calling Membership.CreateUser(user, password).  Right after that, a row is created in the SiteUser table that stores all of the extra user information that we need.  They are joined on the user's username.  The scaffold doesn't know this, nor does it care.  I was screwed.

By using the scaffold in this situation, I was eliminating some necessary behavior in my application.  Sure I dropped the code size by more then 150 lines.  But the new stuff didn't include the one line I really needed.  Whenever you use RAD tools, you usually lose the ability to fine tune.

The same holds true for using a DataGrid vs. a Repeater.  The DataGrid does a lot of things magically.  I was amazed that it could just auto-generate columns and throw the entire table up onto the web page.  After the initial "whooosh" of the magic hitting my eyes at 80mph, I realized that the table wasn't easily customized and wasn't that flexible.  I ended up using <asp:TemplateColumn/> for almost every column.  Since I was essentially the code inside each table cell, the only thing I gained was not having to deal with the <tr><td> elements.  This is still an advantage, kind of.  But having all of my data was buried under <td>s and <div>s, it was incredibly hard to style via CSS.  I lost a an hour just trying to figure out how to make the <td> elements have a border.

I know it's naive to expect a new tool or technology to magically fix your problems.  No silver bullets and all that jazz.  When C# and Java came out, it was fantastic because we no longer had to deal with memory management.  I think this is a good thing; programmers shouldn't be messing around with memory.  With things like Rails and certain aspects of SubSonic, it prevents the programmers from overriding certain methods and styles.  When you move up the ladder of abstraction, make sure you don't abstract away control you might need.  If you do, you will only solve some problems to create new ones.

10 September 2007: Grammar and style edits.

Developing on Vista can be annoying.  Mostly because of the security enhancements and compatibility issues.  Well, only because of the security enhancements and compatibility issues.  I, personally, am used to running around on my development machine with full administrator privileges dropping database tables and debugging on IIS.  Sadly, in Vista, this isn't possible.  Even installing the standard development tools is annoying and requires special steps and patches.  A few months ago, I set up a development machine at my house.  It took about a day, plus more troubleshooting time.  I was about to uninstall Vista entirely, but that would have been the waste of a day.

I recently got a new laptop, a Dell D630, dedicated solely to code/other.  It came with a Vista license, and I stuck with it.  This is my experience.

The Timeline

• 2:19PM - Put in the install disks.  I'll skip the non-developer related steps.
• 2:38PM - Vista installed, started installing patches (23 updates) and missing device drivers.
• 3:18PM - Started installing helper programs, such as Switcher, WinRAR, and setting up WMP11.
• 3:29PM - Installed the core development utilities: TortoiseSVN, gVim, FireFox, FireBug, IE Developer Toolbar, changing folder options to show hidden files & extensions.
• 3:48PM - Received "A device attached to the system is not functioning." error.  Restarted.  Was pretty sure my install was already hosed.
• 3:58PM - Started installing Visual Studio.NET.
• 4:17PM - Started downloading Visual Studio 2005.NET Service Pack 1.  Averaged 320kbps.
• 4:43PM - Started installing VS.NET Service Pack 1.
• 4:57PM - Finished inspecting configuration, actually gave me the prompt to install Service Pack 1.
• 5:14PM - Received "Error: 1331.  Failed to correctly copy MFC80UD.dll file: CRC error."   Twice.  Doesn't seem to have caused a problem.  2nd error so far.
• 5:20PM - Downloaded and installed the Visual Studio Service Pack 1 Update for Windows Vista.
• 5:29PM - Started SQL Server Management Studio Express install.
• 5:36PM - Realized I didn't have my Office and Visio CDs readily available.  Started tearing apart my room.
• 5:40PM - Started installing Office 2007.
• 5:49PM - Setup error, had to roll back the office 2007 install.  3rd error.  A cryptic one at that.
• 5:54PM - Started Visio Install.
• 6:19PM - Initial checkout of the current code-base.  (Delayed, I got distracted by Internet :( )
• 6:23PM - Started Visual Studio.NET
• 6:26PM - Realized I needed the ASP.NET AJAX extensions installed.  Made it happen.
• 6:32PM - DEVELOP ON!

4 hours 13 minutes.  Half a day and a smoke break.

Tips and Common Problems

1. Run the Visual Studio.NET installer as Administrator.
2. Run the Service Pack 1 installer as Administrator.
3. Run the Service Pack 1 Update for Vista as Administrator.
4. Run the SQL Server Management Studio Express installer as Administrator.
5. Whenever you run Visual Studio.NET, run it as administrator.  If not, things fail in odd ways.  Mainly related to IIS debugging.
6. Whenever you run SSMSE, run it as administrator.  If not, you won't have god rights to the database.  (This might be desirable, you can just set up mixed-mode authentication and connect with that.  I'm lazy.)
7. If you're having trouble with Internet Information Services 7, read this post.
8. Yeah, pretty much run anything that deals with memory as Administrator.  It gets annoying, but necessary.  It's better then having applications silently fail.

Overall Experience

Once you know the exact steps you need to do for Vista development, it's not all that bad.  Yes, you have to install a lot of applications, but it's pretty quick.  I think a much faster machine helped.  (I was using a 5 year old HP ZE5300.)  The most annoying thing, by far, is UAC.   It pops up constantly.  It blacks out my screen whenever I need to start Visual Studio.  And whenever I start SSMSE.  And I can't directly open .sln or .proj files anymore.  But damnit, I'm running this OS as Microsoft intended, though I think it's going to end up pissing me off.  UAC problems aside, I've done 16 hours of development on Vista with no other major setbacks.  Just don't mess with the Program Files folder with your app or through explorer.

But wait, you're only doing Windows Development!

This is very true.  If I used Eclipse, or Java, or Ruby, or Python, or some god-awful Lisp descendent, I wouldn't do it.  There are too many potential problems.  Vista ain't `zactly shiny.  If you're using a desktop, don't bother.  Most of the benefits of Vista (that I appreciate) are based on notebooks, tablets, and networking.  Otherwise, stick with XP (or OSX or whatever the hell Linux Distro is hot.)  If it comes prepacked with a new PC, I wouldn't recommend reverting.  You're gonna hafta get with with the future at some point.  Or you could just run Windows 2000 for two years after XP's release, like I did.

When you're taking a class in computer science, the schedule is fixed.  The semester will be over on this date, end of story.  Your project will be due before the end of the semester.  Individual projects may be pushed back, but that's a rare case.  This is somewhat similar to what I'm seeing in professional programming.  Your project will be done by this date.  The difference is how the dates get set.

In class, professors set due dates for assignments.  Of all my courses, not a single professor has come in and said "Okay, you need to program a R/B tree.  When do you think you'll have it done?"  I guess I always thought that I'd be given target dates to work towards.  Until I moved into management, anyway.  Actual programming in the real world has taught me differently.  My boss is constantly asking me for schedule updates.  "When do you think you'll have component x done?  What about component y?  Can you ditch feature j and finish feature i for the demo next Tuesday?"  I've never estimated my own dates, ever.  And I must say, I'm pretty horrible at it.

I've missed every single estimate so far.  At minimum by three days.  And I'm not even working in an extended timeframe, I'm doing three week estimates max.  Thankfully, the books I've been reading (mostly McConnell and general-development MS Press books) have all stated the same thing:  software estimation ability gets better with practice.  So I don't feel too bad about it.  I've been making a bunch of neophyte mistakes.  I'm still excited about the project, and I haven't been tripling my estimates.  Learning through practice, and all that jazz.

But experience alone isn't fast enough.  I needed to take action!  What I have done is to make a table of whenever create/commit to an estimate.  If I say I'm going to have component y by day 15, I write that down.  Then I record how long it took me to finish component y.  Sadly, only one of my components is actually complete; I need to start estimating in less broad terms.  Here's a look:

The smiley faces are optional.  I find them cute and humanizing. 

Keeping track of your estimates gives you data to look back on, to make your future estimates better.  My scheme fits nicely into an excel or *erk* Google Spreadsheet.  Whenever my boss comes into my office and asks me when a component will be done, I just fire up excel and add a row.  A quick easy way to record your estimate history.  Since I'm doing it using a simple spreadsheet without using a super-complicated CASE tools, it might even be considered Agile.  I'll see how it works out.  I think by the end I'll end up being off by a factor of two in most components.  Especially considering my soft (self set) deadline for project feature-completion was last Friday.  Here's to hoping to more accuracy in the future.

I switched weblog providers tonight.  I had been using Community Server 2.1, but now I'm using Subtext.  I much prefer Subtext.  When I first began my hunt for ASP.NET powered weblog software a few months ago, I started with .Text.  Well, I tried to start with .Text.  I remember reading a few blogs that were powered by .Text in my early ASP.NET developer days.  I figured that if it was good enough for ASP.NET developers, it'll be good enough to me.  Sadly, I couldn't easily find a link to a .Text download/installer.  I found the now-defunct godotnet.com workspace, but that didn't offer a download.  It also appeared that sadly, .Text development stopped before I touched Visual Studio.  Scratch that idea.  I poked around the web a bit (even tried WeblogMatrix, sister to WikiMatrix which ignited my love affair with DokuWiki) and couldn't find anything.  Then I remembered that worsethanfailure switched over to Community Server a while back, and checked the site.  Seemed pretty good.  A download and somewhat troubled install later (mostly due to DNS issues, and my desire to host a blog directly on the homepage) I was up and going.  It was pretty cool, albeit slow.  Granted, the server it was running on was fairly weak and carrying Exchange 2007.

Once I installed Community Server, the CommunityServerApp app pool kept crashing unexpectedly.  It appears that whenever the application was recycled, it'd terminate.  Since my site is fairly low-load (one or two hits a day), I'd imagine that the application pool would load itself, serve one or two pages, then crash.  Whenever I logged into the server over rdesktop, there'd be fifteen+ error messages awaiting.  Most annoying, even for a dev server.  I tried upgrading to the recent release of Community Server 2007, but that required me to download the web install (documentation well hidden) and run a SQL Script manually (poor form).  Not to mention the fact that the Community Server license agreement changed and it was super-overpowered.  Seems like solid software, and it works for a lot of people, it's just not what I needed.

I was reading Reddit one day when I came across a link about the Dvorak layout.  Now, whenever I go to a new blog I always read the About page before the post, just to see where the user is coming from.  Well, apparently, this guy ran a successor to my original choice of .Text.  And he knew Jeff Atwood.  And he was one of the people who posted in the thread on CodingHorror where I finally got over my fear-of-the-professional-internet and posted a comment.  And, on top of that, he uses the Dvorak keyboard layout.  All that coolness made me realize that it was time to switch.  The Subtext was install was clean and running within fifteen minutes.  Porting my old posts (all eleven of them) was done by hand.

Subtext is FAST.  Much faster then Community Server.  Though I will point out, it has about 1/8th the functionality.  Again, just want a ASP.NET/SQL Server based weblog.  So Subtext wins.  It is now my weblog software of choice.  I'll probably have more to say on it after a few more days use.  It also supports Windows Live Writer/MetaBlogAPI.  Windows Live Writer is pimp.  I wholeheartedly recommend it. 

Note:  Windows Live Writer also works for Community Server.  The coolness of Subtext is also independent from that of Windows Live Writer.

I'm going to take a stab at writing on something cool, hip, and current.  Microsoft Surface was announced today.  Before reading further, I urge you to visit the site and watch the videos.  Was the site down?  Have you watched them?  Good.

My first reaction to the whole product pure unadulterated want.  It's not up to need yet, but it's close.  I saw the technology about a year ago on Channel 9, back when it was called "touch light".  Minority Report come to life, yeah, cool.  I won't be around to see it.  Then today's announcement came.  End of 2007!  Crap!  I might even see this in my house before I hit 25!  Clearly this is something to get excited about.

The different types of software that could be developed for this technology is phenomenal.  Entertainment, enterprise, other areas listed in the numerous news articles: they could all benefit from this kind of cool.  I want an SDK, I want this hardware, and I want to on the cutting edge writing the cool stuff.  My friends have said the same, quote [capitalization improved]: Man, I would kill to be able to work on something like that.  As this Forbes article states, this is Microsoft's Mac.  A direct successor to their successful console line.

Which means I won't be developing software for it anytime soon.

Microsoft's best SDK strategy for this device, in my humble, un-educated opinion, is to keep development expensive and closed.  Same thing Apple is rumored [Still rumored?  I'm not sure.] to be doing with the iPhone.  Technology built for user interaction, needs to be 100% reliable, usable, and stable.  Windows has thrived due to easy access to development tools.  Anyone can develop any type of Windows application cheaply.  'Anyone', sadly, isn't a developer.  Most Windows applications are shoddy and bug-ridden.  They're hard to use.  Ugly icons abound.  Microsoft can't let junk applications like this touch [ah! ah?] Surface.

Google for screensavers.  Screensavers are graphical programs that all provide the exact same functionality: preventing monitor burn in.  Yet dozens of different companies have developed competing versions, all being differentiated simply by bling.  Looking at this evidence, the market for screensavers or animated dancing girls on a consumer Surface device would be huge.  Development companies would be crazy-stupid to miss out on the opportunity; they'd all rush software to market, full of the WPF equivelent of animated GIFs.

And that would blow.  My coffee table has big enough problems dealing with beer-can rings.  It certainly doesn't need crap software infiltrating it's OS.  Microsoft is sticking with corporate customers to start off.  Good call.  A consumer grade device would either need to have incredible software restrictions or be closed entirely.  I'd wager that all software placed on such a device would have to go through the equivalent of the hardware WHQL process.  It'll be out of the range of the average independent software developer.  The thought really saddens me; I don't care to wait for other certified developers to write cool applications for Surface.  I want to do it myself.  The best software strategy for Surface just happens to disagree.

My programming is in full getting it done swing.  Comments are being neglected, horrible things are being done with try {} catch {} blocks, and variable names are becoming less useful.  Writing high quality code on a schedule is harder then I originally estimated.  A lot of my scheduling problems are tied to my work environment.  Well, the part of my work environment: my paycheck.  Essentially, I don't get paid until I finish the application.  And my paycheck is dependent on delivering a working program; not a maintainable one.

I guess it's the plight of most software developers.  Debates about languages and closures and whatever the hell else is good for academia, but it really gets in the way of getting things done.  I'm not an academic, but I believe in good code.  It's a tradeoff.  Do I spend a few extra minutes here commenting code?  Do I write down my thought process and reasoning for a tricky bit of functionality when my power bill is going unpaid?  What exactly is my motivation to write good code when my paycheck is the same?  I certainly won't be maintaining this code; I'm out as of August 2007.  It'll be a guaranteed revenue stream (to the tune of $3k/month) for my employer, not me.

Professional dedication can only go so far.  As much as I hate it, I go to work developing enterprise applications and come home and dream about developing other applications.  Not shrink wrap or games or anything, but just doing development work that's not my job.  Yeh, I'm that much of a geek.  Point is, I'm supposed to be living the life!  I'm a professional developer now!  My systems are going to be making an impact on the people who use them; I'm drawing a paycheck for making them awesome!  External deadlines and milestone markers really dampen the whole programming experience.  As does reality, but that's more philosophical then I'd like at 4:49AM.

Bottom line:  my code quality is suffering.  I've been developing for this company since March, but I've seen one (yes one) paycheck.  There is a large amount of money outstanding.  It feels like I'm working for a bootstrapped startup (something I swore I would never do) except I'm not doing anything new and exciting.  I'm banging out data access objects and business rules for an insurance underwriter.  Dreams of my enterprise career definitely included a steady paycheck, and this just isn't cutting it.

On the plus side, Gin and Tonic is still as tasty as ever.