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.