Professional Rails Online?

In response to the commenter who asked if there was going to be a beta book.

UPDATE: Clearly I should ask about these things before I post. Jim Minatel from Wrox added the following in comments:

• There will be a PDF about six weeks after the print book, meaning end of March or thereabouts. There will also be an Amazon Kindle version, eventually.

• Also after 6 weeks, the book will be available via Wrox's online subscription service: http://wrox.books24x7.com.

• It won't be on Safari, apparently Wrox books aren't part of the deal there (which I actually was kind of wondering about). Meaning I still haven't placed a book there)

I now return you to my earlier, ill-informed, blather...

Unfortunately, I'm pretty sure the answer is no. Not only doesn't Wrox tend to do that kind of thing, at this point, the book is do to go to press in about two weeks, so the amount of time to get feedback would be sharply limited.

At one point, I was told that sample chapters would be available online before release, but I don't have any information on whether there will be an e-book available. I don't think there will be a direct purchase of a PDF, but it seems as though Wiley just joined the Safari book store, and the book might be available there. I'll try and find out for sure this week.

Another Publication Update

Just got the next version of the book chapters for my examination. I'm not 100% sure exactly where these fit in the process. It looks like they've had a good look-see from a copyeditor, largely for style, clarity, and consistency. (Any lingering "we" sentences seem to have been pruned, for example).

They produced a book-specific style guide, which is a listing of canonical forms for things like plugin names, capitalization of commands or tools and the like. It's kind of interesting to see if I can remember where each name or command was used.

Anyway, I'm supposed to have these turned around by Jan 2, so I'm reasonably sure we're still good to go to press in mid-January, and be released in mid-February.

Things I Learned

Some things I learned about Rails and writing while working on this book:

• The great benefit of working on a project like this book is that it enabled me to compress about two years worth of research into Ruby and Rails tools into six months. In my case, this was a great opportunity to really dig into some tools to find that I've only been using a fraction of their power and also really get a sense of how elegant and flexible the tools are.

• Ever since I learned how to type back on an actual typewriter in the mid 80s, I've always followed the old-time typographical convention of two spaces following a period. Which was burned into my fingers despite multiple people telling me that was a silly and counterproductive thing to do in the brave new world of proportional fonts. In fact, on the wx book, I actually did a global search and replace for a period followed by two spaces to get the manuscript to correspond with the publisher's expected conventions. Somehow, I managed to break that habit while writing this book.

• The hardest stylistic thing for me to get around was avoiding using "we" and "us". In other books and articles, I tend to introduce examples by saying things like "Now we should type the following" or "Let's see how that's implemented". Wiley/Wrox house style, though is to avoid "we" and write the examples as "Now you should type the following" or "I'll show you how that's implemented". Even more preferred is avoiding the pronoun altogether with "Here's how that's implemented" or "type the following". I'm not saying one way is better or worse -- I find the "we" style to be conversational, the Wiley editors clearly disagree. It did take some getting used to, though.

We're In Production Now...

I turned in the last chapter of Author Review on Monday, and Professional Ruby On Rails is now in production. Target release date is still mid-February, final page count will be in the range of 450.

I was able to keep the test-first nature of the code going through nearly all of it, which I'm really happy with.

The table of contents looks something like this (in theory, still subject to change...)

Chapter 1: Setting up a new Rails project using REST

Chapter 2: Using Subversion on a Rails project

Chapter 3: Users, secure logins, email authorization, etc...

Chapter 4: Rake, writing build tasks, and using CruiseControl.rb

Chapter 5: Navigation elements, including menus, tagging, search, and pagination

Chapter 6: Database topics, including legacy databases, relationships, and security

Chapter 7: Testing tools: RCov, RSpec, ways to test views and helpers, and so on.

Chapter 8: Rails and JavaScript. Using Rails and Ajax plugins for some common tasks. RJS. Testing RJS.

Chapter 9: ActiveResource, generating and reading XML data, including RSS feeds

