Real unit test (isolation, no children render)
Calls:
- constructor
- render
require "redis" | |
worker_processes 8 | |
preload_app true | |
timeout 600 | |
listen '/tmp/vodeclic.sock', :backlog => 1024 | |
pid '/tmp/vodeclic.pid' | |
## | |
# REE |
ror, scala, jetty, erlang, thrift, mongrel, comet server, my-sql, memchached, varnish, kestrel(mq), starling, gizzard, cassandra, hadoop, vertica, munin, nagios, awstats
Attention: the list was moved to
https://github.com/dypsilon/frontend-dev-bookmarks
This page is not maintained anymore, please update your bookmarks.
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.
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:
#!/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? |
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...
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.