hmil

export type MyType = { foo: string };


export interface MyInterface {
    foo: string;
}

export class MyClass implements MyInterface {
    constructor(private foo: string) { }
}

hmil

// Create a bookmark with this content:

javascript:((el => 'value' in el && typeof el.value === 'string' && (el.value = el.value + '¯\\_(ツ)_/¯') && void 0)(document.activeElement))

// Use it to insert a shrug emoji in the text field currently focused

hmil

function buildUI() {
    const window = createWindow();
    const btn = createButton();
    const label = createLabel();

    let visitorNumber = 0;
    label.text = `Hello visitor nr ${visitorNumber}`;

    btn.label = "click me";
    btn.onClick = () => {

hmil

usage() {
    echo "my-script.sh [options]"
    echo ""
    echo "Options:"
    echo "    --simple-param, -s           : activate a feature"
    echo "    --complex-param, -c <value>  : set some value"
    echo "    --help, -h                   : print this help message"
}

while [ "$1" != "" ]; do

hmil

/**
 * Arbitrary-length tuples
 * =======================
 * 
 * Working with tuples of unknown length in TypeScript is a pain. Most library authors fall back on enumerating all possible
 * tuple lengths up to a threshold (see an example here https://github.com/pelotom/runtypes/blob/fe19290d375c8818d2c52243ddc2911c8369db37/src/types/tuple.ts )
 * 
 * In this gist, I'm attempting to leverage recursion to provide support for arbitrary length tuples. This has the potential
 * to make some kinds of declarative APIs nicer and enhance type inference in some cases.
 * This example shows how to take a variable-length tuple as an input, transform each of its types and use the resulting

hmil

import build from 'awesome-build-system'

compiled = build.createTarget('/dist/app.js', () => {
    build.exec('tsc -p tsconfig.json')
})

packaged = build.createTarget('/dist/package.tar.gz', [ compiled ], () => {
    build.exec('npm pack')
    build.exec(`cp artifact.tar.gz ${packaged}`)
})

hmil

export interface AjaxRequest {
    url: string;
    method?: string;
    data?: any;
}

let REPORT_ERRORS = true;

export function disableErrorReporting(): void {

hmil

class SyncDB {

    // ... attributes omitted for brievety

    public remove<T extends ISyncEntity>(entity: ISavedDocument<T>): Promise<void> {
        return this.lock.runExclusive( async () => {
            await this.db.remove(entity);
            const mutation = deleteMutation(entity, this.mutationSeq++);
            await this.db.post(mutation);
            return entity._id;

hmil

/**
 * The one true way to deal with nullables in TypeScript.
 * 
 * This code demonstrates a nice design pattern to deal with nullable
 * values in TypeScript. In my blog post, I describe how sane practices
 * around null values involved in both synchronous and asynchronous workflows
 * enhance the quality of the code without any downside.
 * 
 * http://blog.hmil.fr/2017/08/deal-with-nullables-like-theyre-not-even-here-good-coding-practices-in-typescript/
 * 

hmil

Grading scheme proposal

Idea

The TA writes down everything (s)he sees no matter how important it is and doesn't give any "point". The actual grade is computed from the list of issues collected from the comments.

The issues are not specific to the subject rather they are generic comments that can be made about any piece of C code. The issues are codified using a universal issue list. There is little to no room left for interpretation. A direct consequence is that the grading must be as fair* as possible.

* Fairness here means that the handouts should end up sorted by subjective quality based. There is still a subjectiveness bias but it applies to all handouts equally and is not dependent on which TA graded it.