Chapter 10: Time and Space. Managing time and time zones, using Globalize for internationalization

Chapter 11: RMagick, ImageMagick, MiniMagick, and other graphic tools. Gruff and Sparkline charts.

Chapter 12: Deployment with Capistrano and Mongrel

Chapter 13: Performance benchmarking and optimization

Chapter 14: Using Ruby metaprogramming in your Rails application

Chapter 15: Using and creating plugins. Testing plugins and generators

Chapter 16: ERB replacements and JRuby

Appendix A: Things to download

Appendix B: Other tools inspired by or similar to Rails

Two Pathfinder Blog Posts

Two things on the Pathfinder blog.

• Agile Publishing, on publishing experiences and agile methods.

• Live Ruby: Testbed, an attempt to work through a small test and metaprogramming problem live and on the blog.

Enjoy.s

Heads Up

Wow, I haven't been here for a while. Sorry about that. Here's the deal...

The Rails book initial draft went in about a week ago, more or less on time. (Well, on time for a slightly revised schedule). My understanding of the current schedule is that the author review phase will continue through November. After that, it goes to production, where I get another crack at revising thing that have changed. It goes to press toward the end of January for publication mid-February. If everything continues smoothly.

I'm pretty happy with how it turned out. I think I said almost everything I was hoping to. The main constraint was the tight schedule -- I'm hoping to get some newer features and plugins in during author review.

Oh, and I had another Pathfinder blog entry a few weeks ago. This one is about the CDBaby Rails/PHP thing that was kind of a flap way back then.

That's all for now, I'll try to get back updating the Twitter feed and get back to writing here and on the Pathfinder blog more regularly... Thanks.

Quick Book Update

Couple quick things while I have a minute...

• Just turned in Chapter 10 (of 16) of the Rails book. Still mostly on schedule for a turn in on October 26, not quite sure what that implies for a print date

• As I write this, the wxPython book is at 11 thousand and change on Amazon, the highest I've seen in months, which is probably a fluke. Weirdly Amazon says it's the #15 book on "Website Architecture & Usability", which would be great if it was, you know, actually about website architecture usability...

• New article up on the Pathfinder blog. This one is about Rails RJS templates and how to test them. It's partially a book preview, but really only an overlap of subject mat

There's more, but I'll get it when I have a chance.

Apple Fanboy Stuff

Naturally, I did have a thought or two about the new Apple products and the other announcements this week:

• While I certainly understand why somebody who had purchased an iPhone early would be annoyed by the price cut, I did find it kind of funny that many of the same analysts who said the iPhone would never sell at its original price were then jumping on Apple for dropping the price.

• Every now and then, you'll see an economist writing about how online stores should do more variable pricing -- charging a premium price to customers who are more willing to pay it. This week should be an object lesson in why companies don't do that. Since the people who are willing to pay more are usually your best customers, you run the risk of really ticking them off by making them feel like chumps. Which is generally not considered a good business strategy, I hear.

• My read on the price cut is that it comes from three factors:

  1. To keep the price in line with the new iPods, particularly the iPod touch.

  2. Taking advantage of lowered manufacturing costs since they are now making more of the touchscreens.

  3. Really try to drive sales this quarter to take advantage of what Apple perceives as a key moment -- not so much that sales have been disappointing, but that the really are trying to seize the moment.

• It could work, although the analogy to Motorola's strategy with the RAZR (gain market share at the expense of profits) is a little disquieting. On the other hand, Apple has a lot of benefits that Moto's cell division didn't, but it's probably not a good idea for me to list them...

• As for the products themselves, they seem pretty cool. Like just about everybody, I wish they had merged the two iPod models and combined a hard drive with the touch screen. I need to see what the iPod Touch reviews look like in a couple of weeks. It is annoying that Apple seems to have made video out a proprietary cable.

Boring Software Manifesto

Another blog post up on the Pathfinder site. This one is about Agile in general, and features what I think is the World Blog Premiere of the soon to be famous Boring Software Manifesto.

