Josh Benner

Any Drupal developer worth his salt at least knows of the Views module. The shear usefulness and time-saving nature of views has earned the module a place in every Drupal site I've developed. However, because views are stored in the database and their presentation is controlled by the views module itself, managing views between staging/live sites, handling updates, and tracking revisions become difficult issues when dealing with Views.

A few weeks ago I read a brief but interesting article by Jeff Whatcott on Getting Ecto Set Up with Drupal. I had heard of Ecto in passing but had never really looked into using it. With all the hubbub around WYSIWYG tools for Drupal and the like recently, I wondered if a good desktop application would be a viable solution, so I figured I'd give Ecto a try for myself.

After the first day of having the new Mac and playing with iChat, it was time to hunker down and start accomplishing things with the Mac. In the last few years one of the biggest reasons I've been reluctant to get a Mac has been a sense (whether justified or not) that the software selection wouldn't be sufficient for my wants, needs, and tastes. Part of my recent decision to get the Mac was the general feeling that this was no longer the case. I've found this to be true.

I spend a lot of time on my computers. Most of that time is spent using or writing web pages and web applications (and the occasional video game). Web development isn't what it used to be, and tackling everything requires a lot of tools. I'll summarize my needs and the tools that I've settled on using to meet them.

People often ask me how or when I started working with computers, programming, etc. My answers usually hark back to my childhood and my first ventures with my parents' Macintosh Plus, then our family Performa, and my Powerbooks 180c and 540c. Basically, all of my earlier computer encounters were on a Mac, from learning to type to learning my first programming language to discovering the internet for the first time.
Sometime during the late 90s I became frustrated and angry with working in a Mac world and I "converted" to my first Windows machine, vowing to never look back. Since that day I've been working primarily in Windows and Linux, only touching a Macintosh when absolutely necessary... that is, until this last week.

A few months ago the primary project to which I'm assigned espoused an Agile/XP approach for development... well, a heavily modified Agile/XP approach as there is only one developer (me) working on features/tasks/etc that come from a team of people, funneled through a project manager of sorts before they get to me. Because of the unique relationship we've enjoyed with the client, managing the project has been an interesting challenge since client users are involved closely with the project and are sometimes responsible for tasks such as testing.

We've moved between a few task tracking/project management systems in the process, trying to find software that fit our needs, the latest of which is VersionOne. The client actually came across VersionOne, which I'd only heard of in passing before that point, and asked if it would be a viable system to use during development. After a quick glance by several of our team members, we agreed that the system looked pretty good and was unique in that it was designed with Agile in mind so it supported the Agile/XP workflow in a manner than other ticketing systems didn't. So, over the course of a couple days we migrated to VersionOne and started using it.

A friend of mine has been using CakePHP to solve some problems where he works lately, and has been asking me for some help here and there. I always love to help as much as I can, but lately I've found my advice when it comes to CakePHP to be less helpful than it was in the past.

Over the last couple months I've been hearing the term "Technical Debt" get thrown around frequently, describing the effect that results when decisions are made in a project or process that cause problems down the line.

As any good developer will tell you, there are usually more than one way to solve the problem. Once you've narrowed down your options to a few viable courses of action, it's usually the fastest or cheapest that gets chosen. I'm not here to say this is an incorrect way to choose between good options, but I'd say that when we're planning the development of a project, or even just a feature, we ought to also say to ourselves, "Which approach will leave us with the least technical debt?"

The problem is that this isn't an easy question to answer, because we don't always know what new technology, approach, service, or totally different alternative is coming down the road. So what seems like the best idea today may be what we lose sleep over a year from now. What are our options, then?

I felt like having technical blog entries next to personal picture galleries and such a little out of place. That plus the fact that http://bennerweb.com was the first Drupal site I ever set up... I felt I needed to move to some new digs... with every intention of posting more regularly with technical and non-technical articles alike.

I recently presented at an event where several web application frameworks were discussed, including Drupal. Around that time I was also working on several projects written as Drupal modules at a level that I had not done before. These series of events caused me to take a step back and consider Drupal's merit as a web application framework.

This post is in reply to a comment on a previous article that I thought contained some good questions: