| defmodule Day1P2 do | |
| @number_words %{ | |
| "zero" => 0, | |
| "one" => 1, | |
| "two" => 2, | |
| "three" => 3, | |
| "four" => 4, | |
| "five" => 5, | |
| "six" => 6, | |
| "seven" => 7, |
| # | |
| # This was created by smashing together two scripts. One from Gary Bernhardt and one from Small Labs. | |
| # | |
| # See also https://github.com/garybernhardt/dotfiles/blob/master/bin/git-churn | |
| # And http://www.smallmeans.com/notes/shell-history/ | |
| # | |
| git log --all -M -C --name-only --format='format:' "$@" | sort | grep -v '^$' | uniq -c | sort | awk '{print $1 "\t" $2}' | sort -g | awk '{print $1}' | uniq -c | sort -rn --stable | awk '!max{max=$1;}{r="";i=s=60*$1/max;while(i-->0)r=r"#";printf "%15s files changed %5d times %s %s",$1,$2,r,"\n";}' |
| $(function() { | |
| /* The JavaScript history API can be a pain. | |
| * | |
| * For example, if we navigate out to PayPal to | |
| * perform a payment, PayPal is now in the history | |
| * and all history.back() calls or back button | |
| * presses from then on might cause a back navigation | |
| * out of the app and back to paypal, confusing the | |
| * user with a PayPal error page. | |
| * |
| class IdempotentExample < RSpec::Core::Example | |
| # Copied from RSpec::Core::Example but modifed to run | |
| # the block without running before and after :each. | |
| # | |
| # Definitely needs work. | |
| # | |
| def run(example_group_instance, reporter) | |
| @example_group_instance = example_group_instance | |
| @example_group_instance.example = self |
This script installs a patched version of ruby 1.9.3-p194 with boot-time performance improvements (#66 and #68), and runtime performance improvements (#83 and #84). It also includes the new backported GC from ruby-trunk.
Many thanks to funny-falcon for the performance patches.
| # Jim Gay's new book, Clean Ruby (http://clean-ruby.com), has a section on dynamically binding | |
| # methods to objects with roles in a DCI context. He does this in a way that doesn't modify the | |
| # original object, unlike extending the object with a model does. I found the solution clever | |
| # but maybe a little bit unclear (but it's the first iteration of this part of the book, so I'm | |
| # sure it will become more convincing later :). | |
| # | |
| # This is an alternative to that solution which uses Module extension on a simple wrapper/decorator | |
| # object. The module's methods are added to the wrapper and it behaves as though the original object | |
| # has been extended with the role, but the original is untouched. I haven't really seen this solution | |
| # to the role extension problem anywhere else, but I'm sure I'm not the first to suggest it. |
| // Add this to user_extensions.js | |
| function withJQueryTriggers(proto, name) { | |
| var original = proto[name]; | |
| proto[name] = function(locator, value) { | |
| original.call(this, locator, value); | |
| if (locator.indexOf("css=") == 0) { | |
| var selector = locator.replace("css=", ""); | |
| LOG.info("triggering " + selector); |
| # From the app directory | |
| > heroku stack:migrate bamboo-mri-1.9.2 | |
| > git push heroku master |
| Assuming you have remote branch called heroku/master, start by creating a local tracking branch | |
| called heroku. | |
| > git checkout -b heroku -t heroku/master | |
| This will checkout the last revision you deployed to Heroku. | |
| Now tell git to push the heroku branch to heroku/master | |
| > git config remote.heroku.push heroku:master |