I may be giving too much credit to Mike Stackpole, Rick Loomis and the rest of the crew at Flying Buffalo for inventing the genre, but I give them credit for coming up with an interesting way of bringing interactivity to paper.

Creative as it was, the resulting stories were difficult to read. I had to stop every few sentences to turn pages, and jumping around through the book like a peripatetic kangaroo kept me from getting involved in the story itself, kept me all too aware of the medium rather than the message.

Yet how many of us today follow this noble, but failed, experiment when writing our code?

We begin writing our methods with the best of intentions. We lay out the opening scene (the arguments) and launch into the gripping tale of what is happening to them.

Yet only a few lines into the story, we stop. We interrupt the narrative flow in order to make a decision and send the reader off to somewhere else, with no regard for what is happening in the main storyline.

It might be something simple. We might break the reader’s concentration with something like:

id = params[:id].nil? ? 1 : params[:id]
Model.find(id)

Not only that, but if you wanted to be sure you weren’t getting slipped something troubling, you’d also have to check to see if what you were handed as the id actually is a numeric, and if not, handle that separately. It may be a small thing, but it distracts the reader (and ourselves) from the main point of the adventure, which is what we’re about to do with that id.

But we have to be sure there’s something both safe and useful in that id before we use it, I hear you say? Of course we do. It’s just there’s a better, more reader-friendly, way to word that. A way that will do less to distract our reader from our main plot.

If we use the fetch() method instead of simply [] to get the value, we can specify a default to use if the index is unset. This means we’ll get a real value back, no matter what, and won’t have to test for Nil and do any conditional branching to handle it as a special case.

Adding the .to_i method at the end of that (something we couldn’t do so long as the possibility of getting a Nil remained) will make the received value safer to use, by returning zero (a number) if the id value is anything but a number, which means the find method will always have a parameter it can work with, so we can drop it directly into the find:

Model.find(params.fetch(:id, 1).to_i)

This single line pulls from the model by id, supplies a default value of 1 if the id has not been given, and makes sure the given id is in fact a number, returning a zero if it isn’t.

By doing this we’ve handled the problems of Nil and non-numeric input at the same time, so we can guarantee the model will get a type of input it can use; failure in finding the zero id (the result of trying a non-numeric id) can be handled exactly the same as any failure to find an id not present in the database.

Look at your own code, this time realizing you’re telling the story of what happens to the data it encounters. Remember, the code you write today will be read tomorrow, either by yourself or someone else. Use good storytelling techniques to make that easier.

Tell the story of your code clearly, keeping digressions like error handling out if the main narrative flow as much as possible. Keep the main purpose of the code in a smooth unified narrative flow, so as not to confuse your reader. Your reader (who might also be yourself at some future date) will thank you for it.

And so will your code.

The issue with the ruby install is subtle, and doesn’t really show up until long after you have installed it. The issue is it points the gem repository to the wrong place. It points the gem repository to /usr/local/lib/ruby/gems/1.8 which is where the 1.8 gems should reside, not the 1.9 gems.

The ruby 1.9 gems should reside at /usr/local/lib/ruby/gems/1.9. And the default install doesn’t set that up. A sure way to make that happen is to put:

RUBY_DEFAULT_VER=1.9

in the /etc/make.conf file. It’s possible that adding the “-E RUBY_DEFAULT_VER=1.9″ flag on the make command will do the same thing, but I found the make.conf change worked, so I stopped at that point.

Make that change before you install ruby19 from the ports:

cd /usr/ports/lang/ruby19
make install clean

After that, the gems will install in the right location and everything will be work the way it’s supposed.

Nginx

The regular ports install for Nginx, on the other hand, is defective from the get-go. While the ruby issue is a subtle one that may not even pose a problem in some circumstances, the ningx issue will prevent the server from responding to any control scripts.

The issue here is the default configuration script points the .pid file to the wrong location. In the default nginx.conf file installed by the ports system is the line:

pid logs/nginx.pid;

This means the control scripts will not be able to find the nginx.pid file in order to send it signals. Instead the line needs to read:

pid /var/run/nginx.pid;

This will locate the nginx.pid file where the control scripts can find it, and everything will work.

Rails isn’t always an easy proposition on Dreamhost, and this was no exception. BTW, this is *not* the rvm version. I wanted to get the Dreamhost default setup working before I started playing with rvm. I’ll probably post an rvm-related set of instructions later.

In this case, I wanted to move some sites over to NginX as a trial, because the apache/passenger combination had been seeming rather slow and memory-intensive of late. I wanted to see how much time and RAM NginX would save me.

The first bits were simple. Setting up the VPS using the Dreamhost CP went easily, then came time to configure it. The settings are pretty much self-explanatory, as you can see. The idea is to select the NginX web server, then turn mod_php off. (I did the latter just because I’m anal-retentive: mod_php is an apache module, so it wouldn’t work with NginX anyway. But even if it did, I wouldn’t want it; I want to run PHP as a fastCGI/FPM process, anyway.)

Setting those gives you the basic setup for the domain. Unfortunately, that in itself isn’t enough to get the default Rails setup on Dreamhost (Rails 3.0.3 at the time of this writing) working properly. The fun starts now.

After

rails new appname --database=mysql
bundle install

builds the rails app, but there are more issues to come. The first is that Passenger doesn’t find the bundler to load. This is because it’s not looking for it (and, by extension, all your site’s gems) in the right place.

I recommend covering this in a couple of places, because this is something that will end up biting you again and again if you don’t. So, first, in the .bashrc file of your home directory you’ll want:

export GEM_HOME="$HOME/.gems/"
export GEM_PATH="$GEM_HOME:/usr/lib/ruby/gems/1.8"
export PATH="$HOME/bin:$HOME/.gems/bin:$PATH"


This will make sure your deployment tools, like capistrano, will see the gems. The ‘/user/lib/ruby/gems/1.8′ path is the default path Dreamhost is storing its own set of gems. You should check to ensure that’s where it is on your system, and if it’s different change it to whatever it is on your site.

Then you need to do something similar in /config/setup_load_paths.rb (you’ll need to create the file yourself, it’s not in the standard Rails 3.0.3 setup):

ENV['GEM_HOME']='/home/username/.gems'
# You can also set GEM_PATH if needed
ENV['GEM_PATH']="#{ENV['GEM_HOME']}:/usr/lib/ruby/gems/1.8"

You need it here, so that Rack can find the gems; it loads before Rails, after all, so putting them in the Rails config area wouldn’t help.

You’re probably not done yet. There’s another bug waiting to bite you in your Gemfile. I built this Rails app for mySQL, remember? This line:

gem 'mysql2'

was put in the Gemfile by Rails as a default. It resulted (in my case) in bundler using the Dreamhost-supplied mysql2-0.3.7 gem. And you’ll probably trigger an ActiveRecord error with that, along the lines of “this version of mySQL2 doesn’t ship with the ActiveRecord adapter.” Oops.

The solution is to drop back to a previous version of the mysql2 adapter for this, by changing the mysql2 line in your Gemfile to be

gem 'mysql2', '< 0.3'

That tells bundler you want one earlier than 0.3. I've seen it work with 0.2.7 and 0.2.13, so it doesn't seem to be too picky. It may even work with later ones than that; all I can say is I know 0.3.7 doesn't work with it.

That was the extra work it took me up front to get just a vanilla Rails install functioning on Dreamhost VPS. Hope it saves someone else the hours of searching and trial and error I spent getting it to work.

And Of Course Apache Is Different

It can't be so simple as to be the same changes with both. With apache, you need to place the gem path code at the top of config.ru:

ENV['GEM_HOME']='/home/demorails/.gems'
# You can also set GEM_PATH if needed
ENV['GEM_PATH']="#{ENV['GEM_HOME']}:/usr/lib/ruby/gems/1.8"

and it doesn’t need the setup_load_paths.rb file to be present.

