Take a listen to the podcast right now. It’s the best 30 minutes you’ll spend this week.

I picked up Nikolai Krill’s CodeRunner a while back as a sort of scratch pad for writing code snippets. With support for a variety of languages, it looked like a handy tool for banging together scripts and experiments.

But I was let down a bit by one hope that didn’t pan out: a passing attempt at a kind of REPL for Objective-C. While Code Runner supports ObjC as a syntax, you can’t really use it to test your ideas against the frameworks.

Don’t let that get you down. Rails developers, it turns out, can really benefit from CodeRunner. Let me illustrate with an example: quite frequently I use the Rails console to figure out how to pull the data I want from my models. But the console is extremely limited: you can only enter one line at a time, and you can’t go back and modify your code without starting over again. To my knowledge, short of writing test controller actions, this was the only way to go about experimenting like this.

CodeRunner provides another way. Using Rails’ runner script, you can run arbitrary scripts against your app, loading up all its libraries and models. It’s the same power you get by loading the console. So I can compose scripts, edit them, and run them against my Rails app anytime. That screenshot heading this post is what I’m working on right now. It’s an experiment in a way of pulling a series of data from my models; when I’m done with this exercise I will have a hunk of code that I can drop right into a Rails method, and I’ll know it works. That’s hot.

Here’s how you do it.

1. In CodeRunner, go to CodeRunner > Preferences.
2. Choose the Languages tab.
3. Hit the “+” sign to add a new Language.

4. All you have to do is enter the command that CodeRunner will… er… run when you execute your script. It’s in this format:

   ~/Sites/cm-emailtrack/script/rails runner -e development $filename

Give the path to your Rails application, and leave that “$filename” — this is what CodeRunner uses to sub in the file you’re working with.

Ensure that you use the Ruby syntax lower in this window. You should end up with something like this:

Give it a descriptive name (remember, this is only going to work against a specific Rails app), and save it.

Boom! Your programming life just got a little easier. Have fun with it.

My daughter is nine years old. She’s just a few short years from boys turning from an annoyance into a actual problem. The kind of problem where being attractive and female seems to turn many men into degenerate neanderthals. The kind of neanderthal whose behaviour makes it into blog posts like these. I’m writing this because these posts have made me angry enough to blog about it. Here’s an excerpt from Ashe Dryden, citing examples of the kind of behaviour I’m talking about:

A guy at a tech conference asked me where he could get in line to have sex with me.

I stopped drinking because my fear of not being able to protect myself at all times was greater than my want to go out and have fun with friends.

I’ve had a male coworker threaten to come to my house because I didn’t want to discuss a work issue with him while he was angry. Because he attended most tech events in the city I lived in, I stopped attending them – even the ones I was involved in organizing.

Sexuality is at the very core of our being, as both men and women. Men constantly struggle with their urges, and women are under constant scrutiny as potential mates. Nothing is ever going to change that. But we have the mechanisms of culture in place to protect women from men, and men from themselves.

I’m talking about mores here: a generally-accepted notion of what is acceptable. Men whose behaviour ranges from killing innocent turtles to not washing their hands in the bathroom highlight, for me, the ways that mores can be violated.

But there’s a special hell waiting for men who think it’s in any way acceptable to speak to or treat a woman as we’ve seen in these posts (and others). This example is particularly troubling:

I reported coworkers for sexist and homophobic language directed at me only for my boss to not only tell me it “wasn’t that big of a deal”, and then go out of his way to tell the person who said those things to me, creating a very unsafe work atmosphere.

Because it reveals a stark truth about so many men’s attitudes towards women. I’ve thankfully never witnessed this kind of behaviour in person, but I’ve heard enough stories to believe it.

