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
Jared Carroll

Debugging in RubyMine

Jared Carroll
Monday, May 20, 2013

Before using RubyMine, my debugging workflow went something like this:

Why isn’t this test passing?. It should’ve passed. Let me add a few Kernel#puts calls to see what’s going on. Hmmm, ok, it’s still failing. I’m going to need some more output. Man, these tests take forever to run. Syntax error?!. Ugh, typo…

Debugging like this isn’t fun; especially when pairing. Fortunately, RubyMine can help. RubyMine includes a standard debugger that has minimal setup and works out of the box. I still don’t enjoy debugging, but RubyMine has made it much less painful. In this post, we’ll look at debugging in RubyMine on OS X.

Setting Breakpoints

Add or remove breakpoints with command + F8.

breakpoint.png

View existing breakpoints with command + shift + F8.

view-breakpoints.png

Starting the Debugger

Debug the current program with control + shift + D. This will automatically open the Debug tool window (command + 5).

debug-tool-window.png

Use control + D to re-run the last debug session. View recent debug sessions with control + alt/option + D.

debug-menu.png

Examining a Program

Examine variables in the Debug tool window’s variables pane.

variables.png

Use command + N in the Debug tool window’s Watches pane to watch a specific variable. backspace will delete a watch.

watches.png

Use alt/option + F8 to evaluate arbitrary expressions. control + space triggers autocompletion.

evaluate-expression.png

Instead of using the Debug tool window, examine a variable inline by placing your cursor on it and pressing command + alt/option + F8.

quick-evaluate-expression.png

Stepping through a Program

Step into a method with F7. Step over a method with F8. Step out of a method with shift + F8.

Use your cursor as a temporary breakpoint with alt/option + F9. Continue your debug session with F9.

Stop #puts’ing

If you’re using an IDE, take time to learn its debugger. Don’t litter your code with Kernel#puts and friends. Instead, set a breakpoint, start the debugger, examine some objects, and slowly step through your problems.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jared Carroll

File Management in RubyMine

Jared Carroll
Sunday, May 12, 2013

As developers, we create, update, and delete files all day long. Managing files from the command-line is one of the first skills we learned. However, constantly switching from your editor to the command-line to execute a simple file command, a command you’ve probably executed thousands of times before, is tedious and slow. Instead, stay in your editor, and let it take care of the boring stuff. In this post, we’ll look at RubyMine’s file commands on OS X.

Creating Files

To create a new file or directory, press control + alt/option + N within the editor or Project tool window.

new in current directory dialog

Copying Files

Use F5 within the editor or Project tool window to copy the current file.

copy dialog

F5 can also be used in the Project tool window to copy directories.

Cloning Files

To create a copy of a file or directory in the current directory, press shift + F5.

clone dialog

Moving Files

Move files and directories with F6.

move dialog

Like the previous file commands, this command works both within the editor and Project tool window.

Renaming Files

Files and directories can be renamed in the Project tool window with shift + F6.

rename dialog

Deleting Files

Delete files and directories in the Project tool window with delete.

safe delete dialog

Locating Files

To locate a file in the Project tool window, press alt/option + F1 in the editor, and then select the Project View option, the default option, from the Select Target dialog.

select target dialog

Select Reveal in Finder to open the file in a new OS X Finder window.

Working with File Paths

Use command + alt/option + F12 to view the complete file path.

file path dialog

Selecting a directory will open the directory in a new OS X Finder window.

Copy the current file path to the clipboard with command + shift + C. Copy a reference, the current relative file path and line with command + alt/option + shift + C.

paste from history dialog

These commands are useful for when you need to work with a file on the command-line.

Relying on Abstractions

A common developer fear is that overreliance on a particular IDE’s features will cause you to forget, or maybe never learn, the underlying commands. I agree that in some cases, e.g., version control, it’s important to know what’s going on under the hood. However, these situations are rare. And when it comes to everyday commands, I’d much rather use higher-level abstractions to free me from the mundane.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jared Carroll

Running Programs in RubyMine

Jared Carroll
Sunday, May 5, 2013

A typical Rails development environment includes an editor, a terminal for running a web server, and a utility terminal for managing files, using version control, running tests, etc. During development, you’re constantly switching between your editor and these external terminals. RubyMine, an Integrated Development Environment, can eliminate this tedious back and forth workflow. In this post, we’ll learn how to run programs in RubyMine on OS X; allowing you to stay in RubyMine all day long.

Running Files

To run a file, open the file in the editor or select the file in the project tool window, then press control + shift + R. Rerun a file with control + R.

These commands are commonly used to run test files, but they could also be used to run a simple Ruby script.

Run Tool Window

All running programs are displayed in the Run tool window. Press command + 4 to open the Run tool window.

run tool window

Stop a running program with command + F2. Use command + shift + [ and command + shift + ] to navigate between multiple running programs.

Running Tests

In a test file, press control + shift + R outside of any individual test to run all the tests in the file. Press control + shift + R within an individual test to run just that test.

Run Dialog

Open the run dialog with control + alt/option + R. The run dialog lists recently run programs. This is useful for when you want to rerun a test you ran several tests ago.

run dialog

By default, this dialog also includes commands to run a development server, and your entire test suite.

Ruby/Rails Quick List

Use command + option + R to open the Ruby/Rails quick list. The Ruby/Rails quick list includes several useful commands such as, starting a Rails console, and starting an IRB session.

Ruby Rails quick list

You can run a file or a code selection in an existing IRB or Rails console with alt/option + shift + L. View IRB history with command + E.

IRB history

Running Rake Tasks

Run a Rake task with alt/option + R.

run Rake task

If a custom Rake task doesn’t appear in the list, reload Rake tasks from this dialog or the Ruby/Rails quick list (command + alt/option + R).

Running Rails Generators

Run a Rails generator with command + alt/option + G.

run Rails generator

If a custom Rails generator task doesn’t appear in the list, reload Rails generators from this dialog or the Ruby/Rails quick list (command + alt/option + R).

Take Advantage of Your IDE

IDEs increase your productivity by combining all of your development tools into one program. Frequent context switching to external tools not only slows you down, but also requires more in-depth knowledge of each tool. Try gradually replacing external tools with their IDE equivalents. Over time, your knowledge of shell command options and obscure Git commands will no longer seem very important to you.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Andrew Bruce

Procrastination, considered.

Andrew Bruce
Sunday, May 5, 2013

Last week I blogged about a new project for aiding in the hunt for test pollution, Scrubber. This is a personal side project that I began recently. It’s in the very early stages, like many of my other pet projects. It’s something I’ve worked on entirely alone, though I’d also love to collaborate with others and/or pair on it.

I was going to blog this week about the latest improvements I’d made to the code, and how it was going to improve the end-user’s experience despite being a mere refactor and a minor user interface tweak. I got bored after writing the first few paragraphs, and instead got distracted by the code, refactoring and tweaking it more than was necessary. A couple of hours in, I’d totally gold-plated the code in a way that I might have deemed unacceptable whilst on client time. This made me a little angry with myself: why was I procrastinating from blogging, and was I a bad developer who’d lost the ability to work alone?

Something we’re encouraged to do at Pivotal Labs is reflect on our behavior. Thinking about my boredom and procrastination a little, I realized there was something more interesting going on. The process went a bit like this:

  1. Start blogging about the new features. Paste the visual output of the program into the blog post. Realize that the output didn’t meet the requirement of improving the user experience.
  2. Start to implement the missing parts of the feature. Spend hours enjoying the freedom to refactor, delete and re-implement with no time limit, far more than when pairing on client time.

When we pair, we have a safety net to catch us when we get distracted by neat language features or elegant implementation tricks. Our partner will often remind us that we’ve spent, say, two hours making no discernible feature changes and no improvement to maintainability of the code. When soloing, however, especially on pet projects, we are free to choose a goal for the activity. Sometimes we decide to perform code katas, but other times we don’t consciously choose a goal: the goal could become apparent during the activity itself.

So it seemed that I’d accidentally found validation in what I was doing, and a potentially more interesting blog post at the same time. I’d managed to get some programming exercise in instead of banging out a not-quite-earth-shattering new feature. Specifically, I:

  1. Thought like a user until it became obvious that changes were still needed. Switched to developer mode by accident.
  2. Allowed myself to try out several approaches to the Presenter pattern, applying them to a trivial example that would not need a presenter in ‘real world’ programming.
  3. Used the Introduce Null Object refactor in a situation that didn’t call for it. Yet, it felt good and might even prove useful for the project later.
  4. Practiced several coding techniques that might become useful in the work environment.
  5. Temporarily inverted my work-based insecurities about performance and timeliness, providing stress relief as an unexpected benefit of my brain switching itself off from the task at hand.

Reflection is a useful technique for improving well-being. Your mileage may vary. If you’d have preferred to read about the changes made to Scrubber this week, you can read the commit history!

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jared Carroll

Breakdown Your Work in RubyMine with Tasks

Jared Carroll
Sunday, April 28, 2013

In RubyMine, you can create tasks to breakdown and structure your work. A task can be a simple local task, or it can correspond to a feature, bug, or chore, in an issue-tracking system. Each task in RubyMine includes the current state of the editor, allowing you to switch between tasks and resume exactly where you left off. In this post, we’ll explore RubyMine’s tasks on OS X.

Creating Tasks

Press alt/option + shift + N to open the task dialog. Enter the task’s name, then press Enter to create the task.

create task

By default, RubyMine will clear your current context and create a new changelist.

Switching Tasks

A context is a set of opened files. Each task has an associated context. When you switch tasks, its context is automatically loaded.

To switch between tasks, use alt/option + shift + T.

switch task

Isolating Work with Changelists

A changelist is a set of related source code changes. Each task has an associated changelist.

task changelist

Changelists allow you to isolate each task’s changes. Use command + K to commit the current task’s changelist. RubyMine will now consider the task closed, and ask if you want to delete its changelist.

Pivotal Tracker Integration

Instead of manually creating tasks, you can configure RubyMine to load tasks from Pivotal Tracker.

In project settings, command + ,, create a new Pivotal Tracker server in the Tasks Servers section. Then add your Pivotal Tracker project id (located in the Pivotal Tracker project’s settings page) and API token.

pivotal tracker settings

Pivotal Tracker stories will now appear in the task dialog.

Pivotal Tracker tasks

Creating a new task from a Pivotal Tracker story allows you to update the story as in-progress. However, it won’t set you as the owner of the story. Also, closing the task won’t finish the story.

Clean Context Switching

RubyMine’s tasks are well-suited for serial development. But if you constantly switch contexts, like most developers, they fall short, because switching tasks brings along committed work. If each task consists of a single commit, then this isn’t a problem. However, I prefer to commit frequently; resulting in many small, granular commits. So, in my opinion, using a distributed version control system, e.g., Git, and a branch-per-feature workflow, is a better development strategy than RubyMine’s tasks. Branches keep your work isolated from the main line of development, and it’s still possible to cleanly switch contexts.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jared Carroll

Searching Code with RubyMine’s Usage Search

Jared Carroll
Sunday, April 21, 2013

When browsing a codebase, you often want to view the definition of a particular class, method, or variable. However, sometimes you want to do the reverse; you want to see where a particular class, method, or variable is used. Typically this involves using your editor’s text search, or a command line tool, such as grep or ack. Unfortunately, text searches may return false positives, such as log file data, or similarly named constructs. The problem is that you want to search code not text.

RubyMine has text search, but it also includes a powerful, code-based usage search. Usage search is smarter than text search, because RubyMine is aware of code constructs such as classes, methods, and variables. This results in a more accurate search; allowing you to quickly view and navigate actual usages. In this post, we’ll explore RubyMine’s usage search on OS X.

Find Usages

To find where a particular class, method, variable (instance or local), or parameter is used, place your cursor on it, and press alt/option + F7. Results will be displayed in the Find tool window.

find usages

command + alt/option + Up/Down navigates the results. Use F4 to jump to the source code of a particular usage.

Recent usage search results can be viewed again with command + E.

recent usages

Find Usages in File

By default, find usages is scoped to the entire project. To scope it to the current file, use command + F7. command + G and command + shift + G navigate the results.

Show Usages

command + alt/option + F7 can be used to show usages inline. Instead of displaying usages in the Find tool window, they appear in a pop-up window.

show usages

Searching Code

RubyMine’s usage search demonstrates an advantage an IDE has over a text editor. By being aware of code constructs, such as classes, methods, and variables, IDEs can offer powerful tools that allow you to quickly and accurately explore a codebase.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Jared Carroll

Mark Your Place: Bookmarks in RubyMine

Jared Carroll
Sunday, April 14, 2013

Like many text editors, RubyMine supports bookmarks. A bookmark is a reference to a particular line in a file. They are visually indicated by an icon in the editor gutter. Bookmarks can be used as a form of navigation based on interested parts of a codebase. In this post, we’ll explore (using the Mac OS X 10.5+ keymap) the three types of bookmarks in RubyMine: anonymous, numbered, and lettered.

Anonymous Bookmarks

Anonymous bookmarks can be created with F3. They appear as a checkmark icon in the editor gutter.

anonymous bookmark

Unfortunately, there are no default keyboard shortcuts to navigate anonymous bookmarks. Instead, use the Find Action command,command + shift + A, to search for the “Next Bookmark” and “Previous Bookmark” anonymous bookmark navigation commands. These commands will only navigate through anonymous bookmarks in the current file.

Mnemonic Bookmarks

There are two types of mnemonic bookmarks: numbered and lettered.

Numbered Bookmarks

You can have up to 10 numbered bookmarks: 0-9. To create a numbered bookmark, press control + shift + <number>, e.g., control + shift + 4.

numbered bookmark

To navigate to a numbered bookmark press control + <number>, e.g., control + 4.

Lettered Bookmarks

You can have up to 26 lettered bookmarks: A-Z. To create a lettered bookmark press option + F3, then choose a letter to use for the bookmark.

lettered bookmark

To navigate lettered bookmarks, use the bookmarks dialog (discussed below), command + F3.

Deleting Bookmarks

All three types of bookmarks can be deleted by pressing F3 when on the bookmarked line.

Viewing Bookmarks

You can view all existing bookmarks with command + F3.

bookmarks dialog

This dialog also allows you to delete, and navigate bookmarks.

Last Edit Location “Bookmark”

When editing, it’s common to stop for a second to view another part of the file (or a different file), and then navigate back to the original edit location.

Instead of using bookmarks to quickly navigate back to the original edit location, use the Last Edit Location command, command + shift + Backspace.

Experimenting with Bookmark Navigation

After trying out the different types of bookmarks in RubyMine, I find numbered bookmarks to be the most useful. They are both easy to create and navigate. Lettered bookmarks offer a greater number of possible bookmarks, but navigating them requires several commands. I think anonymous bookmarks could also be useful, if you create shortcuts for their navigation commands.

Try them all and see what works best for you.

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

Long-term Estimation in an Agile Environment, or: How I Learned to Stop Worrying and Love the Assumptions Label

Jonathan Berger
Monday, April 1, 2013

Estimation is Hard

Flexible plans executed via iterative development are at the core of Agile:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This is great for figuring out what to build, but all this flexibility can make planning and estimation hard. In practice, developers tend to prefer backlogs containing a few weeks worth of fine-grained stories following INVEST principles, followed by low-fidelity—and unestimated—chunks of epic-sized features. The thinking is that any stories farther out are unstable, and that it’s wasteful to spend time specifying them in detail. Agile planning tools like Pivotal Tracker are built with this perspective in mind, and are great for managing fine-grained details. But what happens when you need to get a more big-picture view of a project? Recently, a colleague said:

As development moves forward, features change. And those changes have implications on the stories later in the backlog or icebox. … Not sure if this the best way since it causes me to not want stories that extend beyond a few iterations.

Isn’t this the perfect distillation of the Agile Manifesto’s notion of “Responding to change over following a plan”? I find the problem isn’t changing stories—this is a natural part of Agile development. Rather, the difficulty is doing the work to 1) figure out which stories are stale, and 2) to re-estimate stale stories, lest 3) clients make plans based on stale estimates and then get upset when we say “sorry, those estimates aren’t accurate any more”. Ideally, the estimates will be revamped downwards (there’s less uncertainty now that we know more about what’s going on, right?), although sometimes we’re discovering hidden complexity and the estimates go up. D’oh!

The Assumptions Label Technique

One technique I’ve used successfully on a few projects is what I like to call the Bullpucky Assumptions Label. I pull it out when the client demands—not unreasonably, I might add—that we estimate out the next 3-12 months of work so that they can get funding / approval from their boss / etc. I’ve seen project teams fight this for weeks (the PM getting more irate and frustrated the whole time), finally lose, and schedule a (miserable) half- or one- or two-day mini-inception during which they proceed to estimate every story for the next few quarters in fine-grained detail. Of course, they inevitably have to re-estimate half those stories in angry IPMs when it becomes clear the estimates are wrong, grumbling “we told you these estimates were bullpuckey”.

Here’s the Assumptions Label technique:

  1. Schedule a 2-3 hour Assumptions Meeting with the PM and 1 or 2 devs. (You don’t need the whole team; these aren’t real estimates). Estimate “stories” (they’re really closer to epics) at a multiples-of-8-point level of granularity. Pretend we’ve built the basic shopping-cart and inventory functionality of Hamazon (“The Internet’s Favorite Purveyors of Pork since 2009!”), and now the client wants to fully copy Amazon’s feature set. It might contain rough estimates like “Reviews and ratings? Mmmm…24 points. Recommendation Engine? 40 points.” Rough out the desired feature set. You’re basically estimating at a pair-week level of granularity, so multiply pair-weeks by (velocity/team strength) and you’ve got your pointed estimate.
  2. Write titles in all caps (they’re easier to see that way). Don’t bother writing a description for the story. It’s ok to use multiple 8-pointers to get to the number you need.
  3. Throw an “assumptions” label on all these stories; they’re easier to wrangle (and it never hurts to drive the point home).
The Assumptions Label technique in action.

The Assumptions Label technique in action. Use it to re-prioritize coarse-grained blocks of epic, and watch estimated completion dates adjust.

Now your PM can give a rough estimate to their boss or their boss’s boss, re-prioritize at a rough level of resolution, and cut scope or add pairs. But it remains clear to everyone that these should never be mistaken for actual, deliverable stories. In fact, these “assumption” stories become a decent way to see what’s next when story-writing. IPM or pre-IPM often becomes an exercise in picking the top assumption off the top of the file and fleshing it out into real stories. By reducing the difficulty in seeing what’s a real story and what’s a rough estimate for planning’s sake, everyone gets better visibility into the project. Pivots can set better expectations for their PMs, PMs can set proper expectations for their boss, and trust is preserved on the team.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
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
Dan Podsedly

Hojoki – activity from Pivotal Tracker and your other apps in one place

Dan Podsedly
Tuesday, December 13, 2011

Hojoki is a new collaboration app that promises to “make all your cloud apps work as one”, by integrating many of the most popular services that your team uses daily (including Pivotal Tracker, of course) into a personalized activity stream.

Once configured, your Hojoki activity stream shows you when a story is created, edited, started, finished and deleted. Hojoki also shows you all of your project members, and allows you to search for who created a story, who requested it, and who is responsible for implementing it.

To welcome Pivotal Tracker users, Hojoki if offering some cool robot-playing-basketball shirts! There are only a few available, though, so they’ll go to the first 10 people who comment on this blog post, below.

More info on the Pivotal Tracker integration, including how to get started, in the Hojoki welcome blog post.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Topics

  • agile (780)
  • rails (113)
  • testing (88)
  • ruby (83)
  • ruby on rails (70)
  • jobs (62)
  • javascript (55)
  • techtalk (44)
  • rspec (38)
  • ironblogger (32)
  • productivity (30)
  • activerecord (29)
  • gogaruco (29)
  • git (28)
  • nyc (27)
  • rubymine (26)
  • bloggerdome (23)
  • mobile (22)
  • process (21)
  • pivotal tracker (20)
  • cucumber (20)
  • 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)
  • css (13)
  • tdd (13)
  • selenium (12)
  • goruco (12)
  • bundler (12)
  • meetup (11)
  • railsconf (11)
  • nyc-standup (11)
  • capybara (10)
  • mac (10)
  • mojo (10)
  • chef (10)
  • api (10)
Subscribe to productivity Feed
  1. 1
  2. 2
  3. 3
  4. →
  • 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 >