Mike asked a few of us to speak about a selection of five of our favorite ruby gems as a way to expose beginners to some great libraries. You can find all the talks on the BostonRB presentation listing. Jason Draper also delivered a great talk on writing your first integration tests that I definitely recommend checking out!

Video and slides from my presentation are below.

Want to learn how to use these ruby gems and more? Our latest project, Launch Academy aims to equip aspiring web technologists with the knowledge they need to become a junior developer in just 10 weeks. Apply today!

You can see the rest of our favorites in our rails template, ignition. We use this template when starting new projects for clients.

I presented some of our learnings to the Route 9 Ruby Group and recorded it. There were some great questions and discussion.

Writing command line applications with ruby is a nice break from the web-based world. I find you can focus much more on the intent of the app than the aesthetic, so it might provide a useful way to prototype some data intensive applications.

The big takeaways I shared with the group:

• Just like you would in your web applicatiions, respect the design pattern of Model, View, Controller (MVC) - it keeps things nice and modularized
• Test all permutations of commands, switches, and flags as best you can. Sometimes, you get some weird interferences or side effects
• Delegate to an object oriented API to keep everything testable
• Document how you want to use the command line application first. It really helps to keep it user friendly.
• Get the excellent book: Build Awesome Command-Line Applications in Ruby

If you’re interested in learning about Rails or getting to know the BostonRB community, the project nights are a lot of fun. We’ve gotten great feedback, and we’re looking forward to improving them over time. The project nights are on the first Tuesday of every month and we’re thankful to the great team at Thoughtbot for hosting us.

At LaunchWare, helping others advance is core to our values. We find that teaching is not only rewarding, but also helps to solidify our knowledge. We’re currently hiring, and we’re looking for developers that are eager to contribute to our wonderful Boston Ruby community in such meaningful ways. If you’re someone that loves to learn and give back, be sure to check out our careers page.

What It’s Like (And What I’ll Miss)

Day to Day

• We all work remotely, but we’re all located in the Boston area. This makes it easy for us to share dinners, co-work at the CiC, and meet with clients in person.
• Standup is at 10:30 am via Google Plus hangout.

• Correspondence throughout the day takes place on HipChat where there’s always something fun to read or rant about, measured in number of times we @launch image me coolio.

  

  See? It’s fun.

• Clients are easy to access through Pivotal Tracker comments and are generally quick and excited to respond.

• We try to follow a week sprint schedule: freezing code at noon on Fridays, staging all of our 4-5 concurrent projects through the afternoon, smoke testing in staging on Monday, and then pushing to production.
• We create feature branches each day, deploy to Github when finished, and Dan reviews code at 3:30 pm.
• A couple times a week we have workshops where we all give feedback and suggestions around a particular topic that we can improve on, like client management, quality assurance, etc. Also remote via G+ hangouts with some live google docs action.
• We’re expected to bill 35-40 hours a week, not eat sleep and breathe code
• Transitioning from hourly to results-based work environment

People

• There are 5 people at LaunchWare, including myself, not including LaunchBot (hopefully it doesn’t read this)
• We’re funny dudes
• We cover a large range of skills, while all proudly sporting the ‘full-stack’ skill set. We’ve got people who pride themselves on abstractions, project management, product management, design and css strategies, and more. Each person has found their niche and developed it extensively since joining the company. This desire to learn and develop is core to our culture.

Dan the man

Dan is our boss, and he’s the man. He gets his own ul.

• Super flexible in terms of travel, taking days off, etc.
• Cares a ton about us, the code, and the clients
• Works like a dog. The company is his baby and he’s always focused on making it bigger and better.
• Willing to, happy to, and loves to be a mentor to his employees - both professionally and personally
• Strict on code reviews - he’ll turn any mediocre coder into a master syntax, best practices, abstraction, framework, and api guru through his pull request feedback on Github.
• Open to feedback and change. I harass him about business process/ strategy all the time, call him out when he makes mistakes, and challenge him on pull request feedback. This is how we all learn. And it’s not just to Dan, it’s company wide.

