- 02-07 Steven
- 02-14 Justus
- 02-28 Peter Paul Koch
- 03-14 Titus Wormer
- 03-28 Jasper
- 04-14 Bram
- 04-14 Peter Peerdeman
- 04-28 Niels
- 05-16 Nick de Bruijn
- 05-23 Guido Bouman
- 05-31 Leonie Watson
- Schaalbare productieomgeving
- Coding in NodeJS
- Waaraan te denken bij een CMS?
- Accessibility
- Ethische data verzameling
Ook vertelde Jasper over een nieuwe beweging waarin je makkelijker PwA’s kan maken. Dit doordat veel native functionaliteit van mobiele devices beschikbaar wordt gemaakt in de verschillende browsers.
- Distributed data protocol
- Connection
- Managing data
- Remote Procedure Calls
- Error
- Wees uniek
- Leer van je fouten
- Doe maar een ding tegelijk
- Je moet je producten kunnen verkopen
Hoe zet je een productie omgeving op die je echt kan gebruiken om je applicatie bezoek baar te maken voor gebruikers? In dit artikel lees je over hoe je dit het beste kan opzetten. We gaan het voornamelijk hebben over NodeJS, Mysql, Nginx, security, OpenVPN, Ubuntu en Esxi.
Om te beginnen heb je een aantal ingrediënten nodig: -VPS met VPN of een hobby server -Esxi -Ubuntu -NodeJS & NPM -Mysql server -Nginx -OpenVPN op je computer
VPS & VPN (Virtual private server & virtual private network) of hobby server Dit is gewoon een computer waarop jouw applicatie en database draaien. Het is belangrijk dat dit wel echt een server is omdat de hardware is gemaakt om langdurig mee te gaan en ook kan het langer aan blijven.
Dit is het hoofdbesturing systeem wat op de server komt te draaien. Dit systeem kan andere besturingssystemen virtueel draaien. Zo kunnen we straks meerdere Linux bakken naast elkaar draaien.
Ubuntu is het besturingen systeem wat we virtueel gaan draaien in Esxi. Voor onze eerste opstelling gaan we vier virtuele containers maken met Ubuntu erin.
NodeJS is de taal en het systeem waarin de Node applicatie gaat leven. NPM is de Node Package Manager waarmee NPM packages geïnstalleerd kunnen worden.
Mysql server is de database software. Deze kan je straks bereiken met een programma zoals Mysql Workbench.
Dit is de proxy software. De proxy software praat straks met de buitenwereld en met de losse node Servers.
Hiermee kan je straks verbinden maken. Deze server verschaft jou straks toegang tot alle andere servers als je mobiel wilt werken (buiten het netwerk waarin de server staat). Laten we beginnen!
Als je een VPS hebt kan je de hosting vragen over de mogelijkheden voor Esxi. Als je een server hebt installeer Esxi met een usb stick. https://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.solutions.doc/GUID-0A264828-3933-4F4F-82D7-B5006A90CDBA.html Zodra je dit gedaan hebt is het belangrijk dat je dit IP adres static maakt. Dit doe je eerst in Esxi, daarna in je router. Op alle ubuntu servers die je nu of in de toekomst aanmaakt is het ook belangrijk dat je ze static maakt!
Maak 4 virtuele Ubuntu containers aan. Het is aan te raden om de NodeJS 2GB ram te geven. De andere drie virtuele servers kunnen 1GB. Geef de NodeJS en minimaal 10 gigabyte opslag en de Mysql minimaal 5GB. Download Ubuntu hier: http://releases.ubuntu.com/14.04/
Installeer op de volgende 4 dingen op de op de verschillende virtuele servers: MYSQL Server -> https://dev.mysql.com/downloads/
Dit is je database server. Voor je software installeert voer altijd eerst apt-update uit. Met ifconfig kan je bekijken welk ip adres deze server heeft.
NODEJS & NPM -> https://www.digitalocean.com/community/tutorials/how-to-install-node-js-on-an-ubuntu-14-04-server
Het is aan te raden om eerst NVM te installeren op de server. Dit zodat je altijd kan switchen tussen verschillende node versies. Start je Node server vanuit /var/www. Zodra je hier een test applicatie in draait kan je deze bereiken via het IP adres van de server gevold door de port die je hebt opgegeven in de app.js (bijvoorbeeld 192.168.0.4:3000). Als je verbinding wilt maken met de database server bekijk je op de MYSQL server wat het IP adres is. Vergeet niet dat daar nog een poort achter moet die staat ingesteld op je MYSQL server. Het is aan te raden om je Node applicatie levend te houden met PM2. Hiermee kan je logs terug kijken en van een afstand je server status monitoren. Ook kan je instellen dat je error logs gemaild krijgt als je server een error krijgt. PM2 houd je app aan. Als hij uitvalt start hij opnieuw op. Lees hier hoe je PM2 installeert: https://www.digitalocean.com/community/tutorials/how-to-use-pm2-to-setup-a-node-js-production-environment-on-an-ubuntu-vps
OpenVPN -> https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-14-04
Nadat je deze tutorial gevolgd hebt kan je verbinding maken met deze OpenVPN server. Vervolgens kan je vanaf buitenaf inloggen en ssh’en naar de andere virtuale servers en de Esxi zelf.
Nginx -> https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-14-04-lts
Maak in de Nginx een profiel aan voor je nieuwe NodeJS server. Doe dit met behulp van deze tutorial: http://www.nikola-breznjak.com/blog/javascript/nodejs/using-nginx-as-a-reverse-proxy-in-front-of-your-node-js-application/
In NodeJS worden een aantal termen gebruikt die belangrijk zijn om te begrijpen. Dit zijn NPM (Node package manager), NodeJS, app.js, modules, NPM scripts en package.json. Voordat je een Node project kan beginnen is het belangrijk om te begrijpen wat deze termen inhouden.
NPM is het “systeem” waarmee je losse modules kan inladen. Deze kan je zelf maken of vinden op npmjs.com. Je kan een NPM package installeren met “npm install name_of_package”. Het is belangrijk om achter het commando –save en –dev te typen. Dit doe je de package versies vast te leggen in de package.json. Zodra iemand anders het project binnen haalt kan hij met “npm install” alle juiste packages binnen halen.
Deze modules zet je vervolgens in je “package.json”. Naast de gebruikte module, zet je ook het versie nummer erbij. Al deze modules worden ingeladen in het mapje: “node modules”. Dit mapje zet je in de .gitignore zodat ze niet mee worden geüpload naar Github. Zodra jij of iemand anders het project wilt gebruiken kan je het project clonen of kopiëren (zonder de “node modules” map) en het commando “npm install” uitvoeren. Ook is het belangrijk dat je aangeeft welke NPM Modules worden gebruikt voor de applicatie, en welke voor de development omgeving. De .gitignore is de file waarin je aangeeft welke bestanden wel en niet gepushed moeten worden naar Github! Meer over .gitignore: https://git-scm.com/docs/gitignore.
Deze modules kunnen echt van alles zijn. Van hele simpele functies (voor bijvoorbeeld een tijdelijke sessie aanmaken en dan verwijderen) tot complexe tijd calculatie functies (Moment.js). Dit zijn modules die je gebruikt voor je applicatie. Er zijn ook modules die je kan gebruiken voor je development omgeving. Bijvoorbeeld Nodemon, deze module herstart je applicatie na iedere wijziging zodat je niet continu je server opnieuw hoeft op te starten. Nodemon moet je bijvoorbeeld installeren met de –dev flag.
Met NPM scripts kan je meerdere commando’s laten uitvoeren met een soort van shortcuts die je van tevoren opgeeft. De NPM script definieer je in je package.json. Je kan met bijvoorbeeld een NPM script al je SCSS en JavaScript (ES6) files laten watchen. Zodra je er eentje bewerkt en opslaat kan je ze automatisch laten compilen voor de uiteindelijke distributie.
NodeJS is de programmeertaal waarin je de applicatie maakt. Het hart van je applicatie leeft in app.js of index.js. Deze file kan je noemen zoals je hem wilt. Je moet dit alleen wel aangeven in je package.json. In deze app.js start je de applicatie, verdeel je de routes en laad je alle modules in met de require functie. In de app.js begin je met het requiren van alle modules. Vervolgens schrijf je de code waarmee je een url request afvangt. Vervolgens start je de applicatie met "nodemon app.js" (dit was een dev-dependencie). Meestal starten mensen dit op poort 3000. Dit kan je veranderen naar alle anderen poorten die je wilt (zolang ze beschikbaar en vrij zijn). Wat een fijne combinatie is in Node is Express met Ejs (embedded javascript). Hiermee kan je twee belangrijke dingen doen. Je html pagina’s serveren aan de client, middleware toevoegen en makkelijk routes maken voor de url structuur van je applicatie. Een simpel voorbeeld vind je hier: https://expressjs.com/en/starter/hello-world.html
Wat is middleware eigenlijk? Met middleware krijg je toegang tot de request en response objecten. expressjs.com beschrijft het op de volgende manier, "Express is a routing and middleware web framework that has minimal functionality of its own: An Express application is essentially a series of middleware function calls.Middleware functions are functions that have access to the request object (req), the response object (res), and the next middleware function in the application’s request-response cycle. The next middleware function is commonly denoted by a variable named next." Hiermee kan je voordat een functie die een url opvangt andere functies laten uitvoeren. Stel dat je een middleware functie schrijft die bekijkt of een gebruiker is ingelogd, als de gebruiker is ingelogd mag de gebruiker verder gaan. Als de gebruiker niet is ingelogd verwijs je de gebruiker door naar een login pagina met de melding dat je ingelogd moet zijn om de pagina te bekijken. Als je deze middleware functie voor iedere pagina zet waar je voor ingelogd moet zijn scheelt je dat een hoop onderhoud en het is ook DRY (don’t repeat yourself).
Embedded javascript is een view engine waarin je de HTML structuur maakt die naar de eindgebruiker gaat. Een alternatief hiervoor is bijvoorbeeld JADE of Handlebars. In de EJS files kan je HTML5, JavaScript, CSS en EJS typen. De EJS view engine maakt hier uiteindelijk html van en geeft dat door aan de client die de pagina opvraagt.
Een CMS. Iedereen heeft het erover. Maar wat is het eigenlijk? Een CMS is niet een soort magische oplossing om content te presenteren aan de gebruiker. Er zijn veel standaard content managementsystemen, maar eigenlijk is een CMS geen standaardoplossing omdat ieder bedrijf andere KPI’s en content heeft.
Een CMS werkt pas echt efficiënt als het op maat is gemaakt of zodanig is aangepast dat het maatwerk is. Dit is vaak te doen met plugins (denk aan alle talloze Wordpress plugins) of door een programmeur in te huren. Optie 1 is het snelst maar zeker niet het best. In de oplossingen, opensource of niet, komen altijd talloze extra functionaliteiten die niet gebruikt worden, dingen moeilijker en slomer maken en niet veilig zijn. Als je een CMS schrijft is het belangrijk om stil te staan bij de basis van het gebruik. Als je voor de plugins kiest is het belangrijk om er niet teveel te gebruiken. Zo meldt https://premium.wpmudev.org/blog/too-many-plugins dat plugins vaak ook de nodige problemen met zich mee brengen!
Voordat je aan een CMS begint is het altijd belangrijk om na te denken over de schillende doelen die de gebruikers hebben. Zo heb je minimaal admins, ingelogde gebruikers en gasten. Al deze gebruikers moeten andere functionaliteiten krijgen. Ook is het belangrijk om uit te schrijven wat voor data je nodig hebt. Dan praat ik niet over wat objecten maar over het ERD-schema. Het ERD schema is de blauwdruk van je database. Margaret Rouse beschrijft een ERD op de volgende manier: “An ERD is a data modeling technique that can help define business processes and can be used as the foundation for a relational database”. Hoe beter dit in elkaar steekt, hoe meer profijt je er later van hebt. Denk aan hoe makkelijk het is om later dingen toe te voegen en de relaties. Het is later vaak bijna onmogelijk om benamingen te veranderen of te verwijderen.
Wat ook vaak vergeten wordt is het feit dat niet alle user alle functionaliteiten mogen gebruiken. Als een gebruiker geen formulier heeft om een pagina aan te maken, betekend dit niet dat hij geen post request kan nabootsen waarmee hij een pagina aanmaakt. Het is niet alleen belangrijk dat permissies worden gecheckt aan de render kant, maar nog veel belangrijk aan de kant waar de functionaliteit wordt uitgevoerd. Er bestaan tools waarmee alle responses van een website mee uitgelezen kunnen worden. Als een kwaadwillige dit bemachtigt kan hij door url’s browsen en veel schade aanrichten. Zed Attack Proxy is bijvoorbeeld een opensource oplossing die meerdere vulnerabilities opspoort (http://www.zaproxy.org/).
Als je een CMS maakt is het handig om te beginnen met de CMS kant. Op basis van de content die erin wordt gestopt kan je nadenken over hoe de front-view opgebouwd moet worden. In de CMS kan je ook beter gelijk rekening houden met de permissies (wie mag wat zien, bewerken, aanmaken, editen), loginsysteem en het user management. In de praktijk blijkt vaak dat het moeilijk is om dit later in te bouwen. Daarnaast is de kans op fouten groter als dit er later omheen gebouwd wordt. Security first! Ook is het belangrijk om altijd goed te debuggen. Volgens PRQA komen de meeste vulnerabilities voort uit code fouten (http://www.programmingresearch.com/coding-standards/application-security-software-secure/).
Blijf consistent en houd een documentatie zodat andere mensen het ook kunnen onderhouden. Kijk ook naar andere CMS structuren. Hierdoor wordt het makkelijker om te begrijpen wat je hebt gemaakt voor anderen. “Don't pave the cowpath”.
Als laatste is het goed om je volledig op de gebruiker van het CMS te richten. Bekijk of je zoveel mogelijk wizards kan opdelen in kleine stukken of kan afvangen met logische flows. Houd de terminologie ook simpel en consistent. Let ook op de toegankelijkheid van het CMS. Is het toegankelijk voor slechtziende of bijvoorbeeld via mobiel?
Hoe maak je iets toegankelijk voor het web? Er zijn talloze voorbeelden van hoe het niet moet. Het is in ieder geval belangrijk om een goede html structuur te hebben. Zorg dat je valide html schrijft en gebruik maakt van de juiste html elementen. Voor toegankelijkheid het vooral belangrijk dat je html semantisch goed is opgebouwd. Het is dan ook handig om je html altijd even door een html validatie systeem heen te halen. Maar waarom zou je de html valideren? Volgens https://validator.w3.org/docs/why.html straat het professionaliteit uit, debug je de code, wordt het makkelijker te onderhouden.
Internet moet voor iedereen toegankelijk zijn. Er zijn talloze online tutorials en studies over hoe je het web toegankelijker kan maken. Het is zelfs goed te doen voor mensen die alleen een cms beheren. Volgens Claire is er een hoop te doen. Zij schreef een tutorial voor Wordpress beheerders: https://premium.wpmudev.org/blog/making-wordpress-accessible.
Geef duidelijke benamingen aan de attributen afbeeldingen en links. Blinden kunnen niet zien wat een afbeelding is of in wat voor context een link is geplaatst. Daarom is het belangrijk dat deze elementen goede beschrijvingen hebben. En bij een link waar ze heen verwijzen. Dit doe je met de “alt” tag. Mocht je een cms gebruiken waar je niet alles in vult, is het nog belangrijker om hier rekening mee te houden. Zo zou een alt tag bij een image verplicht moeten zijn zodat de content creators hier geen fouten in kunnen maken. Dan dwingt het systeem af dat de uiteindelijke front-view de juiste informatie voor screenreaders bevat.
Zorg voor slechtziende dat het contrast goed is. Dit is niet alleen voor slechtziende, wat als iemand bijvoorbeeld op een telefoon kijkt in de zon? Dan is het belangrijk dat het contrast goed is. Er zijn programma’s waarmee je kan uittesten of het contrast ook echt daadwerkelijk goed is. Toch kunnen deze het ook mis hebben! Test het altijd zelf even door met je telefoon of laptop in de zon te gaan staan, of knijp je ogen dicht en kijk of je contrast ziet.
Zorg dat knoppen goed groot zijn en goede states hebben. Vooral op mobiel is dit erg belangrijk. Ook is het goed om na te denken over waar knoppen komen op wat voor device. Als je bijvoorbeeld een touch table hebt waarbij de gebruiker aan de onderkant van het scherm staat, zou het vervelend zijn als de navigatieknoppen helemaal bovenaan de pagina staan. De states van de knoppen zijn ook erg belangrijk. Dit in combinatie met de affordance uiteraard. Is het klikbaar? Wat gaat er gebeuren als ik erop klik? Of geeft het systeem of website al een feedback over welke kant de pagina op gaat bewegen? Wat nog belangrijker is, is de focus state. Mensen die alleen met het toetenbord navigeren kunnen welke knop ze gaan gebruiken.
Zorg voor progressive enhancement. Javascript is erg krachtig, maar dat brengt ook zijn valkuilen mee. Als de verbinding slecht is, het device verouderd is, het device geen javascript kan uitvoeren of als javascript uit staat kan het zijn dat javascript niet goed functioneert. In dit geval is het belangrijk dat de fallbacks goed zijn. Als je met javascript een div klik baar maakt kan de gebruiker niks op het moment dat javascript niet goed werkt!
Zorg dat je webpagina’s en ontwerpen toegankelijker worden voor het hele web door de hierboven genoemde onderdelen minimaal toe te passen in al je websites en apps!
Big data. Wat is dat? Kunnen we het meten? Hoeveel is het en hoeveel hebben we? Misschien een belangrijkere vraag, wie beheert het en wat kan hij ermee?
De belastingdienst hield rond in 2013 een vrouw aan op verdenking van belastingfraude, zei kreeg een uitkering maar kocht te veel excellent biefstuk met haar Albert Heijn bonus pas. Haar uitkering is uiteindelijk stop gezet. (Panopticon privacy - Peter Vlemmix 29:05)
Het is rechtvaardig dat de uitkering van deze vrouw is stopgezet. Maar was het niveau waarop deze vrouw onderzocht is de moeite waard? De oneindige datastroom die wij creëren door te leven wordt opgeslagen en kan op ieder gewenst moment worden gebruikt voor alle denkbare scenario’s.
Het klinkt alsof dit onderwerp ver verwijderd ligt van het onderwerp websites. Toch ligt het dichterbij dan je denkt. Websites zijn zoveel meer dan alleen een informatiebron. Met de talloze inlogsystemen, profielen, reclames, javascripts en databases wordt de mensheid gemonitord! Maar wat is ethisch om op te slaan of om verbanden mee te trekken? Door het gebruik van persuasive design zijn wij in staat gebruikers opdrachten te laten uitvoeren en te sturen in gedrag. Daarmee komt ook een grote verantwoordelijkheid. Designers en programmeurs zouden zo moeten programmeren en designen dat de veiligheid en privacy van de eindgebruikers gewaarborgd ligt.
Als je het hebt over performance, progressive enhancement, toegankelijkheid, tooling, etc. dan heb je het over websites en web apps. Maar waarom vergeten wij privacy altijd? Privacy en etnisch design zou op plek een moeten staan in deze lijst.
Met de komst van IoT wordt dit straks complexer. Onlinedata leeft straks niet alleen maar in onze computers, telefoons en smartwatches... Onlinedata leeft straks in onze koelkast, onze wekker, onze stofzuiger, onze auto en noem het maar op! Tegengaan kunnen we niet, en we moeten het ook zeker niet tegenhouden. Het is belangrijk dat wij ons er bewust van worden en veiligheden in bouwen om integriteit te waarborgen.
