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: March 2013

Jared Carroll

Beginning Mouse-Free Development in RubyMine

Jared Carroll
Sunday, March 31, 2013

As a long time terminal text editor user, and accordingly not a big fan of the mouse, after switching to RubyMine, I immediately began memorizing the keyboard shortcuts. RubyMine shortcuts can look intimidating, especially the three and four-key shortcuts that resemble guitar chords. However after several months of using RubyMine, I’ve found that efficient, painless, mouse-free development is possible. Here are some suggestions in helping you move away from the mouse.

Choosing a Keyboard

It’s important to choose a keyboard with modifier keys (Shift, Control, Option/Alt, and Command) on both the left and right sides, because RubyMine shortcuts often involve pressing one or more modifier keys. Having a set of modifier keys for each hand allows for more natural shortcut fingerings.

I use RubyMine on a Mac with the apple keyboard with numeric keypad. This keyboard has two sets of nice-sized modifier keys.

Respect the Dividing Line

The dividing line on a keyboard determines which hand types which keys. It usually lies on a diagonal between 5 and 6, T and Y, G and H, and B and N.

Almost all RubyMine shortcuts involve a key combination: pressing one or more modifier keys plus a non-modifier key. For safety and speed, always use the modifier key(s) on the opposite side of the non-modifier key. For example, when typing command-f, the find shortcut, use the right command key.

Touch Typing the Function Keys

RubyMine shortcuts make extensive use of the function keys (F1-F12). Most developers have little experience using these keys because editors often neglect the function keys.

Touch typing the function keys is essential for maximum speed. Extend the dividing line to the function keys between F5 and F6. This may vary depending on how your keyboard lays out the function keys.

Key Combination Fingerings

Finding the optimal key combination fingerings can help make shortcuts comfortable and easy to remember. I’ve found the following fingerings for common RubyMine shortcuts to be intuitive and painless.

  • command-option index + ring
  • command-control index + pinky
  • command-option-control index + ring + pinky
  • command-shift index + pinky
  • command-option-shift index + ring + pinky
  • option-control ring + pinky
  • option-shift index + ring
  • option-shift-control index + middle + ring
  • control-shift pinky + ring

Mouse-free Development

RubyMine publishes keyboard shortcuts for each supported OS. In future posts, we’ll explore each category of shortcuts, moving towards complete, mouse-free development.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
John Barker

Ahead of the curve

John Barker
Saturday, March 30, 2013

This is the third and final part in a series I’m writing about lessons that can be learned from functional programming. Find the first part here and the slightly inflammatory second part here.

So, long story short. This series of posts was not intended to be a diatribe against all forms of code that are not functional. Nor a rallying call for Pivotal Labs to abandon its traditional platforms in favor of writing everything in Haskell and Yesod. Instead, it was meant to begin with a playful poke at things we consider sacred, some exploration of the benefits of functional programming and what we can learn from emerging technologies and ideas. I feel that Pivotal has always been ahead of the curve in its technology choices and that it would be wise for us to give this crazy old concept a bit of a try.

Unfortunately: I’m leaving Pivotal. So instead I’m going to link you to some interesting articles and blog posts on the subject that have said everything I could hope to say only much better.

Firstly this paperĀ Why functional programming matters is a great introduction to the subject of FP in general. It speaks about FP in terms of the benefits of first class functions and how they enable composition and modularity. Out of the several (somewhat new) FP languages available Clojure is the one that interests me the most. This great article (by former Pivot David Jacobs) makes an excellent case for applying the language to production problems.

As typically Ruby developers, what FP techniques do we have available and what can we learn? Functional Eye for the Ruby Guy is a great blog post on some of the new features in ruby 2.0, including a look at lazy sequences. This talk demonstrates ways of writing more functional Ruby code, you’re probably using many of these suggestions already! My favorite of all is this Destroy all Software screen cast on how writing ruby code in a more functional way makes it easier to test.

So that’s it. I’ve found some of these ideas to be quite eye opening, I hope you’ll find them as useful as I.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Robbie Clutton

Thoughts on Simple BDD

Robbie Clutton
Saturday, March 30, 2013

A small number of projects here in New York have adopted my extremely simple behaviour driven development library, SimpleBDD, and I thought I’d share some of the emerging patterns those teams have developed while using it.

SimpleBDD, is a way of using a Gherkin like specification language and turning into a method call with Ruby. It takes the approach of tools like Cucumber but reduces it down the smallest set of features. Essentially taking a method call:

Given "a logged in user"

and calling an underlaying function:

a_logged_in_user

If that method is in the scope of the executing test, that method is executed, if the method isn’t in scope or doesn’t exist the standard method not found exception is raised. It enables a developer to produce Gherkin like specifications while staying in Ruby, using the test framework of choice.

I generally try and follow the advise of my colleague, Matt Parker, with his excellent post on steps as teleportation devises. We try and create a reusable and stateless domain specific language (DSL) for our tests and our steps call into the DSL and hold state pertinent to that particular test run.

At first on my current project we have had three separate areas for our request specs. We have the request spec itself which used SimpleBDD to describe the behavior of the application. We then had a ‘steps’ file which had the methods calls from the SimpleBDD and translated those into the reusable DSL for the application. The steps file was reused across all request specs and was becoming big pretty quickly.

Dirk, on another project which is also using SimpleBDD, skipped the ‘steps’ file and placed those methods straight into the rspec feature files underneath the scenario blocks. Then after some discussions with JT on where to keep the state our tests depended on, Brent and our team started using rspecs ‘let’ methods and the ‘steps’ within the scope of the feature block to keep the intention of the test in one place.

By also putting more responsibility onto the DSL, these methods are pretty dumb, leaving the test describing what the test is attempting to achieve through SimpleBDD method calls and the how through calling the DSL via the ‘step’ methods within the feature block in the same file.


require 'spec_helper'

feature 'homepage' do

  scenario 'happy path' do
    Given "an existing user with one widget"
    When "the user visits the homepage"
    Then "the user can see their widget"
  end

  let(:user) { FactoryGirl.create(:user) }
  let(:widget) { FactoryGirl.create(:widget) }

  def an_existing_user_with_one_widget
    user.widgets << widget # Using the application code to create initial state
    login user # Application DSL
  end

  def the_user_visits_the_homepage
    visit root_path # Capybara DSL
  end

  def the_user_can_see_their_widget
    can_see_widget widget # Application DSL
  end

end

This has been working out fairly well for us and if you're interested in a simple version for BDD for your project I hope you check this out.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Luke Winikates

Massive Problems may Affect YOU!

Luke Winikates
Thursday, March 28, 2013

Interestings

Massive DDoS might affect Internet speed

http://mashable.com/2013/03/27/massive-cyberattack-spamhaus/

http://mashable.com/2013/03/27/biggest-cyberattack/

http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet

http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Dmitriy Kalinin

[standup] [sf] 03/27/13: Metro DC

Dmitriy Kalinin
Wednesday, March 27, 2013

Helps

Sinatra Logger

We have a Sinatra app mounted on Rails. If we raise an error in the Sinatra app, it doesn’t show anywhere. Can we attach the Rails logger somehow?

Interestings

Code Climate Blog: Rails Insecure Defaults

http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

Rubymine 5.4 EAP: Rails 4, JRuby Nailgun support, and a feature requested by pivotallabs!

Check out the release announcement here: http://blog.jetbrains.com/ruby/2013/03/rubymine-ichii-early-access-is-open/

This release also includes a small feature requested by the CloudPlanner team here at Pivotal Labs! When you create a new localization property from a view, the dialog will now default your localization file to the last one used: http://youtrack.jetbrains.com/issue/RUBY-13368

Thanks to the two Pivots who up voted our feature requests (Ken Mayer and Justin Richard)! And if you never got around to up voting our team’s RubyMine feature requests, please do so now! It only takes a sec:

http://youtrack.jetbrains.com/issue/RUBY-13332
http://youtrack.jetbrains.com/issue/RUBY-13341
http://youtrack.jetbrains.com/issue/RUBY-13327
http://youtrack.jetbrains.com/issue/RUBY-13326
http://youtrack.jetbrains.com/issue/RUBY-13366
http://youtrack.jetbrains.com/issue/RUBY-13374

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Luke Winikates

[Standup][SF] Upgrade your Rubies

Luke Winikates
Tuesday, March 26, 2013

Interestings

Ruby 1.8.7 end of life – No security fixes after June

More here: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/47201

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Dmitriy Kalinin

[standup] [sf] 03/25/13: Zvezdochka

Dmitriy Kalinin
Monday, March 25, 2013

Interestings

.ruby-version (& .ruby-gemset)

The community appears to be converging on .ruby-version as a standard way to convey a project’s Ruby version. This as opposed to .rvmrc or .rbenv

If you use RVM you can also use .ruby-gemset to specify a gemset.

See https://gist.github.com/fnichol/1912050 for more info.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Brian Butz

Presenter Sanity

Brian Butz
Sunday, March 24, 2013

I’m not a huge fan of Rails view helpers, which is a post for a different day, but put simply I prefer to encapsulate presentation logic in a presenter object rather than mix it in globally across all templates. There’s a few ways to do this, the simplest being the Good Ol’ Plain Ol’ Ruby Object:


  class FooPresenter
    def description_for(foo)
      Date.today.tuesday? ? "50% off! #{foo.description}" : foo.description
    end
  end

Usually, I’ll instantiate the presenter in a controller and then call it within the view:


  class FoosController
    def index
      @foos = Foo.all
      @foo_presenter = FooPresenter.new
    end
  end

  <% @foos.each do |foo| %>
    <%= foo.name %>
    <%= @foo_presenter.description_for(foo) %>
  <% end %>

Everything is simple and feels where it should be, but we’ve gotten this at the cost of losing view helpers mixed in from Rails. One of the helpers I find particularly helpful is strip_tags. If we want access to strip_tags we can do as Rails does when mixing it into the view scope and include it in our presenter:


  class FooPresenter
    include ActionView::Helpers::SanitizeHelper
    def description_for(foo)
      description = strip_tags(foo.description)
      html = Date.today.tuesday? ? "50% off! #{description}" : description
      html.html_safe
    end
  end

This feels a bit wrong as well. For one, we’ve increased the number of public methods on our presenter by at least 4, and only really needed one of them. Two, we have little control over how we are stripping the tags, and so any unit tests we’ve written for our presenter must integrate and essentially test parts of Rails. What we really want is something that can do what strip_tags is doing. Luckily, and due Rails becoming more modular, we already something to do this for us in the Rails library html-scanner. Under the hood, strip_tag is, unless configured differently, passing your string down to the sanitize method on an instance of an HTML::FullSanitizer object. We can do something similar in our presenter:


  require 'html/sanitizer'
  class FooPresenter
    def initialize(sanitizer=HTML::FullSanitizer.new)
      @sanitizer = sanitizer
    end
    def description_for(foo)
      description = @sanitizer.sanitize(foo.description)
      html = Date.today.tuesday? ? "50% off! #{description}" : description
      html.html_safe
    end
  end

Now we have an object that is easy to test purely as a unit, and also has the ability to be extended with different sanitizers.

While this works well with strip_tags, unfortunately not every helper in Rails is as nicely decoupled. The work being done in the number_to_* methods, for instance, are written completely in modules. It may be nice at some point to pull these into corresponding objects, but a short term solution could be to just have an object that includes the module:


  class NumberCruncher
    include ActionView::Helpers::NumberHelper
  end

  > NumberCruncher.new.number_to_currency(1)
  => "$1.00"
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jared Carroll

Why are all the Stories in Pivotal Tracker Missing Descriptions?

Jared Carroll
Sunday, March 24, 2013

I asked my pair on my first day here at Pivotal.

That’s on purpose. A user story is a promise to have a conversation. When we start a story, we’ll have a discussion with the client to fill in the details.

Ok. So we’ll just ping them on Skype or something?

No. They’re sitting at the desk right over there.

The Onsite Customer

In XP, the onsite customer is a domain expert that is part of the development team. Their responsibility is to answer questions, resolve disputes, and set small-scale priorities [1].

In past projects, contacting a client involved emails, IMs, or phone calls. My stories needed detailed descriptions. Description-less stories risked building the wrong thing. So I labeled them “blocked”, and project velocity suffered.

Benefits of having an Onsite Customer

In my current project, having an onsite customer has made a huge impact.

Eliminating story descriptions has simplified iteration planning meetings. Just write down a short title and move on. Discuss the details later.

Constant client communication has helped avoid misunderstandings. Not once has a pair built the wrong thing. Developer time isn’t wasted.

Delivered stories rarely go untested for longer than an hour. A quicker turnaround has shortened system feedback time.

Get Serious About Succeeding

An onsite customer was one XP practice that was missing from my past projects. What client would be willing to give up one of their full-time employees? After four weeks of working on a team with an onsite customer, to me, the answer is clear: a client that wants their product to succeed.

[1] Kent Beck, Extreme Programming Explained: Embrace Change (Addison-Wesley Professional, 2000), 60.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Brent Wheeldon

03/21/13: New York Standup

Brent Wheeldon
Thursday, March 21, 2013

Interestings

Backbonejs 1.0 is out

Not a great deal of changes compared to 0.9x – mostly small behavior adjustments on Collection#set & Model#save.

Upgrading instructions: http://backbonejs.org/#upgrading

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Topics

  • agile (783)
  • rails (117)
  • testing (90)
  • ruby (85)
  • 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 Community Feed
  1. 1
  2. 2
  3. 3
  4. 4
  5. →
  • 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 >