I Feel Textastic

So, back in the summer when I started my bizarre quest to edit my book on the iPad, I had three requirements.

• Be able to read the book files from Dropbox


• Support for editing HTML/XML files, syntax coloring, extra keys, something like that.


• TextExpander integration to make it easier to type the markup tags.

It quickly became clear that I was the only person in the world looking for this exact set of features.
There wasn't any editor that met all those requirements, so I bought a bunch of other editors and obsessively reviewed them on this very site. Naturally, because sometimes the universe loves irony, a new version of editor meeting these features was released a mere week after I turned in the final draft. It's called Textastic, and I'm typing on it right now, though I'll probably edit this in MarsEdit later.

Summary: Textastic is nice. It's got some features that I really like and an overall feeling of being polished. I think it would work fine to do some basic editing on a code file, though it's obviously not TextMate or Vim. As a writing/blogging tool, it's close, but I think it's a point releases or two away from being fully baked -- it's about 80% baked at the moment.

Now here's the part where I give enough details to let you know whether to spend your money. Textastic is $9.99, which isn't a lot in the absolute sense, but is more than some of the other tools that I'd be comparing it to.

I'm noticing kind of a conceptual split among the cloud/dropbox text editors. Some, like PlainText, try to make it feel like you are actually editing the file on the remote server, primarily by automatically saving the file to the cloud. Others, like iaWriter, clearly want you to feel like you are editing on the iPad, and only backing up to Dropbox when you want. Textastic is clearly in the latter group.

Pressing a globe-shaped icon from the main display flips the text edit pane over to reveal a dual-pane file browser. Local files on the left, remote files on the right. Remote files can come from Dropbox, FTP, or WebDAV, and you can download them individually or folder-by-folder. The file structure on the iPad does not need to match the file structure remotely, which is nice. Even better, Textastic keeps track of the remote source of each file. When you are editing the file, the standard-looking export icon allows you to easily upload or update the file being worked on, making simple what might otherwise be a pain. It's easy to download, say, an entire Rails project at once, but you are going to want to delete a lot of directories -- Textastic will even grab the Git subdirectory.

Actual file editing is largely what you'd expect. Easily reachable and usable settings allow you to choose from five monospaced fonts, set the font size, plus turn on or off auto-correct and TextExpander. You can also pinch in the text edit field to zoom in, effectively increasing or decreasing the font size. This is more effective than I would have thought, although it does have what seems to be an unpredictable relationship with the actual font size as you set in a dialog.

Textastic has syntax coloring for just about anything you'll want, and even better, allows you to specify the syntax for each file. There's a find and find-and-replace dialog, and line and column position is discreetly displayed in the upper right. The soft keyboard has an extra set of keys containing programmer specialty punctuation, including parens, brackets, braces, and greater-than less-than, making HTML typing possible. HTML and Markdown can be previewed in the app.

There's a lot of features here and they are nicely tied together. I'm finding Textastic to be decent at tweaking existing code files, and I think I would have been happy to edit or write Prag book files (which are essentially XML) on it, especially with a little TextExpander love.

Using it as a blogging tool, though, exposes some weaknesses that will hopefully be addressed in point releases -- there are a couple of bugs around auto-correct, and some typographic things about spacing when it's wrapping long lines. Both of those are kind of minor. One thing that is weird is that the text field is noticeably sluggish. Typing on the bluetooth keyboard, I can easily get a word or two ahead of the display, and I can even get a little ahead of it on the soft keyboard -- I assume that the calculations for syntax coloring are slowing it down. This can be frustrating combined with the autocorrect bugs.

Still, those are minor quibbles in what is overall a useful app. As an iPad code editor, it's the best I've seen, and it's very close to PlainText or iaWriter as a quick typing app. I'm looking forward to see where this one goes.

A tribute to the humble page number

I've been doing a lot more reading on eBooks since I got the iPad. For the most part, I really like it.
I've been using three different eReader programs: Apple's iBooks, the Amazon Kindle, and the Barnes & Noble Nook. You'd think that an eReader would be basically similar between apps, but there are definitely differences in how the apps feel.

Here's one little example: how does each reader app marks your progress in the book? Physical books have this nice technology called the "page number", which, when coupled with "seeing how thick the book is on both the left and right side" gives you a good sense of how much you have to go before you have to find another book to read.

EBooks of course, don't have pages or thickness (though, for some reason, when I hold my iPad as a reader, I put my finger between the iPad and the Apple case flap, as though I was folding over a paperback book.) Each eReader that I use has a different metaphor for progress. And I'm not sure which I like best. It fascinates me that three different teams looked at this issue, which would not seem from the outside to be that complicated, and came up with three different answers.

The Kindle uses what they call "locations", which are basically virtual page numbers placed at (I assume) regular intervals in the text. The Kindle tells you what location you are at (well, it tells you what locations are currently displayed on the screen, there is usually more than one at a time), and it tells you what percentage of the book you have completed.



