has_many :through

Pair programming isn't right for all projects

2009-09-23T23:48:16-07:00

My hat's off to Obie Fernandez for his recent article 10 Reasons Pair Programming Is Not For the Masses. I don't actually agree that only the elite are cut out for pair programming, but I do think he's on target with his list of obstacles to effective pairing.

There's another axis to consider for fit, however, and that's the suitability of the work itself for pair programming. I don't mean the product domain or the kind of application being written, but rather the technology and tools used to build it.

I started pair programming when I was a freshman in college. My CS10 lab section had 20 students and only 10 computers, so we had to pair up. No one told us anything about how to pair; we just did it. It wasn't really a big deal since students are used to helping each other with class assignments. I think the pairing was valuable for learning, but there was a problem. The problem was Pascal. Specifically, the length of time spent compiling the code every time we made a change. We'd write some code, then fire up the compiler and play Pascal (the game of seeing how many dots you can generate before you get a compiler error). Compiling took a long time, anywhere from 5 to 20 minutes, depending on how big the program was. So what do you do with your pair during that time?

There are all sorts of reasons we hate long wait times during development, whether from compiling, running tests, deployment, or whatever. While it can be nice to take an enforced break now and then, the disruption to flow is a significant obstacle to productivity and quality of work. A five minute interrupt to your flow is murder to your mindset and caustic to your collaborative bond.

After college I worked at Xerox, programming in Smalltalk on a team of about 8 developers. We tended to pair a fair amount, maybe a quarter to half of our time on average. But at other places I worked, we paired a lot less. I'm sure some of that was cultural, but I think a lot of it was because of the technology. Programming in the Smalltalk environment really good for keeping the flow going. Do some coding in a method and save the code, and a second or three later you can see the results. This made pairing so much easier because we could keep our focus on the coding. It's hard enough to keep the pair in a good mode when things are going well, but to have to stop for a few minutes every few minutes adds too much frustration, and the easiest place to direct that frustration is onto your pair.

So if your project is not amenable to a rapid, incremental development cycle, it's going to be a lot harder to keep people pairing on it. I guess that leaves two options. You can punt on pairing, or you can fix the technology so that you get the fast development cycle necessary for maintaining flow. Can you guess which one is going to be better for you?

Circle of death

2009-09-03T22:15:58-07:00

Discipline and creativity

2009-07-12T23:11:42-07:00

I was chatting with a friend over dinner this weekend about the impact of work environment on one's ability to excel as a software developer. We've both worked for companies where we've had to work far more than 40 hours each week for extended periods of time. We both agreed that's a good way to burn out your staff and, more importantly, a bad way to get stuff done faster. Sure, you can do an intense sprint now and then, but you don't win a marathon by running full out the whole way.

The comparison I came up with was that writing software is a lot like writing literature. It takes both discipline and creativity. Having either of those attributes will only get you so far (though it will probably put you ahead of most of the pack). To truly excel you must have both.

http://www.flickr.com/photos/nimboo/ / CC BY-NC-ND 2.0

Discipline is not about putting in long hours (well sometimes it is, but that's not what I'm talking about). Discipline is about consistency. It's like playing blackjack and counting cards - your system won't pay off on every hand, but over time you will reap the rewards. Agile development is very much about that kind of discipline. You write your tests, go red, go green, refactor. This aspect of software is craftwork. It's methodical. It's not very exciting, but it gets you from point A to point B, and for the most part it's predictable.

Putting in 60+ hours a week is not good for your creative output. Being creative requires a brain that is rested and energized. It also takes mixing things up, changing perspective frequently. Burnout is the enemy! Sometimes when I'm stuck I'll get up and walk around the office, have a 5 minute chat with someone about something random. When I get back to my desk I can deal with the issue much better. Or if my pair and I get stuck, we'll put the story on hold for a little bit and tackle something tiny that lets us reset our perspective. That sort of thing usually helps a lot. We know enough not to try something really tough late in the day, and sometimes we save doing a fun story as a reward for finishing something that's no fun at all. Our brains naturally have attention spans that are too short to keep up with what we ask of them. Learn how to work with your brain instead of forcing it to do something it's not suited for.

