Integralist

I'll explain how 'slices' work as best I can, but it might be worth also reading this official go post on the subject: https://blog.golang.org/go-slices-usage-and-internals (it has some nice visual aids too).

A 'slice' is a data structure abstraction around the 'Array' composite data type.

An array is a fixed size and can't be resized once it is full. A slice also cannot dynamically grow larger at runtime, we must create a new slice, and this requires the use of the appropriate builtin functions.

The reason we have to use the builtin append function is because the slice data structure includes a pointer to an array in memory. When appending more data than can be fit into the underlying array, the slice will copy the original array data to a new array and will return a new slice with an updated pointer.

So if you tried to append the values "a", "b" and "c" to a slice s li

Integralist

git log --author="Integralist" --date=iso | perl -nalE 'if (/^Date:\s+[\d-]{10}\s(\d{2})/) { say $1+0 }' | sort | uniq -c|perl -MList::Util=max -nalE '$h{$F[1]} = $F[0]; }{ $m = max values %h; foreach (0..23) { $h{$_} = 0 if not exist
s $h{$_} } foreach (sort {$a <=> $b } keys %h) { say sprintf "%02d - %4d %s", $_, $h{$_}, "*"x ($h{$_} / $m * 50); }'

On the BuzzFeed mono repo...

00 -    0
01 -    0

Integralist

Reference:
https://www.wired.com/2008/08/revealed-the-in/

There is an issue with BGP (Border Gateway Protocol). The issue exists because BGP's architecture is based on trust.

As an example, for e-mail from Sprint customers in California to reach Telefonica customers in Spain, networks for these companies and others communicate through BGP routers to indicate when they're the quickest, most efficient route for the data to reach its destination. But BGP assumes that when a router says it's the best path, it's telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic.

Here's how it works. When a user types a website name into his browser or clicks "send" to launch an e-mail, a Domain Name System server produces an IP address for the destination. A router belonging to the user's ISP then consults a BGP table for the best route. That table is built from announcements, or "advertisements," issued by ISPs and other networks – also known as Autonomous Syst

Integralist

package main

import (
	"fmt"
	"log"
	"net"
)

func main() {
	ipv4Addr, ipv4Net, err := net.ParseCIDR("10.0.0.0/8")

Integralist

alias tmd='transmission-daemon'
alias tmr='transmission-remote'
alias tmrw='watch -n 0.5 transmission-remote -l'
alias tmrsp='transmission-remote --torrent all --stop'
alias tmrst='transmission-remote --torrent all --start'

Integralist

Make the changes

    Create a new branch in git
    Make the changes behind a feature flag
    Run unit tests to validate your changes with the feature flag both on and off

Pull request

    Commit the changes
    Push the changes to a remote on github

Integralist

# It's a good idea to add as many 'trackers' as you can for a specific torrent.
#
# With transmission cli you use:
# --tracker-add "<url_of_tracker>"
#
# Don't forget to make sure you add the tracker to the correct torrent:
# -t <torrent_number>
#
# Usage:
# ./tracker.sh <torrent_number>

Integralist

type A struct {
    mu sync.Mutex
}

a := &A{}

a.mu.Lock()
defer a.mu.Unlock()

a.Something()

Integralist

Build Tags

File: a/a.go

// +build !mock

package a
func DoSomething() {
    return "done"

Integralist

Background

There are two common techniques for implementing slow, controlled deployments, namely canary deployments and blue-green deployments. Both techniques are effective if used properly. This document makes no effort to argue for/against either of these methods.

Canary Deployments

Canary deployments are a technique to reduce the risk of introducing new software versions into production by slowly rolling out the change to a small subset of traffic before rolling it out to the entire infrastructure. As the operator gains confidence in the new version, they can start releasing it to more servers/instances in your infrastructure, and thus routing more traffic to it. Canary deployments last until all traffic has been routed to the new version. If the operator finds any problems with the new version, the rollback strategy is simply to redeploy the old version on the small subset of services/instances until the problem has been resolved.

Blue Green Deployments

Blue-green deployments approach slow an