If you’ve got a website, then chances are it’s built using a CMS.  You know, WordPress, Orchard, Joomla, DotNetNuke.  Why wouldn’t you?  They let you manage all your content on nice admin screens and PHP, ASP.NET, or whatever serverside technology your CMS is built on will magically and dynamically create your website pages every single time a user hits your page.  It’s one of the many ways the web has become so powerful since the olden days when all websites were just a link or two and a flashing, seizure-inducing banner at the top.

What is a static .html site anyway?

Well, if you didn’t already guess, a static site is the opposite of dynamic.  I’m not saying that nothing on your site moves or it’s bland in some way.  Not at all.  What I mean by static .html sites is that the .html has already been pre-generated and is just laying out on the web server as opposed to all your content being stored in a database to be dynamically mashed together when a request comes by a serverside technology like ASP.NET or PHP.  When my friend, Brian Connatser, first told me about his project Hera, which uses Twitter Bootstrap, Jekyl, Rake, and a few other technologies to pre-generate a static site in seconds, it really got me thinking.  Why would anyone want a static .html site with the options we have today in CMS products?  Why would you go seemingly backwards to the old days of .html?  Here’s what I learned after doing the research: Continue Reading…

In the past, I’ve had managers who have asked me for a daily status report of all of the items I’ve worked on during the day…every single one.  They essentially said if it’s not documented that it didn’t happen.  With all the tools we have available to us as developers, there should never actually be a case where what we code isn’t documented.  I’ve heard many people say that 10 minutes is about the amount of time you should have between source control commits, which means there should be a TON of paper trail to show for what you’re working on.  The problem is how do you show this to non-technical managers?  Do you give them access to source control to see commits?   What if even printing out the commit log is too technical for them?  At bare minimum, they’re likely using some sort of project management tool.  Luckily, today we can connect source control, bug/task trackers, and project management tools together to automate “daily status reports” away forever.  In this video I talk about Microsoft’s Project Server and Team Foundation Server connector that lets you do just that.  Take a look.