ERC20 Tokens

ERC20 tokens are contracts on Ethereum adhering to a simple interface:

interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address to, uint256 amount) external returns (bool);
    function allowance(address owner, address spender) external view returns (uint256);
    function approve(address spender, uint256 amount) external returns (bool);
    function transferFrom(address from, address to, uint256 amount) external returns (bool);

    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

The interface defines six core functions:

• totalSupply(): Returns the total number of tokens in circulation
• balanceOf(): Returns the token balance for a given address
• transfer(): Moves tokens from the caller to a recipient
• approve(): Grants permission for another address to spend tokens on your behalf
• allowance(): Checks how many tokens a spender is authorized to use
• transferFrom(): Enables delegated transfers (used by DEXs and other protocols)

To create a new token, we provide the name, symbol, and decimals in the constructor when deploying the contract:

constructor(
    string memory _name,
    string memory _symbol,
    uint8 _decimals
) {}

The constructor only sets the token's metadata. To actually create tokens, you must call the mint() function after deployment to create tokens at a specific address.

ERC20 Faucet

Deploying tokens is useful, but sometimes you want a "faucet" for that token as well. A faucet is a contract that distributes tokens to users on demand, which is particularly useful on testnets where users need tokens to interact with dApps.

The ERC20Faucet contract extends the standard ERC20 contract with an additional method that allows any caller to request tokens:

function money_pweese() public {
    uint256 amount = 5 * 10 ** decimals;
    require(_balances[address(this)] >= amount, "Insufficient faucet balance");
    _transfer(address(this), msg.sender, amount);
}

This function transfers 5 tokens (5 × 10^decimals) from the contract's own balance to the caller. Before users can claim tokens, the deployer must first mint tokens to the contract address using mint(address(this), amount).

Talking is a hydrant in the yard and writing is a faucet upstairs in the house. Opening the first takes the pressure off the second. - Robert Frost

Background

A key generation service is useful for decoupling unique key creation from any other business logic.
This service comes up in System Design questions such as URL shortner and Pastebin.
It works by generating random base64 keys and storing them in an available_keys table.
Once a key is requested to be used, that key is then moved to the used_keys table.

Setup

For our storage, we will use Amazon's DynamoDB, a NoSQL storage. To run it locally, type:

docker run -p 8000:8000 amazon/dynamodb-local

Generating the keys

To generate the keys, we'll use the uuid package to generate the random string and base64 encode it.

import (
    "encoding/base64"

    "github.com/google/uuid"
)

hash := uuid.New()
encodedHash := base64.StdEncoding.EncodeToString(hash[:])

Saving keys into DynamoDB

DynamoDB consists of tables, items and indices.
Each table does not need a schema like in relational DBs but does require a primary key.
This can be any unique attribute of the item. If two attributes are used, one will be the partition key and the other the sort key.

For our example, we will use the key as the primary key.

    type KeyItem struct {
        Key       string `dynamodbav:"key"`
        CreatedAt string
        UpdatedAt string
    }

now := time.Now().UTC().String()

item := KeyItem{
    Key:       encodedHash,
    CreatedAt: now,
    UpdatedAt: now,
}

To create the tables and save the key in the available_keys table we will use the aws-sdk-go-V2 package.
This package is the successor to the original AWS sdk. We assume that the client is already initialized and the used_keys table is created identically to the available_keys table.

// Create the table
client.CreateTable(ctx, &dynamodb.CreateTableInput{
        TableName: aws.String(TableAvailableKeys),
        AttributeDefinitions: []types.AttributeDefinition{
            {
                AttributeName: aws.String("key"),
                AttributeType: types.ScalarAttributeTypeS,
            },
        },
        KeySchema: []types.KeySchemaElement{
            {
                AttributeName: aws.String("key"),
                KeyType:       types.KeyTypeHash,
            },
        },
        ProvisionedThroughput: &types.ProvisionedThroughput{
            ReadCapacityUnits:  aws.Int64(10),
            WriteCapacityUnits: aws.Int64(10),
        },
    }
)
// Save the item
marshalledItem, err := attributevalue.MarshalMap(item)
if err != nil {
    panic(err)
}

name := "available_keys"
_, err = client.PutItem(ctx, &dynamodb.PutItemInput{
    Item:      marshalledItem,
    TableName: &name,
})
if err != nil {
    panic(err)
}

As you can see, creating tables and adding items is pretty straight forward in DynamoDB.

Accessing the keys

When a key is requested from the service, we retrieve the first available key and move it to the used_keys table.
This allows us to reuse keys when they are no longer needed.

First, scan the available_keys table for a key:

var limit int32 = 1
res, err := k.client.Scan(ctx, &dynamodb.ScanInput{
    TableName: aws.String("available_keys"),
    Limit:     &limit,
})
if err != nil {
    panic(err)
}

Next, save that key in the used_keys table:

item := tables.KeyItem{}
err = attributevalue.UnmarshalMap(res.Items[0], &item)
if err != nil {
    panic(err)
}

item.CreatedAt = time.Now().UTC().String()
item.UpdatedAt = item.CreatedAt

marshalledItem, err := attributevalue.MarshalMap(item)
if err != nil {
    panic(err)
}
_, err = k.client.PutItem(ctx, &dynamodb.PutItemInput{
    Item:      marshalledItem,
    TableName: aws.String("used_keys"),
})
if err != nil {
    panic(err)
}

Finally, delete the key from the available_keys table:

key, err := attributevalue.Marshal(item.Key)
if err != nil {
    panic(err)
}

_, err = k.client.DeleteItem(ctx, &dynamodb.DeleteItemInput{
    Key: map[string]types.AttributeValue{
        "key": key,
    },
    TableName: aws.String("available_keys"),
})
if err != nil {
    panic(err)
}

Note: deleting the key involves doing the inverse approach. We get the key from the used_keys table, delete it from there and add it back to the available_keys table.

It's easy to play any musical instrument: all you have to do is touch the right key at the right time and the instrument will play itself. - Johann Sebastian Bach

//go:build
//go:embed
//go:linkname

Why?

go:linkname can be used to access or override unexported methods.
In general, it should be avoided since there is no guarantee that the behavior won't change in future Go versions.
This is still a cool feature of Go, so let's explore it further.

How?

For this example, we'll be accessing the unexported method open in a separate package:

package door

import (
	"fmt"
)

func open() {
	fmt.Printf("Opening the door!")
}

Add an empty exportable method in your package.
Remember to import the package containing your unexported method, otherwise it will fail to compile:

package open

import _ "example1/door"

func Open()

Next, add an empty assembly file i.s in the open package. If this is not added, you'll get a missing function body error.

Finally add the go:linkname directive to the unexported method. Remember to import the unsafe package as well:

package door

import (
	"fmt"
	_ "unsafe"
)

//go:linkname open example1/open.Open
func open() {
	fmt.Printf("Opening the door!")
}

Checkout the playground

References

• http://siadat.github.io/blog/post/golinkname
• https://www.pixelstech.net/article/1649596852-The-magic-of-go%3Alinkname
• https://lnquy.com/blog/go-linkname/

The road to success is always under construction

Pi-hole uses this concept to block devices from connecting to certain servers. It uses ad lists (which you can import from Github) to block any requests to those addresses.

Setup raspberry pi

Follow their setup guide for an easy way to install the pi-hole. Read on for the longer way =).
Download the Raspberry Pi OS Lite version to reduce the number of extra packages.
Flash it onto the SD card using something like balenaEtcher.
Next, navigate to the SD card in your terminal. Add a few files to enable ssh.

$ touch ssh
$ openssl passwd -6 -salt '1234567890' -stdin <<< 'raspberry' > userconf.txt

Note: for macOS make sure your openssl version is correct.

Insert the SD card, connect to your ethernet and power on your raspberry pi.
Find the raspberry pi ip via the router or scanning your network.
Verify you can ssh into the pi:

$ ssh pi@<ip address>

Set a static ip address on the pi.

Setup pi-hole

Now that the pi is up, ssh into the pi and install the pi-hole software:

$ curl -sSL https://install.pi-hole.net | bash

After a few prompts you will have the pi-hole running.
Verify it is running by logging on to the admin panel.
You should see the dashboard below:

Congrats on setting it up!

To build or not to build...

This distribution can be seen in word frequencies across all languages. There seems to be a tradeoff between short one syllable words (easier for humans to speak) and the chance of miscommunication.

Following this video, I took the text of The Count of Monte Cristo and ran a word frequency analysis on the corpus using AntConc.
Then I uploaded the results to Google Sheets and created the chart below:

Notice how the corpus follows the same Zipf's distribution.

Roll up twenty Zig Zags out of one Zipf - Juicy J

