This will expand URL to its canonical form and never outdate even if somebody pushes changes to that file and line later.

Before:

After:

That's noteworthy because git cherry-pick your-branch actually only picks the last commit of your-branch instead of the entire branch.

Example

git cherry-pick HEAD..your-branch

Imagine you're in the middle of a refactoring and a co-worker asks you to quickly try something in your code base on the latest main branch. Or you need to quickly put up a bugfix.

You have multiple options here. Stash everything or create (and push) a WIP commit are two of them.

However, you can also leverage git worktree.

# this creates a `../test-me` folder which includes a worktree copy of the current repo
git worktree ../test-me
cd ../test-me
# make changes and commit them

You can use git worktree list to view all your current worktrees and git worktree remove to remove them.

This can also come in handy if you have to maintain older versions of your code base. You can quickly check it out and apply changes in another folder without disrupting your main worktree.

Logs the current value of a timer that was previously started by calling console.time

https://developer.mozilla.org/en-US/docs/Web/API/console/timeLog

I always had trouble coming up with unique labels when logging inside loops because I didn't know this existed and relied on console.time and console.timeEnd.

Example

console.time('test');

setInterval(() => {
    console.timeLog('test');
}, 500);

Logs something like:

test: 500.716064453125 ms
test: 1000.72509765625 ms
test: 1500.756103515625 ms
test: 2000.7880859375 ms
#...

https://jsfiddle.net/robindrexler/9vyb3c5f/1/

That is because Firefox has implemented a "RCWN" (race cache with network) strategy where it'll try to fetch assets that are already cached from the network when IO is slow on the device and re-issuing the network request will actually be faster than reading the file from disk.

You can see stats at: about:networking#rcwn

const obj = { hello: 'world' };

function greet() {
    return ({ hello } = obj);
}

// logs {hello: 'world'}
console.log(greet());

Example

Imagine a page that has an image:

<img src="https://imgur.com/RrupgUW.jpg" width="250" />

const img = document.querySelector('img');

// image needs to be loaded before we can get its natural dimensions
img.onload = () => {
    const { width, height, naturalWidth, naturalHeight } = img;

    console.log({
        width,
        height,
        naturalWidth,
        naturalHeight,
    });
};

https://jsfiddle.net/robindrexler/dxo28e7n/3/

Example

window.addEventListener('keypress', (event) => {
    document.querySelector('input').focus();
});

You can try it here: https://jsfiddle.net/vq38uhne/1/

Press any key while the input field is not focused.
The value will still end up inside the input field because it's being focussed in the keydown event handler.

It's brilliant.

I used to create astronomically large arrays to slow down execution, but this is much better and much more precise and predictable.

Example

This will block the event loop for 500 milliseconds before continuing.

const endDate = new Date().getTime() + 500;

console.time();

// this blocks the event loop
while (new Date().getTime() <= endDate) {}

// logs something like default: 500.878173828125 ms
console.timeEnd();

https://jsfiddle.net/robindrexler/ybuafxsw/2/

That's useful to do common tasks like disabling or enabling JavaScript. Which otherwise needs to be done by going through the DevTools settings.

The command interface can be opened with command + shift + P (or Ctrl on Windows or Linux).

const add = (a, b) => a + b;
add(1, 3); // 4

Unfortunately, it's easy to get it wrong.
Imagine we wanted to return a result object instead of only the integer.
Something I often see in code (and write too often myself) is:

const add = (a, b) => {
    result: a + b;
};
add(1, 2); // undefined

The expected result probably is:

{
    result: 3;
}

However, it will be undefined instead. This is because the curly braces, we intended to use to create an object literal, open a new block and therefore we'd need to add an explicit return or parenthesis around the implicit return statement to get it to work.
That's pretty nasty and often hard to spot.

Here's two versions that would fix the error:

const add = (a, b) => ({ result: a + b });
const add = (a, b) => {
    return { result: a + b };
};

After making this error a couple of times and simply accepting the way to fix it, I began to ask why doesn't it throw an error, which would make my life a lot easier.
Since enclosing the statement in curly braces does not create an object literal, but opens a new block, there's only the following function body left:

result: a + b;

To showcase it a little bit better, here's how the entire function would look like in es5.

function add(a, b) {
    result: a + b;
}

