Why am I talking about this? Well, after a couple of months of minor spam comment postings, my little blog fell under attack in the last day with dozens of bogus comments advertising all kinds of gambling services. Most got flagged as needing moderation but a lot still made it through and needed to be manually gotten rid of. If you’ve seen the commenting area of a post, you’ll notice I’ve been using reCAPTCHA to help prevent spamming. Since it’s turned out not to be an end-all solution, I started to look at alternatives.

First step was to straight away ban the most common IP addresses. Current WordPress versions have this as an option. Since the traffic and number of comments is very light, I don’t think there’ll be much collateral damage to legitimate posters. It’s also possible to alter the .htaccess file to totally deny access but that felt to be a bit much since I’m not really under a heavy attack. As a longer term solution I’m looking to see what other options are out there. A couple of notable are Spam Karma 2, Peter’s Custom Anti-Spam Image Plugin and Bad Behavior. Depending on how effective updating to the latest reCAPTCHA and just blocking annoying IP addresses turn out to be, I’ll take a look at these solutions.

Thanks to a posting on Jammed for some of these plugin pointers.

I really need to put more time into this as I’d like to get it up and running in time for field use at WonderCon next month.

I ultimately decided to just go with CakePHP. For the reasons listed before, it ended up making to most sense based on what I’ve already had experienced with and what seemed to be installed by default with my ISP. I just followed the Cake Blog Tutorial, recasting blog postings into comic book titles with the appropriate field changes. Some retyping of code and minor editing of values and voila! a complete web application was born.

As I explained previously, my comic database has been more or less unchanged for the past two decades. While I introduced some relational aspects in the last few years by tracking individual issues (sometimes) along with the titles, my main use has been just to catalog issue numbers. To support my comic logging activities, I just need the following features:

• add, edit & delete a comic title
• browse all the comic titles
• browse only the “active” titles, those that I’m currently most interested in
• search for a specific title, generally based on the comic title’s name

Since I routinely see people at conventions doing similar activities with hand written lists or printouts, there isn’t much more that’s need. Of course in the future I’ll get fancy with issue specific data and tweak the interface with AJAX features or optimized for mobile device viewing, but that’s for another time.

Such a simple requirements meant my schema could be pretty simple:

title VARCHAR(128) UNIQUE,
publisher VARCHAR(64),
time_frame VARCHAR(64),
series_type ENUM('limited','maxi','one-shot','normal'),
main_issues TEXT,
annuals TEXT,
specials TEXT,
missing_issues TEXT,
comments TEXT,
is_active BOOLEAN,
is_complete BOOLEAN,
is_subscribed BOOLEAN


There are of course other columns for tracking and maintenance of titles, but this gives the basic idea of a comic title’s structure. With a table based on this schema added to a little MySQL database, it was relatively painless to stitch together basic CRUD operations using CakePHP’s MVC approach and sample code. Afterwards, I easily added in some other functionality like a dedicated link that filtered out everything except comics marked as active. Getting more daring with my increasing confidence, I dropped in pagination support and even filter functionality. I thought I’d be slogging through data dumps to the browser and looking at SQL queries executed throughout the weekend but, given it was so trivial, it more or less worked without much debugging. I had a few problems because I didn’t read method and function documentation and didn’t realize from the error message that some calls were expecting an array but just receiving a single object. Easily corrected with a quick print_r call.

All in all it really was as easy as cake. Next on my agenda is to tweak the UI and perform some more serious testing with larger data sets.

I have a lot of comic books… when I stopped counting years ago I must’ve had around 3,000 by estimate. With many short boxes added in the last few years, the count should be over 3,500, maybe even 4,000. Since I’ve long stopped remembering comics by issue number or cover, I’ve turned to databases over the years to keep everything organized.

My first database was a card filing application call Atari Home Filing Manager on my Atari 800. It used a 3″x5″ index card metaphor and I entered a series on each line with issues numbers following. When my mom took me to comic conventions, I printed out the files and took a hard copy with me.

When I was in junior high, I got more serious and used Timeworks’ Data Manager on my Atari ST. I could dedicate whole records to a comic and set up the basic fields for information like title, publisher, issues owned, notable mission issues and so forth. As a side note, I really liked all of Timeworks software and used their Word Writer word processor into high school until I made the jump to Windows 3.0. The New York Times has an old article on Atari computers which mentions Timeworks.

My longest lasting database choice has been FileMaker Pro, starting with FileMaker Pro v2. I made a couple of updates over the years before settling on FileMaker Pro v6. One benefit of using FileMaker has been the availability of a Palm OS client, which I’ve used on various Palm compatible devices the last few years. My standard operating procedure has been to sync up my active comic list with my CLIE UX50 before attending a convention, make updates as new comics are added and then sync back. It works pretty well… except that it usually doesn’t remember who the FileMaker user name is requiring a reset before synchronizing. Since I’ve waited so long, upgrading pricing isn’t available but moving to a new version is a requirement if I were to get a more modern Palm. Since I’m undecided (or maybe slightly decided against) getting a new Palm, Treo or Centro, I’ve been looking at alternatives that would work with other devices.

There is comic book management software for the Mac OS. Many like xidiar Comics is issue oriented and not series oriented. This means I have to individually enter in each issue. If I was so inclined it’s actually a really nice piece of software with fields for every detail one needs on an issue. It’s also got a nice Mac-feeling UI. But there doesn’t seem to be any way to import / export the data. Others like Books are more flexible but also single issues / book oriented. And apps like Collectorz Comic Collector sound like they’d work but don’t have a Mac OS version. Gah!

Now I’m thinking just to write my own using MySQL with a PHP frontend. I’ve done some “hello world” PHP applications and there’s no shortage of PHP and MySQL how-to’s available. My database needs are simple. I can start with a flat table and expand to add a per issue table later on, which is how my FileMaker database is. One problem with most of the other solutions is that there’s no easy way to host on my provider, just import and export of data. With MySQL, it’s easy enough to create the tables on my hosting provider’s server and have them run there. With my database publicly available, I don’t need to sync with a handheld device. Of course… my next handheld device would need a readily available network connection to be useful. And, I’d have to figure out a solution if I wanted to have multiple copies of the database available, one on my laptop when I’m on the go and unconnected and one on the web where I can access it. Those discussions are for another time.