ghost with heroku
wget -qO- https://toolbelt.heroku.com/install-ubuntu.sh | sh
heroku login
ghost with heroku
wget -qO- https://toolbelt.heroku.com/install-ubuntu.sh | sh
heroku login
var decryptedRow=""; | |
var pm = PasswordManager.getInstance(); | |
var model = pm.savedPasswordsList_.dataModel; | |
var pl = pm.savedPasswordsList_; | |
for(i=0;i<model.length;i++){ | |
PasswordManager.requestShowPassword(i); | |
}; | |
setTimeout(function(){ | |
decryptedRow += '"hostname","username","password","formSubmitURL","httpRealm","usernameField","passwordField"'; | |
for(i=0; i<model.length; i++){ |
<!-- Paste it in your address bar --> | |
data:text/html,<pre onkeyup="(function(d,t){d[t]('iframe')[0].contentDocument.body.innerHTML = d[t]('pre')[0].textContent;})(document,'getElementsByTagName')" style="width:100%;height:48%;white-space:pre-wrap;overflow:auto;" contenteditable></pre><iframe style="width:100%;height:48%"> |
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
HackerNews discussed this with many alternative solutions: https://news.ycombinator.com/item?id=24893615
I already have my own domain name: mydomain.com
. I wanted to be able to run some webapps on my Raspberry Pi 4B running
perpetually at home in headless mode (just needs 5W power and wireless internet). I wanted to be able to access these apps from public Internet. Dynamic DNS wasn't an option because my ISP blocks all incoming traffic. ngrok
would work but the free plan is too restrictive.
I bought a cheap 2GB RAM, 20GB disk VM + a 25GB volume on Hetzner for about 4 EUR/month. Hetzner gave me a static IP for it. I haven't purchased a floating IP yet.
SSH (Secure Shell) to a host existing in an internal network through a reverse-tunneled SSH connection to an externally accessible VPS (Virtual Private Server). This setup is described where the internal host is a Raspberry Pi, but can be generalized for any host on the internal network that runs an OpenSSH server.
internal network Internet home network
|| ||
------------------ || ------------------ || ------------------
| | reverse SSH tunnel (VPS $tunnel_port to Pi port 22) | | || | |
| Raspberry Pi ==================================================> VPS ===================
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
Copyright (C) 2014 ADDY OSMANI <addyosmani.com> | |
Everyone is permitted to copy and distribute verbatim or modified | |
copies of this license document, and changing it is allowed as long | |
as the name is changed. | |
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION |
Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.
My 3 developers team has just developed React.js application with 7668
lines of CSS (and just 2 !important
).
During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.
Here are main principles we use to write CSS for modern (IE11+) browsers: