I gave a quick talk at Boston.rb this month about VCR, a tool that can help make your integration tests more deterministic.
I’ve been enjoying the tool quite a bit. It makes it really easy to interact with web services in your tests in a way that doesn’t depend on the endpoint always being up. This approach leads to better, quicker, and more predictable tests. If you’re already using WebMock or FakeWeb, this tool will automate the process of pre-fetching your response/expected result for you.
So you’ve got a solid idea, a nice niche, and a great web application that meets your customers’ needs. Now it’s time to get PAID. It is all about the proverbial Benjamins after all.
Go With Braintree Payment Solutions
If you’re building a SaaS (Software as a Service) application then you probably need a merchant account, a payment processor, and a subscription billing system. After researching many options, Braintree Payment Solutions has a really stellar offering that really delivers in those three areas. Having been tasked with debugging payment processing issues in the past, having one provider to call is really convenient and simple.
Go With Transparent Redirect
In addition to being an all-in-one solution, Braintree has some pretty cool technology. In order to get around PCI compliance and all the liabilities with storing credit card data, they provide their customers with a system they call Transparent Redirect. This system allows you to post all client credit card information directly to Braintree without persisting any private data on your side.
Do you have custom attributes that you need to capture on registration in addition to the credit card data? No problem! Braintree will pass those through to your response handler.
Put your Braintree configuration in an initializer like config/initializer/braintree.rb
Add a column to your account/user abstraction to store Braintree’s unique identifier for the customer. This will link the account to Braintree’s record.
Use Braintree’s control panel to configure any custom attributes you want to store and/or forward. For more details on this, check out their writeup.
Set up your form
I’m doing some quick handwaving here - I had to create an activemodel compliant abstraction for the Braintree customer. The idea is to create a form that looks like this (hint: give plataformatec’s simple_form a try):
This is the most important part of your app. You want to get paid and your customers don’t want to think twice about giving you their money. Let’s keep these transactions running smooth. Don’t leave a gaping hole in your test suite! I use cucumber for acceptance and integration testing.
Remote Action Problems
So cucumber isn’t always rainbows and unicorns. Cucumber does this really fun thing where it assumes every form submission posts to localhost regardless of what’s actually set in the html.
To get around this, we have to hijack the local requests and basically emulate a post to Braintree directly.
Hack Yo’ Rack
But wait - more fun ensues! Braintree does this really neat and secure thing called request signing. It requires that the hash used to build the query string be ordered. By default on Ruby 1.8.7, hashes are not ordered, so we have to hack both Rack and Rack-Test a bit :-( (Queue the sad panda).
Warning! Horrendous monkey patching ahead!
Use VCR for Deterministic Tests
Phew! That was a lot of hacking to get solid cucumber tests around your app. Let’s make sure that your tests aren’t dependent on Braintree’s sandbox being up and that your tests are generally deterministic. That way, you can run your test suite without necessarily having to be online, and you get repetitious, predictable tests.
To pull this off, I’m a huge fan of a tool called VCR.
This tool will record web requests and responses and allows you to run your tests without hitting the remote servers.
Hide Your Logins, Hide Your Keys
But wait! Don’t commit that code just yet. When you record requests and responses, you need to obscure all the secure stuff that gets passed into your requests and gets returned in your responses. Here’s a quick little utility I whipped up to hide the naughty bits:
It’s a lot of work, but what results are solid, deterministic tests that effectively exercise what your user experiences when signing up for your service. Delightful enrollment features leads to delighted customers, and delighted customers lead to delighted, well-paid entrepreneurs! Happy charging!
Rendering emails locally is a pain. Rendering all the emails in your Rails app is even more of a headache.
I frequently get requests from clients to send them a complete set of the emails sent from their applications for copywriting review. I wrote a quick gem for you to incorporate that function into your ActionMailer tests. It will log all of your emails to a central location so that you can zip them up and send them to your clients and/or stakeholders.
Then, you might have an ActionMailer spec like this:
After you run your suite or this particular spec, you’ll have a file with a path of /some/arbitrary/path/a_delivery.txt that contains the contents of your message. What’s neat is it works well with continuous integration - you could set up your CI to automatically prepare an up to date version of all the emails in your system.
I hope you find it helpful, and that it encourages you to write ActionMailer tests!
Every day starts the same. Open up iterm2, start up a tmux session and create 3 windows. One for working (generating models, opening up the Rails console, etc), one for the server, and one for running autotest in the background. Then, I name the Tmux session appropriately along with all the windows. It takes about 5-10 minutes to get this all set up nicely in the morning. I got kind of tired doing it and felt like it was wasted time. After some research and some honing, I’ve created the following script:
Hope you find it useful! For easy reference and forking I’ve created a gist.
Has Ruby on Rails been good to you? Has the framework helped you get a job or start your consulting career? If so, I challenge you to give 3 percent of your time for Rails 3 over the next few months. If you work 40 hours a week, 3 percent amounts to less than 5 hours a month! Could you donate half a Saturday a month to the framework that figuratively puts money in your bank account? I can, and that’s why I’m pledging three percent for Rails 3 over the next few months.
The Bugmashes have beengreat, but there’s still more to be done. The core team is dedicated and smart, but they can’t do it all. As of the time of this post, there are 1199 open tickets in Lighthouse, 898 open bugs, and 301 open patches. Oh yeah, and by the way, Rails has been basically overhauled and re-architected in its entirety (You might want to kick the tires a bit).
Stop whining about bundler. Stop complaining about the new routing DSL. Instead of taking the time to talk about everything that’s going wrong, put in the time to make it right. Here’s why you should pledge your three percent today:
It Makes a Better Framework
How confident are you in a framework that has 1199 open issues that aren’t going away? How much better would the framework be if developers like Jose, Wycats, and Koz were freed up to focus on the bigger picture? If you use Rails on a daily basis, your unique perspective matters, and you can help with the burden of all of these open issues.
It Makes a Better Community
Negativity is contagious. You can sit on the sidelines and complain about what’s coming, or you can get in the game and help make things happen. What stinks is that if there’s an obnoxious crowd heckling the players on the field, newcomers will be less inclined to jump in. Positivity can be a virus in the same way. If you truly love what you do and you’re grateful, exhibiting that makes the community as a whole better and it attracts newcomers to the project.
It Makes You a Better, More Marketable Developer
Knowing the internals of the framework you use on a day to day basis definitely makes you a better developer. There is no magic behind Rails, just smart design and Ruby. Consider pair programming with someone more experienced than you and how that impacts your performance. Now, imagine working with the leaders of the community on core functionality and how that can improve your skills.
Consider the benefits from a professional perspective as well. Do you think being a core contributor differentiates you in a hiring decision? If you’re a freelancer, does that provide you with something marketable over those still on the sidelines?
This post is for all the recruiters, hiring managers, and human resource professionals hiring developers today. At some point, someone decided that it would be cool or differentiating to post job listings asking for Rails Ninjas, Front End Hackers and Rockstar Web Developers. It’s an unfortunate practice to get your job advertisement noticed, and I urge you to stop.
For developers, words and names are important. From my personal perspective, here’s what these titles say:
Rails Ninja - You want me to creep around the codebase late at night and inject transient bugs to foil my developer nemesis? Should I do everything on my own, or do I have an exclusive ninja clan that I hang out with? You want me to do everything my way, or the way that’s been handed down to me from centuries ago? So, basically, you want a lone wolf that goes about their business without any collaboration or direct engagement?
Front End Hacker - Hacker? To hack a frontend project immediately resonates as short term fixes and solutions that aren’t elegant or user friendly. If you want to recruit hackers to do any type of coding beyond security and vulnerability detection, you’re in the wrong business.
Rockstar Web Developer - This is probably the most prevalent and astonishing of titles - do you really want what this stereotype personifies working in your organization? I immediately associate this with someone that’s arrogant, self-serving, and apathetic. Besides, how effective can you be at solving problems at 9AM when you’ve been up until 4 the night before partying like a ‘Rock Star’? Please.
Some of these questions or perceptions may seem silly, but like I said, words matter. Stop using these titles! What value does this add to your job posting? What does it convey about how you perceive developers? Developers want to be respected and appreciated, not trivialized. Developers want to be understood and stimulated. Here’s three better titles that I guarantee will yield a better candidate pool:
Pragmatic Programmers - (Note: this book is required reading for developers and anyone hiring developers) - Don’t you want to hire problem solvers? The best developers solve business problems with the simplest solution possible. They have a demonstrated history of making things work, and shipping. That’s what pragmatic programmers do.
Motivated, Lifelong Learners - Technology changes. Newplatformsarise, and new languages and frameworks emerge. For the best developers, the technology doesn’t matter. As mentioned above, developers are problem solvers first and programmers second. Finding the best talent is all about finding people that can identify the best tools to solve problems, and they’re unintimidated when it comes to learning and evaluating them. These individuals are typically well informed and love to read. In almost all cases, they thrive on learning new things, inside and out of their industry.
Social, Connected, Passionate Professionals - Books aren’t the only source of learning and discovery. For top notch developers, they realize the importance of community and engaging with peers. Exceptional talent will quickly get discouraged if they don’t have the challenge and stimulation of discourse with other stellar developers. Not to mention, connected individuals bring in more talent and great people. To solve problems, you have to communicate and collaborate. Sure, developers can tend to be introspective, but that doesn’t mean you shouldn’t like or connect with the people you work with.
Think about it from your own perspective for a moment. Can you picture yourself applying for a “CEO Rockstar”, “Recruitment Chef”, or “CTO Samurai” position? So, stop using silly titles. It only distinguishes you as someone who doesn’t regard software development as the art and science that it is.