by

More podcast recommendations

It’s been two years since my previous podcast recommendations, and I’ve listened to a lot of podcasts since then. I recently posted my favorite episodes on effective altruism, and here some more suggestions on all kinds of topics that interest me.

GitMinutes is fun if you’re a Git power user, these are stories about messy Git migrations, code review tools, hosting, etc.

Hanselminutes is a podcast for software developers. I only listen to the occasional episode that looks especially interesting, like the interview with felt@ from the Chromium project.

omega tau goes into incredible depth on very niche science & engineering topics, like the Apollo Guidance Computer.

Philosophy Bites is exactly what it sounds like. Nick Bostrom on the Status Quo Bias was fun.

Point of Inquiry has had an very impressive lineup of guests over the years. Take your pick, or take mine: Peter Singer.

Rationally Speaking also has good taste in guests: Holden Karnofsky, Peter Singer, Max Tegmark, Paul Bloom, …

This Developer’s Life is an anecdote-fueled tour of software development, with episode titles too vague to be useful…

Very Bad Wizards is two guys arguing about morality, mostly.

Waking Up with Sam Harris is my top recommendation, hands down. The guests are phenomenal, and Sam’s voice really adds something to the experience that you don’t get in print. Two episodes with Paul Bloom—The Virtues of Cold Blood and The Dark Side—are among my favorites. Before Sam had his own podcast he appeared on many others, and he still does from time to time. These are all that I could find:

My fantasy podcast would be Sam Harris and Peter Singer in conversation, 8 hours non-stop about trolley problems, average vs. total well-being and akrasia. Until the podcast genie grants my wish, listening to them separately will do, and in addition to the episodes from my post on effective altruism I have found plenty more with Peter Singer:

That’s it for English podcasts, men jag har några tips på svenska också.

Fondpodden hittade jag via Avanzas podcasttips, där det även finns annat som är intressant om man sparar i fonder.

Kreditvärden är en podcast om företagsobligationer, vilket ju inte låter så spännande, men det blir mycket allmänt om ekonomi och framförallt så är Louis & Gabriel väldigt trevliga att lyssna på.

by

The Life You Can Save

I used to read a lot of Peter Singer in my school years, and have always been quite easily persuaded by his writings. So, when I got his 2009 book The Life You Can Save, I already knew the basic argument, that I would find no reasonable objections, and that the conclusion would be uncomfortable. It sat on my bookshelf for over a year, unread.

Perhaps it was the latent discomfort that pushed me to finally take the book off the shelf. A one-sentence summary will do: If you can prevent suffering or death, without sacrificing anything nearly as important, then you should. There are some philosophically interesting problems, many oft-repeated concerns, and a few lingering doubts, but as expected nothing that makes inaction look like the best choice.

The landscape has changed a bit since The Life You Can Save, with the emergence of the philosophy and movement now known as effective altruism. Three similarly-titled books on these issues were recently published, and I binge-read them all: Singer’s new book The Most Good You Can Do, William MacAskill’s Doing Good Better, and Nick Cooney’s How To Be Great At Doing Good. The latter was not my cup of tea, but the other two are both great reads. If I had to recommend one book it would be Doing Good Better.

I will make no attempt to summarize, because the authors have done that themselves in many podcasts and videos. Singer and MacAskill’s Aussie and Scottish dialects add to the experience, and I’ve gone through everything I could find. My top picks are in bold.

Podcasts:

Videos:

Now what? Some effective altruists are giving 10–50% of their income, which is in equal parts inspiring and intimidating. The most good you can do is very good indeed, but Singer also suggests a minimum standard for giving, a baseline to get us started. I’ll give it a try.

I pledge that over the coming year I will give 2.5% of my (after-tax) income to organizations effectively helping people living in extreme poverty.

by

History of the Fullscreen API

This is the story of the Fullscreen API, one of prefixes, capitalization, and event targets…

March–October 2007: “Shouldn’t the video API include a way to toggle full screen on/off?” asks Mihai Sucan, a mere month after Opera’s debut of the video element. Much is said about the security implications of such an API, nothing happens, and years pass…

