Thaumato

Use fo:region-body column-count=2, or column-count=whatever you want.

I’ve been mentally toying with the idea of setting up a dual boot so I can run linux for a while now. My laptop freezes up with Vista all the time. So that was a reason to do it. Also I do rails development and Windows is definitely considered a ghetto. Support for latest features isn’t always there and I found myself more often than not settling or searching the web for a workaround - but I usually found the workaround. Well a couple of weeks ago I ran into something I couldn’t do on Windows - I needed the latest version of merb - and it just would not run on windows. So… I was ready to bite the bullet and install dual boot, etc. when I remembered VMWare Player - well let me tell you it is awesome. I now have a fully functioning linux dev env running in its own window!

One thing, it does take up a chunk of cpu - so yesterday I was multi-tasking - I just closed the player w/o shutting down the linux virtual machine - today I opened it again - and it restored the state perfectly! Even after a physical reboot! That is incredible software! I love this stuff - and its free, I cannot believe it.

Update - when the system is restored the time is out of synch - so this command brings it current
sudo ntpdate pool.ntp.org

Wiring up ActiveMessaging and SQS today - ran into an issue - thought I’d document it in case anyone else comes across it.

Starting up the poller I kept getting a nil pointer at this line -
plugins/activemessaging/lib/activemessaging/adapters/asqs.rb:64:in `subscribe’: You have a nil object when you didn’t expect it! (NoMethodError)

Which I tracked here:
if @subscriptions.has_key? queue.name

Which is part of this method:
# queue_name string, headers hash
# for sqs, make sure queue exists, if not create, then add to list of polled queues
def subscribe queue_name, message_headers={}
# look at the existing queues, create any that are missing
queue = get_or_create_queue queue_name
if @subscriptions.has_key? queue.name #<=exception here!
@subscriptions[queue.name].add
else
@subscriptions[queue.name] = Subscription.new(queue.name, message_headers)
end
end

The issue turned out to be the @request_expires configuration variable by default is set to 10 milliseconds, and the requests were timing out. So I upped it and things are working great.

What makes this a gotcha is another default configuration setting @reliable is set to true. This means most of the errors encountered will be eaten! So I didn’t get a HTTPBadRequest error - I got this nil pointer. So - when setting this up for the first time, my recommendation would be to set @reliable to false. In fact, its not a bad idea for the ActiveMessaging plug-in in general.

Ok - I am fairly new to the REST vs SOAP debate. I hadn’t seen the SOAP stack in progress, but I have an instinct for simplicity and so I was definately rooting for the cause of the REST folks, even if I didn’t fully see what the big deal was about. Anyway, at my day job now I am working on a project which will need to expose a web service to an external vendor. Should be pretty interesting stuff.

We have some very smart people who run the infrastructure side of things where I work, and I thought we might be able to give REST a try for our service. They were sympathetic, but ultimately the security mechanisms we have in place support SOAP very well and while there was no reason REST couldn’t be used it was presented as “not trivial by any stretch of the imagination.”

So - SOAP it was. Document Literal. WSDL. Things I had only vague notions about. So I’m now on a mission to run the SOAP stack gauntlet. I’m actually happy to be doing so. I can feel my brain connecting new neurons. Plus, its good to actually dive deep into the muck to understand the real motivations for people’s aversion to SOAP. I think it is becoming a mantra to diss SOAP out of hand, and so many people are probably not even giving it a try, or understanding why (if?) it sucks so bad. At least at the end of this project I’ll have used it enough to form my own opinion.

Getting up to speed has been challenging, but in a good way - as I mentioned. According to recent studies learning new things exercises your brain and forges new pathways which can help offset alzheimers in old age and keep you sharp well into your 80s. Both good things and likely enough positive mojo to counter whatever frustrations SOAP has in store for me.

Today I am trying to write WSDL. I have decided to try the “Top Down” approach. Its amazing how much more I understand the structure and intent of the WSDL after writing one. Reading it engages an entirely different part of your brain. Its so much more passive than doing. Reading the WSDL spec and trying to slog through some of the documentation on Webservices Profiles was completely boring. I could tell nothing was sticking. There was no residual structure left after going through the stuff, no mental framework left behind at all. But doing is a completely different story. I’m forced to engage the concepts and try and implement them - making many many mistakes along the way. Each mistake involves more and deeper understanding to correct it. At the end I’ve got a fairly good, though by no means thorough, understanding of the WSDL structure.

Software systems have a hard time reaching 100% uptime. Apart from the various bugs in the code which contribute to its capricious nature, the pieces the software itself depends on may crash, break or burn as well. They might behave in a completely unexpected unrecoverable way. Stuff happens. It seems to be the nature of the beast.

A few years back when I was working on a large, +1 year late project with a number of other consultants Ravi, a wise, older programmer, compared software construction to building construction and said that the reason the latter was so much more predictable was that it had been around for 10s of thousands of years while software construction was still in the infant stages. His eyes lit up as he spoke of a future where the same degree of dependability could be found in both fields, and we all wondered what developments would have to occur first. Frameworks, components, not reinventing the wheel every time, process, methods, the list of potential silver bullets went on and on. Its been 5 years since that conversation and while new technologies abound software’s essential difficulties remain. 99.999% uptime is more than most systems hope for, and getting there is an extreme challenge.

But if you look closely at the building/software construction comparison there is a singular advantage builders of human dwellings have over builders of logical dwellings: the stability of their materials.
Wood has 100% uptime - not 99.5. This is no chance that a steel beam could get stuck in an infinite loop. Nails aren’t going to throw stale database connection errors. Cement will not stop working if the cable in the server cage becomes unplugged. Latex paint works with all versions of sheetrock.
The basic building block of physical structures is matter. The basic building block of software is logic. Matter comes with a built in runtime guaranteed by the God. People are often amazed that software works at all. To even begin to reach a level of parity with building construction we would do well to first solve the metaphysical problem of permanence. Too often Berkeley’s hunch is correct in software. But perhaps Werner Vogels and the folks over at Amazon are starting to change that.

The idea of Dynamo has gotten me breathless with excitement. Its birth will be matched only by sliced bread in importance. What they are planning to deliver is nothing less that the metaphysical underpinnings for permanent logical structures, a kind of operating system that could function as the laws of physics and reality function for wood and steel, a new universe where unbounded by time, space, crashes or data loss developers could unleash applications not as creatures into wild mother nature but as intelligent atoms into reality 2.0. Perhaps the singularity is near after all.