Enjoy.

The Rails Edge

I was fortunate enough to attend Pragmatic's Rails Edge mini-conference here in Chicago last week. I have two blog posts up on this at Pathfinder, the first is made up of quotes from my notebook, and the second is some general thoughts. Enjoy.

Pro Rails Book Related Things

A few things I forgot to put in the last book update:

• The Amazon listing has the book at 600 pages. That's almost certainly optimistic. The contract calls for 400-500.

• As far as the schedule goes, I'm currently hoping to turn the complete draft in on October 26th, which is about ten days after the original date. The publisher says that pushes publication out to April, six to eight weeks after the original date. I don't quite understand the math, but I suspect that it has to do with the logistics of availability of printing equipment and the like.

• Chapter Seven appears to be on track to be delivered this week, which makes the book just a smidge less than halfway done.

More On Test-Driven Development

My first post to one of Pathfinder's official blogs is up, it's a companion piece to the blog post here on Test-Driven Development, and you can find it here.

Book Update

Here's a couple notes on the current status of the Rails book and life in general.

• The Rails book is presently just about 30% done -- first payment triggered (yay!). I'm reasonably happy about it so far, though definitely too close to it at the moment to have a clear sense of its quality. I do like the way the test integration is working out -- it seems to help my descriptions of functionality to have the tests there.



• The book is now available for preorder on Amazon. Here's the 10 print "hello" affiliate link, which will conveniently linger in the sidebar of this blog forever.



• I don't think I ever mentioned this, but the last results I got on the wxPython book (for Q1 2007), showed that sales were starting to slump. Although the data was weird -- US sales were down to about 1/3 of the previous quarter, and US returns were way up, such that net sales were almost zero. At the same time, international sales were way up, with the total affect being a drop to about 1/2 or slightly less from the previous quarter. We've now passed the 6700 mark in total sales.



• Apple fanboy stuff: One of the nice features of my new job is that my work computer is now a MacBook Pro. Very nice machine, well designed, very fast. Battery life is decent. Lots of the little design details you've come to expect -- I particularly like the magnetic power cord. Now if only I could use the thing without wearing oven mitts, I think I'd be in business.

And Now, A Special Announcement

Sorry for the radio silence for the last week or so, but I was waiting to be able to announce this:

Today I started a new job at Pathfinder Associates, as a senior software engineer in charge of Ruby on Rails projects. Needless to say, I'm thrilled to be back in the Web game professionally, and even more thrilled to be working on Rails projects.

Everybody at Pathfinder has been super great so far, and I'm looking forward to doing exciting and fun things.

I'll also be blogging on their web site roughly once a week, either at their Technical Development blog or their Agile/Ajax blog.

If you happen to be one of the maybe five people who read this blog regularly, don't worry, I'll continue to post here with updates about the book and thoughts about programming and technical publishing that wouldn't quite fit on the Pathfinder site.

A Customer!

Well, that's a pleasant surprise. Somebody named Stephen has left a comment. And not one of those spam thingies, but some actual relevant questions about tech publishing. Answering them seemed like it might be fun..

1. I noticed there is a pdf version available of your books. Is this something you or the publisher insisted on? Have people shown an interest for this version or are they still overwhelmingly favouring the hard copy? Aren't you or the publisher afraid that the pdf will end up on shady torrents?

I honestly don't remember an explicit decision being made over whether or not an e-book edition would exist. As far back as I can remember, they wanted one and we wanted one, so no problem. I'd imagine that the publisher's wishes would override the author's in this respect if it came down to it.

I don't have the Manning contract for the wxPython book in front of me, but the Wiley contract for the Pro Rails book says "the Publisher shall publish the Work in such style and manner as the Publisher deems appropriate", and I think the Manning contract had similar language.

I'm in favor of offering e-books because they are easy to store, easy to update, and easy to search. From the publisher's standpoint, they have a relatively low cost to produce and people want to buy them, so it's a potentially large win.