There are a couple of advantages to this setup. The biggest is that the locations are stable if you change the font size, so location "2345" always refers to the same place in the book. Because of that, I assume you could actually use a Kindle location in a citation, if you were so inclined. (Okay, you probably don't care. But if you were a student, being able to cite based on an eBook seems increasingly important...) The percentage progress through the book is a reasonably user-friendly way to go. The downside, obviously, is nobody knows what the hell a location is, so saying that you are on "location 2345" has relatively little actual meaning.

Apple's iBooks app went a different way. iBooks takes the nuts-and-bolts approach that a screen's worth of text is a page and will tell you that you are on "page 45 of 456", along with a set of dots that shows progress through the book.



The nice part about this approach is that it is concrete and directly related to the device you are using. You know exactly how many screen taps there are -- iBooks also tells you how many pages are left in the current chapter, which is a genuinely useful piece of information. The problem is the flipside of the Kindle setup -- the page numbers are dependent on font size and device screen. If you change the font, then iBooks recalculates the page you are on. (It also takes a noticeable amount of time to calculate when you open a new book.) You can't use the page number to reference a permanent part of the book. Still, for casual reading, it's hard to deny that the page number that iBooks presents is the most relevant and useful information. Although, strictly aesthetically, I don't love the row of dots, it doesn't read as a progress indicator quite as easily as the other two apps.

The Barnes & Noble Nook app does something different still. It presents page numbers based, I think, on the pagination of the print book. In other words -- and I realize it's slightly insane to define a page number based on something else -- it's essentially the Kindle location, but with location markers placed at the start of each print page.



I can't decide whether I think that's the best of both worlds or the worst -- I like the look of it best, though. Like the Kindle, the Nook's locations are permanent, and therefore citable. There's a certain kind of familiarity in keeping page numbers in a familiar range. That said, it's genuinely a little weird to turn the virtual Nook page and not see the number changed -- the first time I noticed it, I thought it was a bug.

So that's one tiny little usability decision that turns out to be complicated enough to have three separate answers, and even having used all three I'm not sure which one I like best. Superficially, I like the iBooks approach, I think, but I also think that a permanent location marker is needed. As usual, it leaves me with respect for how complicated even easy decisions get once users are involved.

Rails Test Prescriptions Out Of Edit

Very quick status update:

Rails Test Prescriptions is out of copyedit. It should head for typesetting on Monday for a probably ship date in mid-February.

Right now, we're in the phase where I go over the copyedit and whine about things. Actually, this copyedit has been pretty clean, probably the cleanest I've ever had.

By way of contrast, when I did the wx book, the copyeditor did not realize that "Python" and "wxPython" were two different things, and decided to unilaterally change all instances of "Python" to "wxPython", apparently in the belief that I had made the same mistake 1500 times.

Though if there's one thing that copyediting proves, it's that I am capable of making the same mistake over and over again. Here are some things that keep coming up:

• 
  The copyeditor changed all instances of "plugin" to "plug-in", which may be the dictionary usage, but isn't the common Rails community usage. I've changed them all back, except that I changed a bunch of them to "gem".
  



• Apparently I add extra commas to sentences a lot. In my head, I tend to think of a comma as indicating a pause when I read the sentence aloud, which leads me to put commas before words like "and" and "or" in cases where the structure of the sentence doesn't require a comma. I'm not arguing about any of these.



• There's a pretty consistent change where I'll write something like "this only happens when" and it's changed to "this happens only when". I'm assured that the second form is correct, but it still sounds weird to me.



• My probably-annoying tic of putting a) outline notation in b) a sentence was removed. I get why, and I didn't put them back, but I still like the slightly staccato rhythm and extra emphasis from adding those notations to a list. In a couple of cases I rewrote the sentence to get a similar emphasis a different way.



• One surprise for anybody who has been following this book since the beginning is that we finally seemed to have flushed out all the its/it's mistakes, or at least the copyeditor doesn't seem to be finding new ones. I consider that a triumph -- this was a mistake I made A LOT --, aided and abetted by a number of people who made corrections early on.

It's an open question how much of this makes a difference to a reader. I like to think that making each individual sentence clean and consistent lowers the amount of friction between the text and the reader's brain, but then, as an author I would say something like that.

Mock Me, Amadeus

Nick Gauthier's post about mock testing, got some attention and I was kind of opining about it on Twitter, but it's well over 140 characters, so lucky you, I've decided to take it to the blog. (Do read Nick's post, and then then comments, with Nick and Dave Chelimsky and others discussing the topic.)

