So you want to commit changes generated by a GitHub Actions workflow back to your repo, and have that commit signed automatically?
Here's one way this is possible, using the REST API, the auto-generated GITHUB_TOKEN, and the GitHub CLI, gh, which is pre-installed on GitHub's hosted Actions runners.
You don't have to configure the git client, just add a step like the one below... Be sure to edit FILE_TO_COMMIT and DESTINATION_BRANCH to suit your needs.
| -------------------------------------------------------- | |
| -- Auto save/apply zoom levels on a per-domain basis -- | |
| -- (C) 2011 Roman Leonov <rliaonau@gmail.com> -- | |
| -- (C) 2011 Mason Larobina <mason.larobina@gmail.com> -- | |
| -------------------------------------------------------- | |
| -- Get lua environment | |
| local math = require "math" | |
| local tonumber = tonumber | |
| local string = string |
There are three easy to make mistakes in go. I present them here in the way they are often found in the wild, not in the way that is easiest to understand.
All three of these mistakes have been made in Kubernetes code, getting past code review at least once each that I know of.
What do these lines do? Make predictions and then scroll down.
func print(pi *int) { fmt.Println(*pi) }
| Latency Comparison Numbers (~2012) | |
| ---------------------------------- | |
| L1 cache reference 0.5 ns | |
| Branch mispredict 5 ns | |
| L2 cache reference 7 ns 14x L1 cache | |
| Mutex lock/unlock 25 ns | |
| Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
| Compress 1K bytes with Zippy 3,000 ns 3 us | |
| Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
| Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
This post has been written in collaboration with @klervicn
Virtually all web apps and websites need to pull data from a server, usually through a JSON-returning API. When it comes to integrating data fetching in React component, the "impedence mismatch" between the React components, which are declarative and synchronous, and the HTTP requests, which are imperative and asynchronous, is often problematic.
Many apps use third-party libraries such as Redux or Apollo Client to abstract it away. This requires extra dependencies, and couple your app with a specific library to perform data fetching. In most cases, what we want is a direct way to integrate plain HTTP requests (e.g. using native fetch) for usage in React components.
Here we will discuss how we can use React Hooks to do this in an elegant, scalable manner.
| whateverId | attribute1 | someotherattribute | |
|---|---|---|---|
| foo | bar | baz | |
| hello | erwin | world |
If you say "T is a subtype of U", that means that whenever someone wants a U, a T will do: every T works as a U. It follows from this phrasing that U is a subtype of U: certainly if someone wants a U, a U will do.
So if you imagine a type as denoting a set of values, you can write: T ⊆ U.
If every T works as a U, then a function that accepts any U is certainly also a function that accepts any T:
fn(U) works as a fn(T).
So fn(U) is a subtype of fn(T): fn(U) ⊆ fn(T).
This is interesting, because the subtypedness gets reversed: T ⊆ U implies fn(U) ⊆ fn(T).
For easy editor integration and command-line usage, we'd like to be able to specify a Python version per project, with its own virtualenv to isolate its libraries from those of other projects.
We're willing to change $PATH globally once, but not per project. And we'd like to avoid having to run every python command invocation in a special subshell created by a shell wrapper. Instead, simply invoking "python" or "pip" etc. should do the right thing, based on the directory in which it is invoked.
It turns out this is possible!
This simple script will take a picture of a whiteboard and use parts of the ImageMagick library with sane defaults to clean it up tremendously.
The script is here:
#!/bin/bash
convert "$1" -morphology Convolve DoG:15,100,0 -negate -normalize -blur 0x1 -channel RBG -level 60%,91%,0.1 "$2"
Original text from http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html
From: Mark Jason Dominus <mjd@plover.com>
Date: Jul 28, 2005 11:16 PM
Subject: Re: HOP -vs- SICP