Pensieve

Pensieve, is my personal knowledge wiki where I plan to store my thoughts, ideas and notes.

Motive

For most parts, I’ve haven’t practised good note taking habits. Like most people, I’ve used notes as a bucket for scratch thoughts which eventually end up in a pile of notes. Andy Matuschack’s piece on Evergreen note-writing led me to create this infrastructure to publish my notes.

What’s a Pensieve?

The word Pensieve is borrowed from the world of Harry Potter by J.K. Rowling. It’s a magical object used to review memories. I’ll let Albus Dumbledore explain it -

I use the Pensieve. One simply siphons the excess thoughts from one’s mind, pours them into the basin, and examines them at one’s leisure. It becomes easier to spot patterns and links, you understand, when they are in this form.

Albeit personal knowledge, this is a public wiki and it intended to be viewed from non-participant, third-person point of view much like the Pensieve.

Setup

This wiki is made using mdBook and deployed using Netlify.

Other Similar Wikis/Notes

Notes of Andy Matuschak
Exobrain, by @karlicross
Braindump, by Jethro Kuan
nikitavoloboev’s wiki
Knowledge Repository, by rachelbrindle

Learning

Note Taking

It is important to write about what you read. This is mainly because understanding requires effortful engagement and writing forces sharper understanding.
Most note-writing practices are ephemeral and ineffective. People don’t want to forget an idea or thought, so they write it down on a note. Most notes systems offer poor feedback and most “storage-oriented” notes will never be useful again.
We should strive to design practices systems which yield compounding returns on our efforts as they accumulate over time. Evergreen note-writing helps in accumulating insights and thoughts.

Writing

Programming

Notes

Git

Git Cheatsheet

Amend Author Of Previous Commit

The author of the previous commit can be amended with the following command

 $ git commit --amend --author "Don Draper <ddraper@sterlingcooper.com>"

Accessing A Lost Commit

If you have lost track of a recent commit (perhaps you did a reset), you can generally still get it back. Run git reflog and look through the output to see if you can find that commit. Note the sha value associated with that commit. Let’s say it is 39e85b2. You can peruse the details of that commit with git show 39e85b2.

From there, the utility belt that is git is at your disposal. For example, you can cherry-pick the commit or do a rebase.

Caching Credentials

When public key authentication isn’t an option, you may find yourself typing your password over and over when pushing to and pulling from a remote git repository. This can get tedious. You can get around it by configuring git to cache your credentials. Add the following lines to the .git/config file of the particular project.

[credential]
    helper = cache --timeout=300

This will tell git to cache your credentials for 5 minutes. Use a much larger number of seconds (e.g. 604800) to cache for longer.

Alternatively, you can execute the command from the command line like so:

$ git config credential.helper 'cache --timeout=300'

source

Renaming A Branch

The -m flag can be used with git branch to move/rename an existing branch. If you are already on the branch that you want to rename, all you need to do is provide the new branch name.

$ git branch -m <new-branch-name>

If you want to rename a branch other than the one you are currently on, you must specify both the existing (old) branch name and the new branch name.

$ git branch -m <old-branch-name> <new-branch-name>

Resetting A Reset

Sometimes we run commands like git reset --hard HEAD~ when we shouldn’t have. We wish we could undo what we’ve done, but the commit we’ve reset is gone forever. Or is it?

When bad things happen, git-reflog can often lend a hand. Using git-reflog, we can find our way back to were we’ve been; to better times.

$ git reflog
00f77eb HEAD@{0}: reset: moving to HEAD~
9b2fb39 HEAD@{1}: commit: Add this set of important changes
...

We can see that HEAD@{1} references a time and place before we destroyed our last commit. Let’s fix things by resetting to that.

$ git reset HEAD@{1}

Our lost commit is found.

Unfortunately, we cannot undo all the bad in the world. Any changes to tracked files will be irreparably lost.

source

What Changed?

If you want to know what has changed at each commit in your Git history, then just ask git whatchanged.

$ git whatchanged

commit ddc929c03f5d629af6e725b690f1a4d2804bc2e5
Author: jbranchaud <jbranchaud@gmail.com>
Date:   Sun Feb 12 14:04:12 2017 -0600

    Add the source to the latest til

:100644 100644 f6e7638... 2b192e1... M  elixir/compute-md5-digest-of-a-string.md

commit 65ecb9f01876bb1a7c2530c0df888f45f5a11cbb
Author: jbranchaud <jbranchaud@gmail.com>
Date:   Sat Feb 11 18:34:25 2017 -0600

    Add Compute md5 Digest Of A String as an Elixir til

:100644 100644 5af3ca2... 7e4794f... M  README.md
:000000 100644 0000000... f6e7638... A  elixir/compute-md5-digest-of-a-string.md

...

This is an old command that is mostly equivalent to git-log. In fact, the man page for git-whatchanged says:

