Yearly Archives: 2006

Repose

I had the highest hopes, as did we all, for this year. It started with promise, with a houseful of friends over for a black-eyed peas and cornbread dinner I hosted on New Year’s Day, 2006. The humble, earthy flavor of the peas remind us of prosperity through humility.

Springtime brought me a few brief amorous moments; winter thaw, spring hopes, nothing took root, but I didn’t mind. My dry season was over.

July, things went south. I got ill, spent all my time at home alone. One of the hottest, driest summers on record, and my life went cold. When the animal is sick, he seperates himself from the herd to heal. And I healed, physically.

The latter half of 2006 found me on my own, alone. Sure, I’m as much to blame, but there is no motion without desire, no comeradery without kinship, no confiding without confidence. So much I want to say, so much I carry, no one will hear of it. It’s my own weight to bear.

And now I am fully humbled — or humiliated by the demons of my own making — and my prosperity still is not forthcoming.

So on the end of 2006 and the eve of 2007, I stare at my screen, typing the same damned words everyone else says on each new year: may 2007 bring me health, prosperity, and kinship.

Change of Plans

I’m seriously wondering if there will ever be a future for me in technology. My current project, developing a storefront site for a friend of mine, is moving really, really slowly, and it’s all my fault. You see, computers are my hobby; most of my non-work, non-sleeping time is spent at a computer doing god knows what. Sometimes, I even write program code. But when I mix money and heavy expectations in with my love for tech, what I get is cold disdain for the stuff and me not wanting to do much of anything.

The project itself is changing. Previously, we had set forth to write the shopping and catalog system from the ground up. I was planning the database, creating the models, thinking of workflow and interface design, doing what I could to get something usable. But I was moving not fast enough for my client. And there is the rift. What accounts for lead development time is too long for the customer who needs things operational now.

So I’ve completely scrapped the original plans to use Ruby on Rails to build a storefront. Instead, I’m going with an opensource PHP alternative, ZenCart. I know squat about PHP, but what I’m seeing is easy enough to understand somewhat. Nevertheless, the entire solution is prebuilt and usable from the get-go with a little configuration, which is exactly what the customer wants and needs. My plan is to set it up, allow her to add products and categories to her catalog and begin taking orders while I learn the templating system and make changes to the design.

For the paltry price I quoted, I should’ve gone with a prebuilt solution from the start. Now, that’s exactly what I’m going to do. I’ve gotten rid of the prideful righteousness that goes with saying “I completely wrote this”; such mindedness serves me no purpose and does a disservice to my client. Seems I’m finally understanding what the Industry considers a standard dictum: prebuilt is cheap, custom-crafted costs money.

By Air or By Ground, Their Man Will Be Found

An hour ago I stepped outside to empty my trash and check mail when heard a sound I don’t normally hear: that of an aircraft engine revving up and down really close to the apartment. I went out back to investigate and found one of the APD helicopters circling over the neighborhood. Its floodlight was in a sweep-and-search pattern; they’re looking for somebody.

I walked down the block to check it out; got to Chesterfield and saw there was a cop parked, with lights flashing, on each end of the street at North Loop and Koenig. They’re definitely searching for somebody. The cop sitting at Koenig spotlighted me as I was walking away to return to my apartment (and me in my black hoodie, heh). I stopped, turned around, showed my face to the cop; he turned off the light. I waited to see if he was going to bark commands. Nothing. So I slowly and deliberately turned around and walked back home.

A half hour later, the chopper is still circling, taking longer arcs. I could still faintly see the reflections of the lights flashing on the car at Koenig from my place. Hope they find the fool and soon; sleeping might be difficult with a rumbling helicopter overhead.

To hell with protecting the public. Screw all this “enforcement of public law” bullshit. I’ve got to sleep!

Jewels and Stones

So my web design opportunities have slimmed down. That’s to be expected, really. I had two people courting me for help, only one has come through with plans, meetings, and a set of requirements. So, naturally, that is the one I will work on.

I’ve already made a temporary site; it’s mostly in Perl and straight HTML. Got a webmail form, a hard-coded gallery, and a front page set up. The site is mostly served from cgi scripts using templates; each script is specialized to its own page. Boy, do I love Template Toolkit.

After some careful thought, investigation, and simple tests, I decided that Maypole, the Perl Model-View-Controller application framework, though it’s powerful in its own right, had some shortcomings. In one review of Maypole I read, the writer stated that he had a difficult time setting up Maypole to do anything beyond the sample demo applications that are provided in the documentation. I tend to agree with that writer. It’s got promise, but there’s some gnarly details that need to be hammered out before I can do something large-scale with it.

All this talk I’ve made about Maypole being the Perl equivalent of Ruby On Rails, I decided, in one evening of frustration, to actually look into Rails. After reading some docs, installing Ruby, Gem, and Rails, and building some demo applications, I’m kind of sold on the idea. A simple application can be built in one night, a medium one in a few, and a complex one in a few weeks…given I can focus on the task.

