Website Monitoring

There are a lot of great tools out there for monitoring the status of a website. Who knew Google Docs could be one of them? http://lifehacker.com/5896830/use-google-docs-to-monitor-your-websites-uptime

This is a great solution for those folks with smaller websites and/or day jobs. There are bigger, better, badder tools out there that can better serve (and monitor) the enterprise user, but this will work for me.


RabbitMQ Research

This is more of a TODO: for me than anything else, but I think I'm going to need to play with RabbitMQ in the not-too-distant future. Details can be found here:


It's a message broker, and it can be compared to several tools including BizTalk, Microsoft MQ, and Amazon Simple Queue. More research needs to be done.

I'd rather not...

  1. Be bound to Windows unless absolutely necessary. (It's true, while I'm a .NET developer, and I'd quite prefer my code to stay C# for the time being, I'd rather not be bound to Microsoft Servers. The guys on the Mono teams have gotten good lately...
  2. Use my database engine as a queuing platform. Technically it can be done, but it's not quite an eloquent solution
  3. Ever use BizTalk again.
So, the research begins...


Source Control Rant / Migration Strategy

So we've migrated from TFS to Git at work. For all of you haters out there...

TFS is a competent, capable source control engine. It's a huge step forward from the old VSS, and it shows Microsoft is committed to it's customers. It's got a lot of great capability, and it's great for large teams, but it can be difficult for merging and branching strategies. It's relatively simple, but there's a lot of functionality available to those who seek it.

Git is also a competent, capable source control engine. It's a great new way to look at source control, and it really makes sense as a new evolution in source control. It's got a lot of power, and it handles merging and branching better than TFS. However, it's toolset for Visual Studio lacks, and it's more command-line driven than your average Visual Studio coder.

With that said, if your company is migrating from one to another, you need a strategy. Here are a few thoughts...

  1. A source control engine is just a place to save code. TFS is no better than Git which is no better than SVN which is no better then Mercurial which is no better than... They have their strengths and weaknesses, but it doesn't really matter which one you choose... if it works for you. I'm sick of hearing the "I don't want to learn new commands" or the "ProductX is better than ProductY because I said so" arguments. Buck up and deal with it. 
  2. When migrating from ANY technology to ANY OTHER technology, you need to define comparison documentation. Fully flush out the details before your migration. Here are some samples of what these documents might involve....
    • "In TFS, if you right clicked on your solution and clicked "Get Latest Version", with VisualSVN, you'll right click and select "Update"."
    • "In *ProductX*, if you ran the "Install Grapefruit Command", you will need to perform the following steps in *ProductY*: Click X, Drop Down Y, Button Z."
    • "In *ProductX*, if you ran the "DoWork Command", there is no direct equivelant command in *ProductY*. You'll need to see documentation on *FunctionX*, *FunctionY*, and *FunctionZ* to see similar entries."
  3. Your documentation needs to be collaboratively written by someone who is an expert in the new technology and by someone who has never used the new technology before.
Migrating technology is change, and everyone is frightened by change. We're technology professionals, and it is our jobs to embrace change for the sake of improvement. With that said, it's also our jobs to resist change for the sake of change alone. It does not make any sense to answer a question that no one asked, and that's something that a lot of tech professionals have a problem with (I'm looking at you all of you INTJs out there).

It's also our jobs to minimize the impact of the changes on those who aren't ready for it. And that's something we've historically done very poorly. With a little more communication and direction we can reduce this problem though. Remember, resistance comes when people don't know what or why.

And finally, for my sake, please shut up with the technology pissing matches. I don't care if you prefer Git or TFS, .NET or Java, Android or iOS, and neither do your employers.

P.S. Also, I wanted to share a link to a helpful SVN == Git Crash Course Cheat Sheet. http://git.or.cz/course/svn.html