Head in the Cloud

" Everything should be made as simple as possible, but no simpler. " -Albert Eistein. Ok, I have to rant for a bit.  I apologize if the article is brass or if I ramble in places, but I promise, out of it comes a lesson in simplicity and efficiency. For any developer (or any tradesman for that matter), good habits and sharp skills require a solid foundation.  For me, that foundation came from my course work at Bay Path Regional Vocational Technical High School.  One of my instructors there, Bill Bostock, the very first day of class, wrote on the chalk board in large letters: K.I.S.S. Then asked us what it meant.  After some giggling and music references, he elaborated: K eep I t S imple S tupid The KISS Principle That day and that lecture will stick in my mind for ever.  I even use it in my own introduction to computer programming lectures at American Career Institute.  He told us there are many answers to any given problem, some complex, some simple...do e

I noticed the fans in my Macbook Pro were running excessively.  When looking at Activity Monitor, I noted that the Dock was using 100% of the CPU.  A quick search on Google, and I found the culprit to be Parallels.  The root cause is an issue with the graphics API between OS X 10.6.8 and Parallels Desktop 6.  I had indeed recently updated to 10.6.8 in preparation for Lion. The details can be found in this Parallels KB article: Mac Dock consuming 100% of CPU core after upgrade to Mac OS X 10.6.8 Symptoms: Dock consumes 100% of CPU Environment: Mac OS X 10.6.8 Parallels 6.0.12090 The Solution Rather than downloading from the web site, I simply ran the "Check for Updates" on the Parallels application menu.

If you want to handle events when working with System.Diagnostics.Process -- for example, the Exited event -- you have to first enable the raising of events using the EnableRaisingEvents property on Process. 1: using System.Diagnostics; 2:   3: class MyClass 4: { 5: void RunProcess() 6: { 7: Process p = new Process(); 8: p.EnableRaisingEvents = true ; 9: p.Exited += new EventHander(Process_Exited); 10: } 11:   12: }

Bit by yet another not-so-well documented "feature" in Microsoft .Net.  We were compiling in release mode for QA, since we've seen other behavioral differences between debug and release.  We also wanted to emit the line numbers in the stack trace so the engineers would have a better idea of what caused the error.  We added the /degub:pdbonly option, but left the /optimize+.  We noticed that some of the errors when compared to the line numbers didn't make sense.  It turned out that most of the stack trace was wrong... or at least wrong when compared to the original source code. If you want to emit debug symbols, ie. pdb files, when compiling in release mode, you have to disable optimizations.  Compiler optimizations will often reorganize instructions for the most efficient execution.  As a result, any stack trace will produce unexpected line numbers... you'll get the line number in the newly optimized code, not the line in your original source code. Disabling O

A recent project required the need to store an unsigned 64-bit integer in a SQL Server database table. BIGINT won't cut it because BIGINT has a max value of 9,223,372,036,854,775,807 (signed 64-bit integer), and the unsigned 64-bit integer's max value is 18,446,744,073,709,551,615.  The solution is to use NUMERIC(20) instead. I recalled that other DBMS's do support unsigned integers as integer types vs. coercion with numeric, so I decided to compare a few of them and document them here. DBMS Unsigned 64Bit Unsigned 32Bit Unsigned 16Bit SQL Server (as of "Denali") numeric(20) numeric(10) numeric(5) Oracle (as of 11g) number(20), numeric(20) number(10), numeric(10) number(5), numeric(5) MySQL (as of 5.x) bigint, numeric(20) int, numeric(10) smallint, numeric(5) Postgres (as of 9.x) numeric(20) numeric(10) numeric(5) DB2 UDB (as of 9.x) numeric(20) numeric(10) numeric(5)

It was time to upgrade the virtual machine host at Milestone.  Since most of our critical systems are hosted, the server(s) here didn't need to be anything to extreme.  The servers in house are development and test lab related.  The goals for the upgrade were to: Upgrade the hardware Go Green Experiment with various hypervisors to see which ones can be used in SOHO environments with low investment, low TCO, high ROI, and little or no headache when it comes to install and maintenance. Hardware Selection I first took a look at Apple's Mac Mini and Mac Mini Server.  These machines are certainly an upgrade from what I have and meet my green requirement with a mier 85W max power consumption, but they only have a dual core processor.  In most cases, I would say they are perfect for the SOHO environment.  Because we would be spinning up several virtual machines, I wanted to kick it up a notch.  I was also concerned about the availability of drivers with the Mac Mini, since I'd

CentOS/Red Hat 5.5 on Hyper-V R2 seems to work quite well.  The trick is to download the Linux Integration Services from Microsoft and follow the install guide before creating the VM.  The guide provides specific installation guidelines for creating/configuring the VM and installing the OS itself. At the time of this writing, the latest version can be found here: Linux Integration Services v2.1 for Windows Server 2008 Hyper-V R2 http://www.microsoft.com/downloads/en/details.aspx?FamilyID=eee39325-898b-4522-9b4c-f4b5b9b64551&displaylang=en ...but please be sure you download the latest version at the time of your reading this. Creating The Virtual Machine When creating the virtual machine, use the "Legacy Network Adapter" .  To reduce any issues, I recommend making this the only network adapter configured.  CentOS, actually, any non-windows server OS or Windows versions prior to 2003, will not see the virtual "Network Adapter" until integration services are