“Floated selects in Chrome don’t respond to mouseclicks ??” A: There was some speculation that the size of the clickable area of the element had collapsed to zero. The answer: “try display:inline-block”.
Gotcha: “CSS ellipses can change the output in Capybara and cause tests to fail.” There was a general reminder to everyone that ellipses don’t work in any version of Firefox.
Help: “What’s a good jquery placeholder plugin?” A: Placeheld
GoGaRuCo 2010 Videos are finally ready – yay! This was a quality conference, props to @joshsusser et al, each of these talks is worth your time.
File this under “things I wish I’d known about years ago”…
Do you use
delegate in Rails? It’s a great way to avoid Law of Demeter violations. Let’s say you’re modeling people, who belong to households:
class Person belongs_to :household delegate :address, to: household end class Household # has a string attribute 'address' end
Now we can get the address of a Person with the Demeter-friendly
person.address, rather than the trainwreck
When we decide suddenly that a person sometimes needs to override its
household’s address, we can change this to:
class Person belongs_to :household def address overriding_address || household.address end end
and we don’t have to change any code which refers to
But! What about this?
class Person # has a string attribute 'name' end class Business belongs_to :owner, class_name: 'Person' end
How do we get the name of a business’s owner? We could say
business.owner.name, but that’s a Demeter violation. We could delegate,
but then we’d have
business.name, which would be wrong. Luckily, the
delegate have thought of this:
class Business belongs_to :owner, class_name: 'Person' delegate :name, to: :owner, prefix: true end
prefix: true option gives us
business.owner_name, which is much
better. You can also specify a custom prefix instead of
After doing this manually by defining methods for years, I feel silly to
learn that the
prefix option has been around since 2008!
Rails 3 brings with it ActiveModel.
ActiveModel give you a way to make non-db backed models look like db backed models to your views and controllers. See this post for a good explanation of what using ActiveModel buys you.
ActiveModel gives you a great way to test that your class implements the minimum ActiveModel interface: ActiveModel::Lint::Tests
Check out this gist for the details for using these tests in RSpec:
If you’re using a Continuous Integration tool, you should also be using an information radiator like Pivotal Labs’ CiMonitor. CiMonitor is designed to be displayed on a screen that the entire team can see. If any of your builds go red, it shows up as a big red square and the team can quickly respond.
CiMonitor has long had support for CruiseControl.rb and Jenkins (formerly Hudson). However, my CI tool of choice is TeamCity from JetBrains. We’ve recently added native support in CiMonitor for displaying your TeamCity build status, and I want to show you how to get it going. It’s as easy as configuring a new project and pointing to TeamCity’s REST API. Let’s walk through it step by step.
For native TeamCity support, you’ll need to be on the latest version of CiMonitor. Follow the installation instructions on the CiMonitor GitHub page. If you already have CiMonitor installed locally, you’ll have to update to the latest version.
Create a New Project
Login to CiMonitor, and create a new project.
Choose “Team City Rest Project” as the Project Type.
For the Feed URL, you’ll be hitting the REST API provided by TeamCity 5.0 and newer. The correct format for the URL is as follows, with the # representing the TeamCity project number:
You can find the correct project number by clicking onto the project in TeamCity and looking in the URL. Grab the number from the buildTypeId parameter.
You will also need to fill in a TeamCity username and password that CiMonitor will use to access the REST API.
Once you’ve set up the new project, save it and you’re all set.
Watch Your Builds Run!
You can now easily see the status of your TeamCity builds.
CiMonitor will also show that a build is currently in progress.
The integration is pretty solid, but there are one or two things that may seem to be odd behavior.
CiMonitor keeps track of build start times to control the size of the build dots for each project. The older the build, the smaller the dot. Currently, TeamCity’s REST API doesn’t publish the start time of a running build. Since this data is unavailable, CiMonitor just uses the current time when it fetches the feed. This is a minor issue, and JetBrains has already committed a fix for their REST API which will be released in the next version of TeamCity. CiMonitor will use the new field if it’s present in the feed.
Also, TeamCity has a great feature that will tell you that a build is failing before it even finishes. This has an interesting effect on CiMonitor. If a TeamCity build is red, the next time it begins running, CiMonitor will show it as green until the first test fails. Once TeamCity picks up on a failure, CiMonitor will show the build as red. This can be a little confusing at first because it may look like a build-in-progress is green before it has finished.
Hopefully you find this new functionality useful!
can be frustrating in Rails as it tends to swallow the exception that caused it within your
template. A workaround is to wrap your template with
begin rescue end
temporarily for debugging.
JPB informed us of the existence of autolinking in Markdown, like so
resulting in http://pivotallabs.com
This code might not work like you expect:
it does not set the dirty bit, so
A workaround is to police yourself and use
before, well, changing the
without using the setter on
One of the thornier problems in our workflow is knowing when assets are delivered from the designer and keeping them in sync with our application as they change. We used to use e-mail, Skype or sticky notes. The trouble is that the designer’s file naming and directory structure were never quite the same as the application’s
/public/images directory, so direct comparisons were impossible and we ended with a lot bookkeeping to make sure that we didn’t lose any changes. Our solution is to clone the project’s git repository into a folder inside a shared Dropbox folder.
Dropbox is cheap, if not free, available on all platforms, and synchronizes easily across most network connections. git is, well, awesome version control. We already had a Dropbox account set up for the project, and all team members had accepted invitations to join the share. We then made a
git clone of our application source code in the Dropbox folder;
cd ~/Dropbox/MyProject git clone https://github.com/myproject/myapp git-repository
We took a minute or 2 to show the designer how to find the
images directory, and our basic rationale behind naming and directory structure. That became her “new” assets folder. We did not show the designer how to use git, nor do we need to. As far as she is concerned, it is just another folder.
/public/images is even a familiar place for designers.
Here’s where the fun starts: We add the Dropbox/git-repository as a
remote to our main project repository.
cd ~/myapp git remote add dropbox file:///Users/me/Dropbox/MyProject/git-repository
Now, as far as our main project is concerned, the Dropbox folder is another remote, just like github.
During our daily workflow, whenever we need a new asset, or to look for a changed one, we
cd over to the Dropbox folder with the git repository, change into the
/public/images directory and look for what we need. We then use
git add to stage and commit only those assets that we need. Back in our main project, we then
git pull dropbox master
from the Dropbox remote and voila! New images! Later, if the designer makes changes, we can simply run
git status to see what’s changed, re-run git add, commit and pull. The only really gotcha is training our fingers not to type
git commit -am '...'
We have found this to be a very fast, lightweight, way of integrating new assets into the project and keeping track of old ones. The designer is no longer worried about getting out of sync with our project, nor are we worried about missing design changes. As a bonus, there’s a history in the git logs, so we can review changes and even revert if necessary. All this without the designer ever learning a single git command, nor us worrying about our project directory getting accidentally clobbered.
[This is actually a very old trick that I've been using since the late 90's, but back then it was using CVS and NFS mounted shares!]
There are other benefits, too. Sometimes we’ll make minor fixes to the images delivered to us. By adding a remote to the Dropbox git repos, we can pull from our application master and then the designer gets our fixes.
cd ~/Dropbox/git-repository git remote add myapp file:///Users/me/my app
Remember, it’s just a git repos! You can alway revert or reset to previous versions. In the most terrible worst case, you delete the whole Dropbox directory and start “over,” that is, at the HEAD of the repository master on github (or whereever).
Ask for Help
No one has run into this specifically, but a few people said to make sure you’re mocking out Paperclip.
It was mentioned that Artifice is good for Selenium tests while Fakeweb and Webmock are good for rSpec tests. VCR’s got some fans as well. Sounds like you can’t go all that wrong whatever you choose.