$ uname -r
| import fetch from 'isomorphic-fetch' | |
| const setupRequestOptions = (options = {}, overrideMethod) => { | |
| if (overrideMethod) options.method = overrideMethod | |
| if (!options.headers) options.headers = {} | |
| options.credentials = 'same-origin' | |
| return options | |
| } | |
| const setupJsonRequestOptions = (options, overrideMethod) => { |
| It's easy to forget the task at hand. Moreso if like me you are easily distracted. I have a plan for my journey, even if that plan is not playing out on a timeline quite as aggressive as I'd like. Sometimes, though, sticking with the plan requires reminders. | |
| From the chain around my neck hangs a small token, serving to remind me of my plan. I mean that literally: it's a 1922 Pittsburgh Railways trolley token, redeemable (90 years ago) for a journey practically anywhere in the city. Most of my physical journeys these days turn out to be confined to Pittsburgh. This is surprising when you consider that it used to be nothing to me to drop what I was doing, get in the car and drive a couple hundred miles to hang out with someone, have dinner somewhere new or different, or visit some site of interest. It still happens (dim sum, a brew and the West Side Market in Cleveland, for instance) but moving somewhere that I can walk to so many places has ruined me for driving. It would be easy, as the world I experience re |
| SELECT | |
| DATE(bug_when), products.name, components.name, COUNT(*) | |
| FROM | |
| bugs_activity | |
| JOIN | |
| profiles ON who = userid | |
| JOIN | |
| components ON removed = name | |
| JOIN | |
| products ON components.product_id = products.id |
Know how the network clusters. Then when someone's reported, see how the clusters relate. Finding the source isn't too many hops. That'll help find the inciteful players -- the Milos, for example. It won't find people who organize in another medium, but are unrelated on Twitter. But second order analysis of who piles on connects them. Another mode of clustering.
In either case, be more suspicious based on (network) distance.
Then on the product design side: Make a way to separate users, and their first order follows. You report someone & computation checks it out as from a far cluster, and especially if it can find an inciting event? Just block those mentions. Like don't even let the tweet be posted. Gonna mention someone's username? Then you gotta not be a jackass.
It's reactive, mostly automated, but it takes reports seriously. It can eliminate the pile-on effect, especially if you run the algorithm proactively when someone's rate of mentions goes way up.
Also rate-limit non-conversational mentions b
| #!/bin/bash | |
| # Set up my PocketCHIP (Debian Linux) | |
| # NB It's recommended you set up ssh key auth before running this script | |
| # Extra tools -- edit this to suite what you want on your CHIP | |
| OPTIONAL_PACKAGES="vim-gtk git build-essential python-serial arduino arduino-mk" | |
| # Update | |
| # 1st lets fix an occasional but obscure problem during upgrade |
| import mechanize | |
| import boto3 | |
| import os | |
| sns=boto3.client('sns') | |
| phone_number='+13128675309' | |
| kms = boto3.client('kms', region_name='us-west-2') | |
| from base64 import b64decode | |
| CC_number=kms.decrypt(CiphertextBlob=b64decode(os.environ['CC_number']))['Plaintext'] |
Community Summit
Data-Driven Community Management
- Data-driven CM bores people
- So let's talk about fire
- Post-fire, they try to figure out why it happened
- Can they improve anything?
- Was it a crime?
- Post-fire, they try to figure out why it happened
- If something can be improved, is that actually done?