The new year brought with it the chance to reflect on technologies that I see making a splash in the coming year. I’m enthralled by big data and analytics but I’m not a data scientist; likewise, I only see so much value in the wearables themselves, although they’ll certainly feed the big data beast. My list of technologies is strongly influenced by my background in software and devops — without being a list of language or tool features.
I feel like I’m in the homestretch of my migration off of my current hosting provider – FullControl. Nothing against these guys; they’ve been an absolute stellar service provider. I just don’t need the dedicated virtual server I was paying for with them. It’s a short story that came down to rightsizing my hosting provider to align with my current needs. I’ll tell the somewhat longer version of the story in this blog post though since there are a couple of interesting corollaries along the way.
I recently had the opportunity to look into and make use of the Microsoft System.Security.SecureString class. This class is one of those dark corners of the .NET Framework that you don’t think about on a day-to-day basis but are really glad that it’s there when your security auditor starts asking questions about how PII data such as social security numbers are protected while resident in memory. The SecureString class takes care of this problem, helping you avoid a situation where unencrypted sensitive String data is left lingering around on the .NET heap. However, since this class does reference unmanaged memory buffers, its use is not entirely intuitive. I’ve attempted to demystify things with the explanation, drawing and code snippets in this post.