centre{source}

At CentreSource, we have a motto that “outcomes always outweigh the output.”  Through this, we try to focus on meeting the individual goals of our clients, versus focusing on the process of how they get done.  One goal we often hear is that our clients would like an easy way to update the website themselves.  By using a Content Management System (CMS), we enable our clients to accomplish this — without having to install anything on their computers, or know too much about how websites work.

Over the history of CentreSource, we’ve worked hard to choose the perfect CMS to be able to meet the individual needs of each client and project that comes our way.  There was always a balance that had to be struck — it couldn’t be too cookie-cutter, or else we wouldn’t be able to do everything that the client was asking.  Conversely, it wouldn’t be cost efficient if we had to custom build a CMS for our clients each time.  By focusing on the outcome  (the client’s goal of an easy-to-update website), we decided that the best single CMS option was not a single option at all, but instead a “toolbox” approach that would allow us to use the appropriate tool for each unique job.

Last night CentreSource hosted the The Nashville Ruby on Rails / Agile Software Meetup Group for the first time. Presenter Alex Sharp shared a presentation on Test Driven Development (TDD) with Shoulda, a set of helpers that sit on top of the Test::Unit framework. You can see a blog post he made on the subject at his blog.

The group was a good mix of Rails veterans, casual users, and even people who have never used rails. Josh Crews headed the group up and started out with everyone introducing themselves and getting to know each other. Afterwards we had open discussion on topics ranging from Rails skeleton apps like Bort and Suspenders, to ORM implementations in Ruby, to Gems and Plugins like AuthLogic.

Recently, I ran into an issue when building a Symfony plugin for Slideshow renderings.  When I added the support for multiple libraries, in this case Google Slideshow2 and JQuery Cycle, they had drastically different configuration options.  JQuery Cycle allows you to use a list of effects, such as blindX and blindY.  These effects are great, and I want the end user to be able to easily select between them.  Google Slideshow2 allows the adding of thumbnails and traversing controls.  Neither of these settings apply to the other, and this is only two slideshow renderers.  What happens when I add another one?  Five more?  I could create multiple tables for each renderer, such as google_slideshow2_options and jquery_cycle_options.  I could also just provide a textarea for key-value pairs (effect=blindX timeout=500) that the user typed in.  I did not like either of these options, as the former struck me as over-architecting, and the latter as unusable.

It’s been an interesting year at CentreSource. Our focus this year has been mostly internal — we’ve been honing our internal processes and working closely with our now 20-person team to make our day-to-day as efficient as possible. We’re also learning from each other: we spend every day in peer meetings as a means to cross train each other and make sure that all the knowledge we’re gathering from every new client experience is shared with the team. In effect, we continue to raise our own bar every day — something that’s easy to say but harder to do, because the more the bar raises, the more we expect from ourselves.