Stapes.js 1.0.0

stapes

In 2012, more than four and half years ago, i started to work on a small Javascript library called Stapes.js. At that time there was a big upswing in MVC libraries. People were building larger and more complex apps, and were looking for ways to better structure their code.

There were many libraries, but to me they seemed quite complex. Many libraries were more like frameworks: you needed to accommodate your code into their way of thinking, instead of the other way around.

I didn’t like that mentality. So i did what any good nerd would do: i wrote my own library.

I decided early on to follow the UNIX philosophy: do one thing, and do it well. Turns out that my library did three things: class creation, custom events, and data manipulation. But still, that was a lot less than virtually all the other libraries.

Another thing i decided on was that i would write good documentation. A depressing number of libraries, especially Javascript ones, have awful documentation. And even when there is documentation, there are no examples, which to me is the most important thing.

Development proceeded, and applications were built using Stapes. I’m especially proud of the projects at VPRO where i used Stapes, like 3voor12. Apparently, they are still using my little library.

Anyway, the last major release for Stapes was almost three years ago. After that, development has stopped. I occasionally responded to issues and pull requests. But it seems that most people are quite happy with the current state of Stapes.

In the meantime, the world of web development hasn’t stopped. People are building ever more complex apps. They use all kinds of new tools that didn’t even exist three years ago. And the development of the language hasn’t stopped as well: adaptation of ECMAScript 6 (the latest Javascript standard) is looking good, either with or without transpilers like Babel.

So, i need to take a hard look at the future of Stapes. Class creation will be useless because everyone will be using ES6 classes anyway. Custom events are nice, but there are lots of other libraries doing that as well. The data methods are useful, but the implementation in Stapes has never quite hit the sweet spot that i wanted.

And frankly, other people do better. One library that i’m especially fond of is called Vue.js. It shares the same ‘less is more’ philosophy of Stapes, but it’s far more versatile. It’s basically all the good bits of Angular.js 1.x without all the Java-enterprise-like nonsense and complexity.

Which leads me to this conclusion: Stapes simply doesn’t need more than it already has. It’s not dead. It will continue to work fine for your projects, and i might still fix some bugs in the future. But don’t expect any new features or radical changes.

An API that won’t change anymore. No new features. No surprises.

Sounds like the perfect time to finally release Stapes 1.0.0 :)

Brexit

c057065b-a581-43de-915f-997bc26ad4ca

Dit gifje laat zien wat er is gebeurd in het Verenigd Koninkrijk. Je bent van plan iets te doen. Je ouders zeggen “Dat is onverstandig!”. Maar het is ook leuk om lekker tegen je ouders in te gaan. Dan doe je het, en dan opeens realiseer je je (dit is het moment dat het blikje het gezicht van het meisje raakt): hoe hadden we zo dom kunnen zijn? En dan heb je spijt, en moet je huilen.

Volgens mij is het deel van een trend. Weg van de feiten, vertrouw vooral op je gevoel. Weg met de experts.

Een voorbeeld: afgelopen zaterdag stond in de Volkskrant een stuk over ouders die hun kinderen, tegen beter weten in, niet laten vaccineren.

Het is hetzelfde patroon: mensen hebben het gevoel dat ze geen controle hebben over hun leven. Dus doen ze iets waar ze wél controle over hebben: tégen de bestaande conventies, instituten en wijsheid. Een poging terug te keren naar een tijd waarin we zalig leefden van het land, er biggetjes in huis rondscharrelden, en we genoeg hadden aan liefde en gevoel. Dat je waarschijnlijk voor je 40-ste stierf aan de pokken of aan cholera is dan wat minder belangrijk.

Proberen er tegenin te gaan met wetenschappelijk onderbouwde feiten heeft geen zin: mensen gaan dan juist meer in hun eigen ideeën geloven.

Nog zoiets. Ik moest laatst weten of tempeh glutenvrij is (ja). Maar behalve die informatie vond ik ook een alternatieve wereld waarin mensen beweren dat soja ongezond is. Want ‘er zitten stoffen in die de schildklier ontregelen (…) mijn inziens troep‘. Maar anderen zijn het daar niet mee eens, want er zijn ergere dingen: ‘rare westerse producten als aspartaam‘.

Het gaat niet om de vraag of dingen wel of niet gezond zijn, het gaat erom of dingen wel of niet gezond voelen.

Je hoeft niet lang te zoeken om overeenkomsten te zien met de fans van Donald Trump. In the face of all the evidence blijven mensen Trump steunen, ook al liegt hij dat hij barst, en kan hij z’n idiote uitspraken niet onderbouwen.

Van zijn meest significante en nieuwswaardige uitspraken is 77% grotendeels onwaar, compleet onwaar, of volkomen slap gelul (ter vergelijking: Clinton zit op 27%, Sanders op 29%). Trump zegt dat Clinton van plan is om alle criminelen vrij te laten (gelul), dat er duizenden mensen in New Jersey aan het juichen waren op 9/11 (gelul), en dat 81% van de moorden op blanken door zwarten zijn veroorzaakt (gelul).

Maakt dat zijn aanhangers iets uit? Nee, natuurlijk niet.

Dat is ook het deprimerende. Het voelt vast lekker om op Trump te stemmen. Voor ‘leave the EU’. Of iedereen te vertellen dat sojabonen kanker veroorzaken en inentingen autisme.

Maar op een ochtend word je wakker en blijkt dat je geen lid meer bent van de EU en dat je er economisch net zo slecht voorstaat als tijdens de crisis. Dat Donald Trump de leider is van de westerse wereld en op zijn golfbaan aankondigt dat moslims het land niet meer in mogen. En dat kinderen zonder inentingen toch echt ziek kunnen worden en kunnen overlijden.

Natuurlijk, de huidige onvrede heeft diepe en complexe oorzaken. Mensen zijn teleurgesteld in loze beloftes van politici en voelen zich vernederd. Ik realiseer me terdege dat ik deel uitmaak van een hoogopgeleide elite die makkelijk praten heeft.

En ik zou willen dat het antwoord op dit alles “meer kattengifjes” is (sorry).

We moeten ons minder door ons gevoel laten leidden. Maar we moeten niet gevoelloos worden. Ja, we moeten lief zijn voor elkaar.

Succes

deeba877-abf8-4f28-b2d7-8cb954c7b0bb

Een goede vriend van mij vind “succes” een gek woord. Hij heeft gelijk: om “succes” hangt een zweem van stockfoto’s van managers die in de lucht springen met hun duimen omhoog (zie boven).

Toch ga ik het over succes hebben. Mensen vinden het blijkbaar leuk wat ik doe, dus vragen ze me om advies. Wat ik ontzettend leuk vind om te geven en ook graag doe: er zijn weinig dingen zo strelend voor je ego als andere mensen uitleggen wat je doet, en dat ze dan óók nog eens aandachtig luisteren en je later mailtjes sturen dat ze er echt iets aan hebben gehad.

Maar het is ook lastig. Je moet dan je keuzes achteraf gaan analyseren. Dan kom je vaak uit bij one-liners zoals ‘doe, in plaats van denk’. Of ‘volg je passie’. Er bestaan hele industrieën die alleen maar bestaan bij de gratie van het uitgeven van boekjes met dat soort frases.

Alsof je daar wat aan zou hebben.

De beste lessen leer je niet vooraf, maar achteraf. Als je al fouten hebt gemaakt. Of als iemand achteraf tegen je zegt hoe het beter had gekund. Of als je zelf ergens een vaag knagend gevoel hebt dat zegt: ‘dat kan beter’.

En achteraf denk je dan inderdaad: ‘ik had moeten doen, in plaats van denken’. Of: ‘ik had beter naar mijn eigen gevoel moeten luisteren’.

Ook daar koop je niks voor.

Maar toch ga ik een advies geven.

Het is niet belangrijk wat je doet, maar dat je doet.

Dat je doet is dus niet heel lang nadenken. Of vergaderen. Of een groot beleidsstuk schrijven. Je bezig houden met irrelevante details die pas belangrijk zijn bij de uitvoering. Van die bureaucratische dingen.

Dat is dingen doen.

Iemand opbellen. Ergens naar toe fietsen. Iets doen wat je nog nooit eerder hebt gedaan. Een ticket boeken naar een land waar je de taal niet spreekt. Met mensen praten die je niet kent.

Ergo: iets doen zonder dat je al van tevoren weet wat de uitkomst gaat zijn. Experimenteren. Uitproberen. Prutsen.

‘Uit je comfort zone stappen’ heet dat tegenwoordig. Hoe weet je wat je comfort zone is? Makkelijk: bedenk iets dat je gaat doen. Zo. Voel je je nu bang? Angstig? Huiverig?

Goed zo. Dat is buiten je comfort zone. Ga dat doen.

Welkom in 2050

psychic
Er zijn veel manieren waarop je jezelf belachelijk kan maken. Proberen de toekomst te voorspellen is misschien wel de beste. Het klopt nooit, en áls het toevallig wel klopt klinkt het in het heden bizar onwaarschijnlijk.

Maar ik hou van dingen waardoor mensen me belachelijk kunnen maken. Dus ga ik voorspellen hoe het leven er uit ziet over 34 jaar, in 2050.

Hier is het lijstje in het kort. Scroll verder voor de uitleg per voorspelling.

2050 ziet er zo uit:

  1. Iedereen is vegetariër.
  2. Het gebruik van de pil van Drion is gemeengoed geworden.
  3. Geen lid zijn van een sociaal netwerk is een strafbaar feit.
  4. Alcohol drinken is net zo ‘fout’ als roken nu.
  5. Vliegen is een luxe, en daardoor is digitale communicatie veel innovatiever dan nu.
  6. Contant geld is verleden tijd geworden en offline winkelen een uitje.
  7. Engels is de voertaal in vrijwel alle niet-persoonlijke communicatie.
  8. De realiteit is niet meer wat het is geweest.
  9. ‘Staat’ is een vreemd begrip geworden.
  10. Veel blijft ook hetzelfde.

1. In 2050 is iedereen vegetariër

