Events
- Tuesday Brown Bag: Yehuda
Yehuda Katz will be giving a brown bag on Tuesday at 12:30.
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.
No answer.
https://github.com/thoughtbot/capybara-webkit#non-standard-driver-methods
Things like:
Our project needs OpenSSL > v1.0.0 because we’re trying to sign something with a DSA key. We asked on github and fifteen minutes later mpapis had pushed a change to make it configurable. That’s some of the best open source service out there.
If you declare any events in the events property of a initialize, they prevent your instance from being deleted/GC’d. Use an explicit destroy function that calls this.undelegateEvents()
If you look at the network graphs of heroku_san on github, you’ll see a number of branches where the only change is the deletion of the following line from the deploy task:
stage.migrate
If more than a few people are willing to take the effort to fork a gem just so they can delete 1 line, something smells. The reason is that these forkers were using something other than Rails+ActiveRecord+SQL in their project. Some were using Sinatra, others were using Rails, but with CouchDB.
The raison d’ĂȘtre for the heroku_san gem is to make Heroku deploys dirt simple. So, if people are making whole forks to customize the deploy task, we should make it less painful.
Strategies are an object oriented programming pattern for creating pluggable execution control. Now, there is a new class of objects that inherit from HerokuSan::Deploy::Base. These objects control how deploys are executed for you. The Rails strategy, HerokuSan::Deploy::Rails does exactly what HerokuSan has always done:
On the other hand, the Sinatra strategy, HerokuSan::Deploy::Sinatra does nothing more than the base strategy:
You can create your own strategies and then configure HerokuSan to use it instead of its default:
Amend your Rakefile:
require 'heroku_san'
class MyStrategy < HerokuSan::Deploy::Base
def deploy
super
# call my own code to do something unique
end
end
HerokuSan.project = HerokuSan::Project.new(Rails.root.join("config","heroku.yml"), :deploy => MyStrategy)
Amend your Rakefile
require 'heroku_san'
class MyStrategy < HerokuSan::Deploy::Base
def deploy
super
# call my own code to do something unique
end
end
config_file = File.join(File.expand_path(File.dirname(__FILE__)), 'config', 'heroku.yml')
HerokuSan.project = HerokuSan::Project.new(config_file, :deploy => MyStrategy)
load "heroku_san/tasks.rb"