As of the most recent statement I have on the wxPython book, e-book sales are just under 10% of total sales. I suspect that some publishers have much higher percentages -- Pragmatic, for example, really promotes their e-book sales. The Jython book is not available for sale in an e-book form, not even on O'Reilly's Safari Bookshelf. Which is weird, because they (at least used to) offer a competitors Jython book on there...

While I'm on the subject, I don't know right now if the Pro Rails book will be available via pdf. Wrox doesn't seem to do pdf much, and I don't know if they plan on starting.

Funny you should mention torrents, because I relatively recently got an email from Manning that they were trying to get the book removed from a torrent site. So I know it is, or at least has been, out there. I'd say Manning takes this kind of thing pretty seriously, but it obviously hasn't stopped them from providing pdf files. So far, I haven't seen any evidence that this kind of thing is affecting sales, and I'd be very surprised if such evidence presents itself. (Standard Disclaimer -- I don't speak for Manning, and I don't speak for Robin Dunn. If you broadcast a torrent of the book Manning will try and stop you.)

2. Technical books typically have a short shelf life and would probably benefit from frequent updates (e.g. incorporation of errata, version updates etc.). Wouldn't a more flexible way of publishing, with small, frequent runs (or even an outright on demand model a-la-Lulu) be better?

Yes, I could see where having small, frequent updates could be better for the book reader -- this is essentially what Pragmatic does with their e-books.

However, the infrastructure and overhead for doing this in printed books would be pretty significant, even with some kind of publish on demand model. At the very least, the cost to print a copy would go up, probably dramatically. Then you have the secondary problems of managing which errata went into which revision, continually updating the layout when needed, dealing with people who want printed books upgraded. The headaches get big quickly.

That said, something along that model is inevitable, at least for e-books. Eventually, other publishers will have processes as streamlined for this kind of thing as Pragmatic seems to.

This concludes todays episode of Ask A Guy Who Once Wrote A Book. Tune in next time. I hope there's a next time...

A Little Birdie Told Me

In the interests of being able to push out quick updates on the book's progress, I've created a Twitter account for the book. You can follow that account on the sidebar of this here blog, or at http://twitter.com/noelrappinbook -- there's also an RSS feed.

Please remember that any and all information about the book is subject to change at whim. Enjoy.

Book Updates

It's been about a week or so of continued radio silence, so I thought I'd pop in with an update.

I'm in the middle of chapter three of the Rails book. I think it's going well, but nobody other then me has read the chapters yet, so that's easy to say. My first milestone date is the end of the month, and four chapters done -- that's about one-quarter of the entire book.

I did want to say a few things about how somebody like me comes to be writing a book like this. I was first contacted with this idea in early February. If you're keeping score, that means that this project spent about five months going from a gleam in an editors eye to a signed contract, and it will spend about five months going from a manuscript to a printed book, but only about four months for me to actually spend on the writing.

Anyway, I have an agency (Studio B) that represents me for technical writing. Sometime in early February, I received an email from them saying that an unnamed major publisher was looking for a writer for a Rails book, and was I interested. I don't know exactly what happened between the agency and the publisher before that, but Studio B is often approached by publishers looking to match an author with a topic.

I was very interested -- I'd been kind of hoping to do a book on Rails for some time. I talked to an editor at Wiley about what kinds of things they were hoping for and put together a proposal. At the same time, they also expressed interest in a proposal on a different topic, and I did that as well. The proposal contains a description of the market for the book, and a description of the outline. The goal is to convince the publisher that the book is worth doing, and that the author is a good person for the job. In this case, since the publisher had initiated the process, making the case for the book was easier than it might otherwise have been.

The publisher liked the proposal. But if you were wondering who pays attention to Amazon reviews, I was specifically asked about the difference between the ratings for the Jython book versus the wxPython book, to reassure them that the higher ratings for the wx book were not solely due to the co-author.

