Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

My must-see list from MWRC 2013

Stephan Hagemann
Saturday, May 4, 2013

TL;DR

If you watch one talk from Mountain West Ruby 2013, watch Greg Baugues: Devs and Depression.

Talks @ Mountain West Ruby Conference

Mountain West Ruby, was a great conference: lots of content and awesome people. It had one DevOps day and two Ruby days. Its presentations have recently been posted on confreaks.

There were a total of four talks by Pivots, including one by myself (in order of appearance):

  • Andy Pliszka: Extending CRuby with native Graph data type.
  • Matt Kocher: Ruby off the Rails: Building a distributed system in Ruby.
  • Stephan Hagemann: Component-based Architectures in Ruby and Rails.
  • Sarah Mei: Work, Play & Code.

What follows is the list of talks that I recommend watching.

There is one talk that I want to highlight within my list of highlights: “Devs and Depression”. It is the last one in this list and as you can guess it is not about technology. It’s different, bold, and in my opinion very important. Watch it!

Alright, here we go…

DevOps Day

Gene Kim: Why we need devops? - 30000 feet view of why devops is valuable and how to do it. It’s a 3 trillion market.

Will Farrington: Boxen: How to manage an army of laptops – Some impressive stuff github is doing for machine management.

Lindsay Holmwood: Escalating complexity: DevOps learnings from Air France 447 - Chilling: Case study of an airplane crash. Systems within complex systems. Local vs global rationality.

If you want more:

James Turnbull: Hell has frozen over: DevOps & Security – How security people should change their work and how they talk about it.

Drew Blas: Migrating a live site across the country without downtime – Actionable story on how to move data centers.

Jesse Newland: ChatOps at Github – Using hubot (in campfire chat) to manage puppet (and everything). Documenting, interacting, interfacing among remote teams.

Ruby Day 1

Yukihiro Matsumoto: Ruby 2.0 – History of Ruby and features of Ruby 2.0. Maybe don’t watch if you already know about the new features. Maybe watch it, because its Matz.

Michael Fairley: Immutable Ruby – How immutability can benefit your code.

Daniel Huckstep: Ruby Batteries Included – Don’t require gems: Use the Ruby Standard Library.

Ryan Davis: Trolls of 2013 – Not abut trolls, but implementing an interpreter in Ruby. Talk got cancelled on the first day, due to a fire alarm. Way to deal with it Ryan!

If you want more:

John Pignata: Code Smells: Your Refactoring Cheat Codes – Run through a long list of code smells and refactorings.

Ruby Day 2

Brandon Keepers: Ruby at Github – Musings on Ruby: when to use, why to use. And problems (over time) in a big setup.

Craig Kerstins: Postgres Demystified – Lots of stuff you did not know about Postgres.

Greg Baugues: Devs and Depression – Personal story of mental illness. Talks about depression and why we should be more attentive to our fellow developers.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

GoSpotCheck Is Looking For A Web Application Developer

Stephan Hagemann
Wednesday, February 20, 2013

At Pivotal Labs, one of the services we provide our clients is helping them interview and hire. Pivotal Labs and our clients place a strong emphasis on Agile development and its many aspects: Pair Programming, Test-Driven Development, rapid iterations, and frequent refactoring.

LEAD DEVELOPER
GoSpotCheck is seeking a Ruby developer to join our growing team and take an integral role in building our product. GoSpotCheck is a simple way to collect, structure, and share retail intelligence for distributed field teams. We have mobile applications for capturing data and a web application for digesting and analyzing field intelligence. Our applications streamline the process of getting from data to insights to action for enterprise retail customers, enabling them to more effectively manage retail execution.

JOB REQUIREMENTS

  • Proven experience in development of flexible and scalable web-based applications
  • Passion for technology, specifically software development
  • 2+ years of experience with Ruby language and the Rails framework, be proficient with the entire Ruby on Rails stack
  • 3+ years of hands-on web development, demonstrating:
  • Proficiency with HTML/XHTML, CSS, JavaScript and JQuery
  • Sound object oriented design skills and knowledge of application architecture patterns
  • Proficiency with relational databases, including design and development
  • Working knowledge in development of MVC-based web solutions
  • Competency managing source control and automated build processes
  • Excellent analytical and problem solving skills
  • Strong communication and interpersonal skills
  • Android and iOS a big plus