Steeds meer mensen eten vleesvervangers. Of kweekvis. Insecten zitten al in het standaard assortiment van de Jumbo. En in 2050 is kweekvlees vast ook ruim verkrijgbaar.

En zeg nou zelf: de kwaliteit van nepvlees is toch inmiddels al zo goed dat het bijna niet meer te onderscheiden is van echt?

“Echt” vlees wordt in 2050 nog wel gegeten, maar alleen als je een keer ‘luxe’ uit eten gaat, bijvoorbeeld in de retro-snackbar (“Bitterballen met écht vlees, dat ken ik nog uit mijn jeugd!”). Eater.com schreef al eens een recensie over een retro-restaurant in 2081 waar je nog echt vlees kan krijgen.

Doordeweeks eten mensen aardappelen, groentes en een goed stuk kweekbiefstuk.

2. In 2050 bestaat de pil van Drion (en wordt sterk aangeraden)

Als je denkt dat we nu al veel merken van de vergrijzing stel je dan de situatie voor in 2050: veel van de babyboomers uit de jaren 50 leven dan nog steeds dankzij de steeds beter wordende gezondheidszorg. Een enorm probleem, want wie gaat al die zieke hoogbejaarden verzorgen? Vanaf 2040 krimpt de beroepsbevolking en niet iedereen kan of wil bejaardenverzorger worden.

Nu is het nog een misdaad om 99-jarigen te helpen als ze zelf vinden dat hun leven ‘voltooid’ is, in 2050 is het de gewoonste zaak van de wereld. Sterker nog: mensen boven de 80 die weinig eigen geld of kinderen hebben om in hun eigen levensonderhoud (en medische kosten) te voorzien zal de pil van Drion als alternatief worden aangeboden in plaats van minimale verzorging.

3. In 2050 is geen lid zijn van een sociaal netwerk een strafbaar feit

Over dertig jaar zijn de begrippen privacy en ‘persoonlijke levensfeer’ volkomen onbelangrijk geworden. De onthullingen van Edward Snowden tonen aan dat de overheid ons de hele tijd in de gaten houdt. In 2050 is het echter volkomen geaccepteerd dat je lid bent van een, door de overheid gecontroleerd, sociaal netwerk, al dan niet in nauwe samenwerking met een groot bedrijf als Facebook of Google. Geen lid zijn is dan net zoiets als er voor kiezen om geen paspoort te hebben.

Als je te veel online artikelen leest over illegale zaken krijg je een coach langs die moet uitzoeken of je niet aan het radicaliseren bent. Het gevolg is ook dat al je acties vastgelegd worden en gedeeld met bijvoorbeeld verzekeraars. Een zorgverzekering aanvragen wordt onbetaalbaar als je bijvoorbeeld meer dan een biertje per dag drinkt.

Steeds meer mensen zullen daarom onverzekerd door het leven gaan. Jezelf behoeden voor je eigen fouten is te duur geworden. Maar een minderheid zal er juist trots op zijn om niet verzekerd door het leven te gaan: een leven zonder zekerheden is ook wel weer spannend.

4. In 2050 is alcohol voor sukkels

In de jaren vijftig was het simpel: als je niet rookte deed je dat omdat je ziek was. Anders was je gewoon een beetje raar. Tegenwoordig moet je jezelf verantwoorden als je niet elk weekend laveloos in de kroeg staat met je tiende vaasje.

Maar in 2050 wordt je met je tiende biertje direct naar een heropvoedingskamp gestuurd. Meer dan sporadisch alcohol drinken (en dan bij voorkeur alcoholvrij of alcoholarm) is voor de zwakken.

Je ziet het al op bijvoorbeeld muziekfestivals in Scandinavië: daar mag je alleen alcohol drinken in speciaal daar voor aangegeven gebieden. En zelfs Jan Smeets van Pinkpop dacht in 2012 dat het in 2017 ook op Pinkpop ook al het geval zou zijn.

In 2050 ga je ‘naar buiten’ of naar ‘het bierhok’ als je een biertje wilt drinken. Niet erg gaaf, en daarom alleen iets voor de verstokte alcoholisten. Bovendien is alcohol in 2050 een stuk duurder: denk de prijzen die je nu betaalt in Noorwegen of Finland.

5. In 2050 zitten mensen liever in de cloud dan in de lucht

Het meest milieuvervuilende wat je kan doen, na kinderen krijgen, is vliegen. En ook al gelooft een minderheid van de wereldbevolking dat het met de opwarming van de aarde wel meevalt, in werkelijkheid zijn er al genoeg bedrijven die minder energie gebruiken en duurzamer werken. Niet omdat het beter is voor het milieu, maar ook omdat het simpelweg geld scheelt. Vliegen wordt dus weer iets voor de happy few, net zoals een jaar of vijftig geleden.

Wat gaan mensen dan doen? Manieren om niet-lijfelijk met elkaar te communiceren worden steeds innovatiever. Zoals bijvoorbeeld de double, een iPad op wieltjes die je op afstand kan besturen. Het lijkt een gimmick, maar er zijn ook mensen die letterlijk niet zonder kunnen.