There is a balance, and a way that discipline and working creatively mesh. Find a rhythm that works and that you can sustain, then stick with it. Back when I was trying to write science fiction, I got to talk to Cory Doctorow about his practice of writing. His advice was to write a page every day, then send it to people to get feedback. Pretty simple, eh? Cory produces a lot of fiction and I find it shocking that he only does a page a day. But a page a day lets him do a novel and a few short stories in a year, which is a lot more than I ever wrote when I was trying. I think he can probably keep that pace up forever. Sustainable pace wins.

One of the things I like best about working at Pivotal is that we consistently work at a sustainable pace. I can't believe how many startups advertise jobs where they say that they expect you to work "startup hours". I won't even consider working at a place like that ever again. It's not just because I don't like working that way myself, but because I think companies that expect and require that kind of pace from their developers are just going to screw themselves and burn out their developers. They'll either get real about what they can sustain, fail, or figure out how to deal with a high attrition/turnover rate.

Then there are companies that have no discipline and rely only on their "rock star" developers being able to come up with one inspired solution after another. Now, inspiration is great, but it doesn't get you even halfway there. People don't pay you for your ideas; they pay you for how you execute on them. If all you ever did was sit around and think up great solutions for difficult problems, you wouldn't ever get anything done. And if all you ever did was play Rock Band, you might be very inspired but you'd never finish writing Duke Nukem Forever.

As an ENTP (the personality type, not the company), working in a team is the only way I can consistently get things done over a long period. I can be super productive working with other people, but working on my own can be very challenging for more than a short time. It's much easier to keep up my discipline when I'm pairing since that helps me stay focused, and I can be very creative too, since I think better out loud. I know that way doesn't work for everyone, but it sure does for me. I also love tools like Pivotal Tracker that let me easily see what I have to work on next so I don't have to keep figuring it out every time I finish a task and need something else to do. On the other hand, I'm not a Calendar-About-Nothing kind of guy.

That's enough philosophy for the evening. But I'm curious to hear what other people feel about the interaction of discipline and creativity.

It's a wrap!

2009-06-04T08:45:15-07:00

We're finally getting all our after-conference activities completed. The most exciting thing is that we just got our conference media online. We have video and audio recordings of the Golden Gate Ruby Conference technical sessions! Pivotal Labs sponsored the recordings, and is hosting them at pivotallabs.com/gogaruco - you can watch them there or download the files to watch later, or get them from the iTunes podcasts.

We also are trying something new (for Ruby confs, at least). We have put together a 42 page PDF zine, the Golden Gate Ruby Wrap, in order to document the conference, the speakers, the sessions, and the attendees. There are a lot of photos of the event, speaker bios, talk write-ups, and even interviews with attendees. It's the official record of the conference (as official as we get, anyway), and it's free.

Just because people have been asking, I'll say that Matt Aimonetti's talk on CouchDB is not included in the talk videos. Matt didn't want to offend anyone else, so he asked the talk recording not be released. Please don't ask for a copy privately, as I can't help you out. However, there is a great write-up of Matt's talk in the Wrap.

I'd also encourage you to check out the gogaruco blog posts at Pivotal Labs - there are articles for every session at the conference. Sarah Allen also blogged many of the sessions at her site. Know of any other good posts about sessions? Let us know in the comments.

And if you want to see how things looked, there are a lot of good photos up on flickr.

Not the post

2009-04-29T10:30:16-07:00

This is not the post I wanted to write. The post that I wanted to write, that I in fact have mostly written and would have posted days ago if not for this distraction, was about what a great success Golden Gate Ruby Conference was and how proud we are of putting on a top-notch conference that raised the bar in many ways. But I'm the person who is responsible for the technical program at the conference, and with the astounding level of distress over the presentation Matt Aimonetti gave at my conference, it's clear I need to do something.

First off, I want to apologize. The technical program at GoGaRuCo was my responsibility. I could have done a better job and prevented this from happening. Everyone had the best of intentions and there are good reasons why things happened the way they did, but that doesn't excuse the lapse. As a first-time conference organizer there was a lot that I had to learn as I went, and this is definitely an important lesson. I haven't yet figured out the best way to prevent this from happening again, but I'm determined to find a way to do better next time.

And to be clear, I don't think Matt's talk was appropriate for a professional conference. If an employee of Google or Apple or Microsoft gave that presentation at a company event, he likely would be fired. I know that many people found the talk informative, creative and entertaining, and I'm not arguing against that. But there were people who found the sexual imagery in the talk objectionable or felt alienated by the atmosphere it created, and that's not okay. I think there are ways a talk with that title could have been given that would have worked, but the talk that was delivered didn't.