ABOUT OUR COMPANY
GoSpotCheck was founded in May 2011 and is a graduate of the renowned TechStars program. We are backed by some of the best early stage tech investors including 500Startups, Venture51, Doug Feirstein, Walter Winshall, Dave Carlson, and former Coca-Cola CMO Sergio Zyman.

BENEFITS & COMPENSATION
Along with a competitive salary and 100% paid benefits, we offer a highly dynamic and exciting work environment where you will get the chance to make huge contributions to the company. We believe in giving everyone the ability to excel at their job, and that means giving our people the ability to create impact in any way they see fit.

Contact careers@gospotcheck.com and we’ll get back to you ASAP!

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Migrating from a single Rails app to a suite of Rails engines

Stephan Hagemann
Tuesday, March 13, 2012

TL;DR

We moved a Rails app into an unbuilt engine of a new blank slate container app to allow new parts of our app to live next to it as engines as well. It has been working great for us!

I have a sample app rails_container_and_engines of the result’s structure on github.

Skip to the pitfalls and discoveries section to read about some of the speed bumps we during our transition. Interested in the why and how? Read on!

Rationale

As part of the project we had built a web app, a mobile app that talks to the web app’s API, two ETL tools to 1) do the initial data import from the app we were replacing and 2) get data into another of our client’s apps. At this point we knew that we would create one more big web app and several auxiliary apps.

Running up to the decision to using unbuilt engines we had several intense discussions on how to build loosely-coupled, highly-cohesive systems with Rails applications. We saw basically three choices:

  • All-in-one app that could get more structure through namespacing of its interals.
  • Services (REST or whatever, but) running as separate apps and communicating via APIs.
  • Engines running within a mostly feature-less container app.

The two big web apps share several models within the data access layer and use the same data. Because of this we chose the third option and left all of the apps within the same rails code base.

Internal discussions highlighted the costs/benefits of having all of these apps live within their own Rails project versus an engines approach. We feel that by using engines we are getting many of the benefits of a component based architecture without breaking Rails patterns. In addition, we feel that the cost of maintaining individual applications that share a central database or one giant application with less defined components would have been very high.

In order to make day to day development easier, and to avoid the “where do migrations live…” conversation and top level Rails deployment patterns, there is one twist to the architecture: everything resides in one git repo and engines are referenced from a single container application (similar to old school enterprise archive files). Each application is exposed via a unique context or resource identifier (each engine/app could also be isolated per instance via Apache). Here is the directory structure we ended up with:

container_rails_app/
  ...
  app
  config
  engines/
    etl/
    shared_modules/
    web_app_1/
    web_app_2/
  ...

Mike described this pattern in his recent blog posts Unbuilt Rails Dependencies: How to design for loosely-coupled, highly-cohesive components within a Rails application and Rails Contained: A Container for Web Application Development and Deployment. On how to make RubyMine work seamlessly with engines, read my post on IntelliJ Modules in Rubymine.

The steps we took

  • Generate a new, empty Rails app
  • Within the engines folder, create a new, mountable Rails engine
  • Copy all the tests from the original Rails app into the test directory and make them green.

    Ok. This step is a bit more involved. Essentially that’s it thought. Find some of the pitfalls we ran into described below. Here are a couple of highlights of what needs to happen:

    • Copy the files you need for a test to pass and namespace its class
    • Start with the model tests and work your way up towards integration and acceptance tests
    • Namespace everything with the name of the engine (either by fully qualifying every name – don’t do that) or with the lexical scope trick explained below. This includes tests and all classes.
    • Load needed gems explicitly: engines don’t load as much automatically as a Rails app
    • Namespace tables and assets
  • Copy the old .git directory into the new root folder in order to not loose any history. For us, git was not able to detect the changes as moves in many cases. This is certainly an area where you can improve on our solution!