After that, there was some time spent waiting on the two proposals, and which one the publisher wanted to do. At various times, all four possible answers were given (the Rails book, the other book, both, and neither). Eventually, they settled on doing the Rails book. I was informed of that decision in early May, and then my agent and the publisher began negotiating over contract details. I don't think I can really say much about that, but most of the time is not spent on money, but rather on details of which side is responsible for various parts of the finished product beyond the text itself, and who is liable for what if things go wrong (hint: the author is usually liable...) We also settled the length of the book and the schedule.

Oh, and you know the author pictures that appear on the cover of a Wrox book? Rest assured that the pictures are one very well covered topic in the Wiley/Wrox contract.

And that's how a bill becomes a law. I'm enjoying working for Wiley so far, the people I've dealt with have been enthusiastic and helpful. Now, I think this is long enough and I should probably get back to the book itself...

Announcing: Professional Ruby on Rails

I'm pleased to be able to say that I've contracted for a new book, Professional Ruby on Rails, scheduled to be available in "early 2008", hopefully February or March. The publisher is Wiley, through the Wrox imprint -- the ones with the red covers and the author's picture on them. Wiley wanted me to be sure and mention that the ISBN number is 9780470223888, so you'll be ready to pre-order it the second that becomes possible.

The imagined reader of the book is somebody who just finished a beginners book on Rails and is suddenly asked to build a complete public web application. The idea is to cover the kinds of topics that nearly every Rails site will deal with -- things like users and security, performance, deployment, navigation, team development. For each topic, I'll be discussing common solutions, existing tools, emerging standards and so on. There will also be a strong focus on writing tests throughout the book. Hopefully, I'll be able to go into more detail as more of the book is written.

I'm excited and scared. This is my first solo book, which both simplifies logistics and leaves me without a co-author to catch me when I'm totally off base. I know Rails pretty well, but there's nothing like facing a skeleton book outline to impress upon you exactly how much you don't yet know. Research has been lots of fun, though -- the Rails online community is fantastic.

Watch this space for more info about the book, the writing process, and anything else related. If you have a question, or if there's a specific feature that you think should be included, please do leave a comment or send me an email.

Another IBM Article

It's not exactly part five of the four part GWT series, but it is closely related. Please check out my newest article on IBM Developerworks: Simplify Ajax development using Cypal Studio for GWT.

I actually wrote this a few months ago, when the tool was still called Googlipse, and the final publication was delayed a bit while I rechecked all the code and instructions, and changed the name throughout.

One note: it seems as though the GWT 1.4 release candidates do not currently work with Cypal -- you have to use the GWT 1.3 version.

Enjoy.

Didn't I Say I Wouldn't Compare Languages?

I posted a version of this to JJ Behrens' Blog post about Ruby, and decided it was probably worth also posting here.

I use and like both Ruby and Python, here's why...

Things I like about Ruby with respect to Python

1. I think Ruby is the only language that gets accessors right. The thing you want to do 95% of the time -- simple access -- is trivial, and the thing you want to do 5% -- something fancy in your accessor -- of the time is a pretty easy override. Plus, it's nicely encapsulated, and you never have to wonder if that thing in another class is accessed directly or via a method.


2. Blocks. I find that my kind of functional style flows pretty easily in Ruby. It's also not hard to pass named functions. When I first started with Ruby, it used to bother me that you couldn't tell from a method signature if it took a block, but I've since managed to deal.


3. Being able to add method to existing classes. Although I know this really bugs some people, sometimes adding a method to String cleans up the code significantly.


4. Expression-based syntax. The implicit return in Python always causes me at least one error per sessions. Plus I like writing a ternary operator as an actual if statement.

Things I like about Python with respect to Ruby

1. Consistency. Python enforces it. As a result, my Python code is more likely to be readable by me six months later. Ruby tends to be more concise, but some parts of Ruby are still a little too Perlish...


