June

As far as I know, I’m done with conferences and events for this month - which is good, given that July starts a somewhat busier stretch.

July

Speaking of… On July 24th and 25th, I’ll be at Rails Underground in London. I’ve never been to the city, so I’m excited to go (though I’ll only have a couple of half days to look around). I’m also eager to give my talk on Rack again, since it went over pretty well at Railsconf earlier this year.

August

In August, I’ll be in Boston. Twice. August 15th is the date we’re looking at for the next Developer Day (yes, I know the site still says DC. We’ll update it when we have more info on the Boston event). I’ll then be returning two weeks later for my brother-in-law’s wedding, which should be great fun. In between, we’ve got the Rails Rumble - I haven’t made a decision about whether to compete yet, so we’ll see how that shakes out. Should I go for the threepeat?

September

Things slow down a bit in September; I’ve got a proposal in to one event that would happen in the second week, and I’m definitely flying out to Chicago to speak at WindyCityRails (after incorporating some of the feedback on my domain modeling talk from RubyNation).

Afterwards

After September, things get a lot murkier. We’re planning on doing at least one more Developer Day this year after Boston, and I have several proposals out to other events, but nothing’s definite yet.

Anyways, that’s about it. If you’re planning on attending any of these events (all of which look great, by the way - register now!), drop me a line!

This was the first time I’ve given this particular talk, “Comics” Is Hard: Domain Modeling Challenges, and like all first-time talks I was a bit anxious about it. Luckily, a large portion of it consists of me expounding upon the insanity of the comic book industry, which I cand talk about for hours if need be. Overall, I think the talk went pretty well, and I’m very excited to give it again (in London and Chicago, at least) after I have the chance to revise a few aspects of it (particularly, tweaking the balance between the problem and solution sections). My one real regret is that taking questions of Twitter, which worked so well at Railsconf, utterly failed here due to some difficulties with the conference wireless. By the way - if you saw the talk, please rate it on SpeakerRate

It’s also very nice to be back in Reston, at the Town Center, I haven’t been by here for at least a couple of years, and after having lived half a mile away for several years it’s fascinating to see how things have changed.

People

For this year’s conference, I adopted a different strategy than my normal one — I tried to meet and talk with as many people as I could, and as a result I think I enjoyed this year more than I have the past two. An incomplete list of the people I talked with, including old friends and new: akitaonrails, bdainton, bigfleet, bitsweat, blowmage, bphogan, bryanl, cdwarren, chacon, chadfowler, compay, cpytel, cselmer, danabrit, dastels, david_a_black, davidcjames, ddollar, desi, dpickett, egspoony, evanphx, fkchang2000, greggpollack, jamesgolick, jasonrudolph, jedschneider, jeffrafter, jimweirich, joefiorini, jondahl, jseifer, karnowski, kblake, keavy, kellyjeanne, maddox, maraby, matthewcarriere, mbleigh, mhartl, moonshark, msshushu, noelrap, nzkoz, obie, qrush, rbates, reinh, rich_kilmer, robertdempsey, sarahmei, seanhussey, seebq, solaredge, stevesanderson, subelsky, therealadam, tobi, wbruce, wifelette, xymbol, zapnap. (If we chatted and you’re not on the list, feel free to leave a comment! I didn’t get twitter names for everyone I talked to)

I talked with a number of people about Developer Day, and found a few more cities to add to the list of potential future Days, so be sure to keep an eye out for one near you.

Sessions and Keynotes

Most of the sessions I attended went very well. Disappointingly, however, some of those that I was most excited for (the one on mountable apps in Rails 3, for instance) just weren’t what I’d hoped. As for the keynotes:

• DHH’s overview of Rails 3 left me with a lot of excitement, as well as some questions (particularly around the unobtrusive JavaScript support).
• I’ll have a post in the next few days on the Tim Ferriss debacle.
• Chris Wanstrath’s essay was my favorite presentation of the conference.
• I really enjoyed Uncle Bob (though to be honest that was entirely due to his energetic presentation style, which overwhelmed the message for me).
• The core panel went fine, but didn’t bear many insights or surprises.

My Sessions

