After curl-ing for a while in a loop, and sort -u:
Anything added dilutes everything else.
Approachable is better than simple.
Avoid administrative distraction.
Design for failure.
Encourage flow.
Favor focus over features.
Half measures are as bad as nothing at all.
It's not fully shipped until it's fast.
Keep it logically awesome.
Mind your words, they are important.
Non-blocking is better than blocking.
Practicality beats purity.
Responsive is better than fast.
Speak like a human.
$ curl https://api.github.com/octocat
MMM. .MMM
MMMMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMMMM _____________________
MMMMMMMMMMMMMMMMMMMMM | |
MMMMMMMMMMMMMMMMMMMMMMM | Speak like a human. |
MMMMMMMMMMMMMMMMMMMMMMMM |_ _________________|
MMMM::- -:::::::- -::MMMM |/
MM~:~ ~:::::~ ~:~MM
.. MMMMM::. .:::+:::. .::MMMMM ..
.MM::::: ._. :::::MM.
MMMM;:::::;MMMM
-MM MMMMMMM
^ M+ MMMMMMMMM
MMMMMMM MM MM MM
MM MM MM MM
MM MM MM MM
.~~MM~MM~MM~MM~~.
~~~~MM:~MM~~~MM~:MM~~~~
~~~~~~==~==~~~==~==~~~~~~
~~~~~~==~==~==~==~~~~~~
:~==~==~==~==~~
You can also append `?s="your message here"` to use it to say something other than one of the GitHub Zen messages.
$ grep bofh .bash_aliases
alias bofh="nc bofh.jeffballard.us 666 | tail -n 1 | sed -e 's/Your excuse is: //'"
$ bofh
The air conditioning water supply pipe ruptured over the machine room
The comments below demonstrate that, while cute, virtually all of the statements it comes up with are entirely subjective, quite superficial, totally ambiguous, and useless for most things.
It grabs a random commit message from a github repo and displays it. By default, it pulls from a repo containing the original debian fortunes as commit messages. But you can point it to other repos like this:
Go has a weird subset of admin/programmer people who haven't discovered erlang and think they are too good for C.
Node has a weird subset of web people who haven't discovered erlang and think they are too good for deploying a message/job dispatch queue with python or ruby.
If you want to be really bored with all these "modern" programming advancements, learn erlang and lisp and smalltalk. Everything is just reinventing their aspects over and over and over again targeted to audiences as "new new new!"
I assume it's not a reference to responsive ("self-resizing") HTML, but rather things like user input lag (a common problem in apps.) Better to have a zero-lag async calculation than a nominally faster but UI-blocking synchronous calculation or request.
I think it's actually meant to encourage putting up things like spinners, page transitions, etc. Make the user feel that something is happening, and they won't feel slowed down.
I think the message is this: fast is an impossible standard to meet since there will always be inconsistent user experiences, so aim to be responsive before being fast.
I agree with it very much. When I'm zipping files on Linux and my system grinds to a halt due to hard drive contention, I don't want faster zip times, I just want the damn thing to be responsive while it zips in the background.
If you're running zip from the command line, try setting the priority with 'nice' when you run it. That should allow you to continue using your system while zip crunches away in the background. If you forget to set the priority level at runtime, use 'renice' to set the priority level of a running process.