• Cares about us personally. Example: when I roll out of bed, jump into the shower, and run to my computer at 10:29 am, I sometimes appear as if I’m still asleep during standup. I get this type of response.

  Dan: you looked tired this morning - everything ok?
  John: haha yes i look tired every morning :p
  

  What a guy.

Travel

I started at LaunchWare while I was studying abroad in Hong Kong. Home of the 12 hour time difference from EDT. I checked in before bed and every morning, and worked while the team was sleeping. Dan saw past this in hiring me, and we pulled it off well. That’s a tough thing to do for any company, not just a software dev firm.

During that time and since then I’ve been all over the world, and LaunchWare has been very flexible in allowing me to do so. The rest of our team has been doing some serious traveling too! Due to our remote nature, traveling is not an interruption. And it’s not a surprise to show up for standup and someone’s background change to a train, lake, or even beach. Just try to pick somewhere with wifi.

Oh and vacation is on an as-you-need-it basis and Dan is very flexible here. Even in my final weeks, he has been very flexible on letting me take a day here and there. Love it.

(Lack of) Bureaucracy

We don’t do that. We try to optimize our process as often as possible, but we’re all very conscious of when things become too structured. Just like in our code, we don’t like premature optimization in our process. So some things, like that travel policy, are left ambiguous until we stumble across it.

Why I’m leaving

Although the above insights and comments stand on their own, they of course beg the question: so why are you leaving?

The primary things you need to know about me:

• I’m a traveler: I’ve flown 57,500 miles since joining LaunchWare
• I’ve lived in Massachusetts my whole life
• I drive a red scooter (ok, irrelevant)
• LaunchWare is the only non-freelance programming job I’ve held
• I have an opportunity to live with one of my best friends from college in SF

I chose those details very specifically of course and you can probably then guess why I’m leaving. I’m a traveler who’s lived in one place his entire life. I love the idea of getting rid of all my stuff, packing up what’s left and heading out to explore somewhere new. Also, the timing is right. I don’t have much stuff, and my friend is looking for a roommate.

The other part is that I’ve never held another “job” in the development space. This again is tough to say as the unstable explorer type, so it’s time to try some new things. If they aren’t awesome, I’ll be back!

The exposition

Imagine there are two comments on a post. We want to assert that the most recent comment appears first.

We have the following markup:

1
2
3
4
5
6
7
8

<div>
  <div class="comment">
    <p>Here is a newer comment!</p>
  </div>
  <div class="comment">
    <p>Here is a comment!</p>
  </div>
</div>

The most obvious way

The most obvious way to assert that the newer commment appears first is:

1
2
3
4
5
6
7
8
9
10

let!(:old_comment) { Factory(:comment) }
let!(:new_comment) { Factory(:comment) }

within "div.comment:nth-child(1)" do
  page.should have_content new_comment.text
end

within "div.comment:nth-child(2)" do
  page.should have_content old_comment.text
end

Or some variant of this. page.find("div.comment:nth-child(1)") works too.

But this approach is brittle. What if we go all HTML5 on this template and change the comment divs to article tags like so:

1
2
3
4
5
6
7
8

<article>
  <article class="comment">
    <p>Here is a newer comment!</p>
  </article>
  <article class="comment">
    <p>Here is a comment!</p>
  </article>
</article>

Then our test is broken.

Or worse, if we add another comment into the mix as part of another test:

1
2
3

let!(:old_comment) { Factory(:comment) }
let!(:new_comment) { Factory(:comment) }
let!(:some_other_comment) { Factory(:comment) }

Our markup becomes:

1
2
3
4
5
6
7
8
9
10
11

<article>
  <article class="comment">
    <p>Here is a comment!</p>
  </article>
  <article class="comment">
    <p>Here is a newer comment!</p>
  </article>
  <article class="comment">
    <p>Here is a comment!</p>
  </article>
