- Be sure to close your connections inside an Enumerator
Since the block in an Enumerator has its own Thread context and thus connection, be sure to close it at the end od the block.
Since the block in an Enumerator has its own Thread context and thus connection, be sure to close it at the end od the block.
Vim is a great text editor, and MacVim makes it play nicely on a Mac. RVM is a great utility for managing multiple versions of Ruby on a single machine. The Command-T plugin is a great fuzzy-finder for filematching in Vim. But put all of these together, and things can get hairy: if Command-T is not compiled with the correct version of Ruby, it’ll break. Here’s how to compile it correctly:
cd .vim/bundle/command-t/ruby/command-t/ rvm use system make clean ruby extconf.rb make
When you’re running East and the project goes West, it’s time to reorganize the backlog. This can be painful but Tracker comes to the rescue with multiple story selection and cloning panels. Here’s a little cheat sheet!
Dan Podsedly covered this in a blog post last year, here’s an excerpt:
To select multiple stories, use the small checkboxes to the right of story titles. If you’d like to select a range of stories, select the first story in the list, then shift-click on the last story. This will select all in the range, and allow you to drag them together, or use some of the other actions in the Stories drop-down, such as export to CSV or move to another project. Note: range select with shift-click only works in a single panel at a time, but you can select multiple ranges of stories across the whole project.
You can deselect a large number of stories in the Stories drop down menu.
Check out this short Screencast to see a demo of working with multiple stories in Tracker!
One of our tables was using an hstore to collect data (a really big json object). We discovered that the primary database on staging was using PG 9.1.3 while our acceptance & production apps were using 9.1.4. Pushing this very large (58K) object into the hstore caused a Postgres failure:
ActiveRecord::StatementInvalid: PGError: ERROR: cannot execute INSERT in a read-only transaction : INSERT INTO “xxxx” (”created_at”, “data”, “updated_at”, “user_id”) VALUES ($1, $2, $3, $4) RETURNING “id”
while saving the same data into our acceptance app did not cause the error.
We suspect that there is a bug in PG 9.1.3 when inserting “big” strings into an hstore that is fixed in 9.1.4.
We promoted a new 9.1.4 db on our staging app. This cleared our problem.
We were able to stream the contents of a table to the user without loading the whole dataset into memory.
It’s in Denver this year.
In Tracker support, I take delight in answering support requests we get from people on teams who are thinking through the way they make software and how Tracker fits into that process. Recently, a customer asked us if Tracker can support their team’s switch from a more Scrum-focused process to a more Kanban-focused process.
Typically when I get such questions, if I can’t answer them myself, I look through our Tracker blog posts or our Community forum to see if I can’t find something salient. In this case, I found very little information. Knowing that Scrum vs. Kanban is a debate happening for many of our users and, indeed, within the Agile community itself, I decided to ask the Tracker Team: what do we think about Kanban and Tracker?
Glen, a Tracker Developer, says:
“If there were a continuum between Kanban at one end and strict Scrum (per-iteration story commitment), I think that within the Tracker team we’re actually about 75% of the way toward the Kanban end. We operate much closer to “pull” than we do to commitment, letting stories ebb and flow through the Backlog, periodically refilling the Backlog with batches from the Icebox as it becomes clear that we’re getting toward the (meaningful) bottom of the current work pile. And we let releases migrate to logical times in the workflow, rather than being rigid about either their content or timing.
On the other hand, there remains significant benefit (in our opinion) to estimating stories and computing velocity. The discussions of relative complexity and difficulty that we have when we estimate stories is valuable to the team, and having a cost associated with stories and features is an important factor in whether the Product Owner decides they should be prioritized or not. And having a record of iteration velocity tells us lots of interesting things about how the team is performing–in particular, periods of significant velocity drops indicate a struggling team and signal that we should be looking for a cause and something to fix.
In short, our opinion is that you should do what Tracker does, rather than either ‘real’ Kanban or ‘real’ Scrum.”
The rest of the team agreed pretty quickly with Glen, and it’s worth decomposing his response to see how this applies to working with Tracker.
Understanding pull vs. push is central to understanding Kanban. In her book, Leading Lean Software Development: Results are not the Point, Mary Poppendieck describes a push system as, “managed by “pushing” a predetermined plan to the operating environment and tracking task completion against that plan…You manage a pull system by managing the queues, instead of by scheduling the details of the work..” On the Tracker team, instead of deciding on a large set of stories to be completed for a release, we are constantly prioritizing new stories in our Icebox and Backlog. Because we do this, the most important tasks are always at the top and automatically get “pulled” into Current when an interation changes.
While XP and Agile brought us out of the dark ages of big-bang releases in favor of smaller, more frequent releases, there are now varying flavors of frequent releases. In XP and Scrum, releases are typically associated with the end of an iteration, but they don’t necessarily have to be. On the Tracker team, we focus on flexibility within an iteration. This is part of the logic behind Tracker’s release markers. The release markers have a date, but that date does not have to coincide with the end of an iteration, neither is the marker tied to a certain set of stories. We have Epics for that. You can read more about both Epics and Releases here.
Having seen my fair share of support tickets where people ask questions about how they should expect their releases to change when using Tracker, I asked Glen to expand on how and why the Tracker Team releases the way it does:
”Tracker’s model for deployment tries to have frequent releases but to put them into the workflow so that they come after the completion of a batch of related stories. Some development processes are rigid about when releases happen (Every two weeks on Friday!!), and either make people work late to make the release timing or have a “train” model where releases are the train leaving on a particular schedule, and features either make it or they don’t, based on the code being merge-able before some fixed pre-release cut-off time that allows for integration/regression/etc.
Scrum tends to be a rigid work-late process, and Kanban is often either continuous deployment or a “train” process (admitting that their deployment wants feature delivery to be chunked, but only at the very end of the process).
The up-side of our process is that you don’t do silly things like make ‘empty’ releases or do a release a day before a big pile of features are done, causing their becoming available to users to be artificially delayed by the fixed release interval. The down-side is that you can get into a loop where some batch of features is always a day or two from being releasable, so the ‘next’ release keeps being pushed back a couple of days every couple of days, and then maybe you forget to release for a couple of weeks (or months). And that’s bad.”
So far, much of what I’ve written about in our process is, as Glen said, pretty close to Kanban. Our team currently diverges from Kanban by using the estimation of story points and relying on the velocity calculated by Tracker which comes out of XP and Scrum rather than relying solely on the amount of time stories take to finish. In Kanban, focus is placed solely on the amount of time it takes to implement and deliver a story. The Kanban metric, Cycle Time is calculated by looking at the time a story spends in a queue instead of estimating it. Jeff Patton explains Cycle time and how it differs from using points and velocity in his post, Kanban Development Oversimplified.
When I asked the team why we estimate points vs. calculating cyle time, their responses revealed that points estimation is one of the areas in Tracker where team discussion and participation is expected. Tracker developer, David Stevenson points out that there is more than time involved in estimating stories, “PMs should have the ability to see what things are at least ‘easy’ ‘medium’ and ‘hard’. Then they should get immediate feedback when they try to do too many hard things, by realizing that they can’t get done quickly.
Kanban’s velocity based on time treats all stories the same, which only makes sense if you have a consistent mix of easy, medium, and hard stories, and don’t care when a specific story gets done.”
Our Product Owner, Dan Podsedly, who recently wrote the Tracker blog post, Velocity Matters, also weighs in on using Velocity vs. Cycle time. “There are certainly advantages/benefits to tracking cycle time, and being able to predict how long a given item might take to get from point A to point B in the workflow. Kanban focuses on this because it’s based on assembly line manufacturing, where the important thing is to optimize station queues and reduce costly bottlenecks.
While Kanban is popular these days, modeling software development based on station-to-station car manufacturing can have negative side effects, as it can lead to more silos (stations) and lines of communications. In my opinion, Tracker forces teams to act more like teams, and work together to get stories through a simple workflow and towards acceptance (the finish line). Instead of measure how long stories take to complete, we track rate of output (of business valued features), and use that to predict future pace of output.”
And of course, as already discussed, focusing on complexity, rathering than estimating/tracking time, drives the important conversations and allows the PM to make important (prioritization) decisions early on.”
The comments reveal an important, re-curring theme within the Tracker team. We don’t get too hung up about labels such as Kanban, Scrum or even Agile. No matter which tool or process your team is using, at the end of the day, it has to be about getting the software out the door given the people you have and the resources at your disposal. At its core, Tracker is about a team of people making software, not the labels they use to describe their process. Since every team has its own context, your mileage may vary although we are obviously happy if Tracker happens to be the tool that helps you the best.
Poltergeist is a gem that replaces capybara-webkit and handles iframes better supposedly. The unfortunate side-effect of using it is that it modifies how exception handling works even within your controller actions. This was incredibly hard to debug. We recommend not using it for a while.
If you have a nil time column and you set it to nil,
model.changed? now returns true.
The same is true for any values which are equal.
There’s a new version of jasmine-gem on GitHub – please test it out so we can push a new gem next week.
Once the CSS opacity is set on an element with jQuery the z-index is no longer respected and the element appears on the bottom.
Can it be reproduced in other browsers? Only tried Chrome so far.
The workaround is to use:
value = my_model.created_at.to_f * 1000
date = new Date(value)
Try all browsers when dealing with a Date API
There’s also DateJS, but has not been maintained in a long time.
If you have an updated version of Chrome and jasmine fails to start Chrome, reinstalling later version of chrome driver (http://code.google.com/p/chromedriver/downloads/list).
Or alternative is to re-image the machine, which contains later Chrome and later ChromeDriver.
We spent several hours tracking down this (open) bug in bitbucket’s tracker broker. You can change the ampersand to something else in your git-pair script.
IE9′s click handler for SVG paths treats two clicks as a single click and six clicks as a double click.
SNL Ticket Lottery Open
Lottery for SNL tickets is open. Email email@example.com once during the month of August with full contact details to enter.
Full details at nbc.com
After finding that we had a few images checked into our project’s repository but that were not referenced in the project, I wanted to write a script to quickly see if there were any other unused assets.
This was a one-off script, so it probably won’t suit everyone’s needs, but here’s how we approached the problem:
First, we needed to get a list of the files that git was tracking in our image directory. While you could use
ls for that, I wanted to be sure that we weren’t going to list any files that git was ignoring, so we started with
git ls-files, whose output will look something like this if called as
git ls-files ./img:
(For the sake of the example, we’ll assume that
foo.png is referenced in the project and
The next thing we want to do is to see if those filenames are referenced anywhere in the code. At this point, I wasn’t sure if they would be referenced by a relative or absolute path, so I knew I wanted to just search for e.g.
foo.png. I like to check my work with an intermediate command, so the next command we tried out was
for FILE in $(git ls-files ./img); do echo $(basename "$FILE") done
basename gives you everything after the last slash of its input — in this case, just the raw filename.) And when we ran that command, we saw the expected output:
Now that we know we are correctly extracting the desired part of the path, we can check whether that filename is referenced anywhere in the code.
git grep works enough like regular
grep, but it only searches tracked files in the working tree (if you call it without a commit-ish), so we don’t have to worry about excluding the
.git directory or
If we call
git grep foo.png manually, we will see some output like
src/index.html: <img src="../img/foo.png"/>
git grep bar.png will have no output. But it isn’t the output we care about so much as the exit status (noting that
git grep will return non-zero when no results are found) — so let’s run our command again, and verify that we will only remove the expected files:
for FILE in $(git ls-files ./img); do git grep $(basename "$FILE") || echo "would remove $FILE" done
Oops, the output contains the output from
git grep still:
src/index.html: <img src="../img/foo.png"/> would remove img/bar.png
git grep‘s output to
/dev/null and move along.
for FILE in $(git ls-files ./img); do git grep $(basename "$FILE") > /dev/null || echo "would remove $FILE" done
The output looks correct! The last thing to do is to actually remove the file:
for FILE in $(git ls-files ./img); do git grep $(basename "$FILE") > /dev/null || git rm "$FILE" done
After that, run your tests again to make sure that nothing was broken by removing these assumed-to-be-unused files. If you’re green, you’re probably good to commit!
I think these are the two biggest limitations of this roughly-one-liner:
IFSto properly read the lines from the output of
But if those don’t affect you, then you can probably use that mini-script to get rid of some “noise” files from your working tree.
Last week, we made a slight tweak to how velocity is calculated in Pivotal Tracker, to handle team strength overrides in a simpler, more explainable way. As a result, if your project has an adjusted team strength in a recent iteration, you may be seeing a slightly different velocity.
Details of how velocity is calculated, and how team strength affects it, are at the end of this post.
This seems like a good opportunity, though, to step back a bit, and revisit the velocity concept in Tracker and why it (still) matters. Read on, even if you’re an old hat to agile and Tracker!
First, let’s re-define what velocity is. Christian Niles, our iOS engineer, recently gave it an eloquent description (inspired by his recent relaxed strolls through the streets of Paris):
“Just like a speedometer that measures how fast you’re hurtling through space, Tracker’s velocity is a measurement of how fast your team completes stories. Instead of miles or kilometers per hour, Tracker expresses velocity as the number of points completed per iteration.
Because Tracker stories are assigned point values instead of due dates, Tracker calculates velocity by averaging the number of points you’ve completed over the past few iterations. In Tracker, past predicts future.”
Yes, velocity does give you a glimpse into the future, in the form of more realistic estimates of when milestones will be hit, at least compared to wishful due dates. It’s obviously just an approximation, though, and the velocity number itself is ultimately not very meaningful outside the context of a given project.
What’s really valuable are the conversations that story estimation encourages within development teams (and their product owners). Conversations that uncover all kinds of assumptions and hidden scope, and give the product owner the insight to make value decisions at every step (is that 5 point feature really worth it, is there a simpler alternative?), which all leads to leaner, better product, and a more direct path to the finish line.
Having a crisp, prioritized backlog of estimated stories, and a steady velocity, lets you have really constructive conversations with your stakeholders when facing that inevitable change to requirements. Dragging those new stories into the backlog gives you immediate feedback about how the scope increase will affect the future timeline and planned releases, and allows you to make tradeoff decisions (“ok, let’s move these other stories down so we can still make that milestone”).
These conversations are where all the important tactical decisions are made, and there will be many, as you keep learning as a team, and the world keeps changing on you. Each one takes you closer and closer to winning the battle (and shipping great software).
Steady state allows you to predict, at least roughly, when your project will hit important milestones. This gives your business the ability to plan ahead and to make meaningful tradeoff decisions (usually scope vs time), as you discover more scope (and you always do). Predictability is rare in the software industry, and only comes when you get your project to that zen-like state of steady, consistent pace, measured by low volatility (of velocity).
Achieving low volatility takes an ongoing effort, but the practices that collectively yield it are worth the effort on their own merit. Break down large features into small stories (that fit into a single iteration), estimate as a team, maintain a constant ratio of features to bugs and chores every iteration, deliver stories continuously, and have your product owner highly involved, available, and accepting those stories daily.
Unless you’ve got a team of cyborgs, or perfected cloning technology, chances are there will be weeks when a big subset of the team is sick (yes, that achilles heel of pair programming), on vacation, at a conference, or it’s just the usual between the holidays lull with a skeleton crew.
The team strength feature allows you to plan for that (or account for it retroactively), in terms of velocity. For example, if half of your team leaves for a conference one iteration, you might set your the team strength of that iteration to 50%. Likewise, if your team works all weekend to prepare for launching your product, you would set the team strength to 140% (since they worked 7 days instead of a normal 5 day work week).
Check out a short video on team strength here.
You can also adjust the length of a single iteration, for situations such as the big end of year holidays. Or you can use it to effectively put your project on hold, by combining iteration length override with a team strength of 0%.
How velocity is calculated is fairly straightforward, it’s the sum of all ‘normalized’ points completed over a given set of iterations (based on project settings), divided by the combined length of all those iterations, in weeks. ‘Normalized’ points are the number of points the team would have completed in an iteration at 100% team strength.
velocity_per_week(iteration_1, ..., iteration_N) = SUM(iteration_i.points / iteration.team_strength) / SUM(iteration.length_in_weeks)
Iterations with a team strength of 0 are excluded from both sums.
The formula above always returns velocity per week. The project velocity Tracker displays is always multiplied by the default iteration length, and rounded down to the nearest integer. For example, if your iterations are 2-weeks long by default, Tracker will multiply the per-week velocity by 2.
We’ve got quite lot of detailed information about velocity and related topics in the Tracker FAQ, as well as the Getting Started guide. In particular, take a few minutes to watch the Introduction to the Concepts video.
If something still isn’t clear, give us a shout!
p.s. thanks to Richard Jones for the awesome Millenium Falcon pic. we want one!
Use page.driver.render to save a screenshot.
Look at capybara issue discussed yesterday at http://pivotallabs.com/users/abruce/blog/articles/2220-rager-party-standup-7-31-12-
Also of note: http://nice-entity.com/
Using bundle exec may solve some Foreman issues teams have been seeing.