Michael Hood michaelhood

Exporting your 2FA tokens from Authy to transfer them into another 2FA application

IMPORTANT - Update regarding deprecation of Authy desktop apps

Past August 2024, Authy stopped supported the desktop version of their apps:
See Authy is shutting down its desktop app | The 2FA app Authy will only be available on Android and iOS starting in August for details.

And indeed, after a while, Authy changed something in their backend which now prevents the old desktop app from logging in. If you are already logged in, then you are in luck, and you can follow the instructions below to export your tokens.

If you are not logged in anymore, but can find a backup of the necessary files, then restore those files, and re-install Authy 2.2.3 following the instructions below, and it should work as expected.

Some quick thoughts on https://twitter.com/dan_abramov/status/884892244817346560. It's not ignorant at all to ask how browser vendors approach performance. On the V8 side we've discussed bytecode precompilation challenges a few times this year. Here's my recollection of where we stand on the idea:

JavaScript engines like V8 have to work on multiple architectures. Every version of V8 is different. The architectures we target are different. A precompiled bytecode solution would require a system (e.g the server or a CDN) to generate bytecode builds for every target architecture, every version of V8 supported and every version of the JavaScript libraries or bundles bytecode is being generated for. This is because we would need to make sure every user accessing a page using that bytecode can still get the final JS successfully executed.

Consider that if a cross-browser solution to this problem was desired, the above would need to be applied to JavaScriptCore, SpiderMonkey and Chakra as well. It would need to ca

Note: I'm not involved in Prepack in any way — please correct me if I say anything incorrect below!

A few people have asked me if Prepack and Svelte are similar projects with similar goals. The answer is 'no, they're not', but let's take a moment to explore why.

What is Prepack?

Prepack describes itself as a 'partial evaluator for JavaScript'. What that means is that it will run your code in a specialised interpreter that, rather than having some effect on the world (like printing a message to the console), will track the effects that would have happened and express them more directly.

So for example if you give it this code...

PSQL CLI Client

Psql is a fully-fledged CLI client for Postgres, but most people are unaware of its many advanced features.

~/.psqlrc can be edited to persist any behavior or configuration settings you want between psql sessions. It behaves just like ~/.bashrc or ~/.vimrc, sourced at psql launch. See More out of psql for some interesting configurations.

If you have a long query to write and rewrite, you can use \e to edit your query in an editor.

Use \watch at the end of a query in order to automatically re-run the query every few seconds - great for monitoring while making changes elsewhere in your application architecture.

Gmail and GitHub

How to filter emails from GitHub in Gmail and flag them with labels.

The labels in this document are just examples.

Pull Request

Filter	Label

Problem: How can we preprocess JavaScript (at build-time or on the server-side) so engines like V8 don't have to spend as much time in Parse? This is a topic that involves generating either bytecode or a bytecode-like-abstraction that an engine would need to accept. For folks that don't know, modern web apps typically spend a lot longer in Parsing & Compiling JS than you may think.

Yoav: This can particularly be an issue on mobile. Same files getting parsed all the time for users. Theoretically if we moved the parsing work to the server-side, we would have to worry about it less.
One angle to this problem is we all ship too much JavaScript. That's one perspective. We could also look at preprocessing.
We've been talking about this topic over the last few weeks a bit with V8. There were three main options proposed.
1. Similar to what optimize-js does. Identify IIFEs and mark them as such so the browser and VMs heuristics will catch them and do a better job than today. optimize-js only tackles IIFE bu

	#!/usr/bin/python

	import os
	import sys

	from CoreFoundation import (CFPreferencesAppValueIsForced,
	CFPreferencesCopyAppValue,
	CFPreferencesCopyValue,
	kCFPreferencesAnyUser,
	kCFPreferencesAnyHost,

	## Quick fix for slow internet after update to OSX 10.11 "El Capitan"
	## Changes are not permanent, just restart your mac if it doesn't work.

	## write config
	sudo su -
	sysctl -w net.inet.tcp.doautorcvbuf=0
	sysctl -w net.inet.tcp.doautosndbuf=0
	sysctl -w net.inet.tcp.win_scale_factor=0
	sysctl -w kern.ipc.somaxconn=2048
	sysctl -w net.inet.tcp.rfc1323=1

	#! /bin/bash
	set -euo pipefail

	# This script will remove automatic association for all networks not listed in the whitelist
	# passed as the first argument. Passwords will NOT be removed from the Keychain.
	#
	# Alternatively, you can untick "Remember networks" in Network Preferences > Wi-Fi > Advanced,
	# but then you won't be able to auto-join networks even temporarily, and you might already
	# have a long list to go through.
	#

	#!/bin/bash

	# In iTerm, if you have a different colored terminal theme than what you use for
	# vim. You'll see a border of whatever the background color is in fullscreen
	# mode One way to get rid of this is to use escape sequences to switch to a
	# different profilewhen you open vim, and back when you are done.

	# for this to work you need to have a profile set up called 'vimcolors'
	# that matches your vim colorscheme (or at least the background color)