Of course, you can always put the path code in both places. Having the setup_load_paths.rb file doesn’t seem to disturb apache and the extra code in config.ru doesn’t bother NginX. It’s not DRY, no, but it’s also not something that will be changing very often, if at all, so I can live with it.

Credits

• David Liu
• Trinitronix

It is at once both the easiest, and the hardest, stunt to perform. The key is, it’s not a stunt. You can’t fake it, you can’t call it up on demand for any little thing you’re trying to sell.

It’s passion.

Passion needs a specific target. You can be an effective salesperson with a passion for selling, but unless you have a passion for what you’re selling, you can’t change reality.

And you can’t simulate passion effectively, not in the amounts a functioning Reality Distortion Field consumes. You might be able to bend it for one person for a brief time, but that’s not distorting reality, that’s simple persuasion.

It’s not an intellectual thing; you can’t use numbers and figures to produce it. They stimulate the wrong side of the brain. That side specializes in reality; in the cold dispassionate analysis of hard facts. It’s true you can bamboozle with figures (Mark Twain once wrote ‘Figures don’t lie, but Liars can figure’) but again, that’s not really distorting reality.

But passion, genuinely felt and genuinely expressed, makes its way into our emotions, into that place where numbers can’t reach — unless you’re a member of that minority whose real passion is for numbers.

Passion is contagious. You’ve felt it, any time you’ve been among passionate people. Expressed clumsily, it can be off-putting. But smooth out the expression of it, purify it, let it drip over your words as they come out, and it becomes a hundred times more contagious than any virus.

You want to distort reality like a pro? The first step is the easiest; find what you’re passionate about. You can’t assign this sort of passion by an act of will; you can’t become really passionate about just anything. You’re not wired that way.

But somewhere, there is something to excite those passions within you. It’s got to be honestly felt. It has to exist. You can’t manufacture it, you can only refine it. Find your passion and trust it, you’ll know it when you see it, and nurse that passion. Smooth it out, refine it until it becomes stronger than any steel.

And while you’re refining it, learn to wield it. This takes practice, like anything else, and you’ll fail. Don’t worry about that. It even happened to Jobs himself, on occasion. Learn from it and continue. Keep at it.

Archimedes once wrote, “Give me a lever long enough and a place to stand, and I can move the world.” Your lever is your passion, refined until it cannot break. The target of this passion is where you stand.

Go ahead, start moving us.

I even hear Apple and Steve Jobs positioned as wanting to “destroy the web” with their focus on “native apps.” That their “focus on native apps” is “splintering the web.”

Now that I’ve laughed myself silly at the irony, it’s time to take a closer look at the facts in the case. But before we do so, some full disclosure. I use more than one Apple product. I also build Windows machines from parts for my church, contribute to Open Source projects, and run Ubuntu as well as Windows 7 and OSX in my house (in fact, there are more Windows licenses than OSX licenses around here). My prime work is done on OSX, not because it’s perfect, but because it and I get along better than Windows or Ubuntu and I. If that changes, I’ll have no compunction about switching. My computer is a tool, and like any competent workman I use the tool that fits my hand best.

So let’s turn back the pages of time and look at the iPhone launch. A note from Chris Zeigler on Engadget from that time says Apple was encouraging developers to code web apps and download them from their own servers. If Chris’s word isn’t good enough for you, here’s an official Apple press release: that says the same thing. Apple even set up a directory specifically to point to those web apps.

But the devs in Apple’s customer base clamored for the ability to write native apps, so Apple shipped an SDK, and created the AppStore to distribute those apps. No, not out of the goodness of their hearts. Of course they knew they would make money off it.

But note the chronology, here. Apple intended, even encouraged, devs to write web apps that could be hosted on their (the devs’) servers, uncontrolled by Apple. In short, Apple was pushing open web access on Day One of the iPhone launch. And, so far as I can tell, has never backed off that.

So go ahead and build web apps. It’s fun, the technology is open to all, you can build and ship what you like and keep all the money for yourself, if you wish. Just don’t say you’re “circumventing Apple’s iron control” when you do it. Have the integrity to say you’re taking Steve Jobs advice for how to develop for the iPhone, because that’s really what you’re doing.

