DEV Community: Mihail Malo

Setting up git+ssh+gpg on Windows

Mihail Malo — Sun, 24 Feb 2019 18:23:50 +0000

Sometimes we all end up having to use Windows.
I was trying to avoid this, but it sneaks up on you.
So, how does one set up basic git with SSH authentication and GPG commit signing, for VS Code and command line?
Maybe I was spoiled by Linux community documentation, but I basically didn't get an answer. So, today we investigate!

Not in scope: We won't be:

generating the SSH identity with ssh-keygen -t rsa -b 4096 -C "YOUR.ACTUAL@MAIL.HERE"
or GPG key with gpg --generate-key,
nor adding them to https://github.com/settings/keys.

This article assumes you want to use your existing keys. But all these are well-documented. If you disagree and would like me to post a writeup on those, please leave a comment.

We will be using scoop instead of chocolatey, so that our setup is unprivileged and confined to the local user.

We'll assume you don't have anything installed.
So let's open up PowerShell (not as administrator) and begin:

Scoop

# Enable powershell executables
Set-ExecutionPolicy RemoteSigned -scope CurrentUser
# Install scoop
iex (new-object net.webclient).downloadstring('https://get.scoop.sh')

# scoop uses aria2 for parallel downloads
scoop install aria2

Git

scoop install git

Now, if you are on Windows 10 and don't follow Windows news,
run ssh -V and prepare to be shocked.
Since April 2018, Windows ships with OpenSSH!

some reports indicate that you may have to activate the feature as follows (I didn't have to):
Add-WindowsCapability -Online -Name OpenSSH.Client*

Since we are going for a minimal setup here, we will not install our own version.
We still have to add an environmental variable for git to start using it, though:

Don't forget to restart PowerShell / VS Code or wherever you plan to use git after this to load the environmental variable.

Now, let's continue configuring git:

git config --global user.name "YOUR ACTUAL NAME HERE"
git config --global user.email YOUR.ACTUAL@MAIL.HERE

Let's print the config to verify, it should look something like this:

git config -l --global
# user.email=YOUR.ACTUAL@MAIL.HERE
# user.name=YOUR ACTUAL NAME HERE
# credential.helper=manager

Now, let's add our actual key to ssh:

ssh-add YOUR\KEY\PATH\id_rsa

Note: If your key is located at ~/.ssh/id_rsa, and you have pshazz installed, you can (re)open a powershell, and pshazz will run ssh-add, adding it automatically (this will prompt you for the passphrase if you have one). I don't find it particularly valuable to keep your key there on Windows, so you can ssh-add it and then remove the file.

Now, assuming you will be using GitHub (similar for gitlab et al.), let's do a test connection (and save GitHub's signature, otherwise VS Code will get confused and silently fetch forever):

ssh -T git@github.com
# The authenticity of host 'github.com (192.30.253.112)' can't be established.
# RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
# Are you sure you want to continue connecting (yes/no)? yes
# Warning: Permanently added 'github.com,192.30.253.112' (RSA) to the list of known hosts.

At this point, we have working git, but the commits will not get signed yet.

GPG

Now, the git package comes with a gpg executable, at:

# It's my first time writing powershell, any advice welcome
join-path (scoop prefix git) 'usr\bin\gpg.exe'

Let's temporarily alias it to gpg!

sal gpg (join-path (scoop prefix git) 'usr\bin\gpg.exe')

Aside: sal is an alias (wow, much meta) for Set-Alias.
But according to alias alias, alias isn't an alias for Get-Alias? 🤔🤔🤔

In my case it's a slightly older version than is available standalone.

scoop info gpg
gpg --version

But, once again, we're going for a minimal setup.
So, let's just jam our key right on in there.

# Enable signing all commits by default
git config --global commit.gpgsign true

Now, let's import our key:

gpg --import C:\YOUR\KEY\LOCATION\_SOMETHNG_-private.{key,gpg}

You may also want to ultimately trust your key:

$(echo trust; echo 5; echo y; echo quit) | gpg --command-fd 0 --edit-key YOUR.ACTUAL@MAIL.HERE

It is fine to remove your key file after this, it was imported into the gpg install.

Finally, let's install some more packages:

# the default bucket doesn't include GUI applications such as VS Code
scoop bucket add extras

# check for (self)updates
scoop update
scoop update *

# install the good nice things
scoop install vscode pshazz

🎉 We are done! 🎉

The result should look like this:

git config -l --global
# user.email=YOUR.ACTUAL@MAIL.HERE
# user.name=YOUR ACTUAL NAME HERE
# credential.helper=manager
# commit.gpgsign=true

gpg -K
# C:/Users/YOUR_NAME/AppData/Roaming/gnupg/pubring.kbx
# ------------------------------------------------
# sec   rsa4096 2017-10-18 [SC]
#       8E84465BB27D2E97F5B379C0D41763D409EF23A0
# uid           [ultimate] YOUR ACTUAL NAME HERE <YOUR.ACTUAL@MAIL.HERE>
# ssb   rsa4096 2017-10-18 [E]

To test signing, make a commit:

git init git-signature-test
pushd git-signature-test
echo "" > butts
git add butts
git commit -m Init
git log --show-signature
popd
rm -r -fo git-signature-test

The output should include "Good signature from" followed by YOUR ACTUAL NAME HERE <YOUR.ACTUAL@MAIL.HERE>.

Edit: It seems like we installed the whole scoop mostly just to get git :)
Originally this article included installing your own OpenSSH and GPG, and even something from chocolatey, but after reading GitHub issues and experimenting, it turned out that just this is plenty. 🎉

Is nodejs v11 faster than v6

Mihail Malo — Wed, 13 Feb 2019 15:44:03 +0000

This article doesn't aim to present a benchmark that is representative of anyone's real world application (hopefully).
Just a little something provoked by this comment.
It doesn't answer the titular question in a useful way.
If you have any useful comparisons you would like me to link to, please leave them in the comments.

Seriously, this should not at all inform your upgrade decisions.

Our "code"

Let's run a simple test:

"use strict"
for (let i = 0; i < 10; i++) {
  let arr = ["a single pickle"]
  for (let i = 0; i < 25600000; i++) arr = [arr]
  console.log(i)
}

Results

Let's start ridiculously far back:

$ nvm use 1 && time node scrap.js 
Now using io.js v1.8.4 (npm v2.9.0)

real    0m38.984s
user    0m36.885s
sys     0m3.073s

nodejs v4: Oh yeah, an improvement!

$ nvm use 4 && time node scrap.js 
Now using node v4.9.1 (npm v2.15.11)

real    0m21.040s
user    0m18.836s
sys     0m2.834s

nodejs v6:

$ nvm use 6 && time node scrap.js 
Now using node v6.16.0 (npm v3.10.10)

real    0m23.870s
user    0m24.297s
sys     0m2.902s

nodejs v8: Back to v4 performance, awesome!

$ nvm use 8 && time node scrap.js 
Now using node v8.15.0 (npm v6.7.0)

real    0m21.562s
user    0m23.256s
sys     0m2.839s

nodejs v9: (You'll see why this non-LTS is tested in a moment)

$ nvm use 9 && time node scrap.js 
Now using node v9.11.2 (npm v5.6.0)

real    0m19.989s
user    0m21.716s
sys     0m2.990s

nodejs v10.0.0: Oh no, what happened?

$ nvm use 10.0.0 && time node scrap.js 
Now using node v10.0.0 (npm v5.6.0)

real    1m14.604s
user    1m22.655s
sys     0m3.232s

nodejs v10: That's even worse!

$ nvm use 10 && time node scrap.js 
Now using node v10.15.0 (npm v6.6.0)
0

<--- Last few GCs --->
e [22823:0x29e79b0]    18607 ms: Mark-sweep 1278.0 (1334.2) -> 1278.0 (1303.2) MB, 1849.1 / 0.0 ms  (+ 0.0 ms in 69 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1875 ms) (average mu = 0.075, current mu = 0.052) allocati[22823:0x29e79b0]    20618 ms: Mark-sweep 1339.5 (1365.7) -> 1339.5 (1365.7) MB, 1900.1 / 0.0 ms  (+ 0.0 ms in 5 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1965 ms) (average mu = 0.064, current mu = 0.055) allocatio

<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x39c8186dbe1d]
Security context: 0x363e2bf1e6e1 <JSObject>
    1: /* anonymous */ [0x2b128b88e9f1] [/home/mihail/Documents/Development/zigbee/zcl-packet/src/scrap.js:~1] [pc=0x39c81876f729](this=0x2b128b88eb21 <Object map = 0x389f21f02571>,exports=0x2b128b88eb21 <Object map = 0x389f21f02571>,require=0x2b128b88eae1 <JSFunction require (sfi = 0x170c23bc6179)>,module=0x2b128b88ea59 <Module map = 0x389f21f50c21>,__filen...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x8db900 node::Abort() [node]
 2: 0x8db94c  [node]
 3: 0xad6c1e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xad6e54 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xec44e2  [node]
 6: 0xec45e8 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [node]
 7: 0xed06c2 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
 8: 0xed0ff4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 9: 0xed3c61 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [node]
10: 0xe9d0e4 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [node]
11: 0x113c9db v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object**, v8::internal::Isolate*) [node]
12: 0x39c8186dbe1d 
Aborted (core dumped)