Helm is like a template processor. It consists of yaml files with two types of files: Chart.yaml and values.yaml.
The chart file contains keys and templated values such as these:

tree: {{ .Value.treeType }}

Helm is used to keep infrastructure as code, allowing for quick deploys and rollbacks to the cluster.

Setup

Here's a quick run through of how to get started.
Create a project first

helm create <project name>

Add some values to the values.yaml file:

favorite:
  drink: grog

Add a ConfigMap template in templates/configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
    name: {{ .Release.Name }}-configmap-{{ .Release.Namespace }}
data:
    drink: {{ .Values.favorite.drink | quote }}

Note the .Release object. Helm has a few built-in objects.
Note also the pipe to a built-in function quote which will quote the drink value.

Now get a dry-run output first to see the compute value:

helm install <release name> . --debug --dry-run

...
COMPUTED VALUES:
favorite:
  drink: grog
...
MANIFEST:
---
# Source: ./templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
    name: <release name>-configmap-default
data:
    drink: "grog"

Congrats on getting up and running with helm.

Anyone can hold the helm when the seas are calm - Publius Syrus

• Building and testing on each PR and on the master branch
• Linting on PRs
• Auto formatting on PRs
• Deploy previews on PRs

I created a repo go-ci with a simple test server.
Next I started browsing the GitHub Marketplace for existing actions/apps I could use.

Build, Test, Benchmark...Oh My

This required a few actions. I used one separate action for building and testing.
Another action I thought was cool allowed me to run a benchmark test and upload the results to GitHub pages.

Lint Rollers

I used an existing action for linting which under the hood used golangci-lint.
This was nice because it supported multiple linters and would catch more issues.

Auto Format

For formatting, I saw a few actions which would fail a build for unformatted code.
However, I really wanted to auto format the Go code on each PR since this was a repetitive task.
I looked around and saw a few existing actions for JS projects and decided to create a similar one.
I created my own action using gofumpt underneath and published it to the Marketplace.

Sneak Peek Previews

I wanted each PR to have a deployable app. The quickest way for me was to setup a Heroku pipeline and enable Review apps.
While this works, there is probably a better way of doing this.

And that's it.

Just do it - Shia Surprise

(node:79706) Warning: Accessing non-existent property 'cat' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)
(node:79706) Warning: Accessing non-existent property 'cd' of module exports inside circular dependency
(node:79706) Warning: Accessing non-existent property 'chmod' of module exports inside circular dependency
(node:79706) Warning: Accessing non-existent property 'cp' of module exports inside circular dependency

One way of finding out what packages were throwing these warnings was by running the same command but with the --trace-warnings option:

npx cross-env NODE_OPTIONS="--trace-warnings" yarn test

This helped in pinpointing which packages needed to be updated!

Bonus

Here is a contrived example of two classes depending on each other:

// a.js
const B = require('./b');

class A {
    constructor(name) {
        this.name = name;
        this.b = new B();
        this.b.log(name);
    }
}

const a = new A('cat')

module.exports = A;

// b.js
const A = require('./a');

class B {
    constructor() {
        this.a = A;
        console.log(this.a)
    }

    log(stuff) {
        console.log(stuff)
    }
}

module.exports = B;

// package.json
  "scripts": {
    "build": "node a.js"
  },

Now building our files gives us this warning:

$ yarn build

(node:18952) Warning: Accessing non-existent property 'Symbol(nodejs.util.inspect.custom)' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)

Now using --trace-warnings we can see where this issue is happening:

$ npx cross-env NODE_OPTIONS="--trace-warnings" yarn build

(node:18978) Warning: Accessing non-existent property 'Symbol(nodejs.util.inspect.custom)' of module exports inside circular dependency
    at emitCircularRequireWarning (node:internal/modules/cjs/loader:698:11)
    at Object.get (node:internal/modules/cjs/loader:712:5)
    at formatValue (node:internal/util/inspect:746:30)
    at inspect (node:internal/util/inspect:330:10)
    at formatWithOptionsInternal (node:internal/util/inspect:1998:40)
    at formatWithOptions (node:internal/util/inspect:1880:10)
    at console.value (node:internal/console/constructor:327:14)
    at console.log (node:internal/console/constructor:363:61)
    at new B (/Users/ygaberman/programs/test/b.js:6:17)
    at new A (/Users/ygaberman/programs/test/a.js:7:18)