</article>

Not nth-child 1 and 2 anymore…

But hey, we don’t really care which children they are, or what tags they are. We just want to know if the text of the new comment is on the page and placed somewhere before the old comment! Let’s test that. So, here you have it:

The less brittle (and therefore better) way

We know thse things:

1. With capybara, you can grab the contents of the whole page as a string by calling page.body.
2. And with a Ruby string, you can grab the position (index) of a certain substring by calling index(substring).
3. And with Rspec you can assert that one index/position is less than/before another using index1.should_be < index2.

So put that all together, and we replace the brittle approach above with this:

1
2
3
4

let!(:old_comment) { Factory(:comment) }
let!(:new_comment) { Factory(:comment) }

page.body.index(new_comment.text).should < page.body.index(old_comment.text)

Awesome!

But there’s one more thing:

The one more thing (best) way

It would be annoying to type that over and over. What if you or the guys at LaunchWare figure out a better way to do this in the future? You wouldn’t want to have to find-and-replace your whole code base. And we wouldn’t either.

Try this Rspec custom matcher definition on for show:

1
2
3
4
5

Rspec::Matchers.define :appear_before do |later_content|
  match do |earlier_content|
    page.body.index(earlier_content) < page.body.index(later_content)
  end
end

Once this is in play, you can now make this magical assertion:

1
2
3
4

let!(:old_comment) { Factory(:comment) }
let!(:new_comment) { Factory(:comment) }

new_comment.text.should appear_before(old_comment.text)

Definitely try this at home:

How to add this to your project

I’ve released this as a gem! so all you have to do is add

1

gem 'orderly'

to your gemfile. Then you can assert

1

this.appears_before(that)

And you’re in business. #win

Follow me on Twitter at jmondo for <= 140 char gems

There were some great talks and questions asked during the session. One question was “How do you identify components in your application that should be extracted to an engine?”

Basically, you should apply the same principles to engine development as you do regular, object oriented development. Don’t repeat yourself, and identify opportunity for abstraction. If you find yourself building the same functionality across many different Rails apps, there is likely opportunity for you to extract a Rails engine.

Introducing Roboto, a Rails Engine for providing environment specific robots.txt files. Use this to hide your staging and QA environments from search engines.

Google will penalize you if content is duplicated across multiple domain names. If you have a publicly accessible staging environment, this could be hurting your production environment’s search engine rankings. Follow along with this tutorial to hide your staging environment. Note, Roboto only works with Rails 3.1 and higher.

First, remove the generated robots.txt in your Rails App:

1

  #> rm public/robots.txt

Next, add roboto to your Gemfile:

1

  gem 'roboto'

1

  #> bundle

Then, add roboto to your routes (config/routes.rb):

1
2
3

  Rails.application.routes.draw do
    mount_roboto
  end

You can now specify environment specific robots.txt files in config/robots. So, in the case where we want to add a global disallow to our staging environment, we would create a file with the contents below at config/robots/staging.txt. If you haven’t done so already, copy config/environments/production.rb to config/environments/staging.rb and configure your staging server to run in the staging environment (Passenger, Heroku, Unicorn).

1
2

  User-Agent: *
  Disallow: /

You can also specify a fallback robots/default.txt for any environments you do not need to be explicit about.

To get started, just follow the instructions found on the github repo. We use it in a Rails 3.1 project, so it was a simple as adding a splash of bourbon to our gemfile and then including bourbon in our SCSS files.

The next step is to just start experimenting. You’ll quickly find that Bourbon’s syntax is intuitive and follows normal CSS syntax when possible. It provides you with a basic set of tools and gets out of the way. Want a linear-gradient, box-shadow, and border-radius applied to your awesome div?

1
2
3
4
5