Ruby is a strange and foreign language to me, given my history with Perl and Javascript. Everything is an object, like in Javascript, and everything returns something, like in Perl. In Ruby’s case, everything, from constants, to strings, integers, floats, and on up are a subclass of Object, and as such feature a few built-in methods. What most people call methods, Ruby calls messages. You have an object of a certain class, and it has methods that are called with messages like so: someObject.sayHello("Hi There") This is similar in structure to Javascript’s heavy usage of dot notation, but I think the depth stops at one dot. Ruby also has little need of the semicolon to punctuate statements; this I find alien and a little offsetting. They’re really only needed for multiple statements on one line, otherwise the newlines delineate statements.

Perhaps one of Ruby’s greatest strengths, one I’m barely understanding, is its ability to encapsulate blocks of code and store them, and their variables, into persistent chunks to be thrown around as closures, iterators, etcetera. This is where curly braces are most likely to be found. Ruby doesn’t require curly braces around methods, loops, conditions, or anywhere else; those are enclosed by the statement itself and its corresponding end statement.

Rails is programmed in Ruby, and it takes advantage of Ruby’s strengths. Most important to Rails is the class ActiveRecord, which is Ruby’s version of Perl’s venerable Class::DBI module; each object of that class corresponds in some way to a specific record in a specific database table. Coupled with that is a menagerie of other Rails classes such as ActionController and ActionView which round out the triumvirate of the Model-View-Controller paradigm.

Rails is much like Maypole in that it takes only a few real lines of programmer code to make it work. When one creates a Rails application on the command line, Rails builds a generic framework of directories, templates, scripts, tests, and configuration files you can then edit. Once you configure the application to use the database, and have created your tables, you can then ask Rails to create for you a scaffold of classes, templates, and controller methods so you can start manipulating records in the database right off the bat. Once you are done with the generic “CRUD” methods (Create, Retrieve, Update, Delete), you can then replace them with your own custom methods.

As good as all this sounds, what makes me balk about the framework is that, to the uninitiated, Ruby On Rails has some damnable voodoo in it. By this I mean that there are requirements to the way you name your database tables, the fields in those tables, and your application classes; you must conform to certain naming conventions for Rails to automatically see and interact with them, elsewise you’re scratching your head trying to find a way to force Rails to see things your way (which there are ways).

One such naming convention is that your tables must be a plural of what they hold; for instance, you have a table where each record is a “toy”, therefore the table must be named “toys”. Rails has singular-to-plural inflection code built in. Your model must be named “toys”, your application controller class, “toys”, your templates will be in the “toys” directory. Some damnable voodoo indeed! I’ve yet to discover where I can expect Rails to do this, but there are ways to circumvent it, fear not. Most of Rails’ personality is configurable, but doing so makes so much of the automatic things that Rails does fewer and farther between.

So this website I’m building; it’s turning into this smallfry e-commerce storefront with multiple vendors, multiple products, pictures, a blog, a webmail system, back-office report generation, and so on. It gives me trepidation to think what all I have before me. I know I’m not going to get any barebones functionality ready before deadline, but it’s my hope that my client will understand and will be lenient on me. Learning a new language, discovering the powers and caveats of a new framework, trying to handle the things in my personal life…it’s a lot of work.

Choo-Choo to You

I just ordered tickets to Texarkana aboard Amtrak. This is a first for me, the riding Amtrak thing. Leaving Saturday morning at 9:30, arriving at 9pm. Coming back 5:30am a week later on Sunday to arrive home at 7pm. After being a rail afficionado for a lifetime, I finally have the opportunity to ride the rails. I’ve heard it’s classier and more comfortable than Greyhound; I can leave my seat and walk around, and there’s food available onboard. It’s just that in this part of the country, it takes forever to get anywhere.

Amtrak, in Texas, has to share the rails with freight trains, which get priority; Amtrak just leases time and space. So the trips promise to take longer than marked on the schedules. And god help us if there’s a train breakdown somewhere on the tracks, or a train hits a car; that’s at least a 3-hour stop. And nobody can leave the train except at the rail stations. Good thing I don’t smoke anymore.

So I’ll be staying at my cousin’s place, on the couch. Her housemates are night-owls. There’s pets and smoking and alcohol and cold conditions. My mother, who lives in the apartment out back, has promised to let me use her car when necessary; hopefully there won’t be too much inconvenience on either part. This’ll be my first time in Texarkana without the available use of my own car since I moved back from North Carolina in ’98. I’m not used to that level of living, coordinating with others to get around instead of hopping into my car at-will. Get settled in my ways, y’know?

Also, this’ll be the first time I’ve spent a whole week in Texarkana since I moved to Austin. Usually I’m ready to return to the comfort of my own bed after four days, so it’ll be a stretch. I may hate life after the week is over, I may find myself, I may cancel the train reservation and hitchhike back home. I don’t know. Hopefully it’ll go well.

So this is a warning to those of you in Texarkana who are my friends and family (and who still bother to regularly read my mostly-dead journal): I’m coming to Texarkana for the Thanksgiving holiday. Prepare your tables.