Craft Conference in Boedapest

Remco Aalbregt

  • 28/05/2018
  • 11 minuten leestijd
Remco Aalbregt

Craft Conference in Boedapest

Ons Frontend team is op 8 mei vertrokken naar Boedapest om daar de Craft Conference 2018 bij te wonen. Zij schreven hier samen een leuke blog over.

Woensdag

Woensdagmiddag zijn we met het Frontend team gearriveerd in Boedapest. Na het inchecken in het hotel zijn we met het hele team een hapje gaan eten in de plaatselijke foodhal. Vervolgens zijn we heerlijk gaan relaxen in een van de vele badhuizen die Boedapest te bieden heeft. Geheel ontspannen hebben we ‘s avonds een hapje gegeten met het hele team.

Na het uitwisselen van de nodige verhalen was het weer de hoogste tijd om terug te keren naar het hotel, vol verwachting met hetgeen de volgende dag zou brengen.

Donderdag

De vroege vogels van het Frontend team zijn direct na het ontbijt vertrokken om op zoek te gaan naar de lekkerste koffie in Boedapest.

Na het drinken van twee espresso’s bij twee verschillende tentjes, hebben zij zich bij de rest van het team gevoegd. Met z’n allen zijn we vervolgens met de metro en tram afgereisd naar de locatie van de conferentie.

Craft Conference werd net als vorig jaar georganiseerd in het treinmuseum Magyar Vasúttörténeti Park in Boedapest. Op de locatie waren er naast de vaste gebouwen meerdere tenten geplaatst waarin de presentaties werden gegeven. Tussen de presentaties door was er tijd voor ontspanning. Een ritje op een - niet zo’n grote - trein kon natuurlijk niet ontbreken. We merkten al wel snel het nadeel van de combinatie van mooi weer en presentaties in tenten. De temperatuur in de tenten liep namelijk al snel op. Gelukkig nam de bewolking na de lunch toe waardoor het klimaat in de tenten een stuk behaaglijker werd.

Na de eerste dag van de conferentie zijn wij teruggekeerd naar het hotel. In de avond hebben we ons bij fieldmanager Andy gevoegd die in de middag was gearriveerd in Boedapest. Eerst was het tijd om even bij te praten op een terrasje nabij het hotel. Na een hapje en een drankje zijn we vervolgens met de metro in de richting van het parlementsgebouw vertrokken om daar in de buurt heerlijk te eten. Na een gezellige avond met veel gelach zijn we met een voldaan gevoel teruggekeerd naar het hotel.

Vrijdag

Wederom vonden de vroege vogels de koffie in het hotel niet voldoen en zijn weer vertrokken naar het koffietentje van gisteren voor de o-zo-lekkere fix espresso. Toen de rest van het team ook gereed was, zijn we vertrokken naar de conferentielocatie.

Het weer was net als de dag ervoor zonnig. Gelukkig waren de zijkanten van de tenten al deels opengezet waardoor het wat aangenamer was tijdens de presentaties. De enige talk waar het hele team samen heen geweest is, is CSS Grid: Get ready to fall in love door Bill Odom. Deze is later in deze post beschreven door Danh. Na de talk is het team opgesplitst en hebben we samen gedurende de dag een verscheidenheid aan presentaties bijgewoond. Aan het einde van de middag zijn we weer teruggekeerd naar het hotel. Net als de voorgaande dagen hebben we samen gegeten. Ditmaal in een van de vele pizzeria’s die Boedapest rijk is.

De volgende dag was het alweer tijd om Boedapest te verlaten en huiswaarts te keren. Op het vliegveld keken we nog even terug op een bevlogen paar dagen en wordt er zelfs al weer gespeculeerd over de volgende conferentie.  

Favoriete presentaties

Gecombineerd hebben we deze twee dagen een grote verscheidenheid aan talks mogen bijwonen. Onze favorieten hebben we hieronder verder beschreven.

The well rounded architect - Patrick Kua

In deze talk door Patrick Kua leerden we wat een goede architect maakt. In de talk behandelde Kua de volgende onderwerpen: - Wat is een architect? - Wat is architectuur? - De elementen van een well rounded architect. - Wat zijn valkuilen voor een architect?

Wat is een architect? Kua geeft aan dat een architect, naast alle overlap met andere functies en taken, voornamelijk een rol is. Een rol waarin gestuurd kan worden op architectuur, keuzes gemaakt worden en advies wordt uitgebracht.

Wat is architectuur? Ook hier vertelt Kua dat architectuur niet iets heel concreets is. Hij beschrijft het als "significant design choices that impact cost/profit". Een architect is verantwoordelijk voor de architectuur, voedt en onderhoudt deze. Een architect begeleidt architectuur veranderingen en zorgt dat het systeem groeit.

