Skip to content

Youtube search API

Eén van de laatste oefeningen in de PHP cursus waarin ik in mijn vorige bericht over schreef. gaat over het implementeren van een API om Youtube te doorzoeken en gevonden video’s te tonen. Helaas is het gebaseerd op een oudere, niet meer beschikbare versie van de API. Alhoewel ‘helaas’… Niets is zo leerzaam dan een vraag beantwoorden waarvoor het tekstboek geen antwoord heeft.
Het was niet moeilijk om de opdrachten in het boek te maken op basis van een nieuwe, geheel andere API en het ligt voor de hand om er een tutorial over te schrijven. Maar als ik alleen de stappen beschrijf en de links geef naar sites die ik heb geraadpleegd, dan wordt het ook wel duidelijk.

1. Google’s Youtube data API

Google heeft een uitgebreide handleiding voor het implementeren van de Youtube Data API. Een aparte sectie gaat over Search. De subsectie List laat alle API calls en responses zien en geeft voor verschillende scripttalen implementatievoorbeelden. Ik heb gewoon het voorbeeld ‘PHP #1’ integraal gekopieerd en in een PHP bestand geplakt (link).

2. Composer

De kans is groot dat het voorbeeld PHP script in de browser een foutmelding geeft vanwege het ontbreken van een vereiste PHP bibliotheek (Google API client library.) In het voorbeeld script staat keurig uitgelegd wat je moet doen om de bibliotheek te verkrijgen. De aangeboden oplossing is op basis van Composer. Eventueel moet die dus eerst worden geïnstalleerd (link).

3. Google API client library

Het enige wat je blijkens Composer zelf nodig hebt is composer.phar in de applicatie directory (bijv. /var/www/mijnapp/). De Google API client library kun je daarna installeren zoals omschreven in het voorbeeld script…

php composer.phar require google/apiclient:~2.0

Deze opdracht genereert een composer.json bestand en installeert de library en andere vereisten in een nieuwe subdirectory ‘vendor’. Ik kreeg tijdens de installatie waarschuwingen die ik heb genegeerd omdat ik niet verwacht dat die de oefening blokkeren.

4. Google API key.

Versie 3 van de Youtube data API vereist een API key. De stappen om die te verkrijgen staan in de link bij deze paragraaf. In het voorbeeld script staat keurig aangegeven waar de sleutel moet komen. Let wel: Google API’s werken met quota. Voor mijn oefening maakt dat niet uit want het script staat alleen op localhost. Maar in een productieomgeving is het iets om rekening mee te houden (link).

5. Experimenteren

Het voorbeeldscript van Google geeft een html input tekst veld waar een zoekopdracht in kan worden getypt. Het resulaat is een lijst met gevonden video’s zonder de links maar met de videotitels en – id’s. De documentatie (link paragraaf 1) biedt echter genoeg handvaten om er iets moois van te maken.

6. Composer en Google API client library (edit 9 maart 2017)

“Did you see what just happened?”

Het resultaat van de stappen hierboven voor de cursusopdracht is een lijstje met links naar vijf video’s. Hiervoor heb ik blijkbaar 5444 bestanden, in totaal 15,5 MB moeten downloaden (what??!!.) Ik voel aan mijn theewater dat voorzichtigheid, zo niet terughoudend op z’n plaats is bij het integreren van 3r party code. Niet alleen vanwege de omvang, maar ook omdat je feitelijk niet weet wat je in huis haalt.

Of weet ik gewoon niet beter, want nog steeds een noob?

Uitstapje naar de back-end

Sinds januari staat de ontwikkeling richting front-end development even op een zijspoor. Er is om het zo te zeggen een PHP (beginners) cursus op mijn pad gekomen. Vanwege de sites en webapplicaties die ik in het verleden op basis van Drupal en WordPress heb ontwikkeld, ben ik enigszins bekend met PHP. Maar het beperkte zich veelal tot het opzetten van templates en zo nu en dan een script patchen.
Deze week rond ik de cursus af en ik moet toegeven dat ik niet meer zo zeker weet of ik een front-end specialist wil worden. ‘Full-stack’ developer lijkt ineens een stuk aantrekkelijker. De leerweg wordt in dat geval echter ook weer wat langer. De PHP cursus was gebaseerd op procedureel programmeren in PHP 5.0. Daarom ben ik alvast begonnen met een doorstart richting Object Oriented Programming, om vervolgens met een framework als Laravel te leren werken.
Wat me het meest is opgevallen bij PHP? Dat ik het gemakkelijker te leren vond dan Javascript. Of zeg ik dat omdat ik eerder al zoveel met JS bezig ben geweest?

