golang.org rate limiter:
rl := rate.NewLimiter(1000000, 1)
last := time.Now()
for i := 0; i < 10; i++ {
rl.Wait(context.Background())
cur := time.Now()
fmt.Println("last", cur.Sub(last))
last = cur
golang.org rate limiter:
rl := rate.NewLimiter(1000000, 1)
last := time.Now()
for i := 0; i < 10; i++ {
rl.Wait(context.Background())
cur := time.Now()
fmt.Println("last", cur.Sub(last))
last = cur
package main | |
import ( | |
"fmt" | |
"os" | |
"text/template" | |
) | |
type Person struct { | |
Name string |
package enum_example | |
import ( | |
"bytes" | |
"encoding/json" | |
) | |
// TaskState represents the state of task, moving through Created, Running then Finished or Errorred | |
type TaskState int |
// Compile with -DBOOST_TEST_NO_MAIN | |
// Link with -lboost_unit_test_framework | |
#define BOOST_TEST_DYN_LINK | |
#define BOOST_TEST_MODULE Test1 | |
#include <boost/test/unit_test.hpp> | |
#include <boost/test/parameterized_test.hpp> | |
#include <boost/bind.hpp> |
Exhaustive list of SPDX (Software Package Data Exchange) licenses: https://spdx.org/licenses/
/* Scrollbar */ | |
/* From Quassel Wiki: http://sprunge.us/iZGB */ | |
QScrollBar { | |
background: #131313; | |
margin: 0; | |
} | |
QScrollBar:hover { | |
/* Optional: Subtle accent of scrolling area on hover */ | |
background: #161616; /* base +2 */ | |
} |
Responding to requests via simple route matching is built in to Go's net/http
standard library package. Just register the path prefixes and callbacks you want invoked and then call the ListenAndServe
to have the default request handler invoked on each request. For example:
package main
import (
package router | |
import ( | |
"context" | |
"net/http" | |
gpath "path" | |
"github.com/julienschmidt/httprouter" | |
) |
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:
version: "3" | |
services: | |
db: | |
image: postgres:9.4 | |
deploy: | |
replicas: 1 | |
volumes: | |
- pgsql_data:/var/lib/postgresql/data:rw,Z | |
environment: |