{{- range .Values.envs }}
{{ $version := index $.Values.traefikAPI .name "version" }}
{{ $replicas := index $.Values.traefikAPI .name "replicas" }}
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: traefik-api-ingress-controller
package main | |
import ( | |
"fmt" | |
"github.com/spf13/viper" | |
) | |
// Create private data struct to hold config options. | |
type config struct { |
-- Create a group | |
CREATE ROLE readaccess; | |
-- Grant access to existing tables | |
GRANT USAGE ON SCHEMA public TO readaccess; | |
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readaccess; | |
-- Grant access to future tables | |
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readaccess; |
// http://stackoverflow.com/questions/7279567/how-do-i-pause-a-window-setinterval-in-javascript | |
function RecurringTimer(callback, delay) { | |
var timerId, start, remaining = delay; | |
this.pause = function() { | |
window.clearTimeout(timerId); | |
remaining -= new Date() - start; | |
}; |
The intention of this document is to explore patterns of communication between can components and discuss possible improvements and newer patterns.
We should aim for:
- Making common scenarios easier
- Establishing best practices and canonical patterns
- Having as little surprise as possible, it should be clear from looking at the code exactly what the intention is
- Aligning with future standards, specifically try to align with web components as much as possible
package main | |
import ( | |
"image" | |
_ "image/gif" | |
_ "image/jpeg" | |
_ "image/png" | |
"io" | |
"mime" |
# Note (November 2016): | |
# This config is rather outdated and left here for historical reasons, please refer to prerender.io for the latest setup information | |
# Serving static html to Googlebot is now considered bad practice as you should be using the escaped fragment crawling protocol | |
server { | |
listen 80; | |
listen [::]:80; | |
server_name yourserver.com; | |
root /path/to/your/htdocs; |
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