I’ve been using these computer things for a while. I’ve written what is now over 100k lines of production C code and many thousands of lines of code in a variety of other languages. I’ve seen my software run and I’ve run other people software. One thing they all have in common is their propensity to break under unforeseen circumstances. Shit happens. On my laptop, I don’t care much. I want nice, I want convenient, I want new and pretty and productive.
I haven’t blogged for a while because: I have been travelling insanely. About 80k miles this year so far. Hacking on Circonus and (subsequently) Reconnoiter. Providing strategic and tactical guidance on some mind blowing projects for the truly awesome clientele we have at OmniTI. Speaking at quite a number of conferences. Attempting to participate more in some of the open source projects I can help. … and planning for Surge.
My opinion is that the only reason the big enterprise storage vendors have gotten away with network block storage for the last decade is that they can afford to over-engineer the hell out of them and have the luxury of running enterprise workloads, which is a code phrase for “consolidated idle workloads.” When the going gets tough in enterprise storage systems, you do capacity planning and make sure your hot apps are on dedicated spindles, controllers, and network ports.
The CFPs have been rolling in for Surge 2011; these are exciting times. It does, however, appear that our description of what we’re looking for has produced a different set of submissions that what I expected. I think it might help to better understand what sessions were like last year and, luckily, we’ll be releasing all of the Surge 2010 video footage this week. I apologize for the poor audio quality, we intend to pull in A/V recording professionals this year.
At OmniTI, I’ve been a part of writing a lot of open source software, my fair share of closed source software. Some of it has been shipped and some of it has been operated as a service. While it is possible (and quite useful) to take what one learns in one scenario and apply it to another, some things simply translate poorly. I do a lot of consulting with traditional software companies that are looking to make a transition to the new world of SaaS.
I’m flying back from a wonderful event: Strata. I gave a talk there called “Esperwhispering” that seemed to pique many people’s interest. This is the stuff you do when a database just doesn’t have the horsepower to answer your questions fast enough. Esper is an excellent, open-source CEP tool. It’s a shame its GPL, but hey… you can’t win ‘em all. We use esper to power many things internally at OmniTI and our clients and Esper is the code CEP engine we use to make sure Circonus custsomers know when “things go wrong.
Defining the term: I recently used a term and was hit with a lot of out-of-band requests for explanation. It’s a good one and excellent food for thought. ywahusty (yuh-wuh-hus-tee): you will always have users smarter than you. This basic concept is one of sound, pragmatic systems engineering that might appear to fly in the face of traditional product engineering… but doesn’t. In traditional product engineering, there is a goal to produce a product that is both accessible and useful to the largest subset of the predefined audience of the product.