Two nights ago my vacation started. I've set aside two weeks of time away from work, away from software training and IT consulting. I'll be spending part of it with a friend in Seattle, and the other half at home. You would think that I'd be thrilled for this opportunity to relax, to unwind, to recharge for the next round of professional tasks. You'd think that.

Instead, I'm absolutely dreading it.

Years ago I would spend the days and weeks prior to a vacation imagining what I would do with my reprieve from the working world. I'd often use it as an opportunity to make a push in the development of one of my current projects. If I were lacking an "active" project, I'd start one anew. The end result was to work myself into a blissful creative exhaustion.

Thinking about this, there was really only one time this actually worked. Over a decade ago, after months and months of thought and design, I spent three wonderful days attempting to write a video game. 

It was early in what became a five year effort. At the time I was creating a MYST-clone set in cyberpunk world of virtual reality. I was coding in C++ on MacOS 7. I started with almost nothing, but ended in a small program that would navigate a single stationary node of the game world. It responded to interface events, displayed graphics with special effects. I can't remember if the program was able traverse multiple nodes, but it was certainly an accomplishment with my developing programming skills.

By Monday night of the three day weekend, I was exhausted yet nearly euphoric with success. I was amazed how much I accomplished in those 72 hours. With only a little bit more time, I thought.

I didn't realize how much more I had to do. I hadn't externalized the data in files. It couldn't play integrated video. There was no plot, no story, nothing but a few slides rendered in a consumer-grade 3D modeler. To call it a "game" at this point is quaint, maybe a bit amusing to me today. 

I'm two days into my vacation, and I still haven't decided how to spend my time. Mostly, I've frittered away each day watching videos, surfing the 'net, and wishing I were going back to work tomorrow. Instead, I'm packing a messenger bag and a new carry-on rollaway for a 1300 mile flight tomorrow afternoon. 

And I'm dreading it.

I was wasting time this afternoon after my workout as any internet-addicted tech head would -- by repeatedly clicking the Stumble! link on my browser toolbar. After a few clicks, it came across one of those ubiquitous design sites that frequent my StumpleUpon surfing. 

This one was featuring clever business card ideas. I've seen several pages showcasing similar content before, except that this one gave me an idea. I've toyed at making a business card for DE before, but little ever came of it.

For a while the idea of making a business card for the site seemed silly, even taboo given the audacity of creating such a thing. I often felt I was the only one actively contributing to the site. Today it simply seemed like a neat idea; a clear picture had already formed in my mind.

In the end, I put together four business cards, one for each of the deninet staff members. The "job titles" aren't official, but correspond largely with what I had in mind for Denizen Entertainment in general. I blurred out the email address fields on each card in the above image for the sake of privacy.

You'll notice that each card has a non-standard form factor. Edge-to-edge they are the standard US card size, the unique edge helps it to stand out without being too unique to fit in a standard card case. Site userpics were included on each card to give it a unique personality as well as emphasize the internet-centricity of the organization.

Concept art for my Transgender Day of Rememberence Webcomics Project submission this year.

I have been thinking a great deal lately about what do to about the Idea Database. After the long drive to complete the new Windowlight theme (now up and running on the site), this core feature of deninet 6.0 hasn't received nearly enough attention.

When I originally set out to recreate the system we had under deninet 5.0h and earlier, I'm confronted with two basic strategies. The first is to search throughout the Drupal module repository and attempt to find a solution that would create the necessary facilities to meet the original spec. The second is to write our own module from scratch. I've dabbled in module creation before, but ultimately found the projects I was going to undertake too complex or unnecessary.

Relying on contributed modules does have some serious advantages. Instead of a development process, the effort becomes largely that of configuration. Once the possible methods have been reviewed and compared, the list of possible methods can be reduced to an acceptable solution. After that, it's only a matter of implementation and adjustment to the new features and consequences. I've reviewed a number of modules that could possibly work, but the only one that met expectations was the Node Comments module. 

Node Comments is unique in Drupal as it replaces a bit of functionality provided by the core product. While Core Comments is packaged as a module, it is such an essential component that it is a dependency of several other modules. While this would provide a functionality similar to what I was hoping to achieve for the Idea Database, it affects a larger swath of the site functionality than I would prefer. Taking this option would have some serious drawbacks.

For that reason, I've been investigating creating a module to implement the functionality. How to go about doing that, however, becomes a discussion in of itself. 

The module could be developed in one of two ways. It can be created as an integrated, drop-in solution that would provide everything necessary in order to function. It would be an "Idea Database" module in the truest sense. This has advantages of integration as well as being a contribution to the open source community. It would be easier to implement add-on modules to enhance functionality later (Idea sponsorship and donation). The other method is to write modules only to implement features in a generic way. Instead of an iidb module providing Idea and Thought content types, there would be a "revision review" module that could attach to any CCK type. This would be more generic but would certainly implement the Idea/Thought topology originally drafted in the spec.

There is a line of thought that suggests if something is part of your core business, then you should develop it in-house. You shouldn't trust it to third parties that may not be in line with your vision. The Idea Database is part of what I consider as the core business of deninet. If it's really so important, shouldn't it be written in-house?

The problem, as ever, is time. Developing any sort of module takes a degree of time and effort that I could be putting toward other pursuits such as Paper Girl. With my time and energy limited as they are, I'm concerned that this "simple" module would require a lengthy development cycle.

At the moment, I haven't quite decided what to do. The clock is ticking for this years DOR submission, and I would not want to opt out if at all possible. It may be best for me to let the issue of the Idea database to sit for a while I work on my DOR submission. Perhaps the time away will give me some perspective.