Piotr Monwid-Olechnowicz hasparus

Background: we've had a conversation about using full words vs. single letters in function names. One argument against using full words was that it leads to long, Java-like names like getPropertyFromDictionaryOptionCurried.

The problem

Long names like getPropertyFromDictionaryOptionCurried are bad not because they are made of full words. They are bad because they are saying too much.

If single letters read more naturally than full words, then this would be an improvement:

getPropertyFromDictionaryOptionC

Lost from https://blogs.msdn.microsoft.com/ericgu/2004/01/12/minus-100-points/

When I switched over the C# compiler team, I had hoped that I would be able to give some insight into how the design team works, what decisions we make, etc. Language design is a very esoteric field, and there's not a lot written about it (though “Design and evolution of C++“ is a pretty good read). I had hoped that I would be able to do this with concrete examples, as that makes it much easier.

I've been watching for candidate topics to write about, but haven't yet come up with any good ones. One of the problems is that features have a tendency to morph in design (and in whether they'll make it into Whidbey) as time goes by, and it would be bad for me to say, “we're talking about doing“ and then have us decide it wasn't a good idea. Or, for us to decide that doesn't fit into our schedule, or it would break existing code, or any of the other reasons that might cause us to pull a feature. We're generally not comfortable re

ANSI Escape Sequences

Standard escape codes are prefixed with Escape:

Ctrl-Key: ^[
Octal: \033
Unicode: \u001b
Hexadecimal: \x1B
Decimal: 27

Sequence of Gatsby's bootstrap lifecycle with links to source code as of v2.0.0

permalink https://github.com/gatsbyjs/gatsby/blob/ffd8b2d691c995c760fe380769852bcdb26a2278/packages/gatsby/src/bootstrap/index.js

open and validate gatsby-config (get-config-file.js) 1.5 load themes (swyx added this note July 2019)
load plugins (load-plugins/index.js) from the list given in gatsby-config.js
onPreBootstrap: runs onPreBootstrap if it is implemented in any plugins, for example gatsby-plugin-typography. Receives handy [apiCallArgs](https://github.com/gatsbyjs/gatsby/blob/ffd8b2d691c9

I made a little styling lib called glam

(some features are in development)

one

let's start off with the simplest use case. we'll make an 'index.html' page, and assume we've setup our js bundler to output bundle.js

curl \
  -H 'Content-Type: application/json' \
  -X POST \
  -d '{"text": "$TEXT", "mode": "markdown"}' \
  https://api.github.com/markdown

Don't use VPN services.

No, seriously, don't. You're probably reading this because you've asked what VPN service to use, and this is the answer.

Note: The content in this post does not apply to using VPN for their intended purpose; that is, as a virtual private (internal) network. It only applies to using it as a glorified proxy, which is what every third-party "VPN provider" does.

A Russian translation of this article can be found here, contributed by Timur Demin.
A Turkish translation can be found here, contributed by agyild.
There's also this article about VPN services, which is honestly better written (and has more cat pictures!) than my article.

Get Git log in JSON format

git log --pretty=format:'{%n  "commit": "%H",%n  "abbreviated_commit": "%h",%n  "tree": "%T",%n  "abbreviated_tree": "%t",%n  "parent": "%P",%n  "abbreviated_parent": "%p",%n  "refs": "%D",%n  "encoding": "%e",%n  "subject": "%s",%n  "sanitized_subject_line": "%f",%n  "body": "%b",%n  "commit_notes": "%N",%n  "verification_flag": "%G?",%n  "signer": "%GS",%n  "signer_key": "%GK",%n  "author": {%n    "name": "%aN",%n    "email": "%aE",%n    "date": "%aD"%n  },%n  "commiter": {%n    "name": "%cN",%n    "email": "%cE",%n    "date": "%cD"%n  }%n},'

The only information that aren't fetched are:

%B: raw body (unwrapped subject and body)
%GG: raw verification message from GPG for a signed commit

Commit Message Format

This specification is inspired by and supersedes the [AngularJS commit message format][commit-message-format].

We have very precise rules over how our Git commit messages must be formatted. This format leads to easier to read commit history.

Each commit message consists of a header, a body, and a footer.


	-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	-- --
	-- mysql --
	-- --
	-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

	--
	-- mysql <http://sqlfiddle.com/#!9/91afb5/2>
	-- note: sqlfiddle is very stupid