De elementen van een well rounded architect: Volgens Kua zijn er 6 skillsets die indien beheerst kunnen zorgen voor een well rounded architect. Deze benoemt hij als volgt: Leiderschap Goede developer Systeem focussed Ondernemerschap Strategisch technologist Communicator

Leiderschap Zonder leiderschap kan er een wirwar aan implementaties, codebases, frameworks, tools en processen ontstaan. Een leider zorgt voor een gezamenlijke visie en doel. Daarnaast adviseert Kua om verschillende stijlen van leiderschap onder de knie te krijgen. Zo kan per situatie en behoefte een andere stijl gehanteerd worden

Goede developer Als architect is het belangrijk om de inhoudelijke uitdagingen die het team meemaakt te begrijpen en hier rekening mee te houden. Ook belangrijk is het inregelen van een goede decision feedback loop. Zo blijft de kloof tussen het team en beslissingen zo klein mogelijk.

Systeem focussed Een architect bouwt systemen, niet software. Daarbij houdt een architect rekening met environment en infrastructuur. Hij/zij richt een systeem zo in dat goede monitoring mogelijk is op de gehele keten. Systemen moeten mee kunnen groeien, veranderen en schalen. In architectuur keuzes moeten hier rekening mee gehouden worden.

Ondernemerschap Belangrijk is volgens Kua dat een architect echte problemen oplost; problemen die de business ervaart. Daarbij maakt hij/zij altijd een kosten baten afweging. Een goede architect weet ook te experimenteren. Valideert ideeën vóór deze geïmplementeerd worden en zorgt zo ook voor innovatie en business groei.

Strategisch technologist Een goede architect is ook op de hoogte van de laatste en industrie standaard talen, tools, technieken en frameworks. Daarnaast is hij/zij niet blind voor trends en innovatie. Bestaande tools worden pas vervangen als er een bewezen en productierijp alternatief is. Nieuwe technieken worden getimeboxed getest, geëvalueerd en middels trajecten geadopteerd.

Communicator En dan is er een van de belangrijkste aspecten die een architect moet beheersen. Hij/zij moet met mensen buiten de technische omgeving kunnen praten. Een focus hierbij is het kunnen verkopen en presenteren aan verschillende soorten mensen binnen de organisatie. Een architect moet visie kunnen overbrengen en alignment met de business kunnen bereiken.

Wat zijn valkuilen voor architecten? De valkuil waar de meeste teams mee te maken hebben, is die van de ongebalanceerde architect. Dit ontstaat wanneer een architect goed is in een van bovengenoemde categorieën, maar zwak is in andere. Dit kan bijvoorbeeld leiden tot een goede verkoper en leider, maar onuitvoerbare techniek. Of een prachtig technische oplossing, maar weinig of geen toegevoegde waarde voor de business. Ook ontstaat de kans dat de architect zelf mee programmeert en zo zijn team overvalt met code bombs. Met weinig respect binnen het team tot gevolg.

Het allerbelangrijkste vindt Kua dat je tenminste gemiddeld in elke categorie bent om het scala aan taken en verantwoordelijkheden te kunnen vervullen. Goed zijn in specifieke categorieën is goed, mits er geen zwakke categorieën zijn.

Voor beginnende architecten of developers die ambiëren architect te worden, adviseert Kua om voor de komende 6 maanden 2 of 3 categorieën te kiezen die nog niet genoeg ontwikkeld zijn en daar kleine stappen per keer in te nemen. Pas wanneer alle categorieën gemiddeld of goed vervuld kunnen worden, is het verstandig om als architect aan de slag te gaan.

Tot slot Voor developers die ambiëren architect te worden of voor architecten die willen valideren of hun skillset voldoende ontwikkeld is, geeft Kua ons een mooi overzicht.

Dit overzicht geeft voldoende houvast om concrete stappen te kunnen nemen om jezelf verder te ontwikkelen binnen het vakgebied.

Raoul Wittenberns

Perceived performance, the only kind that really matters

Eli Fitch, frontend developer bij het bedrijf MapBox in Washington DC met een passie voor web performance, animaties en 3d. Hij gaf een presentatie over hoe snel een website aanvoelt voor een gebruiker. Hij begon de presentatie met de uitleg waarom je je zou moeten richten op subjectieve snelheidsverbetering bij het optimalisatie van een website. De laatste paar jaar zijn we goed bezig met het verbeteren van de objectieve waarneming van snelheid. Door snellere internetverbindingen en technieken als lazy load te benutten, kan de wachttijd van acties binnen een webapplicatie beperkt worden. Echter worden objectieve snelheidswinsten van 20% of minder niet als zodanig geëvenaard. Om de snelheid van een webapplicatie op een objectieve wijze te optimaliseren, zou je een verbetering van minimaal 30% moeten halen om überhaupt een merkbaar verschil te verkrijgen. Vaak hebben deze verbeteringen dusdanig veel effort van meerdere teams nodig dat dit niet altijd haalbaar is. Focus daarom liever op een subjectieve snelheidsverbetering waarin gebruikers het gevoel hebben dat de webapplicatie al sneller is.

Hij volgde met een uitleg over hoe gebruikers tijd waarnemen. Hij maakte hierbij het onderscheid tussen een actieve en passieve staat. Tijdens de actieve staat is de gebruiker daadwerkelijk handelingen aan het verrichten. In de passieve staat moet de gebruiker wachten tot hij een nieuwe actie kan uitvoeren. Bij de uitleg over de passieve staat gebruikte hij het Engelse gezegde “A watched pot never boils” als voorbeeld. Hij vertelde hierbij dat gebruikers een passieve wachttijd 36% langer schatten dan hij daadwerkelijk is.

Eli toonde vervolgens een aantal trucs waarmee je de laadtijd sneller kunt laten voelen voor de gebruiker. Hierbij is het belangrijk dat gebruikers in de actieve staat blijven en ze niet in een passieve staat komen. Hij gaf hiervoor een aantal voorbeelden:

Vertel gebruikers niet dat ze aan het wachten zijn Wanneer je een gebruiker vertelt dat ze ergens op moeten wachten, met bijvoorbeeld een laadindicator, zullen ze direct in de passieve staat gezet worden. Een oplossing hiervoor is om pas een laadindicator toe te voegen wanneer gebruikers langer dan een seconde moeten wachten. Door gebruik te maken van animaties in een link- of button-element op :active van zo’n 200ms verkort je de passieve wachttijd.

Reageer direct op acties van gebruikers Door gebruik te maken van een optimistische UI zorg je ervoor dat gebruikers niet in een passieve staat komen. Zo kun je bijvoorbeeld direct de UI updaten terwijl je hierna pas de API-call naar de backend maakt. Denk bijvoorbeeld aan het geven van een waardering bij een product. De gebruiker ziet na het klikken op het gewenste aantal sterren direct de waarde staan, terwijl de call nog gemaakt moet worden. In het grootste deel van de gevallen zullen de API-calls toch wel goed gaan. In het geval dat het onverhoopt toch verkeerd gaat, kun je alsnog een melding tonen.

Kies een specifieke laadanimatie Eli vertelde dat het belangrijk is een juiste laadindicatie te tonen. Zoals eerder gezegd zou je voor laadtijden van minder dan een seconde geen indicatie moeten tonen. Hierna kun je een spinner tonen, maar doe dit niet bij wachttijden van meer dan 2 seconden. Eli quote hierbij David Maiser “Uncertain waits feel longer”. Gebruik in dit scenario liever een laadbalk omdat deze zekerheid geven.

Het is belangrijk de animatie van de laadbalk overeen te laten komen met de verwachte wachttijd zo zegt Eli. Wanneer de animatie langer duurt dan de werkelijke wachttijd kunnen gebruikers het gevoel krijgen dat ze te lang moeten wachten. Terwijl een te korte animatie zorgt voor onzekerheid over de laadtijd, iets dat juist voorkomen moest worden door de laadbalk te gebruiken. Een oplossing welke Eli aandraagt is om gebruik te maken van adaptive loading. Door voortdurend te meten hoe lang requests duren voor de specifieke gebruikerkan de animatie van de laadbalk worden afgestemd op de verwachte laadtijd. Eli meet hiervoor het verschil in tijd tussen twee performance.now() metingen. Deze deelt hij vervolgens met de verwachte laadtijd om zo een performanceScalar te berekenen.

Houd de gebruiker afgeleid bij het wachten Hierbij gebruikt Eli de laadsequentie van Slack als voorbeeld. Wanneer je lid bent van veel workspaces, neemt de laadtijd van Slack vrij veel toe. Dit hebben ze opgelost door sequentieel meerdere soorten animaties te tonen, waarbij steeds meer onderdelen van de UI worden ingeladen.

Ook zegt Eli dat we kunnen leren van game-developers. Zo noemt hij FIFA als voorbeeld waarbij een mini-game kan worden gespeeld in het laadscherm. Op deze manier blijven gebruikers in de actieve fase.

Predictive preloading Door direct te reageren wanneer een gebruiker de intentie toont voor een bepaalde actie, kunnen wachttijden eveneens worden verkort. Eli noemt hierbij als voorbeeld een webapplicatie met een login-formulier. Op het moment dat een gebruiker begint met het invullen van het formulier, is het duidelijk dat de gebruiker binnen niet al te lange tijd toegang wil tot de applicatie. Op dat moment kun je alvast beginnen met het inladen van de app bundle. Dit kan al een voorsprong geven van 4 seconden.

