I received an interesting email the other day.  The link was to a Microsoft article announcing an upcoming release of a ‘Cloud Appliance’.  I spoke about how great this would be for the world of computing in a blog post back in February 2009.  I forwarded the article to the folks I work with in Server/Network and they lost their minds.  A system fully capable of abstracting hardware and software!

As someone who works in a heavily regulated industry, and rightfully so in my opinion, this is the best thing to come along since virtualization.  There is no one in my industry that doesn’t recognize the benefits of a cloud based architecture, but new regulations in Healthcare now dictate jail time for certain violations.  I’m less willing to take advantage of the architectural benefits and cost savings if I know there is a real risk of visiting a federal institution of time outs.  Long story short, I’m excited to see Microsoft enter this space. 

More from InformationWeek…

More for Microsoft’s Website…

I came across this great presentation today talking about the challenges of Social Networking and what the next generation might look like.  The presentation is by a guy named Paul Adams who is a UX researcher at Google.

I’m going to tell you the tale of two software shops.  Both shops have incredible Engineers,  great Product Managers and excellent processes.  The only thing that separates these two shops is release night.  One shop knocks out the change in minimal time, the other is working through the weekend to fix issues.  This anomaly has nothing to do with platform choice, complexity of the stack or location.  The problem is universal across all of these.  The difference between these two shops, a release engineer.

Typically a release engineer is a person, or team of people, who are familiar with the build, deployment and configuration of a product.  This is important because one thing I can tell you for sure, your production environment is not exactly the same as your lower environment.  Even more sure is that your production support team has even less knowledge on how to trouble shoot release issues.  You absolutely need someone who is familiar with your configuration.

Unfortunately release engineers are somewhat of a luxury for many shops.  They are an unappreciated component of a successful software shop. If you can’t get the budget to hire one I have a suggestion that has worked for me time and time again.  Appoint one of your developers (and a backup) as the designated release engineer.  This makes on person solely responsible for the success of your pushes. 

There is a cost associated with dedicating on of your developers.  I generally find it amounts to 10 hours a week as the developer builds and defines the process, approximately 6 weeks total.  After that, maybe 1 hour a week to maintain the process.  It sounds like a modest investment, but it will pay off the first time you have 6 developers working all week to make a deployment successful. 

I’ve recently found a site named dzone.com.  Dzone is a lot like Digg.com where you can vote articles up or down based on its merits.  What makes Dzone.com different is that it’s Technologist centric but not biased towards any one technology.  There are articles from Enterprise Architects, UX Designers, Developers, and IT Management (links are sprinkled with all kinds of views).  I have found more interesting articles here than anywhere else. 

It’s a great community and I would highly recommend that any serious technologist book mark this site, read it often, and participate in the voting and discussions.  Not to mention it’s a well designed site.  The Ajax scrolling feature is hot!

Any web developer that’s been around a while remembers the magic of table layouts.  It was part of every tutorial on how to create a website.  The days have changed and now we see a big push for CSS everywhere.  CSS zealots are everywhere, almost as prolific and dedicated as Mac fans!  But is CSS evangelism all it’s cracked up to be?

I recently read a blog post named The shallowness of CSS evangelism.  Clearly titled to get a hair raising out of any CSS fan-boy.  The post was debunking some of the common myths of the CSS vs. Table layout debate put forth in this blog post.  To be honest I’ve been exposed to the ‘CSS is the best way to go’ line for so long that I’ve become to take it as fact.  I’ve clearly broken the unwritten cardinal rule of coding: Keep it Simple Stupid (KISS).    So here comes the wakeup call:

CSS versus tables is another known permathread. It's only recently that the voice in favour of tables layout has improved it's position significantly. Unfortunately the same cannot be said about the rabid pro-CSS group. They continue to spout nonsense and hope no-one looks too deeply at the arguments, and hope enough commenters reply that it couldn't have been said better. Except there is large room for improvement, or perhaps reformulating the argument into something that is backed by real world evidence.

The pro-CSS article lays out 13 ways that CSS trumps table based design.  These are:

1.Faster page loading
2.Lowered hosting costs
3.Redesigns are more efficient
4.Redesigns are less expensive
5.Visual consistency maintained throughout website(s)
6.Better for SEO
7.Accessibility
8.Competitive edge (job security)
9.Quick website-wide updates
10.Easier for teams to maintain (and individuals)
11.Increased usability
12.More complex layouts and designs
13.No spacer gifs

The pro-Table author does a good job to debunk all of these.  The ones that I found questionable that the pro-CSS article even made were: 6) Better for SEO, 11) Increased usability, and 10) Easier for teams to maintain.  The anti-CSS post did a good job debunking, but I would like to add to these three, and who knows, maybe add them to my standard interview questions.

6) Better for SEO

I have no idea how you could even make this argument.  It’s all about the content, and it always has been.  In fact you could make the arguments that, for the most popular search engines it’s all about back links. 

11) Increased Usability

If anything it complicates usability.  Make all the print-friendly arguments you want, but have you tried to keep up with the browser market lately?  Most browsers interpret a table layout the same way.

10) Easier for teams to maintain

I just got this picture in my head of my test automation guy blowing a gasket.  All pages in the site are updated?  One layout change can have a significant impact on other teams.  It’s not trivial and can add risk and time to any project.  I wonder what the project guys at Microsoft, Google, or Amazon would say if some developer ‘easily’ changed some menu layouts!

This is an interesting argument, one in which I agree with the anti-CSS post, we need to have an open dialog before accepting something as fact.  It’s a lesson for me and I hope you can learn from it as well.