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
  • Tools
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker
Can Berk Güder

[Standup][SF] 03/08/13: See-borg

Can Berk Güder
Friday, March 8, 2013

Helps

Mocking XHRs in Capybara

How do you mock AJAX requests in Capybara tests?

Suggestions:

  • Execute Javascript on the page before the test
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Can Berk Güder

03/06/13: It’s Red Day

Can Berk Güder
Wednesday, March 6, 2013

Helps

New column shows up as the wrong type on Heroku

We created a new migration that added a non-string column. After pushing to heroku and running the migration, the column shows up as string.

Suggestions:

  • you should restart your heroku app after every migration.
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Can Berk Güder

03/04/13: Singleton Process

Can Berk Güder
Monday, March 4, 2013

Interestings

github/singleton_process

Ensures that a given process is only running once. Keeps scheduled tasks from overlapping. Uses lock PID files. https://github.com/rjackson/singleton_process

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

Gemnasium offers you Security/Steroids

Kris Kelly
Tuesday, February 26, 2013

Interestings

Security on Steroids

The list of security monitoring services continues to grow. In addition to the holepicker gem and the private beta code climate service, Gemnasium is now offering "Security on Steroids."

http://sendgrid.com/wf/webmail?rp=ZTI1bGQzTnNaWFIwWlhKZmFXUTZNVEl6TkN4MWMyVnlYMmxrT2pJMU5qVTBmUWV5SnVaWGR6YkdWMGRHVnlYMmxrSWpvaU1USXdOamc1TUNJc0ltNWxkM05zWlhSMFpYSmZkWE5sY2w5cFpDSTZNVFV3TVRneE1EZzNOREo5

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

3 Challenges for Agile Design

Jonathan Berger
Monday, February 25, 2013

Software development has been revolutionized by Agile development practices, but designers struggle to adapt to the very same techniques—despite suffering many of the same challenges that led to Agile. What exactly are these problems? And how can Agilists and designers address them?

When is Design Done?

Agile development preaches “Done means Done”. When a story is accepted by the Product Owner, it’s ready to be deployed out into the world. What does “done” mean for design? Automated testing guarantees that on every story, developers will enjoy Acceptance Criteria: a concrete measure of what counts as “done”. Designers, on the other hand, rely on subjective criteria to determine when they’re done. In the best case, this means the product team—or often, the designer working alone—if only they had a partner to pair with! In the worst case this is purely subjective sign-off from the client. While agile developers have access to tools like velocity to plan their work, designers have structural difficulties in estimation, and are consequently less able to plan. Consequently, questions like “when will that feature be done?” are more easily answered by a developer than a designer. That’s not because designers are less responsible than developers. It’s because it’s harder to know when you’re done with design—but that’s of little comfort to anyone who needs to budget time and resources to manage the project. Because Acceptance Criteria—or an answer to the question “what does ‘done’ mean?”—for design is in different units of work than “done” for development, there’s an impedance mismatch in coordinating between the two. Breaking design into units of work with more discrete Acceptance Criteria helps coordinate design work with development work.

What’s Wrong with the Deliverables Business?

Agile Developers ultimately deliver user-facing code, but designers output thinking: solutions to design problems, traditionally expressed via mock-ups or assets. How should the two interact? Should design stay an iteration ahead of development? What does it mean when a developer discovers an interaction problem in a design they’re implementing? Should they stop work? Developers are the tip of the spear when it comes to experience design: in the process of building software, they’re often the first people ever to use it. Sometimes this means they uncover interactions on UX problems that the designers didn’t anticipate. If the necessary design changes cascade into other work, what should the designer do: stop work and refactor (and fall behind), or come back to it later?

Furthermore, it can be difficult to determine how much design is required for developers to complete their work. The best design deliverable is the Simplest Thing That Can Possibly Communicate the Design Solution, and this can vary from team to team and design problem to design problem. Under ideal circumstances, an experienced designer may be able to reasonably estimate how long it will take to 1) solve the design problem, 2) communicate the solution, and 3) iterate on the problem / solution once it’s usable and testable as working software. But. BUT! That’s asking a lot. And it absolutely shreds the question “how far ahead should design stay of development?”.

Why do Designers Feel Unwelcome in Agile?

Let’s take stock: we’ve got gallant developers, accurately estimating stories and delivering working software, and the goofus designers, unable to tell you what they’re doing or when they’ll be done. Knowing “how much design is enough?” is hard. Knowing how much design to start with is hard. Reared in a culture that prizes individuality, that venerates Rock Star Designers, that applauds Working On It Til Its Done, that publicly shreds less-than-perfect work in Crit as a rite of passage, that (with the occasional exception) is alien to the notion of sustainable development—it shouldn’t be surprising that designers are uncomfortable. That starts to lead to discord on the team: designers hating agile; feeling rushed, feeling like they don’t get the benefit of iterative design; feeling that once they touch something, they don’t get to go back and refactor it. Let’s throw in a bit of rah-rah agile ideology, a few jargon-y IPMs and retros, promises that “we’ll come back and refactor that later”, and the creeping suspicion that this whole Agile thing is nothing but smoke, mirrors, and Kool-Ade. Is it any wonder that designers can be hostile to agile?

What can we do? Looking to the example that Agile Development sets, we can see several concepts that may help: Acceptance Criteria-delimited design stories. Meaningful estimation of work for design. A culture that values Sustainable Pace. Translating these ideas from development to design may do more than just help designers work more comfortably in Agile environments—it may help us practice better design.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Callum Stott

Too much magic for Ken

Callum Stott
Friday, February 22, 2013

Helps

Lobot needs YOU

The Lobot project is recruiting team members. Mostly that means that when scheduling permits, you’ll work on Lobot as a project. Contact Ken (the new PM), or Davis.

How do RubyMine inspections work?

I have a module that creates methods dynamically, but I want Command-B to work for those methods.

Interestings

before_save on: :create fails silently

before_save and after_save will happily take an on: :create option, and then completely ignore it. before_validation takes an on: :create option, and actually works, which is why it feels natural to put on: :create after a before or after save.

The right answer, apparently, is to use before_create or after_create.

See also: http://grokbase.com/t/gg/rubyonrails-core/12bda67vx2/rails-core-suggestion-%60before-save-on-create%60-should-either-work-or-raise-an-exception

Resque worker shutting down on Heroku – solved

We recently added the resque-pool gem which does alias_method on the resque worker shutdown? method to look at the pid of the process being shutdown. On Heroku this always evaluates to true.
Takeaway message don’t add resque-pool gem to your gemfile for an heroku application.

hackernewsletter.com

Weekly email of curated links from hacker news. Recommended by Rajan.

Thoughtbot is writing a book

Ruby Science: https://learn.thoughtbot.com/products/13-ruby-science

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Callum Stott

What time is it supposed to be?

Callum Stott
Thursday, February 21, 2013

Helps

Any Good iOS Analytics Tools?

Has anyone tried/prefer any particular iOS analytics tools? We’re looking at Google Analytics, Flurry, and Mixpanel. Per-user drill downs would be nice and all features we need are supported by all three (custom events with extra data and session tracking).

Dying Heroku Resque Worker

We’ve got a resque worker on Heroku that dies instantly without any error. When we created one in a rails console it looked as though it was receiving a shutdown signal.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Callum Stott

Awkward Bluetooth

Callum Stott
Wednesday, February 20, 2013

Helps

Remove unused bluetooth devices from your workstation

Do us all a solid and remove those ghost devices from your bluetooth settings pane. This will make it easier for others to pair them up with a new workstation.

Interestings

GitGutter for Sublime Text

Do you use Sublime Text? Would you like to see a git line change indicator alongside your files?

https://github.com/jisaacks/GitGutter

Bonus: there’s a vim version! https://github.com/tpope/vim-fugitive

Twitter typeahead.js

Twitter have release a js plugin for typeaheads:

http://twitter.github.com/bootstrap/javascript.html#typeahead

Events

Wednesday: Saturday Pair Exchange

Come take part in the the special new extended Pair Exchange event on Saturday from 12:30 – 5:30.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Rasheed Abdul-Aziz

Broken permalinks and narrative, the pitfalls of moving content.

Rasheed Abdul-Aziz
Wednesday, February 20, 2013

Lately I’ve been thinking about the risks associated with:

  • moving content
  • refactoring domain terms within content.

I’ve identified the key areas of risk as narrative and permalinks.

Narrative

The narrative of your site/app can break in subtle and unexpected ways. It is difficult to guard against side-effects upon the narrative. This makes changes to domain terms high-risk. Specifically, a developer focused on the code can easily miss these side effects.

Here’s an obvious, and well guarded story:

Given I am a user
When I visit the user's profile
Then I see their latest activity

That one’s simple, if you move the latest activity to a sub-nav, this story will break (that’s a good thing). In this case, you could ask the product owner, “In the past, having a user’s activity visible on their profile page was desirable. Are you sure you want to lose that?”.

However not all narrative is this cut and dry. Consider this story:

As a user
When I visit a member's profile
I can see a list of pages the member is interested in.

Then, along comes a new unit of work, “Rename all pages to interests”. This seems reasonable, and so you finish the story. The test for the ‘pages’ the member is interested in continues to work, however the member profile ought to lose any reference to ‘pages’. The new domain term ‘interests’ should be used instead.

Now your tests are using misleading or confusing language. You need to update all your stories to use the new term. This can get onerous quickly, but it’s vital for consistency.

I’m yet to find a satisfying technique for mitigating this risk. It’s hard enough keeping the modelling clear of inconsistencies.

This same change to narrative also affects ‘curators’ of ‘pages’. They no longer curate ‘pages’, they now provide ‘interests’. Do we want the curators to go through this mental hurdle, or the strangeness of ‘managing an interest’ versus ‘my interests’? Suddenly a curator has a list of ‘interests which they maintain’ and a list of things they are ‘interested in’.

The best way to mitigate the ‘broken narrative’ risk is to stay strong on short, testable stories. Fast turnaround between development and acceptance is also valuable. The fast feedback cycle is less overwhelming for both developer and product. The chance to think about risks is stronger when the story is as uncomplicated as possible.

The risk of broken narrative is just another reason to avoid this internal desire to take ‘big bites’.

Permalinks

Permalinks and long lasting links, are any URLs for which permanence matters. E.g., the permalink to an article on your blog from some outside source. The risk of broken permalinks can be readily mitigated in your intrgration tests. To achieve this, you need to make sure that product is thinking actively about permalinking. Impart to the product owner that permalinks must be (as much as is possible) explicitly called out in stories.

Permalinks in cucumber tests

Here is an example.

A story in your backlog calls for content that must be available in a permalink. You write a scenario like this:

Given I am a visitor
And there is an article
When I click on a permalink for the article
Then I should see the article

The important term in this story is ‘permalink’ – whenever a step definition calls for a permalink, it needs to use a constructed link:

visit ('/articles/#(article.slug}')

Do not use Rail’s (or your framework of choice) magic:

visit(article_url(article)) # won't capture intent

This way, if the permalink goes away, the test fails, and the intent is clearly captured.

 The many unseen dependencies

To complicate matters, a moderately complex site usually has a swathe of references to the content you are about to move/refactor. The term is often used in abundance, E.g. ‘Post’ or ‘Job’ or ‘Activity’. The page might be accessed from several places, E.g. messages are available from the ‘User -> Messages’ nav item, the ‘”My Favorite Lolcats” group messages’ page etc..

Key take-aways:

  • Fast feedback loops. (small testable and deliverable chunks of work)
  • Oodles (lots) of product owner/ux designer/copywriter/developer collaboration.
  • Changes in domain terms need to be kept consistent throughout your tests.
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Callum Stott

WE’RE #10

Callum Stott
Tuesday, February 19, 2013

Events

Tuesday: Tech Talk: Colin Shield on using Chef Server and Rails

(Davis Frank)

Tuesday: is Extreme: Host Required

(Andrew Bruce)

Host wanted for tonight’s Extreme Tuesday. Acquire within. Talk to Gavin, Andrew, Edgar, or anyone else involved.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Topics

  • agile (783)
  • rails (117)
  • testing (90)
  • ruby (86)
  • ruby on rails (71)
  • jobs (62)
  • javascript (59)
  • techtalk (44)
  • ironblogger (42)
  • rspec (39)
  • bloggerdome (34)
  • productivity (34)
  • activerecord (30)
  • rubymine (30)
  • git (29)
  • gogaruco (29)
  • nyc (27)
  • design (24)
  • mobile (23)
  • pivotal tracker (22)
  • process (21)
  • cucumber (21)
  • jasmine (19)
  • ios (18)
  • tracker ecosystem (17)
  • webos (17)
  • objective-c (17)
  • fun (16)
  • android (16)
  • palm (16)
  • ci (16)
  • "soft" ware (16)
  • bdd (15)
  • tdd (15)
  • cedar (15)
  • rails3 (14)
  • performance (14)
  • css (14)
  • gem (13)
  • mouse-free development (12)
  • selenium (12)
  • goruco (12)
  • bundler (12)
  • api (12)
  • keyboard (11)
  • meetup (11)
  • railsconf (11)
  • nyc-standup (11)
  • capybara (10)
  • mac (10)
Subscribe to agile Feed
  1. ←
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  8. 7
  9. ...
  10. 79
  11. →
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Tools
  • 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 >