real    0m22.973s
user    0m25.113s
sys     0m0.655s

Same, but after reducing array depth to 25500000: Noticeably slower than v10.0.0, even with less work to do!

$ nvm use 10 && time node scrap.js 
Now using node v10.15.0 (npm v6.6.0)

real    1m49.499s
user    2m0.444s
sys     0m3.553s

Bumping it back up to 25600000, nodejs v11: Well, at least it didn't crash

$ nvm use 11 && time node scrap.js 
Now using node v11.9.0 (npm v6.5.0)

real    1m52.919s
user    2m5.220s
sys     0m3.600s

Conclusion

There is no actionable conclusion. This ridiculous case, which we certainly shouldn't want the V8 or nodejs dev teams to optimize for, has significantly regressed with 10.0.0 release and isn't making signs of getting better.
Oh well. On with our lives.

Browsers

The provided code runs on par with or faster in Chromium 71.0.3578.98 than nodejs v4.

I don't know what to even think about that.
It runs faster than v10 but slower than v6 in Firefox 65.0.

Would probably run faster if I disabled it asking "a page is slowing down Firefox, would you like to stop it?" watchdog. If anyone knows what flag can do that, please tell me.

Disclaimer

This is not to be construed as advice to delay switching to nodejs v10.
My advice would be: If you catch someone using < v10 please calmly, without sacrificing professionalism, gently, nonviolently, but insistently, break their legs.
There are many usability and security implications, and this "benchmark" is in no way representative of real applications.
(There are performance improvements in both running normal code and native aspects like IO)

You must read: Deno Style Guide.

Mihail Malo — Tue, 12 Feb 2019 15:30:39 +0000

Good afternoon.
Without further ado, please go read the Deno Style Guide
Especially if you don't use deno, and don't intend to try it out any time soon.

If, for no apparent reason, you want to read some excerpts with emojis in between, here are some of the many gems in that little document:

A function that is part of the public API takes 0-2 required arguments, plus (if necessary) an options object (so max 3 total).

Optional parameters should generally go into the options object.

The 'options' argument is the only argument that is a regular 'Object'.

Other arguments can be objects, but they must be distinguishable from a 'plain' Object at runtime, by having either:

a distinguishing prototype (e.g. Array, Map, Date, class MyThing)

a well-known symbol property (e.g. an iterable with Symbol.iterator).

This allows the API to evolve in a backwards compatible way, even when the position of the options object changes.

Meta-programming is discouraged. Including the use of Proxy.

Be explicit even when it means more code.

Do not document function arguments unless they are non-obvious in their intent (though if they are non-obvious, the API should be reconsidered anyways). Therefore @param should generally not be used.

Code examples should not contain additional comments. It is already inside a comment. If it needs further comments it isn't a good example.

If you want to steal it for your project, this is where the markdown lives.

Disclaimer: The author is not affiliated with the deno project or its authors. Copyright of all images belongs to their respective owners.

Have fun!

Another GOTO to avoid

Mihail Malo — Fri, 08 Feb 2019 18:47:32 +0000

Another GOTO hiding in your code

Or, in clickbait terms:

Is your programming structured? The answer may surprise you!

Just a tidbit I often see people miss, and on more than one occasion caused trouble.

TL;DR: If you start a refactor, you better finish it.
TL;DR 2: The fact that to some people "recursion is its own reward" means it's often "clever code" and as such should be the last resort in production.
TL;DR 3: There aren't spoiler tags on DEV.to, so this one is at the end of the post.

Note: The examples are going to be in JavaScript, for wide accessibility, but this applies to most languages.