The most commonly used word to describe people's negative reactions to Matt's talk that I've read in online discussions is "offended". From what I know, this is not accurate. I haven't spoken to any conference attendee who said they were offended by the talk. I've heard that people felt insulted, alienated, threatened or unwelcome. I don't know if that makes a difference to people's arguments, but I think it is a distinction that matters.

This all has been particularly frustrating to me because we specifically tried to make GoGaRuCo a conference that would be welcoming to women. I looked for women speakers for the program to make the conference more women-friendly, and was so pleased to get Jacqui Maher, who gave one of the highest rated talks of the conference. When we announced Jacqui was speaking, we had several women register right away. We also made arrangements so that a nursing mother had a private space to use her breast pump. Leah and I talked about the number of women who registered often, and did our best to talk to women and get them to attend. And I don't think doing any of what we did deserves any kind of special credit - I think it should be just part of what you do if you want a quality conference.

3% attendance by women may seem low (and it is), but compared to most other regional Ruby conferences we were way ahead. One of the other regional conf organizers said how he wished he could have more than 1% women at his conference. But after all that, we end up known as the conf with the sexist pr0n talk. Sigh.

There's no way I'm going to make this go away, defuse the issue, or correct all the wrong assumptions about what really happened and why. But it might help to know more about how this happened.

I've mentioned before that we tried an experiment putting together the program. Half the speakers were invited directly. I contacted people I knew could give a great talk, and asked them to do one for GoGaRuCo. Each of those conversations had some back-and-forth about the talk and what I wanted to see at the conference. There were no proposals for me to read or evaluate, so these conversations were important. Then there were talks that were selected by attendee voting. We asked for talk proposals, put the proposals up on a website, and registered attendees voted for the talks they wanted to see. Matt's talk was selected by this voting process. There was some amount of conversation I had with the selected presenters, but not as much as with the invited talks. After all, I had descriptions of the talks in the proposals so didn't feel I needed to do anything. I also wanted to respect the results of the voting process. The whole point was for there to be content accepted that I wouldn't have necessarily chosen myself.

Matt's original proposal did not include very much detail about the technical content of the talk. I worked with him to expand the proposal to include sufficient detail to include it in the set of proposals. As a sometime editor with some experience with professional detachment, I tried to keep out of the business of telling him what he should be proposing and focused on getting a proposal that would help voters make their choice. I could have refused to post the proposal, or told Matt to clean up the "pr0n" spin if he wanted to have it included, but I didn't consider that the actual talk would go over the line. To compound things, Matt has told me that the talks we had over grooming his proposal gave him the impression that I was approving doing a talk that included the porn theme. I had a long talk with Matt last night about this, and I can see how he would see our conversations as approval of the content of his talk. That doesn't mean I think Matt's talk was the right talk to give or let him off the hook for what he did, but if nothing else did, this makes my role in the matter clear. It also shows where I need to do better.

I have been to many conferences, spoken at a few, and been on program committees. I've never known any conference to pre-screen presentations or give speakers guidelines about what content is acceptable. We all assume people know what is appropriate and usually that's the case. There have certainly been inappropriate talks given before, and I expect there will continue to be so in the future. But we make the same decision over and over, to let speakers express themselves in their own way, and to use their creativity and passion to communicate in a way that is engaging. Usually that gives us good results. Sometimes it doesn't. I don't think that censoring presentations or imposing content guidelines would help much, if at all, and I don't think it would be worth the potential loss of creativity and quality. It's certainly worth looking at how to improve things, but there don't appear to be any easy answers.

People are getting really upset over this, and that's completely understandable. There has been a lot of anger and name calling and finger pointing and arguing in general. I've gotten angry myself too. But I think most people are coming at this with good intentions and are representing what they believe in. Maybe that's naive, I don't know. I do think that this has turned into an important conversation about women in our technical communities, and I have to hope that something good will come of it in the end.

I'm pretty overwhelmed by this issue and have spent way more time on it than I have to spare right now, but if there's something you to have to say to me, I want to hear it. I don't know how soon I'll be able to respond, but I'll do my best.

Update: I realize those without some previous knowledge of the Golden Gate Ruby Conference might not realize that the awesome Leah Silber was co-organizer of the conf with me. She did most of the heavy lifting on the logistics and stuff, but the technical program was my responsibility. Just wanted to make sure Leah gets the credit she deserves.

The Week Of

2009-04-13T09:24:06-07:00

