| #! /usr/bin/python | |
| # | |
| # Church numerals in Python. | |
| # See http://en.wikipedia.org/wiki/Church_encoding | |
| # | |
| # Vivek Haldar <vh@vivekhaldar.com> | |
| # | |
| # https://gist.github.com/2438498 | |
| zero = lambda f: lambda x: x |
#System Design Cheatsheet
Picking the right architecture = Picking the right battles + Managing trade-offs
##Basic Steps
Visit my blog or connect with me on Twitter
git init
or
There are two modes when you don't want Certbot to edit your configuration:
Webroot is better because it doesn't need to replace Nginx (to bind to port 80) to renew certificates.
In the following, we're setting up mydomain.com to be served from /var/www/mydomain, and challenges will be served from /var/www/letsencrypt.
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
Service Worker - offline support for the web
Progressive apps - high-res icon, splash screen, no URL bar, etc.
Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.
This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
This gist will collects all issues we solved with Rails 5.2 and Webpacker
# Last few parameters(--skip-* part) is only my habbit not actully required
$ rails new <project_name> --webpack=stimulus --database=postgresql --skip-coffee --skip-test
Just documenting docs, articles, and discussion related to gRPC and load balancing.
https://github.com/grpc/grpc/blob/master/doc/load-balancing.md
Seems gRPC prefers thin client-side load balancing where a client gets a list of connected clients and a load balancing policy from a "load balancer" and then performs client-side load balancing based on the information. However, this could be useful for traditional load banaling approaches in clound deployments.
https://groups.google.com/forum/#!topic/grpc-io/8s7UHY_Q1po
gRPC "works" in AWS. That is, you can run gRPC services on EC2 nodes and have them connect to other nodes, and everything is fine. If you are using AWS for easy access to hardware then all is fine. What doesn't work is ELB (aka CLB), and ALBs. Neither of these support HTTP/2 (h2c) in a way that gRPC needs.