Episode 41: This is the sausage being made

Episode 41: This is the sausage being made:

This week Ben Orenstein in joined by thoughtbot CEO, Chad Pytel, to discuss thoughbot’s books, online and in-person training programs, other educational products, and the launch of thoughtbot’s new subscription to everything they teach, Learn Prime. They also discuss some changes to apprentice.io, Five Guys, and much more!

• Episode Notes and Links
• Subscribe via iTunes
• Subscribe via RSS
• Direct Download

Introducing Learn Prime: Subscription access to everything we teach.

Today we’re happy to announce Learn Prime, a subscription service which gives you access to everything we teach. Your monthly $99 subscription gets you ongoing access to all of our books, screencasts, and even all our in-person and online workshops. Our workshops alone are normally over $1,000 when purchased individually!

In addition to our existing materials, we’ve created a new stream of articles only available to subscribers called Learn Bytes. We’ve already published Bytes on using subdomains in Rails, tricks for finding where a method is defined, and faking out a remote service using rack-test, with much more to come.

Subscribers also receive access to something we (humbly) consider the best resource of all: our team. Got a burning Ruby question? Need help testing something tricky? How about another set of eyes on a pull request? Head to our private Campfire room or send an email, and a thoughtbot developer will help you out.

Our goal is to create more great designers and developers. We hope this new subscription service makes our workshops and other learning materials available to even more people.

We’re are also introducing Prime for Teams. For $1999/month your entire team of up to 25 people can get access to everything provided by Prime. That’s less than the cost of your team’s daily pourovers! And for a limited time, as a special launch discount, the price for Prime for Teams is only $1299 per month!

We hope you’ll join the community of people who have already subscribed to Learn Prime. Find out more at Learn.

Clojure: Expectations Ignore A Variable Number Of Args In An Interaction Test

Over the past year I've written the same test a few times.

<script src="https://gist.github.com/jaycfields/5199020.js"></script>
This test accomplishes what I'm looking for when I write it - verification that my-fn isn't called. However, it doesn't prevent me from future regressions where my-fn is called with 0, 2, or 2+ arguments. After being bitten by this issue a few times I decided to add an argument matching function that will accept any value for the argument at it's index, and any value for all of the arguments at a greater index. This argument matching function is anything&

The following example is similar to what's above, except any call to my-fn will result in a failure

<script src="https://gist.github.com/jaycfields/5199074.js"></script>
My original intent was to protect against the scenario I described above*; however, what I ended up with is actually flexible enough to allow me to test other situations as well. For example, I've often found myself testing that a log message was written at a certain level, but not being interested in testing the actual message. The logging I'm working with allows a variable number of arguments, so anything& is perfect for verifying that no matter what args are passed in, the tests passes as long as the level is set correctly.

<script src="https://gist.github.com/jaycfields/5199272.js"></script>
The anything& matching function gives me an extra bit of flexibility that can come in handy at times.

*which is similar to verifyZeroInteractions in mockito

Clojure: Expectations Interaction Tests For Java Objects

I recently ran into some code that forced me to integrate with a Java library. While using the library I found myself wanting to do a bit of interaction testing, which I've historically done with Mockito. As a result, I added the ability to do interaction based tests on mock Java objects, directly in expectations.

Hopefully the code is what you'd expect.

<script src="https://gist.github.com/jaycfields/5198885.js"></script>
The previous example creates a mock Runnable in an expect-let, expects the run method to be run, and then calls the run method of the mock. This test is worthless in a real world context, but it's the simplest way to demonstrate the syntax for creating a mock & specifying the interaction.

The mock function defined in erajure, a minimal wrapper around mockito. All of the "times" arguments are the same as what's available for function interaction tests, examples can be found here.

Episode 40: He's winking at me

Episode 40: He's winking at me:

Ben is joined by Bryan Helmkamp, the founder of CodeClimate. In Bryan’s second appearance on the podcast, Ben and Bryan discuss the architecture behind CodeClimate, scaling the service, and growing the business. They also discuss speaking at conferences, proposal selection, two factor authentication and adding it to CodeClimate, marketing and content marketing, how to decide what to build and proving that it was worthwhile, strategies for testing at the beginning when you have few users, and Bryan reveals CodeClimate next big upcoming feature.

• Episode Notes and Links
• Subscribe via iTunes
• Subscribe via RSS
• Direct Download

Quoth the Raven

One a cold winter's morning this raven laid claim to a sunlit cornice. "Nevermore!"

How to test Sinatra based Web Services

Sinatra is a fantastic lightweight framework for building web services. We’ll use it as the server framework for the HTTP endpoints in our Service Oriented Architecture.

Unlike Rails, Sinatra isn’t all that opinionated on how you set up your application (it has a few sensible defaults), but leaves a lot of open questions on codebase structure, how to test the application, and how to make sure the client is performing as expected.

Sinatra Web Service application structure

A Sinatra application starts as an empty folder. Here’s a directory structure we’ve found works well to add a little organization.

app/
app/helpers
app/models
app/my_service.rb
client/
client/lib/my_client.rb
client/my_client.gemspec
config/
config/initializers/
config/environment.rb
spec/
spec/spec_helper.rb
Gemfile
Procfile
Rakefile
config.ru

The app directory contains the base Sinatra app, along with any helpers and models. The client dircotory contains the client gem which will allow other applications to connect to the service. config has environment settings, yml config files, and initializers. The spec directory holds our RSpec test suite.

Building a client gem

For internal (private) services we often build the client directly into the project, the advantage is you can follow the Outward-In development cycles by first building a feature into the client, and then writing request specs that use the client to connect to the web service.

This allows the us to dogfood our client gem and bring it in as the first step of our development process.

To achevie this we need to configure a few things.

1. Set up the project gemfile to use a local copy of the client in test mode

Include the client gem in your test suite.

# Gemfile
group :test do
  gem 'my_client', path: '~/path/to/my_service/client'
  gem 'webmock'
  # ...
end

2. Use webmock to send all client requests to the Sinatra application

Instead of booting up a localhost webserver every time the test suite is run, lets mount the Sinatra application as a rack app.

# spec/spec_helper.rb
RSpec.configure do |config|
  config.include WebMock::API

  config.before(:each) do
    MyClient.base_url = 'http://www.example.com'
    stub_request(:any, /www.example.com/).to_rack(MyService)
  end
end

3. Use the client in your request specs

After mounting MyService as a rack application we can now use the client gem in our test suite. This allows the client to talk directly to the mounted rack application.

# spec/requests/widget_management_spec.rb
require 'spec_helper'

describe "Widget management" do
  it "creates a Widget" do
    # set up fixture data if needed

    response = MyClient::Widget.create(widget_params)

    # assert expectations on the response
  end
end

Private gem hosting

To use the client gem in other projects we’ll need to use a private gem hosting service like Gemfury. This will allow us to include the client via gemfile in our other projects.

# Gemfile
source 'https://452f6E403CDph10714e41@gem.fury.io/me/'
gem 'my_client'

source 'https://rubygems.org
# ...

Takeaways

• Sinatra is great for creating lightweight services.
• Using Webmock we can test the client directly against the service.
• A private gem repo works well for hosting the shared client.

Written By Harlow Ward

Backbone.js Templates Without Logic or Interpolation

Traditional Backbone.js templates typically interpolate a few values and have a little basic logic, but even the simplest of these templates knows too much. It is the view’s responsibility to manage logic, events, and the relationship with models while the template should simply manage the HTML markup.

Enter the static template. It does not contain any logic or even interpolated values. In fact, a static template does not contain any executable code at all, it is just markup.

A static template and its view might look like this:

# app/assets/templates/profile_details.jst.ejs
<div class="status"></div>
<div class="name"></div>
<div class="age"></div>


# app/assets/javascripts/views/profile_details.coffee
class MyApp.Views.ProfileDetails extends Backbone.View
  className: 'profile-details'
  initialize: ->
    @$el.html JST['path/to/template']

  render: ->
    @_setStatus()
    @_setStatusClass()
    @_setName()
    @_setAge()

  _setStatus: ->
    @$el.find('.status').text @model.status()

 _setStatusClass: ->
    if @model.status() is 'online'
      @$el.find('.status').setClass('green')
    else
      @$el.find('.status').setClass('red')

  _setName: ->
    @$el.find('.name').text @model.name()

  _setAge: ->
    @$el.find('.age').text @model.age()

Keeping all that logic in the view has several key advantages:

1. Easier to test

Keeping all the logic in the view makes it much easier to test-drive that behavior. This in turn increases the quality of your code and gives you greater confidence to build and refactor.

2. Doesn’t break event bindings

With traditional templates, re-rendering creates new DOM elements which requires re-binding events. The DOM for static templates, on the other hand, is only rendered once. This spells the end of your event re-binding troubles.

3. Faster re-rendering

Static templates can significantly improve your re-rendering speeds. Rendering traditional templates was an all-or-nothing decision. However, By encapsulating all the logic into methods on the view, this becomes a much more granular decision. Arbitrary sections can be ‘re-rendered’ in response to events.

By keeping a strong separation of concerns between your views and templates, you end up with code that is cleaner, more modular, more readable, more performant, and easier to maintain. Give it a try, you will be surprised by the power and simplicity of this approach.

Learn more about Backbone best practices in our book Backbone.js on Rails.

Our Intermediate Ruby on Rails workshop is now available online

We’ve just opened registration for our new online Intermediate Ruby on Rails workshop, which starts Monday, April 1st, 2013 (we’re not kidding).

The workshop is taught by Matt Mongeau, who is an experienced thoughtbot Rails developer as well as the instructor of our Intro to Ruby on Rails workshop.

Over the course of a month you will build a Rails applications alongside Matt, working directly with him on many more complex Rails topics like user authentication, complex data modeling, file uploads, refactoring, and more.

Like all our online workshops, this isn’t just a series of videos; it’s an online workshop where you work directly with Matt getting one-on-one and group support.

Furthermore, when you take an online workshop with thoughtbot, it doesn’t just stop after the initial month. You get ongoing support for any Ruby on Rails questions you may have in the future, from Matt and the rest of the thoughtbot team.

We also have special pricing for groups, so your entire company can take the workshop.

We’d love to have you take this course. You can sign up now and the course begins Monday, April 1st, 2013.

Power Stroke

There is No Lab

Much has been said about remote work lately. Yahoo! brought it to the fore when CEO Marissa Mayer completely cancelled their remote work policy a few weeks ago. It made mainstream press and quickly raised the ire of David Heinemeier Hansson, whose beliefs about remote work have shaped his life: half of his 37signals co-workers are remote and he too spends half his year working abroad.

At Icelab we don’t have so much a formal policy about remote work (or about anything, really), but instead some simple guiding principles: work with good people to make good things, and as long as we can keep the business running, do whatever we can to help those people lead the lives they want.

I try to embody these principles: I spent the bulk of last year working from the Philippines and Hong Kong – and just this afternoon, I’ll fly off to Tokyo, the first leg in a trip that will see me working from five countries across three continents over the course of this year. Hugh’s done some of this too, also checking in from Tokyo for a month at the start of last year. And in a couple of weeks, David’s heading to Europe for a holiday and can extend it a little while by doing some work over there too.

Having people work from overseas has been no problem at all. In fact, 2012 was our biggest, most productive year yet.

Remote work isn’t all about extending a holiday or seeing the world. It can also be about finding the right space for productivity in everyday life. Even Yahoo! recognised that you can’t be chained to the office, that “occasionally [you] have to stay home for the cable guy,” but this is more a sign of their failure to recognise the intrinsic value in a change of environment. As The Economist argued:

Plenty of evidence suggests that letting employees work from home is good for productivity. It allows them to use their time more efficiently and to spend more time with their families and less fuming in traffic jams or squashed on trains… You can shackle a Yahoo to his desk, but you can’t make him feel the buzz.

We make our offices as comfortable and conducive to productivity as possible, but good work doesn’t always happen from the same place. Good people, on the other hand, are good people everyday, regardless of their location.