Speak, Code

Cloud Computing Chronicles: Stirring to Life

2008-11-30T14:51:00.001-07:00

So I've been working on a software development project for a couple months now. Sporadically, but working on it nonetheless. I look at the changesets in my source control system (Subversion), and the dates go back to 9/4/2008.

The idea for the project started germinating with Google. I have been developing software for more than a few years now, but the technologies I'm into these days aren't necessarily aligned with what Google is doing. I use Google's products as part of my everyday life, of course. I started using its search engine early in its lifecycle, and I couldn't help but notice the clever software that Google continually pumps out (I'm writing this post with Google Docs). But software development is a mammoth, fragmented industry. For the last several years, I've been working with Microsoft technologies. Google... hasn't.

My path intersected with Google's, though, when one of my (day job) projects needed some basic mapping functionality. At first we looked at some proprietary GIS (geographic information system) software, but decided to look at Google Maps as well. Google's price was more attractive (essentially zero vs. big bucks), the interface was easier, and the feature set did all we needed. The choice was not hard.

More intriguing was the level of community participation in Google Maps. People have created everything from maps of historical journeys to step-by-step maps of red light districts. I wondered if this was the way things were in the Google developer community. Legions of citizens across the world, leveraging Google to unleash their imaginations.

I took a superficial look into the other APIs that Google offers -- data, YouTube, docs, etc. -- and thought it would be cool to create an application that could lead me into this world. When I want to learn something in development, the only way to inject it into my bloodstream is to build an application with it. Reading about a technology or writing sample code can only take me so far. I was ready to go, so I put the idea on the pile of other projects I'd like to do. My ratio of projects I'd like to do and projects I have time for is somewhere around 100:1. So not much happened.

Engine roarin'

The concept gained some momentum with the release of Google App Engine. Here came a service where Google would host your application right in its data centers. What better place to work on Google's technologies? Sounded like fun. The drawbacks to GAE, of course, are well-documented by commentators of all stripe. Namely, you can only develop with the Python language, and there's a little matter of a non-relational database at the heart of the system.

But hey. I was up for a challenge. Development is both my vocation and my hobby. The projects I do for my work are mainly out of my control -- they're what clients are willing to pay for. But on my own time, the field is green. Building an application with GAE would put me in contact with all sorts of worlds I only knew superficially -- Python, Linux, Google APIs. So I started working on it, as I found stray hours here and there. I'll say more about my technical ~~struggles~~ learnings in other posts.

Wizard of Ozzie

Another piece fell into place when I attended Microsoft's Professional Developer Conference in late October, 2008. One of the big technologies Microsoft was pushing was Azure, the cloud computing platform. Ray Ozzie, Microsoft's Chief Software Architect, gave props to Amazon for blazing the trail of how cloud computing for the masses should work. I'm sure he's right. Amazon's EC2 (Elastic Cloud Computing) was the first behemoth out of the gate. From where I was sitting, though, the initiative looked a lot like Google App Engine.

So now there was another angle: Microsoft was coming into the cloud computing game full-bore. I could make my project into a narrative -- how the Microsoft and Google approaches stack up to each other, as I build an application. But I'm also interested in seeing what the developer experience is like for other comparable offerings between Microsoft and Google. For instance, Microsoft has Live Maps, which is remarkably similar to Google Maps. Microsoft answers YouTube with MSN Video. Microsoft is moving Office online, to compete in the space Google Docs occupies.

If you ask either company which has the better offering, you could probably predict the answer. And that's generally who you have to rely on for in-depth answers about the details of technology. I would contend that the main difficulty of modern software development is not technical. It is deciding from a seemingly infinite number of choices. There are a finite number of problems in computer science, but they are generally complex problems. And there are a lot of people/organizations who have thought up solutions. If you're a developer, the stakes are high when you sit down to create a project and you choose a technology. You can almost never predict where a project will take you. You may end up finding out that the technology you chose is a dead end -- that it will not solve the problem. By that time, you've probably lost a great deal of time and money. So. Doing this kind of exploratory development might help my technology bets be more accurate.

Underpromise and Overdeliver

Despite having made my living as a writer at various points in my life, and despite the fact I enjoy sharing experiences with other developers, I have yet to find the enthusiasm to write a technical blog. I've had some fits and starts, as you can see for yourself by reading previous posts on this blog. Maybe the material from this project will give me the "hook" to get into it. Or maybe this will be my last post. Guess we'll just have to see.

But thanks for reading.

Red - Unit Testing with Python

2008-10-13T14:24:00.001-06:00

So. Armed with my new favorite IDE -- PyDev, the first thing I'm starting to look for is a strategy for unit testing Python. Since I'm starting afresh, I'm planning to write tests to lay out my objectives, then learn how to create the functionality for the tests.

I'm not trying to be blinded too much by the way I usually work, but my expectation is that I will be able to find a unit testing framework that can be integrated into PyDev (or Eclipse, as the case may be). Then I can write tests that will live "alongside" my classes and I can run the tests programmatically.

We'll see.

Green - Developing in Python

2008-10-03T07:16:00.001-06:00

I selected PyDev (http://pydev.sourceforge.net/) as the tool to start out with. There seems to be huge enthusiasm for plain-text editors in the Python community. No doubt, it's fun to improvise on the command line. I liken the feeling to going back to nature -- grabbing hold of the rough edges and learning to love them. But I've grown too addicted to more full-featured editors.

PyDev is an open-source Eclipse (http://www.eclipse.org) plug-in with a pretty healthy feature set -- code completion, syntax highlighting, integrated debugging, refactoring, unit testing, third-party plug-ins, and on and on. The main criticisms I see about PyDev are about the complexity/overhead of Eclipse and the fact that you need to run it on a pretty beefy machine. After years of Visual Studio, I'm used to omnibus IDEs. And the machines I use have some horsepower.

I saw that PyDev was recently purchased by Aptana. I don't know enough about the Python ecosystem to know if I should be concerned that PyDev will go a commercial route. But I suppose on the scale of worries, that one is pretty small.

So off I go.

Red - Developing in Python

2008-09-28T14:37:00.001-06:00

For various reasons, I've decided to undertake a project using Python as the primary language. I'm going in fairly cold, with plenty of experience in other areas, but none in Python. My first thought was to develop with IronPython, since I'm steeped in Microsoft developer technologies. (IronPython is a Microsoft Common Language Runtime implementation of Python).

However, I found myself falling back too much on the things I know, and one of the goals of my project is to branch out into things I don't know. No use in doing it, if I'm using a new language to do the same things I'm doing now. So, I'm going whole hog. There are plenty of development tools for Python, so I looked at some overviews and comparisons:

http://spyced.blogspot.com/2008/05/ide-update.html
http://wiki.python.org/moin/IntegratedDevelopmentEnvironments

…etc.

My Own Personal Red, Green, Refactor

2008-09-26T15:05:00.001-06:00

So, if you peruse the sporadic entries up until this one, you might notice that they run long. That's my tendency -- to write long, with exhaustive research and explanations. It's also what keeps me from blogging very often. I'll have ideas, but the prospect of climbing Everest dissuades me from undertaking it. Before I commit the time to explaining the development travails I went thorugh, I'm working on the next idea, and I've left my previous troubles behind.

I thought of an idea that might work for this site. I dig the agile practice of test-driven development, where you start out with an idea of what to do -- write a test, knowing that it's going to fail (red), then work until that test passes (green). That first pass most likely will not be the best solution, so you refactor until you've hit the best solution (given your constraints).

I'm going to try to use a derivation of that method here. I will tee up whatever development issue I'm facing in an initial blog post (call it red). I will then talk about resources I tap into and experiments I attempt in trying to solve that issue. The first idea that works is the green post. And then onto the process of refactoring.

Most likely, the information will not be the definitive answer for the problems I run into. However, the content will be actual issues encountered during actual development. It will not be a contrived example to discuss a new feature. And I won't bother posting about the easy stuff, or the stuff that's a simple google search away.

I will try to keep a consistent set of headlines, so that if you find a topic that interests you, you can search the blog and get an idea of how the problem arose, and how I tackled it.

The Sublime Beauty of the Apple Aesthetic

2008-05-18T23:19:00.001-06:00

That title may sound like I'm writing another dewy-eyed tribute to the genius of Apple. I'm not. This is more a story of an old friend returning to help out in a pinch.

I bought my first Macintosh in 1990 -- a Macintosh Classic with a 9 inch monitor and 4MB of memory. Those were the days when the Mac OS had a clear advantage on anything Microsoft was producing. Even the biggest Microsoft fans would agree that Windows was an abomination before version 3.1, and that version didn't hit the market until a few years after I bought that Mac Classic.

Things change, of course. The story of what's happened in the industry since that time has been told in many different ways, by many different people. Personally, over the years, I've worked with Macintoshes some, but they've clearly faded in importance for me. Making my living as a consultant specializing in Microsoft technologies doesn't often push me in the direction of Apple technologies.

I've never lost a fondness for Apple's industrial design, though. Making things look as cool as they do must be harder than it seems. I always thought that some PC maker could have a viable business by simply copying Apple's designs, and manufacturing the machines for the PC market. But whenever anyone tries that, the result is egg-suckingly lame.

When Apple switched over the Intel chipset, and running Windows on Apple hardware became a viable option, I knew it was just a matter of time before I bought my next Macintosh. I bought a MacBook Pro and I used it almost exclusively for running Windows. I tried out some of the built-in Apple applications, and I played around with the new (for me) operating system. (The Macintosh OS is on version 10.5 now. The last version I used seriously was somewhere around 9.) The experience was fine, but I had a lot more use for my machine as a Windows box. In fact, I might be one of the few people on the planet who looked for a skin for my MacBook Pro that replaced the glowing Apple logo with a Windows logo. (Only because I tended to get a hard time from my Windows-loving cohorts).

Recently, though, something brought me back into the Mac OS, with force. I'm currently starting a personal project that involves delving into innumerable technologies that I have not used before. I'll be chronicling the details later, but let's just say that the leap is huge, and my plate is more than full. The amount of new information to process is astronomical. I decided to start podcasting, to go along with the project. Setting up a process to begin podcasting felt like a big hurdle I had to clear before I could even start.

My goals were fairly simple at the outset:

1. I didn't want my podcast to sound like I was recording in a bus terminal's bathroom stall (which many podcasts do)
2. I wasn't interested in building a home studio, or becoming an audio engineer. I wanted just enough to make it work.

I thought to accomplish those goals, I would have to buy a decent microphone, research the available software packages, weigh the advantages of each, go through intense machine configuration, learn the vagaries of the software package, and on and on. This wasn't just my imagination run wild. It's the normal course of events for addressing a technology-related problem.

I started off by taking a flyer on the microphone. I went onto Amazon and got a microphone that seemed at least suitable for the serious hobbyist. Maybe it was better, but I had no objective basis of comparison. I just bought it. http://www.amazon.com/gp/product/B000H4HS72

A little later, I started my exploration of the podcasting options the same I way I begin just about everything these days -- with a Google search. I noticed something interesting on my first page of results. The program "GarageBand" appeared in several places. I had heard some vague buzz about that program as a great way to record music. This was the first I heard that it had the ability to be used for podcasting. I was fairly certain that the program had been installed with my Macintosh, but I wasn't sure. There is a suite of programs that come with the operating system, but there are also some programs that you have to pay for.

My first pleasant surprise was that I had GarageBand, and I did not have to pay for it. Then I noticed that by simply launching the program, I was given a clear path to make a podcast. How much simpler could it be? There is a button that says "Create a New Podcast Episode" on the main screen. There is even a link for video tutorials right next to it. Watching the tutorial video had me productive about five minutes later.

I felt certain that there would be some work to configure the program to operate with the microphone. Other than plugging in the USB cable, there was not. The interface was clean. Having done some video editing in the past, the paradigm was utterly easy for me to pick up.

Now, there are a lot of issues I have with Apple. Their pricing for commodity components borders on predatory. Their smug superiority about operating system security is setting them up for a huge fall some day. Their cavalier attitude wholesale changes for each OS upgrade means that you have no choice to but keep buying software and hardware at each revision. But, damn. My experience with GarageBand was one of the best I've had with software. And I've had a lot of experience with software.

This is the kind of thing consumer software should aspire to. Someone has a problem, and they don't want to be burdened with a learning curve or massive upfront work, before they even start solving their problem. The program hides the complexity, and the user gets to work. I mean, look: I know there's a whole lot more to broadcasting than what I see in GarageBand. There's a whole scientific discipline to audio engineering that people have spent their lives working with and advancing. Who knows? Maybe there will come a day when my own needs or interests outstrip what I can accomplish with GarageBand, and I have to look for something more powerful. But I doubt it. As of now, GarageBand gives me a very simple solution to a complex problem and produces great results.

I think, in a larger context, that is why Apple is successful. Software designers tend to get hung up on feature wars. They think that if their software does not do everything (even if the use cases are obscure), they are at a competitive disadvantage. Apple seems to take the approach of asking how you can solve a problem without having to become a software expert. I mean, when the iPod came out, the market for MP3 players felt like it had peaked years before. And it had, for the tech savvy. Apple made it approachable for normal human beings.

So there you go. I'll keep this experience in mind. Software isn't finished when every feature is implemented. It's done when the benefit it provides is much greater than the effort it takes to learn how to use it.

Let it Bleed - On the Edge with Silverlight 1.1 Alpha - Part 1

2008-02-02T09:21:00.001-07:00

So I found an excuse to get my hands dirty with Silverlight 1.1. I'm involved in campus recruiting for my company, and each semester we give an employer presentation that involves a talk about the company, then a short demo of some current Microsoft technology. Generally, I give the spiel about the company, then organize some other folks to show off the technology. I decided to flip it this semester, so that I could devise some way to show off Silverlight.

Facebook felt like a good place to start. For the Fall semester, we had given a presentation about using the Facebook API, and it had resonated. As far as I can tell, Facebook adoption among college students runs about 100%. It permeates every aspect of their lives, so talking about how to work with the Facebook API has built-in relevance.

Then I wanted to think of something that exercised a broad range of the Silverlight feature set. Graphics, audio, video, animation, the works.

It was also a project that would give me a chance to learn in an enjoyable way. That is -- dive right in, try things, see if they work. If they don't work, dig into resources to find out why. That's one of the reasons you'll find that developers work on projects on their own time. When a client is footing the bill, you can't be quite so free.

However, there were a number of times during the project where "enjoyable" wasn't the adjective I would have selected. The fact that Silverlight is alpha software meant that there were hiccups, blind alleys and mysterious behavior. Even more brutally, the documentation and online resources are not terribly mature. It's funny -- in the space of seven years or so, the development process has changed completely. It used to be that you learned by instinct, brute force, or hazy documentation. Now, if you need to find out how to solve a particular problem, chances are, someone in the world has faced a similar problem and posted a solution. The answer is a Google search away. That's not necessarily the case with Silverlight at this point in its lifecycle.

But I appreciate the experience now. It was enjoyable It was like a throwback to the wilder days.

So. When I started, here was my initial thought of what would make up the Silverlight demo:

A mechanism to sign in for Facebook
A mechanism to harvest a user's friend list
A XAML-based map of the United States, to indicate where friends are located
Animation
Video

From there, who knows? I wanted to identify opportunities as I went. I will take you through some of the highs and lows of my experience.

Moving Day for VSTO

2007-11-26T21:25:00.000-07:00

I have been working on a Microsoft Office Business application sporadically with the Beta 2 version of Visual Studio.NET 2008. Once I got my hands on the RTM version of 2008, I tried to bring the project across. It did not immediately compile. I clocked in at about 20 build errors. A number of the assembly references were not recognized – apparently there was some renaming between Beta 2 and the real thing.I did a Google search on one of the unrecognized assembly references:

Microsoft.VisualStudio.Tools.Office

… and I was pointed towards the Visual Studio 2008 Readme file. But of course. That’s a handy place to put it, but I gave up reading readme files years ago – when they stopped being pithy descriptions of important issues and started becoming dumping grounds for any minutiae that the developer had in mind.

But this particular readme file had some good information. It began like this:

You may experience build and runtime errors when you build and run Beta 2 Office projects in the release version of Visual Studio 2008. Changes have been made to a number of VSTO reference assemblies.

Bingo. Then we got a nice little table:

Old Reference	New Reference
Microsoft.VisualStudio.Tools.Applications.ServerDocument.dll	Microsoft.VisualStudio.Tools.Applications.ServerDocument.v9.0.dll
Microsoft.VisualStudio.Tools.Office.dll	Microsoft.Office.Tools.v9.0.dll
Microsoft.VisualStudio.Tools.Office.Common.dll	Microsoft.Office.Tools.Common.v9.0.dll
Microsoft.VisualStudio.Tools.Office.Excel.dll	Microsoft.Office.Tools.Excel.v9.0.dll
Microsoft.VisualStudio.Tools.Office.Outlook.dll	Microsoft.Office.Tools.Outlook.v9.0.dll
Microsoft.VisualStudio.Tools.Office.Word.dll	Microsoft.Office.Tools.Word.v9.0.dll

The main change seemed easy enough to follow: The Microsoft.VisualStudio.Tools.Office.* assemblies had become Microsoft.Office.Tools.*

I added the references noted above, and got it down to 9 compile errors. I then noticed that the table was not comprehensive. My suspicions fell on one of the last remaining missing assemblies --Microsoft.VisualStudio.Tools.Applications.AddInBase. I made the mistake of picking the namespace that looked the most like the old one to take up the slack -- Microsoft.VisualStudio.Tools.Applications.AddInManager. Wrong.

So I applied the formula that seems to be implied by the conversion table and looked for the following assembly: Microsoft.Office.Tools.Applications.AddInBase. Nope. Didn’t exist.

Back to Google:

Microsoft.VisualStudio.Tools.Applications.AddInBase

No hits. Wow. It’s not often your search term goes for 0-for-internet. Surely, the assembly name will be found somewhere within MSDN. Nope. I’m starting to wonder where that came from. Let’s try deleting it from the references. Boom. No effect on the number of errors.

All right, then. Put that one aside and see where the errors are coming from. I started to suspect this namespace:

Microsoft.VisualStudio.Tools.Applications.Runtime

…it seems to be giving the compiler heartburn. I look closer at one of the errors:

The type 'Microsoft.VisualStudio.Tools.Applications.Runtime.IEntryPoint' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

Isn’t that interesting? It’s telling me what assembly is missing… and I didn’t seem to have that reference in the project before. Taking the tip that the compiler gave me, I added that assembly reference (Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0) And now we’re down to one compiler error.

The final error concerns the Ribbon Add-In that I created for my beta project. This was what drew me to use VS.NET 2008 in the first place. It was the only environment where you could use the designer to create a ribbon add-in that was specific to one document. (You could get to the same end result in VS.NET 2005 + VSTO, but there was a whole lot of rolling your own.)

In this case, I used the designer to build the Add-In, so the code was generated. That’s always fun to debug, because it’s sprinkled with warnings about how you should not touch the code under any circumstances. But let’s see if we can hone in. First, the compiler takes exception to the parent class – WordRibbon. So. If the shipping version of VS.NET2008 doesn’t like the way Beta 2 generated code, the next step is to see how the shipping version does it.

For comparison’s sake, I create a new Office project – a Word document. I add a new item to the project: Visual C# Items -> Office -> Ribbon (Visual Designer) The parent class that it generates in this case is OfficeRibbon. Otherwise, the method calls look fairly similar. So I simply change the WordRibbon to OfficeRibbon… and this time, the project compiles. Hit debug… and it fails on a SQL permission error. Vista’s new security paradigm strikes again – I’ll blog about that another day. I clean up that error, and now the application runs in debug mode… except my Ribbon Add-in does not show up. It does not throw an error, but neither does it show up.

Back to the test project I created to see how VS.NET 2008 RTM creates the Ribbon Add-In. That one works just fine – it shows up on the Ribbon where it’s supposed to. I launch another instance of VS.NET 2008, so that I can have both projects open simultaneously. I hone in on the generated code, which mainly consists of InitializeComponent() method. Other than the specific buttons and so forth, the code looks awfully similar.But I find one class in the *.Designer.cs file that’s not in the beta version

    partial class ThisRibbonCollection : Microsoft.Office.Tools.Ribbon.RibbonReadOnlyCollection
    {
        internal TestRibbon TestRibbon
        {
            get { return this.GetRibbon<TestRibbon>(); }
        }
    }

So I add that block of code to my new project (changing the class names). Why not? But that has no effect whatsoever.

This is an opportunity to dig into the internals of how the Ribbon Add-Ins generate code… but, then again, it’s not like I’m ever going to go back to the beta version of VS.NET 2008. It’s probably easier to add a new item to my new project – recreate the Ribbon Add-In with VS.NET 2008 RTM’s designer. That gives me the straightest line between where I am and where I want to go.

Recreating the Ribbon Add-In is pretty straightforward, mainly consisting of dragging and dropping a number of buttons. All the functionality behind the buttons resides in other classes, so I just have to wire simple method calls to the buttons’ click events.

One mildly interesting thing did come out of the exercise. Whereas the previous iteration of Add-In allowed me to create a reference to my Word document when the class is initialized:

IMPWriteFactorFour.ThisDocument _wordDoc = Globals.ThisDocument;

… which I then referenced within the Add-In class to execute methods:

        private void nextLineButton_Click(object sender, RibbonControlEventArgs e)
        {
            _wordDoc.advanceLine();
        }

This caused a null reference error in the RTM version. It did not recognize the _wordDoc variable as a reference to the current Word document. I had to change the methods to explicitly set that variable.

        private void nextLineButton_Click(object sender, RibbonControlEventArgs e)
        {
            _wordDoc = Globals.ThisDocument;
            _wordDoc.advanceLine();
        }

… and it was happy. Apparently, something about the order of loading Ribbon Add-Ins changed between Beta 2 and RTM.

And now I can proceed, from the point I left off on Beta 2.

Lessons Learned?

I found it interesting that I had to change a number of assembly references, but the actual namespaces within the code did not have to change. Once I added the correct assembly, the code compiled. In looking at the assembly naming, I'm guessing that the dev team wanted to standardize the naming in the final release to conform to the naming conventions in the previous versions of VSTO. It was also interesting to see the differences in functionality between the beta and final releases of the Ribbon Add-Ins.

The Climb to Visual Studio.NET 2008

2007-11-25T22:00:00.000-07:00

So I was on the road when I heard the announcement that the RTM version of Visual Studio.NET 2008 had been released to MSDN subscribers. It caught me unaware – I hadn’t been keeping up with the timeline for the release. I tried to download it from my hotel room, but if you’ve tried to download anything bigger than, say, a text file on a hotel’s free WiFi, you know the folly of trying to grab a 4 Gigabyte file.

When I got back home and finally got my hands on it, the game was on. I had been playing with the beta 2 release of VS.NET 2008 for some months, so it was cool to get the real thing. To get that program, I had downloaded the Virtual PC from MSDN that had VS.NET 2008 beta 2 and SQL Server 2005 pre-installed. Being a Virtual PC junkie, I was touched by MSDN’s gesture of making that available to everyone.

Seriously, though. I'm deep with virtual machines. Since my work involves multiple clients, and my interests range far afield, I tend to organize through Virtual PCs. So if I go to one client, I’ll use one VPC with all the relevant programs and files, then when I go to another, I have a different VPC. My personal stuff is contained on other VPC’s still. I keep the whole shooting match synchronized through the excellent and underrated program Groove (which I will undoubtedly blog about later). The only downside is that I have about 15 Petabytes worth of VPC’s.

Naturally, then, I decided to install the RTM version of VS.NET 2008 on a VPC. Some interesting things came out of the exercise. Because of the nature of this blog, I’ll tell you about the problems.

I started with a base VMWare image that was running the Vista operating system. It also had the Microsoft Office 2007 Ultimate suite, which I considered vital, since developing Office Business Applications is one of my current interests. I cloned the virtual machine, and then installed programs in the following order:

1. Visual Studio.NET 2008 Team Edition
2. SQL Server 2005 Developer Edition
3. SQL Server 2005 Service Pack 2

I had been through the painful process of trying to get VS.NET 2005/SQL Server 2005 to run on Vista, so that’s why I went straight from the base installation of SQL Server 2005 through Service Pack 2 without pause. There is a good description of that process here.

Well, this “leave the configuration up to the programs” approach caused problems. It seemingly always does, of course, but I’m a hopeful sort. The first problem was that VS.NET 2008 gave me a warning about IIS not being configured. SQL Server 2005 did the same. Worst of all, I found myself without an instance of SQL Server Management Studio 2005. And yes, I had selected Management Tools under Client Tools node in SQL Server Setup during installation. It just apparently didn’t see fit to install or give a descriptive error of what caused the installation failure.

The IIS problems were understandable after a bit of detective work. VS.NET wanted certain features to be turned on, and SQL 2005 wanted some to be turned on as well. Even if you have IIS 7.0 turned on, the installers will not necessarily recognize it. The correct configuration was hardly intuitive, but the information was available.

The lack of SQL tools was a bit more troublesome. Most of the discussion around the issue either blamed the person installing SQL for not selecting Management Tools. There was some sporadic advice about how to install the client tools on their own.

I tried to install the SQL client tools on their own. First, I went the route of changing the program through the usual Vista method: Control Panel -> Programs and Features -> Uninstall a program (I regret that when you want to change a program installation in Vista, you have to select Uninstall a program, but I digress.) That didn’t work. I ran the main SQL Server Installer, and I ran the specific MSI for the client tools (SqlRun_Tools.msi). I was unsuccessful, but the errors were ambiguous. I believe it had something to do with the fact that I had already applied Service Pack 2, and I was trying to go back to the original discs to add the client tools.

I still haven’t got a concrete answer, but I could guess at some possible problems with the initial installation. Maybe when SQL tried to install VS.NET 2005 (as part of Business Intelligence Studio), the installer recognized that a later version was installed (VS.NET 2008) and aborted the operation. Or maybe VS.NET’s installation of SQL Express gummed up the works. I just decided to attack the problem another way.

Solution abound

So. Step #1 for me was to make another clone of my base virtual machine and take another shot from the beginning. Then it was a matter of reconfiguring IIS so that the programs would recognize it. Using a variety of sources to find the requirements for both VS.NET and SQL, I ended up selecting the following settings (to get here in Vista, select Start Menu -> Control Panel -> Programs -> Turn Windows Features On or Off)

Internet Information Services
Web Management Tools
IIS 6 Management Compatibility
IIS WMI Compatibility
IIS Metabase and IIS 6 configuration compatibility
IIS Management Console
World Wide Web Services
Application Development Features
.NET Extensibility
ASP.NET
ISAPI Extensions
ISAPI Filters
Common Http Features
Default Document
Directory Browsing
HTTP Errors
HTTP Redirection
Static Content
Health and Diagnostics
HTTP Logging
Request Monitor
Performance Features
Static Content Compression
Security
Request Filtering
Windows Authentication

(The features in bold were the ones I checked).

Then I changed the order of my installation:

1. SQL Server 2005 Developer Edition
2. SQL Server 2005 Service Pack 2
3. Visual Studio.NET 2008 Team Edition

Right as rain this time. Both programs were happy with how IIS was configured. The SQL client tools appeared as expected. I now have my installation of VS.NET 2008 rocking. And there was much rejoicing.

What have we learned?

If you are going to have a full version of SQL running with VS.NET 2008, install it first. Tread carefully when configuring IIS on Vista, to work with VS.NET and SQL.

What I'm Up To

2007-11-24T22:22:00.000-07:00

Almost all the important things I've learned about coding have come as a result of difficulties. Don't get me wrong, I'm addicted to reference material -- technical books, blogs, and even user manuals. I read them with abandon. I can find something interesting in just about any technical topic, no matter how obscure. But training cannot substitute for the experience of sitting in front of a computer, trying to accomplish some piece of functionality. The questions start immediately. What am I trying to do? How can I accomplish it? What is the best way to accomplish it? How will this task fit into a larger picture? The questions have real consequences. If you don't find an answer, your code does not work. Reference materials help, but the fundamental process of trial and error is where learning really starts to happen.

Another enduring problem is that reference material for technology is fairly good at telling you what it can do. Finding out what it can't do is another story. It makes sense, I suppose. If every software vendor had to document every feature it does NOT have -- "support for 64-bit", "vector graphics", "toilet cleaning" -- manuals would be very long indeed. But it seems like there always comes a time where I say, "I'd like to implement feature A, surely there's a method to do that." -- but I can't find it. Then it becomes a long process of guesswork, until the envisioned solution is hit upon, an alternate method is found, or I go take a rest in the insane asylum for a while.

Most technical blogs -- and let me re-emphasize that they are invaluable to me -- take the tactic of tutorials, feature demonstrations, or product information. I've been considering writing a similar blog myself for years. But after some revelatory struggles with coding, I thought it might be more interesting to write about the challenges I face. I plan to document some of the struggle; not just the pretty end result, but the mistakes, bumps, and bruises that lead to the goal.

I have to believe that anyone who's serious about software development faces similar challenges. It's an industry where you have to keep challenging yourself to move outside your comfort zone, or you never progress. If you find a comfort zone, it generally changes.

I've been in the industry for a decent amount of time. The amount of change is staggering year-over-year. The number and variety of development tools almost defies comprehension. It's rare that I get involved with a work project that doesn't have some novel (to me) technology or technological approach. Then there are the projects that I work on for my own interest. For those, I generally choose new technologies I want to learn. So the learning curve provides innumerable opportunities to share my difficulties.

I kind of doubt that this blog will develop a consistent theme, technology-wise. Since my interests in technology and software development know almost no bounds, I'm generally all over the map. If I hear about something that sounds interesting, I will go after it. Chances are good that most posts will deal with the Microsoft stack, since my career is totally focused there, and my personal projects trend in that direction. But don't bet the farm on it.

So welcome to my blog. If some of my challenges interest you, make you laugh -- or best of all, help you, then I've done what I've set out to do.