It's that time of year again where people seem to be extra generous. Consider donating to small software projects that have made your life easier this year. Some of my favorites include:

• redmine
• rubber
• rubinius
• mms2r
• cucumber

Thanks for all the great software!

Comments

There have been quite a few blog posts around the ruby community on pair programming. Obie Fernandez thinks it isn't for every programmer while Josh Susser thinks it isn't right for every project. I tend to agree with Josh and disagree with Obie. Obie has writing style that seems to make the assumption that his company's methods aren't just the best but the gold standard. In this case he does have a good method for pair programming. However, it isn't the only nor the best method. The best is whatever works for your situation given the programmer you're working with.

It isn't an extreme programming requirement that you're running on Mac. If you're deploying on Linux and you're using Ruby on Rails and vim for your development then logically Linux would be the best OS choice on which to develop. If you're still sold on TextMate, I'd recommend trying emacs but it is your choice. In that case, you have to compromise your development OS choice and go with Mac.

Everyone I happen to pair program with can use vim. Some of us use Mac others Linux. We also enjoy the flexibility of either going in to the office or working remotely. We've tried a couple of different solutions for remote pair programming:

• iChat screen share
  • Easiest network setup
  • OS X only
  • Bandwidth hog (need large pipe on both ends)
  • Sends raw keyboard signals (dvorak/qwerty pairs hard)
• Skype video screen share
  • Easiest network setup
  • Beta OS Support (OS X and Windows only ATM)
  • Bandwidth hog
• VNC and Skype voice
  • Platform agnostic
  • VNC requires NAT traversal
  • Bandwidth heavy (less than iChat)
• SSH, Screen and Skype voice
  • Platform agnostic
  • Very low bandwidth usage
  • Familiar terminal environment
  • GUI text editors not supported
  • may require NAT traversal

We started by trying screen sharing software. This works pretty well with large bandwidth pipes on both ends. Sometimes the screen repainting can be enough of a delay to break co-understanding. This is especially true when using vim navigation. All screen sharing (iChat, Skype video, VNC) seemed to have this issue.

We found that all we were really trying to share was the text editor. With some helpful tips from Linux.com, we were able to get screen with a shared session working. This can be done on any machine where both developers have SSH access. In the following example, John and Pete ssh into a common machine and share a terminal screen session.

User john:

ssh john@common-machine
screen -S pairprog
Ctrl-a :multiuser on
Ctrl-a :acladd pete

User pete:

ssh pete@common-machine
screen -x john/pairprog

We found it as responsive as any other remote terminal and had the added benefit of not dedicating the developers' laptops to the task. This is useful for when you're researching how to solve a problem or looking up API documentation while pairing. Our team found this method of pair programming so useful, we considered it even when in the office. It allows developers to stay in their environments they're comfortable with and get real work done.

I hope Obie's post won't discourage "the masses" from pair programming. Figure out what works for you and make it happen. Pair programming has lots of benefits both to the code base and the participating developers. Similar to TDD, it doesn't just happen overnight. Pair Programming is a skill that developers need to constantly get better at to succeed.

Comments

I spent some time over the past two days cleaning up the polymorphic_include plugin. The most significant was adding unit tests.

I wrote it a year ago so that I could eager load polymorphic associations using :include directives in ActiveRecord. This is mostly useful in a search results page.

Adding tests presented an interesting challenge because it is coded as a rails plugin. It's pretty nasty to test because it uses alias_method_chain to modify the calls to :find and :find_every when a polymorphic exception is thrown.

It isn't as useful for Rails versions greater than 2.1 because they've mostly addressed this issue. However, some queries still throw exception and this plugin tries to correct that. See the README file for more info.

Comments

It seems a lot of geeks with a blog tend to spend more time changing the supporting software and layout of the site more than just writing posts. I am no exception. This weekend I followed in the footsteps of coworkers nirvdrum and graysky and converted my blog to Jekyll. I actually took the additional step of no longer hosting it myself, instead prefering the ease of github pages. Here's what I did to move away from a self-hosted Typo blog

Fork the mojombo.github.com project

It's a good example site that is under MIT license (except the content itself of course). Added benefit is you don't have to mess around with the layout just yet.

1. Delete all copyrighted content
2. Change Tom's information to yours where applicable
3. Change the CNAME to yourdomain.com

Migrate posts from Typo

I had to make some changes to mojombo's converter for typo 5+. So, grab my version of jekyll or patch your gem install. Here is the diff