As with most TV shows, they drive through the setup so hard and fast you don’t have time to care much about anything. The 22nd century is Blade Runner Time, loving cop fathers one too many kids, gets tossed in the slammer. Loving wife is doctor, skill wanted desperately at Terra Nova (more later) so is recruited, but can only take two kids, and must leave husband in jail. Do I really need to explain what happens next?

Let’s jump past the completely unbelievable escape sequence and get to Terra Nova, shall we? Someone discovered a fracture in time and space. They didn’t know where and when it led to so they sent a probe through, and then looked for its signal. With an arrogance only a TV “scientist” could muster, they concluded that since the probe signal didn’t turn up anywhere it must represent an alternate time stream (the alternate time stream thingummy is required to get around the Butterfly Effect, and if you don’t know what that is, you need to find a copy of Ray Bradbury’s The Sound Of Thunder and read it, like now).

So the where of Terra Nova is an alternate timeline of Earth, roughly 85 million years ago (no explanation of how they determined that, as well; after all, an alternate timeline means there may be no end to divergences from anything we know about our past). The who is the standard family set of loving parents, rebellious but sensitive teenage boy, awkward nerdy teenage girl, fearless five year old innocent girl. Boy leaves love of his life behind (of course) and finds a new love interest (of course). Encouraged by New Crowd, boy breaks rules.

Which sets up the family tension, because, you see, father, being an ex-cop does what every ex-cop would do, leaves his agricultural duties behind to follow Man With A Gun, and long story short (too late) gets hired on as Security.

What we’re looking at here is Jurassic Park (hi there, Mr. Spielberg, executive producer) meets Lost. Oh, and we can’t go away without a mention of the Bad Guys. They’re called “sixers,” not because they played basketball in Philadelphia, but because they came in as part of the Sixth Migration, and seem intent on taking over Terra Nova.

If I’ve seemed snarky it’s because this is so standard, so trite, that it begs for it. But then, that’s so for a lot of television shows at the beginning; television, it seems, always selects its starting characters “off the rack.” What counts is where they go from here.

The object of a pilot is to set up the board for the rest of the season; to show the players and get them in place, and provide enough to hook you into coming back next week so we can see what they will do, now they are in position.

What will keep me coming back is how unpredictable they are, or (failing that) how much they make me enjoy a ride in familiar territory. Spielberg, at least, is a master of that. The credits for the rest of the executive producer lot (Castle, The 4400, 24) is spotty. Castle is saved by Nathan Fillion’s grown-up little boy (I’d call it an act, but I know better), the 4400 had a good season or two, then ran out of steam, and 24 wasn’t tolerable after the middle of the second season.

My expectations (after seeing the first hour of the two-hour pilot) are that the Commander has a spy among the sixers, the sixers are attempting to get rid of the dictatorial, even tyrannical, government of Terra Nova and set up something blissfully democratic. Good Cop Dad will find some disturbing things, probably someone playing games with the food supply, that will make him start to question. The boy will hate his father until near the middle of the season (for daring to let himself be put in prison for trying to protect his illegally large family) but honestly, the longer they let that go on, the less likely I’m going to stay around. Maybe it’s my age, but overblown teenage angst makes me more and more twitchy.

So yes, I mean to imply I’ll be watching, at least the early part of the season. I want to see real people grow out of these cardboard cutouts they’ve been parading around in front of me. I want to see the older girl’s knowledge get used for something besides making herself blush. (Honestly, I’m sooo tired of the sexist tripe that makes her embarrassed by how smart she is, I almost hit the back button on the browser. Cut it out, you cretinous writers!) But I’d better see signs of life soon.

It’s fashionable to rate things like this with numbers, so I’m not going to. Instead I’m simply going to say that Terra Nova is starting out in a hole, burdened with ideas and characters that haven’t been new for a half-century or more, but it has enough potential that I’m willing to invest a few more hours in it waiting to see something of that potential realized. I’ll give it chance to either surprise me or make me care (I almost care about dad and older girl right now; doctor mom lost me when she just pulled a leech-like thing another doctor had placed on a man off his back without knowing anything about it, including what it was, let alone the proper way of removing it).