For us, the real work started after this, when we started pullling out common code into a common models engine and began work on the second app.

We got all the tests to pass before we had namespaced any of the assets or rake tasks. That was an additional search-and-replace heavy step after the actual transition to an engine. It is not necessary right away if you do not have multiple applications at first, but to achieve the full effect, you will need to namespace the things as well.

Pitfalls and discoveries

Namespaces

Modules in your enige are not automatically loaded: make sure you reference them yourself before they are needed in other files.

Asset pre-compilation

Rails creates a default app/assets/stylesheets/application.css file which contains these lines:

/* ...
*= require_self
*= require_tree .
*/

If you have this file in your main app, all css files will be compiled into one file. For us, this made almost everything look right. Almost. Little things broke here and there. Our app contained a couple of sections for which the stylesheets were meant to be loaded separately. Add files that you want to have precompiled as individual files to config.assets.precompile list to have them precompiled into separate files and solve this problem.

Are all your references and associations breaking?

Try this

class M::Y
  def use_y
    M::Y.do_it!
  end
end
class M::Y
  def self.do_it!
  end
end

instead of

module M
  class X
    def use_y
      Y.do_it!
    end
  end
  class Y
    def self.do_it!
    end
  end
end

The first way sets the lexical scope to the module M as well as to the class Y allows you to references other classes in M without their full name. The second way sets the scope only to class M::Y and you have to fully qualify every class name to find it.

Don’t fight conventions

We were using fixture builder and while we were namespacing classes in modules we were trying to override the default table names to not be namespaced… Fixture builder didn’t like that at all. There may or may not be other dependencies that make leaving the conventions hard. So, save yourself the trouble and do the migrations (and stay consistent!) and namespace your tables as well!

HABTM

They seem to be falling out of favor, which is probably a good thing. With engines they don’t seem to work (well). We ended up getting rid of our last two habtm relationships instead of trying to make them work. Creating the join as a class and adding the necessary has many :through relationships is straight forward enough.

We ended up with one production performance bug due to this: Rails

Engines depending on engines

We used kaminari for our pagination requirements. When our app first became an engine, kaminari stopped picking up our custom views. Instead it used its standard views. The load order got screwed up to which there are basically two solutions:

  • require => nil on both engines in the Gemfile and force the correct load order in your app, or…
  • avoid name clashes by namespacing your views (which you were going to do anyways, right?)
  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Never use shared examples groups! Usually.

Stephan Hagemann
Friday, March 9, 2012

Shared example groups are a feature of rspec that allow specifying common behavior in a reusable group of specs.

I believe that there is a very specific way in which one can benefit from shared examples groups (and should keep them) and many more in which they come in handy at some point and should be refactored away from as development continues.

When shared examples may seem a good idea

If an application employs mechanisms such as mixins, delegation, or inheritance (which every Rails app by default does…), one can probably find some common behavior. Take a soft-delete functionality for example: specifying for each class that it’s objects are soft-deletable and that it_behaves_like :soft_deletable seems nice, but comes at a cost (and isn’t appropriate).

Shared examples make for a slow test suite

If there are n test cases and m specs in the shared examples, there is a total of n*m specs that will run. Obviously the shared example saves a lot of spec coding: m shared specs, and n references to it. Meaning you need to write only n+m specs.

If, however, it were possible to test the common functionality separately (m specs) and then test only its integration (n specs), there would still be n+m specs to write, but more importantly, there would also be only n+m specs to execute.

n*m vs. n+m, that’s a huge difference.

How to test common code without shared example groups

There are a couple of ways to test common code without resorting to shared examples.

In your spec, write a test harness class that gets your mixin, delegate, or (abstract) super class. This class only has the abilities of a non-special object and the common code. Testing this class allows testing the common code in an isolated way.

If you happen to be relying on ActiveRecord for your mixin as soft-deletable probably would be, use Temping to create an ActiveRecord object that only has ActiveRecord::Base behavior and that of the common code.

