As software developers, we're always looking for ways to write efficient code. Well, this probably isn't one of those examples, but it's a useful little hack that saves time writing conditional statements for dynamic queries:

The problem

You need to write a query with multiple constraints (WHERE clauses) but not all variables are available all the time and you want to keep your AND statements simple.

These are two of my favorite topics: open-source software and real options!

I was sifting through my Time Capsule and found a deck I used several times for high-level discussions about strategy for an IT transformation to (mostly) open-source investments. Truth is, it can be applied to just about any transformation project. The full deck is attached at the bottom of this post, but here are the basics:

The problem....
Research and experience point to Open­Source as a disruptive trend in competitive cost structure, but the transformation costs and benefits are uncertain.

This one gave us fits for days because we were troubleshooting in the wrong manner.  This error generally is not caught by a Rails application because it happens as data is transported between the data storage layer (in our case MySQL) and Rails itself.  So its outside the scope of your application error handling.  This results in a rough experience for users of a web application who see nothing but a white screen with un-style text "Application error (Rails)".  Dead end for them!

What causes the error?

A recent (and currently active) project brings to mind the need for thoughtful transition architectures.  Our development team is installing [gasp] a web content management tool.  In the long run, I have no doubt it's the right move for our group and I advocated enthusiastically on its behalf.  The gasp is because it represents a paradigm shift for our technology stack insofar as the WCM is a commercial open-source J2EE application that is replacing an open-source Rails cms-- and don't hold that against us, we love Rails and continue to use it in many applications.  We just

This should be a familiar topic to most anybody who reads even a few articles a week.  IE6 quirks continue to be a major headache in designing cross-browser compatible web applications.  It takes up a disproportionate amount of time among my QA team relative to the percentage of lingering users.  And I bet the same is true for your organization.  The unfortunate truth beyond the QA sink hole is that IE6 will continue to limit our  innovation process until it dies, or we decide not support it.  The former is not under my control, so I took a quick look at the latte