Ander gedrag dat gebruikers vertonen is het decelereren van de muis voordat ze op een link drukken. Door de deceleratie van de muis in de gaten te houden, kun je een voorspelling maken op welke knop een gebruiker zal gaan drukken. Hierna kun je alvast beginnen met het inladen van de content van de pagina in kwestie.

Slot Eli eindigde de presentatie met een tl;dr; waarbij het de belangrijkste punten nog even opsomde. Hij benadrukte hier dat het gevoel van de performance van een website het belangrijkste is en om te focussen op de gebruiker.

Al met al een boeiende presentatie welke ons weer inspiratie en handvatten geeft in de dagelijkse werkzaamheden.

Remco Aalbregt

CSS Grid - Bill Odom

Bill Odom is een zelfstandige Software Developer die werkt aan Angular Boot Camp. De talk gaat over CSS Grid. Dit is een CSS methode om een layout op een pagina te ontwerpen. Bill geeft veel voorbeelden hoe CSS Grid toe te passen is.

Om CSS Grid te kunnen gebruiken, plaats je display: grid; binnen een wrapper of container class. Dit zorgt ervoor dat alles binnen deze container in een grid te definiëren is. De volgende stap is het instellen van kolommen. Met grid-template-columns stel je het aantal verticale kolommen in. Om ruimte tussen de kolommen te krijgen, maak je gebruik van het grid-gap property. Naast de breedte van de kolommen kan je ook de hoogte van kolommen met de grid-template-rows property aanpassen.

Met grid-template-columns property heb je de mogelijkheid om de breedte van de kolommen te bepalen. Je kan hierbij kiezen voor een vaste breedte of dat de rest automatisch gevuld wordt door middel van het auto waarde. Dit geldt ook voor grid-template-rows property.

Maar wat nou als je een element over de hele breedte van de pagina wilt hebben. Dat kan je rekken door middel van de grid-columnproperty. De waarde is afhankelijk van het aantal kolommen dat je hebt op de pagina. Als je twee kolommen hebt en je wilt de header rekken over de hele breedte, wordt de property als volgt: grid-column: 1 / -1;.

Je hebt ook de mogelijkheid om elementen te verplaatsen in een grid. Dit wordt gedaan middels de grid-row property. Ook dit is afhankelijk van de aantal rijen die er op de pagina staan.

Bill Odom geeft aan dat het vervelend is met de waardes zoals -2 / 1 waardes te werken. CSS Grid geeft dan ook de mogelijkheid om de layout van de pagina in CSS anders te definiëren. Dit kan door middel van de grid-template property. De waarde hiervan bestaat uit kolommen en rijen. Hieronder een simpel voorbeeld:

grid-template: " header header " auto " nav main " 1fr " footer footer " auto / 250px minmax(500px, 1fr)

De header, nav, main en footer zijn regio's. Rechts daarvan bepaal je de ruimte hoeveel een regio moet innemen. De 1fr waarde is nieuw, fr staat voor fractie. Wat dit zegt is dat het de resterende ruimte inneemt.

In de rest van de talk neemt Bill ons mee door verschillende voorbeelden van CSS Grid. Support van CSS Grid wordt steeds beter, maar is nog niet klaar voor de markt.

Danh Nguyen

Building with Blockchain - John Feminella (Pivotal)

Iedereen heeft het over blockchain en jij zit er aan te denken om het ook gaan gebruiken. Maar moet je dat wel doen? John heeft hier het antwoord op en waarschijnlijk is het “Nee”. Of beter gezegd nog niet.

De huidige blockchains zijn namelijk ongelofelijk inefficient. Neem de Bitcoin als voorbeeld. Daar kost het berekenen van een block meer dan tien minuten. Iedereen op de wereld kan dus maar een keer per 10+ minuten een transactie uitvoeren.

Totdat dit probleem opgelost wordt, moet je de afweging maken of het veilig opslaan van je data zo belangrijk is dat je de inefficiëntie van een blockchain het waard vindt. Als het niet zo belangrijk is, kan je er beter voor kiezen om een van de vele “conventionele” databases te gebruiken.

Dat gezegd, het internet lijkt ook niet meer op het arpanet waar het in de jaren tachtig mee is begonnen en kijk hoe groot dat is geworden. Het is dus goed mogelijk dat met wat extra tijd en moeite de blockchain de wereld waarin we leven kan veranderen.

Tijmen van den Bos

Onze collega Samantha heeft nog een leuke vlog gemaakt over hun bezoek aan de conferentie. Bekijk deze hier: Vlog Craft Conference 2018