[chubot]

For me, that is my ~/git/scratch repo (formerly ~/hg/scratch).

I have a lot of experiments in there: different approaches to parsing; R/OCaml/Lua experiments; tests for interactions between Unix signals, processes, and threads; etc.

One thing I've also found useful is: whenever you see a neat code snippet on Hacker News or a blog, download the code, and write a shell script to build and demo it. You don't even have to understand it thoroughly the first time around. But when you come across something related in the future, your brain will remind you of it, and you will have a little shell script you forgot about to puzzle through :) It takes like 10 minutes each time.

I have 141 different subdirs; probably half are my own and half are demos I learned something from (or hopefully will in the future).

[nkangoh]

What do you mean by "write a shell script to build and demo it"? Pardon my ignorance.

[organsnyder]

For many projects, I set up scripts for building (if necessary), running, deployment, etc. That way, when I return to it later I don't have to remember (or take the time to Google) the incantation to run some obscure framework that I haven't worked with in a few years. At the very least, I put some instructions in a readme.

Not sure if that's what chubot meant, though.

[chubot]

I make a shell script to accompany all code; I basically think of it as an "executable README". A README or blog post often contains shell commands. So I just copy those into a script.

And more often than not I add my own tests and demos. Sometimes I write a main() program, if it's C. If it's JS, then add an HTML skeleton and a script that runs a web server to demo it (e.g. python -m SimleHTTPServer). If it's Python, install any deps necessary. And often you will want to run the same script with many parameters to fully demo it.

The idea is to basically prove to yourself that the code works, without necessarily having to understand everything about it. Then when you see it later, your brain knows you can go back to it. You won't feel lazy like "oh man I have to go back and find the web page I saw 3 months ago, download code, pore through instructions to figure out how to build it". That part is already done.

For example, here's a snippet I did when testing out cityhash. It's usually much messier/longer than this.

    run.sh:

    #!/bin/bash
    readonly CITY_SRC=~/src/cityhash-1.1.1
    download() {
      ... <wget tarball> ...
    }
    hello() {
      g++ -I$CITY_SRC -I$CITY_SRC/src -o hello $CITY_SRC/src/city.cc hello.cc
     ./hello "$@"
    }
    "$@"


    hello.cc:

    #include <cstdio>
    #include <string.h>  // strlen

    #include "city.h"

    int main(int argc, char** argv) {
      if (argc >= 2) {
        char* s = argv[1];
        unsigned u = CityHash32(s, strlen(s));
        printf("hash = %x\n", u);
        return 3;
      }
    }

Then I just check those two files into ~/git/scratch/cityhash. Then I can reproduce it on any computer with a couple short commands.

[weaksauce]

I think the assumption was that the code was not fully fleshed out and would require some form of glue code to provide an interface. Even fully fleshed out git repositories usually take a little setup of the environment / compile setting to get it running.