In early 2006 Paul Hurley (ideeli’s CEO) and I (Mark Uhrmacher, CTO) were thinking about a new business. We had the idea to create a community based around great deals for Women’s fashion products where we saw a great deal of potential for great content and product sales. Now, over five years later, we’ve realized much of that vision. Our business success has been chronicled over the years in several places (see here and here). Though we’re very proud of our achievements there, that isn’t what this blog is about.

Insatiable Demand is about a mostly untold story. Over the past five-plus years we’ve built a phenomenal technology platform and team. From two people and three servers to a 70 person team and a 100 instance production environment, …

It’s been some time now that we’ve been talking about devops, the pushing together of application development and application deployment via IT operations, in the enterprise. To keep up to speed on the trend, 451 CAOS attended PuppetConf, a conference for the Puppet Labs community of IT administrators, developers and industry leaders around the open source Puppet server configuration and automation software. One thing that seems clear, given the talk about agile development and operations, cloud computing, business and culture, our definition of devops continues to be accurate.

Another consistent part of devops that also emerged at PuppetConf last week was the way it tends to introduce additional stakeholders beyond software developers and IT …

The goals of the project are basically

• Modularity. Make it easier to add new features without breaking existing ones.
• Pluggability. Make it easier for third parties to add functionality.
• …

The goals of the project are basically

• Modularity. Make it easier to add new features without breaking existing ones.
• Pluggability. Make it easier for third parties to add functionality.
• …

The goals of the project are basically

• Modularity. Make it easier to add new features without breaking existing ones.
• Pluggability. Make it easier for third parties to add functionality.
• …

Whenever we are faced with a choice between two designs, and the first design is upward compatible with the second (i.e. the first design is more restrictive, and implementing design two would not affect functionality provided by design one), and the full impliciations of the second design are not yet known, the first design choice is recommended.
Formulated by C.J. Date in "Relational Database: Writings 1989-1991"