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.

For years, I’ve been dealing with hosting hardware… from my first built-from-parts server under my desk in my San Francisco apartment to my most recent situation as the occupant of a cage in a colocation facility.  In all cases… it sucked.  At the least convenient moment, some component goes south, leaving me with the eternal puzzle “how in the hell am I going to fix that before I get fired.”

I’ve been neck-deep in development for my current client and haven’t much of an opportunity for my own infrastructure, but a new gig has given me pause to consider what, if any, changes I need to make to my situation to improve robustness, flexibility, portability, and total cost of ownership.

I decided it’s time to check out “computing in the cloud.”  (I think I saw that on a billboard or 2,000 on my normal commute to the Bay Area.)  If that idea’s new to you, it boils down to treating your hardware resource needs as abstract commodities that you buy incrementally from a provider, who manages huge physical resources to provide virtual units of processing, storage, etc.

Maybe that’s too obscure.  Think of it this way: you need a web server.  You don’t really want a box, a couple of hard drives, a motherboard, power supply, etc.  You want a web server that you can control and utilize.  Your cloud computing provider says “OK, for $.0X/hour, I’ll make a ’server’ available to you.  You’ll never see it.  It doesn’t actually exist as a physical thing, but you can log in, install stuff, and serve pages.”

That means there’s no power supply to burn out, the disks are redundant (i.e., 10X less likely to fail), and you don’t have anything to throw away when the thing’s obsolete in three months.  In fact, it won’t be, because they’ll just keep adding resources to the pile, and you get your share.  I like the sound of that.

OK, so where’s my data?  If this thing is virtual, my data must BE somewhere?  Well, in the case of Amazon’s Web Services (AWS), you get to decide.  If you want your data to persist between shutdowns (um, yes, you probably do), you need to arrange for persistent storage.  Again, you buy what you need at a few cents per GB.  Now, when you boot this “image” of your server, it can start up on any virtual “instance” of their servers and look exactly the same.  What’s more, you might decide to fire up another server for dev purposes.  Easy, snapshot your image, attach it to another instance, and boot.

Total time: maybe a couple of minutes with a break to get a glass of wine.  Done developing?  Turn it off and toss the storage.  I ran one server for practice for most of a day, and it cost me $.60.

Downsides?  Thus far, I haven’t found too many in comparison to the colo.  Maybe the biggest is that, to keep costs down, you need to apply a bit of discipline to your storage and planning.  In the colo, when in doubt, I can just stick another 1TB drive in there.  That gets pricey in this scenario, but it’s not a very good idea anyway.  It’s the computer equivalent of being a packrat.

More details as I experiment, but so far, I have to say that the colocation business is in deep trouble.

Firstly, let me apologize to anyone who may have left a genuine comment on the site.  The level of spam that I get in comments… is stunning.  Hundreds and hundreds every day.  And those are the ones that the automated filter doesn’t pick up.  The latest thing is to post something innocuous that ALMOST relates to the post… in the hope that I’ll just blindly approve it.

Spammers, call yourselves buzz marketers if you like, but there is a spot in hell with your name on it.

Anyway, I’m sure there were some genuine comments in there.  I just don’t have the time to trawl through them.  I’ll keep looking for a better way to manage that.  Comments are my favorite part of blogging.  This is like having a dinner party, and people keep showing up at the door dressed like the UPS man to say ‘Hi, your house very nice.  I appreciating it all time, dude. Buying V1aGr4 very cheap!!!’  Slam!

Now… on to technojunk!

Due to unforeseen circumstances, I have been thrust back into the world of PHP for a current engagement.  Without going into the pros and cons of PHP (truly, it has both), let’s just say that I’ll be using it.  That being the case, I’ve had to rather quickly decide on a development framework for the app… and boy howdy, are there a bunch of them these days. (continue reading…)

Just a quick note to memorialize a recent client visit during which my use of a MacBook was mocked no less than half a dozen times. The very few times that my regular use of Linux as a desktop operating system was mentioned, it was similarly ridiculed.

And then I was handed the corporate-issue Windows XP laptop. Hm. (continue reading…)

I’m on this organization kick lately.  Long story, but let us just say that I have recently been taking steps to address a bit of a Disorder due to a Deficit in Attention.

