Eric C taiyangc

Gmail and GitHub

How to filter emails from GitHub in Gmail and flag them with labels.

The labels in this document are just examples.

Pull Request

Filter	Label

Semantic Commit Messages

See how a minor change to your commit message style can make you a better programmer.

Format: <type>(<scope>): <subject>

<scope> is optional

Example

Overview

This gist is based on the information available at golang/dep, only slightly more terse and annotated with a few notes and links primarily for my own personal benefit. It's public in case this information is helpful to anyone else as well.

I initially advocated Glide for my team and then, more recently, vndr. I've also taken the approach of exerting direct control over what goes into vendor/ in my Dockerfiles, and also work from isolated GOPATH environments on my system per project to ensure that dependencies are explicitly found under vendor/.

At the end of the day, vendoring (and committing vendor/) is about being in control of your dependencies and being able to achieve reproducible builds. While you can achieve this manually, things that are nice to have in a vendoring tool include:

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.

Overview

Syncing an Ethereum node is largely reliant on latency of the storage. Budget SSDs will struggle to an extent, and some won't be able to sync at all. IOPS can roughly be used as a proxy of / predictor for latency. Measuring latency directly is arguably better.

This document aims to snapshot some known good and known bad models.

The drive lists are ordered by interface and then by capacity and alphabetically by vendor name, not by preference. The lists are not exhaustive at all. @mwpastore linked a filterable spreadsheet (legacy sheet) in comments that has a far greater variety of drives and their characteristics. Filter it by DRAM yes, NAND Type TLC, Form Factor M.2, and desired capacity.

For size, 4TB is a conservative choice which also supports a Fusaka "supernode". The

	/*
	* derivative work of Matheus de Oliveira's json_manipulator.sql
	* https://gist.github.com/matheusoliveira/9488951
	*
	* adapted to support postgresql 9.4 jsonb type
	* no warranties or guarantees of any kind are implied or offered
	*
	* license is as Matheus conferred it on 4/9/2015:
	* matheusoliveira commented on Apr 9
	* @hannes-landeholm, I'd like to take credit if you share them