The proof of it is in how women everywhere live their lives. In how I notice most women walk down the street with their gaze fixed straight ahead or on the ground, lest they meet the eyes of some man and somehow encourage him. Or in how I am often surprised to find the front door of my own home locked when I’ve been out, because my wife is alone there and fears a man will break in and rape her. Or in how, in a public place, I can look at a pretty girl walking by, and then look at the other men around me and see them watching her too.

For the percentage of those men who think it’s cool to approach that woman in an aggressive way: it’s not. Every such advance a woman suffers becomes further evidence to seed her mistrust of men. And this is a disservice to all of society.

I see it especially in technical circles. I actually thought there were no female Cocoa developers in Toronto, because Tacow went for years without seeing any women at meetings. But it turns out those empty chairs could be filled by developers like Ashe Dryden, or all the women who spoke at the recent Renaissance IO Conference.

Women developers are out there, but they’re not coming to the meetings. And the boorish behaviour of men is the reason.

So, for the sake of better diversity at my technical meetups, and for the well-being of my wife and daughter, men really need to shape up. Wash your goddamn hands, leave the turtles alone, and treat women with the same respect you should treat your mother.

One of this project’s components involves a great deal of parsing using regular expressions. I’m working on a UIView subclass that performs syntax highlighting, and writing the correct regular expressions to match the patterns in my target text has proven to be a challenge.

Regular expressions are a difficult skill to learn. But what they don’t tell you is that every language has its own subtly different implementation; techniques that work in Ruby, for example, don’t work in iOS. That’s because Ruby’s implementation is based on Oniguruma, whereas Apple is using the ICU project.

These implementation differences turn out to matter a great deal. As I’ve come to rely on Ruby’s delightful Rubular regex testing tool, I’ve also found that the results I get from it don’t apply to pattern matching in iOS. Sometimes.

So it seemed there was only one solution: build a Rubular that uses the very library I’m looking to target. I give you NSRegexTester.

It works pretty simply: put some text into the box on the left. Enter a regex string at the top and click Test. The left-hand text will appear on the right, with any matches highlighted. Rinse and repeat till you’re happy with your regex, and you can drop that into your code, knowing it’ll “just work”.

The application was built in about 30 minutes, but it took a few more hours to mess around with layout and adding the options window. The list of checkboxes presented a particular challenge; for some reason I can’t figure out how to make them behave as a collection, despite putting them into an NSMatrix. Arggh.

But maybe you can help, because I’m making the source code freely available on Github. Fork it and play around. There’s also a binary available from there if you just want the app.

It’s strange to me that I haven’t given away any of my code before. My Github profile is just a list of projects that I’ve forked for myself. Well, as 2013 arrives, I’m hoping to make a little change by giving something back. I hope there will be other developers like me, who will find this useful.

In 1997, Steve Jobs returned to Apple, and among his first moves was to kill off most of its products. No more Quadras, Performas (Performae?) LCs, Newtons and OpenDocs. In the video above, from the company’s 1997 Worldwide Developers Conference, Jobs takes questions from the audience. This three-minute clip is his answer to why he killed OpenDoc.

But never mind OpenDoc. His answer is about focus. And focus is about saying no. That is what this post is about.

Steve Jobs had a singular goal in 1997: turn Apple into a company that matters. Why he succeeded is, to me, a crucial life lesson that we should take to heart. And it’s that focus is the only way to achieve your goals.

For me, goals matter a lot. Without something to achieve, I’ll feel like my life is passing by without meaning. It’s not enough to earn enough money to pay my mortgage and put my daughter through school. It’s my ambition, to use another term.

Right now, my goal is to become an indie Cocoa developer. It’s been my ambition for so long, that when I first identified it, I would have said “indie Mac developer” — since the mid-2000s, iOS has exploded on the scene.

For a guy with a background in writing and publishing, switching to development is no easy feat. It’s a long-term goal, years in the undertaking. And I can say there’ve been a lot of mis-steps along the way.

My wife talks about goals like a mountain. You can see it off in the distance, and every fork in the road either takes you closer to or further away from that mountain.