How is that valid javascript, I wondered. I've never seen anything like this, yet neither browsers nor node complained about it.
It turns out there's labeled statements in javascript, which coincidentally follow such syntax. They're usually used to label loops to be able to break out of them later.

Example by mdn:

var i, j;

loop1: for (i = 0; i < 3; i++) {
    //The first for statement is labeled "loop1"
    loop2: for (j = 0; j < 3; j++) {
        //The second for statement is labeled "loop2"
        if (i === 1 && j === 1) {
            continue loop1;
        }
        console.log('i = ' + i + ', j = ' + j);
    }
}

For those that have never heard of it, PageSpeed works like this: You enter an URL and the service calculates a score from 0 to 100 and also gives some additional advice on how to improve performance.

While receiving such score is valuable on its own and for example you can safely assume that a score of 95 is great, I somehow missed a way to compare with others. Is a score of 60 good as well or bad? How about 75? I was never sure.

Enter https://webperfchallenge.com/. What webperfchallenge.com does is rather simple. You enter your URL and just like PageSpeed Insights it will tell you the site's Google PageSpeed score. However, it will additionally show you how your site performs compared to the top 50 most popular websites in the world.

Take my site for example. As of writing, its score is 89 which is better than or equal to 97% of top 50 most popular websites. That's useful information, at least for me, because it tells me that my site is good enough™ to hang with the most visited websites when it comes to performance.

Und wer weiß, vielleicht werden es sogar noch mehr sein. In zwanzig Jahren sowieso. Die Frage ist nicht mehr, ob sondern wann ein Großteil der Jobs von Maschinen erledigt wird.
Wann immer die Arbeit von Maschinen für ein Unternehmen günstiger ist, als die eines Menschen, wird es sich für die Maschine entscheiden. Und das ist auch ok so, finde ich.
Arbeit an sich ist kein Selbstzweck. Jeden Menschen, den wir davon befreien können arbeiten zu müssen, empfinde ich als Glücksfall.

So haben die Menschen mehr Zeit sich mit den Dingen zu beschäftigen, die sie wirklich interessieren und erfüllen.
Einfach wird das wohl leider nicht. Wenn man mal drüber nachdenkt, ist unser gesamtes System darauf aufgebaut, dass Menschen durch ihre eigene Arbeitsleistung Werte und Einkommen schaffen. Für sich selbst und für die Gesellschaft als Ganzes. Sind weniger Menschen in der Lage zu arbeiten, weil es einfach keine Jobs mehr auszufüllen gibt, könnte das System zu Taumeln beginnen.
Schauen wir uns mal ein paar Zahlen an (aus dem Jahr 2012)[2]:

tl;dr für die Faulen:
Ein Großteil des Bundeshaushalts entsteht durch Einnahmen, die entweder direkt oder indirekt von der menschlichen Arbeit Einzelner abhängen.

Von den 1.171 Milliarden Euro Bundeshaushalt (Geld, welches durchaus auch sinnvoll für Daseinsvorsorge genutzt wird) kamen 51,2% (600 Millionen Euro) aus Steuereinnahmen.
Ganze 24,8% davon wiederum entfallen auf die Lohnsteuer. Noch abhängiger von menschlicher Arbeit geht es kaum. Weitere 23,7% sind Umsatzsteuer. Wenn weniger Menschen ein gutes Einkommen erzielen können, kaufen sie auch weniger, was zu Mindereinnahmen bei der Umsatzsteuer führt.

Gute 420 Milliarden Euro (35,87% des Gesamthaushalts) entstehen durch Sozialabgaben, wie Arbeitslosenversicherung, Rentenversicherung, Krankenversicherung etc. Auch diese Einnahmen sind direkt abhängig von menschlichen Beschäftigungsverhältnissen.
Heutige Arbeitslose (und andere Bedürftige) können Leistungen nur erhalten, weil Andere sie durch ihre Arbeit erwirtschaften.

Wenn immer mehr Leute durch die fortschreitende Automation arbeitslos werden, geht die aktuelle Rechnung irgendwann nicht mehr auf. Mehr Geld wird benötigt werden, während gleichzeitig weniger Finanzen in den Haushalt strömen.
Konkrete Lösungsvorschläge habe ich leider auch nicht parat, aber mir scheint eine Entkopplung der Bundeshaushaltseinnahmen von menschlicher Arbeit unausweichlich.
Geschaffen werden Werte und Produkte ja immer noch. Ein Kuchen zum Verteilen ist also weiterhin vorhanden. :)

Nur um die Art und Weise sollten wir uns langsam mal streiten, denke ich.
Und wer jetzt noch fünfzehn Minuten Zeit hat, dem lege ich dieses ganz fantastische Video zum Thema fortschreitender Automation ans Herz: https://www.youtube.com/watch?v=7Pq-S557XQU
[1]http://www.businessinsider.com/experts-predict-that-one-third-of-jobs-will-be-replaced-by-robots-2015-5?ir=t
[2]http://www.bpb.de/wissen/tq0plw,0,0,steuereinnahmen_nach_steuerarten.html

Original veröffentlicht auf Facebook am 21.02.2016

During development we simply used Chrome's autocompletion to insert test urls.

Later that day, I showed the app to two people so they'd test it. Since we were at the party already, they used their phones to do so.

Naturally they just typed their domain name (e.g. "google.com") and pressed "analyze".
The app failed and displayed an error. The typed URL needed to be valid and contain a protocol (http or https). However, nobody wants to type an entire URL, especially on a phone.

The fix itself was rather easy. When the entered URL doesn't contain a protocol, "http" is prepended before it is submitted.

We didn't catch that UX-bug during development, because of how we worked.

Conclusion: Get your apps tested on the hallway. You'll generate great insights even with a low number of testers. :)

Browsers will mark non-secure origins as non-secure

Normally, when you visit a site that is served over https, in most browsers, a green lock symbol appears in the address bar, indicating that the page is served securely. This is going to be inverted, at least in Chrome. In the future, sites that are served over http instead of https, will be flagged as insecure. Eventually, once https is the norm, the green lock indicator will completely vanish.
https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure

non-secure

Secure

UPDATE 22.10.2015
Beginning with (nightly) version 44, Firefox flags websites as non-secure, when they contain a password input field. A measure taken to prevent users from submitting login data, because it might be compromised

New web apis are going to be https only

Some of the new web apis, especially those that are considered powerful (e.g. have access to sensitive data), are going to only be available on pages served over https.
For example:

• Service Workers
• • background tasks
  • geofencing
  • push notifications
  • new cache abilities
• App install banners (due to service worker being needed)

UPDATE 21.01.2016

The new compression algorithm brotli, which is said to have a better compression results than gzip, will only work on HTTPS connections in Chrome and Firefox.

https://www.chromestatus.com/feature/5420797577396224

Existing web apis will stop working non secure

Not only will new features be available for secure origins only, there are also discussions in place about removing currently available apis as well. Those include:

• geolocation
• access to microphone / camera
• full screen
• (session) storage

https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins https://sites.google.com/a/chromium.org/dev/Home/chromium-security/prefer-secure-origins-for-powerful-new-features http://www.w3.org/TR/powerful-features/#feature-requires-privilege https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

Deprecation is already in process

Using the geolocation api on a non-secure origin already utters a deprecation warning in recent Chrome versions.

What always bothered me was that it only worked after the document is ready. On amazon.com that can actually take a couple of seconds. As of today, their index page consists of over 9000 lines, including tons of scripts. That just takes a while to be completely processed by browsers. (To be fair, the first bits of the page are visible pretty fast)

However, I really never took the time address this issue. At least not until today. The "fix" turned out to be rather small and straight forward. Chrome allows to control when a content script is executed in the manifest file.

The options are:

• document_start
• document_end
• document_idle (default)

I only had to set it to "document_start" and now the script is executed before any DOM is constructed, instead of afterwards. As soon as a user presses "/" the script can react to it and has access to all elements that are already rendered on the page.
If a user can see the first search input on the page, they can now focus it by hitting the "/" key. No more waiting until the page is ready.

Kind of reminds me of Ruby's Virtual Attributes.

Example getter and setter

var dog = {
    get age() {
        console.log('accessed age');
        return this._age;
    },
    set age(age) {
        console.log('set age');
        this._age = age;
    }
};

dog.age = 8;
console.log(dog.age);

That's why Chrome on OSX offers to warn when CMD+Q is pressed, instead of closing. If you actually intended to close the browser, you can either hold CMD+Q or hit the shortcut again. Chrome will then close.