Anyway, one of the characteristics of this “disorder” is the inability to throw junk away.  Instead, I *used to* keep it.  It could be broken (as in “garbage”) or semi-functional (as in “garbage”).  Broken stuff would get put away for the day that I’d need the parts or fix it (as in “when hell freezes over”).  Semi-functional stuff would stay out to be used once, frustrate me, and then collect dust until the next time I consider throwing it out.  Use once, frustrate, collect dust.  And repeat.

A variation on this theme is stuff that is completely functional but doesn’t meet my needs or perform at the level I’d like.  I’d had just such a situation with my laser printer and fax machine/scanner.  While they worked OK, they were both starting to lose their quality mojo.  Also, they were separate components and required an additional box to enable them to be put on my wireless network.  The last little annoyance was that the printer did not do full-duplex.  Often, I’d print out long documents, and to save paper, I’d manually divide the job and flip the sheets over.  Eesh. (continue reading…)

Not too long ago, I, Mr. Check-me-out-I’m-so-technical-and-cool, had a catastrophic data loss.  As implied by the use of the word ‘catastrophic’, I lost some stuff that… I did not want to lose.  At all. Lost, lost.  Too bad.  Sucks to be me.  How could this happen to a guy who does this for a living?  I’ll tell you how: procrastination.

I knew that off-site storage was necessary.  I have space on remote servers in secure locations… one of these days, I’m going to figure out a good way to, uh… hey, I gotta go pick up the pizza!

But, it’s worse than that.  I actually have a mirrored-disk, network-attached storage (NAS) box specifically for backups.  I have external drives specifically for making local backups, too.  So, short of my office burning down, I should be covered, no?  Uh… no. (continue reading…)

Let me start by saying that I hate Windows. The Microsoft product. I don’t hate Microsoft. I don’t hate Bill Gates, but I hate, hate, hate Windows. This is not a religious thing, either. I have had that operating system break my spirit more times than I care to think about (and I’ve been at it since… Windows 3.0?). Between the blue screens of death, weird distrustful activation schemes, arbitrary proprietary methodologies, and horrible security record, I just can’t stand the operating system itself. And I’m staring at two copies of Vista on my shelf that I can’t use because they suck. That’s about $600 sitting there. Sucking.

Having said that, I also know that I can’t run everything that I’d like to run in Linux. And as much as I love my MacBook, I don’t think I care to buy all my software over again for the Mac, thank you very much.

No, for better or worse, I’m a Linux guy. Note that I am NOT recommending that ANYONE in their right mind switch to Linux for their desktop. I have a propeller on my beanie the size of a helicopter blade. If you’re starting out and can afford it, go Mac. If you can’t afford that, go Windows 7. If you’re a total geek who sits in his (or her) underwear until three in the morning trying to get a cron job to be able to get a custom kernel to build so you can hook up your old radio-controlled light-switch-remote to your machine… Linux is for you. Now, go take a shower and go to bed. (continue reading…)

Granted, I tend to be a little… extreme… in the oddly setup network scenarios. Still, there are times when I need to make my freaky little combination work with a client’s environment without reconfiguring their network to meet my own needs.

I have a client that has a PPTP-based VPN solution in place. While I prefer a more robust SSL or IPSec VPN– this isn’t about me. That’s what they have, and it works for them. I needed to make my tools work with that situation.

On my end, though, I run a Linux desktop with virtualized (ask me later) instances of client servers or development environments. In this case, I had a Windows XP guest system running, but I needed to be able to access my Linux system as well on their network. So, while Linux’s NetworkManager would happily make a connection to their relatively oldish VPN server device, I couldn’t make another from the XP client at the same time.

What’s more, their VPN server device was having no part of routing my network’s traffic. (Note: I am not specifying the parts involved here because I don’t want to start a ‘you should have done THIS!’ discussion. I’m very much a ‘get it working and move on’ person.)

(continue reading…)

If you’re like me and have more than one machine to worry about, you’ve no doubt tried to remotely access one from the other.  There are times when you just can keep getting up to go over to the other machine just to enter some command or see how something’s running.  Then there are times when one machine is in a colocation closet in San Francisco, and you’re living in, say, Japan, like I was.  Or maybe your mom can’t get the 12:00 to stop blinking on her VCR (and she still has a VCR), and now she’d like you to figure out why “the Internet is broken.” (continue reading…)