Here we are, the week of Golden Gate Ruby Conference 2009. Everything is in good shape, and we're looking forward to having an awesome time. So here is some last-minute information about the conference.

We've got a great program. Really, this is the conference I've always wanted to attend. Check out our schedule and the amazing assemblage of speakers. I want to thank everyone who submitted talk proposals, and also everyone who voted for selecting talks. We couldn't have done it without you.

Our tickets sold out in just four weeks. We'll have a full house of 200 people, and we'll do our best to take care of you so you can get the most out of the conference. We'll be emailing attendees soon with some info about things like parking, the after-hours party and such, so keep an eye on your inbox.

If you're not coming to the conference, we've still got you covered. Pivotal Labs has generously sponsored full video recording of all the sessions, so all our talks will be available for viewing or download soon after the conference. And if you can't wait, justin.tv is going to be at the conf streaming video of the sessions live. We'll also have a small team of live bloggers chronicling the presentations as they go, and we'll have an IRC channel going on freenode at #gogaruco so it's almost like being there but without the swag. The place to go to find the videos and blog posts is pivotallabs.com/gogaruco

The tyranny of choice: It's our turn now

2009-02-07T18:48:10-08:00

Rails used to be about simplicity. I just started a new project in Rails 2.3. Here's all the choices I'm now faced with:

Database: MySQL, PostgreSQL
Testing: Test/Unit, RSpec, Shoulda, Context/Matchy, minitest
Mocking: Mocha, FlexMock, RR
Templates: HTML/ERb, Markaby, HAML, Erector
Authentication: restful_authentication, Clearance
Web Server: Apache, Nginx
App Server: Mongrel, Thin, Passenger

It's been about a year since I rolled out a greenfield project. Options are nice, but this feels like Java! And those options are just off the top of my head - I wrote them down in less than a minute without even thinking about it.

Admittedly, it's pretty easy for me to make choices for all these things. I have enough experience that I don't have to spend much time pondering. But for someone new to Rails this all must seem pretty intimidating.

I guess this is why Rails 2.3 has app templates now. Just in time!

Now who has a good template for a quicky open-source app?

Announcing Golden Gate Ruby Conference

2009-01-22T18:47:02-08:00

This has been a long time coming, and I'm very happy to finally be able to announce the first ever Golden Gate Ruby Conference, here in San Francisco on April 17 and 18. There's so much interest in Ruby here in SF, and tons of Ruby mojo too, so it's about time we had our own conference! We'll be bringing in some great speakers from all over so locals who don't get to travel to conferences can get exposed to stuff they can't usually see. And we'll also have some of our high-powered local talent showing off their stuff too.

While this has been in the works for a while, there are still a few details to work out before we can talk about things like registration, price, our speaker lineup, etc. But we wanted to get the word out as soon as we had firm dates so people could get it on their calendars. And there's still a lot we can talk about...

The organizers of the conference are yours truly, Josh Susser ("the has_many :through guy"), and Leah Silber, conference addict and the woman Yehuda Katz was lucky enough to marry. Yehuda is going to be helping me with the technical program too. Our employers, Pivotal Labs and Engine Yard are already committed to sponsor the conference, so we know we have plenty of support to make it happen. There are still a lot of opportunities to get involved as a volunteer or a sponsor, and we're actively looking for both.

Our approach to this conference is not to take anything as a given. We're rebels, we're bucking the system, we're using instance_eval to leave out explicit receivers! For starters, there will be no call for proposals for talks. The program will consist of invited talks, and talks selected by attendee voting. We'll be setting up a site soon where talks can be proposed and voted on.

We've also got a GitHub account set up as a one-stop place where you can find all the code talked about at the conference, and a place to put stuff we may be hacking on over the weekend. Of course you can follow the conference on twitter, and we'll have a blog set up soon enough.

We're shooting for 150-200 people, single track, about a dozen talks, plenty of "hallway track" time, and a few surprises.

If you want to get involved, volunteer or sponsor, the email addresses on gogaruco.com are the best way to contact us.

Looking forward to this. You have no idea...

Agile git and the story branch pattern

2008-12-18T23:39:47-08:00

I've been using git for source code management for over a year now and I'm totally hooked. I won't rave about all the usual reasons WhyGitIsBetterThanX since it's been done already. Instead, I'm going to share how I use git for easy agile development.

