Comments for Pivotal Labs

Comment on AwesomeResource by Hoetmaaiers

Hoetmaaiers — Wed, 22 May 2013 11:29:43 +0000

Are you aware of the gem Her, http://her-rb.org/ ?
This seems to be what you try to accomplish with AwesomeResource.

Comment on A Responsible Recipe for the Fewest Possible Meetings by Don Mullen

Don Mullen — Tue, 21 May 2013 13:16:05 +0000

Great article, Jonathan. Thanks for sharing.

I would add a Risk Assessment meeting to the Friday mix, with the goal of putting together a prioritized list of risks, and how the team means to address them. Team retros are generally looking back at how things went, while Risk Assessments are forward looking and proactive.

I’ve also found that changing the retrospective format keeps things from getting stale. Agile Retrospectives, by Derby/Larsen (http://goo.gl/3WO6E) has many excellent retrospective exercises to mix things up a bit.

Comment on 2013 Tracker Update – New Features, New API, New Design by Richard Amos

Richard Amos — Tue, 21 May 2013 10:41:48 +0000

Hi there – we’d love to try the Beta as long-term Pivotal users.

Thanks!

Comment on Using MySQL foreign keys, procedures and triggers with Rails by Vu Phuc Tho

Vu Phuc Tho — Tue, 21 May 2013 05:32:28 +0000

Thank! Rails does not support foreign key in database level, so this problem has irritated me a lot. I will consider yours an option when working with RoR.

Comment on Pivotal: Why It Works by pht

pht — Mon, 20 May 2013 19:42:08 +0000

” Our ops team has done a great job of having an updatable workstation image that is under test so they know when it breaks. ”

I’m curious to try such thing myself. Can you share some details or even a starting point?

Comment on 2013 Tracker Update – New Features, New API, New Design by Paul Jenkins

Paul Jenkins — Mon, 20 May 2013 05:25:48 +0000

As a startup using PT, we’d love to try the Beta also. Thanks!

Comment on git rebase vs. git merge: an agile perspective by Yawar

Yawar — Sat, 18 May 2013 05:36:30 +0000

I’ve come to think that especially on larger projects, rebasing v merging is very much an art form that you need to develop a feel for.

But if you want to maintain a tight feedback loop–if you want to _regularly_ make sure your topic branch will integrate with the mainline, there is an alternative to repeated merging or rebasing: the test merge strategy. I’ll quote from a classic article[1] to describe it:

`The temptation to merge in the mainline during development can be hard to resist; one likes to know whether one’s work is even remotely relevant to the current state of the code. Fortunately, git makes it really easy to create throwaway branches and test out merges and integration there. Once it’s clear that things work, the test branch can be deleted and the (unmerged) development branch sent upstream.’

I will add here that in case of a merge conflict, you will have to do a bit of git-fu to resolve it on the topic branch while still avoiding a merge/rebase. But it is possible.

[1] http://lwn.net/Articles/328436/

Comment on 2013 Tracker Update – New Features, New API, New Design by Trey Bean

Trey Bean — Fri, 17 May 2013 22:10:52 +0000

We’d also love to be added to the beta list. So excited to see the new features you described!

Comment on Stop leaky APIs by Robbie Clutton

Robbie Clutton — Fri, 17 May 2013 15:28:16 +0000

Hey @yan, I haven’t come across Roar before but it looks pretty useful. Thanks for sharing.

Comment on Stop leaky APIs by In the News: 2013-05-16 | Klaus' Korner

In the News: 2013-05-16 | Klaus' Korner — Fri, 17 May 2013 14:20:45 +0000

[...] Programming News: Stop leaky APIs There are many blogs about how to expose an API for a Rails application and many times I look at this and am concerned about how these examples often leak the application design and the schema out through the API. When this leak occurs a change to the application internals can ripple out and break clients of an API, or force applications to namespace URI paths which I feel is unnecessary and ugly. Read full story => PivotalLabs [...]