The last 2 days I had a lovely time upgrading a major project we work on at BrightMix over to Visual Studio 2008. Actually, the code upgrade was totally automated by VS2008 so that was easy. The hard part was getting VS2008 Team Foundation Build Client to play nice with our Team Foundation 2005 Build Server (abbreviated as TFBS from now on).

Oh, the Trials And Tribulations...

The first thing you find out is TFBS can't figure out how to build 2008 solutions. You'll see something like this in your build log file:

Build FAILED.
C:\Builds\TFSNow\TfsNow-PublicWebsite-Continuous\Sources\PublicWebsite.sln(2): Solution file error MSB5014: File format version is not recognized.  MSBuild can only read solution files between versions 7.0 and 9.0, inclusive.

Fortunately, Mitch Denny has a great post detailing out how to fix this issue. Following Mitch's post, I upgraded the build server from .NET 2.0 to 3.5 and replaced the .NET 2.0's MSBuild.exe with a dumby MSBuild.exe that redirects to .NET 3.5's MSbuild.exe. Fun times. For your convience, here's the dumby .NET 3.5 MSBuild executable that I used (note: mine is hardcoded to redirect to C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe - you'll have to compile your own if you need it to go someplace else).

Next Problem: Deploying Web Applications

After I got the dumby MSBuild.exe in place, I fired off a test build and another error showed up in the log:

error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0 \WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

The problem is with an <import> declaration in the Web Application Project's .csproj file. Basically, the "Microsoft.WebApplication.targets" file doesn't exist on the build server because it only has TFS 2005 installed.

I ran across a couple of helpful blog posts for this problem: Steve Harmen demonstrates a fix to the Web Application Project's .csproj file that involves adding another <import> declaration and some conditional logic. So, I added that in and, sure enough, the test build was now successful.

Surprise! Another Problem!

However, I quickly discovered that the Web Application Project's files (.aspx, .html, binaries, etc.) were not getting deployed to the test server's drop location. Some further digging revealed that some other people have had this problem, but no one had come up with a solution.

My Final Solution

What I ended up doing to get this working was leaving the <import> declaration in my Web Application Project's .csproj to point at the VS2008 directory (the one with "v9.0" in it). Then, I simply created that directory on the build server, since it didn't exist, and I copied the v8.0 "Microsoft.WebApplication.targets" file into the newly created "v9.0" directory. This probably isn't the best solution for this problem, but it seems to work.

If anyone has feedback on this, please leave a comment!

This is part 3, the last post in my Rails VS ASP.NET series. Please see Post #1 and Post #2 if you missed them.

In my previous post, I mentioned that I have a glimmer of hope for ASP.NET. This post is about the current state of ASP.NET, what it's doing right and, moreover, what direction I want to see it go.

The Alt.Net Movement

A community, dubbed Alt.Net, formed around providing solutions to a number of programming concepts that the .NET framework lacks. Particularly pressing is the lack of an MVC framework for ASP.NET. Fortunately, some smart developers out there cranked out a solution to the MVC problem: Monorail, a replacement for ASP.NET's out-of-the-box Webform architecture. Monorails gained a lot of popularity, but , as a 3rd party product, its adoption has been limited. I mean, most ASP.NET devs out there that I've talked to have never heard of it.

As a side note, I think it's worth pointing out here that if a ASP.NET has disgruntled enough programmers out there to the point where they've band together and created their own framework to fix/extend the current architecture, it seems like a good indicator that something is horribly, terribly wrong.

Most recently, Scott Gu announced Microsoft's solution to ASP.NET's MVC conundrum: the aptly named ASP.NET MVC, which is being bundled into the ASP.NET 3.5 Extensions library.

Yoink! We got MVC Now!

How does this play into Rails? Well, one could claim that Microsoft's implementation of the MVC pattern and associated URL routing structures are freakishly similar to that of Rails. Like really, really similar. It doesn't really bother me that Microsoft is making ASP.NET MVC mimic Rails. In fact, it's a great indicator that Rails is on the right track (pardon the pun). I just wish they'd go a bit further and implement the concept of Rails Partials and also extend the Microsoft Ajax Javascript Extension library to be more like Prototype.

Hmmm... Why Use ASP.NET?

If you've done much Rails development, you'll quickly discover that the majority of Rails developers out there use a Mac as their development platform and TextMate as their preferred IDE. I recently joined this bandwagon, and I will admit that it's a pretty sweet set up. Damn you, Apple, for making your MacBook Pro's so attractive!

Anyway, so one thing that sucks about Rails development, especially if you're just learning, is you don't have access to the all-knowing Intellisense to help you along. The latest versions of Visual Studio, and by that I mean 2005 and up, have some very kick ass, easy-to-use Intellisense that helps out not only with .NET code but with CSS and Javascript. Of course, TextMate has the concept of Bundles, which are very powerful, but basically require memorization of Hotkeys to be useful. There's also the NetBeans IDE for Rails, which has some decent Intellisense, but nothing on par with Visual Studio's.

Another thing .NET has going for it is its immediate availability of "Enterprisey" level things, such as message queuing and transaction scopes. It's also great for working with old Com Objects and the like (*shudder*) This comparison post has more details on the subject.

Another situation in which Rails would be a weak choice: say you need to create a new web app that talks to an old legacy database. The Rails ORM, ActiveRecord, is built around the assumption that your database will be created in parallel with the Rails application and follow a strict set of naming conventions. You're going to run into some major setbacks if you try to use Rails for this scenario. However, with ASP.NET, you can easily use ADO.NET to handle this problem much more quickly and efficiently.

I certainly won't claim to know every situation in which one framework might is better suited than the other. Leave a comment if you can point one out!

Rails Vs. ASP.NET Wrap Up!

I could keep going on this subject, but I'm going to stop myself here. I've talked a lot about the problems I've experienced with ASP.NET and a number of the reasons why I believe Rails is currently a far superior web framework. If I had to slim it down to 3 reasons why Rails is better, they would be:

• Integrated ORM
• Convention over Configuration
• Integrated Javascript Library

If you're currently a hardcore ASP.NET dev, like I used to be, I greatly encourage you to take a look at Rails and play around with it a bit - I guarantee it will be an eye-opening experience. Actually, you might not want to; once you get a taste of Rails, you'll likely not want to go back!

In a day of hardcore deliberating and conjugating, we at BrightMix decided to lease a very cool, very sweet, very retro-awesome office space! You can read more about it on the here.

Interestingly, we originally saw this office space by stumbling across this site, which showcases renovations done by the dudes of the DivvyCollective. These guys put in some serious blood, sweat, and tears to tear up this building's old asbestos-laden tile floor, tear down its crappy drop ceiling, cover up some gross 1970's-doctor's-office paint job, and a bunch of other improvements.

It turns out, despite all that work, that they've decided to split up and go their separate ways. Fortunately for us, we've been in business just long enough to be able to afford to start leasing a space.

Stay tuned to this blog (or the BrightMix blog) for pictures of our move-in and an online tour, of sorts.

If you missed it, check out Part 1 of my Rails VS ASP.NET series.

At first, I didn't understand what that phrase meant. Convention over Configuration? I guess I'm a little dense sometimes. At some point, it finally clicked. Suffice to say, ASP.NET has a whole lot of configuration, but not a lot of convention.

Before I go any further, here are the components I see as being integral to Web 2.0 development.

• An ORM tool
• Unit testing framework
• Ajax library/Interface
• Javascript Extension Framework

Rails has all of the above components integrated into its framework. Each component is very well constructed and integrate seamlessly with each other, making for a very slick, easy, and, most importantly, productive developer experience.

ASP.NET, on the other hand, currently only bolsters the ajax and javascript components. which I have issue with. It's not bundled with an ORM or unit testing framework.

Side Note:
Far too many of the ASP.NET developers I've run into don't know what an ORM tool is or what a unit testing framework does. If you're one of these developers, please, please, please!, For the good of your fellow programmers and your profession, educate yourself on ORM's and Unit Testing technologies, ASAP. No one will laugh at you, I promise. We all used to be "that guy."

Yo, What Does This Have to Do With Convention?

Patience, I'm getting there! So, there are plenty of 3rd party frameworks out there to overcome the ORM/Unit Testing deficits in ASP.NET. For unit testing, we have MBunit, NUnit/NUnitAsp, et al. and for ORM's we have LLBLGEN pro, Castle ActiveRecord, NHibernate, et al. The list goes on and on. The result of all this diversity is a very separated and divided developer community. Some developers like to use LLBLGEN, others prefer Nhibernate, and more often than not, the Nhibernate guys hate the LLBLGEN guys (I don't get it!). While all of this diversification is neat because it gives us developers a lot of options, it sucks bad because it introduces a huge amount of configuration complexities.

A Confession...

We're entirely guilty of this at BrightMix. Example: for our ASP.NET projects, we typically use LLBLGEN for our ORM, MBunit as our Unit testing framework, a mix of 3rd party controls (fckeditor, obout controls, nvelocity, et. al.), and an MVC-esque framework that we rolled ourselves.

This setup is cool because:

• it's highly configured for us
• we can crap out a new ASP.NET web application pretty damn quickly.

This set up is crappy because:

• 3rd party stuff usually costs money, at least most good 3rd party stuff
• configuration and integration of 3rd party stuff requires a lot of time and understanding
• pretty much no convention

I wonder... of all the ASP.NET developers out there, what percent of them are using a configured set up similar to ours? My guess is probably not very many.

So, Why is Convention Good?

Imagine you're in charge of hiring some ASP.NET developers. Your team uses one of the many ORM and unit testing frameworks out there, a custom MVC framework, and some other miscellaneous add-ons. What you'll find is that most ASP.NET developers have never even heard of your 3rd party stuff, let alone used it. No, the reality is you will have to teach a newly hired ASP.NET developer the in's and out's of your configuration, which is probably going to take a long, long time. The more configuration, the longer it will take.

With RoR, this conundrum is practically eliminated. 99% of Rails developers will know how to use the standard issue ORM, unit testing, and javascript / ajax libraries with which rails is bundled. Talk about a time saver.

I just read through this post after writing it, and it appears as though I have a lot of bad things to say about ASP.NET, and I, inadvertently, have a lot of good things to say about Rails. Blarg! Maybe I'm just bitter after working with ASP.NET for so long and seeing (and writing) so much terrible, crappy code.

Well, my next post in this series will talk about the future of ASP.NET, which gives me a glimmer of hope for ol' Microsoft.

Microsoft Ajax is Microsoft's free ASP.NET ajax/javascript extension library which is composed of Microsoft Ajax and the extension library, Ajax Control Toolkit. It came out sometime in 2005 - I don't remember exactly when, but it's not until recently that I actually used it extensively.

At first, I was excited about Microsoft Ajax's release; my once bland ASP.NET apps were going to become alive with ajax and javascript! However, after working with Microsoft Ajax for a while now, I'm mostly just frustrated and disappointed. It's dumbed down too much... to the point where a savvy developer will limited and restricted. Sorry Microsoft, wrapping my entire page in an <UpdatePanel> is far from efficient and Ajaxy, even if it does eliminate the "postback flicker."

Also irritating is the name of the Ajax Control Toolkit, which is about the biggest misnomer ever. Most of the controls in this library, albeit useful, have absolutely no Ajax functionality whatsoever. I'm going to make a stab in the dark here and guess that Microsoft's marketing department decided that this title would catch the attention of non-developer people who don't know anything about Ajax... other than that they want it in their application. Boo!

The Sadly Drag and Drop Mentality Re-visted

A while ago, I wrote an article in which I bag on Microsoft for making it possible for developers to drag-and-drop together a web app using ASP.NET and Visual Studio. Well, they tailored towards this style of development with the Microsoft Ajax library, too, and what they ended up creating is a framework that's really only fit for usage in very basic web apps or web apps in which flexibility and performance are entirely unimportant. Unfortunately for us, these are exactly the types of web apps that Average Joe ASP.NET developer seems to create. *Sigh*

Not enough Documentation!

My final grievance is with the documentation for Microsoft Ajax. There's no meaty API that details out all of the javascript behind the Ajax and Ajax Toolkit controls, and this is what I need to know 99% of the time. What I end up doing is painstakingly digging through Microsoft Ajax's complex javascript libraries by hand in firebug... or googling for a solution, hoping that someone else who speaks English has figured it out. Both, obviously, are less than optimal solutions.

Example: I've wanted to trigger the refresh of an <UpdatePanel> control from javascript. This seems like a fairly easy but important feature. You won't find any official documentation on how to do this. If you google for it, you'll find that it can be done using a few methods, all of which are basically hacks that circumvent/trick the normal Ajax framework's behavior. Fantastically not awesome!

I recently started using Ruby on Rails and the Prototype javascript library. The two frameworks are built closely together, similarly to ASP.NET and Microsoft Ajax. However, the documentation for Rails and Prototype is nothing short of awesome.

I'm hopeful that future releases of Microsoft Ajax, if there are any, will address some of these shortcomings that I've repeatedly run into. We shall see, I suppose.

My Roots

My initial plunge into the world of web development started with classic ASP about 3 years ago. I'm sure most developers out there would agree that Classic ASP is not so awesome anymore. Imagine putting VBScript, HTML, and SQL code in a blender, hitting liquefy, and pouring the contents into a ".asp" file. That's, in a nutshell, how most of the classic ASP that I worked with looked. (Obviously, not all classic ASP is this terrible.)

Shortly after doing ASP work for a few months, I was introduced to ASP.NET. I quickly discovered that ASP.NET totally kicked classic ASP's ass; it provided all sorts of cool server-side controls and the power of the .NET framework. Couple that with some tight integration into Visual Studio, and here's what you have:

	AND
ASP.NET (BMW Z4)		Classic ASP (Rusted Junk Box)

A year later, Visual Studio 2005 and ASP.NET 2.0 came out and made things even sweeter. A number of outstanding issues in Visual Studio 2003 and ASP.NET 1.1 were addresses and plenty of cool new enhancements were added. How could things get any better? I had become a stanch ASP.NET supporter.

Along comes Rails

Chad Fowler suggests that we developers should try to learn at least one new programming language per year. Not because we may be using a new programming language at your day job, but because it will broaden our minds and give us new perspective and insight into solving problems.

This is exactly what happened to me. I used Ruby on Rails (RoR) to create a web-based IRC-like chatting app. After learning the in's and out's of RoR, I've since returned to writing ASP.NET, frequently finding myself working on a piece of code and thinking, "how would I do this in rails?" More often than not, I end up perturbed and unsatisfied, knowing that rails would allow for a simpler and cleaner solution. Blarg!

Without going into all of the technical details, I've concluded that RoR's is superior to ASP.NET in that it:

• has a true model/view/controller (MVC) implementation
• is way better at handling Ajax requests
• can cleanly handle URL rewriting
• has as a sweet ORM tool, ActiveRecord, baked right into the framework
• requires little-to-no initial configuration
• built-in testability
• makes it more difficult for the developer to write crappy, inelegant code (note: it does not eliminate the possibility.)

I'll talk be talking about the Convention over Configuration in my next post in this series

Standing in "the office"

Monday was my first day of self-employment for my business, BrightMix.

What can I say? It was pretty rad. I got up at around 10, showered, and put on some comfortable clothes. As you can see, this is the living room in my house, which is decked out in a sweet, new laminate floor not too long ago. The way the desks are setup, it looks kind of like the bridge of a ship in Star Trek. 

We left to go purchasing office-type supplies, but realized, after getting to Sam's Club, that we didn't really need anything other than a white board. Speaking of whiteboards, we decided to make our own, rather than spending $50 on a tiny, crappy white board from Office Max. As this guide indicates, Making your own isn't hard, plus it's considerably cheaper! I'll be posting pictures of the final product soon.

 
The BrightMix Lounge

Will my Lifestyle change considerably?

I'm curious to see how some of my day to day habits conform to this new style of work. Things like:

• sleeping
• eating
• napping
• working
• entertainment

Thus far, I've been sleeping longer, but also working more... I'll note any more observations as they appear.

I've been meaning to make some alterations to Zinknation's layout and I've finally gotten around to it.

The change list:

• New logo (I hacked it together myself!)
• Fancy Zigzag background
• Center/fixed-width layout

Liquid layouts + blogs = boo!

The biggest change was moving the site from a liquid/elastic width layout to a more simplified fixed-width site that is centered on the page. Deep down inside, I like to use liquid layouts because they're a bit more difficult to create and, generally, much cooler. However, I've come to the conclusion that liquid layouts are pretty lame for article-based sites, like blogs. If you have a really big monitor and you maximize the browser, you can end up having an entire paragraph spanned across one really long line. To me, it's just hard to read and looks bad.

Of course, the debate between fixed/liquid layouts has raged on amongst the web design community for a number of years.

In the business world, my experience has taught me that clients generally do not care that a web site has a liquid layout, they just care that it looks good and doesn't take forever to design. So, for general purpose web sites, I recommend a simple fixed-width layout. However...

When liquid layouts rock...

For the most part, any sort of web-based application will probably look and function better with a liquid layout. Google maps, Google Docs,  and Campfire are all prime examples. They actually increase the amount of content that can be display in the browser--they don't just make the existing content s-t-r-e-t-c-h across the screen.

            
Google Maps: 1024 x 768 versus 1650 x 1050

 

But, I digress, let me know what you think about the new layout!

Alright, this is just a little strange to me... nearly everyone I've talked to about my quitting my job has congratulated me. Ironically, the same people congratulated for accepting the job I'm about to quit.

But anyway, so what's the deal? Am I being congratulated for politeness' sake? For creating a company? For having the cajones to up and quit my cushy corporate job?

Some Intestinal Fortitude is Required

About six months ago, Dusty and I started throwing around the idea of quitting our jobs and making a go of it. It was a scary thought for me back then. But, as time progressed, I became less and less frightful. In fact, it started to make more and more sense.

Some Preparations that Reduced Fear and Risk...

• I started saving money 6 months ago in preparation. I have enough saved that I could rough it for around 6 months without making a dime; it's a nice "oh shit" buffer.
• We formulated a few solid software "product" ideas. No formal documentation or anything, but they're ventures that we'd be able to immediately begin work on and probably see quick results.
• Running some actual numbers to determine how much cash flow we would need to maintain our current lifestyles.
• Finding clients, contacts, and even lining up some contract work prior to quitting.
• Last but not least, knowing that starting our own business would be exciting, adventurous, and (hopefully, at some point) lucrative!

What's your story?

As I talk to people who are clearly unhappy employees, I can't help but wonder how many of you are unhatched entrepreneurs. Granted, it's clearly not a profession for everyone. If you're on the fence, or even considering it, I ask you: do you really want to go through life without ever trying the entrepreneurial lifestyle? Worst case scenario, you fail and have to go back to being an employee - whoopty doo.

I just finished up reading The Psychology of Influence. I found it to be a pretty interesting read. The author lists out the biggest influential acts that he (and other researchers) have found. Here's the cliff's notes version of the identified influential behaviors and an example of each.

Reciprocation

Give a little something, and we will be inclined to give back. Simple enough, no? Our BrightMix accountant gave a perfect example of this the other day. He said he gets his best clients from going to social events and giving out free accounting advice. When his audience realizes he knows his proverbial shiznit, they end up hiring him to do their finance work. On the other hand, what if he refused to give out any advise without charging money? I bet he wouldn't be doing so well.

Commitment and Consistency

This idea plays on the fact that once we people set ours minds on something, we tend to stick to it.

Example: researchers went door-to-door in residential California and asks homeowners to display a small "Drive Safely" in a window on their house. Weeks later, another group of researchers went to the same houses and asked the homeowners to display a large, poorly designed billboard in their front lawn. A shocking 83% agreed to the installation of the sign.

Why? These homeowners had complied with the commitment of displaying the small sign, and, in doing so, had altered their own self-images, becoming public servants who promoted safe driving. Thus, it became natural for them to comply with the subsequent installation of the large billboard.

Try this out: write down a goal that you want to accomplish and post it publicly and/or show it to your closest friends, such as "I will become a non-smoker." You will more naturally become consistent with your newly stated self-image. If you smoke again, you're being inconsistent and risk being a big time loser.

Social Proofing

This is a big one. Social proofing relies on the concept that we humans tend to do what other humans are already doing. We perceive what everyone else is doing to be the norm.

The big example cited: the case of a murder in New York's Bronx wherein a young lady was brutally assaulted on three separate occasions over the course of an hour in the middle of a residential area. The assaults were highly audible and numerous residence actually witnessed the attacks as they occurred, but no one attempted to intervene or call for help. Eerie, indeed.

The reasoning is that the witnesses took cues from other witnesses who were watching idly. The effect was contagious, and it appeared as though inaction was "the thing to do" amongst spectators. In the end, the young lady ended up dying.

We definitely take behavior cues from those around us; it's a huge influence.

Likeability and Similarity

We tend to be influenced more easily by people we like and/or with whom we can identify. Example: a number of previously elected presidents were elected because of their charm and good looks--not on their political standpoints. If you've ever dealt with anyone who is good in business, you'll undoubtedly find that you probably perceive them to be similar to you in some or many ways.

Even more so, look at your closest friends and try to determine which have the most influence on you. You'll probably find that your most influential friends also happen to be the most similar to you in their beliefs, attitudes, and behaviors. My like-minded business partner Dusty has influenced me quite a bit (and I suspect the reverse is true)--we managed to convince each other to quit our high-paying jobs and form a company! Hah!

Authority

Nothing too notable here. Someone who is in charge (or at least appears to be in charge) will have a great deal of intrinsic authority. Your boss at work no doubt influences you. The police man waiting to catch you in a speed trap influences you. When "the experts" say you shouldn't eat red meat, and then you don't eat read meat, you just got influenced.

Scarcity

I thought this point was pretty cool. The whole supply/demand of economics proves this behavior quite readily. People want what is rare.

Remember this deal regarding a grilled cheese? 'Nuff said.

Dude, but it's so obvious!

We become extremely blind to acts of persuasion/influence because it's so embedded in our culture and day-to-day life.

Still, I can't help but think that there isn't a lot of profound knowledge coming out of this book. I mean, I could probably come up with a lot of examples persuasion,  but I surely wouldn't be able to categorize with this much granularity. If you hadn't read this article(or book) and were asked to list out all of the things that you felt influenced and/or persuaded people, what do you think you'd come up with?

After a lot of deliberating, debating, planning, perusing, and pontificating, my buddy DustyD and I have decided to start software development company named BrightMix.

Dusty's last day working for Aureus will be this Friday, and I've informed my employer of my intent to sometime in the mid-August.

It's with a heavy heart that I plan to leave my friends and colleagues at Securities America. But, alas, my aching to get out on my own, plus a handful of hot, time-sensitive opportunities, has convinced me (and Dusty) to move forward. I'm making every effort I can to see that my departure from Securities America is as painless as possible--easier sad than done.

Words from the Wise

Pretty much everything I've read from the multitude of startup authors out there indicates that our venture will:

• Be more work than we are anticipating
• Provide us with a freakish amount of experience
• Make us feel alive!

Business Strategy

For our first 6-12 months, we will be primarily doing consulting/contract programming work. This will be an effort to stockpile cash. After that, we want to focus on developing a web-based product and/or service that will generate recurring income for us. Our plan here is to quickly implement a number of small projects, study how they do, and then focus on developing the projects that seem to have the best future.

We want to avoid the lure of Consulting

Contract/Consulting work can be highly lucrative with high dollar-per-hour rates, but we do not want to focus on this type of work; it just doesn't scale well. Plus, if the work dries up, you got no monies--Boo that! I think it's really easy to get sucked into the contract/consulting game because it really is easy money. However, will only go so far.

On the To-Do List:

• Talk with an accountant and/or lawyer to determine some of the inner financial workings and get the company officially declared.
• Update the company Web site and blog to actually contain some relevant stuff.
• Get a stellar logo.
• Set up an "office" (most likely candidate --> my sweet living room).
• Get some initial work contracts hammered out so we can begin working.
• Have a BrightMix Begins party.
• Give everyone at party high fives!

Exciting times, indeed!

Friday my friends and I all gathered at my parents' house outside of Lincoln for some good ol' fireworks-related fun. As they say, there's no better way to celebrate your country's independence than by blowing up a piece of it. I had drove to Missouri a few weeks prior and picked up a healthy amount of high quality, illegal (at least in Nebraska) fireworks to affirm that the show would be as spectacular as ever.

Among the arsenal: roughly 125 Artillery Shells, a roll of 16,000 firecrackers, a bunch of rockets, some other miscellaneous items, and a couple of these bad boys:

After hours and hours of play, my Guitar Hero controller crapped out. The internal components of the flipper switch broke and it was stuck in the "down" position. So much for durability...

What Did I Do?

I shed a few tears, said good bye to the ol' girl, packaged her back up, and headed off to Wal-Mart for an exchange. I love Wal-Mart.

At Wal-Mart...

I'm waiting in the check-out line, watching the clerk ring up the people in front of me. From a distance, she seemed a little odd. The usual cashier-to-patron interaction was not occurring.

Oh My God!

Sure enough, I was right--she was odd. This lovely cashier would be best compared to the crazy cat lady from the Simpsons.

I walk up to the designated checking-out area and was not greeted with the usual "Hello, did you find everything you need?" Instead it was more like, "Bwaaahahhaha how did they know??? BWahaa!"

I was scared and I was frightened. But I stayed the course; I needed a replacement guitar.

The gibberish continued throughout the whole transaction. I wasn't told how much my purchase was, but I was told "BWHWhah! Man o' man maybe they'll GET IT RIGHT THIS TIME."

Touché, crazy cat lady.

I paid my unspoken total ($103.31 - Guitar + 2 boxes of candy). She held out the receipt and I took it hesitantly, expecting to get a cat thrown in my face. Whew, no cat--just some more gibberish followed by a redneck cackle. How damn bizarre.

Back in the Real World.

I tried out my newly exchanged guitar and it works like a champ! I was able to bump myself into the top #1000 Guitar Hero 2 players! Lifelong goal achieved! High-five!

I just finished one of the Pragmatic Programmer's endorsed books: My JOB Went To India (and all I got was this lousy book). My good friend Andrew recommended it to me. I'm going to give you, my loving audience, a quick book review.

Some Background Info

The author, Chad Fowler, is a veteran software engineer and manager who was sent to Bangalore, India to help build the foundation of an offshore development center for his company. I won't go into all of the details, but he interviews a whole bunch of Indian programmers and makes a lot of interesting observations about the software development industry in India. Then, based on those observations (among other insights), he provides 52 ways us dudes/dudettes here in the U.S. can attain leverage over our offshore competitors.

My Overall Opinion

You can pretty much flip to any page in this book, start reading, and get sucked right in. The focus of the book strays away from the whole overseas competition thing at about halfway and Fowler just details out a bunch of really insightful tips that any software developer can utilize. Although, if you want to learn some ways to keep your current job (especially if you work at a larger company), make it more satisfying, and perhaps move up in the ranks, then his advice will apply directly to you.

Favored Chapter: On Maintenance Programming!

The chapter I enjoyed most was about learning to love maintenance programming. Fowler claims that maintenance work is a blessing in disguise because, often times, maintenance programmers have the ability to show off their talents in a variety of ways. For instance, you can: slip in cool UI enhancements, clean up/remove old code, upgrade the project's code platform to the latest ver