In case you have shared example groups in place, but can’t apply either of the above options, you probably haven’t extracted the code enough yet. Do that first and then come back here and refactor away from the shared example group.

Is a shared example group ever the right thing to do?

Imagine a mixin that has complex interactions with the objects it gets mixed in to, like a it_behaves_like :fuzzy_matchable. Fuzzy matching will always work in a similar way, but be working on different attributes or methods depending on the object. In this case the interactions between the object and the mixin are important to specify and verify. David Chelimsky describes this situation in his post about specifying Mixins with shared example groups. This kind of complex interaction seems to me to be the only case in which shared example groups are truly beneficial.

Am I missing good use cases of shared example groups here? Where do you use them?

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Specific interfaces – in the small

Stephan Hagemann
Wednesday, March 7, 2012

Everyone on the Web I found who states that quote I was looking for says “I don’t know who said it, but be ‘Generous on input, strict on output’” (or some variation on this). While I am unsure about the first proposition, I wholeheartedly agree with the second.

Edit 3/8: the quote is known in a different wording as Postel’s Law, which shows up as the Robustness Principle in RFC 793, the specification of TCP. Thanks for the hint, Austin!

Unfortunately, the closest a Rubyist typically gets to the implementation of an interface specification is his tests. This provides a pretty good, but somewhat disconnected specification that can sometimes cover up imprecisions in the interface’s implementation.

On top of that, sometimes our frameworks make it easy to forget what our tests are asserting or spec’ing.

Take rspec’s predicate matchers and this example:

require 'rspec/core'

class VeryImportantQuestions
  def self.really?(answer)
    answer == 'Yes. I am telling you.'
  end

  def self.really_really?(answer)
    answer == 'Yes. I am telling you.' ? 42 : nil
  end
end

describe "really?" do
  context "using rspec predicate matchers" do
    context "if someone is telling you" do
      it "should be really really the case and return true" do
        VeryImportantQuestions.really?('Yes. I am telling you.').should be_true
      end
    end
    context "if someone is not sure" do
      it "should return false" do
        VeryImportantQuestions.really?('I am not sure.').should be_false
      end
    end
  end
end

describe "really_really?" do
  context "using rspec predicate matchers" do
    context "if someone is telling you" do
      it "should be really really the case and return true" do
        VeryImportantQuestions.really_really?('Yes. I am telling you.').should be_true
      end
    end
    context "if someone is not sure" do
      it "should return false" do
        VeryImportantQuestions.really_really?('I am not sure.').should be_false
      end
    end
  end
end

be_true and be_false effectively hide the fact that what’s actually spec’ed is truthiness and falsiness. Only when the following context is added is this imprecision revealed:

  context "spec'ing the actual output of the method fails" do
    context "if someone is telling you" do
      it "should be really really the case and return true" do
        VeryImportantQuestions.really_really?('Yes. I am telling you.').should == true
      end
    end
    context "if someone is not sure" do
      it "should return false" do
        VeryImportantQuestions.really_really?('I am not sure.').should == false
      end
    end
  end

With regard to rspec, I suggest to consider twice whether the benefits of using specific matchers to not outweigh their benefits in your situation. You might get nicer test output, but you might lose the ability to immediately tell what you’re spec’ing.

With regard to tests in general: be specific about what you output – aka be specific about what you test.

Here is the gist: https://gist.github.com/1998462

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Boulder Standup – Feb 16, 2012

Stephan Hagemann
Thursday, February 16, 2012

rspec should render_template still behaving weirdly

Specing a partial being rendered with render_template blows up. What to do?

render_template has been brittle for a long time. It obviously still is:

response.should render_template("template") #works fine
response.should render_template(partial: "template") #works fine
response.should render_template(partial: "template", locals: {local_array: []}) #blows up within rspec

You know how to fix it? Solve it here

RubyMine 4 is out

RubyMine “compare two files” isn’t broken

It is just really, really weird: if you have to scroll when comparing two files check the file that is above in the project drawer first. If you scroll up to do select the second file to compare, the compare window won’t open.

Stubbing can? can be hard