A common modern "best practices" refactor is avoiding switch fallthrough, especially when it's not an alias but some actions are performed before falling through.
We end up going from this:

function theFunction(operation, value) {
  switch (type) {
    case "bigIncrease":
    case "bigIncreaseAlias":
      value *= 2
    case "smallIncrease":
      value += 1
      break
    default:
      throw new TypeError(`Unknown operation ${operation}`)
  }
  return value
}

To this:

function theFunction(operation, value) {
  switch (type) {
    case "bigIncrease":
    case "bigIncreaseAlias":
      value *= 2
      value = theFunction("smallIncrease", value)
      return value
    case "smallIncrease":
      value += 1
      return value
    default:
      throw new TypeError(`Unknown operation ${operation}`)
  }

This became a recursive function, but at least we don't have the "bad" fallthrough anymore, right?
Another one, that improves testability and especially tooling around determining what functions are unused, and generally finding references, is splitting the switch case up into functions.

const operations = {
  bigIncrease: value => theFunction("smallIncrease", value * 2),
  bigIncreaseAlias: value => operations.bigIncrease(value),
  smallIncrease: value => value + 1
}
function theFunction(operation, value) {
  const fn = operations[operation]
  if (!fn) throw new TypeError(`Unknown operation ${operation}`)
  return fn(value)
}

JK, that alias is better solved differently:

const bigIncrease = value => theFunction("smallIncrease", value * 2)
const operations = {
  bigIncrease,
  bigIncreaseAlias: bigIncrease,
  smallIncrease: value => value + 1
}
function theFunction(operation, value) {
  const fn = operations[operation]
  if (!fn) throw new TypeError(`Unknown operation ${operation}`)
  return fn(value)
}

At this point, the astute reader will be totally like

Whoa, you should totally inline that call instead of having "dynamic dispatch" on a string, dude. What if the string name changes?! This is bad for tooling AND a waste of performance.

The reader will of course be right, and we end up with this:

const bigIncrease = value => operations.smallIncrease(value * 2)
const operations = {
  bigIncrease,
  bigIncreaseAlias: bigIncrease,
  smallIncrease: value => value + 1
}
function theFunction(operation, value) {
  const fn = operations[operation]
  if (!fn) throw new TypeError(`Unknown operation ${operation}`)
  return fn(value)
}

The question

Is this good code?
Are we done here?

Well, in my opinion we aren't.

Consider what would happen if we were to change the definition of the abstractly-named .smallIncrease function to value => value + 2!
The effect on the unassuming operation.bigIncreaseAlias would be disastrous! Everything ruined!
How could this happen? (No, this post isn't about the importance of unit testing.) We were so diligent!
Well, what we did is we relied on the smallIncrease function. Not for its actual semantic meaning of "what needs to be done in response to the dynamic "smallIncrease" command", but for its internal implementation details.
What can we do better? How can we avoid a repeat of such tragedy?
Well, for starters, we can avoid obsessively misusing the DRY principle, to avoid cryptic code:

const bigIncrease = value => value * 2 + 1
const operations = {
  bigIncrease,
  bigIncreaseAlias: bigIncrease,
  smallIncrease: value => value + 1
}
function theFunction(operation, value) {
  const fn = operations[operation]
  if (!fn) throw new TypeError(`Unknown operation ${operation}`)
  return fn(value)
}

Look mom, I just totally saved 22 characters! /sarcasm

In real life, the shared functionality may be much longer and more complex. What do?
Simple, use better naming and the Open-closed principle. In other words, write functions that do one thing, functions you will never have to edit, only delete if they become unused.
In our case, that looks like this:

const plusOne = value => value + 1

const bigIncrease = value => plusOne(value * 2)
const operations = {
  bigIncrease,
  bigIncreaseAlias: bigIncrease,
  smallIncrease: plusOne
}
function theFunction(operation, value) {
  const fn = operations[operation]
  if (!fn) throw new TypeError(`Unknown operation ${operation}`)
  return fn(value)
}

If someone edits that to be value + 2 they may be beyond help.
And operations is now just a declarative mapping of strings to locally available functions, much easier to look over at a glance without long implementations inside.
In posher words, when your code's definitions make an acyclic graph you're gonna have a good time.

Disclaimer: Please be gentle, I've never written anything anywhere before.

As promised:
TL;DR 3: Recursive definition is still recursion.
It should be avoided when it doesn't benefit the mental model.