A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."
Google's server is providing an incorrect pseudo-header field. Their response contains the pseudo-header field ':status' with the value '302 Found', in violation of the draft. The relevant section is Section 8.1.2.4 of the h2-14 draft, which reads:
A single ":status" header field is defined that carries the HTTP status code field (see [RFC7231], Section 6). This header field MUST be included in all responses, otherwise the response is malformed (Section 8.1.2.6).
HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line.
| class Object | |
| alias :"__send!__" :__send__ | |
| alias :send! :send | |
| def send(*args) | |
| puts "Nuh uh uh!" | |
| end | |
| alias :__send__ :send | |
| end |
During the PyLadies lunch here at PyCon, I heard 5 people stand up and say that they would not have given a talk if an individual (in many cases Jessica McKellar) hadn't pestered them repeatedly to give a talk. I saw later that someone else had heard this from 10+ people at the lunch.
Increasing speaker diversity is both about sending emails "to the right mailing lists" but it is also largely dependent on individuals reaching out to new (and veteran) speakers to get them to submit talks.
So - a lot of this work has to happen on multiple fronts at the same time - the CFPs need to go out to lots of lists, and individuals need to reach out to lots of individuals.
The only way I have seen this be consistently successful is if many people on the conference committee are all making individual requests to speakers, and the people making the requests are trusted by the talk submitters. It's a systemic issue involving visibility, trust, mentorship in general, talk submission mentoring, and mentorship of talk c
Dear Google,
I'd just like to thank you for disabusing me of the idea that JSON is under some requirement of well-formedness. I'd been labouring under the tyrannical misapprehension that some standards body had written down how JSON was supposed to work and that if I wanted to claim I was using JSON I would have to comply with that specification.
However, I today received a bug report indicating that a project to which I contribute was unable to make HTTP requests your Google Flights website could understand. I found this perplexing, but my eyes were opened when I saw your HTTP request. In particular, I enjoyed your freeform and inclusive definition of JSON. Allow me to show you what you've called JSON by showing you my SPDY request:
:host:www.google.fr
| #!/usr/bin/env python | |
| # | |
| # Licensed under the Apache License, Version 2.0 (the "License"); | |
| # you may not use this file except in compliance with the License. | |
| # You may obtain a copy of the License at | |
| # | |
| # http://www.apache.org/licenses/LICENSE-2.0 | |
| # | |
| # Unless required by applicable law or agreed to in writing, software | |
| # distributed under the License is distributed on an "AS IS" BASIS, |
| require 'mechanize' | |
| name = ARGV[0] # Email or Card Number | |
| pass = ARGV[1] # Password | |
| agent = Mechanize.new | |
| login = agent.get 'http://colectivocoffee.com/loyalty/member-login/' | |
| form = login.forms.first | |
| form.email_number = name |
| etamax_cassette = pytest.mark.betamax_cassette | |
| class TestGitHubAPI: | |
| def test_user(self, session, vcr): | |
| vcr.use_cassette('user') | |
| resp = session.get('https://api.github.com/user', | |
| auth=('user', 'pass')) | |
| assert resp.json()['login'] is not None |
Squid configuration:
http_port 3128
https_port 3129 cert=/usr/local/opt/squid/etc/ssl/squid.crt key=/usr/local/opt/squid/etc/ssl/squid.key
Test names:
The 'http_port' annotation indicates whether Squid HTTP port was used.
The 'https_port' annotation indicates whether Squid HTTPS port was used.