May 22, 2015No Comments

Ruby Rogues and the Double Life of Tests


[Authors note: So, I wrote this in December, and promptly forgot about it for five months. It happens. I've annotated slightly.]

I was excited to be a guest on Ruby Rogues this week [note: actually last December] to discuss my book Rails 4 Test Prescriptions, available now as an ebook, and coming very soon [note: available now]  as a physical object that you can buy or, say, give as a gift to all your friends. [note: still a great idea, please buy for all your friends].

Read more

September 23, 2014No Comments

Stop Missing Files in Your Assets Precompile

Rails Asset PrecompileWell, it’s been a good couple of days. You’ve been productive and finally released that tricky feature. It got pretty complicated, but you knew this was happening and were super careful to test along the way. A lot of the work was done in a new JavaScript file you added to your Rails project. Everything is working well for the team testing this locally (and we tested this thing upside down and inside out). Excellent. Now, it’s time to get this in front of your client. Time to push this new stuff to the server. Deployment successful and the fancy new thing you just built isn’t working. Sounds familiar doesn’t it?

Read more

June 12, 2014No Comments

Rails 4 Test Prescriptions: Build a Healthy Codebase

Your Ruby on Rails application is sick. Deadlines are looming, but every time you make the slightest change to the code, something else breaks. Nobody remembers what that tricky piece of code was supposed to do, and nobody can tell what it actually does. Plus, it has bugs. You need test-driven development, a process for improving the design, maintainability, and long-term viability of software. Table XI's Senior Developer & Agile Coach, Noel Rappin, can help.

Read more

February 13, 2014No Comments

Greg Baugues Talks Devs & Depression on Ruby Rogues

ruby roguesRecently, our old colleague Greg Baugues chatted with the guys at Ruby Rogues about a subject we think is one of the most important facing our industry today: the prevalence and stigma of mental illness in the developer community. A programmer who struggled for a long time to identify and deal with his own ADHD and Type II Bipolar, Greg has given several talks about his own experiences and how to get help if you or a friend is suffering from depression or another kind of mental illness.

Read more

July 9, 20131 Comment

FoxySync: How to Synchronize Your Website with FoxyCart

FoxySyncIf you've ever done an e-commerce integration, then you know what a pain it can be. Traditionally you'd build a shopping cart, create a checkout workflow, and integrate with a third party payment gateway. Ultimately you spend a lot of time writing and testing new code for an old task. I've done a few of these integrations, and the last time I did I tried something new: FoxyCart.

I wanted to try FoxyCart because it would allow me to outsource the shopping cart, checkout, and payment gateway integration. As a result I could clean up my code base, reduce my maintenance costs, and setup for an easy payment gateway switch in the future. Making FoxyCart work with my Ruby on Rails app, however, was not a cinch. There were no Ruby gems to work with and examples in Ruby were sparse. I knew I'd have to figure out a lot of the integration on my own so I thought I'd make it easy for the next Rubyist and cut a gem out of the work. That gem is called FoxySync.

FoxySync encapsulates four FoxyCart integrations: cart validation, single sign on, XML data feed, and API communication. Using all together fully synchronizes and secures all communication between your app and the FoxyCart service. Let's take a look at each.

Cart Validation

Since FoxyCart knows very little about your products, it depends on you to post any metadata—including price—when customers add items to a cart. As a default, the metadata is stored as plain text in the web page where the “Add to cart” button lives. This is risky because, if someone knows what they're doing, they could change the price of your product before it’s sent to FoxyCart. To prevent such tampering, FoxyCart offers HMAC product verification, or what I like to call cart validation. The feature works by validating a hash on each piece of metadata to ensure authenticity. FoxySync makes this easy by providing a helper method to generate the correct HTML form variables.

include FoxySync::CartValidation
cart_input_name 'code', 'mai', 'mai'
# results in <input type="hidden" name="code||5651608dde5a2abeb51fad7099fbd1a026690a7ddbd93a1a3167362e2f611b53" value="mai" />

Single Sign On

FoxyCart keeps an account for each user that checks out on your site, but with a good integration, those customers shouldn’t even know they’re using it. That being the case, it's weird to ask them to reauthenticate on the checkout page if they’re already logged into your site. FoxyCart's single sign on feature prevents this weirdness by asking your application to acknowledge authentication before the checkout page is displayed. FoxyCart makes a request to your site and your application redirects back to FoxyCart. FoxySync helps with this handshake by providing a helper method to generate the redirect URL.

include FoxySync::Sso
redirect_to sso_url(params, user)

XML Datafeed

FoxyCart's transaction datafeed feature ensures that your application is notified of sale details after each successful checkout. When enabled, FoxyCart will post to your application an encrypted XML document and expect a particular response. FoxySync helps with this feature by handling the XML decryption and providing a helper to generate the appropriate response.

include FoxySync::Datafeed
receipt = []
xml = datafeed_unwrap params
receipt << xml.customer_first_name
receipt << xml.customer_last_name
receipt << xml.receipt_url
# etc

API Communication

FoxyCart has a robust API that lets you manipulate and retrieve data about your store, customers, transactions, and subscriptions. FoxySync makes working with the API dead simple, so you can easily access this powerful feature.

api =
reply = api.customer_get :customer_email => ''
reply.customer_id # is the customer's FoxyCart id

FoxyCart is a great service for adding sophisticated e-commerce to your website without having to do a lot of the hard work. However, FoxyCart still needs to be integrated, and for Ruby on Rails apps, FoxySync makes that pretty easy.

Want all the best React Native tools in one stack?  Download your free copy of our own mobile development stack

May 15, 2013No Comments

Highlights from RailsConf 2013 – Portland

“Head West!” This is how DHH described the pioneering spirit of the Rails community in his keynote that kicked off RailsConf 2013. I recently made my own journey west from Chicago. So it was fitting to attend the conference in my new hometown of Portland.

There were many outstanding sessions, including a talk on Rails vs the Client Side by Table XI’s own Noel Rappin, How to talk to Developers by Ben Orenstein, and The Magic Tricks of Testing by Sandi Metz. Topics ranged from integrating NoSQL with your Rails app to designing social media apps for a world that is not “normalized.”

Now is truly a great time to be a Rails developer, and attending the conference was a fantastic way to discover new resources. Rails 4.0 release candidate 1 just came out. There are good learning tools available, including the podcasts RubyRogues, Ruby5, and Code School. There are also great tools for evaluating the quality and security of your code like Code Climate and New Relic. If your company is hiring or job searching, Developer Auction is a resource that takes a creative approach to connecting employers with job seekers.

With over 1,500 attendees, the “hallway track” was packed. I met some really interesting people and had a great discussion with Chuck from Portland Code School about how to get more women involved in the local Rails community. Women are a strong part of the Rails community and were represented at the conference by groups like Rails Girls and Women Who Code. It was also inspiring to see Sandi Metz and the founders of RailsGirls: Linda Liukas, Pia Henrietta Kekäläinen, and Karri Saarinen recognized as Ruby Heroes.

In addition to the sessions, RailsConf 2013 hosted some of the best lightning talks I’ve ever attended. I highly recommend checking out the following:

  • Nick Quaranto and Miles Forrest both gave talks about launching Ruby meetups. Nick started openHack and the Buffalo Ruby group. Miles successfully started his own local Ruby Brigade. He had been commuting from his hometown of Chillowack, BC, after three failed attempts drove him to commute all the way to the Seattle Ruby Brigade.
  • Chris Morris, in his talk on Technical Intimidation, challenged us not to be intimidated by people who know all the things, but to learn from them.
  • Jon McCartie gave a strong presentation on purposeful code. He challenged us to find ways to apply our skills to tasks we value.
  • Yoshiori Shoji was inspired to use gem-mirror to keep on hacking, even during a 10-hour flight from Japan.
  • JC Grubbs spoke about apprentices, and how to teach and value people.
  • Andrew Harvey talked about shaping company culture.
  • David Padilla really summed it up when he said conferences are about content, but they are also about people.

I definitely came out of the conference inspired to learn more, code more, and become more involved in the awesome Rails community. I’m looking forward to next year’s RailsConf, which will be back in Table XI’s sweet home Chicago!

What were your favorite parts of RailsConf 2013?

Want access to more articles like this?  Subscribe now to stay up to date on the latest from Table XI 

May 14, 2013No Comments

Rails vs. The Client Side: XI to Eye

xitoeyeTwo completely different ways have emerged for using Rails as the back-end to a rich client-side JavaScript application:

  • The 37Signals "Russian Doll" approach, used in Basecamp Next, where the server generally returns HTML to the client. This approach uses aggressive caching and a little bit of JavaScript glue to keep the application fast.
  • The "Rails API" approach, where the server generally returns JSON to the client, and a JavaScript MVC framework handles the actual display.

Which of these will work for you? For this week's XI to Eye, I've posted my RailsConf presentation on the topic.

Also, if you like this talk, my book Master Space and Time With JavaScript has much more detailed information on using JavaScript effectively, including a work in progress on Ember.js.

Watch live video from Confreaks - Live Streaming on

Want access to more articles like this?  Subscribe now to stay up to date on the latest from Table XI 

May 8, 20133 Comments

Tales on Rails: The Three Little Devs

Squeel: 3 Little Pigs

You know how the story goes: Once upon a time, there were three little devs. Smart and determined, the three developers set up a new Rails app.

The first little dev, the youngest and littlest, wrote a handful of ActiveRecord conditions in SQL.


[gist id="4bd6c8ea3c3e4be0ccdd"]

All was well, and the queries worked! So it was, and so it continued, for several minutes. But as the littlest dev carried on, innocently combining his scopes, he was interrupted by a big, bad bug. The bug snarled, "Little dev, little dev, just call it quits!"

The littlest dev was having none of this. "Not by the code in my github commits!"

"Then I'll huff, and I'll puff, and I'll raise an exception!" shouted the bug, who proceeded to do just that.

[gist id="5126e7b682aef787e628"]

The littlest dev fled in terror to the chat window of his brother, the second little dev, who was a little bit wiser and a little bit bigger (relatively speaking, of course). He nodded solemnly as his younger brother explained what had happened.

Putting on his bravest demeanor, he announced, "Let's refactor, and chase off that big, bad bug once and for all!"

They worked tirelessly for minutes upon minutes, using the squeel gem to replace their old SQL conditions with robust, readable Ruby code.

[gist id="45429d859f7d06bf69c0"]

Just as they finished adding in a new query, the big, bad bug arrived yet again, displaying an uncanny sense of plot and timing. "Little devs, little devs, just call it quits!"

"Not by the code in our github commits!" came the obvious response from the little devs.

"Then I'll huff, and I'll puff, and I'll raise an exception!" roared the bug. Sure enough, he huffed, and he puffed, and it turned out that the devs had made a typo in their new query, a direct result of too much code duplication.

[gist id="bdfa4f9cea58dbc6f3b1"]

The two little devs opened a group chat with their eldest brother, the third little dev, who was much wiser and much bigger (relatively speaking, of course). He nodded solemnly as his brothers explained what had happened. Confidence radiating from his monitor-tanned face, he spoke slowly and calmly, "Let's refactor, and chase off that big, bad bug once and for all."

The brothers worked tirelessly for at least a few seconds, using ActiveRecord::Relation's merge method to reduce the duplication of logic in their queries.

[gist id="d545f3737f6e34accc7f"]

The big, bad bug did not show up again, and the three little devs lived happily, for at least a little while.

I'm sorry—you don't think this sounds familiar? The version you know involves pigs building houses made of straw, sticks, and bricks? And a wolf with improbable lung capacity? This is no time for make-believe; I'm telling the story the way my father told it to me, and his father told it to him.

Like all good stories, this one has a moral: Use squeel and ActiveRecord::Relation#merge to reduce the complexity and duplication of your ActiveRecord queries. Who knows? Maybe you too can live happily, at least for a little while.

Want access to more articles like this?  Subscribe now to stay up to date on the latest from Table XI 

December 28, 2012No Comments

Pragmatic Flight of Fancy in Rails Testing

A common TDD concept is that you write tests targeting the most optimal API imaginable, rather than contorting your code around current production realities. It’s possibly the most practical form of flight of fancy anyone has ever considered. Run free in a field with your API before you build retaining walls to thwart mudslides. The resulting code is much better because you work toward the best possible experience, deferring details for as long as possible. It’s amazing how well the process works in all types of contexts.

Read more

October 10, 2012No Comments

WindyCityRail’s Ray Hightower Talks Ruby Conferences

Last month all our developers took a trip to the south side of Chicago for WindyCityRails. It was a great conference, and afterward I talked to WCR organizer Ray Hightower about this year's event, what we can look forward to in 2013, and what other conferences Ruby developers should keep on their radars.

1. First off, how was Hawaii? 

Hawaii is wonderful! Aloha Ruby was a very well-organized conference full of smart people. I presented RubyMotion to a group of experienced iOS and Ruby developers. Some of the attendees produce the blogs, screencasts, and books that I use as reference materials. It was very challenging to have my teachers and mentors in the audience!

2. How did WCR 2012 compare to WCR 2011?

WindyCityRails 2012 was held on two weekdays, while previous years' events were Saturday-only. Last year's post-conference survey told us that attendees prefer to spend weekends with their families, so we shifted the dates to make that work. This year's attendance was higher than last year's even though we raised the price to cover two days of conference expenses. And of course, the venue was beautiful. The South Shore Cultural Center is in the middle of a golf course next to Lake Michigan. Since South Shore was so well received by the audience, WindyCityRails will return to South Shore in 2013.

3. What would you like to do differently for WCR 2013?

WindyCityRails 2013 will place heavier emphasis on the technical side of software development. For 2013, we've already confirmed two speakers who deliver large software projects on a regular basis. We will balance the increased technical emphasis with some creative ways for attendees to interact with each other. It would be great to make creative use of the golf course or the lake in 2013. Wonderful things happen when smart people collaborate, and WindyCityRails is a catalyst for powerful collaborations.

4. If you could recommend one non-WCR conference to a Rails dev, which would it be?

It's hard to recommend one, since I enjoy several conferences every year and each has special strengths. Aloha Ruby is exciting for the tech-cred of the audience and the speakers, plus the tropical island venue. MadisonRuby draws Ruby innovators from all over the world, and the organizers do a great job of bringing the local business community into the conference. If I'm giving a recommendation to a Chicago-area dev, I would lean toward MadisonRuby.

5. As a novice Rails dev in Chicago, what extracurricular activities should I be getting involved in?

Novice devs (and advanced devs too) will benefit from ChicagoRuby's monthly events. ChicagoRuby runs three activities each month, bouncing between downtown Chicago and the suburbs. Several strong groups can be found through, including Refresh Chicago, Rails Builders, and Chicago JavaScript. Finally, all devs grow stronger with practice. One great way to practice is to pair program with other devs.

Thanks for the tips, Ray!

Want access to more articles like this?  Subscribe now to stay up to date on the latest from Table XI 

GoodFirms Badge