Our office is located in Union Square: 841 Broadway, 8th floor.

Ample food and drink will be provided, just bring your computers and yourselves. I’ll be hacking all day on documentation patches.

Read more about the hackfest on the Rails Blog

The post Rails 3.1 Hackfest NYC July 23rd appeared first on Pivotal Labs.

1. Test at the point of integration downwards, that the live service returns what you expect for various inputs.
2. Using the same tests to drive your development, write a fake-out of the service that passes the same tests.
3. Then use the faked out service as you test upwards, that functionality in your app can utilize the features of the service.
4. Once you’re ready to integrate, write a very high level smoke test that can pass against both the real service and the fake service.

After some analysis with our client and their resident WordPress expert, we determined we’d need to create users in WordPress when they sign up for rails, and update those users later when they change their information. We knew we’d prefer to use a simple HTTP REST API with a /users resource we could handle the C and U in CRUD. We’d also like to help the developer test drive his API, without having to learn much about Ruby. We chose to write some simple smoke tests in the most pervasive scripting language in world, Bash [1]. Luckily, Bash has an awesome standard distribution, usually including one of the best http wrappers ever written, cURL. So we began with the following script:

#!/usr/env bash
RESULT=`curl -ipost -s http://testsite.boonewebdev.com/api/users -pname=Evan+Farrar -pid=12`
if [[ $RESULT =~ 'evan-farrar' ]]
  echo "Test Create: Success. Got: $result"
else
  echo "Test Create: Failure. Got: $result"
endif

There it was in a few lines of Bash: a failing test. The WordPress developer used our suite of tests, ran them as he refactored, extended our script and corrected it where we had made incorrect assumptions about his service. As we worked with him, it was much easier to simply run the test to see what had changed or what was failing than to try to communicate the subtle differences by email. Of course, once I first saw the script I went a little overboard with Bash hackery; I’ll have to save my resulting Bash unit testing framework for another blab…

[1] This statement is wholly unfounded and without research. I didn’t even ask my friend Google if this was true.

The post Testing Service Integrations with Bash and cURL appeared first on Pivotal Labs.

Fuentes,Jesús,”Cribbage, Chess, and Bridge Club”,Treasurer

But another row with the same character with the same encoding would import fine:

Johnson,Lúisa,Dodgeball Club,President

It turned out that this was due a problem with how Ruby finds character boundaries in 1.8. If that miscalculated character boundary happens to be where a quote mark begins in your CSV file, FasterCSV will hurl:

1.8.7> 'Jesús,"'.split(//)
=> ["J","e","s","349s,""]
1.9   > 'Jesús,"'.split(//)
=> ["J","e","s","ú","s",",","""]

This is not a problem in Ruby 1.9 with FasterCSV or in the old fashioned CSV class included with Ruby’s standard library in 1.8.6. Hopefully I can help others who have got this error staring them in the face despite having a perfectly valid CSV in every regard:

FasterCSV::MalformedCSVError: FasterCSV::MalformedCSVError
    from /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/fastercsv-1.5.3/lib/faster_csv.rb:1623:in `shift'
    from /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/fastercsv-1.5.3/lib/faster_csv.rb:1614:in `each'
    from /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/fastercsv-1.5.3/lib/faster_csv.rb:1614:in `shift'
    from /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/fastercsv-1.5.3/lib/faster_csv.rb:1581:in `loop'
    from /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/fastercsv-1.5.3/lib/faster_csv.rb:1581:in `shift'
    from /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/fastercsv-1.5.3/lib/faster_csv.rb:1526:in `each'
    from /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/fastercsv-1.5.3/lib/faster_csv.rb:1537:in `to_a'
    from /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/fastercsv-1.5.3/lib/faster_csv.rb:1537:in `read'
    from /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/fastercsv-1.5.3/lib/faster_csv.rb:1229:in `parse'

The post FasterCSV, Ruby 1.8, and Character Encodings appeared first on Pivotal Labs.

require 'sms-rb'
SMS.twilio_id = "DE4DB33F"
SMS.twilio_secret = "ASDFGHJK123456"
SMS.twilio_phone = "+15555555555"
SMS.text("eat more cake", :to => "+13121234567")

By configuring Twilio to hit a URL in your rails app you can also receive messages easily:

class TextMessageParrotController < ApplicationController
  def parrot
    SMS.text("*SQUAWK* #{params[:body]} *SQUAWK*", :to => params[:from])
  end
end

And it’s as simple as that. Don’t hesitate to try out Twilio. They give you an ample amount of SMS credit when you sign up — more than enough test messages to bootstrap any sort of SMS integration in your Rails application. It’s a lot of fun!

Red Rover, by the way, is looking to hire some developers. It’s a great company that is passionate about engaging students with their university and each other. Their technologies at work include Rails, Solr, rspec, SMS, hadoop, and RSS. But experience with Rails, knowledge of test driven development and great communication are what they are really hoping to have. I’d love to see folks in the New York City area who can come pair with us at pivotal, but working remotely is certainly possible too. Just shoot a mail to kevin < at > redroverhq.com if you are interested.

The post Sending Text Messages with Twilio appeared first on Pivotal Labs.