factory :project

Before long you’re adding relations to projects, and the first thing people do is this:

factory :project do
  association :user
end

This immediately means that every single time you instantiate a project, you’re getting a user as well. In most cases this is more than you want, and if you continue to follow down this path you end up with a huge slow test suite. I prefer a slightly different strategy: start small and compose.

factory :project do
  ...
end

trait :with_manager do
  association :user, factory: :manager
end

This defines a very simple factory :project which gives you only a project and allows you to build a project with an associated user like so:

FactoryGirl.create(:project, :with_manager)

The result is a couple more arguments when you use the factory, but the overall code is more intention revealing.

If this is too much, you could always create a more descriptive factory:

factory :managed_project, parent: :project, traits: [:with_manager]

If you stick with this strategy, you’ll find that tests are more concise, factories are more useful and your test suite run time won’t grow as fast.

The post Start small and compose: A strategy for using FactoryGirl appeared first on Pivotal Labs.

Object Oriented Programming (OOP) as an idea has been oversold. The most commonly used languages in use today are designed around the idea of OOP. Extremist languages like Java force you to think of everything in terms of objects. But is Object Orientation (OO) a good idea? Does it have problems? Is it the right tool for everything? Let’s explore some of these questions in a slightly tongue in cheek and cathartic rant.

Imperative vs Declarative

The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. — Paul Graham

Procedural programming languages are designed around the idea of enumerating the steps required to complete a task. OOP languages are the same in that they are imperative – they are still essentially about giving the computer a sequence of commands to execute. What OOP introduces are abstractions that attempt to improve code sharing and security. In many ways it is still essentially procedural code.

Declarative languages on the other hand are about describing computation. While a a declarative language necessarily maps down to imperative code, the resulting code often reveals less incidental complexity and can sometimes be much more easily parallelized.

State

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. — Joe Armstrong

State is not your friend, state is your enemy. Changes to state make programs harder to reason about, harder to test and harder to debug. Stateful programs are harder to parallelize, and this is important in a world moving towards more units, more cores and more work. OOP languages encourage mutability, non determinism and complexity.

As someone who was initially hostile to the idea that state is the root of all problems, I initially greeted this idea with skepticism. Mutating state is so easy and fundamental in OOP that you often overlook how often it happens. If you’re invoking a method on an object that’s not a getter, you’re probably mutating state.

Nouns and Verbs

Java is the most distressing thing to happen to computing since MS-DOS. — Alan Kay

The typical college introduction to OOP starts with a gentle introduction to objects as metaphors for real world concepts. Very few real world OOP programs even consist entirely of nouns, they’re filled with verbs masquerading as nouns: strategies, factories and commands. Software as a mechanism for directing a computer to do work is primarily concerned with verbs.

OOP programs that exhibit low coupling, cohesion and good reusability sometimes feel like nebulous constellations, with hundreds of tiny objects all interacting with each other. Sacrificing readability for changeability. Many of  OOP best practices are in fact encouraged by functional programming languages.

Inheritance vs composition

Object-oriented programming is an exceptionally bad idea which could only have originated in California — Edsger W. Dijkstra

Inheritance is one of the primary mechanisms for sharing code in an an OO language. But this idea is so problematic that even the keenest advocates of OO discourage this pattern. Inheritance forces you to define the taxonomy and structure of your application in advance, with all it’s connections and intricacies. This structure is resistant to change which is one of the primary problems software developers face every day. It also fails to model some pretty fundamental concepts.

Further reading

This is far from an exhaustive list of the criticisms leveled at OOP. While I believe the problems with OOP are extensive, I do think it is a valuable mechanism for developing software. But is certainly not the only one. The biggest problem in my mind is thus:

When people overcome the significant hurdle of fully appreciating OOP, they tend to apply it to every problem. OOP becomes the solution, and every problem looks like a nail.

There’s got to be a better way…

The post All evidence points to OOP being bullshit appeared first on Pivotal Labs.

Tenderlove explains YAML exploits

Tenderlove explains YAML exploits in great detail, and with his usual panache

http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html

The post [NY] Thursday Standup appeared first on Pivotal Labs.

So I wrote a quick script to remove all remote branches that have been merged into develop (our working branch, you’ll have to alter the first instance of ‘develop’ to master if you use a more typical git branching model).

Here goes:

git branch -r --merged develop | sed 's/ *origin///' | grep -v 'master$' | grep -v HEAD | xargs -n 1 printf "echo git push origin :%sn" | bash

The post Cleaning old branches appeared first on Pivotal Labs.

• PhoneGap 2.0 released – supposed to be easier for devs?
• Mountain Lion’s out today
• Chrome 21 supports drag & dropping of FOLDERS onto a web page

The post NYC Standup 7/25/2012 – Phone Gap appeared first on Pivotal Labs.

• automated deploys with jenkins

TL;DR:

exec ssh-agent ./path/to/your/build/script

We setup our ci server to deploy (via capistrano) our app to an “acceptance” environment after a successful build. However, the ssh configuration on the environment we deploy to confuses the ruby net-ssh library, rendering the “forward-agent” option in capistrano useless. Therefore, our build script needed to manually add keys to the ssh-agent.

To make an ssh-agent available to your build script in jenkins, wrap the shell command for your build script in “exec ssh-agent”:

exec ssh-agent ./path/to/your/build/script

Your build script will be executed as a subprocess of the agent. When the command finishes, the agent dies with it.

To help DRY up your stylesheets, SCSS allows for inheritance. Take the following example:

.btn-red {
height: 20px;
width: 20px;
border-radius: 5px 5px 5px 5px;
background-color: #FF0000;
}

.btn-white {
height: 20px;
width: 20px;
border-radius: 5px 5px 5px 5px;
background-color: #FFFFFF;
}

Notice the similarities between the three classes; copying & pasting style declarations should tickle the same spidey sense that copying & pasting Ruby code does. Fortunately, SCSS offers @extend, which can be used like so:

.btn {
height: 20px;
width: 20px;
border-radius: 5px 5px 5px 5px;
}

.btn-red {
@extend .btn;
background-color: #FF0000;
}

.btn-white {
@extend .btn;
background-color: #FFFFFF;
}

Events

• Machine learning meetup tonight

The post Standup NY 7-19-2012 appeared first on Pivotal Labs.