November 2009–March 2010: Eric Carlson (Apple) adds an API for fullscreen video to WebKit:

partial interface HTMLVideoElement {
  readonly attribute boolean webkitSupportsFullscreen;
  readonly attribute boolean webkitDisplayingFullscreen;
  void webkitEnterFullScreen();
  void webkitExitFullScreen();
}

The webkitbeginfullscreen and webkitendfullscreen event are fired on the video element.

The inconsistent capitalization is noticed and fixed by adding webkitEnterFullscreen() and webkitExitFullscreen() aliases. The original names are kept for backwards compatibility.

Revisions: 50893, 54143, 55946

June 2010: Robert O’Callahan (Mozilla) begins working on a proposal to allow any element, not just video, to go fullscreen.

August 2010–January 2011: Jer Noble (Apple) implements something similar to the then-current Mozilla proposal in WebKit:

partial interface Element {
  const unsigned short ALLOW_KEYBOARD_INPUT = 1;
  void webkitRequestFullScreen(unsigned short flags);
}
partial interface Document {
  readonly attribute boolean webkitIsFullScreen;
  readonly attribute boolean webkitFullScreenKeyboardInputAllowed;
  readonly attribute Element? webkitCurrentFullScreenElement;
  void webkitCancelFullScreen();
}

The webkitfullscreenchange event is fired on the current fullscreen element and bubbles.

Revisions: 66251, 75277

September–December 2011: Chris Pearce (Mozilla) begins implementing the proposal in Gecko. Meanwhile, Anne van Kesteren (then Opera, now Mozilla) starts working on a spec at the W3C. The fullscreen element stack is introduced, which makes nested fullscreen (e.g. video in a presentation) possible. When exiting from nested fullscreen, it now becomes un-obvious which element(s) to notify, so the event target is changed to the document.
Revisions: 1c36dc1c92c5, 332cd2925b28

These spec changes are implemented in Gecko, but the old names, and mozFullScreen, are kept:

partial interface Element {
  void mozRequestFullScreen();
}
partial interface Document {
  readonly attribute boolean mozFullScreen;
  readonly attribute boolean mozFullScreenEnabled;
  readonly attribute Element? mozFullScreenElement;
  void mozCancelFullScreen();
}

The mozfullscreenchange event is fired on the document and bubbles.
Bug: 545812

March 2012: Jer Noble implements the W3C spec in WebKit:

partial interface Element {
  void webkitRequestFullscreen();
}
partial interface Document {
  readonly attribute boolean webkitFullscreenEnabled;
  readonly attribute Element? webkitFullscreenElement;
  void webkitExitFullscreen();
}

Notably, the webkitfullscreenchange event target is the fullscreen element, not the document. Because the event bubbles, listening on the document does work, though.
Revision: 111028

September 2012: The Fullscreen API moves to the WHATWG. The W3C version has been unmaintained ever since.

November 2012: Opera 12.10 is released with support for the spec as it was in February, without prefixes. Opera 12 is the last major version based on Presto, so this unprefixed implementation does not last long.

May 2013: Vincent Scheib (Google) questions why the events bubble. Since it is just an accident of history, they are made to not bubble in the spec.
Commit: 5eb5af63369385c888a5146dda57d462cb9a41da

October 2013: Internet Explorer 11 is released with an ms-prefixed fullscreen API:

partial interface Element {
  void msRequestFullscreen();
}
partial interface Document {
  readonly attribute boolean msFullscreenEnabled;
  readonly attribute Element? msFullscreenElement;
  void msExitFullscreen();
}

The MSFullscreenChange event is fired on the document… and bubbles! Most likely the implementation predates the spec change.

Now: This is a bit of a mess! The long history of changes in capitalization and event targets has given JavaScript library authors ample opportunity to write code that will fail once the unprefixed API is made available. I’m trying to implement and ship the unprefixed Fullscreen API in Blink, and some bumps in the road are likely.

by

Media playback restrictions in Blink