div.awesome {
  @include linear-gradient(#f1f2f4, #ccc);
  @include box-shadow(0px 1px 4px rgba(0, 0, 0, 0.3));
  @include border-radius(4px);
}

Want to apply your awesome div styles to other elements in a single line? Want to do that while enabling the flexibility of changing the gradient colors? All you have to do is create a Sass mixin and some variables.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// create the mixin

@mixin awesome_mixin($top_color, $bottom_color) {
  @include linear-gradient($top_color, $bottom_color);
  @include box-shadow(0px 1px 4px rgba(0, 0, 0, 0.3));
  @include border-radius(4px);
}

// awesomeness

.div_needing_awesome {
  @include awesome_mixin(#748BB9, #5570a7);
}

Do you want to use Bourbon’s button add on, but modify your button’s margins and padding on the fly?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// create the mixin

@mixin awesome_button($color, $margin, $padding){
  @include button($color);
  margin: $margin;
  padding: $padding;
}

// button time!

.big_awesome {
  @include awesome_button(#5570a7, 4px, 20px 40px 24px 40px);
  font-size: 22px;

}
.small_awesome {
  @include awesome_button(#51c96e, 4px, 5px 7px 8px 7px);
}

Note above that you can use shorthand for the $margin and $padding variables just like you would with plain css. All you have to do is comma delimit them when passing as an argument.

Be sure to find a list of all supported functions, mixins, and addons at the bottom of the documentation. There are some helpful functions like tint and shade for altering colors and useful variables like font-family.

Finally, you can bundle open bourbon to explore the gem. The source is well organized and readable. You can see all the work thoughtbot put into the project to make your life easier.

1

  <%= link_to "Delete", widget_path(@widget), method: :delete %>

Every time I write something like this, it makes me think twice. The problem with this code is that it heavily relies on JavaScript and jquery-ujs to trigger the right action on the server (An HTTP DELETE request). Anchors are semantically only capable of linking to URL’s with a GET request.

Here’s why writing a link this way is bad:

• It relies heavily on javascript. Any user with a non-JavaScript capable browser will not be able to exercise this action.
• It can be followed by a bot if you’re not careful. Search engines and other bots might catch this link and attempt to follow it.

Sometimes, I’d write a link with a manual route so that I could use a proper link. Something like this:

1

  <%= link_to "Delete", delete_widget_path(@widget) %>

After properly configuring routes and a controller, this issues a GET to the widgets controller and destroys the widget via a delete instance method. This is even worse for a number of reasons:

• It violates RESTful conventions. A GET request should generally not cause writes to your domain objects.
• It circumvents a bunch of Rails countermeasures and makes you succeptible to exploits. Things like cross site request forgery protection aren’t run on GET requests. That means a malignant user could try to impersonate another user by hijacking their session.
• This link is even more succeptible to bots following it if you do not include a rel=”nofollow” attribute.

With a desire for other opinions, I turned to twitter and had a great conversation with some smart folks. We were debating on how HTTP should not constrain a user’s experience and that there should be an accessible way to markup links that issue a DELETE request. Ultimately, it boiled down to a decision between using a link as opposed or a button and/or form element for this type of interaction. Kevin’s tweet really hit home for me.

A button would look something like this:

1

  <%= button_to "Delete", widget_path(@widget), method: :delete %>

Buttons and links look very different natively, but that’s not HTML’s fault. Browsers interpret them differently, making for very distinct renderings.

The markup or the HTML standard is not at fault here. The browser makes a certain assumption of how you want a button to look vs. how you would like a link to look. If you’re practicing sound web standards, aesthetics and presentation should be the responsibility of your CSS. So, I created a SCSS/SASS mixin to make a button look like a link.

1
2
3
4

  input {
    @include link_like_button;
    color: blue;
  }

Which looks much truer to form (note I’ve added color: blue in addition to the mixin):

So in conclusion, don’t use a link to trigger write or destroy actions, especially for aesthetic reasons. You can override the styling opinions of the browser to make a button appear to the user like a link.

As an aside, Twitter can be such an awesome place to learn a thing or two. Since investing in community is part of our company values, we spend a lot of time there. If you’re new to Ruby or the Rails community, it is a great way to learn purely through osmosis.

Let me show you how the users of your app can share activities on Facebook. Thankfully, the effort required to integrate a feature like that has gotten a lot easier with tools like OmniAuth and the introduction of Facebook Dialogs. What’s more, they’ve made it so that you can provide a progressively enhanced experience for your users. In this article, I’ll walk you through how to build a link that works with or without JavaScript enabled.

Create Your App

We won’t reinvent the wheel here. Check out the well written guide on how to create your app. Be sure to note your AppId and Secret Key

Integrate OmniAuth

We used omniauth-facebook. We don’t advocate the use of devise’s baked in omniauth support because it does not support the ability for users to have multiple identities. If you want to eventually support other authentication mechanisms like Google or Twitter, you’ll run into some architectural problems.

For more detail on getting omniauth set up, the tutorial over at NetTuts isn’t too terrible.

Show Dialog Links For Facebook Authenticated Users

Add our little facebook_dialog gem to your Gemfile.

1

gem 'facebook_dialog'

Add your api key to an initializer like config/initializers/facebook_dialog.rb

1

FacebookDialog.api_key = "<your appid/api key>"

In your view, do something like this:

1
2
3
4
5
6
7
8

<%- feed_dialog = FacebookDialog::Feed.new({
  redirect_uri: "http://www.example.com",
  link: "http://www.example.com",
  name: "Wow!",
  caption: "Something pretty awesome",
  description: "Zomg! You won't believe what I found on the web."
})-%>
<%= link_to "Share on Facebook", feed_dialog.url, id: "share_on_facebook" %>

You can then add the JavaScript pieces at the tail end of the body to optimize page loading. Check out our simple jQuery example below:

1
2
3
4
5
6
7
8

<%= facebook_js %>
<%= javascript_tag do %>
  <%= fb_init_js %>
  $("#share_on_facebook").click(function(e){
  e.preventDefault();
    FB.ui(<%==  feed_dialog.to_json %>);
  });
<%- end -%>

The facebook_dialog gem supplies the facebook_js and fb_init_js helpers.

Independent

Stories that are independent make the whole development process easier. You don’t have stories waiting for others to be completed so estimation of development time becomes more precise. Be creative, sometimes stories can be combined or defined in a way to decreases dependencies.

Negotiable

Stories help in the discovery and planning phase of a project. They facilitate the conversation between client and the development team. Remember to note high-level details and decisions that are made in these meetings.

Valuable

Make sure each story provides value to either the purchaser or user of the product. This type of focus can help in the proritization of stories. Some clients are comfortable writing their own stories and this can provide good insight into their vision of the product.

Estimatable

If a story is not estimatable, it is usually too large or the development team lacks the domain or technical knowledge necessary for an estimation. A conversation with the client can increase domain understanding, while a developer can build technical understanding before estimation.

Small

Small stories allow for the most accurate predictions. If they are too big or small, it is difficult to block out the correct about of development time. Combine or split stories to managable sizes. Stories can be split by user actions (separate create, edit, update stories).

Testable

A story is not complete until it can pass automated tests. Non-functional or overly subject requirements can lead to untestable conditions and should be avoided. As the code base evolves, you will continually use your tests to ensure old stories are not broken.

Exceptions can be perceived as non-local GOTO statements. This can adversely affect the readability of your code and mislead team members as to the actual intent of your method. Let’s take an oft-used controller action for example.

This is bad for a few reasons. First, we’re utilizing what’s called a catch all exception here. This is bad design because we could be burying an error that developers need to know about. Perhaps there’s a hook that sends an email out upon creation, and the SMTP server is down. With this implementation, the developers would have no way of knowing about that exceptional case and users would continue to receive unprocessable entity status codes.

This is also a violation of REST. When something is exceptional or in an errant state, like an SMTP server being down, the proper status code to return is 500 (Server Error). Returning an unprocessable entity infers to the client that they have supplied invalid information and that they’re disobeying the API’s contract.

So, let’s improve this example a bit to remove the catch all exception:

This is better because it expressly handles for an expected exception as opposed to any error that can happen in the ruby universe of errors. This way, if an SMTP server was unavailable or timed out, developers could be notified about that problem and address it.

There’s still a problem here, however. The code above is not intentional and should be considered a violation of the Principle of Least Astonishment. Programmers read code a heck of a lot more than they write it so your code should be clear and intentional. Utilizing a conditional expressively states “I’m expecting this case to fail sometimes, and here’s how we handle it.”

This also allows us to evaluate all the lines in each side of the conditional whereas a rescue halts execution.

There are also moderate performance gains to using conditionals because Ruby is optimized for that logic as opposed to exception handling.

This conversation is not new. To quote one of my favorite books (first published in October, 1999), The Pragmatic Programmer,

“…exceptions should rarely be used as part of a program’s normal flow; exceptions should be reserved for unexpected events”

If you’re still not convinced, let me google that for you.

I’ve been playing around with SpringPad and thought it would be cool to share my notebook from the day. Check out my notes.

After using SpringPad on my iPad for the day, I can see myself taking notes at other conferences in this way. I’ve really been enjoying the application, and I recommend you check it out. I also dig the Android app.

Another great idea the organizers incorporated into the agenda were lunch conversations with all of the speakers. It was a great way to facilitate a more interactive chat. The highlight of the day for me was watching Elizabeth Yin guide business oriented founders towards not rushing to build products and to make small steps towards building complex feature sets. She did a phenomenal job expressing Lean Startup sentiments in a simple and understandable manner. Launchbit has done a great job assembling a toolkit for founders to assess their business ideas. I definitely recommend checking out the Launchbit site.

If you’re using Rails and you want to be secure, you should be protecting against mass assignment. Basically, without declaring attr_accessible or attr_protected, malicious users can set any column value in your database, including foreign keys and secure data.

Here’s a brief introduction to how mass assignment protection works. Let’s say you have a user that belongs to a group:

When I set group_id to be protected, I’m disallowing it to be set by mass assignment.

My recommended approach, however, is to always set a whitelist of mass assignable attributes with attr_accessible instead of a blacklist with attr_protected. That way, you don’t unintentionally leave a secure attribute unprotected.

This was a great addition to the Rails framework, but I always found myself wanting to conditionally protect attributes based on the state and authorization of my user. For example, I might want disallow users from setting their roles when they update their profiles, but I might want to allow admins to adjust their role via an administrative backend. This is how you can get it done in Rails 3.1

Along with this helpful change, you can also circumvent mass assignment protection entirely. This is useful, for example, if you’re loading data and you control the source.

You should really only use without_protection if you control the inputted attributes. It isn’t something you’d want to have in a controller action, generally speaking.

For more information on scoped mass assignment and additional attack vectors you should be securing against, check out the edge Rails guide on security

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.

Slides Below:

Hope you find them useful!

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.

For more details, check out their docs.

Implement Transparent Redirect

I used the Braintree gem to get things going.

Initializer

Put your Braintree configuration in an initializer like config/initializer/braintree.rb

Schema Changes

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.

Custom Attributes

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):

Integration Test

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!

Also, here’s the complete GIST for reference.

A big thanks to Michael Durrant for filming the presentations!

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.

I’ve called it postmaster_general.

Once installed (add it to your gemfile as specified in the README, set the log directory like so:

PostmasterGeneral.log_directory = "/some/arbitrary/path"

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!

Hope you find it useful! For easy reference and forking I’ve created a gist.

The Bugmashes have been great, 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?

Get in the game. Pledge your 3 percent today and give back.