2. Real keyword arguments (coming to Ruby soon). The Ruby syntax magic of gathering up map pairs into a hash is sort of annoying.


3. I find Python's multiple inheritance mechanism to be easier to understand then the Ruby package/module setup. It always seems like I'm messing up the difference between 'require' and 'include'...


4. On balance, I prefer Python immutable strings to Ruby's mutable string/symbol split.

WWDC Keynote, 2007

I think I'll have to join in the general chorus of the underwhelmed. Bullet points:

• The new desktop and finder sure look shiny. The dock stacks do look kind of useful, and having a dedicated downloads folder strikes me as a classic kind of Apple UI move.


• Having the finder be visually similar to iTunes strikes me as, on balance, a good idea. And, although I don't find Cover Flow tremendously useful in iTunes, I can see a place for it in the Finder. Especially if you can page through PDF files and other similar tricks.


• I don't think the power-user critics of the Finder are going to be much impressed, though. For one thing, no tabs. (Come to think of it, I'd like tabs in iTunes, too...)


• It was really weird to see so much time spent on features that have already been demoed and known for a year. I was definitely hoping for more new stuff.


• Core Animation looks really cool, and if it's half as easy to use as advertised, there's going to some very pretty Mac apps coming down the road.


• Safari for Windows, which initially sounded kind of weird, actually makes sense to me. It's probably not a very large development effort, and anything that makes Safari more valuable as a development platform for web developers makes Safari more useful, and by extension, the Mac platform more useful.


• I did not have good luck with the Safari betas, though. Windows side, the beta crashes when I try to set my proxy. Mac side, the address bar doesn't do anything when you enter an address. Worse, it broke the nightly WebKit builds that I've been increasingly using as my primary browser, so I had to uninstall.


• As far as I can tell, developers seem to be downright irritated by the non-SDK announcement for the iPhone. The thing that's not clear to me is whether the webapps would have any hooks at all into the iPhone OS -- at least one of the liveblogs I was following on made it seem like there'd be some nod to tighter integration that a typical web app. Anybody else get that? Because otherwise, to go up and make the big announcement that the web, you know, still works even on an iPhone, that's just strange.


• They placed the iPhone announcement for 6PM, which feels more humane than making people stand in line for a 9AM open


• A lot of notable non-mentions: ZFS, iLife, iWork, any hardware, resolution independence, and so on...

Programming Perl, Personal Edition

Due to circumstances somewhat beyond my control, I find myself working in the largest Perl project I've ever done. Now, I'm not in the least interested in a "my language is better than your language" deal because a) this strikes me as very well covered territory, and b) it seems particularly pointless as the Perl 6 team appears to be doing a nice job of taming Perl's more rococo features.

There are, of course, some things I did want to mention...

• I'd be totally lost without the very large assistance of Damian Conway's Perl Best Practices book. It's an excellent guide to the minefield of all the things Perl lets you do, pointing you to the things you actually should do (especially on a large program). It's also refreshing to see a Perl book that doesn't treat the ability to write unreadable code as some kind of rite of passage or inalienable right.


• I didn't actually intend to use all three homonyms of "write" in that last sentence, but I think I'll leave it in...


• As a result of reading Conway's book, and somewhat in self-defence against my own Perl skills, I seem to be writing the most verbose Perl in the history of the known universe. I think I may have written more compact Java.


• This is also the first time I've worked this closely with a code-tidy utility, and I think I like it. Usually, I advise against doing things like lining up equal signs because it's too much work to maintain, but with perl tidy, that's not an issue, and it is more readable.


• Perl's cultural insistence on using plain non-jargon words is usually kind of charming, and only occasionally irritating (quick, rank "carp", "cluck", and "croak" in order of severity...)


• My most consistent error to date? Forgetting to dereference the argument to grep or map, which I've been doing at the rate of about twice a day for the past two weeks. Since the reference gets promoted to a single-element array, this is a little annoying to track down. Luckily, unit tests were designed for this kind of thing...


