Hyper-V 2012 has been out for a while now; I finally took the plunge and upgraded my lab infrastructure at home1. Given that all my test containers are virtualised in Hyper-V 2008 already; it should just be a case of moving the images around to free up a host machine so that the hosts can be upgraded in sequence. Ultimately it was painless, but time consuming; a large part of it was copying gigabytes of data around my network.
I have inherited a bunch of broken laptops; it’s over-egging it to call it a lab↩︎
So, we’ve ascertained that projects are more likely to fail than succeed; but somehow we succeed a lot of the time. There are some general principles that I apply when delivering any project which I’ve found makes everyone a lot happier; the team, the business stakeholders, and me. A word of warning; anecdotal evidence is not science, no matter what some alternative therapists would have you believe; I’m not a PMP and I don’t have any qualifications from the PMI. All of this might just be hokum and inapplicable outside of my experience.
Bridging between MSMQ and java using the adapter framework
Microsoft Message Queueing is a pretty good way of allowing applications running on different servers to communicate in a failsafe manner; it’s baked directly into all recent versions of Windows and has extensive API support via Visual Studio. However, all your applications are going to be running on the Windows platform and this can cause issues if your technology stack spans multiple platforms. Bridging between MSMQ and other platforms like a java based ESB might be causing you a bit of a headache.
It often occurs to me that a fair number of project managers are inordinately optimistic when it comes to managing the delivery of a project. Given the number of high-profile failures reported in the media, and their own experience, you’d think that we would have learnt to temper our optimism with a healthy dose of realism. Seems not.
Working with different character encodings is almost fun. I do get asked a lot about this kind of thing; my transform doesn’t work, or this EDI document doesn’t parse properly (I suppose the customer thinks that diacritics are allowed in the UNOA character set?); I like to say that the adapter only knows as much about encoding as you do; everything is configurable so your choices (or tacit acceptance of the defaults) will have a huge impact on how the adapter behaves.