<style>
  .conditional_form_part {
    display: none;
  }

  .conditional_form_part_activator:checked + .conditional_form_part {
    display: block;
  }
</style>

<form>
    Mailing address differs from home address
    <input class="conditional_form_part_activator" type="checkbox">

    <div class="conditional_form_part">
        some other content
    </div>
</form>

Here is a jsfiddle of the result:

As you can see from the CSS section, the trick is the combination of the :checked pseudo selector with the + selector. When elements like radio and checkbox are checked, the :checked selector applies. The + selector applies when an element immediately follows another element. In combination we can target the immediate sibling of a checked checkbox and use that for styling.

There are a couple of other CSS selectors that allow you to extend this example, e.g., the tilde operator, which selects any following element. Better brush up on your CSS selectors.

YMWBL – Your Mileage Will Be Limited

Note, that you would not be able to make this example work, if the checkbox were wrapped in a label (or any other element). There is no selector with which you could target the conditional form part in that case.

As far as structural queries go, CSS is limited in expressive power to only allow selection deeper into the document tree (i.e., with the > (child) selector) or downward within the current level (with + or ~), but never upwards within the tree.

The post Showing and hiding conditional HTML without Javascript appeared first on Pivotal Labs.

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.

The post My must-see list from MWRC 2013 appeared first on Pivotal Labs.

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!

The post GoSpotCheck Is Looking For A Web Application Developer appeared first on Pivotal Labs.

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.

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

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

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

The post Migrating from a single Rails app to a suite of Rails engines appeared first on Pivotal Labs.

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?

The post Never use shared examples groups! Usually. appeared first on Pivotal Labs.

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

The post Specific interfaces – in the small appeared first on Pivotal Labs.

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

The post Boulder Standup – Feb 16, 2012 appeared first on Pivotal Labs.

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!

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.

The post IntelliJ Modules in Rubymine appeared first on Pivotal Labs.

• 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

The post Test your Rake tasks! appeared first on Pivotal Labs.

• 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.

The post Standup 11/11/2011: Some funkinesses appeared first on Pivotal Labs.