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.