But what you probably want is some stats. We like numbers, right?

Across all of our offices, the people who grew mustaches and shaved their heads into Mohawks raised just over $20,000.

Together with some of our friends and clients, notably Square, AirBnB, Social Chorus and Snapfish, the Webstache network (really just a team of teams) raised over $43,000. This was enough to be ranked as the 57th best multinational network. We’re a multinational network because the gang at Appex (in Norway) joined in. But that amount was good enough for 22nd place on the US leaderboard.

Lastly, the EMC network – all of the Pivotal Labs teams, Greenplum, and a bunch of EMC proper teams – raised over $63,000. That’s #12 in the US overall and the 3rd highest corporate network.

Your chatter, upper lips and yes, dollars, helped raise awareness around Men’s health issues. So big, BIG, thanks from all of us. And we’ll see you in Movember 2013!

The post An Entirely Late Movember Wrap-Up appeared first on Pivotal Labs.

Movember 1st, a bunch of us in the SF office started clean-shaven. We’ve talked about prostate cancer. And we’ve grown some Mo’. We’ve talked about testicular cancer. And we’ve grown some Mo’. We’ve raised some money…actually, we’ve raised a LOT of money.

The Webstache network has raised over $12,000 so far – and that’s before we’ve all been the laughing stock of our various Thanksgiving tables tomorrow. Thanks to all the friends at AirBnB, Square, and Snapfish who’ve helped and itched our way to such a good mark.

But there’s so much more to do. More people to inform, more whiskers to grow, more money to raise, and maybe a few heads to shave.

Stay tuned.

The post Mid-ish Movember appeared first on Pivotal Labs.

You start by singing up at Movember’s site. The fundraising platform is easy to use to gather donations and to promote your upper lip’s “progress” over the month.

Once you’re in, it’s time to promote. Take a picture of yourself and give a motivation. Download the iOS or Android apps for your phone and take pictures of your mo each day.

Spreading awareness is marketing – so work it! Let the world know how the mo’ effort is going. Use the Facebook and Twitter links to start the campaign in your feeds. Or send out emails – Movember gives you a custom URL for your page. Point all your friends, family and coworkers to your Mo Home Page so they can find out more and donate easily.

(Make sure they know that donations are tax deductible and that they’ll get a handy tax receipt.)

Remember that each time you’re asked about the dusting of fur on your face that you’re raising money for prostate and testicular cancer research and awareness. Expect to have lots of conversations like this over the month:

Person: Nice mustache!
You: Thanks! I’m growing it for the entire month of Movember. Care to donate to support testicular and prostate cancer?

Some Guy: What is that thing on your face?
You: It’s my mustache and it’s here to remind you to get your prostate checked. Did you know that 1 in 6 men will be diagnosed with prostate cancer in their life?

Best Friend Ever: Hey! Even better looking than last Movember! Where do I donate again?
You: You’re the best friend ever.

Get ready to shave on Thursday. And then don’t stop talking all month long.

The post Getting Involved with Movember appeared first on Pivotal Labs.

What started as a bit of a joke has become a worldwide effort to teach everyone about “dude cancer.” Guys grow, friends and family donate, and we all talk a bit about men’s health issues, specifically prostate and testicular cancer.

So how, exactly, does this work?

Once you’re in, you…

1. Wake up on Movember 1st and shave clean
2. Don’t shave the mustache, don’t grow a beard, and don’t connect to the ‘burns
3. Tell everyone who asks that you’re doing this for the dudes

Last year the 1.9M “Mo Bros and Mo Sistas” around the world collected over $126M (USD). Pivotal along with a group of clients and friends, raised over $40,000 of that.

Things are just getting ramped up and already the leaderboard has crossed $3.5M.

So it’s time for all of us to get growing!

The post Movember is here! Movember is here! appeared first on Pivotal Labs.

This release is relatively minor, but has a lot of things under the hood that will make it easier for us to continue to improve the project. Some highlights:

Jasmine Core Fixes & Features

• New HTML Runner/Reporter (designed by Sean Durham) is now the default
• An improved toEqual matcher for deep Objects

Jasmine Gem Fixes & Features

• Detection and support for the Rails Asset Pipeline
• All requests served with no-cache headers, helping out when your browser supports them correctly

Development fixes

• Catch-up on issues with recent Rubygems and Ruby 1.9.3
• Fixed bugs when developing for Jasmine on Linux
• Moved CI to Travis
• Cleaned up the building/concat of jasmine.js
• Overall better task code, now tested, for building & testing Jasmine

