This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.
| package main | |
| import ( | |
| "context" | |
| "flag" | |
| "fmt" | |
| "log" | |
| "net/http" | |
| "os" | |
| "os/signal" |
| // ==UserScript== | |
| // @name Telegram dark theme / night mode | |
| // @namespace https://github.com/cacfd3a/ | |
| // @version 1.0 | |
| // @description Dark theme / night mode for Telegram Web | |
| // @author Maarten <maartentrompper@gmail.com> | |
| // @match https://web.telegram.org/* | |
| // @grant GM_addStyle | |
| // ==/UserScript== | |
| GM_addStyle('body { color: #fff;'); |
This gist was essentially created out of my own rant about Netflix being hostile to IPv6 tunnel services since June 2016. You are welcome to read my opinion on the matter, this is the more technical side to the issue and how to combat it within your own network.
Since I wrote this, various GitHub users have contributed their thoughts and ideas which has been incorporated into this gist. Thank you to everyone who have contributed their own methods and implementations.
Netflix now treats IPv6 tunnel brokers (such as Hurricane Electric) as proxy servers. A while ago it became apparent to users and Netflix that somewhat by accident, IPv6 tunnel users were being served content outside of their geolocation because of the way Netflix was identifyi
A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."
An update by Paul Johnston (paul@roundaboutlabs.com), for a Serverless Architecture scenario. This assumes something akin to AWS Lambda + API Gateway + DynamoDB (c. 2016) Function as a Service (FaaS) solution as the basis for deployment rather than a cloud-based virtual server approach which the original paper was based upon. The FaaS solution implies each function is separately scalable and the database is inherently partitioned (assuming designed/built well).
If you agree/disagree, please fork and share with me on twitter @pauldjohnston.
Currently, there is an explosion of tools that aim to manage secrets for automated, cloud native infrastructure management. Daniel Somerfield did some work classifying the various approaches, but (as far as I know) no one has made a recent effort to summarize the various tools.
This is an attempt to give a quick overview of what can be found out there. The list is alphabetical. There will be tools that are missing, and some of the facts might be wrong--I welcome your corrections. For the purpose, I can be reached via @maxvt on Twitter, or just leave me a comment here.
There is a companion feature matrix of various tools. Comments are welcome in the same manner.
| #!/usr/bin/env ruby | |
| # Usage | |
| # $ docker-machine create my-machine123 -d virtualbox | |
| # $ ruby <(curl -L https://git.io/vvvco) my-machine123 | |
| # https://gist.github.com/mattes/4d7f435d759ca2581347 | |
| require 'erb' | |
| bootlocalsh = %Q(#/bin/bash |
| # Set variables in .bashrc file | |
| # don't forget to change your path correctly! | |
| export GOPATH=$HOME/golang | |
| export GOROOT=/usr/local/opt/go/libexec | |
| export PATH=$PATH:$GOPATH/bin | |
| export PATH=$PATH:$GOROOT/bin |
Answering the Front-end developer JavaScript interview questions to the best of my ability.
Sometimes you need to delegate events to things.
this works in JavaScriptThis references the object or "thing" defined elsewhere. It's like "hey, thing I defined elsewhere, I'm talkin' to you."
| # 內容 | |
| # repo 位置 | |
| - https://github.com/facebook/react | |
| - https://github.com/facebook/flux | |
| # 官網 | |
| - React | |
| * http://facebook.github.io/react/ |