Pivotal Labs » Danny Burkeshttp://pivotallabs.com
Agile DevelopmentTue, 03 Mar 2015 21:56:49 +0000en-UShourly1http://wordpress.org/?v=4.0Is Pair Programming Worth It?http://pivotallabs.com/pair-programming-worth/
http://pivotallabs.com/pair-programming-worth/#commentsThu, 09 Jan 2014 20:31:04 +0000http://pivotallabs.com/?p=25142Our COO, Edward Hieatt, was recently interviewed on the topic of pair programming, and why it is such a critical component of our software development process here. You can find the interview at http://www.airpair.com/pair-programming/, along with numerous quotes from current and former Pivots.

]]>A talk by Jacob Maine about collecting, analyzing and presenting very large amounts of data. Introduces the problems of big data, mentions some of the relevant technologies and gives a bit of advice about designing solutions.

]]>http://pivotallabs.com/big-data/feed/0Urban Dictionary: Recent Infrastructure Changes for Rails at Scalehttp://pivotallabs.com/urban-dictionary-recent-infrastructure-changes-for-rails-at-scale/
http://pivotallabs.com/urban-dictionary-recent-infrastructure-changes-for-rails-at-scale/#commentsWed, 30 May 2012 16:54:18 +0000http://pivotallabs.com/?p=11370Urban Dictionary is a Ruby on Rails application and the 109th most visited site in the country according to Quantcast. Today it runs entirely in the cloud — on Heroku, AWS and Akamai — and per-user costs are lower than ever. Founder Aaron Peckham discusses recent infrastructure changes to the site,aaa

]]>Urban Dictionary is a Ruby on Rails application and the 109th most visited site in the country according to Quantcast. Today it runs entirely in the cloud — on Heroku, AWS and Akamai — and per-user costs are lower than ever. Founder Aaron Peckham discusses recent infrastructure changes to the site, the costs and benefits of each change, and tricks to minimize risk while making changes to a large site.

]]>http://pivotallabs.com/urban-dictionary-recent-infrastructure-changes-for-rails-at-scale/feed/0Scaling Web Applications with MemCachierhttp://pivotallabs.com/scaling-web-applications-with-memcachier/
http://pivotallabs.com/scaling-web-applications-with-memcachier/#commentsWed, 23 May 2012 17:00:54 +0000http://pivotallabs.com/?p=11375Amit Levy introduces MemCachier, a scalable cache service for cloud hosted applications available now on Heroku. MemCachier seeks to relieve developers from worrying about provisioning and managing servers, allowing applications to scale up and down seamlessly. MemCachier also provides insights that help developers understand their cache behavior and how to cache moreaaa

]]>Amit Levy introduces MemCachier, a scalable cache service for cloud hosted applications available now on Heroku. MemCachier seeks to relieve developers from worrying about provisioning and managing servers, allowing applications to scale up and down seamlessly. MemCachier also provides insights that help developers understand their

]]>http://pivotallabs.com/scaling-web-applications-with-memcachier/feed/0Introduction to Darthttp://pivotallabs.com/introduction-to-dart/
http://pivotallabs.com/introduction-to-dart/#commentsWed, 16 May 2012 17:05:04 +0000http://pivotallabs.com/?p=11378Dart is more than a new structured web programming language. Google’s Dart Developer Advocate, Seth Ladd, talks about the philosophy and motivation for this new open source developer platform. There’s an overview of the language, libraries, and tools that help developers from all platforms build apps for the modern web.

]]>Dart is more than a new structured web programming language. Google’s Dart Developer Advocate, Seth Ladd, talks about the philosophy and motivation for this new open source developer platform. There’s an overview of the language, libraries, and tools that help developers from all platforms build apps for the modern web.

]]>http://pivotallabs.com/introduction-to-dart/feed/0Responsive Web Design From The Futurehttp://pivotallabs.com/responsive-web-design-from-the-future/
http://pivotallabs.com/responsive-web-design-from-the-future/#commentsWed, 04 Apr 2012 17:14:05 +0000http://pivotallabs.com/?p=11384Responsive web design is about a lot more than the size of your screen. Kyle Neath, Director of Design for GitHub, talks about about how GitHub handles links, the url bar, partial page updates, and explains why he thinks the HTML5 history API is the most important thing to happenaaa

]]>Responsive web design is about a lot more than the size of your screen. Kyle Neath, Director of Design for GitHub, talks about about how GitHub handles links, the url bar, partial page updates, and explains why he thinks the HTML5 history API is the most important thing to happen to front end development since Firebug.

]]>http://pivotallabs.com/responsive-web-design-from-the-future/feed/0DevOps for Developers: When the site goes down I should know what to dohttp://pivotallabs.com/devops-for-developers-when-the-site-goes-down-i-should-know-what-to-do/
http://pivotallabs.com/devops-for-developers-when-the-site-goes-down-i-should-know-what-to-do/#commentsWed, 07 Mar 2012 18:33:33 +0000http://pivotallabs.com/?p=11392Agile brings the idea that when designing a product, collaboration produces better results than conflict, but all too often a familiar us-vs-them war breaks out between developers and operations. Devops is a buzzword, but in reduction it means putting the people in charge of writing the code in charge ofaaa

]]>Agile brings the idea that when designing a product, collaboration produces better results than conflict, but all too often a familiar us-vs-them war breaks out between developers and operations. Devops is a buzzword, but in reduction it means putting the people in charge of writing the code in charge of keeping it running. Pivot Matthew Kocher attempts to convince you that you want to run your own site, and teaches you a little bit about how to do it.

