This is a story about leaky abstractions. It’s not a happy story, and I don’t talk about cool things like WPF, AJAX, JSON, POX, or how much I detest the RIAA.
Instead, this is the story of a developer and the Process.Start() method. It’s not exciting, and I don’t mention Silverlight anywhere other than this sentence.
Still, you should listen.
Leaky Abstractions are the technological equivalent of a spring poking through your couch. Until the day that you sat on that rusty, pointy springy-spring, you knew that your couch was comfy. To tell the truth, you really didn’t know, care, or care to know why. Joel Spolsky has his own diatribe on this subject, and it’s worth reading. Of course, he talks about software, and not couch springs, but I’m sure you will still get the point.
Some time ago, my team noticed that a core part of our application would fail to respond, and when we restarted it, it would fail to reclaim its remoting TCP/IP port. Specifically, it listened on port 30123, and whenever we restarted the application, we would receive a System.Net.Sockets.SocketException claiming that the port was already in use. From the command line, a netstat –a verified this information. The netstat output also revealed that the “dead” process had the port still locked. We were mystified, as netstat was reporting a Process ID (PID) that was no longer in the task list.
Earlier this week, my twelve year old daughter approached me and asked to learn "All that computer stuff that you do." We had chatted previously about my job, but I had taken particular care to not pressure her into learning computers. Such a decision is best left to natural curiousity.
Hanna and I talked about several languages. She had wanted to learn C#, as that is what I spend most of my time with. Instead, I suggested Ruby. I've always wanted to learn the language, and an interpreted environment would make the edit-compile-debug loop a little bit easier.
Ruby has yet to disappoint me as a teaching language. While I haven't found any Ruby books suitable for teaching a pre-teen Ruby programming skills, I have been able to develop simple lesson plans to teach basic concepts. Along the way, I'm also learning the language, which is a big plus for me.
I feel like I just got hit by the dodgeball in elementary school gym class. In a unique game of tag, I'm supposed to tell everyone five things that they didn't know about me. Well, here goes:
1. I spent 6 years in the United States Army as a Military Policeman. I served in quite a few places overseas, incuding time as a NATO peacekeeper in Bosnia.
2. I once assisted the Secret Service in guarding President Clinton. My unenviable task was keeping the press corps from standing in front of a Secret Service SUV packed with every armament imaginable. There was an agent sitting behind the wheel with one foot on the brake, and the other on the gas, with the idea that if there was a threat, he would gun the engine and drive forward in order for the rest of the agents to retrieve heavier firepower. While I'm quite sure that no-one present was overly fond of the press, no-one wanted the headline "Government Agent Creates Speedbump Out of CBS Cameraman. Film at 11." I met the President again shortly after this assignment.
3. Before I was old and slow, I ran track and cross-country in high-school. Back in the day, I used to be able to run a sub-5 minute mile, and once ran a "short" 5k in under 16 minutes. Not world record stuff, mind you, but not bad.
4. I got into Information Technology after leaving the service. I had applied for the Cobb County police department in Georgia, and was waiting for my academy date. While waiting, I applied for an internet tech support job. When my academy date rolled around, I was already a supervisor making almost twice what I would as a police trainee. I stuck with my new career, and here I am eight years later! (I still watch law & order for my cops & robbers 'fix').
5. I would like to try my hand at writing a technical book, but I always feel that it would be a bit presumptuous of me.
Now for the "tag" part - Tag: Yang Cao, Wally McClure, Rob Mensching, DonXML, and Erik Porter.
My Continuous Integration presentation in Dallas, Texas went pretty well. Although I'm not a practiced speaker, it seems that the audience was engaged and interested. I've even been invited to present on the same topic again to another group.
A few loyal readers have complained that the "Occasional Clue" has been a little less occasional than anticipated.
One of the keynote presentations today was on Windows Compute Cluster Solution. Now, I've been working with Windows Clusters in a High Availability environment for some time now, so I've been very interested in what Microsoft's message was going to be in this product space. Microsoft has been getting their lunch handed to them in this area by Linux clusters for a long, long time. While it is currently possible to build High Performance Clusters on Windows without the Compute Cluster Solution, it is certainly not straightforward.
Well, everyone else has been posting about the PDC - I thought that I would have written by now, but I haven't really seen anything that is really exciting. So far, most everything seems to be a refinement of things introduced in PDC 2003.
Oh, Office 12 was mentioned. Since use Office as a glorified Wordpad.exe, that's really not that exciting.
I am currently sitting in the session, "High Performance Computing with Windows Server Compute Cluster Solution." It's a slide-show fest, with very little demo or bits to see. This session is a basic review of of Clustering, and is mostly review if you are familiar with these concepts.
There's actually very little about what microsoft is doing in this space, and more about what high performance clustering actually is. I'm still not impressed. Show me, don't slide-show me.
Sometimes things that everyone just knows aren't always true.
For example, when I look at c# code, I know that local variables are stored on the stack. Or, I thought I knew that.
So, over the last couple of years, I've been what I consider a 'defender' of MSDN documentation. After all, the docs are miles ahead of what they used to be.