Wednesday, January 27, 2010

Thoughts on iPad

On the one hand, Apple’s new gadget is a big fat iTouch.  After all, what’s the real difference between an iPhone and an iTouch to begin with? Voice calls via 3G, for one.  Take those out and the only real difference is the video camera, which is neglible since they can put one in at any time.

Here is why the best ebook reader in the world will still not get me to buy one, and it’s not because I’m a book nut who loves the smell of paper.  Ready?  You can’t rip a book.

Go back to when iTunes was new, and you could buy music from Apple.  Not all music, sure.  But what were your options at that point?  If you already had the music in a different digital format then maybe you could port it.  Fine.  But the big killer idea was that you could get the CD and you could rip it.  Convert physical into digital.  And then you win.

What’s the comparable example for books? I don’t read a great deal of brand new bestseller types.  When I pick up a book it’s either a non-fiction thingie out of the Shakespeare section, or its a classic scifi that I missed the first time around.  Sometimes, to be fair, a new scifi tome or Shakespeare novel will come out and I do pick those up off the “New Releases” shelf, but those are only a portion of my purchases.

So, what am I to do?  The book I want is not available in iPad format.  Is it available in some other digital format because somebody else did the work for me?  Maybe.  Sometimes.  Not often.

So then what?  I can’t meaningfully rip a book.  I am well aware that there is technology that can do it, and Google’s pioneering some work in that area.  I’m talking about a single home user trying to turn his physical book into a digital version.  Can’t be done.  And that kills me.  If you told me that you were installing a book ripping machine in every Apple retail store, and that I could walk in and get a genius to rip my books into iPad format for me? I’d be all over it.  I’d systematically rip my whole collection (depending on much Apple charged me for the service :)). 

Where I do see a future for these devices is a few years down the line when my kids go to college.  I see them carrying a single device, instead of a backpack full of text books.  All their text books are right there in a tablet.  All the updates, too.  And homework and study guides, and question and answer forums.  It’ll have a keyboard for speedy word note taking, but you can also draw on it for diagrams.  It’ll have net so you’ve always got Google and Wikipedia, but it’ll also have instant message and SMS because you can’t live without those.

The big question will be how you keep the difference between “study machine” and “cheating machine”.  If you’re allowed to have it, you’ll be able to cheat with it.  But if you’re not allowed to have it, you’ll lose all your reference materials.  I’m not sure how that will play out yet.  I’d love to imagine some sort of signal blocking device so that once you’re in the classroom your teacher could assure that all your devices switched to local mode, but I don’t see that happening.

Monday, January 11, 2010

Rails : Passenger Is Deleting my Sub / RailsBaseURI Prefix

Ok, this was a weird one.  I’m not going to jump into a lesson in how to make Phusion Passenger work to deploy Rails applications, but suffice to say that I had a situation working where we have multiple controller entry points all in to the same application, so I had this:

RailsBaseURI   /foo
RailsBaseURI  /bar

/foo and /bar, then, are soft links from the docroot over to the Rails application’s public folder.  The dispatcher is smart enough to say “Ok, based on the public folder I know where the Rails app lives, and once I know that I can go invoke the appropriate controller.”  So a request for /foo would expect there to be a foo_controller.rb file.

That’s been working fine for me in production for months.

But this week I got the most annoying problem – I added /baz, and kept everything else the same – the soft link, the RailsBaseURI, the baz_controller file.  But now all of a sudden I’m getting  :

No route matches "" with {:method=>:get}

And, let me tell you, it is very hard to Google for empty strings.  I got plenty of examples of people having trouble with No route matches “/foo” or “/approot”, but in each case it was at least telling them their route – mine was being eaten!

On a hunch I would try /baz/baz – and it worked fine.  I tried /baz/ (note the trailing slash) and suddenly my “No route matches” error would turn into “/”.  Aha, I had it – somehow my prefix, which I’m relying on to handoff to my controller, is being eaten.  So by the time Passenger spots “/baz” and hands off to Rails, it just gives “” – and Rails in this case doesn’t know what to do with “” because I don’t have a default route set up.

The problem appears related to an update to Rails, in conjunction with Passenger.  Many people pointed me to this fix:


I dismissed this out of hand, though, because of my multiple controllers.  What value would I put in there?  I did not want my app to default to one particular entry point.

Turns out I dismissed it too soon.  What I did was add this:


And guess what?  Success!  The best way I can take to interpret this is that it’s telling Phusion “Hey, the value in this variable?  I need this, don’t kill it.”  For instance when I made it a “/” value I suddenly started getting errors saying that I had no “baz” route (see how no slash?)  So by saying that I have no relative url root, I’m saying “It’s not safe to delete anything that came in as if it were extra baggage, just leave it all in place please.”

That may be a painful explanation, particularly to anybody who understands the guts of the Passenger/Rails handoff, but it’s working for me now and I’m abiding by my “If I couldn’t find the answer by googling that means other people have the same problem” rule and posting for the next guy.