• I wanted to quick mention a couple of formatting things that Conway recommends in his book that I've never seen in other language's style guides (maybe I should get out more...). First is the "cuddled else", which is the placement of an else line on the same line as both the close of the if block and the start of it's block: } else {. A quick google on the phrase confirms that it's mostly a Perl thing -- I've never seen a non-Perl style guide comment on this. Conway, and I see that he seems not to be alone in the Perl world, recommends dropping the else to the next line. The idea being that it's more visually clear because the else is now in line with it's close bracket just like any other block. I had always thought that the Java/C style was there to visually connect the else to the if that had just closed.


• Conway also recommends breaking up long lines before the operator, rather than right after an operator. I'm reasonably sure that's different from almost any other style guide I've ever seen, but I have to say, it works for me. The idea is that you are more likely to see the visual cue that the line is a continuation if the hanging operator is at the very left of a line rather than the right. I think it's working for me partially because the split lines look so weird to me that I look more closely to see what's going on. Whatever the reason, it does seem to be making the code more readable for me.

iTunes Plus... A Fresh Lemony Scent, Perhaps?

Couple thoughts on Apple's first foray into the brave world of non-DRM'd music:

• I think the most of the user experience in iTunes is handled nicely. There had been some worry about this -- I seem to recall some speculation before the EMI announcement that Apple would only take out DRM if they could do it store-wide, and keep things simple. Anyway, the iTunes Plus branding and the simple option to either always or never see the plus songs seems to work just fine.



• That said, it's very odd that the upgrade songs feature does not allow you to select individual albums or tracks -- it's all or nothing. That's not a good user experience.



• I'm a little surprised by the album upgrade, as well. Since they seem to have mostly held the line on the $9.99 album even for Plus albums, it's not completely clear to me why I have to spend $3.00 to upgrade my old $9.99 album to a new $9.99 album.



• I do hear some difference in sound quality on the new tracks. Granted that a) I know that there's supposed to be a difference, b) I have really cheap sound equipment and c) not exactly professional-quality audiophile ears. Even so, it seemed to me that sharp sounds like percussion and acoustic guitar seem to pop out of the background a little more. The effect is more obvious in my car than on my cheap headphones. Go figure.



