Posts

Showing posts from February, 2012

Using Mongoid, MongoHQ, and Heroku

I recently tried to set up mongoid with a free mongohq account on heroku... This info is accurate as of 28 Feb, 2012. For the impatient (I just want to make it work) mongoid.yml production: uri: <%= ENV['MONGOLAB_URI'] %> Gemfile gem 'bson', '1.3.1' gem 'bson_ext', '1.3.1' gem 'mongoid', '2.0.2' For those who want more detail (I have a similar problem, how do I troubleshoot To determine heroku environment variables, do this: $ heroku config and the results should contain a line like what follows: ... MONGOLAB_URI => mongodb://heroku_app928349384:lkfjgoierheourhgoeurhgoeuh@ds031087.mongolab.com:31087/heroku_appapp928349384 ... The important thing to note is what the left hand line says. Around the internet (like here on SO they will incorrectly name the ENV as MONGOHQ_URI. So then update mongoid.yml like this: Additionally, it appears that different versions

Governance Gone Wild

I've written in the past about change control processes and how they relate to agility. Taking things to the next level, there's a bigger issue that needs to be addressed. There are essentially two radically divided camps on what value IT Governance provides for enterprise software. These camps are: #1 the business camp which is tired of hearing excuses about why they are losing millions of dollars of business because IT cannot deliver a solution in a timely manner and #2 The IT camp that is tired of the business camp requesting crazy stuff and causing millions of dollars of unnecessary support costs. Camp #1 thinks governance is an excuse for IT/process wonks to slow things down or foot drag instead of delivering solutions. Camp #2 thinks governance is a way to reign in the business folks who believe that unicorns and pixie dust cause fully configured computers and network infrastructure to magically appear over night. I hope its obvious that both camps are spectacula

Architectural Antipattern: "Through The Looking Glass"

An anti-pattern is a commonly occurring pattern that is ineffective. There is an architectural anti-pattern I like to call "Through the Looking Glass". This is when a system is broken into pieces or layers, but the pieces are cut perpendicular to the direction that the team and the business require. A common example is when a set of screens used to access a database system is split system into "front end" and "back end" components. This "front end" and "back end" split ONLY makes sense if the back end can identify thier required interfaces before the front end is designed. If the "back end" requirements are being driven by the "front end" screens and/or systems, then this split is either #1 wrong or, at a minimum #2 premature. Most often, new systems need a front end to identify APIs that need to be used... it's more economical to build the system in such a ma

The Best Practices Myth

I've found the term "best practices" to typically be a magical incantation that people invoke to use a fictitious third party expert to support their position. When most people say "best practices dictate" they're really just saying "because I said so" and I meet them with extreme skepticism. This is not to say that the idea of "best practices" isn't alluring. Wouldn't it be great if we could simply do things the "best" way and not have to think about what we're doing. In fact, sometimes it might be valid, for example a "best practice" in java is to follow a naming convention. The first letter of classes should be upper case for example. I think this is reasonable, but frankly I'm currently hard pressed to understand WHY. If you're going to recommend best practices, I feel you have an obligation to be able to explain the NEED of the "best practic

people are not interchangeable cogs, they are more like the wind

Great organisations understand that people are not interchangeable cogs, but the wind in their sails. I've struggled to come up with a metaphor that helps explain why command and control processes are so failure prone. In a command and control process, someone (or worse yet a committee) decides "how we're going to do things" and then builds a process to support this idea. Truly degenerate cases will take a step further and try to buy tools and then build their process around their tools. These struggling organisations then spend years try to find the right people or mold people to fit into their process. These organisations have fallen into the trap of thinking that people are just pieces of a giant machine and that once they state their process, they simply need to find the correct pieces and hook them together. The problem wi