But seriously, television, science fiction is the literature of ideas. It’d help to have a few before you try this again, OK?

Still, I’m fairly nervous about it, and the why of that didn’t become clear until the train ride home from Reno, when I had time to think.

After Raleigh (last year’s NASFic) I’m convinced that I can handle most anything a convention can throw at me. But the unsettling question is will I?

That’s what it all comes down to, each and every day, for all of us. We most definitely can, if we have the will. I’m reminded of a quote attributed to Vince Lombardi (while there is no proof he said precisely this, it’s close enough to his thought that I’m sure he won’t mind being associated with it):

The difference between the successful man and the rest is not a matter of luck, or intelligence, or even talent; it is a matter of will.

The “matter of will” is not the “I wish” type so many of us confuse with will. It’s the determination and mental discipline to do what it takes to achieve what we are willing. If my will falters, I cannot achieve, and that’s not a lack of ability, but a lack of will.

As so often with quotations from St Vincent of Lambeau, it applies to so much more than football. Success, no matter how we define it, is never free of cost. It has a price, rarely measured in mere money.

The only question that matters is: will I pay it?

Be conservative in what you emit, and liberal in what you accept.

It stems from RFC 761, and it was originally intended to guide the creation of computer-computer interactions. In a nutshell, the law describes the nature of a robust system: when sending to another system, adhere as closely to a rigid standard as possible, but when receiving data from another system, allow for as much variability as possible.

I’ve since taken this principle as foundational for computer human interaction. Humans are by nature vague, imprecise, and sloppy beasts, so the computer should be prepared to accept a great deal of variability from them, while delivering precision to them.

But lately, I’ve been musing on this as also a fundamental principle of human-human interaction.

It’s not a new idea. We all know humans are inaccurate, imprecise, and vague creatures; we’ve known it for centuries. But I think in the digital age we live in, it may be wise to revisit the brilliant scientist who made so much of it possible, and take some advice.

Postel’s Law is a principle of robustness, meaning it makes sure the system continues to work, even under stress. Think about it: isn’t that what we expect from, and even need in, human interactions?

A system that follows the path set by Jon Postel will continue to function in the presence of garbage input. Shouldn’t we do as much?

If I’m following Postel’s Law and you say something that I disagree with, or am even offended by, I don’t blow up. Also I don’t immediately cut you off. I try and make sense first of what you say, and if I can’t I say so and ask for clarification. In worst case, I identify the offensive bits, drop them, and get on with the meaningful ones. “Be liberal in what you accept.”

From the other side, “Be conservative in what you emit” means I don’t call you names. I don’t shout at you. I don’t call you stupid because you don’t see what I see.

I don’t make the claim that applying Postel’s Law to human-human interaction is either a novel or a unique idea. In times past it went by the names of courtesy and civility. “Turn the other cheek” could be part of it, as could “A soft answer turns away wrath.” Proverbs like this abound in the world’s Wisdom Literature.

But perhaps we need a new, digital, formulation of the policy to reach the citizens of this digital world.

I’m not saying be phony or two-faced. “Be liberal in what you accept” doesn’t mean that, nor does it mean be a doormat. I’m saying you don’t need to retaliate for every offense, you can pass on by, noting the bad behavior of your communicant, like a warning flag from a compiler.

I’m also not saying you have a license to be deliberately offensive or hostile, to abuse the protocol. “Be conservative in what you emit.” No matter how you’re treated, you treat others with a high standard.

I realize we’re none of us computers, so we won’t follow any protocol laid out for us perfectly. At bottom line, I’m saying we should all try to behave as civilly toward other people as our computer behaves toward other computers, thanks to Jon Postel.

So in the interests of helping out anyone else out there with the same idea, that of wanting to try out something new in hopes of finding something better, here’s a quick-and-dirty glimpse at the way I use git around here.

Git isn’t SVN

