I've taken the benchmarks from Matthew Rothenberg's phoenix-showdown, updated Phoenix to 0.13.1 and ran the tests on the most powerful machines available at Rackspace.
Framework | Throughput (req/s) | Latency (ms) | Consistency (σ ms) |
---|
make_wrq(Method, RawPath, Headers) -> | |
{ok, Dispatch} = file:consult(filename:join( | |
[filename:dirname(code:which(?MODULE)), | |
"..", "priv", "dispatch.conf"])), | |
R0 = wrq:create(Method, {1,1}, RawPath, mochiweb_headers:from_list(Headers)), | |
R1 = wrq:set_peer("127.0.0.1", R0), | |
{_, _, HostTokens, Port, PathTokens, Bindings, AppRoot, StringPath} = | |
webmachine_dispatcher:dispatch(RawPath, Dispatch, R1), | |
wrq:load_dispatch_data(Bindings, | |
HostTokens, |
require 'openssl' | |
def gen_key(name) | |
key = OpenSSL::PKey::RSA.new 1048 | |
file = File.new(name, "w") | |
file.write(key) | |
file.close | |
end | |
def get_key(name) |
#!/usr/bin/env python3 | |
import http.client | |
import ssl | |
import urllib.parse | |
def boxcarpush(): | |
# Prepare the notification parameters | |
params = urllib.parse.urlencode({ |
-module(channels). | |
-compile(export_all). | |
make() -> | |
Ref = make_ref(), | |
Pid = spawn(?MODULE, channel, [Ref]), | |
{channel, Pid, Ref}. | |
channel(Ref) -> | |
receive |
I've taken the benchmarks from Matthew Rothenberg's phoenix-showdown, updated Phoenix to 0.13.1 and ran the tests on the most powerful machines available at Rackspace.
Framework | Throughput (req/s) | Latency (ms) | Consistency (σ ms) |
---|
$ ssh -A vm
$ git config --global url."git@github.com:".insteadOf "https://github.com/"
$ cat ~/.gitconfig
[url "git@github.com:"]
insteadOf = https://github.com/
$ go get github.com/private/repo && echo Success!
Success!
Tested with Apache Spark 1.3.1, Python 2.7.9 and Java 1.8.0_45 + workaround for Spark 1.4.x from @enahwe.
Download and install it from oracle.com
This gist is based on the information available at golang/dep, only slightly more terse and annotated with a few notes and links primarily for my own personal benefit. It's public in case this information is helpful to anyone else as well.
I initially advocated Glide for my team and then, more recently, vndr. I've also taken the approach of exerting direct control over what goes into vendor/
in my Dockerfiles, and also work from
isolated GOPATH environments on my system per project to ensure that dependencies are explicitly found under vendor/
.
At the end of the day, vendoring (and committing vendor/
) is about being in control of your dependencies and being able to achieve reproducible builds. While you can achieve this manually, things that are nice to have in a vendoring tool include:
-------------------------------------------------- | |
-------------------------------------------------- | |
-- Import tasks from Things to OmniFocus | |
-------------------------------------------------- | |
-------------------------------------------------- | |
-- | |
-- Script taken from: http://forums.omnigroup.com/showthread.php?t=14846&page=2 && https://gist.github.com/cdzombak/11265615 | |
-- Added: OF3 & Things 3 compatibility; task order; areas/folders; tags | |
-- Empty your Things Trash first. | |
-- |