As vaguely announced, a few days ago we launched a new project called CodePeek.  While we have our own reasons for this particular project, it was really just a very quickly done project that, by default, was built using the tools that we had available to us and experience with.  One of those tools we picked simply because of familiarity was MogileFS.

MogileFS has always been my default choice whenever I needed to store a lot of data somewhere, without any relational context to that data.  It handles replication, and for the most part just works.  For things like pastes, with the support for images and other media types, it was a reasonable choice.

Except it is just a bit fragile and lacks certain features that we really wanted to have available to us.  I don't want this to be interpreted as being critical of MogileFS because I think it's good software.  However, I do think that it is software that requires more attention than what we wanted to give it and also is not an exact fit for our purposes.

This discussion was happening while we are also exploring various document-based storage engines (commonly referred to as "NoSQL").  This movement has produced CouchDB and, of course, MongoDB (as well as many others).  For us, MongoDB looked like the obvious solution because it supports replication, has an incredibly easy API and was very fast in our tests.

After about an hour of hacking and debugging last night, I had everything working.  I spent 20 minutes this morning writing a migration script and everything has just simply worked.

With a total investment of about 2 hours — including setup, "apt-get install mongodb" wasn't much trouble — we have replicated MongoDB storage (across 2 Linodes), and new storage code.  I'm pretty impressed with the agility in which we can move to replace a storage backend, and believe it is a testament to the quality inherently available when using superior tools, like Moose, Catalyst and DBIx::Class.

Much of my work to date with Cold Hard Code has been for relatively large applications.  These big, complex applications can quickly overwhelm so a lot of time is spent keeping things simple.  Our most recent project, Codepeek, gave me a chance to make something less intense.

The logo came together very fast.  Hoefler & Frere-Jone's Tungsten is CHC's corporate font so it's use was predetermined.  I had it in my head to create something playful, classy and more pop than my usual work.

From jump I knew that I wanted to set the text on an arc. After a few attempts I finally found what I wanted with a negative leading. This gave it a presence that reminded me of an announcer crowing to the crowd: Codepeek has arrived!

The two-tone effect is intentional, providing some clarification for the words.  The name is inspired by the concept of "peeking at code".  My original idea was "peekcode" but the k and c felt like a linguistic train wreck that refused to roll off the tongue.  Codepeek worked much better but was backward from my original concept.  Placing "peek" front and center in bright white balanced the message I was trying to send.  Careful not to forget the "code" I added a strong gradient and some subtle dots that are intended to look like bubbles rising in the code.  Those embellishments can be easily removed and the logo reduced to two colors very easily, fulfilling one of the rules of logo design.

The small leaves set behind the name are decorative fleurons that provide some distinction for an otherwise wordy logo.  It's a purely subjective decoration that I have an odd affinity for.

Codepeek was a great project that Jay and I took from concept to production in just over a week.  It gave me an opportunity to create a light, playful identity that I'm very proud of.