I want to back up a bit from the "Mock testing is bad for you and hurts puppies" versus the "Mock testing will make your breath fresh and cause you to lose weight" split argument. (It's possible I might be oversimplifying the two sides of the argument). I've used mocks badly and I stopped using them for a while. I want to discuss how I've started to use mocks with what feels like effectiveness. I'm not all that confident that it's the best way -- I expect to have changed my mind again in six months -- but it's working for me and I like it.

Take a fairly typical Rails feature, maybe a list that's filtering based on certain criteria. I think we can do this discussion without specifying exactly what the criteria is, let's stay abstract.

From a user perspective, the only valid test is the acceptance test, which is "when I submit this form describing my filter, I see the objects that I expect".

From a developer's perspective, though, that's not enough information to fully test or code the feature. Specifically, it's too big a chunk of code to do in one TDD step, so we need to break it into smaller pieces that we can write developer tests against.

The TDD process is supposed to ensure that any change in program logic is driven by a failed test. In this particular case, we'll most likely be changing the program logic in two places.

• The model object or objects being discussed needs to change to take in parameters from the user request and return the expected set of objects.


• The controller that is the target of the user request needs to convert the Rails request parameters to some kind of call to the model object.

I'm assuming a typical Rails practice thin controller structure, where the controller basically makes a single call to a model that does most of the work.

We're getting to mock objects, promise.

Okay, we've written a Cucumber acceptance test and it's failing, so we need to start working on the actual application. It doesn't matter technically whether we do the model or controller first, but for the purposes of storytelling, let's talk about the model first.

The model testing is straightforward. We have some set of cases, usually the happy-path case, plus exceptional cases like blank input. Maybe we'll test for case sensitivity or partial matches, or whatever the business logic requires.

For our purposes here, the main point is that we don't mock the calls within the model layer. They way I do it, even if this filter spans multiple model objects, I don't use mock objects within the model layer, for most of the reasons that Nick lays out in his post.

You might argue that the database itself is a different layer than the model layer, and you could mock the actual calls to the database itself so that your tests don't have the overhead of dealing with the database. I think that's a useful line of argument in some web frameworks, but in Rails I generally haven't found that helpful, except maybe for pure speed benefits. I do, however, try to write as many tests as I can without actually saving objects to the database.

Okay, model tested. That brings us to the changes to the controller. (To keep this a little less complicated, I'm leaving the view test out of it, these days I tend to let Cucumber stand as my view testing, on the theory that if there's view logic that doesn't present an acceptance-testable change to the user, then it probably shouldn't be view logic). So, what is the behavior of the controller that needs to be tested and built?

There are two different ways of describing the controller's behavior, each with a different implication for specifying that behavior. I'm not saying that one is right or one is wrong, but I do think that the kinds of other tests you are writing make one plan more useful than the other.

• The controller's job is to take the user's input and present to the view the expected set of objects.


• The controller's job is to take the user's input, send it to the model.

The difference, I guess, is between a conductor and a conduit -- in both cases, the controller dispatches the work elsewhere, but in the conductor view, the controller object has more perceived responsibility for the behavior of the system.

Or, to put this another way, if the model behavior is not correct, should the controller test also fail? Thinking of the controller in the first way, the answer is yes, the controller's job is to deliver objects to the view, and if the calls are incorrect, then the controller has also failed. In the narrower view of the controller's responsibilities, the controller's job is just to call the model layer. Whether or not the model is correct is somebody else's problem.

Before I started using Cucumber regularly, I tended toward the conductor metaphor, but when I also have Cucumber tests, controller tests written like that feel very redundant with the acceptance test. So now I'm more likely to use the conduit metaphor and just test that the controller has the expected interaction with the model.

Which means mocks. And that's largely how I use mocks within my application -- to prevent the controller layer tests from directly interacting with model code. (And I using mocks to avoid dealing with an external library, but that is a different story.)

There are two potential problems with using mocks like this. First, the mocked controller test doesn't fail if the model is wrong or the model's API changes. If the mocked controller test is part of a larger test suite, though, this isn't an issue. The controller test won't fail, but something else will, either a model test or an integration test. You might even argue that limiting the number of failing tests from one code problem makes the issue easier to diagnose. (You might also argue that the cucumber test makes the controller test irrelevant. I don't agree, but you might argue it). So this issue doesn't bother me much.

The second thing to look out for is the inverse -- the mock test will fail if the API to the model changes even if the actual behavior at the end hasn't changed. I have more trouble with this one, but it does tend to work out (while admitting that it has been annoying when I've gotten sloppy and used mocks to cover an uglier API). Assuming that the model API is reasonable, and that the controller's mission in life is to call a particular API, then if that API changes, then in some sense the controller's behavior is changing and that should trigger a failed test.

However, in order to prevent this kind of problem, you really do need to use your tests to drive code structure and the clean API between the controller and the model. If the test mocking seems like it's becoming a burden, then that indicates that the code is not properly factored.

I'm not yet prepared to defend that all the way to the death, as I've said, I have been bitten by cases where mocks made the tests more brittle by exposing the internals of the model to the controller in more detail then necessary. Almost always, that happens on legacy systems that were written without tests and might not have a clean separation between model and view concerns. I have much, much less trouble with newer code that has a TDD-accented modular design.

You can mess yourself up badly with mocks. I for sure have, and it kept me away from RSpec for a long time. I've gotten better at using them, I think, and have started using them more frequently, but pretty much as I've described here. It's what works for me this week.

The Eternal Battle of the Keyboard and the Mouse, A Sidenote

This week I did Obtiva's weekly Geekfest with a presentation/bookreport on the Making Software book. I'll write more about that book later, right now I want to expand briefly on something I referenced at the end because it's one of my favorite tech/UI examples to talk about.

We were discussing the relationship between an experts gut feeling about what works and what can and can't be shown using empirical evidence. Specifically, the difference, even for experts, between our perception of our effectiveness and our actual effectiveness.

I referenced something from Bruce Tognazzini's book Tog on Interface about how... well, here's the exact quote, because I didn't get it completely right from memory. This was originally written in August 1989 -- Tog is talking about the UI guidelines for the original Mac models.

We've done a cool $50 million of R&D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

• Test subjects consistently report that keyboarding is faster than mousing.


• The stopwatch consistently proves that mousing is faster than keyboarding.

This contradiction between user-experience and reality apparently forms the basis for many user/developers' belief that the keyboard is faster.

One thing I love about mentioning this example to a room full of developers is that everybody leaps in with "But I use Vim, and my keyboard shortcuts really are faster..." Sure. You are a unique snowflake.

To be fair, Tog is talking about users new to the mouse, though that hardly weakens his point, and he's mostly talking about common tasks on the order of cut, paste, and save, not the kind of super powered keyboard stuff that Vim users use (or, you know, TextMate users, it's not like I ignore keyboard shortcuts).