In a system with a lot of cancan abilities – what is the best way to stub a particular ability for controller specs? In the hierarchy of controllers, a lot of abilities may be checked, all of which would need to stubbed in order to get to the code under test.

Instead of stubbing the abilities, create a new, anonymous, ability class specific for your spec that gets all the necessary abilities and then stub current_ability to return an instance of that class. Internally cancan calls current_ability when you call can?: cancan controller additions

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

IntelliJ Modules in Rubymine

Stephan Hagemann
Tuesday, February 7, 2012

IntelliJ has a feature called modules: “a functional unit which you can compile, run, test and debug independently.”

Modules in IntelliJ: Multiple top-level folders

A module in IntelliJ is a top-level view on a part of a codebase. IntelliJ is for Java, which is why I do not typically use it. I use Rubymine – no similar functionality exists here… but a way around that!

It may have been true at some point that these kind of modules were not something that Rails offered, but they have been around for quite a while: Engines!

Engines are typically seen as a way to package a Rails app that can be reused and configured in the context of other Rails apps. However, many big Rails projects can benefit from engines and their ability to structure a large codebase into smaller, more independent parts. Namespacing within one Rails app can achieve a similar effect, but engines take it to the next level: all the code, including views, javascript, and even rake tasks and migrations can be separated consistently. Now, if the apps were totally separate, several independent Rails apps might be the right solution, but if those are tied together by the same database, one might do more harm then good when ripping that code apart…

The Problem

Imagine a Rails project with the following folder structure:

rails_app/
  app/
  ...
  engines/
    custom_engine1/
    custom_engine2/
  ...

The engines are somewhat hidden away, two levels deep in the folder structure. Also, running specs for engines in these sub-folders won’t work from Rubymine, because the paths it tries to use are wrong.

Whether you are actually working with engines or just want to see multiple root folders in Rubymine at once, here is how to do it.

Make modules work in Rubymine

1) You can get modules to work in Rubymine by opening your Rails project in IntelliJ: Cmd + ; opens the project structure dialog, select Modules from the list on the left and create a new module with the + button. Or, you can simply add a few files to your project…

2) The .idea folder in the root of your project holds the Rubymine configuration files. Edit modules.xml and add a module line for every module you would like to create:

<!-- ROOT/.idea/modules.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
  <component name="ProjectModuleManager">
    <modules>
      <module fileurl="file://$PROJECT_DIR$/custom_engine1/module1.iml" filepath="$PROJECT_DIR$/custom_engine1/custom_engine1.iml" />
      <module fileurl="file://$PROJECT_DIR$/custom_engine2/module2.iml" filepath="$PROJECT_DIR$/custom_engine2/custom_engine2.iml" />
    </modules>
  </component>
</project>

In the root folder of every module create a .iml file with the name of that module like so:

<!-- ROOT/engines/custom_engine1/custom_engine1.iml -->
<?xml version="1.0" encoding="UTF-8"?>
<module type="RUBY_MODULE" version="4">
  <component name="NewModuleRootManager">
    <content url="file://$MODULE_DIR$" />
    <orderEntry type="inheritedJdk" />
    <orderEntry type="sourceFolder" forTests="false" />
  </component>
</module>

Voila: The next time you open the project folder in Rubymine, the custom_engine folders show up as top-level entries in the projects file list!

Modules in Rubymine!

Here is the gist: https://gist.github.com/1764127

This worked for me with Rubymine 3.2.4 and IntelliJ IDEA 11 CE.

Edit March 14: make sure that all module names are distinct and no module names are substrings of other module names. This confuses RubyMine and can prevent specs from running successfully.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Test your Rake tasks!

Stephan Hagemann
Sunday, February 5, 2012

There are several reasons why you should test your Rake tasks:

  • Rake tasks are code and as such deserve testing.
  • When untested Rake tasks have a tendency to become overly long and convoluted. Tests will help keep them in bay.
  • As Rake tasks typically depend on your models, you (should) loose confidence in them if you don’t have tests and are attempting refactorings.

A problematic Rake task test

Here is a Rake file…

File: lib/tasks/bar_problematic.rake