As I mentioned in my last post, I was responsible for or a participant in three sessions this year. The first, the Teaching Rails Birds-of-a-Feather session, went very well — we had somewhere around thirty attendees (I’m terrible at estimation), and a lot of great ideas and experiences were discussed. It sounds like people are independently hitting on the same ideas, and the BoF was a good chance to meet up and discuss them. (By the way, attendees — don’t forget to the #teachingrails tag on things you do going forward!)

I originally thought the Rails Rumble panel went well, but it’s not doing so well in the attendee evaluations. From my experience watching panels, I think it’s probably the most difficult format to get a lot out of, as there are just too many variables to track. I had a lot of fun in the various talks we did to prepare for it, though.

Finally, my last session on Rack support (why am I always scheduled for the last day?!?) was extremely well-received. I’m pretty sure that I made more last-minute changes to this than to anything I’ve done before, since Rack in Rails is still changing — I was able to implement an example middleware on Tuesday or Wednesday that I just couldn’t on the previous Thursday, for instance — but by the time Thursday morning rolled around I was good to go, and the audience responded very positively. Plus, I got to draw attention to Doug Avery’s design talent by including the Bowling Thunder logo on one of my slides (and check out the Reddit item that the slide spawned!).

Oh, and if you attended one of these sessions, I’d love it if you could rate me over at SpeakerRate. Thanks!

Vegas

I never really understood the outrage over the move from Portland to Las Vegas, and after attending I’m even more mystified. Like most of the attendees, I go to Railsconf for the conference, not for the city. I left the conference hotel to see Penn & Teller on Sunday, dinner at an Ethiopian restaurant on Wednesday, and Star Trek on Thursday, and I didn’t gamble at all. I’m guessing the conference will be elsewhere next year, but if the quality is the same I don’t know that I’ll particularly care about the city.

Celebrities!

If you followed the Railsconf Twitter stream at all, you know that Billy Mays was often seen at the blackjack tables in the Hilton, and as far as I could tell, completely hammered. I saw him all the freaking time, and the one time I turned on the TV in my room, his show on the Discovery Channel was on. It was a little surreal.

I’m also 99.5% sure that I saw Leslie Segrete (formely on the TLC show While You Were Out) heading to the pool on Monday, and I wish I’d said hello and found out for sure. Looks like the National Hardware Show has more TV star power than the Rails community — who knew?

Inspiration

One of the main benefits I get from attending a conference is inspiration, and this was no exception. Those six hours in the airport? A lot of that time was spent hacking, as was part of the flight to Atlanta. I’m extremely motivated to work on several projects now, and I can’t wait to see everything else that was spurred on by the conference. Between that and all the great connections I was able to make, I’m happy to call Railsconf 2009 a huge success.

• Monday at 8:30pm, I’m moderating a BoF on “Teaching Rails,” which grew out of a discussion I had with Brian Hogan on IRC. We think there’s a real lack of focus on the experience of people new to Rails — there’s a lot of information scattered around, but there’s no authoritative way to bring people into the community.
• Wednesday at 4:25pm, I’m participating in a panel discussion called “Starting Up Fast: Lessons from the Rails Rumble.” Nick Plante set this up, and got a number of the winners from the past two years. It should be fun, and I’m excited to hear about how the non-solo teams worked. Oh, and if you have a question for the panel you can submit it beforehand.
• Thursday at 10:45am, I’m giving a session entitled “And the Greatest of These Is … Rack Support.” As big as the announcement of the Merb merger was, I think the biggest news in Rails over the past year was the adoption of Rack, and in this session I’ll explain why.

So it looks like I’ll be pretty busy, but I’m always eager to meet new Rubyists — if you see me in the halls, say hello! And if you’re on Twitter, take a look at Railsconf Tweetups, which looks to be a cool way to see who’s going to what.

Page caching is the most efficient of the markup caching methods that Rails provides, but it suffers from two major problems. First, page cached content is saved to the filesystem, where it is then publicly accessible - regardless of the protections originally placed around that content. Second, page caching is appropriate only for content that is relatively static - things that change quickly, or are relevant to particular users.

The talk I’ve been presenting introduces a technique for bypassing these problems. At the moment, I’m calling it “progressive caching,” though I’m open to alternative suggestions. Basically, the idea is that many pages in an application are mostly cacheable, with only a few distinct regions that change frequently or depend on the identity of the logged-in user. On my comic book site, for instance, the release list has only a few pieces of content that depend on the user:

Progressive caching this content would involve page caching the release list, and then firing off an AJAX request on the page load that, if a user is logged in, returns the appropriate data to fill in those chunks with client-side JavaScript.

This technique grows more powerful when it is paired with Rails Metal, which allows you to bypass some of the overhead of the Rails stack for specific requests. The sample app that I discuss in the talk, for instance, shows the following results:

If you can’t read the numbers, that’s 617ms for a page running on my local machine, pulling back 150 or so covers and adding a tag to 45 of them based on the logged in user vs. 135ms for the same content with progressive caching. In fact, I was able to get the latter version down to 66ms, with some further optimizations.

All in all, progressive caching is a strategy that I think deserves a close look. I’ve worked on a number of applications that could benefit from it, and I imagine others have, as well.

Note: I’ve written a more in-depth exploration of the technique (with actual code!) on Viget Labs’ Extend blog.

I first conceived of Developer Day six or eight months ago, and after stewing on it for a while and talking it over with Justin Gehtland and a number of my co-workers at Viget, we finally decided to go ahead with it about two or three months ago. Having never organized an event of this sort before, I was a little surprised by all the work required, but it turned out better than I’d imagined - and by their comments and tweets, it seems like the attendees and speakers had a good time, too.

With that success under our collective belt, then, we’ve decided to do it again — this time, in DC, in late May. We’ll have some of the same speakers, as well as some new ones local to the area, but we’re committed to the idea of high-quality content for a very low cost, and to the idea of local conferences (even smaller than regional ones). We look forward to seeing people in DC in a few months, and who knows — maybe Developer Day will be coming to your city next!

I’ll be giving a version of my talk from Developer Day, entitled “Page Caching Resurrected.” Here’s the abstract:

Over the past year, Rails has gradually (and sometimes quietly) introduced some dramatic new changes. The most obvious of these is the Merb merger, but one of the most important steps on the path to Rails 3.0 was the introduction of Rack support. The effects of that change are wide-ranging, and are often surprising — and include the possibility for new architectures that were impractical or impossible before. Specifically, it is now feasible to build a complex Rails application that can still respond extremely quickly and directly to a specific set of requests, such as those an AJAX service might experience.

In this session, we’ll explore in depth how this strategy reinvigorates a useful, but formerly limited, capability of Rails: page caching. Of the three caching methods built into Rails, page caching is by far the most efficient, but it is also the least flexible. By making use of the Rack support in Rails (with tools like Rails Metal and simple Rack applications), page caching will come into its own as a viable strategy.

My company (Viget Labs) has teamed up with Relevance to present a full day of great technical talks on all sorts of topics (performance, source control, testing, and more) and on a variety of technologies (Ruby, Rails, JavaScript, Scala). We’re confident that we’ve got the best program you’ll find anywhere for $50, especially when you throw in breakfast, lunch, and snacks from local restaurants. Space is limited, though, so if you’re free on Saturday the 21st of March and feel like coming (up|down|over) to downtown Durham, check out the site and register!

Of course, I immediately started obsessing over how it did, and ended up spending my evening upgrading the web service backend to provide better results for searches. Still, it’s been a lot of fun, and I can’t wait to get more apps out there.

If you have any feedback or questions on the app, feel free to post them in the comments here!

One of the issues I had was scrolling. The app I’m working on displays a table (UITableView) in which each cell contains an image that I’m pulling down from the web. Given the way that the iPhone loads the cells, however, this meant that every time you scrolled a cell (even if you’d seen the cell before) into view, it had to wait for the image to be pulled from the server. Granted, the images are pretty small, but there was still a very noticeable delay as you moved back and forth through the list.

The obvious solution was to cache the images, and that’s just what I ended up doing (after a couple of failed attempts). Here’s the gist of the code:

Basically, this code expects a JSON array, each element of which is a hash with a text description and a URL to an image. When the view loads, the code parses cycles over the array and creates a new UIImage for each image URL, which it adds to a dictionary (the key is the URL, the value is the UIImage). When a cell is displayed, the code looks for the appropriate entry in the images dictionary and adds it as the cell’s image. Thus, all the image requests are front-loaded, and scrolling smooths out considerably.

Note: I’m sure I’ve done some terrible things in this code. Before flaming, please consider that 1) I’m still learning, and 2) this is meant as an example of a technique, not as an example of wonderfully-written Objective-C. Thanks!