Blink and WebKit have a setting for requiring a “user gesture” to play or pause an audio or video element, which is enabled in Opera for Android, Chrome for Android, the default Android browser, Safari for iOS and probably other browsers. This makes some sense, since mobile devices are used in public and in bed, where unsolicited sound from random Web sites could be a nuisance. Also, autoplaying video ads would waste bandwidth.

The trouble is that this gets in the way of reasonable use cases like games or playlists, and developers are not impressed. We’ve discussed this a lot internally at Opera, and as an experiment we’ve removed the restrictions in Opera beta for Android.

However, I’ve also found a workaround for current browsers. As of WebKit r108831, all restrictions are removed in the first successful load() or play() call. Any user gesture is accepted, so one can listen to all input events and remove the restrictions as soon as the user clicks, touches or uses the keyboard. One does not need to start playback at that point, but can wait until a later time. For example, one could “liberate” a number of audio elements for later use in a game.

I’ve prepared a demo of the workaround. It works in current versions of Opera, Chrome and Safari. While it does not work in the default Android browser prior to KitKat, even there it could be adapted to e.g. autoplay background music by calling play() instead of load() in the input event handler.

Given this, I think that either a user gesture should be required for every play() or the restrictions should be removed completely. My tentative suggestion is the latter.

by

One month in Blink

On October 1, I began working in Opera’s new Web Technology team, tasked with improving the Web platform by contributing to the Chromium and Blink projects. Most of my effort has been on the Blink side, and it has been a very pleasant experience so far. Since I’ve worked so much with <video> before, I jumped right into that area and looked for things to work on. Chromium/Blink is a big code base which will take time to get intimately familiar with, but I was still able to make small improvements in a few areas.

Event handler attributes

My colleague Henrik reported that onplay and friends were missing on HTMLMediaElement, and I thought it surely would be easy to fix. However, I am easily distracted, so instead of just adding them I decided to implement GlobalEventHandlers and WindowEventHandlers, which ended up taking me 11 commits and even requiring IDL code generator (Perl!) changes. Now onplay is supported, but you probably don’t want to use it – use addEventListener(‘play’, func) if uncertain!

While in the neighborhood, I also made the onerror attribute on <body> and <frameset> work per spec. I was a bit surprised to find this broken, presumably it isn’t that important for site compat…

Removing features

Although I’m quite happy with Blink code, I was surprised to find how much non-standard stuff there is, including prefixed APIs, undocumented quirks and things that have been removed from the spec. Fortunately, the Blink project is supportive of removing these things, with care, and I’ve now picked most of the low-hanging fruit on HTMLMediaElement, getting rid of a weird npr.org quirk, webkitPreservesPitch, webkitHasClosedCaptions, webkitClosedCaptionsVisible, startTime and initialTime.

Counting features

When there’s a risk that removing a feature is going to break the Web, the first step is to figure out by how much. UseCounter counts (opt-in) which features are used on each page view, so I went ahead and added/improved counters for various things that would be nice to eventually remove: a bunch of prefixed HTMLMediaElement APIs, the TextTrackCue constructor, the beforeload event and the two (!) prefixed fullscreen APIs. There’s also the media attribute on <source>, which is still in the spec, but getting usage data will help us decide whether to remove it.

Fixing bugs

It’s a beautiful thing when you can fix a bug just by removing code, and I did so this month by removing the width and height properties from the <video> intrinsic size logic. After my fix intrinsic size is still not per spec, but at least it’s less wrong.

In my only non-trivial Chromium contribution, I made CookieMonster wait for disk flush when deleting cookies, so that cookies are really gone when the UI says they are. This involved fixing a flaky test, which was fun.

Loading text tracks

I began looking into <track> and WebVTT and soon stumbled upon a FIXME in TextTrackLoader, which is what feeds data to the WebVTT parser. Unable to resist the bait, I refactored TextTrackLoader to use RawResource and removed TextTrackResource. Finally, I fixed some other minor issues and fiddled a bit with the TextTrack IDL.

One year ago

Also this month, one year has passed since my final commit in Core (Presto), which was on October 12, 2012. I was a little bit sad when I noticed this anniversary, but at the same I’m really happy about working on Chromium and Blink. Hopefully the next month will be even better!

Web Technology

The Web Technology team (source)