The first thing to remember is that git isn’t svn. It’s not server-based. It’s a distributed code management system, meaning there could be potentially hundreds of repositories involved. You can use it just like svn, and have a single repository on a single server, but that would be like buying a minivan to drive two people around town. Of course, I have a repository on my server (and I honestly question the wisdom of anyone who doesn’t) but that’s only one repository, and it isn’t the first one I create.

I start out by creating the repository in my project directory on my development machine:

git init
git add .


Those two lines of code initialize an empty repository and then add every file in my current directory to the repository. The second line might instead be broken into several lines, if I didn’t want to add every file, but this is the quickest. (If there arejust a few files you want to leave out of the repository, you’ll want to check out how “git ignore” works.)

What About The Server?

Well, that’s all fine and good for your local development, but what about shared development? Don’t you need a server for that?

Yes, but you don’t need git on the server. After all, a git repository is simply files. All you really need is ssh access to the server.

ssh user@server.com
mkdir projectname.git
cd projectname.git
git init

The first line above gets you into the server, the second line creates the directory you’ll be using for your remote repository. The final two lines above create the empty repository. After those, you can log out and return back to your local machine.

You send your changes from your local repository to your remote one by using the “git push” command. But first you’ll need to tell git where the remote repository is:

git remote add origin user@server.com:projectname.git

This line creates a reference to a remote repository and calls it “origin” (it’s a longstanding custom that the main remote repository be called origin, but it’s not a necessity). It points “origin” at the remote repository we set up earlier.


git push origin master

This line pushes the changes in the local repository up to the remote one identified as origin.

Now you can continue to develop on your local machine, committing changes to your local repository, and once you’re finished, you can push all (or just some of) the changes up to the server.

(And yes, the obvious “git pull” would be how you bring changes pushed to the server by other members of the team down to your local repository.)

A quick sheet of “normal” git commands.

Git User’s Manual

The idea itself isn’t new, talking heads on TV and radio have been doing that for decades. The theory behind it goes something like this: When the show’s host says something eminently reasonable, the listeners will sagely nod their heads and agree, but no one picks up the phone to call in and congratulate the host on being reasonable. On the other hand, if the host says something outrageous, people will call in by the droves, either to argue vehemently or to cheer the host on into further outrages.

Either way, the phones ring and the host has something to do for the next hour. If the callers are rational, the host backs down from the outrageous claim with the excuse that the hyperbole was necessary to get people thinking. Of course, that’s a convenient fiction, because the host really wasn’t trying to get people to think; the goal was to make people talk, not to make them think.

That’s the real goal of talk radio, to make people talk, either to the host on-air or about the host to their friends. Then more people talk about the show, and more people will tune in, either to hear the next outrageous statement, or to hear things they can argue with or complain about.

So that process works brilliantly, for Talk Radio. But the goals of an Open Source project aren’t to get people to talk and argue. The primary goals of an OS project are to ship good code, and to rationally evaluate proposed code. Stimulating argumentation and complaints runs almost directly counter to those goals.

Anything that draws attention away from the code causes a problem. Being obnoxious is fun, don’t get me wrong. There’s a certain amount of gratification gained when you see a thousand knees jerking in time to your words. But while those knees are jerking, there’s no thinking going on, and without thought, code dies.

Whenever you do or say something to cause outrage or controversy, you’re diverting attention away from your point, which is about the code change you’re proposing. In addition, you’re giving people that might otherwise have been convinced by your code an excuse to ignore it. You’re giving people who would resist your proposed change, for whatever reason, more ammunition to use against you, giving them a way to, if not defeat the proposed change, at least derail it for quite some time.

And all the while you’re doing nothing at all to forward the proposed change. People who would have been inclined to accept the change, will accept (aside from those whom your conduct scares away from it, that is) and people who would not be inclined to accept are even farther away from the decision to accept. You stirred things up, alright, but in doing so only made it harder for the change to go through, not easier.

Keep a civil finger on your keyboard, and the opposition will have to mount arguments to reject the change based solely on the code. Your code change will stand or fall on its own.

And isn’t that the whole idea?