Models | Examples |
---|---|
Display ads | Yahoo! |
Search ads |
var str = 'class ಠ_ಠ extends Array {constructor(j = "a", ...c) {const q = (({u: e}) => {return { [`s${c}`]: Symbol(j) };})({});super(j, q, ...c);}}' + | |
'new Promise((f) => {const a = function* (){return "\u{20BB7}".match(/./u)[0].length === 2 || true;};for (let vre of a()) {' + | |
'const [uw, as, he, re] = [new Set(), new WeakSet(), new Map(), new WeakMap()];break;}f(new Proxy({}, {get: (han, h) => h in han ? han[h] ' + | |
': "42".repeat(0o10)}));}).then(bi => new ಠ_ಠ(bi.rd));'; | |
try { | |
eval(str); | |
} catch(e) { | |
alert('Your browser does not support ES6!') | |
} |
Hi there!
The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.
Please click on the link above to go to the cheat sheet.
JD Maturen, 2016/07/05, San Francisco, CA
As has been much discussed, stock options as used today are not a practical or reliable way of compensating employees of fast growing startups. With an often high strike price, a large tax burden on execution due to AMT, and a 90 day execution window after leaving the company many share options are left unexecuted.
There have been a variety of proposed modifications to how equity is distributed to address these issues for individual employees. However, there hasn't been much discussion of how these modifications will change overall ownership dynamics of startups. In this post we'll dive into the situation as it stands today where there is very near 100% equity loss when employees leave companies pre-exit and then we'll look at what would happen if there were instead a 0% loss rate.
What we'll see is that employees gain nearly 3-fold, while both founders and investors – particularly early investors – get dilute
define(function(require) { | |
var React = require('react'); | |
var paramRegex = /__(\d)+/; | |
var parser = new DOMParser(); | |
var errorDoc = parser.parseFromString('INVALID', 'text/xml'); | |
var errorNs = errorDoc.getElementsByTagName("parsererror")[0].namespaceURI; | |
// turns the array of string parts into a DOM | |
// throws if the result is an invalid XML document. |
# Thanks to this post: | |
# http://blog.ikato.com/post/15675823000/how-to-install-consolas-font-on-mac-os-x | |
$ brew install cabextract | |
$ cd ~/Downloads | |
$ mkdir consolas | |
$ cd consolas | |
$ curl -O http://download.microsoft.com/download/f/5/a/f5a3df76-d856-4a61-a6bd-722f52a5be26/PowerPointViewer.exe | |
$ cabextract PowerPointViewer.exe | |
$ cabextract ppviewer.cab |
If you have already seen Richard Feldman's talk entitled "Making Impossible States Impossible" or have read "Designing with types: Making illegal states unrepresentable" then you can skip the explanations and just head straight to the Reason examples.
This post is intended to display how to model your Reason Application to prevent creating impossible states. The benefits of being able to design a feature in this way include avoiding having to deal with complex test scenarios regarding defined business rules and a clear documentation of what is possible just by looking at the type definition. Long story short, let's see how this all works by implementing an example.
local usbWatcher = nil | |
-- This is our usbWatcher function | |
-- lock when yubikey is removed | |
function usbDeviceCallback(data) | |
-- this line will let you know the name of each usb device you connect, useful for the string match below | |
hs.notify.show("USB", "You just connected", data["productName"]) | |
-- Replace "Yubikey" with the name of the usb device you want to use. | |
if string.match(data["productName"], "Yubikey") then | |
if (data["eventType"] == "added") then |
/** @jsx React.DOM */ | |
var Graphic = React.createClass({ | |
componentDidMount: function() { | |
var context = this.getDOMNode().getContext('2d'); | |
this.paint(context); | |
}, | |
componentDidUpdate: function() { |