Thanks to http://blog.nikosd.com/2011/11/github-flavored-markdown-in-yard.html
# Gemfile
group :development do
gem 'yard'
gem 'redcarpet'
GitHub.TreeSlider = function () { | |
if (window.history && window.history.pushState) { | |
function a() { | |
if (e.sliding) { | |
e.sliding = false; | |
$(".frame-right").hide(); | |
$(".frame-loading:visible").removeClass("frame-loading") | |
} | |
} | |
if (!($("#slider").length == 0 || !GitHub.shouldSlide)) if (!navigator.userAgent.match(/(iPod|iPhone|iPad)/)) { |
Install Passenger in Lion | |
http://electronicholas.com/2011/08/passenger-prefpane-1-5-for-mac-os-x-lion-10-7/passenger-prefpane/ | |
Enable web server in "Server App" | |
gem install passenger | |
rvmsudo passenger-install-apache2-module | |
copy commands from output to /etc/apache2/other/passenger.conf | |
Here's an example with ree@integrity gemset |
Thanks to http://blog.nikosd.com/2011/11/github-flavored-markdown-in-yard.html
# Gemfile
group :development do
gem 'yard'
gem 'redcarpet'
This script installs a patched version of ruby 1.9.3-p125 with patches to make ruby-debug work again (#47) and boot-time performance improvements (#66 and #68), and runtime performance improvements (#83 and #84). It also includes the new backported GC from ruby-trunk.
Huge thanks to funny-falcon for the performance patches.
I think that the approach @tenderlove has suggested to avoid monkey-patching MiniTest
(and the way MiniTest
works) means that to use Mocha
with MiniTest
, you would either need to include the Mocha
integration module into every test case, or define your own test case class inheriting from MiniTest::Unit::TestCase
.
This works well for Rails
(i.e. ActiveSupport
), because it already defines a new test case class (ActiveSupport::TestCase
) which is a suitable place to include the Mocha
integration module.
If we were to go down this route, in non-Rails Ruby projects you'd need to do one of the following...
#!/bin/bash | |
# License: Public Domain. | |
# Author: Joseph Wecker, 2012 | |
# | |
# -- DEPRICATED -- | |
# This gist is slow and is missing .bashrc_once | |
# Use the one in the repo instead! https://github.com/josephwecker/bashrc_dispatch | |
# (Thanks gioele) | |
# | |
# Are you tired of trying to remember what .bashrc does vs .bash_profile vs .profile? |
Locate the section for your github remote in the .git/config
file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@github.com:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
A slightly updated version of this doc is here on my website.
I visited with PagerDuty yesterday for a little Friday beer and pizza. While there I got started talking about Go. I was asked by Alex, their CEO, why I liked it. Several other people have asked me the same question recently, so I figured it was worth posting.
The first 1/2 of Go's concurrency story. Lightweight, concurrent function execution. You can spawn tons of these if needed and the Go runtime multiplexes them onto the configured number of CPUs/Threads as needed. They start with a super small stack that can grow (and shrink) via dynamic allocation (and freeing). They are as simple as go f(x)
, where f()
is a function.
Attention: the list was moved to
https://github.com/dypsilon/frontend-dev-bookmarks
This page is not maintained anymore, please update your bookmarks.
ror, scala, jetty, erlang, thrift, mongrel, comet server, my-sql, memchached, varnish, kestrel(mq), starling, gizzard, cassandra, hadoop, vertica, munin, nagios, awstats