Qt, the cross-platform system that Capybara-Webkit & PhantomJS use, does not get updated when you update the capybara-webkit gem.
So make sure you keep Qt up-to-date on your dev boxes and CI, and keep dev/CI in sync, for best performance and least pain.
E.g.,
$ brew install qt
$ gem uninstall capybara-webkit
$ bundle
Yes, someone actually wrote a [http://mattsears.com/articles/2011/11/16/nyan-cat-rspec-formatter] NyanCatFormatter
Bringing back the Pair eXchange and we need pivots to help show off the value of pair programming. The Meetup is full but any pivots who appear on the waiting list will get approved.
http://www.meetup.com/pivotal-labs-sf/events/67463192/
Our project was having trouble converting from MRI 1.9.3 to JRuby. We’re using OpenSSL to decrypt a string, which worked fine in MRI. However in JRuby the same code raised the error ” OpenSSL::Cipher::CipherError:
Given final block not properly padded”.
We discovered that OpenSSL on jRuby is stricter and you must set an initialization vector, e.g. cipher.iv = “ ” * 16
Join us for a sunday afternoon of devops talk and hacking. June 24th at the Pivotal Labs office.
XTC-SF is a new meetup held at Pivotal SF at 7pm, from Tuesday 19th June.
Inspired by the London group of the same name, topics include XP, TDD, mocking etc.
The first proposed topic is “How do we teach people to refactor to an architecture, or value an architecture at all?”
Informal discussion, pizza, beverages. All welcome.
Yehuda Katz will be giving a brown bag on Tuesday at 12:30.
suggestion: use Capybara error call back and a screen shot utility.
You can set parameters in the flash scope when redirecting:
redirect_to pants_path, :notice => “Successfully put on pants!”
redirect_to pants_path, :alert => “Pants are alight! Douse them forthwith!”
redirect_to pants_path, :flash => { :error => “What pants?” }
Don’t accidentally pass should_receive a method name as a string instead of a symbol. You’ll get a lovely ‘SystemStackError: stack level too deep’ error.
https://github.com/onsi/coccyx
coccyx is a tiny little addition to backbone that I cooked up that addresses finding and fixing memory leaks by solving two problems:
1) you can pass constructorName in as a parameter when defining your Backbone class to get a custom constructor name printed out (instead of “child”) in console.log and in Chrome’s heap analyzer.
2) you can call view.tearDown() to automatically unbind any callbacks attached to view.model, view.collection, and delegateEvents. You can also add a custom beforeTearDown handler to clean up any other references you might be aware of.
The best part is: if you registerSubView() as you add subviews then calls to tearDown on a root node will walk the subview hierarchy and clean the subviews up too.
If you’re in a controller action and you get there via a nested route, any path helpers you call automagically get the ID of the resource you’re nested under. The route helpers reverse-merge in the parameters of the request.
This means if you have these routes:
resources :magazines do
resources :ads
end
and you’re in an action in the ads controller, nested under magazine 5, you can do this:
edit_magazine_ad_path
without passing in a magazine object. It will pull magazine_id 5 out of the request parameters.
results in
[38, 39, 40, 41, 42, 43, 44]
As per ruby enumerable docs.
This is because grep uses threequel, which on a range is defined as inclusion. Answer courtesy of Giles Bowkett
“What are the reasons for using
to_svsto_strvsto_string“
Dave suggested to_string is for Java developers. Cathy will look into this more today and report back.
Em.Object.Prototype.jasmineToString() to return this.toString() fixed this.Phantomjs crashes randomly when running our test suite on CI, but not locally.
Possible leads:
Seen similar issues on Ubuntu but not on Mac.
Try building phantomjs from source.
There is a new way in rails 3 to turn off attr_accessible checks – just pass without_protection: true in as a parameter after your attrs. WTF.
I try to avoid writing static documentation. It gets old and out of date as soon as the next person comes along because it is logically far away from the code it describes, so event the best intended developers won’t always be aware of the documentation dependencies. Since working at Pivotal I’ve enjoyed writing tests first with RSpec, which results in one form of executable documentation to describe behavior to other developers working in the code base. But what about when you need to express behavior to people outside of your code base? Maybe your stakeholders have a company requirement of documentation, maybe you’re trying to entice third party developers to use your new HTTP API, or maybe you just want people to install your gem, what then? Your audience matters, and there’s a variety of tools out there to use depending on your needs.
Cucumber is one tool that can be used to fill this need. It’s designed to be a DSL for creating DSLs to describe your application. It has a nice attribute that it is very human readable. You can then use tools like Relish to publish docs from your Cucumber suite. The drawback is that you put a lot of effort in to expressing what you want in English, which is great if you’re really showing this to non-technical people, but it can be an over optimization if your readers have some technical context.
In the case where your audience is an outside developer, something like rspec_api_documentation might be more appropriate. It layers on a DSL to your familiar RSpec DSL that lends itself to HTTP APIs. This is great because your RSpec tests become more expressive without the overhead of defining the DSL yourself. From there, you run a rake task to generate HTML. Your spec runs will fail if your docs get out of sync, which should be never if you have CI. The web is an easy venue to consume this kind of information, but the tool doesn’t let you editorialize much beyond the description of the resource and the parameters.
One of our open source projects here at Pivotal Labs is Jasmine, a JavaScript testing framework that runs in the browser. Unlike Rspec where you need to have ruby installed and a database set up and so on, everyone has a browser. Check out the jasmine docs and scroll to the bottom. That’s right, the examples are tests, the comments are close to the tests so when the test fails you know to update the text as well, and now someone has a working example of how to use Jasmine all in one. The page itself is generated using Rocco, a Ruby port of Docco.With the combination of docs generated from tests, and tests that run in the browser you get this perfect blend of readable, easy to maintain documentation that is available to your entire audience.
Sometimes you have to provide documentation, but that doesn’t mean it has to be outdated. By creating executable documentation you can have confidence that the code and docs are staying in sync. Consider your audience carefully when choosing how you will document your software and know that there are more than a handful of options available, one of which will probably suit your task well.