With the changes applied, the migration is pretty straight forward.

Modify permalinks and update feedburner

Modify your permalinks in jekyll to match your old typo install so readers don't lose their way.

Check in all changes to github

You should change your project name to <github-username>.github.com and commit those chages up to github. Also, FYI you need a paid account for CNAMEs to work on github.

Update your domain's DNS

You need two entries

1. A-record yourdomain.com to 65.74.177.129
2. Cname www.yourdomain.com to yourdomain.com

Add disqus for comments

Since these are static pages, the preferred way to add commenting to your blog is through disqus. Actually, I've grown to prefer disqus even if it is self hosted.

1. Add your website at http://disqus.com/add
2. Add the generated javascript to the bottom of your post layout

That should be all you need to get started. I'd recommend changing your layout so your blog doesn't continue to look like mojombo's blog. However, this isn't strictly necessary.

Comments

I work for a small VC-backed company in the mobile social media space. Something we want to offer is a public API to open up our community to development of 3rd party tools. Although we have the technical capabilities to build an infrastructure in-house, I had a look at Mashery to outsource some of the ongoing work. We were looking for:

• proxy front end that can scale up as our API use grows and have a caching strategy to reduce the load on our servers
• ability to throttle on a per app (or developer key) basis to anticipate server load
• developer documentation that is easy to update and publish, skinned to look like our site
• ability for developer feedback
• analytics on the usage of the API
• OAuth support

Looking at Mashery's offering, they seemed like a good fit. That was a month ago. Today, none of those things are fully baked. Nothing of their offering is self-service so everything requires customization. Most tasks run serially and take a minimum of 3-5 business days.

We should have known at the beginning. After the website erred out on purchase attempt, I was assigned an account rep who wanted to set up a conference call. After attempting to explain their cost as a "request per second per developer key", I counted them out. That type of pricing model wouldn't work with us mainly because all of our installs of, say, an iPhone app would have the same developer key. That prompted this tweet.

To be fair, the CEO got right back to me (as a side note, I guess it proves Twitter is a good way to get feedback to a company.) He seemed as confused as I was and explained they were changing their pricing model that day. Long story short, we signed up on a monthly basis based on the new, more straightforward pricing scheme (they've yet to publish as of this writing.)

One point of contention was OAuth was not a part of their standard package. It was considered an advanced custom feature. It was odd because OAuth is quickly becoming the best practice for accessing user generated content. I would expect a market leader to be driving best practices, not behind on them.

However, OAuth alone would double the monthly fee and require a custom $2500 setup. We decided to implement that ourselves. Again, it isn't that we couldn't, we just didn't want to spend the time. This also complicated matters. Now we'd have to pass valid consumer keys to Mashery so they could still perform their throttling function. This never happened...we weren't able to get to this discussion before aborting the relationship.

Next pain point was on the skinned development documentation. It took them over a week to "provision" us a portal. And when they did, it wasn't skinned. After pointing back to the contract, our rep agreed to skin the portal. We sent over a screenshot and was told it would be skinned in 7-10 business days. In short, don't expect public facing documentation for three weeks after your first monthly payment.

The next hurdle was reporting. Our rep attempted to explain to us their wacked-out URI-based reporting scheme. You had to define which parts of your URL path was important to your calls. Long story short, they don't support Ruby on Rails RESTful type urls. For example, they couldn't figure out how to make these different calls for reporting:

• /pictures.xml
• /pictures/39290.xml
• /pictures/39290/comments.xml

The first one is a collection of all pictures. The second is retrieving the single picture with ID 39290. The last one is retrieving the comments attached to the picture 39290. I guess the problem was with ID wildcarding.

Because of this "unusual" URL scheme, we were given a statement of work for $1000 and five business days to implement what amounts to a regular expression in your code. We were told repeatedly that no customer has asked for anything so strange in reporting.

So, we refused to pay the ransom and asked for a refund. They've refused the refund. Apparently, they consider us "2 days from success". We're out a couple of thousand dollars and a month's headache for the effort. At least we figured it out early. I would suggest having them prove themselves to you before plunking down any money. At the least, ask for a 30-day guarantee. Don't let them develop their 1/2 baked product on your dime.

Update 6/18/09

After much back and forth with Mashery on twitter and email they have agreed to refund our money. They were gracious and took the time to understand our frustrations. In the end we have different opinions of how the process should work but I think we both have a better understanding of where each other are coming from.

Comments