That said, the basic argument -- that the time spent trying to remember the keyboard shortcut is cognitively engaging, while the time spent on the mouse is boring and thus seems longer -- still sounds plausible even for Vim users. Frankly, I don't know what similar studies would show today. I'm not even sure you could design a similar study about Vim, since Vim expertise is such a huge component of effectiveness.

At Geekfest, I combined details of this with a different study about whether the Mac's top-of-the-screen menu bar was faster than Window's style menubar in the window. (Hint: it is. Still.)

The point is the Tog book is great. Really dated now, but still a lot of fun to read. The other point is that it's worth checking your assumptions every now and then to make sure they are valid.

Tune in next week for more on Making Software and the whole project of empirically studying software development.

Me Break Weekly

In the interests of full disclosure, I probably should start by saying that, technically, Rails Test Prescriptions was not actually featured on this week's MacBreak Weekly.

But it is a lot more fun to say that it was...

Here's the whole sordid, somewhat self-indulgent story:

I've been a regular listener to the MacBreak Weekly podcast almost since it started, and recently I've taken to listening to the show while walking to the train but switching to the video version when I get on the train.

This week, MBW host Leo Laporte chose the Ruby Pickaxe book as his pick of the week, calling attention to the $10 sale that was just ending. As Leo shows the Pragmatic website on the screen, and talks about how Pragmatic has the best programming books. Right as he does that, he scrolls down the Pragmatic home page, and by total luck, Rails Test Prescriptions is right there in the random carousel of books on the home page. Yay!



Hey, I know it's not a real mention or anything like that, and that I'm probably the only person in the world who even noticed. But it made me smile sitting on the train riding home this week. I'll take that.

Rails Test Prescriptions Status Update

We've gone through the technical comments for Rails Test Prescriptions and I've made the substantial changes that I plan to make. At this point, we are about to enter the production process, we just missed getting it in before the Thanksgiving holiday, so I'd expect this to start next week.

I'd also expect beta 10 to come in next week, hopefully Monday, maybe Tuesday.

As for the timeline on the rest, I'm not 100% sure. I think that ordinarily Pragmatic expects indexing and copy edit to take 2-3 weeks, but I'm not sure how the holidays and vacation will affect that. I'm still expecting the final print version to be available sometime in January.

November 15: Getting Closer

So. Um. I really didn't intend to be off the blog for quite this long. But, well, one thing leads to another, and sometimes the easiest thing in the world to do is Not Blog.

Some things that are going on:

Rails Test Prescriptions is through it's full technical review. Comments were mostly positive, with a nice dusting of "why didn't I think of that", and "Oops", and "I should fix that", plus the occasional "We're just going to have to agree to disagree".

