Rails is cool.  It’s the framework that I used to code all kinds of nifty AdWords API-based tools for a huge PPC client for many years.  With Rails flexibility and speed of development, I was able to manage millions of dollars, hundreds of thousands of keywords, and a wide diversity of data sources with only a couple of employees to handle the nitty gritty of day-to-day management.  Things were pretty simple then… create some tables, a couple of controllers and the corresponding views, and you had a remarkably powerful web site up in no time.

As of late, though, I’ve been relegated to the relatively, well, primitive? land of PHP.  As a language that started life as some kid’s web page maker and had stuff bolted on over the years to keep it relevant, it does a hell of a job.  Still, it’s kludgey.  I often find myself re-creating complex functionality to get myself back to a more abstracted way of working, which is what I personally prefer.

So, recently, with the impending wrap of my current project, I went back to take a look at the state of the state of Rails.  I must say that I’m a bit concerned.  The way that project is progressing down its philosophically heavy-handed path reminds me very much of how I felt about J2EE a few years back– just about when local and remote references to EJBs started wrecking everything.

None of this is to say that you can’t still do all kinds of neat stuff with Rails, and for that matter, I suspect that one can just ignore all this RESTful, resource-oriented stuff and just make a web site.  On the other hand, the nature of Rails is that once you depart from the common convention, you’ve isolated yourself.  Convention over configuration, donchaknow.

I worked with Rails for years, and my most recent foray into a refresher barely sounded familiar.  Rack?  CSRF?  Datamapper?  Whu?  I guess it’s good that Rails is continuing to progress, but I must say that as someone who qualified as a zealot not too long ago, the esoteric nature of the conversation leaves me feeling like its going the way of so many successful technologies in the past– the priesthood gets so familiar and proud of themselves that they run off leaving the parish wandering around confused.

That is to say, it’s not the introduction of new methods and technologies, it’s the opacity of them.  I did a little reading in some of the discussion areas on the topics, and the conversation was often summarized as: “You don’t get it?  You don’t DESERVE to get it!”  One interesting sideline was the apparently universal outrage over some guy who used a porn site as an example for a talk at a recent conference.  Um… don’t care.

Ah well, I guess I’ll download the most recent PragPub book and see if I can catch up.  Still, I hope this doesn’t end the way I’ve seen these things go in the past wherein the adepts ride their philosophically inscrutable rightness right in to the dirt.

I’m working on a project that uses jQuery.  Now, firstly, jQuery is a remarkable piece of kit, as they say.  As an old-school Web guy, I recall not at all fondly having to kludge up every piece of Javascript to get it to do… anything.  With jQuery, I just drop in the script include and start picking out elements to noodle with.  It almost always works, too, in any recent-issue browser, and I think we’ve all just agreed to stop coddling people who insist on using a 5 year old release.

HOWEVER, I have run into a new thing that points out the danger of all of these pre-packaged kits that are the norm now.  I decided to use Google’s API to call some of their snazzy graphing bits.  These, too, are very cool.  Set up a few data points, some parameters, and bing!  (the sound, not the site), you’ve got a lovely interactive graph!

Unfortunately, there’s *something* in the interaction of the $(document).ready of jQuery and the google.setOnLoadCallback that does not play well together. Load the google code, and the jQuery stops working.  No error.  Nothing.  Just… no jQuery.

Now, at this point, I’ve got jQuery sprinkled liberally all over my site, and so the jQuery.noConflict approach is probably out of the question, since I’d need to go through and replace all the $ references with something else.  I think.  Who knows?  Maybe not.

There’s the problem.  I have no clue what the problem is.  There’s no way to know without hours of googling and trial and error to see what might, possibly, perhaps be the offending conflict.  So… what are my choices?

• Suck it up.  Just accept that the pages that use the Google jsapi bits don’t get jQuery love.  Actually, this might be a reasonable solution given my limited use of the stuff, but it isn’t very intellectually satisfying.
• Go all Google.  My understanding is that I can actually load jQuery via the Google API.  There’s several benefits to doing that including less load on my server, potential caching benefits, and less worrying about versioning.  Still, what just happened there?  I’m stuck with Google?  Aren’t they a private, for-profit corporation?  Didn’t we… uh… wait…
• Pitch Google and go with some other solution.  There are lots of graphing solutions out there.  Again, though, this buys me several hours, at least, of research and retooling of the site.  Besides, then I can’t use their stuff.  I *want* to use their stuff.
• Run away.  Just quit my job and flee.  Get a van and a hippie girl.  Get high and drive down into Mexico.  I speak Spanish pretty well.  I’m pretty handy fixing stuff.  I could probably make a living if I just defaulted on my loans.  Sounds awesome at the moment, but my kids would be sad, and I suspect I’d feel stupid pretty quick.

Sigh.  Ah well, back to it.  I guess it just goes to show you that no matter how much pre-packaged goodness is out there, you still have to know what you’re doing.  Too bad.

Meet the new blog.  Same as the old blog.

Not really.

I find that I get a lot of use out of my own notes (kept in Zim!) and the blogs of other propeller-heads.  I’ve stopped writing in my other blog for the time being for reasons I won’t go into, but I feel the need to write about… something.  There’s two things that I know much about: backyard farming and technology.  I’ve been a computer dork literally since programs were stored on rolls of paper, paper cards, and formatted graph paper looking stuff (RPG FTW!). (continue reading…)