Saying “no” means taking another step towards the mountain. Saying “yes” to the wrong thing means heading away. Here are some examples of saying “yes”:

• Watching Breaking Bad in the evening instead of coding
• Agreeing to write Web Development With The Mac instead of working on my first Mac app.
• Helping to run my local Mac User Group instead of learning more Cocoa

Saying No to these things means disappointing people. Because watching TV takes me away from learning more Cocoa, I cut it way back. Because writing a book basically consumed my life for six months, I decided to never do it again. Because preparing a two hour presentation every month took too much time, I resigned my post with the local MUG. In all those things, there was a lot of No going on.

People are disappointed when you say No to them. In fact, we seem trained to say Yes as often as possible; we don’t want to let anyone down. But Yes has a way of fracturing our lives, taking us in every different direction.

Yes, I’ll help organize this party. Yes, I’ll write a piece for that newsletter. Yes, I’ll help out that other person with their computer.

No. No means those people have to find someone else to do that stuff. And that’s hard. But if you want to get anywhere, you have to disappoint others.

Who are you answerable to? For me, my ultimate authority is Future Aaron, a crusty, geriatric version of me, rasping out my last breath on a hospital bed. Looking back and wondering what I’d accomplished. Did I build something worthwhile, or did I drift through life, starting things but never finishing?

Well, in October of this year, I launched Tiberius. It’s my first “real” Cocoa app, and the beginning of a new branch in my own road to that mountain over there. It took some five years of false starts, misdirection and reboots to get here. It involved me sitting in front of my computer for so many evenings, I began to associate Xcode (the Apple developer environment) with night-time; seeing it open during daylight was a strange and noteworthy occurrence.

If you have a goal, then, you have to do this:

• Say what it is. Out loud.
• View it as a mountain. Admire how beautiful it is at this distance.
• Vow to get there.
• Say Yes to what gets you closer.
• Say No to what takes you further away.

Do those things, and crusty, geriatric Future Aaron will approve. What greater motivation is there?

CouchDB, and the iOS framework called TouchDB, form the networking foundation for Tiberius, ensuring that sweet sweet data seamlessly moves between a user’s various iOS devices and the web. I firmly believe in CouchDB as an enabling technology for the next generation of mobile apps that rely on a web services backend. As such, I was thrilled to share my excitement about CouchDB with a group of people for whom I have so much respect and admiration.

I recorded my presentation using QuickTime’s screen capture feature. The results are sufficient, if not pro-level. But if you weren’t able to make it, this is the next best thing, excepting the roar of my MacBook Air’s fan, my keyboard hammering, and my apparent inability to repeat questions from the attendees, prior to answering. Sigh.

You can also download the two projects that I used to demonstrate CouchDB and TouchDB:

1. A complete Ruby on Rails web application, which talks to CouchDB using the RestClient gem. (Zip Archive, 123KB)

2. A complete Xcode project, a simple Table View application for iPhone that speaks to CouchDB using TouchDB. (Zip Archive, 4.2MB)

Video: CouchDB Presentation for Tacow

I went on a scouting mission to the Apple Store today. This was going to be my first chance to hold and use an iPad mini. As an iPad 2 owner, I wanted to see if the new mini would work for me: is the screen too small? Is it too slow?

I managed to fight my way through the crowds to spend about 15 minutes putting a black iPad mini through its paces. I came away seriously impressed.

To my mind, the iPad mini is the iPad Apple should have made from the start. Its size and weight are incredibly pleasant; it feels “just right” in my hand. I can hold it in one hand to read for extended periods, but in active mode I can readily use both hands to interact with on-screen elements, and they’re not too small at all.

One of my chief concerns — can I read comfortably on a smaller screen — was immediately obviated during my time with it. It’s no retina display, but it’s very comfortable, and considerably better than my iPad 2. Another concern was about performance, and the iPad demonstrated itself quite capable of running all the apps I tried without a hitch, proving once more that the iPad is a computing appliance.

Most of the reviews on the web echo my positive impressions of the device, and you can read about them yourself (one of my favourite might be The Verge’s, but you won’t have to look far for more).

But as I was driving home today, one thought stuck with me: text entry on this iPad is a real problem. Unlike with the 9.7-inch iPad, you can’t work the landscape keyboard touch-type-style (if you will). You have to type in a style more akin to the iPhone — with your thumbs in portrait mode. And it works great, for that purpose.

But as I wrote in my Logitech Ultrathin Keyboard Cover review, even a landscape 9.7-inch iPad on-screen keyboard offers much better typing efficiency than an iPhone: up to 63 words per minute, versus a best time of 26 words per minute. It would seem the iPad mini on-screen keyboard is going to really limit my ability to get text into this device.

And you just can’t get away from that problem. Even on a full-sized iPad, I lose 20 words per minute, in a best-case scenario — programming is right out!

As I was thinking about this, it struck me that while the 7.9-inch iPad mini is a fantastic device, I wonder if Apple originally went with 9.7 inches in 2010 because it would give them the closest approximation to a full-size on-screen keyboard? Back then, a keyboard that you could approximate touch-typing upon would have been vital. Today, people are sold on the idea of an iPad for more than setting text, and will (I’m sure) devour the new smaller iPad at a terrific rate.

And yet.

What can be done about this most vital problem of ever-smaller computers? The 7.9-inch display is (to my mind) perfectly suited for so much of what I want a tablet for, except for text entry. What other ways can we use to make this better?

I have some ideas. They range from interesting to crazy.

Talk to the Hand

First, there’s speech recognition. Obviously. I’ve actually been very impressed with the accuracy and speed of speech input on the iPhone 5. For sending text messages, beating out a three-sentence email, or even getting a search term into Safari, it’s not too shabby. But it comes with a pack of gotchas: you really need a quiet, preferably private, environment (despite the fact I make Tiberius, I feel awkward talking to computers in front of people), you have to wait to see if your text was even recognized, and there are hilarious (or frustrating) mistakes to contend with. Until Apple invests a lot more into speech recognition, it’ll remain a secondary option to typing.

“Sub-Typing”

Now let’s go a bit sci-fi. Imagine a technology that is to typing what subvocalizing is to speaking. Instead of actually typing, you could make the finger motions and it could be recognized. In a way, it would be like thinking what you wanted to type, and ideally much more accurate than a real keyboard.

Turns out that idea isn’t entirely nuts — I found mention of something kinda-sorta similar in a very old issue of Wired. The first item on this page (“Hand Job”… eeewwwww) talks about a project to attach special chips to your fingers in order to recognize motions. There’s no other mention of it anywhere else; I suppose it sunk into oblivion. But I would love to see this idea manifested, Apple-style.

“Aggressive Autocompletion”

Finally, let’s say that we are happy with the way we input text for blogs and emails. It remains that the on-screen keyboard is totally useless for writing code: even terrific apps like Diet Coda can’t bring sufficient access to the special keys needed.

But what if you were coding in an environment that knew exactly what you might be typing? I think of it as “aggressive autocompletion”: if you’re coding HTML, you tap a tag button, and pick a tag from a list. Then all you fill out are the attributes. Imagine typing an anchor tag: hit “a”, then type in the contents of the “src” attribute, and the rest is filled in.

A hypothetical Cocoa development environment would aggressively remember variables and class names, and supply them on demand with a given keystroke. It could be more intrusive, but I wonder if, done right, it couldn’t make programming possible on a touch display.

Maybe one of these solutions will replace the keyboard. Maybe a combination of them. Maybe none, and we’ll be hunting and pecking from the bridge of Discovery while an alien entity tells us to attempt no landings on Europa.

When I watch Star Trek, I think about the ways that characters interact with their PADD devices; they seem to tap at them in nonsensical ways. Jake Sisko, the captain’s son in Deep Space Nine, was a writer, and we see him sometimes using a stylus when he’s composing on his PADD. That doesn’t make sense either. I hope that by the time we hit the 24th century, we’re doing better than that.

In the meantime, I’m going to take my chances on an iPad mini as my next tablet. The 32GB, black, with LTE, in case you’re wondering.

[Photo credit: The Verge. But you could tell from the giant "The Verge" in the bottom corner, right?]

Conference Badges, past and present. Left: C4[1] dog tags from 2007. Right: Çingleton 2012

I was a tourist: a web developer with pretensions towards Cocoa development. All the guys I met there were seasoned developers, whose examples were exciting, if not out of apparent reach. Thanks to a fortunate intervention by Dave LeBer and Karl Moskowski, I joined Tacow, and that regular exposure to actual, real developers became my motivation to push on.

Fast forward five years, and my goal is closer. In 2010 I put my first app in the Store, and that experience propelled me to this week, when I expect to launch Tiberius, my first “real” app, if you will. It’s an exciting time, and I hope a solid step towards my ambition to be running Xcode during the day. After 18 months of part-time development, I’ve come to associate Xcode with the nighttime.

I give you this history lesson as a way to bring you to Çingleton, an annual symposium for Apple developers. Despite a couple previous C4 conferences, and last year’s SecondConf (I do love me some Chicago, it seems), I couldn’t shake that feeling of being an interloper; a sense that I didn’t belong. There wasn’t a single instance of another developer giving me that feeling: fellow attendees have proven unfailingly kind and generous in their enthusiasm for where I’m from. Yet in my heart, I knew I hadn’t attained a level to think of myself as their peer.

That’s over now. For the first time, I looked onto the crowd of nerds milling about in this beautiful space, and I thought to myself: “these are my people.”

Photo by Rene Ritchie, originally published on iMore.com

The Lessons Learned

This isn’t a reckoning of what happened at the conference — Rene Ritchie did a terrific job of that, covering days one, two and three — but an account of what this conference did to my general mental state.

I actually go to these conferences to meet my kind, of course. But the net result of those talks, and those drinks, and uncomfortable chats in circles while a hundred conversations roar around you, is a shift in perception.

In my day job as a web developer, my thinking is consumed with tactical issues: how to make a certain thing work in a certain way. Put together enough of those tactical solutions, and I have a successful day. Fail enough at those tactical issues, and you get added stress in your life. In point of fact, my day life is consumed with the avoidance of stress, my head down, my brow furrowed. I’m basically a nerdy marionette, my strings pulled by circumstance, and the business needs of my employer.

Çingleton was like having my eyes opened to a universe of better possibilities. When Michael Lopp talked about the certainty of your career changing every three years, I was relieved! When Marco Arment talked about seizing your own authority — you want to be a developer? An editor? Make yourself one! — was empowering, and inspiring, and true.

And when Serenity Caldwell talked about her struggle making Macworld’s ebook publishing workflow functional, it reminded me of my own life. It was a vivid duplicate of my own circumstances, a tactical life struggling to bend tools to my will without a chance to sit back and figure out the big picture. That talk in particular was like cold water: that’s me, up there, banging around between Word, InDesign, Calibre, Pages and back. While Caldwell is trying to string together a publishing workflow, I’m struggling to push a mountain equally obscure and thankless.

Stepping Back

When I had the chance to step back from my tactical existence here, I took that time to think strategically, about my career. On the five hour drive back to Whitby from Montreal, I dictated a half dozen solid app ideas into my iPhone. I thought big thoughts. I composed poetry in the silent car. I swore breathlessly that I would always be like this.

But like a dream, that feeling is slipping away in a tidal wave of tactical issues. Monday morning came with a storm, and all my happy thoughts are being pushed away.

Can we build for ourselves the kind of work life that emulates — no, encourages — the type of thinking that conferences like Çingleton inspire? I don’t know, but I want to find out.

In broad terms, the formula seems pretty simple:

• I want to work on building great things
• I have significant authority in deciding what makes the thing great
• I have the time and space to practice my work; without artificial deadlines
• I also have the time to not practice my work, but instead to research, play, and think.

It seems like a crazy list. I know this kind of environment can exist; I want to create it here.

I’m going to leave comments open on this post. If this makes any sense, I’d love to hear from others about what this conference (or others like it) do for you.

In the meantime, I definitely plan to head back to Montreal next year, if they’ll have me.

My deepest thanks to the brilliant organizers of the event: Guy English, Luc Vandal, Scott Morrison, and Petra Mueller.

I’ve been building web sites for some twelve years now. And I love what I do: using code to express an idea is a task that I approach, every day, with a sense of humility and honour.

But if there’s one thing I really hate about being a developer, it’s that circumstance forces me to be less good at my job than I’d like.

This job description, posted by a Denver-based Web development shop named CrowdFavorite, kind of set me off. I can’t speak to whether their actual working environment matches the description of their job posting, but it made me confront the uncomfortable facts of my own career.

CrowdFavorite’s hiring ethos appears to be based around the notion that quality matters most. They want to hire developers who strive to create “a truly elegant finished product”.

Who the heck wouldn’t want to do that?

But there’s an unmentioned tension in that post. It comes from the time-worn engineering truism, that goes something like this: “On time, on budget, done right. Pick two.”

In my career, as a freelancer and as an employee for other companies, I’m overwhelmingly pushed to accept the first two as immutable, with the third as a variable. It’s never a question of “doing it right”; instead, it’s getting it delivered by a certain date, with an acceptable level of quality.

“Doing it right” comes with a great number of customer-unfriendly terms. You can’t claim how long it will take to do it right, because programming is complicated, and optimistic specifications might need to be re-written. You can’t claim that it will cost a certain set amount, because you’re developing a feature that’s never been done in this way before, and like basic R&D, it can’t be rushed.

So when you put your emphasis on “doing it right”, you inspire images of a bucolic land of un-rushed timetables, laissez-faire development and a “whenever-you’re-happy-with-it” management style.

I’m blue-skying here, but let me paint you a portrait of a developer who doesn’t feel like he or she needs to focus on anything but delivering top-notch user experiences. That person would spend hours gazing out the window, deep in thought. There’d be some chatting with colleagues, some whiteboarding, and some coding sessions. Coding would be an activity of long silences punctuated by the occasional patter of keystrokes. The results of their work — ideally arrived at through some consensus with other stakeholders — would be deeply personal, defended vigourously, and delivered in an iron-clad quality guarantee.

That’s not my life. As long as I’ve been doing this work, I’ve been frantically hammering away at my keyboard, planning while I code. I make stupid mistakes and hurriedly scamper back to correct them. I’m pulled in many different directions: by management, clients, the too-few hours of the day, and the constant, over-arching need to produce, ASAP. The results are makeshift, bugs are normal, and I’m often battling on two fronts: to both fix what I’ve broken, and to make the new stuff.

These are two ends of a spectrum. Surely even CrowdFavorite will nudge their developers to hit certain milestones, and surely I need to be better at pushing back on deadlines (while simultaneously extending the job, and the paycheque… argh!).

It seems like a fantasy. To accomplish it, the developer needs to be protected, at almost any cost, from the pressures of the inevitable money-holders. I don’t know how that’s possible, to be frank.

Again, I don’t want to make any claims about this job posting, but it sure feels like a beautiful tale, rather than reality.

But if given the choice between my end and theirs… oh boy, I would love to be there. So let’s all take a deep breath, step back and figure out how we can turn our reality — even just a tiny bit — into CrowdFavorite’s happy fantasy.

I didn’t really plan for that decision to be binding, or even bear out in reality. But that’s exactly what happened: over the proceeding two-plus years, every book I read was made out of bits instead of atoms.

The streak came to a halt a few months ago, when I tagged along with my wife to her favourite bookstore, and I noticed this little baby on their discount table:

Jeffrey Deaver’s new book, Carte Blanche, is a mass market paperback with a subtle difference: its shape was a golden rectangle, and dammit, it felt really good in the hand. Seven bucks, a James Bond novel by a new, authorized author, a light summertime read… okay, let’s give this a shot.

So what we will have here is a review of a book. Not any particular book, but the book — that paper artefact that people have been enjoying for hundreds of years. Because I was experiencing it anew for the first time.

The Trouble with Atoms

Nicholas Negroponte’s book, Being Digital, has been a terrific influence on my appreciation of the 21st Century. In particular, his notion of the difference between atoms and bits is quite evocative, and I’m delighted that he has made the whole book available online for your enjoyment (ironically, I have a lovely hardcover edition on my office bookshelf; in my defence, the book was purchased before 2010). Go read that page and come back here.

Atoms are the things that you hold in your hand: this wad of paper and glue and ink; that composition of metal and glass and lithium. To get them, you have to pay someone to move it in the real world: put it on trucks, airplanes, container ships. They have to be laboriously and expensively manufactured.

Bits are instant, ever-changing, and moving them is virtually without cost. They can be configured however we dream them to be. It’s not just software, not just the data that the software runs. It’s the interaction mechanism with information, and its possibilities are endless.

So we agree that the subject of that photo up there is a bunch of atoms, and the information you’re reading now is a collection of bits. The book you see in that picture will never display different bits, whereas your computer, or your iPad, or your Kindle, can always be reconfigured to show you different bits.

If you ever want different atoms — like a new book, or a new computer — you have to go out and get it. Compared to getting new bits, it’s a total hassle.

So when I approach a review of the traditional paper book, it’s from this notion of the book as a physical artefact, and the real-world problems it presents, vis a vis its electronic counterpart.

Physical Appreciation

I can’t deny the physical attraction of a paper book. When done right, it’s an incredibly evocative object, and especially for those of us of a certain age, it’s easy to confuse books with their purpose. The paper book is a story. The paper book is information. But it’s not, and the tension between the thing and the stuff it contains is the subject of a great deal of hand-wringing.

I feel certain that paper books will never die. Unlike such things as vinyl records and VHS cassettes, or children and grandchildren will have no problem identifying one in the wild. But my experience with this paper book has convinced me, more than ever, that these books will become a more rarefied object, something to be lavished attention upon, perhaps.

But for the most common cases — a trashy novel, a political or sports bio, the next instalment of A Game of Thrones — I think we’ll be reading those electronically. When the information is meant for consumption, we’ll do it as cheaply and easily as possible. When we want the experience of handling the information — think of travel books, cookbooks, memoirs, beloved literature — there’ll always be a place for that physical artefact.

Carte Blanche isn’t in that latter category. It’s an ideal candidate for electronic consumption.

Pros and Cons

The book’s physical properties were also its limitations. While it was a pleasure to appreciate as a discrete thing, the reading experience itself left some aspects to be desired. Here’s a short list:

• The very first night I started the book, it happened I was at the cottage, where there is no reading lamp by the bed. I had to get an LED lamp, which made for a very uncomfortable reading experience, juggling this paperback and light source.
• The book was never where I wanted it to be. Having left it on my bedside table at home, I’d want it the next day while going to the bathroom, say, or taking a break from work. My iPad is always with me, because I use it all the time, and so my current book would be with me too. Not so with this paper thing, that only has the one use.
• People talk about how a paper book is such an ideal reading interface: you can’t argue with the resolution of the print, for example. But I often find paperbacks in particular to be difficult to read. In an effort to preserve the spine, I don’t open the book as widely as others might; subsequently, the text in the inside margins can be tough to read. The paperback is also a two-handed device; an iPad can be propped up and held with one hand, which I often appreciate.
• Once I’m done with the book, it’s no longer of any use to me. This is the worst part, to my mind. It’s possible I’ll read this book again, but it’s not likely. So what now, I’ve got to store this block in my house forever? It wasn’t that great a book to deserve that kind of pride of place.

