A healthy start

This week was my first working for RL Solutions, a software company which provides solutions for the healthcare sector. RL have their main office in Toronto, Canada (checkout the pictures on their careers site). I couldn't find a bus that would travel that far each day, so (sensibly) I've joined the development team based in their Adelaide office.

I get the impression from the four interviews I had before being offered the position (including with Sanjay, the founder and CEO) that RL have definite ideas about the kind of people they want to hire (not just looking for technical expertise). One of the things that appealed to me was the approach RL is taking in creating a modern, mature, healthy, fun and social work environment. That seems to manifest itself in a number of ways (some just relevant to Toronto or Adelaide and some in common) and I think it's a really positive thing.

My first few days have been spent getting to know the other Adelaide staff (helped in no small way by going out to lunch together on my first day), working through the company's induction programme (they are pretty organised around this), and starting to familiarise myself with the application and codebase that I'll be calling home.

I will also say it is nice to work in a modern building again – one where you don't have nagging doubts that the lifts will deliver you to the floor you requested, and that (a bonus for occasional bike commuters) has shower facilities! I'm still in the CBD though, so no changes to my daily commute.

A nice surprise was the 'welcome' pack waiting on my desk on my first day – including a company-branded backpack.

It's going to be an interesting time, especially learning a whole new business (hospitals etc.) – quite a contrast to my previous industry areas of commodity handling and higher education online teaching and learning. It might prove quite useful to be married to someone with a nursing background, not to mention that our family seem to be rather regular consumers of the health system!

I'm looking forward to it 😀

The Grand Final

Yesterday was my last in the office at Eka (formerly MatrixGroup). It was great to catch up with everyone one last time after just over 3 years being on staff. A few final handovers, farewell lunch, attending and presenting at my final Developer meeting and monthly company meeting. I'll miss working with the people there, but I'd decided it was time to move on. In the meantime, I'm taking a short break. Time to relax, get some kms on the bike, enjoy Adelaide's beautiful spring weather, one or two jobs around the house and do some family things for the first week of the school holidays. After that I'll be starting something new – more about that in a couple of weeks time! The photo is from my ride on Tuesday with the Mud, Sweat & Gears blokes heading to Outer Harbour. That turned out to be a handy 93km round trip! I must be doing ok as I pulled up pretty well. It is pretty flat for most of the ride, which probably helped. (Oh yes, it's also the AFL Grand Final today)

Beware of Invoke-WebRequest in PowerShell DSC

PowerShell has a handy cmdlet named Invoke-WebRequest. I was making use of this in a Script resource as part of a DSC script.

The weird thing was that most of the time it worked, but sometimes the DSC script hung, and as best I could tell, it was within the Script resource that was calling Invoke-WebRequest, but I couldn’t understand why.

Eventually on one particular server, I was able to cause something surprising to happen – calling Invoke-WebRequest caused a modal dialog to appear. The interesting thing was that the server had Internet Explorer Enhanced Security Configuration enabled. Not surprisingly that’s the default for Windows Server.

I posted a question to Stack Overflow and a comment added to the answer made me realise what is actually going on.

I had naively assumed that Invoke-WebRequest is just a nice wrapper around the .NET Framework’s WebClient class, but it turns out it is a bit more than that. It also appears to reference IE-related code.

If you're curious as to what Invoke-WebRequest actually does, then fire up your favourite IL decompiler and point it at C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.PowerShell.Commands.Utility\v4.0_3.0.0.0__31bf3856ad364e35\Microsoft.PowerShell.Commands.Utility.dll (that's the path I found the full assembly at).

While the implementation of Invoke-WebRequest actually uses System.Net.WebRequest, it also creates an instance of the IHTMLDocument2 COM object, and I suspect this is the trigger that causes the IE warning to appear.

So if you just want to hit a web address without requiring all the extra features of IE processing, just call either WebClient or WebRequest directly from PowerShell, or Use Invoke-WebRequest but probably not in a 'headless' environment.