Take part in an exciting and life-enhancing fat-chewing session! Waste valuable time pontificating on thinly-supported opinions!
You may recall my noting that shortly I’ll be performing regular news gathering, mastication, and regurgitation duties for Cinescape, which will require cruising entertainment-industry news sites for valuable lies about upcoming projects et cetera.
Much like speeding through my blogroll, actually. But now I’ll have to pay a bit more attention. Of course, those of you that took longer than most of us to learn how and why one’s shoes must be tied, the importance of good hygiene in attracting a mate, and why it’s better for your monkey-status to shoot some hoops than read a book are thinking: “Hm, I could whip up a robot that could do that in no time flat.”
Well, first, that’s what I’m thinkin’, too, beanie-bros; and second, we’re lying to ourselves.
It will actually take a significant amount of effort.
On the web, as you well know, “a significant amount of effort” means first, we design a database. (Then we screw up and lose all the data, or maybe even the data-structure, but we don’t tell anyone and it’s back together again by morning, maybe even with most of the data)
Then we adjust the design structure to reflect the actual needs of the users (well, ok, the budget doen’t actually include this, but it says right here that we should – it’s those darn suits, holding everybody down again), since we were only imperfectly able to anticipate the data structure needs.
NOW we can work on the robot.
But guess what? That whole swath of mildly amusing geekrant is just bait. Really, it’s like this.
I have to store a great deal of data, daily, for rework and attribution and so forth. There’s a decent CMS (content management system) at the mag which I’ll be using, but they want the finished product, not the raw materials. So that means I need a locally maintained database that allows me to store articles, attribute them (via URL at minimum, but possibly with greater granularity), quickly prioritize and sort, and rewrite. I can keep in mind we’ll eventually be building a little seeker-bot to grab the data as I design the storage structure.
So here’s the question: I have and use FileMaker Pro (uh, I think I’m using an older version – 4.mumble) for most of my quick and dirty database stuff, because of its’ ease of setup and UI rework. Sadly, it’s stuck in OS9 and I’m running it via the Classic environment; which really hasn’t hurt it’s core performance, but for stuff like browser-to-field drag and drop, it’s not ideal. It works fine, though.
See Jane Code! is a small visual dev studio app for PHP and MySQL. PHP and MySQL are coding langidges (and a database server) that help to run bellerophon, the overtaxed, resurrected-from-the-grave G3 laptop which serves these pages to you, my teeming tens and dozens.
Using this tool, or something similar, I can get at least 30% of the design flexibility of FMPro and have another webside app to wave in the face of oh, those many recruiters who so ignore my weekly applications for their jobs.
I prefer an organic, UI-oriented design practice, and when the client is ME, I can indulge myself.
Here’s the turnip soup: Should I stick with old FMPro 4 and take advantage of that flexibility while I fine tune my needs, at the expense of a possibly cool demo project? Or commit to an experiment and set up my data-collector as a web-oriented app from the get go?
I could use FMPro on an interim basis, you know, to get the benefit of the organic evolution; but the interface quirks of going from browser to FMPro are not conducive to data granularity.
I could also buy a new OSX-compatible version of FMPro.
Speak, you nerdly persons in your glasses! Speak! Indulge us with your deep thoughts on the matter!