| #!/bin/bash | |
| # require unzip | |
| UNZIP=$(which unzip) | |
| if [ $? -ne 0 ]; then | |
| echo "Error: requires unzip command" | |
| exit 1 | |
| fi | |
| # pull the first level dependencies from lein via some sed pain |
Short version: I strongly do not recommend using any of these providers. You are, of course, free to use whatever you like. My TL;DR advice: Roll your own and use Algo or Streisand. For messaging & voice, use Signal. For increased anonymity, use Tor for desktop (though recognize that doing so may actually put you at greater risk), and Onion Browser for mobile.
This mini-rant came on the heels of an interesting twitter discussion: https://twitter.com/kennwhite/status/591074055018582016
| (fn best-hand | |
| [hand] | |
| (let [ranks (map second hand) | |
| suits (map first hand) | |
| rank-freqs (sort (vals (frequencies ranks)))] | |
| (letfn [(flush? [hand] | |
| (apply = suits)) | |
| (straight? [hand] | |
| (let [straight-hands (set (map set (partition 5 1 [\A \2 \3 \4 \5 | |
| \6 \7 \8 \9 \T |
Logplex is the Heroku logging multiplexor. Components throughout the Heroku platform publish syslog packets that are received and processed by a grid of logplex nodes. Users may retrieve their logs through requests to the logplex API.
Logplex relies on channel, token, drain and session objects. This data is stored in redis, but also cached for fast lookups in a normalized format in ETS tables. When logplex boots, all of the keys are loaded from redis and cached in ETS. When an object is created or deleted through the logplex API, other logplex nodes are notified of the change (via Erlang rpc calls) so that they may update their local ETS cache. We would like to explore the possibility of using nsync to manage replicating the dataset into ETS. This would speed up logplex boot times and save us from making Erlang RPC calls to update local caches on remote nodes.
To get started, fork logplex on github and follow the directions below to get logplex running locally.
Once you are up and runni