namespace :foo do
  desc "bake some bars"
  task bake_a_problematic_bar: :environment do
    puts '*' * 60
    puts ' Step back: baking in action!'
    puts '*' * 60

    puts Bar.new.bake

    puts '*' * 60
    puts ' All done. Thank you for your patience.'
    puts '*' * 60
  end
end

…and its too simplistic spec:

File: spec/tasks/bar_rake_problematic_spec.rb
require 'spec_helper'
require 'rake'

describe 'foo namespace rake task' do
  describe 'foo:bake_a_problematic_bar' do

    before do
      load File.expand_path("../../../lib/tasks/bar_problematic.rake", __FILE__)
      Rake::Task.define_task(:environment)
    end

    it "should bake a bar" do
      Bar.any_instance.should_receive :bake
      Rake::Task["foo:bake_a_problematic_bar"].invoke
    end

    it "should bake a bar again" do
      Bar.any_instance.should_receive :bake
      Rake::Task["foo:bake_a_problematic_bar"].invoke
    end
  end
end

Some notable aspects of testing Rake tasks:

  • Rake has to be required.
  • The Rake file under test has to be manually loaded.
  • In this example, the Rake task depends on the environment task, which is not automatically available in a spec. Since we are in rspec, the environment is already loaded and we can just define environment as an empty Rake task to make the bake task run in the test.

When run, this spec fails on the second it block… and that is not the only problem with this spec and the Rake task:

  • The Rake task duplicates code to output information to the user.
  • The spec “should bake a bar” will output that information when run, which clobbers the spec runners output.
  • The spec “should bake a bar” again will fail, because Rake tasks are built to only execute once per process. See rake.rb. This makes sense for the normal use of Rake tasks where a task may be named as the prerequisite of another task multiple times through multiple dependencies it might have – the task only needs to run once. In our tests we have to reenable the task.

A better Rake task test

A new version of the above Rake file…

File: lib/tasks/bar.rake
class BarOutput
  def self.banner text
    puts '*' * 60
    puts " #{text}"
    puts '*' * 60
  end

  def self.puts string
    puts string
  end
end

namespace :foo do
  desc "bake some bars"
  task bake_a_bar: :environment do
    BarOutput.banner " Step back: baking in action!"
    BarOutput.puts Bar.new.bake
    BarOutput.banner " All done. Thank you for your patience."
  end
end

… and its spec:

File: spec/tasks/bar_rake_spec.rb
require 'spec_helper'
require 'rake'

describe 'foo namespace rake task' do
  before :all do
    Rake.application.rake_require "tasks/bar"
    Rake::Task.define_task(:environment)
  end

  describe 'foo:bar' do
    before do
      BarOutput.stub(:banner)
      BarOutput.stub(:puts)
    end

    let :run_rake_task do
      Rake::Task["foo:bake_a_bar"].reenable
      Rake.application.invoke_task "foo:bake_a_bar"
    end

    it "should bake a bar" do
      Bar.any_instance.should_receive :bake
      run_rake_task
    end

    it "should bake a bar again" do
      Bar.any_instance.should_receive :bake
      run_rake_task
    end

    it "should output two banners" do
      BarOutput.should_receive(:banner).twice
      run_rake_task
    end

  end
end

This spec passes just fine and does not clobber the spec output. Again, let’s look at noteworthy things:

  • The output of the Rake task now goes through the BarOutput class. This reduces code duplication and allows for easy stubbing. There are other ways to achieve a similar effect and not clobber test output: Stub puts and print, stub on $stdout.
  • Rake.application has a nicer way of requiring Rake files than a simple load, because rake_require knows where Rake files live.
  • Rake::Task["TASK"].reenable reenables the task with name “TASK” so that it will be run again and can be called multiple times in a spec.

Here is the gist: https://gist.github.com/1764423

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Standup 11/11/2011: Some funkinesses

Stephan Hagemann
Friday, November 11, 2011