The paperback isn’t an entirely bad thing, though. I noted some benefits:

• It’s lighter than an iPad, though it’s heavier and more awkward than a dedicated piece of reader hardware like the lovely Kobo Reader.
• It can be readily lent out. This, to me, represents the biggest advantage of paper books. If I tell my dad about this book, I can just give it to him for a time. Or forever. And he can pass it on to a friend. In my family, it’s not uncommon for a book to make the rounds of several family members. The use of DRM in electronic books makes this impossible, practically speaking.
• It announces to house visitors or fellow beach denizens (for example) what kind of book you read. People like to have shelves full of books that tell of your erudition, or your pedestrianism. Whether you stock Kant and Proust, or King and Crichton, says something about you. On an iPad, all my books are stuck in my iBooks app. And while I’m reading, it’s just a wall of text; nobody will deduce anything about my reading choices. Except that it’s probably something nerdy.
• You can read it outside with ease; in fact, a book is better enjoyed outdoors. On the patio, at the beach, on the dock at the cottage… it’s great to have a paperback. An iPad sucks at being outside. But this factor doesn’t weigh too heavily on me, personally. I’m a giant nerd, so I don’t spend a lot of time outside. But it bears mentioning.
• You don’t need electricity to read a paper book. Like the outdoor issue, I’m not really swayed by this factor, as my iPad rarely dips below 50% charge, and I’ve structured my life around having powered docking cables everywhere I go. But, should the Apocalypse arrive, it would be nice to escape to some Bond action in between bouts of crapping my pants over the hordes of zombies out there.

Hey, look at that: five items in favour of the paper book, and only four opposed! That must mean the paper thing is better, right?

No.

Postscript: A Word About Cost

Given what I said about bits and atoms, there’s an expectation that digital books should be less expensive than paper ones.

But, in a farcical twist that defies all common logic, it’s actually more costly to buy the bits rather than the atoms. At least, on Amazon:

So why is that? Publishers aren’t in a rush to open their expense reports to tell us, but I think there are a few factors at work.

Books have a ton of fixed costs that occur regardless of how the book gets produced: author royalties, publishing staff salaries, marketing costs, editorial and design work come to mind.

A print-ready file for the printer is a different kind of deliverable than an ePub document (the kind commonly used on iPads and Kobo readers), and those cost money to produce as well. But where things diverge is the next step: a printed book needs to be transmitted to a printer, which then expends huge resources to produce a run, which is then sent throughout the world to stores and warehouses.

A digital file is uploaded to a server, and there’s no additional cost to sell one copy or one million.

We’re told rather defensively that the printing and distribution process adds relatively little to the cost of the book, and I don’t have much trouble believing it — after all, none of us pay the actual environmental costs of enjoying a global supply chain. But I still think that electronic books can be considerably cheaper for a publisher to produce. As publishers — no early adopter of technology, to be sure — get better at this, they’ll be able to drive those production costs down.

For now, it feels like we’re the victims of a political struggle, as the publishers fight a rearguard action to keep us addicted to atoms. They’re terrified that lower prices will bleed them dry, in the belief that sales volumes will remain the same.

I don’t believe that. If book publishers embrace the future, they can find ways to drive down the production costs, drop the prices and multiply their sales. We’ve seen it already with Amazon’s direct publishing program, which lets individual authors set their own price. Phenoms such as Amanda Hocking have made millions from 99-cent books.

That feels like the future, and I look forward to publishers embracing it.