Twee redenen waarom Firefox beter is dan Chrome

De meeste mensen kiezen geen browser. Ze gebruiken de browser die hen wordt aangereikt. Safari dus, of Edge. Veel power users kiezen voor Chrome omdat deze de reputatie heeft snel en simpel te zijn. Slechts een kleine groep mensen kiest op basis van eigen vergelijkend onderzoek. Zij komen misschien uit bij Opera, Firefox of nog iets anders.

Achter Safari, Edge en Chrome zitten grote multinationals (Apple, Microsoft en Google). Hun browsers zijn goed en worden steeds beter. Maar de populariteit van die browsers wordt bepaald door marketing. Alternatieve browsers zijn niet per definitie beter, maar ook zeker niet slechter. Het is niet erg dat ze in de schaduw staan van de grote browsers, maar het zou een ramp zijn als ze helemaal verdwijnen. Daarmee zou ook hun invloed op de ontwikkeling van het World Wide Web verdwijnen.

Daarom hier maar eens een pluim opsteken voor Mozilla’s Firefox. Dit is een open source browser van een non-profit* organisatie die geen ander belang heeft dan een onafhankelijke browser te ontwikkelen. Firefox is beter dan Google Chrome omdat:

  • werken met verschillende profielen veel gemakkelijker is
  • het gebruik van meerdere tabbladen efficiënter is

Als je de browser intensief gebruikt (werk, zakelijk, gezondheid, hobby / vrije tijd) dan is het fijn om verschillende profielen te gebruiken. In ieder profiel kun je afzonderlijke add-ons gebruiken en desnoods ook verschillende accounts bij sociale netwerken. Zowel Chrome als Firefox ondersteunen dit. Maar bij Firefox kan je eerst een profiel kiezen en daarna pas de browser laten openen. Bij Chrome moet dat andersom. Net even wat lastiger.

In Firefox kun je instellen dat bij een herstart alleen de gepinde tabbladen en het actieve tabblad worden geladen. De andere tabbladen worden pas geladen als je deze actief maakt. Bij Chrome worden bij een herstart alle tabbladen geladen. Stel je eens voor hoeveel extra tijd dat kan kosten.

Natuurlijk snap ik ook wel dat niet tabbladen of profielen, maar snel en simpel de belangrijkste kenmerken van een browser zijn. En als je developer bent is wat er achter F12 zit ook niet bepaald onbelangrijk. Wat mij betreft doen Firefox en Chrome op dergelijke punten niet voor elkaar onder.

Firefox logo Probeer Firefox

* Mozilla heet officieel Mozilla Foundation, inderdaad een organisatie zonder winst-oogmerk. Maar onder de paraplu van de foundation zit ook de Mozilla Corporation. Dit bedrijf maakt wel winst. Winst die gebruikt wordt om de medewerkers van Mozilla te betalen én om in de browser te investeren.

Vanille JavaScript

Als je bedenkt dat ik sinds 1995 connectie heb en van het begin af aan met html heb gespeeld, dan zou je misschien verwachten dat ik de evolutie van JavaScript van dichtbij heb meegemaakt. Maar JS en ik waren nooit zo intiem. In mijn webmanager periode (ook alweer meer dan vijf jaar geleden) was ik altijd blij als ik een snippertje script of een complete JQuery module van het web kon kopiëren om in mijn project te plakken.

Tijdens mijn Functioneel Beheer jaren heeft het werkveld zich ondertussen flink ontwikkeld. Webmanagers zijn SaaS oplossingen en webmasters hebben zich gespecialiseerd in content, seo en sem. Webdesigners hebben verstand van ux/ui en webdevelopers hebben zich gesplitst in back-end- en front-end developers. Wat die laatste groep betreft: er zijn er die zich meer hebben bekwaamd in het implementeren van frameworks en libraries, dan in ‘vanilla’ JavaScript. Het gerucht doet de ronde dat deze developers zich buiten de context van frameworks en libraries ook geen raad weten met JavaScript.

Ik wil graag aan de slag met Express, Angular en React. Maar ik vrees dat ik zonder gedegen kennis van vanille JavaScript eigenlijk niets anders leer dan wat ik al kon, namelijk knippen en plakken. Daarom bijt ik me al sinds het begin van de herfst vast in de beginselen van programmeren in JavaScript. Ik ben gestart met het boek JavaScript: From Novice to Ninja door Darren Jones. Dat kreeg ik gratis bij een lidmaatschap van Sitepoint. Het goede van dit boek is dat het een aantal belangrijkste thema’s goed behandelt. Een minpunt is dat de voorbeelden een beetje wereldvreemd zijn. Ik denk ook niet dat ik al een ninja ben.

Ik ben nu bezig in een boek dat vrij beschikbaar is: Learning JavaScript Design Patterns door Addy Osmani. De schrijver bespreekt in dit boek best practice oplossingen voor veel voorkomende oop vraagstukken. Misschien durf ik me na dit boek wel Ninja te noemen. Of misschien moet ik daarvoor eerst de Functional Programming design patterns in JavaScript nog leren.

“It will be pretty when we get there”

Ergens in maart of april begon ik aan een opfriscursus webdesign. Eigenlijk een cursus front-end development maar dat wist ik later pas. Bij aanvang kende ik alleen het jargon zoals dat gebruikelijk was ten tijde van de hoogtijdagen van Web 2.0. Het volgen van mijn eigen curriculum was tot nog toe een feestje, maar niet meer nu ik ben aanbeland bij functioneel en object georiënteerd programmeren in JavaScript.

De moeilijkheid van JavaScript is dat er zoveel manieren zijn om iets te laten gebeuren en dat boeken (blijkbaar) niet kunnen of willen vertellen wanneer en waarom je het beste een bepaald patroon kan volgen. ‘Speaking of patterns’: de boeken die ik tot nog toe heb geraadpleegd, zwijgen of zijn zwijgzaam over het bestaan van programmeerparadigma’s en -patronen. Bovendien zijn de voorbeelden en oefeningen te academisch, of misschien kan ik beter zeggen, te wereldvreemd.

Ik zit nu dus even in een dip met mijn zelfstudie. Ik heb vorige week zelfs even overwogen om alleen te slagen voor basis JavaScript (procedureel programmeren) en verder te gaan met lessen over wcag en aria. Maar als ik dat doe dan maak ik daarna weinig kans om iets op te steken over Express-, Angular- en React.js. Linksom of rechtsom moet ik mij dus het functioneel en object georiënteerd programmeren zien eigen te maken.

Om mijzelf te overwinnen ben ik vanochtend op zoek gegaan naar Youtube video’s die het kunnen uitleggen zodat zelfs ik het begrijp. In plaats daarvan vond ik een paar mensen die een soort van metafysisch praatje houden over webdevelopment:

Vooral de presentatie van Brenna O’Brian (The myth of the real JavaScript developer) was erg bemoedigend. Haar presentatie deed bij mij een kwartje vallen over een idee dat ik in allerlei andere contexten al vaker was tegen gekomen. Een idee wat mij aansprak zonder in staat te zijn het op mezelf toe te passen: Het is oké om niet perfect te zijn. Ze gebruikt mooie voorbeelden om dit te illustreren. Het is bijna alsof ze zegt: het is eigenlijk beter voor ons project als je het niet bent. Ze citeert in haar presentatie nog de president-directeur van Pixar, Ed Catmull, die heeft gezegd: “It will be pretty when we get there, but it won’t be pretty along the way”. Dat is een mooie en wijze les die niet alleen toepasselijk is op leren, maar op het hele leven zoals zich dit ontvouwt.

Hallo wereld

Het wilde met mijn loopbaan als functioneel beheerder niet meer zo vlotten op het laatst. Met mijzelf ook niet. Wat ik er vooral van heb geleerd is, dat je in de zoektocht naar wat echt en waar is vooral jezelf vaak tegenkomt. Misschien ga ik daar op een ander moment nog eens wat dieper op in. Verder lezen “Hallo wereld”