Interesting

  • rspec stub != stub!. stub! is an alias method for stub. There is however also a method stub that is an alias for double. If you try to stub a method on the test class (to stub it on the context), you should probably use the magic subject/helper/controller methods. If you don’t, using self.stub(:name => 'result') will create a double, while self.stub!(:name => 'result') will stub the method as you would expect.

  • Asynchronous file creation and downloading: if an asynchronous process writes a file using File.open and f.write, an other process checking the presence of the file to determine whether it is already available for download, will deliver the empty file, if the file has been opened, but not yet written.

    • Workarounds:
      • if you have one write to the file only: check filesize.
      • update an ActiveRecord attribute after the file writing is completed and check against that.
  • == on DelegateClass: newing up an instance delegate_x of DelegateClass from object x, x == delegate_x, while of course x.class != delegate_x.class.

Keystroke of the day

  • Rubymine KOTD: The search+replace mode you reach via Cmd+r allows you to see recent searches by hitting the down arrow. If that doesn’t work for you in Lion, hit Ctrl+h.
  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Another first four weeks: concerned and delegated

Stephan Hagemann
Thursday, November 10, 2011

James’ post from a couple of weeks ago inspired me to write up my own experiences of my first couple of weeks at Pivotal. However, instead of telling you how it felt, I will tell you about stuff I learned.

ActiveSupport::Concern

I have seen and used this pattern of adding both class and instance methods from a module to a class:

module Foo
  def self.included(base)
    base.extend(ClassMethods)
  end

  module ClassMethods
    def foo
      'classy'
    end
  end

  def foo
    'instancy'
  end
end

class Bar
  include Foo
end

Bar.foo # => "classy"
Bar.new.foo # => "instancy"

While the syntax for including Foo in Bar is nice and succinct, the definition of Foo contains the funny looking “included” hook to also extend the base class.

If you happen to have ActiveSupport around, you can instead define Foo as follows while achieving the same result:

module Foo
  extend ActiveSupport::Concern

  module ClassMethods
    def foo
      'classy'
    end
  end

  def foo
    'instancy'
  end
end

The documentation explains the more convenient feature of Concern, which is module dependency. Using Concern, module dependencies are correctly loaded without the need for you to be concerned.

DelegateClass

In one of the projects I worked on, we were exporting data from a Rails app. We wanted access to the business logic of the models while not littering the application’s code with export related code. We decided to extend the models using DelegateClass (see Jeff’s blog post on DelegateClass as a starting point). And DelegateClass rocked our world, too.

A couple of things to note:

  • It turns out, that these days there is no need to manually ensure that id gets delegated. It works out of the box.
  • Class methods need manual delegation.

Here is a basic delegation example:

require 'delegate'

class Foo
  def to_s
    "foo"
  end
end

module Export
  class Foo < DelegateClass(Foo)
    def bar
      "#{self} bar"
    end
  end
end

foo = Foo.new

foo.to_s # => "foo"

Export::Foo.new(foo).to_s # => "foo"
Export::Foo.new(foo).bar # => "foo bar"

When delegating ActiveRecord models with associations between them, the following pattern can be helpful to make sure you get the delegated classes when traversing relationships:

class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post
end

module Export
  class Post < DelegateClass(Post)
    alias_method :original_comments, :comments
    def comments
      original_comments.map { |comment| Export::Comment.new(comment) }
    end

    #some methods for exporting
  end
end

module Export
  class Comment < DelegateClass(Comment)
    alias_method :original_post, :post
    def post
      Export::Post.new(original_post)
    end

    #some more methods for exporting
  end
end

original_post = Post.new(comments: [Comment.new])
original_post.comments.first.class # => Comment(...)
post = Export::Post.new(original_post)
post.comments.first.class # => Export::Comment

#Be aware!
original_post == post # => true
original_post.class == post.class # => false
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Stephan Hagemann

Stephan Hagemann
Boulder

Subscribe to Stephan's Feed

Author Topics

conferences (1)
boulder (1)
jobs (1)
engines (2)
rails (2)
refactoring (1)
rspec (4)
testing (4)
ruby (3)
cancan (1)
rubymine (2)
rake (1)
basics (1)
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >