Month: November 2006

24 Hours with the Sony Reader

Right, I know I promised I would tell a story about deploying software based on Django. It’ll have to wait [1]. Yesterday I wandered into the local Border’s to kill some time after lunch. Nothing to look for, just like the books. And there it was, a lone Sony end-cap display with (gasp) live, in-the-flesh Readers.

The four word review: hardware hot, software not.

I’ve been lusting after the Sony LIBRIe Reader for some time. When I travel, I hate the part of packing where I have to decide what books to take; I start with a pile of at least half-a-dozen, and end up limiting myself to two. OK, three. This isn’t to say that I even end up reading all the way through those two. Or three. Just that I tend to be reading a few things at the same time, and don’t like having to decide what I’ll be in the mood for the next week. So the thought of taking a slim device loaded with several dozen of my favorite books, along with technical references and work-related documentation… the mind boggles.

So of course I picked up a Reader yesterday. The four word review: hardware hot, software not. I guess I should clarify: device hot, desktop software not. The device itself is a great text reader. It’s light weight (about 9 ounces), has a display that looks uncannily like paper [2]. The text is crisp and the controls decent. Yes, there is a weird flash between page changes, but it hasn’t risen to the level of annoyance for me yet. Overall the engineers managed to craft a device that comes closer to the book experience than anything I’ve previously seen.

It’s the desktop software, Sony Connect, that should be flushed. I’ve admittedly only used the software for less than 24 hours, but I can tell you now that I won’t grow to love it. If anything, I’ll uncover more reasons to hate it. But here’s my brief list for now:

  • The software desperately wants to be iTunes, but just isn’t… I don’t love Apple’s use of custom widgets in iTunes for Windows [3], but Sony’s custom widgets are even worse.
  • Like iTunes, Connect embeds a browser in the application for browsing their online store. But somehow they managed to fuck up scrolling: filling out the registration form in the store and press the down arrow to scroll down the page only to find, hey, what happened? Oh, right, the list box on the left that wasn’t even focused received the command. Try to use the scroll function on your touchpad? Hah! It’s scrollbars only for you, bitch.
  • Plugging in your reader doesn’t let you sync it… it just shows up in the software and you have to drag things manually [4].
  • The Reader is expandable with either Memory Stick or SD (thank you Sony, for realizing that some people want to use their removable storage media in devices other than yours). Unfortunately the Connect software sort of screws that up too — it will only let you drag files to the SD card when its connected by way of the Reader [5], and even then it makes you choose between internal storage and the SD. Can’t I just say “put these on the Reader, please?”
  • Finally, library management is too screwed up to describe: importing allegedly-supported formats fails silently with no notice, you can only create “collections” (the Reader’s way of grouping books) on the PC and then drag them to the Reader, and I couldn’t figure out any way to add a new text to the Collection once its on the Reader without re-creating it on the PC adding something and dragging it back. Which created a duplicate with the same name. Not exactly what I was going for.

There is good news, however. Even though the LIBRIe was a Japan-only, a community of hackers sprung up to both translate the firmware to English and support user-generated content. That effort seems to have graced the Reader with a ready-made hacker community, anxious to liberate the Reader from Sony’s ineptitude. Particularly interesting to me is the development of libprs500, a Python library that reverse engineers the USB protocol and which I successfully used to transfer a text to the Reader under Linux.

We can fix it, we can make it better. We have the technology.

[1]OK, I’m actually still trying to work out whether there’s really a story there, or if everything’s looking like a nail lately. Stay tuned…
[2]Maybe a cross between paper and the old-school monochrome Palm Pilot displays… and yes, that’s a compliment.
[3]Yes, the Sony Connect software is Windows-only right now.
[4]OK, so maybe they think people will attain massive etext libraries on their computers which won’t all fit on the Reader. Fair enough, but there should really be a way to “sync all until I run out of space, and then make me choose” option. Don’t make me think, damn it!
[5]That is, plugged into the Reader, tethered to your USB port, not plugged directly into your integrated card reader.
date:2006-11-11 12:26:51
wordpress_id:463
layout:post
slug:24-hours-with-the-sony-reader
comments:
category:geek

Deploying Python Applications

This post started out as details of some Django work I’ve been doing lately. But it turned out that I needed to talk about zc.buildout first, so Django will have to wait.

Lately I’ve been working on an application for work that’s using CherryPy. Why not Django, you ask (since I was going to be writing about Django…)? The first reason is that we already have code in production using CherryPy, and fewer dependencies is better. More importantly, the application I’m working with does minimal database access and has no need for what I perceive to be Django’s killer feature — dead easy administrative interfaces.

As I started building this application, I was faced with what (for me) is a common question: how do I get code from my development laptop to the server with a minimal amount of fuss? How do I actually deploy this application in a way that’s manageable in the long term?

The basic answer to this, the one that gets me by 80% of the time, is Subversion. You check the code in, you check the code out. But what about dependencies? I guess there are eggs, which are supposed to help with that. What about scripts? setuptools has some support for generating those. What about Python paths? Sigh.

It turns out that a tool originating in the Zope world, zc.buildout, provides a really attractive story for deploying Python applications. zc.buildout is a project developed by Jim Fulton of Zope Corp that “provides tools for assembling applications from multiple parts, Python or otherwise.” At its core is a text file that describes that parts that makes up the application, and the recipe each part uses to perform its actual action. Some basic recipes, like running tests or installing an egg (dependencies and all) are made available via the Cheeseshop, and creating your own is straightforward.

So if I truly believe that fewer dependencies is better (as I stated above), you might wonder how I can be advocating for a tool that is itself a dependency, and requires yet another (setuptools). I suppose I should have qualified my earlier comment: fewer dependencies that I have to think about is better. In my opinion, the best thing about zc.buildout is the fact that it relieves me from having to think about dependencies. Here’s how it works.

I include two additional files in Subversion with my project, buildout.cfg and bootstrap.py. buildout.cfg defines the buildout process for my project, which in this case just involves installing a single egg. bootstrap.py is magic. bootstrap.py allows me to start with a stock Python installation (no setuptools, zc.buildout or other dependencies), run bootstrap, and end up with a functioning zc.buildout system. By default it creates an eggs sub-directory, which it places the eggs for setuptools and zc.buildout in. It also creates a bin sub-directory that contains a new script, buildout. Running that script parses my buildout.cfg and installs the parts I requested.

As part of the my project’s setup.py script, I use setuptools entry points to specify that I have a script I want to make available. In this case the script just runs a simple web server, which makes testing easy. The script is specified as a dotted Python path and a callable, separated by a colon. For example, my.package:main.

zc.buildout improves on this experience by reading the script information during the buildout process and creating wrappers in the bin subdirectory it created earlier. Those wrappers are interesting because zc.buildout bakes in the eggs that my code depends on. This may be a bit of a yawn if you have a box with just one web app on it. But at Creative Commons where we have several different web apps, all with slightly different sets of dependencies, and a couple with Python version dependencies, this makes a world of difference. No more writing wrapper scripts, no more installing dependencies into site-packages. Two commands (bootstrap, then buildout) and you’re up and going.

I haven’t played with custom recipes yet, but even with simple tasks like this, zc.buildout is a great tool. Thanks, Jim! Tomorrow: zc.buildout, Django, eggs and you.

date:2006-11-07 16:50:41
wordpress_id:458
layout:post
slug:deploying-python-applications
comments:
category:development