Iedereen doet nu natuurlijk al aan Skype en gewoon ouderwets bellen, maar in 2050 is het zo ingeburgerd dat het nog nauwelijks uitmaakt waar je bent: communicatie verloopt voor het overgrote deel digitaal.

6. In 2050 is contant geld verleden tijd en offline winkelen een uitje

Hoe lang blijft contant geld nog bestaan? Er zijn al veel winkels die pin-only zijn. Niet alleen veilig, maar ook fijn voor de overheid die alles kan volgen (zie voorspelling #3). In 2050 is contant geld óf verboden, óf alleen nog maar in gebruik bij louche massagesalons en voor hele kleine betalingen (denk onder de €20).

Straten in het centrum zullen in 2050 trouwens een stuk minder winkels bevatten. Dat zie je nu al doordat winkelen verschuift naar het internet. Boeken en muziekwinkels sluiten, Vroom en Dreesman is niet meer en hoe vaak bent u de afgelopen tien jaar nog binnen geweest bij een reisbureau?

In 2050 zullen winkelstraten vooral bestaan uit servicezaken, zoals kappers en schoonheidssalons, horeca en winkels waar je pakjes op kan halen en misschien een reep chocola kan kopen.

7. In 2050 is Engels de voertaal in vrijwel alle niet-persoonlijke communicatie

Het basisonderwijs in Nederland is in 2050 volledig dubbeltalig (of wellicht drietalig, met Spaans of Mandarijn als derde taal), een grote minderheid van het onderwijs is zelfs geheel Engelstalig. Vanaf de middelbare school is het grootste deel van de lessen Engels, als je op een HBO of Universiteit nog Nederlands spreekt doe je dat alleen in de pauze met je Nederlandse vrienden.

8. In 2050 is ‘staat’ een diffuus begrip geworden

Landen bestaan in 2050 nog wel, maar het zijn er een stuk meer dan in 2016, en je zult ze niet gelijk herkennen als land. Veel landen zijn opgesplitst (denk Vlaanderen en Wallonië, Californië), maar er zullen ook gebieden zijn die we nu niet als land zouden (h)erkennen. Nu zijn er al gebieden waar andere regels geleden om de economie te stimuleren, zijn er ‘gated communities’ en kun je in Japan je laatste rustplaats hebben in een bedrijfsgraf.

In 2050 is dat nog veel extremer doorgevoerd en hebben ‘bedrijfszones’ misschien wel eigen wetten en worden ze erkend als aparte staat.

9. In 2050 is de realiteit niet meer wat het is geweest

De realiteit staat onder druk. Door het uitkomen van de Oculus Rift is Virtual Reality (VR) voor het eerst bereikbaar voor de massa, en andere technieken, zoals de Hololens van Microsoft, laten zien dat ook Augmented Reality (AR) mogelijk is. Daarnaast is de software zo goed geworden dat het onmogelijk is om met het blote oog nog het verschil te zien tussen computergegenereerde beelden en fotografie of video. Nu al heb je al technieken om gezichten perfect te animeren.

Het gevolg zal zijn dat er de komende decennia veel discussies zullen worden gevoerd over wat ‘echt’ is. Dode acteurs zullen vervolgen maken op hun populairste films. Mensen zullen onterecht worden opgesloten omdat camerabeelden zijn vervalst met dit soort technieken. In 2050 zullen die discussies er nog steeds zijn, maar zal het grootste deel van de mensheid hebben geaccepteerd dat realiteit verleden tijd is geworden.

10. Veel blijft ook hetzelfde.

2050 is heel anders dan 2016, maar veel dingen blijven ook hetzelfde.

  • Mensen klagen nog steeds over het weer. En daar kunnen we, ook in de verre toekomst, niks aan doen.
  • Er is geen medicijn gevonden tegen de meeste vormen van kanker en tegen AIDS. Wel zijn de vooruitzichten een stuk beter, en de behandelingen veel effectiever en minder ingrijpend. Maar hét geneesmiddel tegen al die nare ziektes is er nog niet.
  • We kunnen nog steeds niet tijdreizen of eeuwig leven.
  • Nederland is nog steeds een koninkrijk met een net gekroonde nieuwe Koningin Amalia.
  • We hebben nog steeds de Euro en de Europese Unie. Wellicht is de EU dan wel wat kleiner, zo  zonder de UK, Griekenland en een paar Oosterse staten.

En misschien wel het ergste: ook in 2050 is NEC nog steeds nooit landskampioen geweest.

Tot in 2050!

Handling complex nested dicts in Python

Python is a lovely language for data processing, but it can get a little verbose when dealing with large nested dictionaries.

Let’s say you’re using some parsed JSON, for example from the Wikidata API. The structure is pretty predictable, but not at all times: some of the keys in the dictionary might not be available all the time.

Consider a structure like this:

animals = [
    {
        "animal" : "bunny"
    },
    {}
]

If you would try to directly access the animal property in a fashion like this:

for item in animals:
    print item["animal"]

You would get an error like this:

bunny
Traceback (most recent call last):
    KeyError: 'animal'    

Because the animal key is missing in the second item in the list. You could use the handy get method:

for item in animals:
    print item.get("animal", "no animal available")

The second argument to get is a default value that will be used if the key is not available:

bunny
no animal available

Excellent! However, this leads to problems when having a nested structure:

animals = [
    {
        "animal" : {
            "type" : "bunny"
        }
    },
    {
        "animal" : {}
    },
    {}
]

You could nest the get statements

for item in animals:
    print item.get("animal").get("type")    

But leads to an error because the animal key is lacking in the third item.

You could do something like this:

for item in animals:
    if "animal" in item:
        print item.get("animal").get("type")    

But with deeply nested structures (i counted seven levels in the Wikidata API) this gets unwieldy pretty fast.

Wouldn’t it be awesome if you could simply do this?

for item in animals:
    print item.get("animal/type")

Note the / in the get method.

Unfortunately, this is not possible in vanilla Python, but with a really small helper class you can easily make this happen:

class DictQuery(dict):
    def get(self, path, default = None):
        keys = path.split("/")
        val = None

        for key in keys:
            if val:
                if isinstance(val, list):
                    val = [ v.get(key, default) if v else None for v in val]
                else:
                    val = val.get(key, default)
            else:
                val = dict.get(self, key, default)

            if not val:
                break;

        return val

Now you can do this:

for item in animals:
    print DictQuery(item).get("animal/type")

bunny
{}
None

Nice, huh?

De belachelijke wachtwoordeisen van de Belastingdienst

Wachtwoorden zijn net als puisten. Iedereen heeft ze, maar je gaat er niet uitgebreid over orereren tijdens de vrijmibo. Toch moeten we het even over wachtwoorden hebben, met dank aan de Belastingdienst.

Afgelopen week deed ik aangifte. Mijn wachtwoord was verlopen vanwege “nieuwe veiligheidseisen”. Als klein tipje kreeg ik vast wat eisen waar mijn nieuwe wachtwoord aan moest voldoen:

3381de49-dece-48dd-9cd9-f922dbf59f7c

Ik moest gelijk denken aan dit klassieke Dilbert-stripje:

5945df16-8a42-427b-9316-ea0567ac531c
Even een experimentje: dit zijn wachtwoorden die volgens deze wachtwoordtester van Dropbox ‘eeuwen’ duren om te kraken. Maar bij de Belastingdienst zijn ze niet geldig:

  • zoh8Cea6ah@2Mui6iezaev4ieduo0g (te lang)
  • uYiRaenoeaoV (geen speciale tekens)
  • ahxaith4oov7oh! (geen hoofdletters)
  • #uad2airuWah0a (vier keer de letter ‘a’)

Hier zijn een paar wachtwoorden die wél geldig zijn:

  • Password1
  • Welcome2
  • Hello123

Leuk detail van dit lijstje: al die wachtwoorden komen uit de lijst van de 20 meest gebruikte wachtwoorden. Niet zo veilig dus, en volgens de wachtwoordtester te kraken in minder dan een seconde.

Dit is trouwens een interessant detail uit het lijstje (met dank aan Niels voor het spotten):

04a6b6c3-5a54-416c-8a63-e96160764767

Dit is een beetje curieus. Het kan namelijk de suggestie wekken dat de Belastingdienst wachtwoorden niet veilig versleuteld opslaat.

Dat zit zo: als je het goed doet sla je wachtwoorden nooit ‘zo’ op in een database. Ze worden altijd versleuteld door hashing. Dat hashen gaat maar één kant op: je kan een hash berekenen van een wachtwoord, maar andersom kun je niet terug van hash naar wachtwoord.

Ondanks dat je het wachtwoord zelf niet weet kun je wel controleren dat het klopt: de hash van wat iemand intikt bij een inlogscherm moet matchen met de hash in de database. Je vergelijkt dus nooit twee wachtwoorden, altijd twee hashes!

Als je dit mechanisme gebruikt (wat praktisch alle grote internetbedrijven doen) is het onmogelijk om te zien welke karakters er in een oud wachtwoord voorkomen.

Zowel in de comments hier beneden als op Twitter wordt gesuggereerd dat de BD wél veilig toegang heeft tot je wachtwoord, namelijk op het moment dat je het oude wachtwoord moet intikken. Dan zouden ze die check kunnen doen. Dat is een goed punt, maar helaas weten we niet op welke manier de Belastingdienst die check uitvoert.

Ook is er de eis dat je wachtwoord anders moet zijn dan je vorige wachtwoorden (meervoud). Je zou alle vorige wachtwoorden als hash kunnen opslaan, en het op die manier kunnen checken. Maar waarom zou je dat doen? Het creëert alleen maar extra complexiteit in het systeem en het voegt geen echte verbeteringen toe in de veiligheid.

Wat zou de Belastingdienst dan wél moeten doen? Zoals je kan lezen in dit inmiddels klassieke stripje van XKCD en dit lange technische artikel van Jeff Atwood is de oplossing simpel: eis gewoon langere wachtwoorden (minimaal 12 tekens), zónder al die gekke regels. ‘appelmoes kerk paars konijn’ is als wachtwoord eindeloos veel veiliger én beter te onthouden dan ‘B3l@st!ng’ en alle andere lelijke varianten.

Alle huidige bizarre regels zorgen er voor dat mensen slechte wachtwoorden bedenken die niet veilig zijn. En ze maken het én niet leuker én niet makkelijker. Zonde.

Naschrift: in een eerdere versie van dit artikel werd stelliger gezegd dat de Belastingdienst wachtwoorden onveilig opslaat. Dat heb ik aangepast na commentaar op dit blog en de gelinkte tweet.

Het lijstje, editie 2015

Er zijn enkele zekerheden in het leven rond het einde van het jaar: pijnlijke kerstdiners met je schoonfamilie, te veel geld betalen voor een matig feestje met oud en nieuw en het lijstje, mijn jaarlijkse opsomming van het mooiste en het beste op muziekgebied.

Ik doe dit al twaalf jaar. Daardoor zijn er inmiddels patronen te herkennen. Zoals een soort omgekeerde Star Trek Movie Curse: oneven muziekjaren lijken beter te zijn dan de even jaren. En inderdaad: 2015 was een goed jaar! Wel jammer voor volgend jaar, want dat gaat dus bagger worden. Ook opvallend: net zoals in 2010 hebben Sufjan Stevens en Joanna Newsom een nieuw album uit dat hoog staat in deze lijst. En zoals altijd is het veel alternatieve muziek met een elektronisch randje (of andersom) en zo af en toe een uitstapje richting de hiphop en R&B.

De twintig van 2015

  1. Jlin – Dark Energy
  2. Joanna Newsom – Divers
  3. Sufjan Stevens –  Carrie & Lowell
  4. Father John Misty – I Love You, Honeybear
  5. Tame Impala – Currents
  6. Björk – Vulnicura
  7. Natalie Prass – Natalie Prass
  8. Floating Points – Elaenia
  9. Grimes – Art Angels
  10. zZz – Juggernaut
  11. Oneohtrix Point Never – Garden of Delete
  12. Deafheaven – New Bermuda
  13. Jamie xx – In Colour
  14. Panda Bear – Panda Bear Meets the Grim Reaper
  15. Miguel – WILDHEART
  16. Kurt Vile – b’lieve i’m going down…
  17. Kendrick Lamar – To Pimp a Butterfly
  18. Aphex Twin – Computer Controlled Acoustic Instruments pt2 EP
  19. FKA Twigs – M3LL155X
  20. Beach House – Depression Cherry

Ik heb ook een YouTube playlist gemaakt met van vrijwel alle albums hierboven een representatief nummer én, gewoon omdat het lekker is, Run Away With Me van Carly Rae Jepsen.

Videostill door Iris van Vliet

Dan het beste concert van 2015: Joanna Newsom in TivoliVredenburg zou een eenvoudige keuze zijn. Maar laat ik dat eens niet doen. De launch party van het nieuwe album van zZz in OT301 was behoorlijk legendarisch. Ik denk dat ik zo’n beetje enige was die geen drugs op had, in die kolkende massa in dat veel te kleine zaaltje. Beste concert van het jaar!

Talk Talk - Laughing Stock

De herontdekking van dit jaar vond eigenlijk al plaats in 2014, maar mag ook dit jaar nog best genoemd worden: Talk Talk, en dan vooral de laatste twee albums Spirit of Eden en Laughing Stock heb ik de afgelopen 24 maanden vaak gedraaid. Wat een briljante muziek. Heel gek om dan te lezen dat Mark Hollis, het brein achter de band, na zijn soloplaat in 1998 eigenlijk nooit meer iets heeft uitgebracht. Blijkbaar had hij alles gezegd en gespeeld wat hij wilde.

Dat was het voor dit jaar. Voor meer lijstjes zie Sander Spek, Pitchfork, Best Ever Albums, The Guardian, Metacritic, Tiny Mix Tapes, Plato, Kindamuzik, Rate Your Music en 3voor12.

Als je benieuwd bent wat ik de afgelopen 12 jaar (!) leuk vond: hier zijn de edities van 2014, 20132012201120102009, 2008, 2007, 2006, 2005, 2004 en 2003.

What i do after a fresh Mac OS X install

I recently had the ‘pleasure’ of freshly reinstalling Mac OS X ‘El Capitan’ on my MacBook Pro. As an experiment, i took notes on what i did after that: what settings i changed, which apps i installed and other tweaks i did.

Tweaks and settings:

  • Remove useless apps from Dock (Facetime, Maps, etc)
  • Copy ‘home’ directory from backup disk
  • Removing useless shortcuts from Finder sidebar (“All my files”, iCloud, etc)
  • Copy keychains and set as default
  • Drag the dock to the left instead of bottom
  • Enable ‘don’t rearrange spaces’
  • Enable ‘don’t correct spelling’
  • Enable full keyboard access
  • Disable natural scrolling
  • Enable ‘Show path bar & status bar’ in Finder
  • Increase tracking pad speed a few notches
  • Enable sound volume slider in menu bar (not all of my keyboards have volume keys)
  • Add signatures in Mail.app
  • Enable ‘Show on desktop: hard disk’
  • Enable ‘New finder window shows home directory’
  • Enable ‘When Searching, search current folder’
  • Don’t show warning when changing an extension
  • Set computer name to something meaningful and easy to remember
  • Copy .ssh settings
  • Disable gamed daemon
  • Snap to grid for desktop icons
  • Hot corners: top left for all applications and bottom right for desktop
  • Add nice custom backgrounds for desktop spaces
  • Play a sound when the volume changes
  • Set mouse speed to maximum
  • Add keyboard shortcuts for fast moving of mail messages to folders
  • Enable ‘show date in menu bar’

Apps / packages i install, in order of importance

  • Chrome
  • Sublime Text
  • Spectacle (if you don’t know this app, check it out)
  • Macpass
  • Mamp
  • Dropbox
  • Google drive
  • Xcode
  • Spotify
  • Echofon
  • Legacy java
  • Cafeine
  • Imageoptim
  • Telegram
  • Nvalt
  • Slack
  • Transmission
  • Torbrowser
  • Virtualbox
  • Vlc
  • Office
  • Brew
  • Compass
  • npm

The future and the tightrope: Fronteers 2015

fronteers15-header

The last two days i’ve been attending the Fronteers 2015 conference in the Tuschinski theatre in Amsterdam. This was my fifth Fronteers conference, i was there in 2014, 2012, 2011 and 2010 as well.

The mix of talks was ideal: from the extremely technical (MPEG decoders in Javascript and WebAudio) to more higher-level presentations on team management and digital governance.  The team of volunteers making it all happen got a well-deserved standing ovation at the end of the conference.

Not just boys anymore

Of the 16 presentations, 6 were given by female speakers. That’s over a third. In 2010, five years ago, there were just 2 female speakers. Because we don’t want to have a web that’s primarily target towards white guys living in the Bay Area, it’s extremely important to have speakers that are as diverse as the world itself. If we want to have more woman in tech, we need role models to show that girls can code just as well as boys. So i loved the fact that one of the most in-depth technical talks, about the WebAudio API, was given by Soledad Penadés, who didn’t stop coding because she was a girl.

We need CMS as a service

For me, the most interesting talk that directly related to my work was the one by Phil Hawksworth on static sites. Because building static sites is basically all i do nowadays at de Volkskrant this talk was especially useful to me. Phil briefly mentioned ‘content as a service’ as one of the key pieces in a static site infrastructure. Unfortunately it also seems to be the thing that’s not widely available right now.

I’ve written before on how the perfect CMS should just be a CMS for an API instead of a site, this is basically the same line of thought.

Contentful is a CMS-as-a-service that is mostly following this route, but for now i don’t really like to bet on a proprietary solution. I would love to see some (open source) development in this area.

The future and the tightrope

You can’t have a frontend conference without talks about browser features that aren’t (yet) widely implemented and tips and tricks to improve performance. It was fascinating to hear about the new possibilities with service workers and ‘above-the-fold’ CSS rendering. And i think Chris Heilmann is right in ranting about how webpages still take up too much space, use too many requests, and don’t work without Javascript.

On the other hand, there is a reason why so many webpages are like that and i think it was best explained by the highlight of this conference: Primate’s talk about “the tightrope between mediocracy and bankruptcy”. In an entertaining and, at times, hilarious presentation, Espen, Bart and Gordon brilliantly explained the difficulties every small and medium-sized web agency faces. From the balance between using mediocre templates (that are cheap) or custom designing every piece of content (which is expensive) to the choices of having no clients or bad clients, they were spot-on.

Simply put: you just can’t put every single ‘best practice’ in practice because, well, you’ll go broke.

It’s fine to put every cutting-edge technology in your app if you’re Google or Facebook (because you have a virtually endless supply of money), but if you’re a regular company, you need some very good reasons to introduce such technology, because those developers don’t come cheap, and they’re not doing something your client will happily pay for.

That doesn’t mean you should never use anything cutting-edge in your sites, it just means that you need to consider the advantages and disadvantages, the exact thing your client is asking, and how much time and money you can spent.

To sum it up in that two-word developer cliché: it depends.

See you next year in April!

Tackling video and audio on the mobile web

Imagine that you’ve got this cool project where you’re building a multimedia scrollstory for the web. There’s some great video and audio content, the designer has made some really nice looking visuals, all you’ve got to do now is to bring it all together in a fantastic interactive extravaganza.

And then suddenly there’s a voice somewhere in the back of your head: wasn’t there something with audio and video on mobile webbrowsers?

The touch revolution has given us wonderful new possibilities, but also a lot of headaches on how to translate the desktop web experience to mobile and tablet. Audio and video might be one of the biggest hurdles.

So, what are those problems? And more importantly: how can we fix them?

Problems

Let’s start with the problems. Basically, there are three major problems with media on mobile.

  1. The biggie: on both iOS and Android (this includes both mobile and tablet devices) it is not possible to ‘autoplay’ a media file. What this means, in practice, is that you always need a user action to initiate an audio or video play, such as a button click. For ‘narrative video’, such as a YouTube embed, this is usually not a big problem, but it can be very frustrating when you’re trying to use video as a background layer (example).
  2. Only on iOS mobile (hence: iPhone and iPod touch) video will always start in a separate player, outside of the browser. This means that you can’t layer text or images over the video. It also means that the user gets taken out of the experience in the browser. Like the autoplay problem, this is mostly acceptable for ‘narrative video’, but awful for background video. Note that this problem does not apply to audio.
  3. On iOS (both tablet and mobile) you can only play one media file at the same time. When you have two videos on a page, you have one of them playing and you hit ‘play’ on the other, the first one will pause.

There are some minor problems too. I won’t delve too deep into these points, it’s just so that you know it when you encounter them:

  • On both iOS and Android video files play in another process than the browser. This means that there might be some quirky edge-cases, such as having a different user agent when playing a media file (something like ‘Quicktime’ instead of ‘Safari’) and files that won’t work if they’re located in a folder that is behind basic authentication.
  • Support for subtitles (using the WebVTT standard) can be buggy. For example, styling the titles is limited on iOS and might lead to some weird bugs as well, such as videos not playing, even if their paused property says true. Also: the ‘subtitles’ button in the video interface sometimes randomly decides to turn off.

Solutions

I could spend this whole article about why these restrictions exist on mobile, and whether they should be there or not.

I won’t. Let’s just say that there are some good reasons why you don’t want to have autoplay video on mobile (think sleazy advertisements) and some good reasons why you do (that wonderful multimedia project that you want to build). Instead of pointing fingers, let’s look at possible solutions.

First of all: there doesn’t exist one simple and easy solution that will fix all of these problems. There are some stable workarounds and others that are more experimental.

  • One solution to the autoplay problem is to only use one single video element and change the source instead of creating a new element. Then, you can ‘save the first click’ and use the event handler to switch between sources. You could even fade the video out, then change the source, then fade in again to have a slightly less clunky transition between two videos. I’ve created an example here (try it on your iPad!). This is a decent solution, but there are a few disadvantages. One of them is that switching still takes quite some time, i’ve timed it to around five seconds or so. Especially if you want to have smooth transitions (such as in a scroll story), this might be unacceptable. Also, this method doesn’t fade audio in and out. Remember that this solution won’t fix problem #2 and #3.
  • Another autoplay solution, especially applicable to audio, is using audio sprites. Instead of having different audio files you stitch them all together in one big file and move the current time. Another decent solution, but this takes a lot more work and overhead, and is probably unusable for video because of the file size. Also, you can still only play one sound at the same time.
  • Yet another autoplay solution, only applicable for audio, is to use the Web Audio API. Here’s an article about how to use it on iOS. Unfortunately the Web Audio API is not supported on any version of Internet Explorer and the stock Android Browser (Chrome for Android does support it), so you need to use other solutions for those browsers. You could try using something like Howler.js to make it work on all platforms.
  • A more experimental approach is to use a Javascript video decoder and play the video in a <canvas> tag. This actually works and, in theory, solves all three problems. There are a few big drawbacks though. The audio track doesn’t play at all, the browser needs to download the complete file first and, because it’s such an experimental technology, you might run into problems that are difficult to debug. Also, because the decoding is not hardware accelerated (native video is) this can be too demanding on older devices and result in choppy playback. There’s a decoder for MPEG1 (larger files, but better performance), and one for MPEG4 (smaller files, but buggier with slower performance).
  • One method pointed out to me by Daan Louter from the Guardian is crossfading a couple of JPEG files in and out. This works especially well if you don’t have a lot of movement in your ‘video’.
  • Don’t rule out the honourable Animated GIF. It tackles all three problems, but there are some obvious downsides. No audio again, and GIF is a very limited format. You can’t have more than 256 colours, and longer files of higher resolution tend to get really huge (think dozens of megabytes) pretty quickly. But for some usecases, that might not be a problem.

Some recent libraries have tried other hacks, especially for iPhone. All these libraries are experimental, so make sure you thoroughly test them out before using  in production.

  • The library iphone-inline-video solves the problem by not actually ‘playing’ the video, but by updating the slider 25 times per second. You can see a simplified example of this technique here (iPhone only).
  • Canvasvideo.js copies the content to a <canvas> tag and also enables audio.

Rethinking the problem

Another solution is to completely rethink the app. Video and audio might be problematic, but why use them at all? Instead of using video to give the user a nice experience, maybe you can get the same thing while using CSS animations or the <canvas> tag.

The elephant in the room is of course going native. All of these problems don’t exist when you’re building an Objective-C / Swift (iOS) or Java (Android) app. But going native brings it own problems, including the need to develop three times if you want to reach the widest audience (iOS, Android and web for desktop), the loss of easy sharing using URLs, the hassle of going through the App / Play store and the fact that mobile developers don’t come cheap.

When all else fails, there’s always the obvious and easiest solution: use click-to-play video when possible, and still images when there’s no other option. But it’s a bit sad that mobile users will get a watered-down version of the desktop experience.

In the end it all comes down to what you really think is important and which tradeoffs you’re willing to take.

Do you have any other solutions or workarounds? Add them in the comments.