Wednesday, July 12, 2017

show all project code (a find-git-xargs example)

The following command finds all your project's Javascript files that aren't installed via NPM. It then does a "git blame" so you can see who wrote which bits of code, and how old the code is.

find . -path ./node_modules -prune -o -name '*.js' | xargs -n1 git blame --date=short --

If you're using OSX, install the GNU versions of the Unix tools

gfind . -path ./node_modules -prune -o -name '*.js' | gxargs -n1 git blame --date=short --

Those who don't understand Unix will be doomed to reimplement it. Poorly. :)

Tuesday, July 11, 2017

OSX: control-left/right moves by words in terminal

I use the three-finger-swipe to move viewports on OSX. Using control-left and -right to move by words in the terminal is VERY helpful!  Here's how to do it:

1) go into Preferences and disable control-left/right

2) add this to your ~/.bashrc file:

# control-left/right = skip by word in terminals
bind '"\e[5C": forward-word'
bind '"\e[5D": backward-word'
bind '"\e[1;5C": forward-word'

bind '"\e[1;5D": backward-word'

3) log out and back in to enable control-left/right to skip by words

hack day THIS SATURDAY in Santa Monica!

Next John Tells All Hack Day is this Saturday!
Bring a project (yours or open source), I'll talk about Python Iterators and Functional Programming for a while, then we'll work on stuff together.

Saturday, July 8, 2017

talk: APIs, Authorization, Authentication, Word Soup!

(This page is


Students learn a ton of webapp acronyms, and which are important.

Talk is now on Youtube!  Thanks to Wai-yin and Philosophie for sponsoring my being at the Coding for Product group.

"Can I hack my banking website with Curl?  Lil Bub wants to know!"

Friday, June 30, 2017

workshop: Zero to Webapp in Python

(This page is

Slides: Google Slides

Workflowy outline

GitHub source code

Web development is amazingly complicated. Can we get away with not learning that much?  John will do an interactive workshop on how to start with nothing and wind up with a working web app!


Students will learn how to write a tiny webapp without their brains exploding. NON-GOAL: we'll simplify the stack to exclude many things required for real projects. We won't cover classes, many types, modules, the debugger, nor testing. We might get to packages, virtual environments, and 3rd party modules like Flask. The intent of this workshop is to get something working with a minimum of magic.


* Python!
* HTML+CSS (a tiny amount)
* Bash shell (a little)

The goal is to deliver a simple working webapp, then refine it with small changes, each time understanding _why_. Students  become much more comfortable and confident with Python, the console, and web technologies in general.

Monday, June 26, 2017

John at work

I'm updating a class for Saturday, "Zero to Webapp in Three Hours", for non- or intro programmers. I just realized that all of the students have already learned most of the material!  So here's me updating the class:

re: hyperproductive development and debugging microservices

Story time.
At one company I've worked with, two guys knew the code completely cold. The other 5 devs only worked on bits and pieces, so it was difficult for them to have substantial discussions let alone valuable changes to the codebase. Visibility was further limited by there being no "end to end, production-like" stack. Each dev would run one component, developing and testing it always in isolation from the other components.
When I Am King(tm), all devs (and qa) will work on independent, production-like environments. They can beat the shit out of the entire system and get high-quality feedback on changes before it lands in production, where visibility is more awkward, and there are consequences.
For those people working with services, I mean microservices: check out Linkerd from the Cloud Native Computing Foundation (they host Kubernetes, Prometheus, and other valuable software). Linkerd allows services to be assembled from other services, with additional requirements. For example in production let's say service A calls service B. In environment "Staging", it would be configured to use (production) service A, but instead of A calling B, it would call the new version, B'. This allows "services" to be stitched up together easily. Another advantage is that B can be wrapped by another service C, allowing C to emit before/after messages and enabling further tracing. This allows service components to be safely debugged, even in production! This "remapping" feature can even be done on a per-request basis, allowing you to route and test services on the fly! Check it out.