Pivotal is proud to announce the release of the databasedotcom gem. Developed in partnership with Heroku and Salesforce, this gem wraps the Force.com REST API in familiar Ruby idioms, making it a snap to create web applications that integrate with your existing Salesforce instance, or even straight Ruby apps that do offline analysis of your Salesforce data.

I will be giving a session at Dreamforce on Tuesday, August 30, introducing the gem and demonstrating how easy it is to integrate into a Rails application. The session is entitled Building and Deploying Great Applications with Salesforce, Ruby, and Heroku, and takes place in Moscone West Room 2008 from 5:00 pm - 6:00 pm.

]]>Pivotal is proud to announce the release of the databasedotcom gem. Developed in partnership with Heroku and Salesforce, this gem wraps the Force.com REST API in familiar Ruby idioms, making it a snap to create web applications that integrate with your existing Salesforce instance, or even straight Ruby apps that do offline analysis of your Salesforce data.

I will be giving a session at Dreamforce on Tuesday, August 30, introducing the gem and demonstrating how easy it is to integrate into a Rails application. The session is entitled Building and Deploying Great Applications with Salesforce, Ruby, and Heroku, and takes place in Moscone West Room 2008 from 5:00 pm – 6:00 pm.

The Ugly Truth

On a recent project, we had an ActiveRecord model that declared some relationships and callbacks like so:

belongs_to :credit_card
before_create :build_credit_card

The intent was that build_credit_card would build the associated CreditCard instance, and ActiveRecord's default :autosave feature on the belongs_to would save it.

What we discovered was that no CreditCard object was being persisted. We confirmed that :autosave is on by default for belongs_to relationships, so we couldn't immediately understand why the new CreditCard wasn't being created.

Googling proved futile, so we dove right in to the ActiveRecord source- and boy did we have a good laugh about 10 minutes later.

What we found was that the :autosave option works by simply declaring a before_save callback- that makes perfect sense.

In our case, however, we were building the object to be autosaved in a before_create callback, which ActiveRecords runs after the before_save callbacks (cf. the callback ordering docs).

So our first problem was that we needed to move the call to build_credit_card from a before_create callback to a before_save :on => :create callback.

Did you catch that? There is a difference between before_create and before_save :on => :create. A big difference.

While I understand the how and why of this, the semantics don't make it obvious. So beware!

We ran our tests again, and, still, no love. Ahhh, we've still got an ordering problem. In addition to the ordering semantics detailed in the docs, ActiveRecord also runs callbacks within a single group in the order in which they are declared. So, even though we changed the call to build_credit_card to occur in a before_save, it was still occurring after the :autosavebefore_save callback, because of the declaration order.

On a recent project, we had an ActiveRecord model that declared some relationships and callbacks like so:

belongs_to :credit_card
before_create :build_credit_card

The intent was that build_credit_card would build the associated CreditCard instance, and ActiveRecord’s default :autosave feature on the belongs_to would save it.

What we discovered was that no CreditCard object was being persisted. We confirmed that :autosave is on by default for belongs_to relationships, so we couldn’t immediately understand why the new CreditCard wasn’t being created.

Googling proved futile, so we dove right in to the ActiveRecord source- and boy did we have a good laugh about 10 minutes later.

What we found was that the :autosave option works by simply declaring a before_save callback- that makes perfect sense.

In our case, however, we were building the object to be autosaved in a before_create callback, which ActiveRecords runs after the before_save callbacks (cf. the callback ordering docs).

So our first problem was that we needed to move the call to build_credit_card from a before_create callback to a before_save :on => :create callback.

Did you catch that? There is a difference between before_create and before_save :on => :create. A big difference.

While I understand the how and why of this, the semantics don’t make it obvious. So beware!

We ran our tests again, and, still, no love. Ahhh, we’ve still got an ordering problem. In addition to the ordering semantics detailed in the docs, ActiveRecord also runs callbacks within a single group in the order in which they are declared. So, even though we changed the call to build_credit_card to occur in a before_save, it was still occurring after the :autosavebefore_save callback, because of the declaration order.