As far as timing goes, the plan is to respond to all outstanding comments and give the thing a good read-thru by this Friday. I'd expect that we'll put out a beta at that point (for one thing, the factories chapter has been updated to factory_girl 2, and I'd like to get that out). After that, I'm not sure how long the copyedit part of the process will take. The Pragmatic web site has mid-January as the publish date at the moment, while Amazon is about a week or two more pessimistic.

In other news, loosely defined, Scrivener 2 is out with handy sync to external folder support, meaning I can easily round-trip between Scrivener on the Mac and, say, PlainText on the iPad. Nifty, and I can't wait for iaWriter to support sub-folders so I can round-trip with that, too. Also, I'd love it if MarsEdit had the same kind of round-trip sync, not that anybody is asking.

In a slightly related story, I'm doing a kind of half-assed NaNoWriMo, half-assed because I haven't been able to do it anything near every day. But I'm picking up something I wrote and got pretty far with a few years a go before stopping, and I really would like to get it all the way to The End.

I also just obtained the new Making Software book, which is a collection of empirical software engineering research. I'd expect to see a blog post or two on that, based on what I've read so far, I think I'll have opinions on this.

SCNA

Spent Friday and Saturday at the Software Craftsmanship North America conference, which was a friendly gathering of people interested in being really, really good coders.

A few scattershot observations -- my favorite quotes and whatnot are on my twitter stream, except for Corey Haines' talk at the end -- I had put my stuff away and didn't have a readily available tweeting device.

• I'm much more comfortable with artisan metaphors for programming than martial arts ones. That may be because I've never studied a martial art (though it's not like I'm a practicing carpenter either). If you find meaning or inspiration in martial arts terms, great, they never totally feel right to me.



• The best energy in the room the whole time was after lunch on the second day, when most of the attendees were in the spillover room with about 5 impromptu teaching/learning sessions going on at once, not counting some people just working together at stuff.



• Of course, I'm lousy at taking advantage of things like that -- too afraid I'll miss something to stick at one thing.



• I'm not sure there was a common theme, but a lot of the talks had moved past the "how to be a software craftsman" or even the "why to be a software craftsman" levels, and got to the "okay, we're software craftsmen. Now what?" level. Particularly the problem of when to treat software as art, as craft, or as commerce.



• Really enjoyed the panel session with Bob Martin, Chad Fowler, Michael Feathers, and Enrique Comba Riepenhausen -- it was interesting to see all of them talk about their process in the small, and what they struggle with. The Randori session, where the speakers and other noted attendees paired together in four minute pieces, was more entertaining than enlightening, but it was pretty entertaining.



• Liked most of the talks, particularly Chad Fowler's, despite the Motorola six sigma flashbacks, and Corey Haines' call for less negativity and more joy in our work.



• This is probably a longer post, but I genuinely wonder about the focus at this conference and at other software conferences on finding a job that makes you happy. Do other professions have this to anything like the same extent? Is there a greater range between good and bad situations in software than in other professional realms? Granted, of course, that we aren't in positions of physical danger?

Rails Test Prescriptions in review.

Book status update

The book will be headed out to full text review today. The biggest change of note is that Blue Ridge, which is no longer a supported project, has been replaced as the JavaScript test framework of record by Jasmine. Feels kind of Orwellian to turn Blue Ridge into an unproject like that, but obviously I'd prefer to have living, ongoing projects in the book. The Cucumber and RSpec chapters were also brought in line with the latest versions.

I'm not sure whether there will be a beta 9 with these changes. I think so, but I haven't put it through channels yet.

What happens after the full text review depends in part on the review comments. There are at least two more steps to go (copyediting, indexing), and probably a few more I don't know about, but we're getting there...

One Step Closer

I turned in a draft version of the completed performance chapter Monday morning, marking the first time that I've ever been able to say that I have a complete draft of the book. I'm hoping for a beta by the end of this week.

And, since I haven't added the links in a while, here are the links where you can get the book from Pragmatic or from Amazon.

Which isn't to say that I'm done, though it's getting closer. For one thing, there's a fresh batch of errata -- sincere thanks for that, most of the issues found are easy to fix and hard to find.

Next up is a general look-through to make sure that the book is still reasonably up to date. I'm aware of the following things that I know need to be updated:

• Blue Ridge in the JavaScript chapter needs to be replaces with Jasmine and the jasmine_rails gem


• Some of the cucumber default behavior changed since I last touched up the chapter


• In the factory/fixture chapter, Machinist is going for a version 2.0 that's quite different, and I need to decide if I want to keep talking about Machinist 1, jump to the in-beta Machinist 2, or make Factory Girl the star of the chapter.


• I might want to add the not_a_mock library to the comparative mock tool discussion

If you've been reading Rails Test Prescriptions, and you are aware that a different library or tool is substantially out of date, let me know. Thanks.

Book Update

Brief update. Haven't done this in a while.

The chapter on performance testing, and test performance is getting closer to done. I had hoped to finish it last week, but obviously didn't get there. But it's definitely getting there.

Solving the Kata

My post for the RubyLearning Blog is now available. It's called "The Testing Mindset", and it's an extended work through of my TDD answer to the Ruby Kata from earlier this week.

Enjoy.

A Quick Ruby Kata

This is, I have on good authority, actual homework from a 4th grade gifted program, paraphrased to make it more code-kata like.

Find all the unique sequences of digits, like [1, 1, 2, 3, 8] that have the following properties:

• Each element of the sequence is a digit between 1 and 9


• The digits add to 15


• There is at least digit that appears exactly twice


• No digit appears more than twice


• Order is irrelevant [1, 1, 2, 3, 8] and [1, 3, 2, 1, 8] are the same sequence and only count once.

I believe the original problem did specify that there are 38 sequences that match.

I'm interested in seeing solutions to this if anybody goes ahead and does it. I'm pretty sure there's an elegant solution using Ruby 1.9 enumerations, but that's not the way I went on my first try.

iA Writer For iPad: Another Review

The latest in my unending attempt to find the perfect iPad text editor is iA Writer -- it's been just over a month since I last wrote about this. iA Writer's "hook", as it were, is an entire manifesto about usability for writers. Writer's goal is to let the writer focus as much as possible on your text. Toward that end, Writer has two features that are unique compared to the other iPad editors that I have reviewed, mostly Elements and Droptext.

To my mind, Writer's best UI innovation is a real attempt to make the built-in iPad typewriter more usable. Above the regular qwerty keys is a new top row that includes common punctuation marks, smart parenthesis, and typewriter keys to move the cursor one character or one word back and forth. Just that simple bit makes the built-in keyboard a lot quicker for basic typing.

The other innovation is a "focus mode", which fades out the interface elements and grays text that is not near the line being entered. I find this to be more of a gimmick. It's not like there is much UI to fade. I'm also seeing a bug where the "focused" section does not follow the typing when you move to a new line. I'm actually seeing a general bug that Writer can't keep the current line in the view. As I type it doesn't seem to automatically scroll to keep the insertion point in view, which is an annoying bug.

As to other features, Writer syncs with Dropbox, which is nice. Like Elements, it creates its own flat folder within your Dropbox account and finds text files within it and ignores folders or non-text files that you may have placed in that folder. Unlike Elements, Writer doesn't force you to use Dropbox. It does allow you to email or copy your text easily. Also unlike Elements, Writer doesn't automatically sync, you have to manually force the sync. Like Elements, but unlike Droptext, Writer registers itself as an open target for text files in other programs.

Writer has a couple of other things going for it. It uses a very nice custom monospaced sans-serif font, one that I would love to have on my text editors in general. On the other hand, if you don't like the font, tough noodles, because you can't change it. Happily for me, I like both the font and the relatively large default size.

Writer provides an always-visible character count, and in lieu of a word count, gives an estimate of how long it would take a reader to read the file. No idea how that is calculated, but it's certainly unique.

Overall, I like this app, I really like the idea of making the soft keyboard more featured. The scrolling issue is annoying, though to be fair, it's entirely possible that it's just an issue in the 4.2 beta.

Looming on the horizon, at least for the kind of writing I'd like to be able to do on an iPad, is Scrivener 2, which will allow for synch with a series of files via Dropbox. I suspect, though, that will require more flexible Dropbox support than Writer or Elements have -- such as folders.

Meanwhile, Merlin Mann took the opportunity of this apps release materials to go off on a rant about writing and distraction.

Including:

If you feel "distracted" while writing, buy a new iPad app. Also? Conquer your alcoholism by trying a new gin. -- Merlin Mann


Listen, gang. Use what works to do what you need. But, don't pretend new training wheels make the bike go faster. -- Merlin Mann

I get it - the materials for this app are a little precious, and I also don't find much value in hiding most of the text. That said, it's a very usable and minimal app that has very little fiddly stuff to mess with. And that said, my ratio of thinking about writing on the iPad to actual writing on the iPad is frighteningly high. So I understand the point that buying running shoes doesn't make you a runner, and buying this app doesn't make me a writer. It does, though, make writing on the train a little more fun.

Bottom line on Writer: the extended keyboard makes this far and away the best text app I've if you aren't using an external keyboard. I think some of the other features are gimmicky, but I think the basic focus is good, and I'm excited to see where this one goes with a little more polish. I've written this post using Writer with the touch keyboard (though I'll do some editing on the Mac before I post, especially HTML links, which are a real pain on the iPad), and it's the best experience I've had with the touch keys by far -- I'd use this to compose emails, for example.

Sept 20, 2010: Update

There is a long list of half-finished blog posts that are currently waiting for me to finish them, but they are all queued behind working on the book and other various life tasks.

As far as the book goes, I'm currently working on the performance chapter. This chapter will cover the Rails performance test features, and then will move to strategies for improving the actual performance of your tests.

The first part of this chapter is interesting to me because it's one of the few features in Rails Test Prescriptions that actually map very closely to a section in Professional Ruby on Rails that I wrote three years ago. The mechanism for running the tests has gotten much easier -- at that time the performance tests were more complicated to set up but the output and interpretation parts haven't changed.

The second part of the chapter will be about ways to improve the actual speed of your test suite. I'll talk more about that as I get further into writing it. This will also wind up being the home of the Autotest section that's the only part of the original book that hasn't found its way into the new book.

This will be the last new chapter to go into the book -- if you've been closely following the betas, that means that one chapter that has been in the beta table of contents is being dropped -- the one on browser-level testing. Basically, it was a chapter that was not something that I was particularly knowledgable about and we decided that it was not worth putting in the book just for the sake of saying we had a chapter there.

Anyway, this means the next beta will be the full length of the book, I'd expect to see it no later than the first week of October. After that, I know there are at least two chapters that need significant updates -- the JavaScript chapter needs to swap Jasmine for BlueRidge, and the factory section might swap Factory Girl as the main example over Machinist. There are some other parts that need more minor updates.

September 13, 2010: WindyCityRails

I'm going to have an official WindyCityRails conference report up on the Obtiva blog shortly. Consider this the more self-indulgent conference round-up.

Ray Hightower and the rest of the team put on a great show, everything ran smoothly, and even the typical complaints about WiFi were kind of muted.

When I'm at a conference, I tend to use Twitter as my notebook. People seem to appreciate it, it's nice to get quotable lines out into the community, and it gives me an excuse to monitor the Twitter backchannel. So, check out @noelrap for some play-by-play.

The iPod + bluetooth keyboard worked great for this -- if I wasn't presenting, I wouldn't have used the MacBook at all. Not least of the advantages was that I didn't have to fight for a power strip. The only real disadvantage was that the fairly wide view angle meant that anybody sitting next to me had a great view of my twitter-stream.

It was kind of funny to be able to recognize my Twitter-avatar popping up on laptop screens in front of me, suggesting that I was twittering too much (though I do seem to have gained followers over the day).

Also, the much-maligned Twitter/iPad interface was a champ -- particularly great was the ability to continue to work through all the browsing screens with a compose window open.

Anyway, the conference itself was fun. It was amazing to me how many people I know there now, considering that two years ago at the first WCR, I knew about three people that I didn't actually work with.

One highlight was talking with David Chelimsky commiserating about book processes when somebody came up to mutually ask us a question about testing. Thankfully, we agreed.

My own session went reasonably well, you can check out the bad code I wrote about over on github. I made kind of a rookie mistake in that I wasn't completely prepared to explain basic Cucumber and RSpec usage along with the legacy testing strategies. This became mostly a time management issue, and while I managed to get through everything I wanted to say, the session became a lot less hands-on then I was expecting. I mostly got positive feedback, though, so I think it was okay.

I do think I sold more of the RSpec book then of my own, indicating that I don't really understand this self-marketing thing.

I got a lot of ideas for performance follow-ups from John McCaffrey's talk and later from Nick's Gauthier's slides on test suite performance that I expect to include in future apps.

September 10, 2010: Just a thing or two

I've got a bunch of half-written posts, none of which you'll see today since I've been spending all my time getting ready for WindyCityRails tomorrow. So, some quick hits and things to mention before I forget...

Beta 7 of Rails Test Prescriptions came out earlier this week. The big addition is the chapter on RSpec. I'm happy with how this one came out. And now I can see the light at the end of the tunnel, with only one or two chapters left to write.

Speaking of WindyCityRails, registration ends at 2PM today (Friday the 10th), and they say no tickets will be sold at the door. There are still tickets available as I write this for both the conference itself and for my tutorial. It's going to be great, so be there.

Continuing the self-promotion, the interview I did for the coderpath podcast is now online. Other than the fact that I sound like I'm connecting via dialup, I'm happy with how it turned out. At the end, they ask when the book is coming out, and I say that main writing will probably be complete in August or September. Turns out that's a bit optimistic, but I'm hoping only a bit.

And on other blogs... I'll also be contributing to this RubyLearning Blog post series. Should be fun.

Obligatory Apple thing As you probably heard, Apple released explicit, written App Store guidelines yesterday, along with clarifying the review process. The best part is that the guidelines are actually written in plain English with a relative lack of legalese. Granting that they should have done this when the store came out, this is still a great step and should reduce the uncertainty around the store somewhat. They also loosened the rules around non-XCode projects, which is good, and maybe leads the way to getting projects like MIT's Sketch in the store, I hope/

September 7, 2010: On Writing Bad Code

I've been working on my tutorial session for WindyCityRails (tickets still available...). The session is about how to test when you are working in a legacy app that doesn't have tests.

Naturally, that requires some legacy code for the attendees to work with during the tutorial. My own worst Rails messes are either back in the 1.2.x time frame or I don't have access to them any more. I don't have the right to distribute legacy code that I have inherited, and most of those people wouldn't want me calling their code a junkpile in public.

So I've been writing a faux-legacy application, or at least enough of one to make the needed points in the tutorial. The idea stumped me for a bit because the app needs to be both complex enough to plausibly show the issues in legacy testing and simple enough so that setup and changes can actually happen in a short workshop.

Eventually, I hit on the following guidelines for writing deliberately bad code:

• Aggressive corner cutting on features that aren't essential to the presentation.


• Don't look anything up and don't use gems or plugins, not least of which to prevent setup issues.


• Make no effort to put things in the "right" place.


• Work quickly, without design and never go back to clean up a mess.


• Randomly, do something a little bit less elegantly than normal. Oh, and some metaprogrammy Ruby things were off limits, assuming I was writing as somebody who didn't know Ruby that well.

And I think I got some nicely tangled code rather quickly.

At this point I think I'm supposed to say one of two things:

• Boy I sure was able to write that code fast without the pesky rules! I guess that TDD stuff isn't that great after all.


• Boy, I sure wrote nasty code without those pesky rules! I guess that TDD stuff really is great after all.

I think I believe the second point more than the first. It's hard to look at this code and not see some major pain coming in the future. That said, you have to acknowledge the emotional power of seeming to write fast code.

Because I did go pretty fast here, and I got a satisfying amount of app built in a relatively short number of hours with a very continuous novelty burst in my head from seeing new things in a browser.

The temptation to say, "I was deliberately writing ugly code. If I just stopped doing that, then boy, I could go really fast and not use TDD, I can control bugs without TDD." And the thing is, that'll be true for a while. Maybe a long time, if you're pretty good and working by yourself.

This is related to the very seductive idea that your project doesn't need to use Agile methods because you can control your changes up front. In both cases, you go quickly mostly by ignoring the inevitability of anything changing in the future (who cares how tangled the code is if nobody ever has to modify it...)

In the end, though, change is coming. So the trick to working in a legacy environment is taking code that was never written to allow change and making it more amenable to change.

Sep 3, 2010: Twitter for iPad and Other Craziness

Book Status

RSpec chapter edits complete, a dozen or so errata squashed, and hopefully we'll get beta 7 out. I suspect it'll be after Labor Day, though. I'm pleased with how this one turned out. The RSpec chapter is a challenge -- I'm literally squeezing a book's worth of content into a chapter, but I think it covers the major points clearly.

Since I haven't posted it in a while, you can buy the book here and on Amazon.

That, I think, pretty much ends the content that had some basis in the Lulu book, moving us into the one or two chapters that I need to write from scratch, as well as at least one chapter that has been obsoleted over the summer (BlueRidge). Still, getting closer.

WindyCityRails Update

Still seats available for my WindyCityRails tutorial. Right now, I'm trying to coordinate what I want to say with the faux-legacy app I'm building for people to practice on. The faux app needs to look legacy-ish, but still be easy enough to install and work with that something meaningful can be done in a three hour tutorial. Interesting problem.

More iPad

Two possible changes in my iPad app mix:

Twitter app replacing Osfoora HD

For all that it's kind of insane, I really like the official Twitter iPad app. It's super polished, and although I'm not convinced that the actual implementation of the overlapping tabs is optimal, I think the basic idea is great. One interesting point is that they clearly have chosen to favor a specific kind of Twitter user.

The overlapping tab works well at letting you see data related to a tweet (usually the contents of a link) and still see your account side bar and some of your timeline. It's quite pretty, aggressively bold in the way the original Tweetie app was, and useful. I appreciate that it's fewer clicks and generally easier to follow links on a lot of tweets in short succession, which I do a lot. I do think it's weird that the browser tab kind of half-sticks around even after you go back to your timeline, and it's easy to miss the spots where the browser tab slides back (as opposed to trying to horizontal scroll the browser window). A lot of people are reporting that it's hard to figure out how to move the panes -- I think it could be clearer in-app.

But, I like that it keeps my place when I change orientation -- which is Osfoora's most annoying non-feature. I like the layout in general, I think it gets the natural proportion of a twitter stream right (a lot of the other Twitter apps make the stream really wide, which feels strange to me), and it feels very polished and responsive.

Now I wish that the Mac Tweetie that I bought MacHeist in order to get an early beta might actually come out. Sigh.

River of News replacing Reeder, Maybe.

I'm not sure about this one. River of News is a simple RSS reader that displays articles in a basic River of News style, meaning one after another.

It's not as pretty or full featured as Reeder, but it's also less inscrutable and I tend to like the general layout.

Right now it seems as though River of News works better when I'm reading most of the articles in a feed or folder, because it scrolls better than Reeder does. But since Reeder has the mini previews, it's faster if I plan on skipping most of a feed. Still wondering which will work best.