Hi there!
The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.
Please click on the link above to go to the cheat sheet.
{ | |
"defaultProfile": "{79285a8e-036c-446f-8a9c-78994e34bf85}", | |
"initialRows": 30, | |
"initialCols": 120, | |
"alwaysShowTabs": true, | |
"showTerminalTitleInTitlebar": true, | |
"showTabsInTitlebar": true, | |
"requestedTheme": "dark", | |
"profiles": [ | |
{ |
Hi there!
The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.
Please click on the link above to go to the cheat sheet.
#!/usr/bin/env perl | |
use feature 'switch'; | |
use strict; | |
use warnings; | |
use Data::Dumper; | |
use File::Basename; | |
use File::Copy; | |
use File::Path qw/make_path/; |
Over the last 3 years or so I've helped a bunch of companies, small and large, switch to Django. As part of that, I've done a lot of teaching Django (and Python) to people new to the platform (and language). I'd estimate I've trained something around 200-250 people so far. These aren't people new to programming — indeed, almost all of them are were currently employed as software developers — but they were new to Python, or to Django, or to web development, or all three.
In doing so, I've observed some patterns about what works and what doesn't. Many (most) of the failings have been my own pedagogical failings, but as I've honed my coursework and my skill I'm seeing, time and again, certain ways that Django makes itself difficult to certain groups of users.
This document is my attempt at organizing some notes around what ways different groups struggle. It's not particularly actionable — I'm not making any arguments about what Django should or shouldn't do (at least
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
from django.conf import settings | |
from django.core.signals import request_finished | |
from redis.client import Redis | |
database = Redis( | |
host=getattr(settings, "REDIS_HOST", "localhost"), | |
port=getattr(settings, "REDIS_PORT", 6379), | |
db=getattr(settings, "REDIS_DB", 0), | |
password=getattr(settings, "REDIS_PASSWORD", "")) |
import redis | |
from django.conf import settings | |
from django.core.signals import request_finished | |
try: | |
from eventlet.corolocal import local | |
except ImportError: | |
from threading import local |
# Config for Nginx to act as a front-end for Riak | |
# The main goal is to proxy all GETs directly to Riak, and disallow anything else (POST, PUT, etc) | |
# Also, disallow use of the map/reduce query links (i.e. /riak/bucket/key/_,_,_) | |
# Config is in /etc/nginx/sites-available/default or somewhere like that | |
# Set up load-balancing to send requests to all nodes in the Riak cluster | |
# Replace these IPs/ports with the locations of your Riak nodes | |
upstream riak_hosts { | |
server 127.0.0.1:8098; |