The last two lines show us where the dependency is. This is quite useful for chasing down any circular dependencies!

Can we fix it? Yes.

const target = {};
const proxy = new Proxy(target, {
  set: (obj, prop, value) => {
    console.log(`Setting ${prop} to ${value}`)
    obj[prop] = value;
  }
});

Now when we set a value on our proxy, our target will have that value and our log will be called:

proxy.name = 'turtle'
'Setting name to turtle'

Proxies are built using the Reflect API and can be used for validating getters/setters. The example below shows how we can throw an error if a property does not exist on the target.

const target = {
  name: 'hi',
};
const proxy = new Proxy(target, {
  get: (target, prop, receiver) => {
    if (prop in receiver) {
      return Reflect.get(target, prop, receiver);
    }
    throw new Error('property does not exist!');
  }
});

proxy.name // 'hi'
proxy.dne // Uncaught Error: property does not exist!

Some use cases for proxies:

• Validation: Is the input a valid integer?
• Caching: Can we return the data from memory instead of fetching from our api?
• Observability: Can we be notified when an object's state is changed?

Go out there and build!

Today we'll explore building 2048 with svelte and CSS grid layout.
This post is short, so jump down to the resources to get started on your own!

Svelte is a front end framework promising less boilerplate code. Less is more, so less try it out.

npx degit sveltejs/template 2048
cd 2048
yarn
yarn dev

Once up and running, let's navigate to localhost:5000. Once there, let's add a 4x4 grid.
When working with CSS grid, we set the container to display:grid, as well as other grid properties.
Finally, let's set the properties of the cell (height, width, and how we will display the content).
See the minimal example below:

.grid {
	display: grid;
	grid-gap: 10px;
	grid-template-columns: 1fr 1fr 1fr 1fr;
	grid-auto-rows: 1fr;
}

.cell {
	width: 48px;
	height: 48px;
	display: flex;
	justify-content: center;
	align-items: center;
}

Once the layout is setup, we write some code to handle the key/touch events since we want to support both mobile and desktop.
We use the swiped-events repo to detect mobile swipes. Neat...

const mobileKeyMap = {
	'swiped-up': 'ArrowUp',
	'swiped-down': 'ArrowDown',
	'swiped-left': 'ArrowLeft',
	'swiped-right': 'ArrowRight',
}
const mobileKeys = Object.keys(mobileKeyMap);

const setupMobile = () => {
	mobileKeys.forEach(eventName => {
		document.addEventListener(eventName, (event) => {
			event.key = mobileKeyMap[event.type];
			handleInput(event);
		});
	})
}
setupMobile();
const handleInput = (event) => {
	switch (event.key) {
	case 'ArrowUp':
	case 'ArrowDown':
	case 'ArrowLeft':
	case 'ArrowRight':
		game.handleInput(event.key);
		game.grid = game.grid;
		return;
	default:
		return;
	}
};

And with a lot of help from Rosetta Code, we create a separate game.js class to handle the game logic.
Finally, we create a separate svelte component to make it rain when the player wins:

Resources

• Original game
• 2048 in all languages
• Repo

Quaerite Et Invenietis

TIL: Deque is an abbreviation for double-ended queue...amazing!

This week, we'll take a brief look at how Wix works. Wix is a site builder useful for ecommerce and portfolios.
It is a high level site builder, trading customization for quick setup and ease of use for non technical customers.

A very simplified flow of setting up a site is something like this:

When building a site, Wix has a nice dashboard which lets us preview our site on both desktop and mobile.
Further, if we enable their developer mode (Corvid), we can add our custom JavaScript for a given page or the whole site.
While Wix can be a bit slow at times (toggling between previewing and editing the site is a pain),
Wix does a great job of getting you up and running on your own.

Give it a try!

Two cool options we can use are Netlify's deploy previews
and AWS Amplify's web preview.

Assuming we have a pipeline setup with either of those services, we can connect either platforms to our repo.
After enabling deploy previews (usually by connecting either Netlify or AWS Amplify to our platform),
we can see a preview of our pull request!

Netlify

For Netlify, we can see the GitHub checks below. Tapping on the details link will take us to the preview app.

AWS Amplify:

For AWS Amplify, we have to do a few more steps. Our repo must be set to private, after which we can see the completed check below.

Unfortunately we can only get the link from the AWS Amplify console. Navigate to App -> App Settings -> Previews to get your preview URL.

Go out there and try it out on your own!