For someone who can barely keep his blog up to date, I would still love to write a book one day. I’ve been told I have a great amount of technical talent multiple times, can sometimes firehose people asking for an intro to a topic, or get a bit detailed. So I’ve got plenty in my head to share, I’m just not sure on how to distill the knowledge I have and what topics people would be genuinely interested in reading. My frontrunners for the topics I’d love to write about are:Continue reading

The current project I’m on is finding a path to adopting DevOps in an enterprise environment. The weeks of preparation, pitch to directors, and executive management is in the past, I’ve received the necessary approval to proceed without any limitations (outside of additional authority to actually enforce change). Still need to persuade each product group to see the light and change on their own, while guiding them down a yellow brick road.

News had spread a little that we got the green light, and some individual contributors in the company were interested in what DevOps was really all about. There is as much curiosity in learning more about it as there was fear of job loss from the change, even though no headcount modifications were even in the pitch. The only changes we suggested were lateral moves in the existing reporting structure.Continue reading

I was asked by another developer recently that was struggling to find a way to provide a Guid that was somehow a hashed value of a given string. The idea was that for any provided string, it would always return the same Guid value. They weren’t concerned with duplicates as that was taken care of using some other set of business logic.

The best thing that came to mind that accomplished this was pushing the string through the MD5 crypto provider and then feeding it into the Guid constructor. The output from the provider is 16 bytes, which just so happens to be the matching array size that the Guid constructor hopes to receive.

Weirdly, neither him or any of the other developers on his team knew about this trick. So I figure it’s something that should be worth posting as it didn’t seem obvious to them, and I guess I should make use of this blog thing every once in a while given that I pay $10/month for it.

If you happen to be giving Visual Studio 2012 RC a run around the block and noticed all of the menus are in CAPS, you can drop this in a Setting.reg file and import it…

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General]
"SuppressUppercaseConversion"=dword:00000001

If you decided that you want to go back, change the contents of the file to the following and import it again…

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General]
"SuppressUppercaseConversion"=-

Update (10/13/2014):

These same instructions can be applied to Visual Studio 2013 as well by substituting the ‘11.0’ value for ‘12.0’. For those of you using Visual Studio Express 2013 for Web, the same instructions while substituting the ‘VisualStudio’ value for ‘WDExpress’ will work.

With whatever version you are using, if you don’t want to open the Registry Editor, you can also enable it using PowerShell and the appropriate registry string like so…

Set-ItemProperty -Path HKCU:\Software\Microsoft\VisualStudio\12.0\General -Name SuppressUppercaseConversion -Type DWord -Value 1

In my daily browsing of stackoverflow.com topics, I stumbled across a conversation on ‘coined programming jargon’. The conversation is well on it’s way to go beyond the 8 pages and appears to have started somewhere in or before February. I’m not sure how I managed to miss this one, but the terms coined are quite amusing. I might just have to go and start using them in my projects for when I need a lift.

Here are my personal favorites…

  • Pokemon Exception Handling – For when you just have to catch em all.
  • Yoda Conditions – The act of using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it’s like saying “if blue is the sky” or “if tall is the man”.
  • A Duck – A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.
  • Hindenbug – A catastrophic data destroying bug.
  • Bloombug – A bug that accidentally generates money.
  • Schrödingbug – A problem that some people see when they look and others can’t find at all. Often tied to the execution environment in a surprising way (or a cat).
  • Heisenbug – A computer bug that disappears or alters its characteristics when an attempt is made to study it.
  • Barack Obama – An [account or queue] that we assign our most aspirational tickets. Like stuff we’d really like to do with a project but will probably never get approval for.
  • Fear Driven Development – When project management adds more pressure by firing someone or something else of similiar shock factor.
  • Higgs-Bugson – A hypothetical bug predicted to exist based on a small number of possibly related event log entries and vague anecdotal reports from users, but it is difficult (if not impossible) to reproduce on a dev machine because you don’t really know if it’s there, and if it is there what is causing it.
  • Chunky Salsa – A single critical error or bug that renders an entire system unusable, especially in a production environment.
  • Hooker Code – Code that is problematic and causes application instability (application “goes down” often).
  • Hydra Code – Code that cannot be fixed. Attempts to fix any single bug will causes two new bugs to appear. In the end, it should be rewritten.
  • Ninja Comments – Comments that doesn’t exist in code where someone would normally find them
  • Code Slush – The date after which no changes will be accepted, except of course, all the changes that management will ask for at the last minute. Like Code Freeze but accepting of the fact that some changes will still get in.

Update 9/15/2014: Link is now dead, so it’s just you and me now. If you know about a longer list of these somewhere, let me know.

I thought I might talk about my pre-blogging days of trying to learn PowerShell when I was trying to avoid learning the VBScript language (I don’t care much for the synatic qualities of the language).

I personally love the PowerShell language as I’m familiar with both C# and PHP, and (at least to me) it looks like a bastard child of the two. The creation and intialization of objects or variables are done the same way as in PHP and has the same method and property accessors that you’d come to recognize in C#. It took me about an hour to pick up the basics of the language, but I just needed to learn how to create classes so I could start causing some damage.

Unfortunately one of the lacking items in PowerShell, even after version 2 is the lack of native classes. The strength of the .NET framework has always been behind the PowerShell language, but it’s never been directly accessible unless you’ve built cmdlets that allow you such power, so your reliance on custom classes have required you to compile them using Visual Studio. Until such time comes around, there are at least a couple of workarounds.

I had pinged a few people around Microsoft to see if it might be possible after reading this blog entry regarding the CTP3 release of PowerShell v2 if the method in how one would dynamically compile C# code into an console application could be used in other ways. It evidently wasn’t quite clear from the original post, so James Brundage from the PowerShell team posted this blog entry showing how you can use the same technique to compile C# based classes on the fly in a script. Pretty neat!

If you’re not a blogger, but know PowerShell pretty well, let me know about any hidden or not-so-known tricks in PowerShell that you know of and I can make an entry for you. Credit will be given!