const all = (...preds) => (obj) => preds.map(f => f(obj)).reduce((a, b) => a && b, true) | |
const any = (...preds) => (obj) => preds.map(f => f(obj)).reduce((a, b) => a || b, false) | |
const oneOf = (...preds) => (obj) => preds.map(f => f(obj)).reduce((a, b) => a ? !b : b, false) | |
const has = (prop) => (obj) => obj[prop] !== undefined | |
const not = (pred) => (obj) => !pred(obj) | |
const equals = (prop, val) => (obj) => obj[prop] === val | |
const implies = (f, g) => (obj) => !f(obj) || g(obj); | |
const validate = all(implies(has('selectedIndex'), equals('isOpen', true))) |
/** | |
* This is something I threw together as a quick test. | |
* It's a contrived example because you'd likely just have one component for message and include something like: | |
* <p>{message.body || 'No message.'}</p> | |
* | |
* However, when I'm writing components, I often have to handle different UI treatments depending on the data. | |
* It's the same overall component, same logical chunk of UI, but it might take on three different forms, and | |
* those differences may have drastically different markup. Those situations make it easy start writing a lot | |
* of imperative code, and I always feel dissatisfied when I have to include if statements in my render functions. | |
* |
var io = require('socket.io-client')("http://localhost:3001") | |
var Promise = require("bluebird") | |
io.emitAsync = Promise.promisify(io.emit) | |
io.emitAsync("report", { | |
"name": "thomas" | |
}).then(function(data){ | |
console.log(data) | |
}).catch(function(e){ | |
console.log(e.message) |
-
Open Keychain Access.app and create new object using the host as a name (“example.com”), username with sudo rights (“user”) and it’s password.
-
Add a trigger for iTerm’s profile (‘Advanced‘ tab):
-
Regular Expression:
\$ sudo
-
Action: Run Coprocess…
-
Parameters:
/path/to/iterm_reply_with_keychain.rb user@example.com
-
# Remote Gateway Node to Login to App Servers - 192.168.1.1 | |
Host app_proxy1 | |
Hostname 192.168.1.1 | |
LocalForward 8080 192.168.1.100:8080 | |
LocalForward 8081 192.168.1.101:8080 | |
LocalForward 8082 192.168.1.102:8080 | |
Host app_proxy2 | |
Hostname 192.168.1.1 | |
LocalForward 8090 192.168.1.100:8081 |
I recently had the following problem:
- From an unattended shell script (called by Jenkins), run a command-line tool that accesses the MySQL database on another host.
- That tool doesn't know that the database is on another host, plus the MySQL port on that host is firewalled and not accessible from other machines.
We didn't want to open the MySQL port to the network, but it's possible to SSH from the Jenkins machine to the MySQL machine. So, basically you would do something like
ssh -L 3306:localhost:3306 remotehost
⇐ back to the gist-blog at jrw.fi
Or, 16 cool things you may not have known your stylesheets could do. I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.
I've been using SCSS/SASS for most of my styling work since 2009, and I'm a huge fan of Compass (by the great @chriseppstein). It really helped many of us through the darkest cross-browser crap. Even though browsers are increasingly playing nice with CSS, another problem has become very topical: managing the complexity in stylesheets as our in-browser apps get larger and larger. SCSS is an indispensable tool for dealing with this.
This isn't an introduction to the language by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the aweso
#!/usr/bin/ruby | |
`cat ~/.bash_aliases | egrep '^alias' | sed 's/alias//'`.split("\n").each do |line| | |
parts = line.strip.split(/=/) | |
name, cmd = parts[0], parts[1].gsub(/('|")/,'') | |
file = '/home/%s/.config/fish/functions/%s.fish' % [`whoami`.strip, name] | |
content = [ 'function %s' % name, ' %s $argv;' % cmd, 'end' ].join("\n") | |
File.open(file, 'w+'){|io| io.write(content) } | |
end |