In addition, we’ve revamped the Jasmine home page to give you a better online reference for using Jasmine every day in your projects. It should cover all of the public interface for writing tests. If we’ve missed something, let us know. It uses Rocco with a custom layout and includes Jasmine on the page, giving you not only a reference, but a test run to see if the reference runs green (Big thanks to Michael Jackson of Twitter who made the suggestion of ‘running documentation’).

The post Jasmine 1.2 released appeared first on Pivotal Labs.

How hard could it be to put Sprockets 2 and the Asset Pipeline into a Rails 2 app?

1. Add Sprockets 2

In the Gemfile:

gem sprockets, "~> 2.0"

2. Working with SASS

If you need/want the Sass gem for SASS or SCSS stylesheets, then this goes in the Gemfile:

gem 'sass'
group :development, :test do
  gem 'sprockets-sass'
end

Rails 2 doesn’t include Sass by default. So you need to add it. Yes you might already have Sass if you’re using HAML for your view templates, but since they’re about to be broken apart, add it now.

The sprockets-sass gem adds support of watching individual .sass files in development and recompiling the parent stylesheet asset as needed. It’s not going to be used in production, but more on that later.

For your SASS files you’ll want to use @import to declare SASS dependencies instead of Sprockets’s require.

3. Rack it up in config.ru

Sprockets runs as Rack middleware, but since it’s difficult to map a path in Rails’ environment.rb 2 and make a rackup file. Name it config.ru so that the rest of Rails’s scripts (e.g., script/server) work with it transparently. For example:

What’s going on in this rackup file -

• Sprockets with the same paths as Rails 3.1′s defaults – add more as necessary for your app
• Guard against mapping /assets in production.
• Guard against multiple loads if Rails is already initialized (a fix for testing)
• Use Sprockets::Helpers to get asset_path and asset_url helpers (and others, see sprockets-helpers) for your stylesheets and views
• Map / to the rest of Rails, guarding the middleware you don’t need in test

4. More Templates

Using EJS or Mustache? Then drop in the additional gems that work with Sprockets 2′s templating via Tilt:

gem 'ejs'
gem 'sprockets_spacely'

5. Move Your Assets

Now that configuration is done, move your assets under app/assets, just like the Rails Guide suggests. Don’t forget to change the url calls in your stylesheets to asset_url. Run the app, checking your JS console for 404s until all the includes and paths are correct.

6. Capybara

Capybara now needs to forget that it’s running Rails and instead just a Rack app. This technique (WARNING: eval ahead.), meant for using Cucumber/Capybara in a Sinatra app, works.

7. Compile your assets on deploy

All of this work so far makes your assets available from your /app directory in development and test. In production, they will get served from /public/assets. Rails 3.1 provides the assets:precompile to be used as part of the deploy process Generate an empty Rails 3.1 app and copy it into lib/tasks. Copy the Sprockets configuration from your config.ru into this task. Or yes, come up with a way to DRY this configuration up. Then you need to make sure it’s run at the right time during your deploy.

8. What’s left?

This was all we needed and it’s working well for this app. There are a few things that this guide doesn’t cover.

Assets from gems or /vendor are not loaded. Feel free to add explicit paths to Sprockets as needed. The Sprockets Helpers gem doesn’t yet support a Proc for an asset host, but there’s now an open issue on Github. This project didn’t need the former and we threw something together based on Sasset, which appears to be abandoned, and use it only on the asset compile step. We’re not using CoffeeScript on this project. These we’ll leave as exercises for the reader.

The Asset Pipeline is still a bit new and we’re all getting used to it. It’s not just Sprockets, SASS, etc. – there is a lot of functionality that Rails puts on top of Sprockets, but it’s easy enough to add the equivalents.

That wasn’t so bad, was it?

The post Giving Rails 2 the Asset Pipeline appeared first on Pivotal Labs.

In 30 days, we met our goal of raising $20,000 for Livestrong and The Prostate Cancer Foundation and then some – the current tally is $23,318.

But that’s not enough. We had Pivots who couldn’t grow mustaches. And Pivots who had mustaches who didn’t want to shave them. What are these Pivots to do?

Someone said, “But a Mohawk is like a mustache…FOR YOUR HEAD.” Then there was much betting and cajoling and smack talk. In the end, Pivotal agreed to donate $500 to Movember for each Pivot that got a mohawk.

Which meant we needed to have Mohawk shaving parties in New York and San Francisco. Pivots in the Boulder and Denver offices, as well as a couple of remote Pivots did the same.

Total: 28 ‘hawks shaved (plus Gregg, the one with the green & purple one-day ‘do merited a half-donation) and another big donation coming to Movember from their friends at Pivotal Labs. We may break $40K before the donations close.

Big thanks to my fellow Pivots for growing, donating, raising, and yes, shaving. And HUGE thanks to Pivotal Labs for tolerating all of this and making the big donation this year.

The post Movember Update: Check Out the ‘Hawks While the Pivots Involve It appeared first on Pivotal Labs.

November Second will be a little different. I’ll wake up, I’ll shower, and I’ll shave, and I’ll take the train to work and code. But that shave will be a little shorter, skipping my upper lip. I’ll continue ignoring one part of my face through the end of the month.

Why? Because it’s Movember. And guys still get prostate and testicular cancer.

Last year during Movember, Pivotal Labs helped raise $10,000 of the $7.5M raised in the US for the Prostate Cancer Foundation and LIVESTRONG to help research and awareness of “dude cancer”.

This year we want to double that amount. But we need your help.

We started a network at Movember called Webstache – a place where anyone in the web development community can start a team, or join a team, or just donate. Our friends at Square have joined the Pivotal teams from San Francisco, Boulder and New York. How about your company?

The mustache I’ll be growing is sad. But not as sad as the fact that 1 in 6 men will be diagnosed with prostate cancer.

The post Remember, Remember, It’s Time for Movember appeared first on Pivotal Labs.

So install Chrome, make sure your Gemfile has Capybara set to >= 1.0, bundle install and let’s get configuring.

Update your SpecHelper

You have to tell Capybara that you want to use Selenium/Webdriver and Chrome. Put this in your spec_helper.rb file

Capybara.register_driver :selenium_chrome do |app|
  Capybara::Selenium::Driver.new(app, :browser => :chrome)
end

Chrome & chromedriver

While there’s been limited Selenium support in Chrome for a while, with release 12 there is an entirely new and complete automation interface to Chrome. To use it you need a platform-specifc chromedriver binary in order to connect Webdriver and Chrome. Download it, make sure it’s executable, and put it on your path.

Chrome likes to update, so stay on the general release (if you can) to reduce update frequency. You can even take steps to prevent Chrome from updating, but I’ll leave that as an exercise for the reader.

BOOM

That should be enough to get your Capybara specs to start using Chrome. You’ll want to play with your setup and maybe only run some specs with this driver.

Caveats

Webdriver does not appear to support Safari. This may matter to you if you’re using this setup to approximate Mobile Safari. But for the types of tests you’re likely writing for Selenium it should be good enough. After all, every mobile Webkit build is slightly different.

While complete (in terms of browser features) and far faster than previous Selenium-Chrome pairings, it’s still slow-ish – for example, typing isn’t nearly as fast as Firefox. So you might not want to make this your default stack for your entire Rails app.

You might make it your only stack if you’re testing a Webkit & JavaScript only framework, say an HP webOS application using Enyo.

But that’s another post.

The post Capybara, Selenium, Webkit and your Mobile Site appeared first on Pivotal Labs.

People ask how to do this in JavaScript on the Jasmine mailing list every so often.

So here’s an example of “Shared Example Groups” in Jasmine.

This Game spec looks totally fine for a basic ball game. But what if I want to have multiple different types of ball games?

Here are specs for Basketball and (American) Football:

The specs related to the Game itself are inline. That doesn’t feel very DRY and really, we want to test the interface with the same code. We’re working in JavaScript. So we write a function.

Jasmine works by building up all the functions to execute at spec run time. When you call describe, the passed-in function is executed immediately. Inside the describe, the calls to beforeEach, afterEach and it queue up the passed-in functions for execution later, when you want to run your specs.

This means you can put all of your shared specs, including any beforeEach calls, in a function that can be executed as needed. Like this:

Each time sharedBehaviorForGameOf is called, the three before and two spec functions are queued up. Call it twice and you’ll wind up with four new specs in your Jasmine environment.

And since it’s a function, yes, you can pass parameters. The context parameter can be used to pass in a ball and a game for use in the shared specs. Since the “(shared)” describe function is called each time sharedBehaviorForGameOf is called, there will be a separate closure for the local ball and game.

So now we can refactor our specs to use our function.

This is a useful technique, but use it appropriately and with a little caution. Use it in situations for consistent testing, not just to DRY up your specs for DRY-ness’s sake.

Keep the varied behavior (like the field goal scoring above) outside your shared behavior function instead of using the parameters. The parameters should be for the object(s) under test, not their behavior.

And lastly, (as always) keep your mind on your JavaScript closures.

The post DRYing up Jasmine Specs with Shared Behavior appeared first on Pivotal Labs.