The basic idea is to never do anything in the master branch except use it to move changes between the remote repo and local branches. Keeping master clean takes very little effort and will save your bacon when you get into trouble. The example I'll use here is working on a story to render title text in a bold style on a page.

1. Locate story "titles are in bold text" in Pivotal Tracker and click Start.

What do you mean you're not using Pivotal Tracker?

2. Get going with a clean start.

$ git checkout master
$ git pull
$ rake db:migrate   # if there are new migrations
$ rake              # if you don't have a CI server

3. Make a branch to work in.

$ git checkout -b bold_titles

4. Test-drive the story.

Since you are committing locally, you can commit often. Sometimes I like to commit every time I get a test to pass, or after crucial steps in a refactoring.

$ git commit -am "Don't bold empty titles"

We should all know the advantages of frequent commits: when an experiment fails, it's easy to get back to a previous state where things worked; or when refactoring, you can see how things were before you started changing things around. With git you can also do things like cherry-pick commits, so if you want to grab a single test and its implementation and extract it as a patch or whatever, you can do that.

When you are done...

$ rake
$ git commit -am "Render titles with bold style"

5. Merge with master

When you're done with the story, you need to integrate your changes with the master branch. You'll have to fetch and merge the changes from origin/master into your branch.

a. Review changes

I like to review changes to make sure I didn't leave any debugging cruft in, and as a final check on code quality.

$ git diff master

b. Merge changes

$ git checkout master
$ git pull
$ git checkout bold_titles
$ git rebase master

The four commands above may seem a bit convoluted, but all you're really doing is merging updates from the remote repo to your story branch by way of the master branch. Now, if you have any merge conflicts, they are all in the story branch where you can work on resolving them in your normal work environment without disturbing the master branch.

If you took enough time resolving merge conflicts that someone else checked in changes to the remote repo, repeat this step until you're fully merged locally.

Also, notice I used rebase instead of merge to integrate the master branch changes, but that choice is up to you. Whether you use rebase or merge is a matter of convention for your project. Doing a rebase will replay your changes on top of the changes you just merged with. That should have a net effect of zero on the final product but has the advantage of keeping all your changes contiguous in the history, and won't generate a separate merge commit when you merge back to the master branch since the changes come in as a fast-forward.

You can also rebase with the -i (or --interactive) option to squash several (or all) of your commits into a single commit, or to organize your changes as a reduced number of commits. Frequent commits are great to manage your own work and give many checkpoints to roll back to if needed. But adding dozens of commits to the project for a simple feature can be overwhelming for others on your team, and can make it difficult to navigate or understand the project history. For example:

$ git rebase -i master

That will show you an $EDITOR session like this:

# Rebasing 1234abc..3333ccc onto 1234abc
#
# Commands:
#  pick = use commit
#  edit = use commit, but stop for amending
#  squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
pick 1111aaa Use <strong> tag to bold titles
pick 2222bbb Don't render empty titles as bold
pick 3333ccc Use font-weight property on h1.title instead of <strong>

The commits are listed in chronological order, oldest on top. If you want to combine several commits into one, edit the word pick at the start of the line to say squash, and that commit will be merged with the one above it. Since you are seeing all your commits and their messages, you can probably say something useful about the whole set as you package it for pushing to the shared repo. Sometimes you'll want to squash down to just one commit, others you may want to structure the package as a small number of related commits, say one commit for your feature addition, and another for a refactoring your feature relies on.

Important: Rebasing rewrites history and should never be done to reorder changes you have previously pushed to another repo or shared publicly.

c. Be green

Once done merging, make sure you're still green.

$ rake

d. Merge early, merge often

If the work on your branch takes long enough, you might want to perform a merge several times. As other people push to origin/master, you can pull those changes and integrate them into your branch incrementally, rather than waiting until the end when you're done. Whether to do this is a judgement call, and would depend on factors like the nature of the work you're doing the the kind of changes you'd be integrating. But one of the more valuable practices of agile development is continuous integration, and spending too much time accumulating change on a branch that is cut off from the rest of the development stream can eventually make for a difficult merge at the end of your story.

6. Push

Once you have integrated your changes with those from master, you can merge them back to the master branch and from there to the remote repo.

$ git checkout master
$ git merge bold_titles
$ git push

7. Cleanup

$ git branch -d bold_titles

Delete the story branch, click Finish on the story in Pivotal Tracker, then get up and stretch and get some water.

Caution

Probably the biggest gotcha particular to Rails development on more than one branch is dealing with database migrations. It's easy to get confused between the state of the database and which migrations are in what branch. I'll take one of two approaches, depending on how complicated things are. One is to rollback the migration on the current branch before switching to another branch that doesn't have that migration yet, then run pending migrations on the new branch after switching. But if you're going to be switching around branches with different migrations a lot, the best thing is to integrate the migration changes so they exist on both branches and it ceases to be an issue.

Discussion

Okay that's a lot of stuff going on. What's the point? Well, the point is dealing with the unintended. (I was going to say "unexpected", but if you're developing software or working on a team, you should expect crazy things to occur occasionally.) There is obviously overhead in managing multiple branches, and you may wonder what you're getting for the cost of that overhead. There are a couple things that come to mind that I'll mention here, but I'd like to hear more in the comments from people about what situations they deal with this way (or other ways).

The first thing this approach helps with is being able to make frequent commits without breaking the build or disrupting the work of teammates. Working with a centralized SCM system like Subversion can force you to choose between checkpointing your work and keeping the state of the project consistent. I know agile developers who swear that making frequent commits to the shared repo is the way to go, and just deal with having to keep the build green and functional on every commit. But I find that approach too constraining, and it can impose an uncomfortable style on how I do my work. I find being able to do frequent commits without worrying about disrupting my teammates' work with half-finished features lets me concentrate on getting things done, instead of thinking about how big a change I can make without messing up someone else's work. And I also don't have to worry about the converse either. Don't you hate pulling down changes that include a migration and wondering if the relevant model changes to let that migration do the right thing have been made yet?

But why the separate story branches? Isn't it just as convenient to do all your work in your local master branch and do your local commits there? Up to a point, sure. But keeping a separate branch for work means that you always have a good baseline around for reference, it lets you rebase to manage your changesets easily, and it makes dealing with merge conflicts a bit more sane.

And if you have to share or backup the state of your work in progress, it's very easy to push your local branch to a branch in the remote repo without disrupting anything.

There's also the advantage that it's easier to deal with being interrupted. Say you're working on a story that's going to take you all day and someone finds a nasty bug in production. Time to drop everything and get it fixed right away! If you have your work in progress on a branch, it's simple to do a checkpoint commit, switch back to master, create a new branch for the bugfix, fix the bug, push the fix, then get right back to where you were before.

Push

I've been using the story branch pattern for development for most of the last year, and have found it useful, convenient and a lifesaver when things get weird. I've also watched teammates that do their work in the master branch, and it is more work for them to deal with issues and avoid making unintended messes. Like all useful practices it takes a little bit of effort up front, but it saves a lot more effort when it really matters.

Saying Goodbye to New York, Speaking at nyc.rb

2008-12-08T20:41:10-08:00

As my extended silence here has probably indicated, New York has been keeping me busy. It's been a crazy, hectic, and wonderful couple of months. I learned a lot, met some great people, and ate way too much pizza. I've also achieved that particular New York state of mind where I'm no longer phased by anything. However, this is my last week in New York before I return home to my beautiful city of San Francisco. I'm going to miss a lot about New York, but not the winter weather. Seriously, 25 degrees is not a reasonable temperature, and whoever thought so should be fired.

I didn't manage to post a note about it here, but last month I delivered a keynote talk at Voices that Matter: Professional Ruby Conference (which I affectionately christened ObieConf). My talk was Ruby: Fragile or Agile? I guess by the time I got them my talk info they were too busy to update the site so there's no description on the site, but the talk was about Ruby's destiny, and how lessons learned from when C++ ate Smalltalk's lunch could be instructive in guiding Ruby's future. I'll be reprising the talk tomorrow night (perhaps tonight by the time you read this (or yesterday if you're a feed slacker)) at the nyc.rb meeting.

The Pivotal office here in NY is coming along nicely. We've hired a few locals and moved into a bigger space, so we're ready to rock. And our first NY office production launched recently - Cookstr.com. Oh by the way, I'm starting to do more blogging on the Pivotal Labs technical blog, Pivotal Blabs. My most recent post is about using ActiveRecord internals to easily generate subselects.

I've got a few topics queued up to blog about on here too, so I'm hoping I'll be able to catch up some shortly. Stay tuned.

Oh yeah, I got to try a lot of the pizza suggestions. I really liked Grimaldi's, Lombardi's, and Two Boots. But man, Caracas Arepa Bar beats pizza nearly any day.