(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
This Gist is there to help you creating a Sankey Diagram from your Google Spreadsheets.
Changes:
code.gs)| #! /bin/sh | |
| GOOS=linux go build -o $2 "$1" | |
| GOOS=linux go build -ldflags="-s -w" -o $2.-sw "$1" | |
| upx -f --brute -o $2.upx $2 | |
| upx -f --brute -o $2.-sw.upx $2.-sw | |
| GOOS=linux gotip build -o $2.tip "$1" | |
| GOOS=linux gotip build -ldflags="-s -w" -o $2.tip.-sw "$1" | |
| upx -f --brute -o $2.tip.upx $2.tip |
Here's a list of mildly interesting things about the C language that I learned mostly by consuming Clang's ASTs. Although surprises are getting sparser, I might continue to update this document over time.
There are many more mildly interesting features of C++, but the language is literally known for being weird, whereas C is usually considered smaller and simpler, so this is (almost) only about C.
struct foo {
struct bar {
int x;| M[16],X=16,W,k;main(){T(system("stty cbreak") | |
| );puts(W&1?"WIN":"LOSE");}K[]={2,3,1};s(f,d,i | |
| ,j,l,P){for(i=4;i--;)for(j=k=l=0;k<4;)j<4?P=M | |
| [w(d,i,j++)],W|=P>>11,l*P&&(f?M[w(d,i,k)]=l<< | |
| (l==P):0,k++),l=l?P?l-P?P:0:l:P:(f?M[w(d,i,k) | |
| ]=l:0,++k,W|=2*!l,l=0);}w(d,i,j){return d?w(d | |
| -1,j,3-i):4*i+j;}T(i){for(i=X+rand()%X;M[i%X] | |
| *i;i--);i?M[i%X]=2<<rand()%2:0;for(W=i=0;i<4; | |
| )s(0,i++);for(i=X,puts("\e[2J\e[H");i--;i%4|| | |
| puts(""))printf(M[i]?"%4d|":" |",M[i]);W-2 |
Strongly opinionated set of guides to quickly setup OS X Mavericks for web development. By default OS X hides stuff that normal people don't need to see. These settings are better defaults for developers.
I don't want: any sounds, annoying confirmation dialogs, hidden extensions, superflous animations, unnecessary things running like Dashboard, Notification center or Dock(Alfred/spotlight works better for me).
These are my opinions. Read this document through and pick up the good parts to your preferences.
To setup your computer to work with *.test domains, e.g. project.test, awesome.test and so on, without having to add to your hosts file each time.
| -- ----------------- | |
| -- Setup environment | |
| -- ----------------- | |
| -- Animation off, mofo | |
| hs.window.animationDuration = 0 | |
| -- Get list of screens and refresh that list whenever screens are (un)plugged | |
| local screens = hs.screen.allScreens() | |
| local screenwatcher = hs.screen.watcher.new(function() |
With GitHub Actions, a workflow can publish artifacts, typically logs or binaries. As of early 2020, the life time of an artifact is hard-coded to 90 days (this may change in the future). After 90 days, an artifact is automatically deleted. But, in the meantime, artifacts for a repository may accumulate and generate mega-bytes or even giga-bytes of data files.
It is unclear if there is a size limit for the total accumulated size of artifacts for a public repository. But GitHub cannot reasonably let multi-giga-bytes of artifacts data accumulate without doing anything. So, if your workflows regularly produce large artifacts (such as "nightly build" procedures for instance), it is wise to cleanup and delete older artifacts without waiting for the 90 days limit.
Using the Web page for the "Actions" of a repository, it is possible to browse old workflow runs and manually delete artifacts. But the procedure is slow and tedious. It is fine to delete one selected artifact. It is not for a regular cleanup. We need