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

Monthly Archives: May 2012

Tyler Schultz

Standup 05/22/2012: [SF] CarrierWave is messy

Tyler Schultz
Tuesday, May 22, 2012

Ask for Help

“CarrierWave is messy leaving files in the tmp directory when running tests. Is rm -rf the best answer?”

Yes!

“While the we love Rails, we don’t need it, we just want its asset packaging features. Some suggest using sprockets. Do you have other suggestions?”

  • jammit
  • grunt

Interesting Things

*Gem Maintainers: use LicenseFinder to save users of your gem the hassle of digging through your gem to figure out what license your gem is distributed under.

*A Pivot had great success using Join.me for remote pairing. Setup was a snap! Others suggest checking out TeamViewer as well.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Kris Hicks

git add -e

Kris Hicks
Monday, May 21, 2012

git add -e is like git add -p, except instead of adding things at the hunk level, you edit the entire patch at once. Or, in other words, whereas git add -p will show you each hunk for every file and ask what you want to do for each of them, git add -e will show you the entire patch and allow you to edit it at will. I used this trick to recently split apart one massive commit into 28 smaller, digestible ones.

Say you’ve replaced a line containing “baz” with one containing “bar”. When you git add -e, you’ll be presented with a diff like so:

foo
- baz
+ bar

From here you can decide, actually, you don’t want to delete baz, you just want to add bar. And you want to add it above baz.

From this spot you can just change the minus to a space, making that line context for the diff. Then you can move the line that adds bar above baz, with this result:

foo
+ bar
baz

After saving and closing the editor you’ll be able to look at the result of your work in the index with git diff --cached:

foo
+ bar
baz

And the line you made into context remains in your working directory, which you can see with git diff:

foo
bar
-baz

But what if you end up modifying the diff in a way that makes it a patch that doesn’t apply? Git’s got you covered there.

Let’s say that when you moved bar above baz, after removing the minus from baz, you added an extra line on accident, making the patch invalid:

foo

+ bar
baz

When you save and close the editor Git will tell you of the problem:

error: patch failed: <some_filename>:1
error: file.txt: patch does not apply
fatal: Could not apply '.git/ADD_EDIT.patch'

In which case you’ll be able to attempt the add -e again, as Git will not have made any changes to the working directory or index at this point.

In some cases Git will attempt to apply the patch and give you the option of retrying the add, re-opening the editor with the modified .git/ADD_EDIT.patch if you choose to retry. If you don’t choose to retry, Git will delete .git/ADD_EDIT.patch.

In addition to editing the patch wholesale via git add -e, you can also choose during git add -p to edit a particular hunk manually by choosing ‘e’ to edit it instead of simply adding it via ‘a’. You can also add a file glob to the end of add -e as you would any other command to limit the size of the patch you’re about to edit.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Roberto Ostinelli

[Standup][SF] 5/21 – No Money! ($0)

Roberto Ostinelli
Monday, May 21, 2012

Helps

chirp chirp

Interestings

  • $0: In Chrome, this command dumps the most recently selected node into the console.

  • RSpec2: If you are used to defining your specs with subject{} and its{} blocks, beware of unexpected results, since the subject changes to whatever is returned by the its blocks.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Mark Rushakoff

RSpec: Asserting arrays’ content without regard to order

Mark Rushakoff
Monday, May 21, 2012

Sometimes I want to make assertions about the content of an array when the order of its content is not guaranteed:

nums = [1,2,3].shuffle
nums.length.should == 3
nums.should include 1
nums.should include 2
nums.should include 3

(Of course this is a contrived example, and we could just write nums.sort.should == [1,2,3]. But sometimes we are working with objects that aren’t already sortable.)

I recently found out that RSpec has an array matcher that is specifically intended for this use case, via the =~ operator:

[1,2,3].shuffle.should =~ [1,2,3]
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Justin Richard

5/18/12 Standup – Performance without downtime please

Justin Richard
Friday, May 18, 2012

Help

Q: A team is looking for options to test their app’s response times under load. What’s the recommended tool?

A: Browser Mob was recommended as a hosted option. They have scripted browsers that make requests against your site.

Tsung is an Erlang project that can send a bunch of traffic to your site.

Q: Is it possible to deploy without downtime to Heroku?

A: The closest option is to have two apps that share a single database and coordinate your deploys and A/B which one serves the app publicly. This is clunky. Perhaps Heroku is working on a supported solution for rolling restarts of dynos.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Max Brunsfeld

[Standup][SF] 5/17 – we approve of the juggernaut

Max Brunsfeld
Thursday, May 17, 2012

Ask for Help

“Is Juggernaut still the best library to use for websockets, long-polling etc?”

The last commit on master was about 2 months ago. One pivotal project is using it, and they approve of it. If you’re on Heroku, you might try their pusher service.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Max Brunsfeld

[Standup][SF] 5/16: Travis CI – Distributed sticker distribution

Max Brunsfeld
Wednesday, May 16, 2012

Ask for Help

  • “Anybody know of good short-to-medium-term housing in SF?
    Try airbnb, ‘vacation rentals by owner’, or homeaway.

Interesting Things

  • If you’re setting up a postgres database using ActiveRecord, and you see an error that looks like this:

    new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)

then the problem may be that your template1 database (the default database that postgres copies from when you CREATE DATABASE) is configured to use ASCII, rather than UTF8. Try adding this option to the relevant section of your database.yml:

template: template0

More information about Template Databases in postgres

  • If you donate to Travis CI, then you will receive free stickers.
  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Introduction to Dart

Wednesday, May 16, 2012

Dart is more than a new structured web programming language. Google’s Dart Developer Advocate, Seth Ladd, talks about the philosophy and motivation for this new open source developer platform. There’s an overview of the language, libraries, and tools that help developers from all platforms build apps for the modern web.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Kris Hicks

git reset -p

Kris Hicks
Wednesday, May 16, 2012

I’ve been using git reset -p a lot recently and I think it makes sense to clarify what it is that it does because when I first started using it I found it a little confusing.

I sometimes realize that an earlier commit contains some change that I don’t want, so I want to remove it from the commit. This also works when not rebasing, so for simplicity I’ll use an example where the commit to be modified is already HEAD. Previously I would have done:

git reset HEAD~1
git add -p
git commit -C <treeish>
git checkout .

Or, in English:

  • take off the HEAD commit, adding it to the working directory
  • add back the parts you want to keep
  • make a new commit using the message from what used to be the HEAD commit
  • throw away the changes you didn’t want

With git reset -p this process is a little different. Here’s what it looks like:

git reset -p HEAD~1
git commit --amend -C HEAD
git checkout .

Again, in English:

  • apply to the index the negations of certain parts of the HEAD commit
  • amend the HEAD commit with the negations
  • throw away the changes you don’t want

How does this work?

In the second example you added -p to the reset command. This will reset only parts of the original commit, leaving it intact otherwise. That’s worth stating a different way: When you reset -p, the original commit remains unchanged. The only changes are made to your working directory and index.

The trick is to know what you’re doing when you’re saying “y” to a hunk git presents to you for resetting. Say you added a line to the commit originally:

foo
+ bar
baz

But you want to get rid of it. When you git reset -p, git will ask you:

foo
- bar
baz
Apply this hunk to index [y,n,q,a,d,/,e,?]?

If you say ‘y’, Git will apply that hunk to the index. What you also get, however, is the original hunk (that added “bar”) in your working directory.

To summarize, your working directory will have:

foo
+ bar
baz

While the index has:

foo
- bar
baz

While the commit (unchanged, remember) has:

foo
+ bar
baz

You now have a chance to tell git what you want to do, without having done anything to the original commit yet. In the example above, you wanted to get rid of the addition of the “bar” line. To do that, you want to take what’s in the index (the negation of the addition of “bar”) and apply it to the commit, making it go away:

git commit --amend -C HEAD

Then you still have in your working directory the adding of “bar”, which in this case you just want to get rid of, so:

git checkout .

I like using reset -p because it makes it really easy to make small changes to a commit, removing something I added or putting back something I deleted.

reset -p allows you to more easily get a grip on the changes you’ve made and the ones you’re about to make. It also makes much better use of Git, in that you can do even more interesting operations when in the resulting state, which I won’t go into now as to avoid information overload.

And there you have it.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jonathan Berger

FOWD day 3: Failing And Doing It Well – Mark Boulton

Jonathan Berger
Wednesday, May 16, 2012

Design luminary Mark Boulton takes a well-deserved break from talking about grids and talks about failure instead.

Failing And Doing It Well – Mark Boulton

What’s the last time you really screwed up?

  • What did you do? Did you hurt someone? What happened as a consequence?
  • At some point in life, we stop being encouraged and applauded for screwing up.
  • At some later point, we start be chastised, blamed, made to feel bad.
    fail

  • On the internet #FAIL became the worst possible word. Why?

Mark’s first time snowboarding

  • 1st time in the ski lift: didn’t know there was a safety bar. Rode up screaming.
  • Fell on his ass a lot. In the same spot. For a week.
  • Learning to snowboard is an exercise in pain management
  • Nobody says “#FAIL!”; he was encouraged. For the first time since he was a baby.

Perfection

  • When did Perfectionism become a good thing?
  • It’s a psychological disorder; it’s a problem.
  • Apple product advertising is particularly guilty.
  • Staying at a 5 star hotel wrecks your expectations. Nothing should go wrong, right?
  • The cracks are much more apparent when there’s an expectation of luxury and perfection.

Course-Correct

  • At 16, Mark wanted to be a forensic scientist. Spent 2 years doing biology, chemistry, physics.
  • Didn’t do so well; took exams and it was a failure.
  • What do you do then? Course-correct.
  • > Everyone has a plan until they get punched in the face. – Mike Tyson

Drupal

  • Hired to redesign drupal.org in 2008 and then to redesign the UX for Drupal 7.
  • User testing indicated people didn’t know how to create content in Drupal 6. Big problem for a CMS.
  • Fidelity curve: quick/cheap/truthful <=============> photoshop comps / expensive
  • Mark spends most of his time on the quick/cheap end
  • Responsive design requires a lot more work; are you going to do high fidelity mocks for 8 breakpoints?
  • Low-res sketches are better most of the time.
  • People are willing to be more honest with low-res; they’re willing to criticize.
  • Early on: map a design framework to the work.
  • Drupal’s main problem is that it’s by developers, for developers. They’re very few champions for the content creators in the community.
  • Created a “Roles / Website / Result” 3-up book, trying to understand “what are they trying to do?”
  • At first it was very complicated, but they got it down to a bunch of design principles and 2 personas.
  • Paper prototypes are like cave paintings: they’re artifacts of a painting; they’re not the thing itself.
  • 12 weeks of paper prototyping.
  • What’s the failure? Mark & co. didn’t understand how things get done in the Drupal community. The Drupal Issue Queue breaks your design into 1,000,000 different pieces, and then they’re managed by lots of different people with lots of questions.

CERN

  • The internet was invented here!
  • Lots of accelerators, colliders, etc.
  • Home of the worst typography in the world: Cern Control Center
    cern sign

  • What if there’s a fire? Lots of strange signage around.

  • They’ve got a gizmo that’s blown up every time it’s been turned on, except for once (on a full moon.)
  • Every time it blows up, they say “Hmmm. That’s interesting!”
  • They make clouds! They have the cleanest room and water in the world to make clouds with.
  • Cern does really cool stuff, but no one knows about it.
  • NASA has a really easy job (from a publicity POV). They have pictures of Earth from space(!). CERN has plumbing.
  • Mark is trying to create a sense of wonder around CERN.
  • There’re some cool data visualizations around this stuff:
    cern
  • Mark is trying to bring some of this to the website in real time.
  • Talking to people has been difficult; some of these braniacs are nice, but others are really scary.
  • Mark introduced a branding bar across the 1000s of CERN mini-sites.
  • Some teams hijacked the bar and put navigation in it. Mark said “don’t”, but they did anyway.
  • Sometimes you just have to be adaptable.

It’s not working.

  • Foundation year of art school: spent the summer working on an oil reproduction. At the end, was told to tear it up.
  • Everything you’ve learned is shit. We’re going to make you unlearn it. We’re going to teach you to look and to think.
  • It’s less about the tools, and more about how you deal with things.
  • This was all about the critique.
  • We don’t do a lot of critique in web design. There’s a lot of talk about “don’t be mean”.

Rules of crit

  • Listen. Don’t interject and be defensive.
  • It’s about the work. It’s not personal.
  • Conversation. I expect you to talk back, not just say “uuuh…ok”
  • Public. 1-on-1 is very different than public.
  • In the crit. What’s said in the crit, stays in the crit. Don’t take it home. Don’t carry it around with you.

    • It’s within the crit that we can fail. That’s iteration. Mark wrote more about it on his blog and will try to extend the conversation to twitter using the hashtag #crit

Thinkering

  • His uncle used to restore steam engines.
  • It’s important to do something w your hands
  • Thinkering: the time spent thinking whilst doing something with your hands
  • When riding a bike, you’re focused on a single task but your mind is free to wander.

  • OMA (Koolhaas) builds models out of foam blue bricks instead of cardboard (like most architecture studios).

  • cardboard takes 24 cuts to make a cube; foam takes 6. More time thinking and making, less time involved with the tools.

Love

  • We craft websites. There’s care that goes into it.
  • Craft requires time.
  • Deadlines run counter to that.
  • Theres’ no timescales on love; you just do.
  • Crafting isn’t the end product, its the journey.

In work

  • Speak. A lot. Daily standups, crits. Talk to clients too.
  • Be a project manager. It’s your responsibility not to shirk management to someone else. Managing time, workflow, deliverables.
  • agile, not Agile. MB thinks they’re broken for design. It’s very hard not to turn into a reactive designer. small-a-agile means small, nimble, able to course-correct, working at the appropriate level of fidelity all the time. “3 rounds of iteration” is nonsense created by the ad agencies in the 1950s.
  • Critique.
  • Work with clients, not for clients. Don’t work with people who don’t get what we do. If you think the people you’re working with are idiots, walk away.
  • Value, not time. The problem with charging by time is that you become a commodity. MB charges by value—the day rate changes.
  • Don’t hide. If you don’t have work done on time, tell them and apologize. It’s ok.
  • No ambition. “Don’t have ambition, be a dreamer.” Dreamers are happy with their lot. Ambitions have plans, and if you don’t get it, you fail.
  • Make small mistakes.
  • We’re all here to get better. We should fail to get there.
  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Topics

  • agile (778)
  • rails (113)
  • testing (87)
  • ruby (83)
  • ruby on rails (70)
  • jobs (62)
  • javascript (54)
  • techtalk (44)
  • rspec (38)
  • activerecord (29)
  • productivity (29)
  • gogaruco (29)
  • ironblogger (29)
  • git (28)
  • nyc (27)
  • rubymine (25)
  • bloggerdome (22)
  • mobile (22)
  • cucumber (20)
  • process (19)
  • pivotal tracker (19)
  • jasmine (19)
  • design (18)
  • ios (18)
  • webos (17)
  • objective-c (17)
  • android (16)
  • palm (16)
  • "soft" ware (16)
  • fun (15)
  • tracker ecosystem (15)
  • ci (15)
  • cedar (15)
  • rails3 (14)
  • performance (14)
  • bdd (14)
  • gem (13)
  • tdd (13)
  • selenium (12)
  • css (12)
  • goruco (12)
  • bundler (12)
  • meetup (11)
  • railsconf (11)
  • nyc-standup (11)
  • capybara (10)
  • mac (10)
  • mojo (10)
  • chef (10)
  • api (10)
Subscribe to Community Feed
  1. ←
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. →
  • 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 >