If you’re looking for custom reporting and analytics for your projects, Easy Insight just added integration for Pivotal Tracker.
More details about how it works on the Easy Insight site.
How do I migrate paperclip attachments from one model to another?
A Pivot wants to do his civic duty of embracing change. This means refactoring his domain model to suit the emerging requirements of his product team. Unfortunately, this also means he has to move a paperclip attachment from one model to another. Paperclip does not appear to have a built in way to do this.
The opinion of the group was to use the brute-force solution: write some code to do the migration yourself. If you are using Amazon S3 for storage (which this project is), you can do an S3 ‘cp’ command to move the assets from one path to another. At the end, you can use the rake command ‘paperclip:refresh:thumbnails’ to re-generate the thumbnails.
If you want to do this by hand, cyberduck has a nice interface for batch re-naming of files on S3.
Amazon CloudFront now supports HTTPS
They also dropped their prices.
IE has a limit of 31 CSS files.
This has bitten many Pivots over the years. Your 32nd (and up) CSS file will be silently ignored.
Cappuccino is an open source framework for building browser-based apps. It is designed exclusively for building apps, not websites, which lets the framework focus on high-level tasks and specialized performance optimizations. Ross Boucher of 280 North, authors of Cappuccino, demonstrates the framework.
See all our talks at http://pivotallabs.com/talks
Our custom Chef recipe stopped working on EY cloud
We have some custom Chef recipes that we have been running on EY Cloud for some time. The code for these custom recipes was using the chef-deploy gem, which was apparently always available in the environment in which the recipe ran.
However, when we ran our recipe last week, it blew up trying to require the gem. We fixed this by removing the require and folding some of the code from the gem into our recipe.
There is a corresponding issue in the EY community forums:
The integration lets you easily pick a Tracker story from within RubyMine and create a task out of it. RubyMine tasks let you organize your work into different contexts. You can switch between tasks, and create source control changes based on them.
To use it, you’ll need a Tracker API token. Go to your My Profile page to get that.
Next, in RubyMine, go to Settings, and add a Pivotal Tracker task server (under Tasks/Servers). Use http://www.pivotaltracker.com for the URL, and enter your API token and Tracker project ID.
Note: This version of RubyMine sometimes hangs when trying to add a task server through the settings UI. As a workaround, you can edit the workspace.xml file, located in the .idea directory under your Rails root. Add the following under the element:
<servers> <PivotalTracker shared="false" url="http://www.pivotaltracker.com"> <option name="APIKey" value="YOUR_API_TOKEN" /> <password /> <option name="projectId" value="YOUR_PROJECT_ID" /> <option name="useHttpAuthentication" value="false" /> <option name="useProxy" value="false" /> <username /> </PivotalTracker> </servers>
Once the task server is configured, you can use the Switch to Task dropdown in the RubyMine tool bar to add a new task based on story in your Tracker project, or change between existing tasks.
You can optionally create a source control change based on the task, allowing you to preserve the story context all the way through to the commit.
If you’ve using Tracker’s post commit hook to automatically link commits to your stories, you can reformat the change description to match what Tracker expects (e.g. [completes #123456]) before you commit the change.
A common feature request from teams that have multiple projects on the go in Pivotal Tracker is the ability to move stories between projects. We’ve just added that feature.
To move a story, or a group of stories, select them first, using the selection check boxes to the right of story titles:
Then, select the ‘Move to Project…’ option in the Actions drop-down, and choose the project you’d like the story or stories moved to:
You should see a message that the stories were moved, and there should a history entry for the move as well, both in the source and destination project. Moved stories retain comments, tasks, attachments, as well as their own history of actions.
It’s also now possible to move stories to a project via the API. Simply do a story update, with the target project’s ID in the story’s element. More on that on the API help page.
Starting Jun 30, the Twitter API will no longer allow 3rd party applications (such as Tracker) to connect using your Twitter username and password. Instead, applications will be required to use OAuth, an authentication protocol that allows users to approve a 3rd party application to act on their behalf without sharing their username/password.
Pivotal Tracker now uses OAuth for project Twitter notifications. When you enable this feature for your project (see the integrations help page for more on that), you’ll be asked to sign in to Twitter (on the Twitter site), and give the Pivotal Tracker application permission to access your Twitter account.
If you have enabled Twitter notifications for your project(s) prior to this release, the stored credentials are in the username/password format. You’ll need to remove these old credentials, by clicking the ‘Remove Twitter Credentials’ button. After you’ve done that, click the ‘Sign In With Twitter’ button to re-enable the Twitter notifications using the new, more secure OAuth way.
More information on Twitter and OAuth can be found here.
Pivot Ryan Dy leads a discussion on upcoming HTML5 and CSS3 features. Ryan talks about how best to take advantage of the new features in the most modern browsers. Slides available at http://ryandy.com/html5
Cappuccino is an open source framework for building browser-based apps. It is designed exclusively for building apps, not websites, which lets the framework focus on high-level tasks and specialized performance optimizations.
Jose de Castro uses Rails and Sinatra to demonstrate the Tropo API for building real time communications apps. He discusses how media servers, SIP Servlets, and JRuby are used to create a standards-based stack for cloud communications.
A little while ago I wrote about Cedar, a BDD-style testing framework for Objective-C. The responses I received nearly all went something along these lines: “That’s great! Too bad I can’t use it, since I’m writing an iPhone app.”
I actually wrote Cedar specifically for testing iPhone OS projects we’re working on at Pivotal. To prove it, I’ve started a small public iPhone project that I’ve test-driven entirely with Cedar. You can get the project here (more on that in a bit); it should eventually allow you to log into Pivotal Tracker, see all the delivered stories in a given project, and accept or reject each one. At the moment it does little more than start up and display the Pivotal Chicken*, but it does contain Cedar specs that run on and off the device.
“How is this possible?” you ask. I’ve done two things to make this work:
I separated out all classes that don’t depend on UIKit into a target that builds a static library. The specs for this target run as a console app using the OS X runtime, so no need to worry about runtime support for blocks (assuming you’re running 10.6). Also no need to incur the overhead of starting the emulator every time you run tests. This is a pattern I started using ages ago to make automated testing easier on Win32 client applications, and it works great for all the mobile platforms I’ve worked on. Framework independence means faster tests, and faster tests mean happier programmers. I recommend doing this whether you’re interested in testing with Cedar or not.
Tests for the actual app, which does depend on UIKit and therefore must target the iPhone runtime, run on the emulator (or, in theory, a device) using the PLBlocks iPhone runtime for block support.
Getting the specs up and running takes a few steps, but as we all know good things come to those who wait.
Clone, or otherwise obtain the StoryAccepter project. It will probably have a number of missing library references.
You’ll need to build Cedar, both the dynamic framework (Cedar.framework) and the static iPhone library (libCedar-iPhone.a), as well as the OCHamcrest and OCMock frameworks. Fix the references in the StoryAccepter project to point to these libraries on your system.
If you’re running Leopard you’ll need to install PLBlocks 1.0 for Leopard, and you’ll need to include the runtime and set the compiler for both spec targets; the PLBlocks page has excellent instructions. If you’re running Snow Leopard the project should already contain the runtime, so you’ll just need to download and install the compiler for PLBlocks 1.0.1.
Select the DomainSpec target, and make sure you’ve selected the appropriate Mac OS X runtime for your system. Build and run; you should see dots appear in the console window as the specs run.
Select the StoryAccepterSpec target, and make sure you’ve selected an iPhone runtime (if you want to try running on a device you’ll have to set up the provisioning, of course). Build and run; the emulator should start up and try to run the app, which will simply run the specs and then exit. You should see dots in the console window, as before.
All of this still has some rough spots, especially the UIKit-dependent specs, but even so I’ve found test driving with hierarchical describe blocks far more pleasant than using OCUnit. Some things I hope to improve on:
I imagine the app that runs the UIKit-dependent specs showing a graphical display of test results, perhaps similar to what GHUnit displays when run on the emulator or device.
The iPhone doesn’t allow dynamic libraries, and I haven’t found a way to use OCHamcrest or OCMock for UIKit-dependent specs. The folks at Carbon Five describe using these libraries in their tests on the device; I’m curious to know how they pull that off.
Once iPhone SDK 4.0 comes out with support for blocks this should all work without the need for the PLBlocks runtime. That won’t help iPad development for the foreseeable future, though.
Full-stack integration testing à la Selenium.
Lots of other things. What would you like to see added to Cedar?
*Not an officially endorsed Pivotal mascot (yet).