• The big controversy, of course, is the fact that account information is still embedded in the non-DRM files. (Unless I'm mistaken, that information was in the DRM files, so before we get all conspiracy theory we should at least consider the possibility that it was either overlooked, or a pain to remove for some reason). I was amused to see two different blogs where the blogger breathlessly posted this dastardly information only to have commenter after commenter say it isn't that big a deal. Which it isn't — it's not like Apple removing DRM from the music somehow changed copyright law... I'll grant that it's always a little creepy to find a personal infobit somewhere you don't expect it, but I'm having a hard time getting worked up over it, especially since I expect it'll be fully hacked by the time I finish typing this sentence.

Text Auditor

I hate Microsoft Word. I feel that I came by this rightfully, after a whole book's worth of numbered lists that refused to line up, images that refused to stay put, and the truly irritating indexing interface.

For a long time I'd sort of rant about how word processing was this core user task and we still couldn't figure out the right UI for it. I'm not totally backing off that, although I've also read people ranting that text editing was solved 20 years ago by Emacs and Vi, and there's no point in looking at anything new, which achieves a level of crankiness that makes me look calm.

What occurred to me as I was thinking about writing about text entry and UI was the sheer number of different programs that I use for various kinds of word processing or text editing. Most of these are optimized for a specific set of activities, and do that particular job well enough that it's worth learning a new program in order to get that benefit.

More and more, I find myself also using tools that help me with text cross-applications, like generic text expansion tools, or clipboard history tools, or even monster aggregators like Quicksilver. Put that way, it sounds a little bit like the OpenDoc dream, where your spell checker would come from one place, and your text editor from another, and the font manager in from another. But OpenDoc was about components instead of applications and looking at the list below, it's pretty clear that applications aren't going away anytime soon...

So here's a list of all the apps I can think of that I do some kind of text edit in, with some comments.

Adium/Pidgin -- IM Clients (Adium Mac side, Pidgin in Windows, plus another couple for internal work things). None of these has a ton of text editing support, although I do wind up typing a fair amount of text into them over the course of day. Pidgin has a great name, but I really wish it had one piece of AIM functionality, namely the ability to read text in a different size then you send it.

Eclipse -- Currently it's my Windows side Ruby/Rails editor of choice, although I'll probably change my mind six more times before I settle on something. It's also my Windows Perl editor of choice, as it seems to be the only free editor that does syntax checking.

GMail/Google Docs -- Gmail, obviously, used for email, although I do sometimes use it as quick storage for text I want to be able to work on from multiple locations. You're supposed to use Google Docs for that kind of thing, and I do, sometimes. It's great for collaborating (we used it for final notes on the manuscript for the wx book, for example). But for normal use, it's just a hair too unresponsive, and the UI is just a touch awkward within the browser.

IntelliJ IDEA -- Java editor of choice. Still the most fully featured of the big Java IDE's, although the other's are catching up. A big memory hog, though.

jEdit -- Window's side default text editor, especially for Python. Been using it for years. Very nice feature set, I'm used to the controls, decent syntax coding for the languages I use.

Jer's Novel Writer -- I don't use this as much as I'd like, but I'm putting it in here as a great example of tuning a text entry program to a specific use. In this case, writing fiction. Nice features include easy annotating and the ability to specify separate display and printing formats -- very useful for keeping your print document in manuscript format.

MarsEdit -- Well, I'm writing this post in it. Mac side editor of choice for blog posts. Why did I spend $25 on this when it's functionality is pretty easily replicated from TextMate? Good question. It's got a very clean UI, and I like that it previews while you type. And if I need to do something fancy, it interfaces with TextMate.

MS Word -- Windows word processor when forced to use it. Word actually isn't that that bad if you stay within the confines of a four-page office memo. Once you add styles, though, it's a mess. Actually, I don't think anybody's really solved the UI for a WYSWIG styles system -- which is one reason why I use HTML, Textile, or Markdown where I can. I feel like I have much greater control over the styling if it's all in text.

NeoOffice -- Mac side word processor of choice, although I rarely use it for the reasons given above. I've gone through all the free or free-to-try alternative word processors on the Mac, and NeoOffice is the one I keep coming back to (especially since the newest version, which fixed some performance issues).

Outlook -- Windows email program. Possibly the worst styled text email editor around. I think it's the only one that, if you insert a paragraph in the middle of a quote from a previous email, keeps the quote formatting on your new text. This is, shall we say, not helpful.

PowerPoint -- I guess it's a text editor, of sorts. This is here mostly for a mini-rant... I know that everybody says that effective presentations should have minimal text on each slide. I even agree. But... in many environments, including lectures and a lot of corporate situations, the slides become a de facto deliverable to people who are unable to make the original meeting. If you don't have enough text for those people to follow along, they will get angry...

TextMate -- Mac side programmer editor of choice. I tried a number of different editors when I switched to Mac and realized that jEdit didn't really play nicely with OS X. I find the TextMate UI to be unusually clean, and it's the most powerful and extensible text editor not written in Lisp.

VoodooPad Lite -- Mac desktop Wiki application. I'd probably use this more if my daily work were Mac side. It's very nicely done.

That's a lot of applications. I'm pretty sure I missed some, at that. I think my point is that specialization is the way to solve the text UI dilemma. Still, needing 13+ apps to solve my basic text entry needs.... seems less than optimal somehow.

A Program Note

This is for the two or three of you that are subscribed to this blog via RSS feed -- I've just added a FeedBurner feed, and if it's not too much trouble, it'd be great if you could switch over to it at:

http://feeds.feedburner.com/10Printhello.

The "Subscribe" link in the sidebar will also work.

Thanks.