New users are encouraged to use git-log(1) instead.

The difference is that git-whatchanged shows you the changed files in their raw format which can be useful if you know what you are looking for.

See man git-whatchanged for more details.

Branching

Never put feature branches in the remote/origin/trunk.
Control access to new features with runtime configuration, not branching.

Feature Branches

Traditional: Create a branch for this feature in the remote, develop the feature on the branch over some period of time, then merge the entire branch back into master when complete.

Drawbacks:

You have to merge. Merging can be painful and error prone.
This aggregates risk into a single high-risk merge event at the end of development: both explicitly (everything is merged at once) and subtly (commits on the branch aren’t immediately available/so easier to hold them to a lower bar of quality).
When you have multiple feature branches, it’s impossible to test interactions between the features.
You generally can’t A/B test code in feature branches, can’t roll it out to a small percentage of uses, and can’t easily turn it on for just employees since it is in a separate branch.

Advantages:

Before the merge, no impact on production.

Advantages of not Feature Branching:

You don’t have to do merges.
Risk is spread out more evenly into a large number of small risks.
You can test interactions between features in development easily.
You can A/B test and do controlled rollouts easily.

Controlling Access to Features

Build a runtime configuration which defines which features are visible, based on the tier (dev, testing, prod), the logged in user, global config, A/B test groups, whatever else. It should look like this:

if (is_feature_launched('poke')) {
  show_poke()
}

Links

Recommendations on Branching

Writing Reviewable Code

Each commit should be as small as possible, but no smaller.
The smallest a commit can be is a single cohesive idea: don’t make commits so small that they are meaningless on their own.
There should be a one-to-one mapping between ideas and commits: each commit should build one idea, and each idea should be implemented by one commit.
Turn large commits into small commits by dividing large problems into smaller ones and solving the small problems one at a time.

If you’re developing a feature and run into a preexisting bug, stash/checkpoint your change, check out a clean HEAD/tip, fix the bug in one change, and then merge/rebase your new feature on top of your bug fix so you have two changes:

“Add feature x” + “Fix bug in y” > “Add features x and fix a bug in y”

Sensible Commit Messages

Commit messages should explain why you are making the change.

Have a title, describing the change in one line.
Have a summary, describing the change in more detail.
Maybe have some other fields.

Bad:

Allow dots in usernames

Change the regexps so usernames can have dots in them.

Good:

Allow dots in usernames to support Google and LDAP auth

To prevent nonsense, usernames are currently restricted to A-Z0-9. Now that
we have Google and LDAP auth, a couple of installs want to allow "." too
since they have schemes like "abraham.lincoln@mycompany.com" (see Tnnn). There
are no technical reasons not to do this, so I opened up the regexps a bit.

We could mostly open this up more but I figured I'd wait until someone asks
before allowing "ke$ha", etc., because I personally find such names
distasteful and offensive.

Some guidelines which are organization dependent:

If/where text is wrapped
Maximum length of the title
Whether there should be a period or not in the title
Use of voice/tense (”fix” vs “fixes”)

Links

Writing Reviewable Code

Rebase

Merge workflow: git commit, git pull, git push.

The problem with the merge workflow:

It has the potential disaster, because every merge and merge commit has to be handled correctly by every committer.
History become a mess. It has all kinds of inexplicable merge commits and the history (gitk) becomes useless.

Rebasing?

A branch is a separate line of work.
A public branch is one that more than one person pulls from.
A topical branch is a private branch that you alone are using.
A tracking branch is a local branch that knows where its remote is (???).

The fundamental idea of rebasing is that you make sure that your commits go on top of the public branch, that you rebase them so that instead of being related to some commit way back when you started working on this feature, they get reworked a little so they go on top of what’s there now.

Don’t do work on the public branch. Work on a topical or feature branch, as if it were a single patch you were applying.

$ git checkout origin master
$ git pull
$ git checkout -b my_feature
$ git fetch origin
$ git rebase origin/master
$ git checkout master
$ git rebase my_feature
$ git push

The fundamental idea is that I as a developer am taking responsiblity to make sure that my work goes right in on top of everybody else’s work. And it “fits” there--that it doesn’t requrie any magic or merge commits.

Since we are using rebase, we only plop out commits right on top, and then push. It does not change the public history.

Computer Science

Software Security

Blockchain & Cryptocurrency

Resources

Cryptography

Learn

Crypto 101 Course

Zero-Knowledge Proofs

Health & Fitness

🏃‍♂️Running

How long, realistically, would it take my 4 mile from from 45 min to sub 30 min?

What does the 30 minute run require? Physiologically, in order of importance:

Aerobic conditioning. Our oxygen-carrying system must be in top notch, from the lungs taking in oxygen, the heart pumping it into blood, and the working muscles picking up that blood and using it. This is simply the basis of performance for any distance runner.
Lactate Clearance. The ability of the muscles to clear waste products during activity. The more efficient our muscles are able to do this, the higher intensity we will be able to run at for 30 minutes.
Basic Speed. Which is the neuromuscular ability to run and maintain an efficient stride and leg turnover (we are not concerned about energy system demands here). While basic speed is not directly needed (because you can already run the 400m in 1:52), it is valuable to train for the following reasons: it improves your efficiency dramatically, making it easier to train and to race at given speeds. it reduces your risk of injury (making it easier to train consistently for a long period of time). and it takes very little effort and time to include basic speed training.

Aerobic Conditioning is improved by all distance running. Now, some people find this hard to believe, but your body does not know what a mile is. From a training stimulus perspective, it responds to duration and frequency.

Lactate Clearance is improved by running at an intensity that causes lactate buildup, stimulating muscles to clear waste products. We refer to this intensity as the lactate threshold. Truthfully, any intensity above the lactate threshold causes lactate clearance stimulus. But it is advantagous to us to run at the lowest intensity that causes lactate clearance stimulus, because we can run for a longer duration.

Basic Speed is trained by very short bursts of fast running, with very long recoveries so that the neuromuscular system is fully primed. Training the motor patterns of efficient running teach our body to run more efficiently at all intensities, and efficient running translates into both speed and lower risk of injury. But, we’re not going to head to the track and do specific speed workouts. Instead we are going to insert short repetitions called strides into some of our easy runs, so that we aren’t dedicating whole workouts to basic speed, and we also get the benefit of directly integrating these motor patterns into our easy running.

This nerd mumbo-jumbo aside, all training is about three things: frequency, duration, and intensity. Training creates a stimulus, the specifics of which are determined by the three key factors. You recover from the stimulus with adaptation. Our mission is to create the right stimulus for success at the task of the 30 minute run.

How do I get faster?

There are many factors that affect your speed, and you can spend many hours reading about this subject. The basic principles tend to be the same regardless of which specific distance you are training for. Things to consider include:

Base Building: Safely and steadily improving your mileage is often the first thing to consider. You can read more about this here, here ,here and here. Ensuring you have a solid foundation of plenty of miles should help you to avoid injury as you prepare for a race.
Quality: Once you are established in your running it is a good idea to incorporate some form of quality, whether that is hill sprints, intervals, or tempo runs. What sort of quality to include will depend on your goals. Read more here.
Lifestyle: Make sure you are getting a proper diet, are sufficiently hydrated, and get enough sleep. If you are under or overweight then addressing this may also help with your speed. Make sure that you are managing any medical conditions (e.g. asthma) appropriately and that you remain vigilant against any new injuries.
A good place to start would be this introduction by /u/HDRgument. It gives information on the main physiological factors affecting running performance, the training used to target those factors, and how to gradually build your training.

If you are ready to take your running to the next level and want to understand more about the principles behind training and getting faster, Daniels’ Running Formula is a good read.

How do I fix my form/footstrike?

The canonical bad running form looks something like this: slow cadence, long leaps, landing on a straight leg, ahead of your body, hands in front of your chest, upper body bent forward (slouching). What happens here is that the entire body weight, plus a good portion of the forward momentum you have, is jammed straight into the ground, and because the knee is straight and the hip muscles don’t engage properly, the impact force ends up hitting the bones and joints, all the way from the feet up into the hips and lower back, and even up the spine to the neck and head. Bones and joints are not built for this, so you will get in trouble with this. Now, typically this kind of running form combines with a pronounced heel strike; that’s because it is essentially a grotesquely scaled-out walking gait: you basically just lengthen your walking stride, add a bit of push-off to turn your steps into leaps, and that’s it. Forcing a forefoot strike will not change any of that; it might even make things worse, because one, you will be inclined to “reach out” with your toes, making the overstriding worse, and two, hitting the ground this way with the foot in an overextended position doesn’t help at all, it’ll just hurt the ankle joint more.

The proper solution is to forget about footstrike entirely, and instead work on a better overall gait. That means:

Short, quick, light steps, even (especially!) at slow paces.
“Run tall”: keep your head upright (imagine a string pulling your head up, like with a puppet), eyes on the horizon.
Relax, especially feet, ankles, arms, shoulders.
Bend the knees.
Keep your feet behind your body.
Use gravity to move forward: just slightly pushing the hips forward and down will have you effortlessly accelerate while staying completely relaxed. Practice this in the form of strides.
If in doubt, bend the knees more.

If you do all this right, you cannot possibly overstride, and rather than jamming impact forces into your knees and even losing a lot of energy by braking with every step, you will use your muscles and tendons to dynamically cushion the impact. It’s very likely that adjusting your form like this eventually leads to a forefoot strike, but if it doesn’t, don’t sweat it - as long as your steps are light and dynamic, it doesn’t matter at all.