This is a valid Atom 1.0 feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<subtitle></subtitle>
^
<link href="https://www.fronteers.nl/"/>
^
line 29, column 33: (27 occurrences) [help]
<updated>2024-11-18T00:00:00Z</updated>
^
line 389, column 0: (18 occurrences) [help]
<div class="simple-quote_decorative-start" aria-hidden=&quo ...
line 2039, column 0: (3 occurrences) [help]
<iframe src="https://player.vimeo.com/video/?texttrack=en" widt ...
line 2458, column 0: (18 occurrences) [help]
<div class="note"> Als je Remix al kent, zie je dat ik `useA ...
line 3083, column 62: (25 occurrences) [help]
<title>Zure developers &amp; uitnodigende communicatie</title>
^
<a class="curly-braces-bg banner_component" style="backgro ...
<style>
line 7018, column 0: (2 occurrences) [help]
<video controls="" width="480" height="270">
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:base="https://www.fronteers.nl/">
<title>Fronteers blog</title>
<subtitle></subtitle>
<link href="https://www.fronteers.nl/feeds/blog.xml" rel="self"/>
<link href="https://www.fronteers.nl/"/>
<updated>2024-11-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/</id>
<author>
<name>Fronteers</name>
<email>bestuur@fronteers.nl</email>
</author>
<entry>
<title>Oproep kandidaten voor algemeen bestuur</title>
<link href="https://www.fronteers.nl/nl/blog/2024/11/oproep-kandidaatstelling-bestuur"/>
<updated>2024-11-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2024/11/oproep-kandidaatstelling-bestuur</id>
<content xml:lang="nl" type="html"><p>Omdat de Algemene Ledenvergadering alweer in zicht is willen we met het huidige bestuur een oproep doen zodat Fronteers leden die zich graag kandidaat stellen voor een algemene bestuurspositie binnen Fronteers dit tijdig kunnen doen.</p>
<p>Als algemeen bestuurslid help je mee te beslissen over de toekomst van de vereniging, maar onze bestuursleden nemen ook een hands-on houding aan wanneer het komt op vlak van ideeën te verwezenlijken.</p>
<p>Qua tijdsbesteding varieert dat sterk per bestuurslid. Je hebt natuurlijk zelf in de hand of je wat meer tijd wil besteden. Maar er zijn wel maandelijkse bestuursvergaderingen waar je verwacht wordt aan deel te nemen.</p>
<p>Je kan je kandidaat stellen tot en met de dag van de ALV. Tijdens de ALV, zal het huidige bestuur nog een laatste oproep doen voor mensen die zich wensen kandidaat te stellen.
Mensen die nadien een kandidaatstellingen insturen zullen moeten wachten tot de volgende ALV die in normale omstandigheden pas over een jaar zal doorgaan.</p>
<p>Indien je meer informatie wil over de ALV of het bestuur staan Claudia, Wim, Schepp en Jewwy je graag te woord via Slack of via <a href="mailto:bestuur@fronteers.nl">bestuur@fronteers.nl</a>!</p>
</content>
</entry>
<entry>
<title>Meld je aan voor de ALV 2024</title>
<link href="https://www.fronteers.nl/nl/blog/2024/11/meld-je-aan-voor-de-alv-2024"/>
<updated>2024-11-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2024/11/meld-je-aan-voor-de-alv-2024</id>
<content xml:lang="nl" type="html"><p>Op <strong>vrijdagavond 29 november</strong> organiseren we de jaarlijkse algemene ledenvergadering (ALV)! Deze zal online doorgaan en start vanaf 19u30 en je moet je vooraf registreren om deel te kunnen nemen.</p>
<p>Tijdens de ALV nemen we als bestuur, vrijwilligers en leden samen de (financiële) staat van Fronteers door, en evalueren we hoe het gaat met de vereniging. Tot het begin van de vergadering kan elk lid een voorstel doen voor een agendapunt of een ter stemming te brengen onderwerp. De voorlopige agenda staat hieronder.</p>
<p>Op de planning staat al reeds het overlopen van de jaarstukken van de vereniging over 2023, de financiën over 2024 en de nieuwe begroting voor 2025. Deze stukken zullen enkele dagen voor de ALV naar alle aangemelde aanwezigen worden opgestuurd. Mocht je niet aanwezig kunnen zijn, maar deze informatie wel willen inzien: laat het ons weten! Notulen van de avond worden altijd zo snel mogelijk na de vergadering online gedeeld.</p>
<p>De planning:</p>
<ul>
<li>Opening</li>
<li>Vaststelling agenda</li>
<li>Toelichting Congres commissie</li>
<li>Toelichting overige commissies</li>
<li>Jaarrekening 2023
<ul>
<li>Bevindingen kascommissie</li>
<li>Vaststellen jaarrekening</li>
</ul>
</li>
<li>Benoeming nieuwe kascommissie</li>
<li>Financiën 2024 (voorlopig)</li>
<li>Begroting 2025</li>
<li>Invulling bestuur</li>
<li>Rondvraag</li>
</ul>
<p><a href="https://tally.so/r/mKPlpz"></a>.</p>
<div class="accent-block">
<a href="https://tally.so/r/mKPlpz" target="_blank" rel="nofollower noreferrer">Gelieve je aan te melden via dit formulier</a> (Enkel voor leden).
Indien dat niet wil werken kan je ook een mailtje sturen naar <a href="mailto:secretaris@fronteers.nl">secretaris@fronteers.nl</a>
</div>
</content>
</entry>
<entry>
<title>We hebben een nieuwe website!</title>
<link href="https://www.fronteers.nl/nl/blog/2024/10/nieuwe-website"/>
<updated>2024-10-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2024/10/nieuwe-website</id>
<content xml:lang="nl" type="html"><p>De website is gemaakt door een <a href="https://www.fronteers.nl/nl/informatie/colofon">grote groep vrijwilligers</a> die gedurende de covid-19 pandemie online, en daarna in Utrecht, meerdere sessies bij elkaar zijn gekomen om aan de site te werken. De insteek was om het <em>samen</em> te doen: een project te maken waarbij niet alleen het eindresultaat belangrijk was, maar het proces ernaartoe evengoed. Een manier om een keer met die ene collega die je via Fronteers kent samen te werken, ook als je daar normaal de kans niet snel toe hebt. En om van elkaar te leren, want we vinden kennisdeling heel belangrijk als vereniging.</p>
<p>Dit was ook de reden dat het wat langer heeft geduurd. Zo'n sociaal project had natuurlijk te lijden onder de wereldwijde coronapandemie. Maar, wij van Fronteers geven het niet zo snel op, en het eindresultaat spreekt voor zich!</p>
<p>De nieuwe website is gebouwd met <a href="https://www.11ty.dev/">Eleventy</a>, een static site generator ontwikkeld door Zach Leatherman. We hopen met de keuze voor Eleventy een systeem te hebben waar elke collega developer betrekkelijk eenvoudig zich in kan redden. Is het perfect? Nee. Is het foutloos? Verre van. Maar dat heeft ook een bepaalde charme. Als je iets ziet, kun je een <a href="https://github.com/fronteers/website/issues/new/choose">issue maken</a> of een <a href="https://github.com/fronteers/website/fork">fork maken</a> en zelf een wijziging voorstellen. En is dit nog nieuw voor je, dan is er vast wel een vrijwilliger die je eens wil helpen met hoe Git werkt, want dit is een mooie plek om het te oefenen.</p>
<h2>Maar wat kun je allemaal op deze nieuwe site?</h2>
<ul>
<li>Je mag - mits je lid bent van de vereniging - zelf <a href="https://github.com/fronteers/website/blob/main/docs/represent.md">een profiel aanmaken</a> waarop je jezelf laat zien. Er wordt dan naar gelinkt vanuit ons ledenoverzicht. Als we een aantal profielen hebben, kunnen we ook pagina's live zetten waarop je gevonden kan worden als werkzoekende, freelancer of als iemand die wel eens junioren wil mentoren.</li>
<li>Je kunt ook een blog schrijven en insturen. Schrijf je blog in Markdown (je kunt hiervoor <a href="https://github.com/fronteers/website/blob/main/templates/blog-nl.md">een sjabloon</a> vinden op Github) en plaats het in de juiste map. Maak een pull-request en iemand van onze marketingcommissie kijkt je inzending na. Wordt je PR gemerged, dan sta je op de site! 👏</li>
<li>Heeft je bedrijf een vacature, dan kunnen je ontwikkelaars tot de vacature verloopt nog correcties doen in een proces dat minder afhankelijk is van 1 vrijwilliger. Shout out naar Bernard die <em>jarenlang</em> voor ons de vacaturebank heeft gedaan! 🙏</li>
<li>De site is nu ook tweetalig. Waarmee we hopen ook Engelstalige expats te kunnen betrekken bij de vereniging.</li>
<li>Tot slot zijn onze <a href="https://plausible.io/fronteers.nl">website bezoekersstatistieken</a> voor iedereen openbaar in te zien.</li>
</ul>
<h2>Openingsactie!</h2>
<p>Om de nieuwe website te lanceren hebben we een openingsactie! De rest van het jaar berekenen wij <strong>geen kosten</strong> voor het <a href="https://www.fronteers.nl/nl/werk-en-freelance/vacature-plaatsen/">plaatsen van een vacature</a>.</p>
<h2>Bedankjes</h2>
<p>Ten eerste bedanken wij natuurlijk de <a href="https://github.com/fronteers/website/graphs/contributors">vrijwilligers en passanten</a> die in de afgelopen jaren een bijdrage hebben geleverd aan deze nieuwe website!</p>
<p>We worden gehost door Netlify die ons sponsort met een <a href="https://www.netlify.com/legal/open-source-policy/">Open Source Unlimited pakket</a>.</p>
<p>Het design is gemaakt door Ready For Take-Off, die je kunt kennen van de designs van Fronteers Conference 2015, 2016 en 2017.</p>
</content>
</entry>
<entry>
<title>Nieuw bestuur van 2023</title>
<link href="https://www.fronteers.nl/nl/blog/2024/01/nieuw-bestuur-van-2023"/>
<updated>2024-01-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2024/01/nieuw-bestuur-van-2023</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 10 november vond de jaarlijkse ALV (algemene leden vergadering) online plaats. Zoals velen ondertussen waarschijnlijk al wisten, hebben Anneke Sinnema en Edwin Martin besloten om hun rollen in het bestuur niet te verlengen.
Zowel Anneke als Edwin hebben een cruciale rol gespeeld voor Fronteers de afgelopen 6 jaar, Anneke als voorzitster en Edwin als secretaris.</p>
<p>Met de voorbije pandemie zal dit zeker niet makkelijk geweest zijn en dus wensen we hen beiden een toch wel zeer verdiende pauze toe. Beiden zullen nog altijd deel blijven uitmaken van Fronteers in de toekomst, maar dan in een andere rol.</p>
<p>De traditie met nieuwe mensen die zich kandidaat stelden werd inmiddels voortgezet en leden hadden de kans om hun stem uit te brengen. Het nieuwe bestuur bestaat uit Christian “Schepp” Schaefer, Jewwy Qadri, Wim van Iersel en Claudia Reynders.</p>
<p>In de weken opvolgend aan de ALV is het oude en het nieuwe bestuur samengekomen om de nieuwe rollen te verdelen en de uitkomst is als volgt:</p>
<p><em>Wim van Iersel</em> (banaan666) zet zijn rol als penningmeester voort nadat hij vorig jaar het stokje overnam van Sander Vink.Doordeweeks kun je Wim aan het werk vinden als webmaster/front-end developer voor Tilburg. Je kunt <a href="https://www.fronteers.nl/nl/blog/2022/11/nieuw-bestuurslid-wim-van-iersel">Wim’s officiële introductie ook lezen op de Fronteers blog</a>.</p>
<p><em>Christian Schaefer</em> (schepp), roepnaam “Schepp”, assisteert onze secretaris met documentatie en communicatie. Schepp heeft een vrij lange geschiedenis als Fronteers-lid en is een van de weinige Duitse leden. Na een paar jaar vrijwilligerswerk te hebben gedaan voor de conferentie, werd hij in 2019 eindelijk lid van de conferentiecommissie. Sinds 2010 is hij mede-presentator van een wekelijkse Duitse podcast over frontend-ontwikkeling, die nu de 600 afleveringen nadert. Schepp is ook mede-organisator van twee meetups: de lokale Düsseldorfse meetup Webworker NRW (2014 - gepauzeerd sinds 2020) en het online-only CSS Café (sinds 2020).</p>
<p><em>Jewwy Qadri</em> (Jewwy), volgt Edwin op als secretaris. Jewwy trad in 2019 toe tot de conferentiecommissie en maakte niet alleen deel uit van een prachtige editie, maar was ook zeer enthousiast om de boel opnieuw op te starten na de pandemie. Jewwy is sinds kort ook toegetreden tot de workshopcommissie waar hij nog meer mogelijkheden zoekt om mee te helpen organiseren. In zijn functie werkte Jewwy ruim tien jaar als front-end developer in de e-commerce sector, voordat hij onlangs bij een toegankelijkheids-adviesbureau aan de slag ging. Als hij niet met code bezig is of Fronteers vooruit helpt, scherpt hij zijn professionele bowling vaardigheden nog verder aan.</p>
<p><em>Claudia Reynders</em> (Claudia R) volgt Anneke op als voorzitter nadat ze sinds eind 2019 deel uitmaakte van de Belgische commissie als organisator van evenementen. Overdag werkt Claudia als community lead voor een Belgische codee school genaamd BeCode, waar ze de toekomst van nieuwe ontwikkelaars helpt vormgeven en hun curriculum beïnvloedt om belangrijke praktijken en kennis op te nemen.</p>
<p>We wensen jullie allemaal een prachtige start van het nieuwe jaar en kijken ernaar uit om de Fronteers-gemeenschap verder uit te bouwen!</p>
</content>
</entry>
<entry>
<title>ALV vanavond online</title>
<link href="https://www.fronteers.nl/nl/blog/2023/11/alv-vanavond-online"/>
<updated>2023-11-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/11/alv-vanavond-online</id>
<content xml:lang="nl" type="html"><p>De Algemene Ledenvergadering is verplaatst naar een online bijeenkomst. We maken hierbij gebruik van Slack. De vergadering start om 19:30 en stopt naar verwachting rond 21:30.</p>
<p>Leden van Fronteers die nu de ALV online is toch graag de ALV willen bijwonen kunnen zich aanmelden bij het bestuur. Dit kan via een e-mail naar <a href="mailto:secretaris@fronteers.nl">secretaris@fronteers.nl</a> of via een DM naar Edwin Martin op Slack.</p>
<p>Wil je meedoen maar ben je nog niet lid van de Fronteers Slack? <a href="https://join.slack.com/t/fronteersnl/shared_invite/zt-k3wyhquf-atZIftTxxCaPRpRlO744xg">Meld je hier aan voor onze Slack</a>. Als je je aanmeldt voegen wij je toe aan een besloten kanaal (#alv2023). Hier kun je de jaarstukken vinden en vooraf aan de ALV vragen stellen of agendapunten aandragen.</p>
</content>
</entry>
<entry>
<title>Kandidaat bestuur Fronteers: Claudia Reynders</title>
<link href="https://www.fronteers.nl/nl/blog/2023/11/kandidaat-bestuur-fronteers-claudia-reynders"/>
<updated>2023-11-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/11/kandidaat-bestuur-fronteers-claudia-reynders</id>
<content xml:lang="nl" type="html"><p>Aanstaande vrijdag vindt de jaarlijkse algemene ledenvergadering (ALV) van Fronteers plaats. Een van de onderdelen tijdens de ALV is de bestuursverkiezing. Kandidaat bestuurslid Claudia Reynders stelt zich voor!</p>
<p>Hoi ik ben Claudia Reynders, ondertussen al enkele jaren de drijfveer achter commissie België waar ik met heel veel passie meetups organiseer. Ik leerde Fronteers kennen ergens een goeie 10 jaar geleden dankzij een meetup in het Antwerpse.</p>
<p>Door me de laatste jaren voornamelijk in te zetten om de commissie en activiteiten in België terug op gang te trekken, voel ik me ook sterk betrokken bij de vereniging.</p>
<p>Zelf heb ik ook al best wat te danken aan Fronteers, zo heb ik door de jaren heen al enorm wat bijgeleerd, maar ook heel wat interessante mensen leren kennen. Zoals onlangs nog op Smashing Conference te Antwerpen! Zeker niet onbelangrijk is dat een aantal van de jobs in mijn carrière ook deels voortkomen uit dat deeltje netwerken en nieuwe connecties maken.</p>
<p>Ik wil ook nog even vermelden dat ik tot nu toe ook al best wat steun heb gehad aan mensen uit de online Fronteers community. Vooral Anneke heeft me de afgelopen jaren enorm geïnspireerd en gesteund. Daarom vind ik het ook jammer dat zij aftreedt, maar anderzijds is dat ook net wat me vandaag aanzet om me kandidaat te stellen als bestuurslid.</p>
<h1>Waar wil ik aan bijdragen?</h1>
<p>Fronteers heeft sinds het bestaan al veel verandering en verbetering gebracht dankzij de doelstelling van de vereniging en de mensen die zich tot nu toe daar hebben voor ingezet al die jaren.</p>
<p>De doelstelling:</p>
<p>&quot;<em>De professionalisering van het beroep front-end web development. Daarbij streven wij naar erkenning, verbetering en ondersteuning van de (positie van) Nederlandstalige front-end webontwikkelaars.</em>&quot;</p>
<p>Maar sinds de start van de pandemie merken we allemaal wel dat Fronteers een stuk minder actief is geworden en daar zou ik graag verandering in willen brengen. Eerst en vooral door de meetups in Nederland terug op gang te trekken, waarna andere activiteiten hopelijk ook volgen. Om dit te kunnen verwezenlijken zijn er natuurlijk mensen nodig die zich daar mee achter willen zetten. Het huidige bestuur heeft al een aanzet gedaan om interesse op te wekken, nu moeten we enkel zien over te gaan op actie. 💪</p>
<p>Verder wil ik ook graag voortzetten waar Anneke al mee begonnen was: het inzetten op onderwerpen zoals diversiteit, toegankelijkheid, transparantie van het bestuur enz...</p>
<p>En zoals Anneke het zo mooi beschreef gisteren:</p>
<p>&quot;Het glazen potje met kiezeltjes en stenen waar zand tussen gemixt zit, maar alles mooi samen doet hangen&quot; en dat is eigenlijk ook wel hoe ik mezelf zie, als iemand die haar steentje wil bijdragen waar mogelijk en nodig. Dit zie ik zelf vrij breed, maar weet ook dat het soms ook enkel gaat om kennisoverdracht en ondersteuning, taken delegeren en helpen sturen.</p>
<h1>Wie ben ik en wat kan je van mij verwachten?</h1>
<p>Ik stel mezelf altijd voor als een &quot;hearing impaired front-end designer with a focus on diversity, inclusion, accessibility and sustainability in tech&quot;.</p>
<p>Ik heb best een brede achtergrond en ervaring in IT. Oorspronkelijk ben ik opgeleid als PHP developer, een job waar ik eigenlijk amper in gewerkt heb want al gauw werd het duidelijk dat ik meer affiniteit en plezier had aan front-end development. Daarna heb ik ook nog een tijdje als product manager gewerkt en me ook verder verdiept in UX design.</p>
<p>Momenteel werk ik parttime als &quot;technical&quot; career coach voor een non-profit die bootcamps organiseert. Dit houdt in dat ik mensen begeleid in hun carrière switch in web development e.d. .</p>
<p>Naast Fronteers en mijn werk ben ik in België ook actief met het bouwen van een community voor vrouwelijke programmeurs. Samen met een aantal vrijwilligers organiseren we meetups, sturen we maandelijks een nieuwsbrief uit en hebben we nog tal van andere activiteiten en initiatieven. In al die zaken ben ik op 1 of andere manier wel betrokken en help meestal ook om alles in goede banen te leiden. Dus ik denk dat ik wel wat ervaring te bieden heb. :-)</p>
</content>
</entry>
<entry>
<title>Meld je aan voor de ALV 2023</title>
<link href="https://www.fronteers.nl/nl/blog/2023/10/meld-je-aan-voor-de-alv-2023"/>
<updated>2023-10-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/10/meld-je-aan-voor-de-alv-2023</id>
<content xml:lang="nl" type="html"><p>Op vrijdagavond 10 november houden we weer onze jaarlijkse algemene ledenvergadering (ALV)!</p>
<p>Het vindt <em>online</em> plaats. Alle leden zijn hiervoor van harte uitgenodigd, en we hopen nieuwe bestuursleden te verwelkomen!</p>
<p><a href="https://www.fronteers.nl/nl/blog/2023/10/meld-je-aan-voor-de-alv-2023#english">English version</a> below.</p>
<p>Tijdens de ALV nemen we als bestuur, vrijwilligers en leden samen de (financiële) staat van Fronteers door, en evalueren we hoe het gaat met de vereniging. Tot het begin van de vergadering kan elk lid een voorstel doen voor een agendapunt of een ter stemming te brengen onderwerp. De voorlopige agenda staat hieronder.</p>
<p>Wat in ieder geval zal worden behandeld zijn de jaarstukken van de vereniging over 2022, de financiën over 2023 en de nieuwe begroting voor 2024. Deze stukken zullen enkele dagen voor de ALV naar alle aangemelde aanwezigen worden opgestuurd. Mocht je niet aanwezig kunnen zijn, maar deze informatie wel willen inzien: laat het ons weten! Notulen van de avond worden altijd zo snel mogelijk na de vergadering online gedeeld.</p>
<p>Het is alweer drie jaar geleden dat bestuursleden Anneke en Edwin zijn herverkozen en dit jaar treden ze statutair weer af. Anneke stelt zich niet herkiesbaar. Edwin laat dit afhangen van de vorming van het nieuwe bestuur. Als dreigt dat het bestuur kleiner wordt dan drie personen, dan zal Edwin zich opnieuw verkiesbaar stellen.</p>
<p>Het mag duidelijk zijn: het bestuur zoekt versterking. Niet alleen voor de rol van voorzitter en secretaris, maar ook om het bestuur in het algemeen productiever te maken. Petra Knip heeft zich al kandidaat gesteld. Wil je je ook kandidaat stellen voor het bestuur? Laat het ons dan voor de ALV weten. Tijdens de ALV zal door de aanwezige leden voor nieuwe bestuursleden worden gestemd. Als lid kan je een aanwezig lid machtigen om voor je te stemmen.</p>
<p>Als bestuurslid help je mee de vereniging op de kaart te zetten en te houden. Je zorgt er voor dat commissies een zetje krijgen en dat vrijwilligers het zelfvertrouwen hebben om activiteiten te ontplooien voor de vereniging. We hebben de ambitie om weer vaker meetups en activiteiten te organiseren, zetten graag het Fronteerscongres voort, en zetten onze nieuwe website live. Anneke, Wim en Edwin staan je graag te woord via Slack of <a href="mailto:bestuur@fronteers.nl">bestuur@fronteers.nl</a> als je ons hierin wilt helpen!</p>
<ul>
<li>Opening</li>
<li>Vaststelling agenda</li>
<li>Toelichting Congres commissie</li>
<li>Toelichting Overige commissies</li>
<li>Jaarrekening 2022</li>
<li>Bevindingen kascommissie</li>
<li>Vaststellen jaarrekening</li>
<li>Benoeming nieuwe kascommissie</li>
<li>Financiën 2023 (voorlopig)</li>
<li>Begroting 2024</li>
<li>Invulling bestuur</li>
<li>Rondvraag</li>
</ul>
<p>Meld je aan door een email te sturen naar <a href="mailto:secretaris@fronteers.nl">secretaris@fronteers.nl</a> of laat het Edwin weten op Slack.</p>
<h1>English version</h1>
<p><em>On Friday evening, November 10, we will hold our annual general meeting (ALV) again! It takes place <em>online</em> at 7:30 PM via the <a href="https://join.slack.com/t/fronteersnl/shared_invite/zt-k3wyhquf-atZIftTxxCaPRpRlO744xg">Fronteers Slack channel</a>. All Fronteers members are cordially invited to this event, and we hope to welcome new board members!</em></p>
<p>During the AGM, the board, volunteers and members review the (financial) state of Fronteers together and evaluate how the association is doing. Until the beginning of the meeting, any member can make a proposal for an agenda item or a subject to be put to the vote. The provisional agenda is below.</p>
<p>What will in any case be discussed are the association's annual accounts for 2022, the finances for 2023 and the new budget for 2024. These documents will be sent to all registered attendees a few days before the AGM. If you are unable to attend, but would like to view this information, please let us know! Minutes of the evening are always shared online as soon as possible after the meeting.</p>
<p>It has been three years since board members Anneke and Edwin were re-elected and this year they are resigning by statute. Anneke is not standing for re-election. Edwin makes this depend on the formation of the new board. If there is a risk that the board will become smaller than three people, Edwin will stand for re-election.</p>
<p>It should be clear: the board is looking for reinforcement. Not only for the role of chairman and secretary, but also to make the board more productive in general. Petra Knip has already put herself forward as a candidate. Would you also like to stand as a candidate for the board? Then let us know before the AGM. During the AGM, the members present will vote for new board members. As a member you can authorize a member present to vote for you.</p>
<p>As a board member you help to put and keep the association on the map. You ensure that committees get a push and that volunteers have the self-confidence to develop activities for the association. We have the ambition to organize meetups and activities more often, would like to continue the Fronteers Congress, and are putting our new website live. Anneke, Wim and Edwin are happy to speak to you via Slack or <a href="mailto:bestuur@fronteers.nl">bestuur@fronteers.nl</a> if you would like to help us with this!</p>
<ul>
<li>Opening</li>
<li>Setting the agenda</li>
<li>Explanation of Congress committee</li>
<li>Explanation Other committees</li>
<li>Annual accounts 2022</li>
<li>Audit committee findings</li>
<li>Adopting annual accounts</li>
<li>Appointment of new audit committee</li>
<li>Finances 2023 (provisional)</li>
<li>Budget 2024</li>
<li>The Board</li>
<li>Any other business</li>
</ul>
<p>Register by sending an email to <a href="mailto:secretaris@fronteers.nl">secretaris@fronteers.nl</a> or let Edwin know on Slack.</p>
</content>
</entry>
<entry>
<title>Vrijwilligersetentje groot succes</title>
<link href="https://www.fronteers.nl/nl/blog/2023/07/vrijwilligers-etentje-groot-succes"/>
<updated>2023-07-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/07/vrijwilligers-etentje-groot-succes</id>
<content xml:lang="nl" type="html"><p>On Thursday, July 27th, we dined at LE:EN in Utrecht with existing and new volunteers, discussing Fronteers. As previously mentioned in an earlier post, we were <a href="https://www.fronteers.nl/nl/blog/2023/07/vrijwilligers-gezocht">seeking volunteers</a> to help revitalize the association.</p>
<p>Well, we succeeded! Between the &quot;Sprinkhaan Green Goddess&quot;-without-Sprinkhaan and the Choco Pie, we went through the attendees. We now have (the beginning of) a workshop committee, a complete education committee, and a complete marketing and communication committee. Additionally, there are three potential candidates for the board whom we plan to introduce to the role before the General Assembly.</p>
<p>Furthermore, Fronteers still has an active committee in Belgium and the conference committee (currently considering the future of the Fronteers conference), as well as occasional volunteers who lend their expertise in areas such as accessibility or help with the website.</p>
<p>It would be ideal to add three more names to the <a href="https://www.fronteers.nl/nl/blog/2023/07/vrijwilligers-gezocht#:~:text=3%20mensen%20voor%20de%20workshopcommissie">workshop committee</a> and combine it with the activities committee, so we can organize several enjoyable and educational workshops and gatherings once again!</p>
</content>
</entry>
<entry>
<title>Vrijwilligers gezocht!</title>
<link href="https://www.fronteers.nl/nl/blog/2023/07/vrijwilligers-gezocht"/>
<updated>2023-07-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/07/vrijwilligers-gezocht</id>
<content xml:lang="nl" type="html"><p>De vereniging zoekt versterking. Hieronder zet ik uiteen wie we waarvoor zoeken! Lijkt het je leuk om ons te helpen in één van onderstaande rollen, neem dan contact op met het <a href="mailto:bestuur@fronteers.nl">bestuur</a>.</p>
<p>Voor alle posities hieronder geldt het volgende:</p>
<ul>
<li>wij denken aan gemiddeld MAX 2 uur per week (maar gaan hierbij ook uit van asynchroon online contact dat hier onder valt)</li>
<li>vrijwilliger zijn bij Fronteers hoort geen geld te kosten: reiskostenvergoeding, declareren bonnetjes wanneer nodig.</li>
<li>vrijwilligers krijgen 50% korting op hun lidmaatschap.</li>
</ul>
<p>Binnen elke commissie is er 1 persoon die de commissie voorzit. Deze:</p>
<ul>
<li>communiceert met het bestuur</li>
<li>geeft aan als er nieuwe vrijwilligers nodig zijn</li>
<li>geeft aan als iemand stopt</li>
<li>communiceert tussen workshop, activiteiten en onderwijscommissie als er kans is om een gastspreker in te zetten voor workshop, meetup en gastles</li>
</ul>
<h2>3 mensen voor de workshopcommissie</h2>
<div class="note">Doel van de commissie: Faciliteren van kennisdeling)</div>
<p>We willen graag in het schooljaar 2023-2024 vier workshops organiseren. Bijvoorbeeld twee in Utrecht en twee in Amsterdam. Jules Ernst (accessibility) en Jad Joubran (JavaScript) zijn beschikbaar. Jeroen Reumkens (https://www.jeroenreumkens.nl/) is misschien een idee (creatief coden, animaties?). We willen graag onderwerpen voor junioren (introductie tot...) en senioren. Mogelijk vooraf een enquete doen/onderzoek om te kijken welke onderwerpen interessant zijn. Ouder idee: VIP developer overvliegen en die in twee of drie steden een workshop vragen te geven bij een gastbedrijf.</p>
<ul>
<li>Aantal personen per workshop: 12 (plus workshop docent en vrijwilliger)</li>
<li>Perks: vrijwilliger doet kosteloos aan workshop mee</li>
</ul>
<h2>3 mensen voor de activiteitencommissie</h2>
<div class="note">Doel van de commissie: Kennisdeling, collega's helpen netwerken</div>
<p>We zouden het liefst in het schooljaar 2023-2024 vier activiteiten organiseren om de zichtbaarheid van Fronteers te vergroten. Wat voor activiteit en waar die plaatsvindt, daar zit veel vrijheid in. De online meetups die sinds begin coronatijd zijn opgezet vallen ook onder de activiteitencommissie. Deze staan nu maandelijks ingepland, maar we kunnen de frequentie wat verlagen en de marketing online verhogen. Idee: Een sessie organiseren met/bij een partij als IederIn, Bartiméus voor verhogen bewustzijn toegankelijkheid. Bedrijven zouden waarschijnlijk graag een 'werkbezoek' hosten als we een vorm kunnen vinden om dit te doen zonder al te veel duidelijke 'reclame angle'. Netwerkevents zoals een gezamenlijke fietstocht bijvoorbeeld in de lente en zomer. Ouder idee: VIP developer (zie idee bij workshopcommissie) vragen om te spreken op een meetup</p>
<ul>
<li>Contact leggen met bedrijven die locatie willen sponsoren</li>
<li>Contact leggen met marketingcommissie over promotie van activiteit</li>
<li>Zelf aanwezig zijn op activiteit, of delegeren naar ander Fronteerslid (voor introductie van Fronteers)</li>
<li>Perks: Eigen zichtbaarheid, netwerken</li>
</ul>
<h2>2 mensen voor de voor onderwijscommissie</h2>
<div class="note">Doel van de commissie: Kennisdeling, professionaliseren van developers</div>
<p>Vroeger had Fronteers een onderwijscommissie, maar helaas is die al een tijdje inactief.
Het zou interessant zijn voor Fronteers om opnieuw docenten en de beroepspraktijk met elkaar in contact te brengen, zodat nieuwe developers goed beslagen ten ijs komen bij hun eerste baan (brede kennis hebben van toegankelijkheid, performance en duurzaamheid). En daarnaast onderwijsinstellingen (Hogescholen en bootcamps) te helpen in hun contacten met potentiële (gast)docenten. Bovendien is het goed om studenten te helpen met netwerken zodat ze minder kwetsbaar zijn wanneer ze een 'DEI achtergrond' hebben en (het komt helaas voor) te maken krijgen met lastige werksituaties.</p>
<ul>
<li>Contact leggen met onderwijsinstellingen en bootcamps, eens op lokatie koffie drinken en kennismaken met docenten</li>
<li>Contact leggen met mogelijke gastdocenten die interessant zijn om voor te stellen aan onderwijsinstellingen</li>
<li>Kansen zien voor Fronteers. Bijvoorbeeld event lokaties (sponsoring door onderwijsinstelling) voor workshops of meetups, mogelijkheid tot koppelen van 'carrière mentoren' (seniore collega's) met (net afgestudeerde) studenten, organiseren van een junior Jam Session</li>
</ul>
<h2>2 mensen voor de marketing- en communicatiecommissie</h2>
<div class="note">Doel van de commissie: Bekendheid van Fronteers vergroten en andere commissies ondersteunen</div>
<ul>
<li>ophalen van content en versturen van een nieuwsbrief elke 2 maanden</li>
<li>content op de website up to date houden</li>
<li>gastschrijvers voor het blog benaderen</li>
<li>regelen en bedenken promotiemateriaal/swag</li>
<li>(regelen van) vertegenwoordiging op congressen (als sponsoren van een event opportuun is) en meetups (vergoeding reiskosten)</li>
<li>beheer van de Fronteers 'kluis' (momenteel doet Jewwy dit 👌)</li>
<li>marketen van de mogelijkheid tot het plaatsen van vacatures bij Fronteers</li>
<li>kortingscodes regelen voor diensten/online cursussen/events buiten Fronteers gerelateerd aan webdevelopment</li>
</ul>
<h2>2 mensen voor het bestuur</h2>
<div class="note">Doel: voortbestaan van Fronteers garanderen, visie op de vereniging doorontwikkelen</div>
<p>Voorzitter Anneke is toe aan vervanging en om het voortbestaan van Fronteers te garanderen hebben we eigenlijk wat meer bestuursleden nodig. Op dit moment hebben we als rollen een voorzitter, een secretaris en een penningmeester. Het liefst komen hier twee bestuursleden bij die het bestuur ondersteunen op het punt van:</p>
<ul>
<li>Vrijwilligersmanagement (bedankjes aan ex vrijwilligers, nieuwe vrijwilligers zoeken)</li>
<li>Contact met de commissie België zodat die zich ondersteund weet in middelen als marketing, vrijwilligersbedankjes, etc.</li>
<li>Contact met de verschillende commissies en ondersteuning (bewustzijn van budget, aanmoedigen van initiatieven, commissies aan elkaar linken)</li>
</ul>
<h2>1 persoon voor de Commissie België</h2>
<p>De <a href="https://fronteersbe.github.io/">commissie België</a> bestaat nu uit drie personen (Claudia, Ibe, en Thomas) met Claudia als de kartrekker daar. Er wordt gezocht naar een vierde persoon om te helpen met het organiseren van activiteiten in Antwerpen, Limburg en Vlaams Brabant.</p>
<h2>Commissie Congres</h2>
<p>De huidige congrescommissie zal eerst moeten evalueren hoe mogelijk het men acht om in het komende jaar een evenement te plannen aangezien we helaas voor dit jaar het congres (wegens tegenvallende kaartverkoop) moesten annuleren.</p>
</content>
</entry>
<entry>
<title>Fronteers Conference is cancelled</title>
<link href="https://www.fronteers.nl/nl/blog/2023/07/fronteers-conference-is-cancelled"/>
<updated>2023-07-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/07/fronteers-conference-is-cancelled</id>
<content xml:lang="nl" type="html"><p>There will, unfortunately, be no Fronteers Conference this year.</p>
<p>With a very heavy heart, we have to inform you that we aren't able to hold our 14th conference.</p>
<p>Despite a big marketing push in the last few weeks, we needed to sell more tickets to make it possible for us to hold this year's conference. Unfortunately, we are still far from the break-even point, and projections suggest we won't be able to reach it. So we decided to cancel now before needing to make huge financial commitments to vendors like catering and the venue itself. The financial risk would have been too big to continue. We've extremely sorry as you might already have booked flights or hotels, but the decision was unavoidable and certainly not made lightly.</p>
<p>Thank you so much for your support for everyone who bought a ticket! It really means a lot. And we are very sorry we can't keep our side of the deal. We will refund your ticket as soon as possible. We've already instructed Tito to set things in motion, but it might take a few days to a week or two before the banks transfer the money back to you. We will keep an eye on the process to ensure everyone gets a full refund. If you have yet to receive your refund after two weeks, please let us know, and we'll try to find out what happened.</p>
<p>What this means for the future of the Fronteers Conference, we don't know. If something changes, we will definitely let you know.</p>
</content>
</entry>
<entry>
<title>Vrijwilligersdiner</title>
<link href="https://www.fronteers.nl/nl/blog/2023/06/vrijwilligersdiner"/>
<updated>2023-06-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/06/vrijwilligersdiner</id>
<content xml:lang="nl" type="html"><p>Op donderdagavond 27 juli gaan we met de vrijwilligers van Fronteers uit eten in Utrecht om de staat en de toekomst van Fronteers te bespreken. Maar we kunnen wel wat vers bloed gebruiken.</p>
<p>Wil jij ons helpen om de vereniging vernieuwd leven in te blazen? Graag nodigen we potentiële nieuwe vrijwilligers uit om op 27 juli aan te schuiven voor een kennismaking met onze verenigingscultuur!</p>
<p>Neem vòòr vrijdag 14 juli contact op met het bestuur als je mee wilt doen. Dit kan via Slack of via een <a href="mailto:bestuur@fronteers.nl">e-mail naar het bestuur</a>.</p>
</content>
</entry>
<entry>
<title>Fronteers.nl websitebouwdag op zaterdag 29 april</title>
<link href="https://www.fronteers.nl/nl/blog/2023/04/fronteers-nl-websitebouwdag-op-zaterdag-29-april"/>
<updated>2023-04-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/04/fronteers-nl-websitebouwdag-op-zaterdag-29-april</id>
<content xml:lang="nl" type="html"><p>Op zaterdag 29 april gaan we weer in Utrecht verder samenwerken aan de nieuwe website van Fronteers. Iedereen die zin heeft om aan te haken is welkom. Ervaring met het werken aan de website is niet nodig, er lopen meerdere leden rond die je alles kunnen uitleggen.</p>
<p><img src="https://www.fronteers.nl/_img/bijeenkomsten/2023/seven-zaal.webp" alt="" /></p>
<p>Op zaterdag 25 maart gaan we in Utrecht verder samenwerken aan de nieuwe website van Fronteers. Iedereen die zin heeft om aan te haken is welkom. Ervaring met het werken aan de website is niet nodig, er lopen meerdere leden rond die je alles kunnen uitleggen.</p>
<p>Waarom organiseren we deze dag? Fronteers is nu al een tijd bezig met de nieuwe website, maar het vordert niet zo snel. We hopen met deze dag de site een flinke boost te geven. Misschien komt de site die dag wel af?</p>
<p>De dag houden we op zaterdag 29 april van 11:00 tot 17:00 uur. Voor drinken en een lunch wordt gezorgd. Ook als je korter langs wil komen ben je welkom.</p>
<p>De locatie is bij <a href="https://www.google.com/maps/place/Restaurant+Seven/@52.0899045,5.115603,17z/data=!3m1!4b1!4m6!3m5!1s0x47c66f5b40a6e57d:0xae00eeee5182a113!8m2!3d52.0899045!4d5.1177917!16s%2Fg%2F11b7gxzjzx">Seven</a>, in het centrum van Utrecht, 6 minuten lopen vanaf Utrecht CS.</p>
<p>Restaurant Seven
Mariaplaats 7
3511LH Utrecht</p>
<p>Wil je ook komen en ons helpen? Meld je dan aan door een mail te sturen naar <a href="mailto:edwin.martin@fronteers.nl">edwin.martin@fronteers.nl</a>. Je hoeft alleen een laptop mee te nemen.</p>
<p>Wil je alvast een kijkje nemen? Op onze <a href="https://github.com/fronteers/website">GitHub-pagina</a> is alle informatie te vinden.</p>
</content>
</entry>
<entry>
<title>Fronteers.nl websitebouwdag op zaterdag 25 maart</title>
<link href="https://www.fronteers.nl/nl/blog/2023/03/fronteers-nl-websitebouwdag-op-zaterdag-25-maart"/>
<updated>2023-03-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/03/fronteers-nl-websitebouwdag-op-zaterdag-25-maart</id>
<content xml:lang="nl" type="html"><p>Op zaterdag 25 maart gaan we in Utrecht verder samenwerken aan de nieuwe website van Fronteers. Iedereen die zin heeft om aan te haken is welkom. Ervaring met het werken aan de website is niet nodig, er lopen meerdere leden rond die je alles kunnen uitleggen.</p>
<p>Waarom organiseren we deze dag? Fronteers is nu al een tijd bezig met de nieuwe website, maar het vordert niet zo snel. We hopen met deze dag de site een flinke boost te geven. Misschien komt de site die dag wel af?</p>
<p>De dag houden we op zaterdag 25 maart van 11:00 tot 17:00 uur (wie wil kan tot 18:00 uur blijven). Voor drinken en een lunch wordt gezorgd. Ook als je korter langs wil komen ben je welkom.</p>
<p>De locatie is bij <a href="https://www.google.com/maps/place/Restaurant+Seven/@52.0899045,5.115603,17z/data=!3m1!4b1!4m6!3m5!1s0x47c66f5b40a6e57d:0xae00eeee5182a113!8m2!3d52.0899045!4d5.1177917!16s%2Fg%2F11b7gxzjzx">Seven</a>, in het centrum van Utrecht, 6 minuten lopen vanaf Utrecht CS.</p>
<p>Restaurant Seven
Mariaplaats 7
3511LH Utrecht</p>
<p>Wil je ook komen en ons helpen? Meld je dan aan door een mail te sturen naar <a href="mailto:edwin.martin@fronteers.nl">edwin.martin@fronteers.nl</a>. Je hoeft alleen een laptop mee te nemen.</p>
<p>Wil je alvast een kijkje nemen? Op onze GitHub-pagina is alle informatie te vinden.</p>
</content>
</entry>
<entry>
<title>Fronteers Boekenclub 5 - The Programmer's Brain</title>
<link href="https://www.fronteers.nl/nl/blog/2023/03/fronteers-boekenclub-5-the-programmers-brain"/>
<updated>2023-03-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/03/fronteers-boekenclub-5-the-programmers-brain</id>
<content xml:lang="nl" type="html"><p>Bij de vijfde editie van de Fronteers Boekenclub lazen we <a href="https://www.manning.com/books/the-programmers-brain">“The Programmer’s Brain” van Felienne Hermans</a>.</p>
<p><img src="https://www.fronteers.nl/_img/fbc5-the-programmers-brain-felienne-hermans-200w.png" alt="Omslag The Programmer's Brain: What every programmer needs to know about cognition" /></p>
<p>“What every programmer needs to know about cognition”, zegt de ondertitel. Het is een beperkende titel, want het is een ontzettend interessant boek dat door heel veel meer mensen dan alleen programmeurs gelezen zou moeten worden.</p>
<p>Van ons zevenen was er maar 1 - Marrije - die zich geen programmeur zou willen noemen. Maar we hebben wel allemaal programmeerervaring. Programmeurs zijn net mensen, tenslotte; geen aparte categorie, niet slimmer of beter, niet gekker of eenkenniger.</p>
<h2>Over het boek</h2>
<p>Felienne - sommigen mogen [Fee-lie-nuh] zeggen - Hermans is <a href="https://vu.nl/nl/nieuws/2022/felienne-hermans-nieuwe-hoogleraar-computer-science-education">hoogleraar vakdidactiek van de informatica</a> aan de VU in Amsterdam en daarnaast 1 dag in de week docent op een middelbare school in Rotterdam. Ze heeft de <a href="https://hedycode.com/">programmeertaal Hedy</a> ontworpen, om kinderen al jong te leren programmeren.</p>
<p>Ze zei over leren programmeren: “Er zijn een paar redenen waardoor programmeren lastig is. Ten eerste moet je vaak heel veel tegelijk leren: de concepten van programmeren zoals invoer en uitvoer, of condities (de bekende if-then-else), maar ook de juiste schrijfwijze. Programmeertalen worden heel boos als je iets fout typt. Als je in Python een spatie op de verkeerde plek zet krijg je al een fout. Doordat je concepten en code tegelijk moet onthouden krijg je een cognitieve overload en onthoud je wat je leert niet zo goed.”</p>
<p>Het boek bestaat uit vier gedeelten; code lezen, over code denken, betere code schrijven, beter samenwerken. De aandachtige lezer vindt er oefeningen in, om code te lezen, te annoteren en te structureren. En tips. Wil je beter onthouden, gebruik dan <a href="https://nl.wikipedia.org/wiki/Flashkaart">flashcards</a>, net als bij het leren van Franse woordjes.</p>
<p>Er staat een heel (goed) hoofdstuk in over hoe je dingen moet noemen. Zoals het spreekwoord zegt: “There are only two hard things in computer science: cache invalidation and naming things”. Welnu, er zijn onderzoeken genoeg gedaan naar wat ‘t beste werkt. Gebruik bijv. geen afkortingen. En liever CamelCase dan snake_case. Niet te lang, niet te kort. Consistentie is beter dan je soms wel, soms niet je aan conventies houden.</p>
<p>En verder lazen we nuttige hoofdstukken over hoe we leren, hoe werkgeheugen, korte-termijngeheugen en langetermijngeheugen samenwerken.</p>
<p>Bekijk een <a href="https://www.youtube.com/watch?v=FJn6_dCp-BM">presentatie door Felienne Hermans</a> op YouTube.</p>
<h2>Wat we ervan vonden</h2>
<h3>Nina</h3>
<p>Ik zie mezelf als een programmeur die beter wil worden in programmeren. Het is een heel interessant boek, van hoog niveau, als een studieboek. Ik had het liever nog wat toegankelijker gehad.
In dit werk vind ik het lastig dat je moet blijven leren. Door de aanmoediging in dit boek wil ik dat gestructureerder doen, met flashcards en herhalingen. Ik denk dat het dan langer blijft kleven. Dit boek leerde me dat oké is als je iets niet begrijpt; je mist gewoon nog kennis of informatie en daar kan iedereen aan werken.</p>
<p><em>Oordeel: geen sterren</em>, want ik heb het nog niet uit.</p>
<h3>Rosita</h3>
<p>Ik zie mezelf niet als ‘echte’ programmeur. Maar ik ben het natuurlijk wel, als ik werk met HTML, CSS, JavaScript en PHP. Ik heb het boek nog niet helemaal uit. Ik vond het Engels pittig, het wetenschappelijk jargon in het boek was soms een drempel. Maar wel een heel goed boek, confronterend. Ik heb in mijn opleiding geleerd om veel notities te maken, zodat je het aan anderen door kunt geven. Dat blijkt in werk als programmeur te helpen.
Ik leer dagelijks. Ik had een JS cursus gedaan waar ik niks van snapte. Totdat ik een cursus deed die hetzelfde vertelde maar op een visuele manier, met betere handvatten. Toen snapte ik het beter. Dit boek helpt me beter begrijpen hoe mensen leren.</p>
<p><em>Oordeel: 4 sterren</em> - ook vanwege toegankelijk flink wat tekst, hoge informatiedichtheid</p>
<h3>Marrije</h3>
<p>Ik ben geen programmeur, echt niet. Mijn vader is programmeur. Ik ken BASIC van toen ik kind was. Verder ben ik projectmanager en informatie-architect. Ik vond dit een heel interessant en pittig boek. Voor mij waren de codevoorbeelden moeilijk toegankelijk. Het is meer een boek over hoe het brein werkt dan een boek over programmeurs. Ze legt heel duidelijk uit wat cognitive overload is; ik vond het geruststellend dat dit voor iedereen geldt. Goed is hoe ze laat zien hoe je code kunt annoteren, voor jezelf en voor anderen. Gewoon met pen en papier schetsen werkt heel goed. Daar leer je heel veel van, net als van flashcards gebruiken. Het is ook gewoon fijn om tactiel te werken. Dat helpt met begrijpen.</p>
<p><em>Oordeel: 4,5 sterren</em> - moeilijk maar de moeite waard.</p>
<h3>Jacqueline</h3>
<p>Ik dacht wel dat ik een programmeur was, totdat ik dit boek las. Ik kom echt vanuit een andere hoek, want de voorbeelden zijn erg technisch. Het is echt een studieboek. Wat ik heel leuk vond: het inzicht over hoe je leert. Focus is ook heel belangrijk. En de overload doordat je gestoord wordt. Het is niet gek om daarom bepaalde standaarden uit je hoofd te leren. Dit was een stimulans om toch echt te blijven studeren. Ik ga meer flashcards gebruiken; ik vond eerst dat dit iets voor op school was, maar nu weet ik dat me dit ook in m’n werk kan helpen. Dit boek kost tijd. En het zou interessant zijn om met een team te doen.</p>
<p><em>Oordeel: 4 sterren</em> - heel interessant, maar voelt wel als een studieboek</p>
<h3>Adam</h3>
<p>Ik vind mezelf wel een echte programmeur met 10 jaar ervaring in allerlei talen. Ik heb het als luisterboek geluisterd en als programmeur vind ik het echt het beste boek dat ik in tijden las. Beter zelfs dan ‘Clean Code’ van Uncle Bob. Veel geleerd, inspiratie voor de toekomst. Het was een eye-opener om te begrijpen waarom het moeilijk is om te schakelen tussen verschillende talen. En dat het nuttig is om afspraken te maken over conventies binnen een codebase. Het is nu ook helder voor me waarom je niet onmiddellijk een codebase kunt snappen. Commentaar in code is minder nuttig dan ik eerst dacht, dat patronen en namen zo belangrijk waren wist ik niet. Je hebt soms gewoon tijd nodig. Werkgevers die haast hebben, geven me geen goed gevoel. Ik moet het begrijpen. En dat kost tijd.</p>
<p><em>Oordeel: 5 sterren</em></p>
<h3>Annemiek</h3>
<p>Wat is een programmeur? Ik weet het niet, maar als je iets met JavaScript doet ben je een programmeur. Ik ben een startende developer. Als ik niet begrijp in een codebase, dan raakt me dat. Daarom vond ik het nuttig om te lezen over het verschil tussen iets niet kunnen en iets niet weten. En dat je niet tegelijkertijd code kunt lezen en begrijpen. Wat een herkenning, en erkenning, ook dat mensen met taalgevoel betere programmeurs zijn, omdat het meer gaat om lezen dan om logica. Het was nuttig dat ze suggereerde om code eerst op te knippen en lijntjes te trekken. Het is ook goed om meer in teams naar code te kijken.
Prima uitleg hoe hoe het brein werkt, met associaties, niet als een mappenstructuur.
Goed dat ze zei dat je als je iets moet opzoeken dat je eerst even moet proberen het uit je geheugen kunt halen. Als oefening.</p>
<p><em>Oordeel: 4,5 sterren</em> - menselijk geschreven</p>
<h3>Paul</h3>
<p>Ik vrees dat ik al heel lang een programmeur ben, al ontken ik dat graag. Ik ben helemaal niet zo gesteld op logica en abstractie, ik ben een talenmens en klooi graag maar wat aan. Ik verwachtte dat het een saai boek zou zijn, maar het is echt een heel goed en interessant boek. Ik waardeerde heel erg dat Hermans aanstipte dat kunnen lezen belangrijker is dan goed zijn in logica. Het stuk over de diverse type variabelen vond ik ook erg interessant. Al met al ben ik heel blij verrast door dit boek.</p>
<p><em>Oordeel: 4,5 sterren</em> - ik heb veel geleerd en het boek overtrof mijn verwachtingen</p>
<h2>FBC6: dinsdag 11 april</h2>
<p><img src="https://www.fronteers.nl/_img/fbc6-cathy-oneill-weapons-of-math-descruction-200w.png" alt="Omslag van 'Weapons of Math Destruction' door Cathy O'Neill. Het ontwerp suggereert een explosie en je ziet een doodshoofd gevormd door nodes." /></p>
<p>Bij de zesde editie bespreken we '<a href="https://en.wikipedia.org/wiki/Weapons_of_Math_Destruction">Weapons Of Math Destruction</a>' door Cathy O'Neill, een boek uit 2016. De omineuze ondertitel luidt: &quot;How Big Data Increases Inequality and Threatens Democracy&quot;.</p>
<p>&quot;WMDs, or Weapons of Math Destruction, are mathematical algorithms that supposedly take human traits and quantify them, resulting in damaging effects and the perpetuation of bias against certain groups of people.&quot;</p>
<p><a href="https://www.meetup.com/fronteers-nl/events/292029379/">Meld je aan via meetup.com</a>.</p>
</content>
</entry>
<entry>
<title>Met korting naar CSS Day 2023</title>
<link href="https://www.fronteers.nl/nl/blog/2023/01/met-korting-naar-css-day-2023"/>
<updated>2023-01-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2023/01/met-korting-naar-css-day-2023</id>
<content xml:lang="nl" type="html"><p>Op 8 en 9 juni organiseert Web Conferences Amsterdam voor de negende keer <a href="https://cssday.nl/">CSS Day</a>.</p>
<p>Zoals bij eerdere edities het geval was, krijgen Fronteers-leden korting op dit congres. Je betaalt 575 in plaats van 675 euro voor een kaartje voor beide dagen (alle bedragen exclusief BTW). Het aanbod is geldig voor mensen die op dit moment al lid zijn, en je kunt ervan gebruik maken door <a href="mailto:bestuur@fronteers.nl">een e-mail naar het bestuur</a> te zenden. Je ontvangt dan een kortingscode waarmee je je kaart kunt kopen.</p>
<p>CSS Day vindt dit jaar plaats op donderdag 8 en vrijdag 9 juni in de <a href="https://cssday.nl/2023/venue">Zuiderkerk</a> in Amsterdam.</p>
</content>
</entry>
<entry>
<title>Herfstblaadjes zien</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/herfstblaadjes-zien"/>
<updated>2022-12-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/herfstblaadjes-zien</id>
<content xml:lang="nl" type="html"><figure class="simple-quote">
<div class="simple-quote_decorative-start" aria-hidden="true">{</div>
<div class="simple-quote-content">
<blockquote>
<p>[...] als we ons afvragen wat dit wij is, wat zien is en wat ding of wereld is, komen we terecht in een labyrint van moeilijkheden en tegenstrijdigheden. Wat Sint-Augustinus zei over de tijd — dat het voor iedereen volkomen bekend is, maar dat niemand van ons het aan de anderen kan uitleggen — moet ook van de wereld worden gezegd.</p>
<p></p></blockquote>
<figcaption class="simple-quote-author">— Maurice Merleau-Ponty, Het Zichtbare en het Onzichtbare (1968)</figcaption>
</div>
<div class="simple-quote_decorative-end" aria-hidden="true">}</div><p></p>
</figure>
<p>Afgelopen herfstvakantie was ons gezin op vakantie in de Duitse Eifel. Ons zoontje Sam was 16 maanden oud, en naast rondgesjouwd worden in de schouderdrager wilde hij graag ook zelf stukjes lopen. Sam houdt niet van schoenen, en wanneer hij deze (onder luid protest) wél aan moet, gaat hij liever kruipen dan lopen. Dus dan maar op blote voeten.</p>
<figure class="figure">
<img src="https://www.fronteers.nl/_img/adventskalender/afbeelding-job-1.jpeg" alt="Een foto genomen op een asfalt bospad, dat zich uitstrekkend in de verte met een flauwe bocht naar rechts beweegt. Aan de linkerkant een heuvelrand, begroeid met bomen en struiken. Rechts een vangrail waarachter meer bomen te zien zijn. Het pad is bezaaid met herstbladeren. Een drietal personen, 2 volwassenen (man, vrouw) en een klein kind wandelen over het pad, met hun rug naar de camera. De man houdt het linkerhandje van het kind vast, in de rechterhand houdt het kind een herfstblaadje. De vrouw draagt een rode messenger-bag, donkere hoodie en spijkerbroek. De man draagt een platte pet, bruine jas en spijkerbroek. Het kind kijkt naar achter richting de camera, de volwassenen hebben hun blik op het kind gericht." />
<figcaption class="figure__caption">Aan de wandel op blote voeten. Foto: auteur.</figcaption>
</figure>
<h2>Blaadjes zien</h2>
<p>Tijdens deze wandelingen is elk gevallen herfstblaadje interessant. Voortdurend wordt het huidige opgeraapte blaadje verwisseld voor een ander blaadje dat de aandacht trekt. Sommige worden in stukjes gescheurd, andere blaadjes worden vluchtig bekeken en weer weggegooid.</p>
<p>Wandelingen verlopen langzaam op deze manier, maar om hem zo op zijn gemak bezig te zien met een veelvormigheid aan herfstblaadjes deed me wel afvragen: hoe ontvouwt de werkelijkheid zich voor Sam? Wat maakt juist die blaadjes interessant? Hoe ervaart hij de wereld om zich heen? En hoe heeft deze bewuste ervaring zich gevormd vanuit de “<em>great blooming, buzzing confusion”</em> aan indrukken waarover de psycholoog William James in 1890 schreef?</p>
<figure class="simple-quote">
<div class="simple-quote_decorative-start" aria-hidden="true">{</div>
<div class="simple-quote-content">
<blockquote>
<p>… any number of impressions, from any number of sensory sources, falling simultaneously on a mind which has not yet experienced them separately, will fuse into a single undivided object for that mind. The law is that all things fuse that can fuse, and nothing separates except what must. … The baby, assailed by eyes, ears, nose, skin, and entrails at once, feels it all as one great blooming, buzzing confusion; and to the very end of life, our location of all things in one space is due to the fact that the original extents or bignesses of all the sensations which came to our notice at once, coalesced together into one and the same space. There is no other reason than this why 'the hand I touch and see coincides spatially with the hand I immediately feel.'</p>
<p></p></blockquote>
<figcaption class="simple-quote-author">— William James, The Principles of Psychology (1890)</figcaption>
</div>
<div class="simple-quote_decorative-end" aria-hidden="true">}</div><p></p>
</figure>
<h2>Ontwerpen keuren</h2>
<p>Vanuit mijn werk in digitale toegankelijkheid word ik soms gevraagd om een ontwerp te keuren. Vaak zijn dit ontwerpen van websites, af en toe een app. Meestal binnen omgevingen zoals <em>Figma</em>, <em>Invision</em> of <em>Adobe XD,</em> maar ook in vroegere stadia zoals <em>creative exploration</em> of abstracte wireframes. De manier waarop ik naar ontwerpen probeer te kijken doet me denken aan hoe Sam misschien wel naar de wereld kijkt.</p>
<h2>Zien</h2>
<p>In zijn onvoltooide werk “Gedachten” — Pensées — schrijft de wiskundige, natuurkundige en filosoof Blaise Pascal over twee manieren van het benaderen van de werkelijkheid: het meetkundige denken, “l’espirit de géométrie”, en het fijne inzicht, “l’espirit de finesse”.</p>
<figure class="simple-quote">
<div class="simple-quote_decorative-start" aria-hidden="true">{</div>
<div class="simple-quote-content">
<blockquote>
<p>🇫🇷 Il y a beaucoup de différence entre l'esprit de géométrie et l'esprit de finesse. En l'un les principes sont palpables, mais éloignés de l'usage commun ; de sorte qu'on a peine à tourner la tète de ce côté-là, manque d'habitude : mais pour peu qu'on s'y tourne, on voit les principes à plein ; et il faudroit avoir tout à fait l'esprit faux pour mal raisonner sur des principes si gros qu'il est presque impossible qu'ils échappent. 🇳🇱 Verschil tussen het meetkundige denken en het fijne inzicht. Bij het eerste zijn de beginselen tastbaar, doch liggen buiten het dagelijkse leven, zodat men moeite heeft zijn hoofd in die richting te wenden omdat men dat niet gewoon is: men hoeft er slechts op te letten en men ziet de beginselen duidelijk. En men zou al helemaal een onverstandig mens moeten zijn om verkeerd te redeneren vanuit beginselen, die zo alledaags zijn dat het haast onmogelijk is eraan voorbij te zien.</p>
<p></p></blockquote>
<figcaption class="simple-quote-author">— Blaise Pascal, Pensées, (1669)</figcaption>
</div>
<div class="simple-quote_decorative-end" aria-hidden="true">}</div><p></p>
</figure>
<p>De geometrische geest denkt voornamelijk vanuit principes, oorzaken, gevolgen, en verbanden. Geometrisch denken maakt scheidingen tussen zaken, deelt in vakken, tekent lijnen.</p>
<p>De verfijnde geest denkt voornamelijk vanuit intuïtie. Het ervaren van zaken die niet per definitie duidelijk zijn voor anderen. Verfijnd denken omvat en combineert.</p>
<h2>Bashō en Tennyson</h2>
<p>Dit verschil tussen meetkundig en verfijnd denken wordt prachtig uitgedrukt in de manier waarop de Japanse dichter Matsuo Bashō en de Britse dichter Lord Alfred Tennyson (19e eeuw) spreken over het zien van een bloem:</p>
<figure class="simple-quote">
<div class="simple-quote_decorative-start" aria-hidden="true">{</div>
<div class="simple-quote-content">
<blockquote>
<p>🇯🇵 Yokoe mireba nazoena hana sakoe kakine kana 🇳🇱 Zie toch eens hoe het Herderstasje bij die heg in bloei staat; oh, kijk..!</p>
<p></p></blockquote>
<figcaption class="simple-quote-author">— Matsuo Bashō (17e eeuw)</figcaption>
</div>
<div class="simple-quote_decorative-end" aria-hidden="true">}</div><p></p>
</figure>
<figure class="simple-quote">
<div class="simple-quote_decorative-start" aria-hidden="true">{</div>
<div class="simple-quote-content">
<blockquote>
<p>🇬🇧 Flower in the crannied wall, I pluck you out of the crannies, I hold you here,root and all, in my hand, Little flower — but if I could understand What you are, root and all, and all in all, I should know what God and man is. 🇳🇱 Bloem in de gebarsten muur, Ik pluk je de spleten uit. Hier houd ik je in mijn hand, wortel en al Klein bloemetje – kon ik maar bevatten wat je bent, wortel en al, en al in al, dan zou ik weten wat God en de mens is.</p>
<p></p></blockquote>
<figcaption class="simple-quote-author">— Lord Alfred Tennyson (19e eeuw)</figcaption>
</div>
<div class="simple-quote_decorative-end" aria-hidden="true">}</div><p></p>
</figure>
<p>In beide gedichten staat het zien van — de ervaring van, de ontmoeting met — een bloem centraal. Maar de manier waarop de schrijvers een bloem ervaren verschilt sterk. Er is verwondering te lezen in beide gedichten, maar waar Bashō aanschouwt en uitnodigt, begint Tennyson met geometrie: het pakken van de bloem en daaruit te willen analyseren om uiteindelijk te willen begrijpen.</p>
<h2>Niet zien</h2>
<p>Beide gedichten over de bloem veronderstellen de aanwezigheid van de bloem. Dat deze is waargenomen. En hoewel ik bij het keuren van een ontwerp me probeer te realiseren wat ik zie, is het weten wat ik <em>niet</em> zie — en waarom — evenmin zo belangrijk. Denk bijvoorbeeld aan fenomenen zoals <a href="https://en.wikipedia.org/wiki/Banner_blindness">Banner Blindness</a>.</p>
<p>Wat we waarnemen is al het product van onbewuste selecties: van alle optische zenuwsignalen die onze visuele cortex bereiken is er gewoonweg te veel om alles te verwerken. Er wordt geselecteerd op wat er voor ons relevant is, en dat wordt primair gestuurd vanuit onze <em>doelen</em>.</p>
<p>Neem het beroemde experiment waarbij er een video getoond werd waarin twee groepen mensen elkaar een basketbal toespeelden. Een groep droeg donkere t-shirts, de andere groep witte. De toeschouwers hadden een doel: ze moesten het aantal keren tellen dat de bal tussen personen met een wit t-shirt werd gepasseerd. Halverwege de video liep er een vrouw in een gorilla-pak in beeld, richtte zich naar de camera, imiteerde een gorilla door zichzelf op de borst te slaan, en liep verder. De helft van de toeschouwers bleek later de “gorilla” niet te hebben gezien.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/afbeelding-job-2.png" alt="Een scene van een ruimte: op de achtergrond 3 liften. Verspreid door de ruimte staan verscheidene mensen in witte en zwarte t-shirts. Twee mensen in witte t-shirts staan dichtbij de camera, naar elkaar toe gericht. De rechterpersoon is licht door de knieën gebogen en houdt een bruine basketbal vast. In het midden van de ruimte staat een persoon in een gorillapak, kijkend naar de camera." /></p>
<p><em>Een frame uit <a href="https://www.youtube.com/watch?v=vJG698U2Mvo">de video die bij een van de selectieve-aandacht experimenten werd gebruikt</a>.</em></p>
<figure class="simple-quote">
<div class="simple-quote_decorative-start" aria-hidden="true">{</div>
<div class="simple-quote-content">
<blockquote>
<p>Approximately half of observers fail to notice an ongoing and highly salient but unexpected event while they are engaged in a primary monitoring task. This extends the phenomenon of inattentional blindness by at least an order of magnitude in the duration of the event that can be missed.</p>
<p></p></blockquote>
<figcaption class="simple-quote-author">— Daniel Simons &amp; Christopher Chabris, Gorillas in our midst: Sustained inattention blindness for dynamic events (1999)</figcaption>
</div>
<div class="simple-quote_decorative-end" aria-hidden="true">}</div><p></p>
</figure>
<p>De selectieve perceptie binnen ons bewustzijn fungeert als een zoeklicht — de fenomenoloog Edmund Husserl noemde dit het <em>Ichlicht,</em> de “ik-lamp”: ons <a href="https://plato.stanford.edu/entries/consciousness-intentionality/">bewustzijn is altijd ergens op gericht</a>, en daardoor zien we andere dingen niet, zoals het experiment demonstreert.</p>
<p>Het komt ook voor dat we meer in staat geraken om dingen waar te nemen doordat anderen dit doen. Een mooi voorbeeld hiervan is dat de ontdekking van de onverwachte planeet Uranus leidde tot meer ontdekkingen door een verschuiving van het mentaal kunnen kijken naar de werkelijkheid:</p>
<figure class="simple-quote">
<div class="simple-quote_decorative-start" aria-hidden="true">{</div>
<div class="simple-quote-content">
<blockquote>
<p>It was William Herschel’s discovery of Uranus in 1781, for example, the first discovery of a hitherto unknown planet in several millennia, that made astronomers mentally ready to notice additional ones, 67 as evidenced by the exceptionally rapid successive discoveries of the hitherto undetected four largest asteroids by three different astronomers between 1801 and 1807.</p>
<p></p></blockquote>
<figcaption class="simple-quote-author">— Eviatar Zerubavel, Hidden in Plain Sight (2015)</figcaption>
</div>
<div class="simple-quote_decorative-end" aria-hidden="true">}</div><p></p>
</figure>
<p>Hoe de mogelijkheid tot <em>zien</em> en <em>niet-zien</em> door cultuur en opvoeding kan worden beïnvloed, wordt ook prachtig beschreven door de taalkundige en oud-missionair <a href="https://en.wikipedia.org/wiki/Daniel_Everett">Daniel Everett</a> in het boek “Don’t Sleep, There Are Snakes”. Hierin vertelt hij over zijn leven bij de Amazoniaanse Pirahã stam:</p>
<p>Daniel Everett, _Don’t Sleep, There Are Snakes: Life and Language in the Amazonian Jungle (2008)</p>
<p>It was still around seventy-two degrees, though humid, far below the hundred-degree-plus heat of midday. I was rubbing the sleep from my eyes. I turned to Kohoi, my principal language teacher, and asked, &quot;What's up?&quot; He was standing to my right, his strong, brown, lean body tensed from what he was looking at.</p>
<p>&quot;Don't you see him over there?&quot; he asked impatiently. &quot;Xigagai, one of the beings that lives above the clouds, is standing on the beach yelling at us, telling us he will kill us if we go to the jungle.&quot;</p>
<p>&quot;Where?&quot; I asked. &quot;I don't see him.&quot;</p>
<p>&quot;Right there!&quot; Kohoi snapped, looking intently toward the middle of the apparently empty beach.</p>
<p>&quot;In the jungle behind the beach?&quot;</p>
<p>&quot;No! There on the beach. Look!&quot; he replied with exasperation.</p>
<p>In the jungle with the Pirahas I regularly failed to see wildlife they saw. My inexperienced eyes just weren't able to see as theirs did.</p>
<p>But this was different. Even I could tell that there was nothing on that white, sandy beach no more than one hundred yards away. And yet as certain as I was about this, the Pirahas were equally certain that there was something there. Maybe there had been something there that I just missed seeing, but they insisted that what they were seeing, Xigagaí, was still there.</p>
<p>Everyone continued to look toward the beach. I heard Kristene, my six-year-old daughter, at my side.</p>
<p>&quot;What are they looking at, Daddy?&quot;</p>
<p>&quot;I don't know. I can't see anything.&quot;</p>
<h2>Te veel zien</h2>
<p>De ervaring van Everett bij de Pirahā is vergelijkbaar met het probleem binnen AI en computerzicht: AI beeldherkenning is notoir slecht in het herkennen van zaken die voor de AI niet of onduidelijk bestaan. Net zoals Everett Xigagaí gewoonweg niet <em>kan</em> zien (en de Pirahã vergelijkbaar verkeerssignalen en markeringen niet <em>zagen</em> toen enkelen van hen met Everett naar een nabijgelegen stad reisden) is een AI engine niet in staat om dingen te zien die het model niet begrijpt of kent.</p>
<p>Dit “begrip van de wereld” probleem is onderdeel van het <a href="https://plato.stanford.edu/entries/frame-problem/">Frame Problem</a>. De cognitief wetenschapper en filosoof <a href="https://nl.wikipedia.org/wiki/Daniel_Dennett">Daniel Dennett</a> schrijft over de opgave om een AI systeem te bouwen wat op elk moment uit de werkelijkheid die het ervaart de <em>juiste</em> patronen weet te herkennen, en conclusies te trekken zonder in eindeloze verwerking terecht te komen waarbij de juiste aannames over de wereld worden gebruikt. Dennett beschrijft op humoristische wijze hoe een voor mensen relatief <a href="https://www.youtube.com/watch?v=cDA3_5982h8">eenvoudige taak als een boterham smeren</a> voor een AI een onoverkomelijk moeilijk probleem kan zijn. Hoe weet de AI (met zogenaamde <a href="https://nl.wikipedia.org/wiki/Kunstmatige_algemene_intelligentie">AGI</a> - “algemene intelligentie”) dat het temperatuurverschil in de kamer waar het zich bevindt niet relevant is voor de opdracht die het moet uitvoeren — of het feit dat er op dat moment geen olifanten in de buurt zijn?
Een model als <a href="https://en.wikipedia.org/wiki/GPT-3">GPT-3</a> is tot indrukwekkende resultaten in staat, maar handelt exclusief binnen het gebied van taalkundige verwerking en valt daardoor onder <a href="https://en.wikipedia.org/wiki/Weak_artificial_intelligence">narrow AI</a>.</p>
<p>Daniel Dennett, Cognitive Wheels: The Frame Problem of AI (1984)</p>
<p>What is needed is a system that genuinely ignores most of what it knows, and operates with a well-chosen portion of its knowledge at any moment. Well-chosen, but not chosen by exhaustive consideration. How, though, can you give a system rules for ignoring - or better, since explicit rule-following is not the problem, how can you design a system that reliably ignores what it ought to ignore under a wide variety of different circumstances in a complex action environment?</p>
<p>En hoewel wij mensen er in vergelijking met AI vreselijk goed in zijn om de complexe werkelijkheid tot de voor ons relevante patronen terug te brengen — iets dat we ons zelden beseffen — probeer ik me er bij het keuren van een ontwerp van bewust te zijn dat ik in patronen en heuristiek naar een ontwerp kijk, en dat dit voor anderen kan verschillen. Ik probeer te schakelen in de manier waarop ik naar het ontwerp kijk, en me voor te stellen hoe dit voor anderen en hun context en doelen zou kunnen zijn. Ik probeer te schakelen tussen manieren van waarnemen, <em>á la</em> Pascal.</p>
<h2>Anders zien</h2>
<p>Als ik naar de Grand Canyon kijk, kan ik dit op meerdere manieren zien. Als enorm ravijn, als scheur in een landschap, en als doorsnede van een vreselijk oude planeet.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/afbeelding-job-3.png" alt="Een rij van 3 foto’s van de Grand Canyon. De meest linkse is een hoog genomen luchtfoto, waarin de GC als scheur door het landschap trekt. De middelste foto is genomen vanaf de rand van een plek in de GC, een groot ravijn tonend waar onderin een rivier loopt. De rechtse foto toont een wand van de GC waarin de verscheidene aardlagen duidelijk zichtbaar worden." /></p>
<p><em>Meerdere manieren om naar de Grand Canyon te kijken.</em></p>
<p>Als toeristen-attractie. Als geologisch fenomeen. En ga zo maar door.</p>
<p>Wanneer ik zo actief aan het <em>perception-switchen</em> ben merk ik dat het me helpt om een ontwerp anders te zien, en me beter voor te stellen hoe een gedeelte verkeerd begrepen zou kunnen worden, of onduidelijk is. Ik probeer dingen terug te brengen tot hun essentie, tot datgene wat ze maakt dat ze zijn. Van knop, tot navigatiebalk, tot blogpost.</p>
<p>Wat maakt bijvoorbeeld dat een knop een knop is? Dat is geen eenvoudige vraag. Om Pascal er weer bij te halen: je kunt een vraag als deze beantwoorden via het meetkundige denken — de plaats, contrast, tekst, grootte — maar ook met de <em>verfijnde geest:</em> <a href="https://www.jstor.org/stable/41682743#metadata_info_tab_contents">waarom vind ik dit een knop</a>?</p>
<p>Hart &amp; Hegeman Manufactoring Corporation, Push Switch (1905)</p>
<p>First and foremost, buttons should easily bend to the will of their operators; they should cause no difficulty for pressers …</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/afbeelding-job-4.png" alt="Een horizontale serie afbeeldingen van verschillende knoppen. Van links naar rechts: een fysieke drukknop van plastic met groot rond drukvlak; een tekst-knop gemaakt van zwarte tekst &quot;&quot; op grijze achtergrond; een grafische knop met zwarte gecentreerde tekst &quot;OK&quot; op grijze achtergrond; een blauwe knop met zwarte gecentreerde tekst &quot;Button&quot;, waarbij de knop ronde hoeken heeft en een diepte-effect vertoont; een knop met paars-blauw-groen gradient achtergrond en de zwarte gecentreerde tekst &quot;button&quot;." /></p>
<p>Maar vergeet het experiment met de gorilla niet: we bekijken, filteren en verwerken de werkelijkheid afhankelijk van onze doelen. Dus ook: verwacht ik daar een knop?</p>
<h2>Een “plek om van af te vallen” en een “plek om van af te stappen”</h2>
<p>In zijn boek “The Ecological Approach to Visual Perception” schrijft psycholoog James Gibson (bekend van het begrip <em><a href="https://en.wikipedia.org/wiki/Affordance">affordance</a>,</em> hoewel deze term is terug te voeren naar <a href="https://nl.wikipedia.org/wiki/Kurt_Lewin">Kurt Lewin</a>’s &quot;Aufforderungscharakter”) onder andere over hoe wezens de omgeving om hen heen waarnemen:</p>
<p>James Gibson, The Ecological Approach to Visual Perception (1979)</p>
<p>A <em>brink</em>, the edge of a cliff, is a very significant terrain feature. It is a falling-off place. It affords injury and therefore needs to be perceived by a pedestrian animal. The edge is dangerous, but the near surface is safe. Thus, there is a principle for the control of locomotion that involves what I will call the edge of danger and a gradient of danger, that is, the closer to the brink the greater the danger. This principle is very general.</p>
<p>A step, or stepping-off place, differs from a brink in size, relative to the size of the animal. It thus affords pedestrian locomotion. A stairway, a layout of adjacent steps, affords both descent and ascent. Note that a stairway consists of convex edges and concave corners alternating, in the nomenclature here employed.</p>
<p>Deze manier van de omgeving waarnemen — als iets dat <em>faciliteert:</em> af-vallen, of af-stappen — probeer ik ook toe te passen op de manier waarop ik naar een ontwerp of een interface kijk. Dat betekent concreet dat ik probeer te zien wat het element van de interface betekent voor mij als gebruiker.</p>
<p>Dus niet alleen sign-up-formulier, maar ook <em>uitnodiging om lid te worden,</em> en <em>plek om informatie te delen</em>. Niet alleen <em>link,</em> ook <em>navigatie, verplaatsing,</em> en in het geval van bijvoorbeeld een link “view comments” ook interpretaties als <em>“plek met bijdragen”,</em> waaruit wellicht de vraag komt of het relevant is dat de hoeveelheid comments er bij wordt vermeld, en waarom er comments mogelijk zijn, hoe dat past in de rest van de interface, en zo verder.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/afbeelding-job-5.png" alt="Een foto van een baby die richting een vrouw kruipt. De baby kruipt binnen een houten vierkante frameconstructie met glazen bodem waarvan de helft door een geblokt patroon bedekt is. De vrouw staat buiten het houten frame en nodigt de baby lachend uit om naar haar toe te kruipen. De baby is bijna halverwege en begint de doorzichtige helft van de ondergrond te bereiken." /></p>
<p><em>Een foto van het <a href="https://en.wikipedia.org/wiki/Visual_cliff">“Visual Cliff” experiment van Eleanor J. Gibson uit 1960</a>. Is het een plaats om af te vallen, of af te stappen? Het doel van het kind is uiteindelijk om de moeder te bereiken. Hoe ervaart het kind de werkelijkheid?</em></p>
<p>Deze “reducerende geest” die voortdurend de vraag stelt “waar kijk ik naar, en welke ervaring heb ik hierbij?” is terug te vinden in de kunsten. Zie bijvoorbeeld hoe een <a href="https://nl.wikipedia.org/wiki/Tronie_(schilderkunst)">tronie</a> zoals het <em>Meisje met de Parel</em> een grotere gelijkenis vertoont met de zintuigelijke ervaring, terwijl het kubisme van Picasso experimenteert met herkenbaarheid, vormen en patronen. De <em>Black Square</em> van Malevich en <em>Composition II in Red, Blue and Yellow</em> van Mondriaan stellen ons steeds weer de vraag over wat het is om naar pure vormen, lijnen en kleuren te kijken en wat dit met ons doet.</p>
<p>Een iconische meubel zoals de <em>Zig-Zag Stoel</em> van Rietveld doet dit vergelijkbaar. We zien waarschijnlijk dat het een stoel is. Maar waarom? Wanneer is dit niet langer het geval? Voor wie is dit geen herkenbare, of zelfs bruikbare stoel?</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/afbeelding-job-6.png" alt="5 afbeeldingen in een horizontale rij. 1: een schilderij van een jong blank meisje, en profil in linkerrichting. Ze draagt een blauw met gele tulband, haar gezicht lichtjes naar de camera gedraaid. Ze draagt een kleine parel in haar linker-oor. 2: een cubistische weergave van een vrouw die een mandoline bespeelt. 3: een zwart vlak omlijnd door een wit vlak in de ratio 1:3. 4: Een grid met meerdere vierkanten in verscheidene groottes. 3 zijn gekleurd: rechtsboven (rood), rechtsonder (geel) en linksonder (blauw). De anderen zijn wit, en elk vierkant is gescheiden van het andere door een dikke zwarte lijn. 5: een houten stoel samengesteld uit 4 vierkante platen die aan elkaar bevestigd zijn zodat 1 platte de &quot;voet&quot; vormt, 1 platte het zitvlak, 1 staande de rugleuning, en 1 verbindt het zitvlak en voet." /></p>
<p><em>Van links naar rechts: Meisje met de Parel, Johannes Vermeer; Girl with a Mandolin, Pablo Picasso; Black Square, Kazimir Malevich; Composition II in Red, Blue, and Yellow, Piet Mondriaan; Zig-Zag Stoel, Gerrit Rietveld.</em></p>
<p>Dit raakt aan zowel <a href="https://nl.wikipedia.org/wiki/Ontologie_(filosofie)">ontologie</a> — de categorieën van het Zijn — als aan <a href="https://nl.wikipedia.org/wiki/Fenomenologie">fenomenologie</a>: wat is het om te ervaren? Welke categorieën en beelden komen in ons op wanneer we kijken, wanneer we lezen?</p>
<h2>Merels zien</h2>
<p>Wallace Stevens, Thirteen Ways of Looking at a Blackbird [stanzas I, II, VII] (1954)</p>
<p>Among twenty snowy mountains,</p>
<p>The only moving thing</p>
<p>Was the eye of the blackbird.</p>
<p>I was of three minds,</p>
<p>Like a tree</p>
<p>In which there are three blackbirds.</p>
<p>O thin men of Haddam,</p>
<p>Why do you imagine golden birds?</p>
<p>Do you not see how the blackbird</p>
<p>Walks around the feet</p>
<p>Of the women about you?</p>
<p>Goede kans dat tijdens het lezen van deze 3 stanza’s er allerlei beelden door je hoofd schoten. Van bergen, vogels, bomen en meer. Hoe zagen die bomen er uit?</p>
<p>Binnen de cognitieve psychologie wordt een mentale categorie (zoals “vogel”) een concept genoemd. In het geval dat je je een voorstelling maakt van een voorbeeld binnen de categorie heet dit een prototype. Deze worden beïnvloed door je ervaringen: binnen de categorie “vogel” zul je eerder aan een kraai, roodborstje, meeuw of adelaar denken dan aan een pinguïn.</p>
<p>Binnen de fenomenologie is dit vergelijkbaar met de essentie van een ding: de fundamentele manier waarop het in je bewustzijn bestaat. Wanneer je bijvoorbeeld over een boom nadenkt, heeft die boom in je bewustzijn meerdere dimensies. Een voorkant, een achterkant. Ook al is de fysieke boom waar je naar kijkt op dat moment voor jou alleen van 1 kant te bekijken.</p>
<p>En ook al mocht je niet naar een <em>daadwerkelijke boom</em> kijken — misschien is het wel een als boom verklede front-end ontwikkelaar — in je bewustzijn is de essentie van het <em>ding</em> nog steeds een boom.</p>
<p>Dit alles geldt ook voor een knop. Een navigatiebalk. Een invoerformulier. Wanneer je aan een “OK knop” denkt, heb je daar een bepaald beeld en verwachting bij. Bij het doelmatig verkennen van een ontwerp filter je daar op. Zoals je op zoek gaat naar dat éne stukje Lego. Zo probeer ik me bij het keuren van een ontwerp ook nadrukkelijk bewust te zijn van de onbewuste verwachtingspatronen die ik hanteer. Paradoxaal als dat klinkt.</p>
<p>Ludwig Wittgenstein, Filosofische Onderzoekingen (1953) (geparafraseerd)</p>
<p>De aspecten van de dingen die voor ons het meest belangrijk zijn blijven ons door hun eenvoud en alledaagsheid verborgen. (Je merkt het niet op — omdat je het altijd voor ogen hebt.) De echte grondbeginselen van ons onderzoek vallen ons niet op.</p>
<h2>Symbolen zien</h2>
<p>Tijdens het kijken naar een ontwerp komen er veelvuldig symbolen en iconen voorbij. Ik probeer me hierbij bewust te zijn van de <a href="https://en.wikipedia.org/wiki/Semiotics_of_culture">cultuursemiotiek</a> — <em>waarom</em> ik bepaalde symbolen kan interpreteren — en tot in hoeverre de symbolen kunnen bijdragen aan de begrijpbaarheid van het ontwerp. En hoewel het ▶️ ”play” symbool binnen de context van een video bijna universeel begrepen wordt, geef ik er nog steeds de voorkeur aan om er tekst bij te plaatsen. Andersom kunnen symbolen de begrijpbaarheid van tekst vergroten:</p>
<p>Susan B. Barnes: An Introduction to Visual Communication: From Cave Art to Second Life (2nd edition) (2011) - mijn nadruk.</p>
<p>Today, people are more visually wired. They follow directions with text and graphics 323% better than with text alone. Images are also more persuasive. … In electronic contexts—including computer screens, the World Wide Web, multimedia environments, and virtual reality—the use of visual icons can be compared to written language because visual icons execute computer commands […] understanding the relationship between iconic desktops and physical ones is a key concept behind user-friendly metaphors.</p>
<p>Masoud Yazdani, Iconic Communication [chapter 6: Communication Through Icons, by Philip Barker and Paul van Schaik] (2000)</p>
<p>The argument that we should consider the combination of text and icon as a solution to our communicative objective may be a positive step forward. Is it not true that we see in our everyday life people combining spoken language with gestures, hand and eye movements, intonational variations?</p>
<h2>Kom en zie</h2>
<p>Uiteindelijk beschouw ik het keuren van een ontwerp als een existentiële handeling. Het vertelt me iets over een ander, of anderen: zij die het ontwerp tot stand brachten. Het zegt iets over hun kijk op de wereld, en hoe een spectrum van mogelijke doelen door hen naar een ontwerp wordt vertaald.</p>
<p>Tegelijkertijd vertelt het me ook over mijzelf: de dingen die ik zie (of niet zie) bij het ervaren van het ontwerp. Het schrijven van het rapport dwingt me om deze ervaring — en de daaruit voortvloeiende observaties — in concrete taal op te schrijven. Om na te denken over datgene waar ik precies naar kijk en hoe ik tot die conclusie kom.</p>
<p>Zo gezien (sorry) is ontwerp-keuring een voortdurende dialoog op meerdere aspecten. Een dialoog met een toekomstig gebruiksscenario: wat kan hier misgaan? En op welke manieren en waardoor? Welke perspectieven kan ik hanteren om het ontwerp anders te zien? Van welke dingen ben ik me misschien minder of niet bewust?</p>
<figure class="simple-quote">
<div class="simple-quote_decorative-start" aria-hidden="true">{</div>
<div class="simple-quote-content">
<blockquote>
<p>One sees the environment not with the eyes but with the eyes-in-the-head-on-the-body-resting-on-the-ground.</p>
<p></p></blockquote>
<figcaption class="simple-quote-author">— James Gibson</figcaption>
</div>
<div class="simple-quote_decorative-end" aria-hidden="true">}</div><p></p>
</figure>
<p>Wat we zien, en niet zien. De herfst, het bos, het asfaltpad. Je vrouw. Je zoontje. Blote voetjes. Een vuistje met herfstblaadje.</p>
<p>Hoe ik dit alles concreet toepas tijdens het samenstellen van een keuringsrapport schrijf ik in een vervolg. 🍂</p>
<p>Met dank aan <a href="https://boeddhistischdagblad.nl/auteurs/30649-column-dick/">Dick Verstegen</a>. Alle afbeeldingen via Wikipedia behalve wanneer anders vermeld.</p>
</content>
</entry>
<entry>
<title>A Design Token Carol</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/a-design-token-carol"/>
<updated>2022-12-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/a-design-token-carol</id>
<content xml:lang="nl" type="html"><p>Design Tokens implementeren. Waarom zou je eraan willen beginnen? Welke mogelijkheden zijn er? En wat komt men zoal tegen tijdens de implementatie ervan?</p>
<p>Het is bijna kerst en als ik denk aan kerst, denk ik aan ‘A Christmas Carol’ van Charles Dickens. Eigenlijk denk ik dan ook altijd aan Harry Potter. Elke kerst kijk ik weer een keer alle Harry Potter films. Maar omdat Harry’s Design Tokens niet zo lekker klinkt en ik 7 delen wat lang vind houd ik het bij de 3 delen van ‘a Christmas Carol’. En met dat kerstverhaal in gedachten, schrijf ik dit verhaal met behulp van de 3 design token geesten:</p>
<ol>
<li>De geest van de tijd toen we nog niet wisten wat design tokens waren</li>
<li>De geest van de huidige tijd nu we design tokens implementeren</li>
<li>De geest van de toekomst die ons laat zien wat we met design tokens kunnen bereiken</li>
</ol>
<h2>De tijd toen we nog niet wisten wat design tokens waren</h2>
<p>De eerste geest neemt ons mee naar de tijd toen we nog niet wisten wat design tokens waren.</p>
<ul>
<li>Toen gebruikten we nog SCSS- en CSS variabelen door elkaar heen.</li>
<li>We hadden variabelen voor alle design system kleuren. We hadden ook al variabelen voor lettertypen en scherm groottes. Maar nog niet voor de verschillende lagen, maatvoering en schaduwen van componenten.</li>
<li>Bij een rebranding werden er nieuwe kleurnamen bedacht met nieuwe waardes. En dan was het een stoelendans om de nieuwe kleuren op de verouderde kleuren te plotten en ervoor te zorgen dat het design system in overeenstemming met oudere versies bleef.</li>
</ul>
<p>Er miste nog iets; een structuur voor de benaming van de kleinste herbruikbare onderdelen van het design system. Een methode om die onderdelen te definiëren en te gebruiken in elke technische implementatie. Met als doel de technische implementatie(s) zo agnostisch, droog(DRY) mogelijk en direct overal te kunnen updaten wanneer er wijzigingen zijn.</p>
<p>Voor die redenen zijn Design Tokens bedacht. Design Tokens zijn de kleinste ondeelbare delen van een design system zoals kleuren, tussenruimte en lettergrootte. Design tokens zijn gecreëerd door het Salesforce design system team, en de naam is ook door dat team bedacht.</p>
<blockquote>
<p>Design Tokens are a methodology. IMHO, saying &quot;design tokens are just variables&quot; is like saying &quot;responsive design is just media queries&quot;. It's a technology-agnostic architecture and process for scaling design across multiple platforms and devices, including native, and more.</p>
</blockquote>
<p>In 2019 is ‘<a href="https://www.w3.org/community/design-tokens/">The Design Tokens Community Group</a>’ opgericht. Het doel van deze groep is om standaarden te creëeren, waarop producten en design software kunnen steunen voor het delen van de styling onderdelen van een design system.</p>
<h2>Vandaag</h2>
<p>De tweede geest neemt ons mee naar het nu. De tijd waarin we bezig zijn om design tokens te implementeren. Design Token standaarden zijn nog niet definitief. En tot die tijd zijn er verschillende mogelijkheden om uit te kiezen en om mee te werken. De opbouw en stappen die men daarin volgt zijn overal wel hetzelfde:</p>
<h2>1. Structuur en Opbouw</h2>
<p>Er zijn verschillende manieren om de taxonomie van design tokens in te richten. Zo een structuur zorgt ervoor dat wanneer (nieuwe) tokens geïntroduceerd worden deze dezelfde opbouw hebben. Een voorbeeld vind je in de afbeelding hieronder. Daar bestaat een token altijd uit een design system naam en categorie en zal een token meestal ook een modifier bevatten. <a href="https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676">Bron</a></p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/blog-nina-1.png" alt="Een voorbeeld van een structuur van de naamgeving van design tokens" /></p>
<h2>2. Naamgeving</h2>
<p>Elk design system dat ik ben tegen gekomen hanteert weer andere conventies voor de naamgeving van tokens. Zo maakt <a href="https://www.notion.so/2317415513144ecc9ff32b5160254bcb">Adobe Spectrum</a> gebruik van de volgende type tokens en lagen: (Zie afbeelding).
<a href="https://spectrum.adobe.com/page/design-tokens/#Design-token-types">Bron</a></p>
<ul>
<li>globale tokens als basis voor andere tokens zoals bijvoorbeeld een kleur: <code>blue-400</code></li>
<li>alias tokens t.b.v. een activiteit of andere toepassing zoals <code>cta-background-color</code> (cta staat hier voor call to action)</li>
<li>component specifieke tokens zoals<code>button-cta-background-color</code></li>
</ul>
<p><img src="https://www.fronteers.nl/_img/adventskalender/blog-nina-2.png" alt="De naamgeving die Adobe Spectrum hanteert" /></p>
<p><a href="https://www.notion.so/2317415513144ecc9ff32b5160254bcb">Salesforce</a> hanteert een iets andere structuur. Ze hebben bijvoorbeeld 2 type tokens en hanteren een andere naamgeving zoals bijvoorbeeld voor kleur: <code>$palette-blue-95</code> die als basis dient voor <code>$brand-background-primary</code> . En <a href="https://www.notion.so/2317415513144ecc9ff32b5160254bcb">Shopify</a> hanteert ook een eigen structuur. En die heeft bijvoorbeeld gekozen voor de term interactive in plaats van de afkorting for call to action en houdt het bij 1 token: <code>p-interactive</code>.</p>
<p>Welke conventie ook gekozen wordt, leg eerst met het team een aantal voorbeelden vast. Op die manier zorg je ervoor dat de kans op miscommunicatie en misverstanden verkleint.</p>
<h2>3. Notatie en Verspreiding</h2>
<p>Afhankelijk van hoeveel developers/designers design tokens gaan gebruiken, zijn er verschillende keuzes voor het vastleggen van design tokens. Als de tokens gebruikt gaan worden door een kleine groep die allemaal CSS gebruikt kan het voldoende zijn de tokens alleen als CSS variabelen vast te leggen. Je kunt zelfs overwegen design software in te zetten als compiler voor je tokens. Zowel <a href="https://www.figma.com/community/plugin/843461159747178978/Figma-Tokens">Figma</a> als <a href="https://sketchelements.com/plugins/design-tokens/">Sketch</a> bieden de optie design tokens vanuit je design om te zetten naar CSS variabelen of een JSON bestand. Als de gebruikers groep groter is en ook gebruikt maakt van verschillende technieken zoals SCSS of Flutter dan is het wellicht handiger een standaard notatie als JSON te gebruiken en zelf een compiler te bouwen. Of om een package als <a href="https://amzn.github.io/style-dictionary/#/">Style Dictionary</a> te implementeren die het voor je naar elk gewenst formaat kan omzetten.</p>
<h2>De Toekomst</h2>
<p>De laatste geest van vandaag neemt ons mee naar de toekomst. In de toekomst is er 1 standaard voor het vastleggen en verspreiden van design tokens; de Design Token(DT) Standaard. De DT Standaard is in 2025 ontwikkeld en gepubliceerd door de Design Token community groep. Via elke design software kunnen designers de design tokens van hun merk veilig publiceren en kunnen de design tokens via die weg in elke applicatie worden gebruikt. Wanneer een designer een token update en opslaat is dat direct te zien in de applicaties die gebruik maken van de tokens.</p>
<p>Wil je op de hoogte gehouden worden van die toekomst of bijdragen eraan? Ga dan naar de <a href="https://www.w3.org/community/design-tokens/">Design Token community groep</a>. Wil je af en toe gezellig mee praten over UI en UX op Fronteers Slack? Join dan <a href="https://fronteersnl.slack.com/archives/C0YCG8058">de channel #ui-ux</a>.</p>
</content>
</entry>
<entry>
<title>Wordt eens volwassen; Het Accessibility Maturity Model</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/wordt-eens-volwassen-het-accessibility-maturity-model"/>
<updated>2022-12-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/wordt-eens-volwassen-het-accessibility-maturity-model</id>
<content xml:lang="nl" type="html"><p>In een wereldbeeld waarin diversiteit en inclusie gelukkig steeds meer op de agenda staan, is digitale toegankelijkheid voor veel organisaties nog onbekend terrein. De meeste organisaties komen er mee in aanraking door wettelijke eisen, omdat ze bijvoorbeeld producten leveren aan een overheidsorganisatie. Daar wordt gevraagd of ze aan de gestelde eisen rond digitale toegankelijkheid voldoen.</p>
<p>Ook zijn er organisaties die hun eerste stappen al hebben gezet. Ze hebben bijvoorbeeld een onderzoek laten uitvoeren door een expert, hebben een training gevolgd en zijn met alle bevindingen aan de slag gegaan.</p>
<p>Hoe maak je dan als organisatie de volgende stap? Wat doe je om digitale toegankelijkheid te verankeren in je processen? Hoe ga je ervoor zorgen dat wat je zojuist bent begonnen niet een eenmalige actie blijft? Je wilt natuurlijk niet dat de resultaten volgende jaar alweer teniet gedaan zijn. Je wilt toewerken naar een situatie waarin je als organisatie volwassen wordt in digitale toegankelijkheid.</p>
<h2>Wat is digitale toegankelijkheid?</h2>
<p>Voordat we verder gaan, misschien hoor je als lezer wel tot die groep die eigenlijk weinig tot niets weet van digitale toegankelijkheid? Even terugspoelen dan voor een korte introductie!</p>
<p>Digitale toegankelijkheid gaat erom dat iedereen mee kan doen in de digitale wereld, online en offline. Het proces van digitale toegankelijkheid is van toegevoegde waarde voor iedereen, want het zorgt voor een product dat beter te begrijpen en te gebruiken is.</p>
<p>Het is echter van absolute noodzaak voor mensen met een beperking om deel te kunnen nemen aan de maatschappij. Denk daarbij aan mensen met een visuele, lichamelijke, auditieve en ook cognitieve beperkingen. Voor deze mensen is meer dan 95% van de websites niet zonder problemen te gebruiken (bron: <a href="https://webaim.org/projects/million/#wcag">Webaim</a>), en dan hebben we het nog niet over de miljoenen apps die beschikbaar zijn.</p>
<p>Om dat te verbeteren is in 1999 de eerste versie van de Web Content Accessibility Guidelines (WCAG) gepubliceerd. Inmiddels zijn we bijna bij versie 2.2 van deze richtlijnen. De WCAG is een (ironisch moeilijk te lezen) document dat toetsbare normen bevat, waar je met je website aan kunt voldoen om te zorgen dat deze voor zoveel mogelijk mensen goed te gebruiken is.</p>
<p>De WCAG zijn echter maar een meetinstrument en pas het begin van jullie reis in de wereld van digitale toegankelijkheid.</p>
<h2>Het Accessibility Maturity Model</h2>
<p>Wat is dat dan eigenlijk, een Maturity Model?</p>
<p>Een Maturity Model is een manier om je huidige kennis en vaardigheden op een bepaald onderwerp te bepalen. Je kunt het dan inschalen op een bepaald niveau en vervolgens meetbare en uitvoerbare acties daaraan koppelen om het proces naar het volgende niveau te tillen.</p>
<p>Er zijn verschillende versies van het Accessibility Maturity Model (AMM). In dit artikel kijk ik in het bijzonder naar de versie die op dit moment in ontwikkeling is door een werkgroep van het W3C. De meest actuele versie van het document is te vinden op https://www.w3.org/TR/maturity-model/</p>
<p>Met het AMM gaat digitale toegankelijkheid verder dan alleen de WCAG of andere technische standaarden. Het geeft je organisatie handvatten om jullie bedrijfsprocessen op het gebied van digitale toegankelijkheid in kaart te brengen en verbeteringen in gang te zetten. Een gestructureerde manier om te kijken naar aspecten als “wat doen we al” en “hoe effectief zijn we hierin” gecombineerd met ontdekken waar de gaten en verbeterpunten liggen. Hierdoor gaan jullie op een bestendige manier producten ontwikkelen die voor iedereen te gebruiken zijn! Je wordt er bovendien toe aangemoedigd daar continu stappen in te blijven zetten.</p>
<p>Aan de slag gaan met het AMM is dan ook iets heel anders dan het uitvoeren van een toegankelijkheidsonderzoek. Dat laatste geeft je alleen maar een kijkje in de toegankelijkheid van een bepaald product. Toegankelijkheidsonderzoeken zijn dus maar een van de puzzelstukjes binnen het AMM. Het zegt verder weinig over hoe je als team omgaat met digitale toegankelijkheid, welke middelen jullie tot je beschikking hebben en waar ruimte voor groei zit.</p>
<h2>De structuur van het Accessibility Maturity Model</h2>
<p>Het AMM van het W3C bestaat momenteel uit 7 dimensies waarin toegankelijkheid kan bijdragen. Binnen die dimensies zijn er steeds ijkpunten, normen die je rechtstreeks kunt beoordelen, waarbij voortgang gemeten kan worden en een Maturity schaal waarin per ijkpunt, over verschillende gradaties, eisen zijn vastgesteld.</p>
<h2>Dimensies</h2>
<p>binnen de huidige opzet van het AMM zijn 7 dimensies opgesteld, elk met een korte definitie in begrijpelijke taal:</p>
<ol>
<li><em>Communicatie</em> - Alles over toegankelijkheid voor interne en externe communicatie van de organisatie. Alles van interne mails tot documenten en berichten op social media.</li>
<li><em>Kennis en vaardigheden</em> - Hoe zorgt je als organisatie voor het opbouwen en onderhouden van kennis rond toegankelijkheid. Welke intern en externe bronnen worden betrokken? Hoe zorg je dat mensen de informatie weten te vinden en gebruiken.</li>
<li><em>Ondersteuning</em> - Alles rond toegankelijkheid in de ondersteuning van werknemers en klanten. Welke behoeften hebben mensen om hun werk te kunnen uitvoeren en waar lopen onze klanten tegenaan in het gebruik van onze producten?</li>
<li><em>ICT development Life Cycle</em> - De dimensie waaraan de meeste mensen het eerste denken bij digitale toegankelijkheid. Hierin valt alles van idee tot ontwerp en realisatie van een product of website.</li>
<li><em>Personeel</em> - Hoe wordt er rekening gehouden met toegankelijkheid in HR zaken als werving, onboarding etc en hoe kunnen mensen met een functiebeperking binnen de organisatie hun ervaringen inzetten voor verbeteringen.</li>
<li><em>Inkoop</em> - Welke rol speelt toegankelijkheid in het inkoopproces? Hoe worden hier al producten beoordeeld en problemen voorkomen?</li>
<li><em>Cultuur</em> - Diversiteit en Inclusie. Welke waarden en normen zijn er verwerkt in beleid om toegankelijkheid tot kernwaarde van de organisatie te maken.</li>
</ol>
<h2>IJkpunten en voortgang</h2>
<p>Binnen de eerder genoemde dimensies kun je ijkpunten vaststellen. Houdt deze ijkpunten zo specifiek mogelijk om het beoordelen makkelijker te maken, maar ook zodat je behapbare stappen kunt zetten.</p>
<p>Enkele voorbeelden van ijkpunten zijn:</p>
<ul>
<li>Styleguides hebben toegankelijkheids-aantekeningen (ICT development life cycle).</li>
<li>Er is trainingsmateriaal beschikbaar voor nieuwe collega’s (Kennis en vaardigheden).</li>
<li>Er is een toegankelijke feedback mogelijkheid voor mensen die problemen ervaren met ons product. (Ondersteuning)</li>
</ul>
<p>Je voortgang binnen het AMM houdt je bij over verschillende gradaties. Het W3C model kent er binnen de MAturity schaal standaard 4, namelijk:</p>
<ul>
<li><em>Inactief</em> - Er is nog geen bewustwording of erkenning van een behoefte op dit vlak.</li>
<li><em>Begonnen</em> - Er is een bewustzijn voor toegankelijkheid met eerste stappen, maar nog niets structureel.</li>
<li><em>Integratie</em> - Er ligt een duidelijk plan met uitvoerbare en meetbare stappen.</li>
<li><em>Optimalisatie</em> - De basis is gelegd en mensen werken actief aan constante verbetering.</li>
</ul>
<h2>Hoe ga je hier mee aan de slag?</h2>
<p>Het AMM geeft je dus een manier om meetbaar te maken hoe je organisatie presteert op gebied van toegankelijkheid. Hoewel het model nog in de ontwikkeling is, kan het zeker al toegepast worden. Je kunt er goed inzicht mee krijgen. Om het in te zetten kun je het als compleet model gebruiken of je eigen scope bepalen en de aandacht richten op een of enkele van de dimensies.</p>
<p>Als je bepaald hebt hoe breed je het model wilt gaan toepassen is het tijd om informatie te gaan verzamelen bij de betrokken mensen. Zeker in een organisatie die nog niet veel met toegankelijkheid doet kan dit al een uitdaging op zich zijn, maar ook dat zijn bevindingen die je kunt opnemen (fase ‘Inactief’) en je kunt er duidelijke acties aan koppelen.</p>
<p>Wanneer we het bijvoorbeeld toepassen op de ICT lifecycle zijn er daarbinnen alweer verschillende fases waarop je het model kunt toespitsen. In de planfase bijvoorbeeld kun je al kijken hoe er vanaf het begin rekening wordt gehouden met toegankelijkheid. Zijn er eisen opgenomen waaraan het eindproduct moet voldoen zoals voldoen aan de WCAG, en hoe wordt dat bijgehouden? Zijn er in de ontwerpfase best practices waaraan designers zich kunnen houden en worden er bij gebruikersonderzoek ook mensen met een functiebeperking betrokken? Weten ontwikkelaars in de bouwfase hoe ze toegankelijke code moeten schrijven en hebben testers de juiste vaardigheden om met ondersteunende technologieën zoals een screenreader te kunnen testen? Hoe komen hun resultaten weer in de backlog terecht en wie zorgt dat ze daar niet ondersneeuwen tussen de andere tickets?</p>
<p>Voor al die vragen zijn ijkpunten op te stellen. Er is een Excel document beschikbaar met een voorbeeld over hoe je de voortgang zou kunnen bijhouden, maar het staat je natuurlijk vrij om hier je eigen invulling aan te geven, passend bij je eigen organisatie. Aan andere versies, zoals HTML, wordt nog gewerkt. <a href="https://www.w3.org/WAI/APA/task-forces/research-questions/maturity-model/Overview.xlsx">Excelbestand Accessibility Maturity Model</a></p>
<p>Toegankelijkheid op een goede manier verankeren in je organisatie is, zoals met veel processen, niet iets waar je morgen mee klaar bent. Het is een proces van jaren. Maar stap voor stap, taak voor taak, kun je met het Accessibility Maturity Model toewerken naar een structureel toegankelijke organisatie!</p>
</content>
</entry>
<entry>
<title>Dit is hoe ik omga met het developer imposter syndroom</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/dit-is-hoe-ik-omga-met-het-developer-imposter-syndroom"/>
<updated>2022-12-21T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/dit-is-hoe-ik-omga-met-het-developer-imposter-syndroom</id>
<content xml:lang="nl" type="html"><p>Wat voor syndroom? Het imposter syndroom. Vrij vertaald naar het Nederlands het ‘bedriegers syndroom’. Ik hoor sommigen denken, wat mankeer je dan? Nou, eigenlijk niets. Zo is er is geen diagnose voor. Maar het is wel degelijk iets. Voornamelijk binnen de tech industrie is het percentage van ‘developer imposter syndroom’ erg hoog. Uit een onderzoek uit 2018 blijkt zelfs meer dan de helft van de developers, er in min of meerdere mate last van hebben.</p>
<h2>Wat is het developer imposter syndroom?</h2>
<p>Ik ben altijd geïnteresseerd geweest in psychologie, en was dan ook enorm getriggerd toen ik van het fenomeen hoorde. Het komt er in de basis op neer, dat je twijfelt aan je eigen kunnen. “Wanneer ontdekt iemand dat ik eigenlijk niets kan?”, is een veelgehoorde kreet. Vaak onterechte gedachten. Merendeels gebaseerd op vergelijkingen met andere developers. Mensen die last hebben van het imposter syndroom onderschatten eigenlijk hun eigen prestaties. In de praktijk kun je hier bijvoorbeeld last van hebben na een meetup. Waar alle developers met elkaar stonden te praten over een nieuwe techniek. Zelf kende je deze niet, en je voelde je daarna direct slecht omdat je deze techniek niet beheerst. Je ziet het als een tekortkoming. Je denkt, dat het niet beheersen van deze techniek jou een slechte developer maakt.</p>
<h2>Onderzoek uit 2018</h2>
<p>Developers van van grote techbedrijven als Amazon, Facebook en Microsoft gaven aan dat ze zich voelden als een imposter. Gemiddeld 58%. Uit het <a href="https://www.teamblind.com/blog/index.php/2018/09/05/58-percent-of-tech-workers-feel-like-impostors/">onderzoek van Blink</a>, bleek zelfs dat bij Salesforce een developer werkt, die reeds 14 jaar in een engineer rol zit. Nog steeds aangeeft bang te zijn om ontmaskert te worden. Lachwekkend? Sneu genoeg blijk ik er zelf ook last van te hebben (en ik weet ook dat het onterecht is). Het is vermoedelijk te wijten aan de aard van de technische industrie. Met zoveel nieuwe ontwikkelingen, die zich in rap tempo opvolgen, is het onmogelijk om alles (goed) te beheersen.</p>
<h2>Vacatureteksten</h2>
<p>Zo werd ik weer eens geprikkeld door rond te struinen op LinkedIn en andere websites, op zoek naar een mogelijk nieuwe front-end opdracht. Typescript, Svelte, ES6, Angular, React, Redux, Node.js, Webpack, GIT, end-to-end testing, unit testing, Agile, Scrum. En het liefst 10 jaar ervaring. Mooi is dat ik ook weet dat bepaalde technieken, frameworks of tooling niet eens zo lang bestaan. Wees bewust dat er eigenlijk rariteiten in de vacatureteksten kunnen staan van de recruiters. Mezelf tevens beseffende, dat het allemaal mijn imposter syndroom aanjaagt! Ik heb wel ervaring met React, ES6. Werk dagelijks met Git. Maar toch heb ik de laatste jaren niet dagelijks met React gewerkt. En ik schrijf eigenlijk ook maar weinig unit tests. Het geeft me een onbehagen gevoel, en zegt er een stemmetje in mijn hoofd, “zie je nou wel, je bent een slechte developer”.</p>
<h2>Oplossing voor het imposter syndroom</h2>
<p>Een oplossing voor het developers imposter syndroom? Dat werkt natuurlijk voor iedereen anders. Over het algemeen werken de volgende onderstaande punten voor mij heel goed:</p>
<ul>
<li>Focus op je eigen kwaliteiten, je mag daar trots op zijn.</li>
<li>Vergelijk jezelf niet met anderen.</li>
<li>Herinner jezelf eraan dat je niet alles kunt beheersen.</li>
<li>Accepteer dat er een collega is, die meer (of iets) weet over een bepaald onderwerp.</li>
<li>Durf zelfs hulp te vragen aan die collega.</li>
<li>Hou je eigen prestaties bij. Vier kleine successen! Schrijf ze desnoods op, of showcase ze op je eigen website.</li>
<li>Fouten maken is normaal. Het maakt je geen slechte developer. Sterker nog, je zou er nog een paar moeten maken. Dat maakt je juist een goede developer, omdat je nu weet hoe het niet moet.</li>
</ul>
<p>Durf jij te erkennen dat je ook wel eens last hebt van het developer imposter syndroom? Weet dat je niet alleen bent. Probeer eens aan bovenstaande checklist te denken. En vooral, wees trots op jezelf. Happy coding!</p>
</content>
</entry>
<entry>
<title>Intl, de ECMAScript internationalisering API</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/intl-de-ecmascript-internationalisering-api"/>
<updated>2022-12-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/intl-de-ecmascript-internationalisering-api</id>
<content xml:lang="nl" type="html"><p>Intl is de standaard ECMAScript internationalisering API en wordt al sinds 2016 door alle browsers ondersteund, maar ontwikkelaars vallen toch vaak terug op onnodige (en verouderde) JavaScript bibliotheken.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/blog-edwin.jpg" alt="Een vrouw die Intl vertegenwoordigt, kijkt verontwaardigd naar haar vriend die een vrouw die Moment Luxon vertegenwoordigt nafluit" /></p>
<h2>Aargh, tijdzones en zomertijd</h2>
<p>Ontwikkelaars klagen vaak als ze tijdzones of zomertijd moeten ondersteunen. Het tijdstip dat ze willen tonen verschilt een (of meer) uur van het tijdstip dat in de data zit. Soms lossen ze dat op door er zelf het verschil erbij op te tellen, niet wetende dat daarmee het probleem alleen groter is geworden en de tijd na de eerstvolgende zomer-wintertijdwisseling waarschijnlijk weer onjuist is.</p>
<p>Terwijl de oplossing heel eenvoudig is. Sla tijd altijd op als GMT, dus zonder tijdzone-offset en zonder zomertijd. Je kan hiervoor de Unix epoch gebruiken, dat is het aantal seconden sinds 1 januari 1970 GMT. Gebruik deze tijd ook in je API’s.</p>
<p><em>Tip: gebruik hiervoor geen 32-bits integer, want dan heb je in 2038 weer een probleem.</em></p>
<p>Vanuit deze GMT-tijd kan je met JavaScript eenvoudig de lokale tijd tonen. Het Date object heeft al heel lang functies om zowel de tijd als de datum in de gewenste locale weer te geven (<code>date.toLocaleDateString()</code>, <code>date.toLocaleString()</code> en <code>date.toLocaleTimeString()</code>). Je kan helaas niet afwijken van de standaard tijd/datum-weergave van deze functies.</p>
<p>Als je toch invloed wil hebben op hoe de tijd wordt weergegeven, dan kon je (in het verleden) zelf iets schrijven of je wenden tot JavaScriptbibliotheken. Een veel gebruikte bibliotheek, die ook overweg kan met tijdzones en zomertijd is Moment.js.</p>
<h2>Moment.js</h2>
<p>Er zijn inmiddels veel betere alternatieven voor Moment.js. Toch zie ik veel ontwikkelaars nog steeds met Moment.js werken. Het is te begrijpen dat als je een API eenmaal goed kent, je niet graag overstapt op een andere API.</p>
<p>Er zijn toch een aantal goede redenen om over te stappen, want Moment.js heeft een aantal serieuze nadelen:</p>
<ol>
<li>Moment.js is verouderd en wordt niet meer verder ontwikkeld. <em>&quot;We recognize that many existing projects may continue to use Moment, but we would like to discourage Moment from being used in new projects going forward.&quot;</em> Zoals te lezen is op de <a href="https://momentjs.com/docs/">Documentatiepagina</a>. Verdere uitleg over dit besluit staat op hun <a href="https://momentjs.com/docs/#/-project-status/">Project Status pagina</a>.</li>
<li>Moment.js bevat alle tijdzone- en zomertijdgegevens van alle landen is daardoor best groot.</li>
<li>Moment is niet geschikt voor tree shaking, dus je laadt altijd de hele bibliotheek in, ongeacht hoeveel je ervan gebruikt.</li>
<li>Moment.js is niet <em>immutable</em>. Als je een tijdstip x hebt en je wil de tijd twee uur later weten, dan verandert de waarde van x, wat je meestal niet wilt. Als je dit eenmaal weet, dan zorg je dat je eerst een kopie van x maakt, maar het blijft onhandig.</li>
<li>Een reden die ik op andere plekken niet tegenkom: door de tijdzone- en zomertijdgegevens in je JavaScript op te nemen, kunnen ze niet makkelijk worden bijgewerkt. Met een paar honderd landen kan je je voorstellen dat deze gegevens regelmatig wijzigen, maar als je je JavaScriptbibliotheken maar af en toe bijwerkt, of in het slechtste geval nooit, dan weet je dat je snel met verouderde gegevens zit.</li>
</ol>
<h2>Erdogantijd</h2>
<p>Een interessant voorbeeld is de tijdzonechaos in 2015 in Turkije. De wintertijd zou ingaan op 25 oktober, maar omdat er op 1 november verkiezingen waren, werd dit een paar weken van te voren verplaatst naar 8 november, zodat het tijdens de verkiezingen een uur langer licht zou zijn. Microsoft, Apple, Google (Android) brachten snel updates uit, maar zoals je je kunt voorstellen, werden niet alle systemen op tijd bijgewerkt. De Turken leefden twee weken lang met een deel van de klokken op de gewone tijd en een ander deel op &quot;Erdogantijd&quot;.</p>
<p>Zie ook <a href="https://codeofmatt.com/on-the-timing-of-time-zone-changes/">On the Timing of Time Zone Changes</a> van Matt Johnson-Pint voor andere voorbeelden van tijdzonechaos.</p>
<p>Door de tijdzone- en zomertijdgegevens hardcoded in JavaScript op je website te zetten maak je het probleem niet echt kleiner.</p>
<p>Je kan in plaats van Moment.js ook een modernere bibliotheek gebruiken zoals Luxon, die op Intl is gebaseerd. Maar waarom zou je dan niet gelijk Intl gebruiken?</p>
<h2>Intl</h2>
<p>Intl kan op het eerste gezicht wat ingewikkeld overkomen, maar zoals je hieronder kan zien, valt dat best mee.</p>
<p>Hier is een voorbeeld:</p>
<pre><code>// Take any date object
const date = new Date(Date.UTC(2022, 11, 25, 11, 30, 00));
// Create a DateTimeFormat
const dateTimeFormat = new Intl.DateTimeFormat('en-GB', { dateStyle: 'full', timeStyle: 'long' })
// Format the provided date
dateTimeFormat.format(date)
// returns &quot;Sunday, 25 December 2022 at 12:30:00 CET&quot;
</code></pre>
<p>De eerste parameter van <code>DateTimeFormat</code> is de <em>locale</em>. Dat is de taal waarin de datum weergegeven moet worden, niet te verwarren met de tijdzone. Gewoonlijk is dit de taal van de pagina zelf, maar wil je ingestelde taal van de gebruiker gebruiken, dan kan je als waarde <code>undefined</code> meegeven.</p>
<p>De tweede parameter bevat de opties. Bij zowel <code>dateStyle</code> als <code>timeStyle</code> zijn de volgende waarden mogelijk: <code>&quot;full&quot;</code>, <code>&quot;long&quot;</code>, <code>&quot;medium&quot;</code> en <code>&quot;short&quot;</code>.</p>
<p>Als dat niet voldoende is, kan je ook voor elke deel van de datum aangeven hoe deze moet worden weergegeven. Voor bijvoorbeeld de maand kan je <code>month</code> de volgende waarden geven:</p>
<ul>
<li><code>&quot;numeric&quot;</code> (bijvoorbeeld 3)</li>
<li><code>&quot;2-digit&quot;</code> (bijvoorbeeld 03)</li>
<li><code>&quot;long&quot;</code> (bijvoorbeeld March)</li>
<li><code>&quot;short&quot;</code> (bijvoorbeeld Mar)</li>
<li><code>&quot;narrow&quot;</code> (bijvoorbeeld M)</li>
</ul>
<p>Wil je de datum voor een bepaalde tijdzone weergeven, dan kan je de optie <code>timeZone</code> meegeven, bijvoorbeeld <code>timeZone: &quot;Asia/Tokyo&quot;</code>.</p>
<p>Vrijwel elke denkbare datumnotatie is mogelijk. Zie voor de lijst van alle mogelijke opties de pagina <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat">Intl.DateTimeFormat() constructor</a>.</p>
<p><code>format()</code> geeft altijd een string terug, maar wat als je de seconden in een kleiner font wil weergeven? Of AM/PM in een andere kleur? Ook dat is mogelijk. In plaats van <code>format(date)</code> roep je dan <code>formatToParts(date)</code> aan en je krijgt een array terug van alle datumonderdelen en hun waardes. Je kan dan zelf bepalen hoe je elk van deze waarden weergeeft.</p>
<pre><code>dateTimeFormat.formatToParts(date);
// returns
[
{ type: &quot;weekday&quot;, value: &quot;Sunday&quot; },
{ type: &quot;literal&quot;, value: &quot;, &quot; },
{ type: &quot;day&quot;, value: &quot;25&quot; },
{ type: &quot;literal&quot;, value: &quot; &quot; },
{ type: &quot;month&quot;, value: &quot;December&quot; },
{ type: &quot;literal&quot;, value: &quot; &quot; },
{ type: &quot;year&quot;, value: &quot;2022&quot; },
{ type: &quot;literal&quot;, value: &quot; at &quot; },
{ type: &quot;hour&quot;, value: &quot;12&quot; },
{ type: &quot;literal&quot;, value: &quot;:&quot; },
{ type: &quot;minute&quot;, value: &quot;30&quot; },
{ type: &quot;literal&quot;, value: &quot;:&quot; },
{ type: &quot;second&quot;, value: &quot;00&quot; },
{ type: &quot;literal&quot;, value: &quot; &quot; },
{ type: &quot;timeZoneName&quot;, value: &quot;CET&quot; }
]
</code></pre>
<p>Naast <code>DateTimeFormat</code> bevat Intl nog een reeks mogelijkheden die nuttig zijn bij internationalisatie.</p>
<h2>RelativeTimeFormat</h2>
<p>Relatieve tijd, zoals je vaak ziet op fora en chatkanalen.</p>
<pre><code>// Create a RelativeTimeFormat
const rtf = new Intl.RelativeTimeFormat('nl-NL');
rtf.format(-2, 'minute')
// returns &quot;2 minuten geleden&quot;
</code></pre>
<h2>ListFormat</h2>
<p>Het weergeven van lijsten in de gewenste taal.</p>
<pre><code>// Create a ListFormat
const listFormat = new Intl.ListFormat('nl-NL', { style: 'long', type: 'conjunction' });
listFormat.format([&quot;bananen&quot;, &quot;appels&quot;, &quot;mandarijnen&quot;])
// returns &quot;bananen, appels en mandarijnen&quot;
</code></pre>
<p>Daarnaast kan je met Intl ook taalafhankelijk getallen juist weergeven, meervoudsregels toepassen, alfabetisch sorteren en tekst opdelen in (onder andere) woorden.</p>
<p>Wil je aan de slag met de Intl API en alle mogelijkheden bekijken, dan kan je zoals altijd terecht bij de goede <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl">documentatie op MDN</a>.</p>
<p>Maar wil je de Intl API interactief ontdekken, dan kan je <a href="https://www.intl-explorer.com/?locale=nl-NL">Intl Explorer</a> van Jesper Orb uitproberen.</p>
<p>En mocht je denken &quot;heel leuk die Intl API, maar de Date API mag ook wel wat beter&quot;, dan heb ik goed nieuws: momenteel wordt gewerkt aan de <a href="https://tc39.es/proposal-temporal/docs/">Temporal API</a> die de oude Date API zal vervangen.</p>
</content>
</entry>
<entry>
<title>Fronteers Boekenclub 4 - The IT Girl</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/fronteers-boekenclub-4-the-it-girl"/>
<updated>2022-12-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/fronteers-boekenclub-4-the-it-girl</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 13 december bespraken we bij de vierde Fronteers Boekenclub het boek &quot;<a href="https://chantalschinkels.nl/de-it-girl/">The IT Girl</a>&quot; van Chantal Schinkels.</p>
<p><img src="https://www.fronteers.nl/_img/fbc4-de-it-girl-chantal-schinkels-200w.png" alt="" /></p>
<p>De ondertitel van dit boek is ‘Hoe overleef je een door mannen gedomineerde werkvloer?’ Deze editie werd in ieder geval niet gedomineerd door mannen. We bespraken het boek met 7 vrouwen en 1 man (*). Na het eerste uur schoof Chantal zelf ook nog aan, voor vragen.</p>
<h2>Over het boek</h2>
<p>Het boek kwam uit in augustus 2021. De titel is een woordspeling: aan de ene kant een meisje met een baan in de IT en anderzijds een ‘<a href="https://en.wikipedia.org/wiki/It_girl">it girl</a>’, a la Paris Hilton. Het bestaat uit 3 delen: ‘Voordat je het ziet’, ‘De ladder op’, ‘Breek het systeem’.</p>
<p>We vroegen Chantal wie ze als doelgroep ziet voor het boek. “Iedereen, uiteraard. Mijn belangrijkste doelgroep is vooral vrouwen die aan het begin van hun carrière staan. Maar gaandeweg het schrijven van het boek kwam ik erachter dat het geen vrouwenprobleem, maar een leiderschapsprobleem.”</p>
<p>Schinkels geeft een aantal tips. Bijvoorbeeld: probeer zichtbaar te zijn; vorm een ‘wolf pack’; vind een mentor, vind een sponsor. En om mannen te overtuigen: “Noem hun dochter. Werk op hun gevoel, hun papa-zijn. Ze weten niet hoe het voelt. Het is ook voor een gedeelte gebaseerd op angst. Bang dat ‘we’ iets afpakken. Maar het is geen zero sum game. Het is niet zo dat mannen iets verliezen als vrouwen beter betaald worden.”
Ze noemt ook een aantal typetjes, zoals ‘de jatgast’, ‘ondermijn-heer’ en ‘aanrechtprofeet’.</p>
<h2>Zelfs voor mannen</h2>
<p>Iedereen zou dit boek moeten lezen, zelfs mannen. Hoofdstuk 10 richt het woord speciaal tot hen. Ook voor hen is dit boek geschikt, want dit is geen boos boek. “If you’ve never been exposed to these kinds of problems, you don’t see them. That is why some men do not see the problem. And that is why we must include them in this.”</p>
<p>Zoals Schinkels zei: “Bij de mannen ligt de sleutel. Je hebt maar 1 man nodig om cultuurverandering te starten. Denk aan het bystander effect. Als niemand ingrijpt, doe jij het ook niet. Maar een man kan tijdens vergaderingen net iets makkelijker zeggen: ‘Zo doen we dit hier niet’.”</p>
<h2>Bedreigend</h2>
<p>Er zijn denk ik (*) 2 soorten mensen: mensen die denken dat ‘feminist’ een scheldwoord is en mensen die wel vinden alle mensen gelijke kansen en gelijke rechten horen te hebben. Ik viel van m’n stoeltje van verbazing toen Chantal vertelde dat ze was uitgenodigd om te spreken op een congres maar wel als het praatje ‘niet te feministisch’ was. “Mannen lopen weg als je te veel schreeuwt. Ik maak dat nog steeds mee. Ik wil niet de boze vrouw zijn.” Anno 2022! Het moet wel gezellig blijven, he?</p>
<h2>Schijn bedriegt</h2>
<p>Nederland lijkt soms vooruitstrevend, maar op het gebied van gelijke behandeling laten de cijfers iets anders zien. De verhouding zijn aartsconservatief en droefmakend. Van alle personen die in 2018 in een technisch beroep werkten, was maar 13% vrouw. In de ICT is dit 14,3%. Inmiddels ligt het percentage vrouwen die voor een bèta-opleiding kiezen in het hoger onderwijs op een gemiddelde van 18%: aan de universiteit gaat het om 27% en in het hbo om 12% van de studenten.</p>
<p>Waarom is dat een probleem? Hoe meer mensen in de IT zouden werken, hoe beter. En ook: hoe diverser, hoe beter. Voor werkgevers, want vacatures worden beter vervuld. Voor werknemers, want daarmee wordt hun werkplek eerlijker en minder eenzijdig. En voor het uiteindelijke resultaat. Denk aan <a href="https://www.boredpanda.com/google-translate-sexist/">seksistische vertalingen</a>, <a href="https://www.digitaltrends.com/mobile/smartphone-size-design-for-woman-hand/">telefoons die voor mannenhanden gemaakt zijn</a>, apps die vergeten dat <a href="https://www.vice.com/en/article/qvp5yd/the-strange-sexism-of-period-apps">sommige lijven anders werken</a>.</p>
<h2>Wat we ervan vonden</h2>
<p><em>Rosita: 4 sterren</em>. Ik vond het een mooi en nuttig boek. Niet alles is even herkenbaar voor me. Ik werk nog niet zo heel lang in de IT; werk is voor mij wel heel belangrijk. Het heeft mij heel veel gebracht, inkomen, levensvreugde. Bij de types mannen dacht ik wel: ‘Is dat echt zo?’. Ik vond het een eye opener.</p>
<p><em>Jacqueline: 3,5 sterren</em>. Ik vond het heel herkenbaar, bijna te herkenbaar. Het is echt confronterend om een Wall of Guys te ervaren. Lastig in het boek vond ik dat ze handvatten geeft die te theoretisch zijn. En ik vind het lastig om ‘vooraan’ te gaan staan. Ik weet niet of ik dat wil. Ik herkende wel alle mannentypes. Heel veel mannelijke developers denken: “Ik denk niet zo, dus het probleem bestaat niet”.</p>
<p><em>Marrije: 4 sterren</em>. Een goed boek. Ik vond het echt shockerend om de cijfers weer te zien. Goed dat Chantal de nadruk legt op de noodzaak voor systeemverandering. Want daar zit denk ik het grootste probleem, niet in mannen zelf. Maar die typetjes en dat pestgedrag, bah, veel te herkenbaar. Ik vind: “Zet jezelf gerust in het middenpunt, vergeet de mannen”.</p>
<p><em>Annemiek: 5 sterren</em>. Een erg interessant boek. ‘t Was een goede voorbereiding op mijn nieuwe loopbaan als vrouwelijke developer. Ik heb er ook zeker tips uit meegenomen voor het kiezen van een fijne werkgever. Fijn ook dat het vooral op interpretatie van onderzoek was gebaseerd en niet alleen een mening.</p>
<p>Werd ook wel een klein beetje huiverig door de keerzijde die veel besproken wordt. Gelukkig viel die in de praktijk wel mee, maar wellicht dat dit ook komt doordat ik dus een werkgever heb gekozen waar erg veel focus is op inclusie en diversiteit. Ik had er wel veel herkenning in met de typetjes, ondanks dat ze misschien wat stereotiep zijn</p>
<p><em>Sanne: 4 sterren</em>. Goed onderbouwd boek, met veel voetnoten. Ik vond de schrijfstijl lastig en ongestructureerd. Maar inhoudelijk heel goed. En ook herkenbaar, helaas, dat bestiarium van mannen.</p>
<p>Het gaat niet direct, het gaat heel subtiel. Mannen pikken een idee en pronken ermee.
Ik ben wel de enige vrouw in een team van 8. Het wordt wel tijd dat er wat representatiever wordt.</p>
<p><em>Monique: 3 sterren</em>. Mijn referentiepunt is: “Moet iedereen dit lezen?” En dan denk ik: nee, ik ken boeken dit het punt over emanicpatie beter maken. ‘t Maakt uit op welk punt je in je carrière staat. Ik ben 50+ en ik heb alles wel gezien en gehoord. Mijn manier was om ‘one of the guys’ te worden. Als ik vroeger me had opgesteld zoals dit boek adviseert had ik het niet overleefd. Wat Jacqueline zegt: niet iedereen wil strijden. Ik herken wel dat er heel veel werk aan de winkel is.</p>
<p><em>Nina: 5 sterren</em>. Een belangrijk boek, want hiermee kunnen we een start maken voor de dialoog. Rijk aan informatie en goede concrete adviezen. Ik ben al wat langer geïnteresseerd in inclusie in bredere vorm. Ik vond de typetjes’ en de generalisaties over mannen onprettig. Die typetjes zie ik bij zowel mannen als vrouwen. Ik twijfel of dit de manier is om mannen mee te krijgen.</p>
<p><em>Paul: 3,5 sterren</em>. Qua onderwerp is dit een nuttig boek, omdat het een impliciet probleem expliciet maakt. Nederland lijkt een progressief, feministisch land, maar de verhoudingen op de werkvloer vertellen een ander verhaal. Qua schrijfstijl vind ik het niet een geweldig boek. Het 'manifest' was niet puntig en zet niet aan tot bekeringsdrang. Ik vond het een grappig dat er 1 hoofdstuk 'voor de mannen' was.</p>
<h2>Tips om meer hierover te lezen, luisteren, kijken</h2>
<ul>
<li><a href="https://leanin.org/book">‘Lean In’ door Shery Sandberg</a>: praktische tips en ervaringen.</li>
<li><a href="https://www.walburgpers.nl/nl/book/9789463725170/werk-is-geen-oplossing">Werk is geen oplossing door Marguerite van den Berg</a>: “Werk zou ons emanciperen en onafhankelijk maken. Zo draaien ook gesprekken over feminisme steeds om hetzelfde saaie en uitgeputte idee dat alle vrouwen de arbeidsmarkt op moeten. En dat terwijl niet werken voor veel vrouwen allang geen optie meer is”</li>
<li><a href="https://www.debezigebij.nl/boek/waarom-vrouwen-minder-werken-dan-mannen/">Waarom vrouwen minder werken dan mannen door Liesbeth Staats</a>: “Hoe komt het toch dat deze patronen in Nederland zo hardnekkig zijn en zich zo moeilijk laten uitroeien? En wat zijn de gemiste kansen voor vrouwen én mannen, zolang we ons niet los worstelen van deze ingesleten gewoontes?</li>
<li><a href="https://carolinecriadoperez.com/book/invisible-women/">Invisible women door Caroline Criado Perez</a>: wat zijn de gevolgen als je niet ook denkt aan vrouwen als je een product ontwerpt, of medicijnen ontwikkelt?</li>
<li><a href="https://www.guernicamag.com/rebecca-solnit-men-explain-things-to-me/">Rebecca Solnit, de uitvinder van ‘mansplaining’</a></li>
<li>Podcast: <a href="https://podcastluisteren.nl/pod/Sophie-and-Coco-naar-het-einde-van-de-loonkloof">Sophie &amp; Coco: naar het einde van de loonkloof</a></li>
</ul>
<h2>FBC5: dinsdag 28 februari</h2>
<p><img src="https://www.fronteers.nl/_img/fbc5-the-programmers-brain-felienne-hermans-200w.png" alt="" /></p>
<p>Voor de volgende keer nodigen we iedereen uit. Ook mannen, en zelfs vrouwen.
<a href="https://www.meetup.com/fronteers-nl/events/290317895/">Meld je aan via meetup.com</a>.</p>
<p>Het was nog spannend welk boek we kozen voor de vijfde editie. Dan lezen we “<a href="https://www.manning.com/books/the-programmers-brain">The programmer's brain</a>” door Felienne Hermans. Een andere kanshebber was ‘Weapons of math destruction’ door Cathy O'Neil.</p>
<p>(*) dit stukje is geschreven door die man, Paul van Buuren.</p>
</content>
</entry>
<entry>
<title>Design Tokens gebruiken voor de Theming van een website</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/design-tokens-gebruiken-voor-de-theming-van-een-website"/>
<updated>2022-12-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/design-tokens-gebruiken-voor-de-theming-van-een-website</id>
<content xml:lang="nl" type="html"><p>De kans is groot dat je hier terecht kwam omdat je op zoek was naar een effeciente manier om theming toe te passen in een website. Om te beginnen is het belangrijk om duidelijk te krijgen wat er precies met Theming en Design Tokens bedoeld wordt.</p>
<h2>Wat is Theming?</h2>
<p>Theming is een techniek binnen software development waarbij je op basis van een voorgedefineerd kleurenschema de vormgeving van die website aan past.</p>
<p>In de praktijk kom je theming vaker tegen in UI libraries, zoals <a href="https://chakra-ui.com/">Chakra UI</a>, <a href="https://getbootstrap.com/">Bootstrap</a> en <a href="https://tailwindcss.com/">TailwindCSS</a>. Op die manier kan je de uiteindelijke vormgeving van de UI componenten aanpassen, maar helaas zitten daar dan ook weer grenzen aan.</p>
<p>Wat vaker het geval is dat je zaken zoals de primaire, secundaire kleuren kan aangeven en daarnaast lettertypes voor kopjes en normale tekst. De daadwerkelijk opties verschillen natuurlijk per UI library, maar het is vaker lastig te controleren waar hoe die kleuren en lettertypes toegepast worden.</p>
<h2>Wat zijn Design Tokens?</h2>
<p>Design Tokens is een werkwijze die vaak als onderdeel van Design Systems gebruikt wordt. Een Design System is methode waarmee de vormgeving van een merk (brand in het Engels) op een systematische manier toegepast kan worden op al haar uitingen. Denk hier bij aan websites en apps. Wat het Design System in feite doet is alle ideeën en logica van het ontwerp vast leggen in richtlijnen en code. Op die manier kan het werk en de moeite die gedaan is het ontwerp beter gewaarborgd worden, omdat het Design System dan als een automatische autoriteit geldt als het aankomt op ontwerp.</p>
<p>In zo’n systeem is het essentieel dat zaken zoals typografie (lettertypes e.d.), kleurgebruik en maatvoering (marges, paddings en groottes) gemakkelijk, op 1 plaats, beheerd en gedefinieerd kunnen worden.</p>
<p>Dit is precies wat Design Tokens doen. Het zijn als het ware globale variabelen (binnen het systeem) waarin al deze zaken als waarden opgeslagen zijn. Een bijkomende kracht van deze tokens is dan direct ook dat een waarde een betekenis meekrijgt. Neem als voorbeeld deze css code voor het stylen van een link:</p>
<pre><code>/*
De link heeft voor de tekst een rood-paarse kleur en voor de lijn
onder de tekst een ietwat andere rood-paarse kleur. De gedachte
achter de kleurwaarden is echter niet duidelijk.
Als in, waar zijn deze kleuren op gebaseerd?
*/
a[href] {
display: inline-block;
color: #ff4400;
border-bottom: 2px solid #ffdd12;
}
/*
Door de kleurwaarden te definiëren als tokens (effectief hier als
css-variabelen) koppel je de kleurwaarde aan een betekenis.
Op die manier wordt het duidelijker wat het idee achter de
vormgeving van de link is. Met andere woorden, door het gebruiken
van tokens documenteer je impliciet de betekenis van de tekstkleur
en de onderlijningskleur van deze link.
*/
:root {
--PerenComputer-colour-brand-main-text: #ff4400;
--PerenComputer-colour-brand-main-lines: #ffdd12;
}
a[href] {
display: inline-block;
color: var(--PerenComputer-colour-brand-main-text);
border-bottom: 2px solid var(--PerenComputer-colour-brand-main-lines);
}
</code></pre>
<h2>Design Tokens voor Theming</h2>
<p>Er zit een overlap tussen hoe standaard Theming gedaan wordt (zoals in UI libraries) en hoe Design Tokens gebruikt worden. Beiden gebruiken in de basis een configuratie (bestand of data-object), waarin alle waarden gekoppeld zijn aan definities (variabelen of properties).</p>
<p>Hier is een voorbeeld om het verschil tussen Theming zonder design en met design tokens uit te leggen:</p>
<pre><code>/*
Dit is een voorbeeld van hoe theming werkt voor de UI library Chakra UI.
In dit voorbeeld pas je het bestaande standaard thema aan door de kleur
tokens voor success, error, primary en secondary aan te passen.
**/
import { extendTheme } from '@chakra-ui/react'
/*
red.[nummer] refereert naar een voorgedefineerd kleurenschema van
Chakra UI: &lt;https://chakra-ui.com/docs/styled-system/theme&gt;
*/
const theme = extendTheme({
semanticTokens: {
colors: {
error: 'red.500',
success: 'green.500',
primary: 'red.500',
secondary: 'yellow.800',
},
},
})
</code></pre>
<p>In het bovenstaande voorbeeld van Chakra UI pas je het standaard kleuren schema aan naar je eigen wensen. Echter ontstaat er hier een subtiel probleem met betrekking tot schaalbaarheid. De namen error en success geven enkel dat de kleuren op een bepaalde manier gebruikt worden voor communicatie van de success en error staat van iets, maar niet hoe en op wat voor manier. En dan hebben we het nog niet eens over de kleur definities primary en secondary. Deze twee vertellen je nog minder over hoe, waar en wanneer ze wel en niet gebruikt worden.</p>
<p>Op een kleine schaal zal dit niet voor grote problemen zorgen en is deze manier van werken daarom ook vaker ok, maar zodra de complexiteit omhoog gaat (meer code, meer componenten, grotere codebase), wordt het steeds lastiger om kleuren correct toe te passen, omdat het ook onduidelijk hoe kleuren precies gebruikt moeten worden. M.a.w. zorgen dat het kleurgebruik klopt met de originele intenties van het ontwerp.</p>
<h2>Design Tokens gebruiken binnen Theming</h2>
<p>Een methode om hier beter mee om te gaan is door Design Tokens te gaan gebruiken. Omdat Design Tokens juist bedoeld zijn om het gebruik van waarden (zoals kleur) te documenteren krijg je automatisch een meer gestructureerde manier van werken. Neem als voorbeeld hieronder waar het eerdere voorbeeld aangepast is om meer te werken volgens de filosofie van design tokens:</p>
<pre><code>import { extendTheme } from '@chakra-ui/react'
/*
Dit is een aangepaste versie van het eerdere voorbeeld
Dit gebruikt nog steeds het kleurenschema van Chakra UI, maar de
naamgevingen van de properties zijn daarentegen gebasseerd op de
functie van de tokens. M.a.w. hoe de waarde gebruikt moet worden.
Let op: niet iedere UI library ondersteunt het defiëneren van
eigen tokens.
Chakra UI ondersteunt dit wel, maar je moet dan nog wel handmatig
deze tokens toepassen op de respectievelijke componenten.
*/
const theme = extendTheme({
semanticTokens: {
colors: {
error: {
border: 'red.500',
},
success: {
border: 'green.500',
},
ctaButton: {
background: 'red.500',
},
button: {
background: 'yellow.800'
},
text: {
onLightBackground: 'gray.900', // heel donker grijs
onDarkBackground: 'white'
},
},
},
})
</code></pre>
<p>Als je Design Tokens voor Theming wilt gaan gebruiken dan is de eerste stap de beste manier vinden voor het definiëren van de token-namen. Een goede basis richtlijn hier is om de naamgeving van de tokens te baseren op waar ze voor gebruikt worden. Een vraag die je jezelf dan kan stellen is bijvoorbeeld hoe wordt <code>red.500</code> gebruikt? En waarom? De antwoorden (op basis van ons voorbeeld) zijn dan:</p>
<ul>
<li>
<ul>
<li>Als rand (border) kleur bij error meldingen</li>
</ul>
</li>
<li>
<ul>
<li>Als achtergrondkleur bij Call-to-action knoppen</li>
</ul>
</li>
</ul>
<p>Met deze basis van naamgeving op basis van functie, kan je vervolgens o.b.v. kleurenpalet (bijvoorbeeld gebaseerd op een ander merk), dezelfde tokens andere waarden geven:</p>
<pre><code>import { extendTheme } from '@chakra-ui/react'
/* Pear computer's merk kleuren zijn 'red.500'(primair)
en 'yellow.800'(secundair). */
const PearComputersDesignTokens = {
colors: {
error: {
border: 'red.500', // is de primaire kleur
},
success: {
border: 'green.500',
},
ctaButton: {
background: 'red.500', // is de primaire kleur
},
button: {
background: 'yellow.800',
},
text: {
onLightBackground: 'gray.900', // heel donker grijs
onDarkBackground: 'white'
},
},
}
/* gebruikt oranje (primair en teal (mint-groen, secundair) en
blauw (tertiair), maar pas die anders toe dan Pear Computers.
Let op de achtergrondkleur van de ctaButton. */
const OrangeComputersDesignTokens = {
colors: {
error: {
border: 'orange.700', // is de primaire kleur
},
success: {
border: 'teal.500',
},
ctaButton: {
background: 'teal.500', // is NIET de primaire kleur
},
button: {
background: 'blue.800',
},
text: {
onLightBackground: 'gray.900', // heel donker grijs
onDarkBackground: 'white'
},
},
}
const theme = extendTheme({
semanticTokens: OrangeComputersDesignTokens,
})
</code></pre>
<h2>Conclusie</h2>
<p>Je zou kunnen zeggen op basis van de voorbeelden dat Design Tokens in deze context hetzelfde zijn als Theming, maar dat is niet helemaal waar. Ze gedragen zich enkel alleen maar zo. De kracht van het gebruiken van Design Tokens, voor het Themen van een applicatie of website, ligt in de methode van werken. Deze werkwijze dwingt, als het ware, om goed na te denken over de structuur en naamgeving van 1 van de meest basale onderdelen van een website.</p>
<p>Dit betekend natuurlijk niet dat Design Tokens daarmee altijd de beste oplossing zijn voor Theming. De werkwijze van Design Tokens is namelijk met zo een hoge mate gestructureerd dat het ook meer tijd kost om te implementeren. Dus het loont altijd om eerst te evalueren of er genoeg tijd beschikbaar is om deze werkwijze te hanteren. Zo nee, is een simpelere oplossing misschien beter.</p>
<p>Uiteindelijk is het in ieder project de kunst om de juiste balans tussen elegantie (goede architectuur e.d.) en pragmatisme (<em>OK</em> is soms ook <em>goed</em> genoeg) te vinden.</p>
</content>
</entry>
<entry>
<title>De Balans Tussen DRY en KISS</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/de-balans-tussen-dry-en-kiss"/>
<updated>2022-12-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/de-balans-tussen-dry-en-kiss</id>
<content xml:lang="nl" type="html"><p>Als professionele (front-end) developer is de kans groot dat je in een team werkt en dat je rekening moet houden met het feit dat andere developers met jouw code zullen moeten werken. Het is dan van belang dat je nette code schrijft. Allereerst zodat andere developers je code begrijpen, maar—laten we wel wezen—ook omdat je niet wilt dat andere developers denken dat je er niets van bakt. De makkelijkste manier om nette code te schrijven is door je te houden aan development principes.</p>
<h2>Don’t Repeat Yourself</h2>
<p>Eén van de beter bekende development principes is Don't Repeat Yourself, of DRY afgekort. Dit principe gaat vooral over slim programmeren. Het vinden van delen in je code die je kunt abstraheren. Krijg je het idee dat je telkens dezelfde functie schrijft om bijvoorbeeld een input te valideren, dan is het <em>slim</em> om één functie te schrijven waar je elke waarde van de input door kunt halen om te valideren. Je houdt je code kort en je bespaart jezelf tijd omdat je jezelf niet hoeft te herhalen. Het is ook makkelijker om je code te beheren en het bespaart je tijd en moeite mochten er ooit veranderingen nodig zijn.</p>
<p>Een goed voorbeeld van Don’t Repeat Yourself is de Factory Design Pattern in JavaScript. Een fancy naam, maar eigenlijk is het minder complex dan het lijkt.</p>
<p>Laten we naar een klein voorbeeld kijken van de Factory Design Pattern.</p>
<p>Stel dat we de volgende code hebben:</p>
<pre><code>const Kerstboom1 = {
type: 'Nordmann',
hoogte: 185,
aantalBallen: 75,
lichtAan() { console.log( '🎄' ) },
lichtUit() { console.log( '🌲' ) }
}
</code></pre>
<pre><code>const Kerstboom2 = {
type: 'Douglasspar',
hoogte: 500,
aantalBallen: 350,
lichtAan() { console.log( '🎄' ) },
lichtUit() { console.log( '🌲' ) }
}
</code></pre>
<p>We maken hier twee keer een kerstboom object aan. De twee functies om de lichtjes aan en uit te doen zijn echter een beetje dubbelop. Ze zijn in beide kerstbomen precies hetzelfde. Dit is waar een Factory van pas komt.</p>
<pre><code>function kerstboomFactory( type, hoogte, aantalBallen ) {
return {
type,
hoogte,
aantalBallen,
lichtAan() {
console.log( '🎄' );
},
lichtUit() {
console.log( '🌲' );
}
}
}
const Kerstboom1 = kerstboomFactory( 'Nordmann', 185, 75 );
const Kerstboom2 = kerstboomFactory( 'Douglasspar', 500, 350 );
</code></pre>
<p>De Factory is een functie die het creëren van de kerstboom centraliseert. Daarmee houden we onze code DRY. De herhalende delen–de functies–worden gedefinieerd in de functie en de variabele onderdelen zoals de type, hoogte en aantal ballen kunnen mee worden gegeven aan de functie als argumenten. Deze Factory is een minder complex voorbeeld. Je kunt ook wat complexer gaan, zoals het gebruiken van een <code>Class</code>, maar dat is niet van belang voor dit artikel.</p>
<p>Er zijn een boel andere design patterns voor JavaScript die helpen om je code DRY te houden. Ik kan je aanbevelen om eens te kijken op <a href="http://patterns.dev/">patterns.dev</a> waar <a href="https://www.lydiahallie.io/">Lydia Hallie</a> en <a href="https://addyosmani.com/">Addy Osmani</a> een geweldige resource over dit onderwerp hebben opgericht.</p>
<h2>Keep It Simple Stupid</h2>
<p>Dit vind ik het development principe met de leukste naam: Keep It Simple Stupid, of KISS. Eigenlijk is het een <em>design</em> principe gericht op gebruiksgemak voor de eindgebruiker. Maar het is ook prima toepasbaar op software development en een code base.</p>
<p>De term zou zijn bedacht in de Amerikaanse marine waar ze met vliegtuigmotoren werkten. De hoofdingenieur zou gezegd hebben dat de motoren zo simpel moesten zijn dat in gevechtssituaties iemand met basic training en met simpel gereedschap de motoren moeten kunnen onderhouden.</p>
<p>Ik wil diezelfde analogie op programmeren in teamverband toepassen. De code zou zo simpel en begrijpbaar moeten zijn dat een junior developer, iemand met weinig ervaring, de code kan onderhouden en er hun weg doorheen kan vinden.</p>
<p>De beste manier om je code simpel te houden is om duidelijke afspraken te maken. Afspraken over hoe je je code schrijft:</p>
<ul>
<li>Dat variabelen bovenaan een bestand worden gedeclareerd.</li>
<li>Wat voor uitlijning en witruimte er word gebruikt.</li>
<li>Welke naming conventions er worden gebruikt.</li>
</ul>
<p>Als elke developer in je team zich daar aan houdt krijg je consistente code die makkelijk te lezen hoort te zijn.</p>
<p>Commentaar schrijven word ook vaak genoemd als manier om een code base toegankelijk te maken voor developers die er nog niet bekend mee zijn. Hoewel dat klopt ben ik persoonlijk van mening dat als je simpele code schrijft met duidelijke benamingen van je variabelen en functies, commentaar in veel gevallen niet nodig is. In programmeren noemen we dat zelf documenterende code (<a href="https://en.wikipedia.org/wiki/Self-documenting_code">self-documenting code</a>). Maar soms kun je er niet omheen en dan is commentaar bij de code heel behulpzaam voor andere developers.</p>
<h2>De Balans</h2>
<p>Over het algemeen is het volgen van development principes een goed iets. De afgelopen jaren ben ik echter al een paar keer een developer tegengekomen die daar in door kon schieten waardoor het juist een averechts effect had. Twee verschillende gevallen om precies te zijn. In beide gevallen ging het om developers die erg bekend zijn met de Design Patterns die ik eerder hierboven ook noemde. Hele technische developers die ervaring hebben met delen van Front-end Development die voorheen meer met back-end werden geassocieerd totdat JavaScript frameworks dit mee naar de front-end brachten.</p>
<p>Er waren gevallen waarbij deze twee developers oplossingen bedachten waar ze–in mijn mening–iets te veel waar doorgeschoten in het toepassen van bepaalde design patterns waardoor de code juist complexer werd dan had gehoeven. Functionaliteit werd geabstraheerd waardoor code over meerdere bestanden werd verdeeld. Er werd grot geschut ingezet voor een simpele kleine klus. De oplossingen zouden misschien passen bij grote features maar waren ongeschikt bij de kleine features waar ze nu werden toegepast.</p>
<p>Het gevolg was dat een andere developer enige tijd later aan hetzelfde stuk code moest werken en veel tijd kwijt was om alles te vinden in de code en om alles te begrijpen. Junior developers en developers zoals ik–die aan de front-front-end kant zitten met meer kennis van HTML en CSS dan van technische design patterns in JavaScript–zouden hier de nadelige gevolgen van merken. In deze gevallen was ik het ook persoonlijk die moeite had om een ogenschijnlijk simpele bug op te lossen ook al kun je mij niet echt meer een junior developer noemen.</p>
<p>Daarbij kunnen we terug komen op de analogie over vliegtuigmotoren en wat de Amerikaans ingenieur daar over zei. Hoe de vliegtuigmotoren zo simpel moeten zijn dat monteurs met basiskennis de motoren moeten kunnen repareren. De twee developers hadden de motor veel te complex gebouwd waardoor developers met basiskennis of zonder specialistische tools (kennis van JavaScript Design Patterns) het niet of moeilijk kunnen onderhouden.</p>
<p>De onbalans hoeft niet perse te komen door te veel complexiteit. Je kunt je code ook zó simpel opzetten dat het veel tijd kost om het te onderhouden. Een extreem voorbeeld is misschien een statische website die volledig uit losse HTML pagina’s bestaat waarbij op elke pagina dezelfde header met navigatie voorkomt. Eén wijziging moet je dan op alle pagina’s toepassen.</p>
<p>Ik vind dat er een balans moet worden gezocht tussen DRY en KISS. Tussen simpliciteit en complexiteit. Zeker als het gaat over een code base waar meerdere developers aan moeten werken. DRY code is goed totdat het te complex wordt voor (junior) developers om goed te begrijpen. KISS code is goed totdat het te simplistisch wordt en developers te veel tijd kwijt zijn met het onderhouden van de code.</p>
<p>Denk aan je mede-developer.</p>
</content>
</entry>
<entry>
<title>Hoe de pandemie mijn werk en woning veranderde</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/hoe-de-pandemie-mijn-werk-en-woning-veranderde"/>
<updated>2022-12-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/hoe-de-pandemie-mijn-werk-en-woning-veranderde</id>
<content xml:lang="nl" type="html"><p>Maart 2020 was de maand dat de wereld (weer) voorgoed veranderde. Dit is de tweede keer voor mij en velen van ons dat het wereld voorgoed veranderde. Eerst op 11 september 2001 en nu in maart 2020. Hoewel er gesproken wordt over weer naar “normaal” gaan, is het “normaal” van voor maart 2020 is voorgoed weg. Onze manier van werken is voor velen veranderd: de pandemie liet zien dat voor vele vakgebieden thuiswerken mogelijk is, en dat mensen die thuis willen werken dat moeten kunnen, terwijl degenen die liever op kantoor werken dat ook kunnen blijven doen.</p>
<p>Als iemand die immuungecompromitteerd is betekende de eerste twee maanden van de pandemie in compleet isolatie zitten. Ik ging alleen in de nachturen als de kans om iemand tegen te komen klein is, naar buiten om lucht te scheppen. Vrienden en familie brachten boodschappen voor me aan deur. Tot vandaag betekend het dat ik bij hoge infectiecijfers zo min mogelijk op kantoor wil zijn.</p>
<p>Ik ben ook laatdoof en de lockdown bleek een goede uitkomst te zijn voor de toegankelijkheid in communicatie.</p>
<p>Ik werk als front-end developer op een hogeschool bij de nieuws en magazine redactie. Ik werkte 4 dagen per week, altijd op kantoor, maar heel soms thuis. Op kantoor hadden we allemaal een Windows desktop en ik heb ook een MacBook.</p>
<p>Dankzij de MacBook en cloud opslag kon ik makkelijk omschakelen naar voltijd thuiswerken. Het was alle hens aan dek bij de IT-afdeling om honderden laptops te regelen voor alle werknemers die van de ene dag op de andere moesten thuiswerken.</p>
<p>Als doof persoon die altijd een schrijftolk nodig heeft voor vergaderingen, presentaties en belangrijke gesprekken bleek thuiswerken het beste wat er is qua communicatie. Nu moest iedereen wel alles via e-mail, tekstberichten en Teams communiceren. Voorheen was bijna alles mondeling op kantoor. Tolken op afstand was iets wat ik nooit gebruikt had. Het werkt heel simpel: mijn schrijftolk doet ook op de achtergrond mee met Teams vergaderingen. Alles wat gezegd word wordt naar mij gestreamd via een apart link.</p>
<p>De eerste weken en maanden waren er veel haperingen en frustratie. Zelfs de beste internetverbinding viel soms weg midden in een vergadering of de tekst van de tolk liep vast. Ik begon last te krijgen van mijn pols en armen vanwege elke dag uren achter mijn bureau zitten.</p>
<p>Niet alleen dat, ook het constant binnen zitten met lockdown deed me goed kijken naar wat ik miste in mijn huisinrichting. En zo begon de aanschaf van het ene na het andere essentiële item.</p>
<h2>Mijn werkplek verbeteren</h2>
<p>Toen de eerste lockdown startte had ik mijn MacBook Pro 13’ van 2019, een 23’ budget Asus monitor, een plat APple toetsenbord en een Apple trackpad. Tevens had ik een eerste generatie iPad Mini. Ik verving de Apple trackpad met een <a href="https://support.logi.com/hc/en-us/articles/360035271133-Getting-Started-MX-Master-3">Logitech MX Master 3</a> en het Apple toetsenbord werd vervangen door een <a href="https://www.keychron.com/products/keychron-k6-wireless-mechanical-keyboard">Keychron K6</a> met aluminium case, RGB lichten, en blauwe Gateron switches. Ik wilde altijd een mechanisch toetsenbord hebben en er was geen beter moment dan een lockdown. De Logitech en Keychron waren de juiste keuze, ik heb sindsdien geen last meer van RSI gehad.</p>
<p>De iPad bleek zo oud dat het zelf met nieuwe updates het internet verbinding veel bufferde waardoor de tolk tekst die ik streamde vastliep. Ik heb toen een <a href="https://support.apple.com/kb/SP822?locale=en_US">iPad (8gen) me 128 GB</a> met een Apple Pencil aangeschaft. De oude iPad mini was nog goed voor een tegoedbon van 20 euro. Het verschil was en dag en nacht tussen zo’n oude iPad mini en de nieuwste iPad van dat moment.</p>
<h2>Ook andere aspecten maken thuiswerken fijner</h2>
<p>Ik ben geen koffieleut en dronk het alleen als ik bij de koffiebar was. Ik had dus geen koffieapparaat thuis, maar omdat ik nu altijd thuis was besloot ik een eenvoudig apparaat te kopen voor als ik zin had in een kleine kopje maar geen tijd voor een koffiewandeling. Ik wilde geen van de capsule apparaten en koos voor de eenvoudige <a href="https://www.melitta.co.uk/products/coffee-machines/filter-coffee-machines/aromaboy-filter-coffee-machine-retro/">Melitta Aromaboy</a> filterapparaat. Het is geen dure espressomachine, maar goed genoeg voor een kopje. Die staat nu mooi naast mijn <a href="https://www.krups.nl/p/excellence-toaster-kh682d-broodrooster/7211003732">broodrooster</a>. Om de een of ander reden had ik ook nooit een broodrooster en besloot er eentje te kopen.</p>
<p>Uitgebreid lunch maken, thee van losse blaadjes drinken, en koffiezetten werden een hobby. Op kantoor werken betekende vaak cafetaria voedsel, warm water uit de automaat in een papieren cup voor thee of een wandeling maken om een dure lunch te kopen. Nu had ik mijn eigen keuken met alle nodige apparaten en een AH om de hoek om elke dag een goede lunch te maken.</p>
<p>Daarna besloot ik dat mijn kleine keuken aan een upgrade aan toe was. In de vorm van een nieuw rek waar mijn combi-oven op kon, mijn borden, glazen, <a href="https://www.crock-pot.com/6-quart/crockpot-express-6-qt-pressure-cooker-black-stainless-steel/SAP_2100468.html">Crockpot</a> en nog wat onmisbare spullen. Ook een nieuw kookblok en kookplaat kwamen erbij. Het oude fornuis was een tweedehands ding dat maar half werkte, dus een nieuwe was hoognodig.</p>
<p>Ondertussen besloot het wooncorporatie door te gaan met de voor de pandemie geplande verbouwingen in de herfst/winter. Mijn woning kreeg nieuwe ramen met dubbelglas, betere isolatie en nieuwe deuren. Het resultaat was een “nieuwe” uitstraling van de woonkamer. Tijdens de dagen en tijdsblokken dat mijn woning aan de beurt was was het wel stressen. Ik zat in mijn kleine keukentje te werken met mijn Macbook, mondmasker op, en een dikke trui, want mijn woning had op die momenten geen ramen en deuren.</p>
<p>Nadat alles gedaan was besloot mijn koelkast ook dat het genoeg was na 17 jaar trouwe dienst. Gelukkig gebeurde dat in de tweede lockdown (of was het de derde lockdown) toen bezorgers weer binnen mochten. De lockdowns zijn een grote tijdloze vlek in mijn geheugen. En zo had ik alle reden een strakke moderne koelkast aan te schaffen die past bij mijn nieuwe keukeninrichting.</p>
<p>Het totaalresultaat is een appartement met een praktische Manhattan-achtige keuken waar alles zijn plek heeft zonder vol en rommelig te zijn. Een werkplek met een voor mij ergonomische muis en toetsenbord, ondertussen ook met een <a href="https://www.philips.co.uk/c-p/346E2CUAE_00/ultrawide-lcd-monitor">Philips 34’ curved scherm</a>. Geen last meer van tocht dankzij de nieuwe ramen en deuren. Een iPad die meerdere keren een superhandige oplossing is geweest. En dan heb ik het nog niet over de Lego pronkstukken op mijn boekenkast, want de eerste lockdown weken deed ik niks anders dan puzzels maken en Lego bouwen. En tenslotte, een van de beste dingen die uit de pandemie kwam is mijn vernieuwde liefde voor fotografie.</p>
<h2>Vanuit lockdown ook goede dingen ontstaan</h2>
<p>Tijdens de grote opruiming besloot ik al mijn oude camera spullen in te ruilen voor 1 goede kwaliteit compact camera. Een <a href="https://shop.panasonic.com/cameras-and-camcorders/cameras/point-and-shoot-cameras/dc-lx100m2">Lumix LX100 II</a>. Sindsdien ben ik meer serieus bezig met mijn fotografie en had ik ook een actievere uitlaatklep en afleiding tijdens de lockdowns.</p>
<p>Ondertussen werk ik al bijna 3 jaar thuis. Sinds dit jaar is het hybride werken geworden. Ik ben meestal 1 dag per week op kantoor, soms 2 dagen. Het is voor mij een goede combinatie. Door 1 a 2 keer per week op kantoor te zijn zie ik mijn collega’s en ben ik ook in een andere omgeving, wat mijn creativiteit bevordert. Als ik thuis werk hoef ik niet 2 uur per dag met de OV te reizen waardoor ik mijn dag rustiger kan beginnen doordat ik meer tijd heb. Ik kan mijn werkdag indelen zodat ik tussendoor boodschappen kan doen of een wandeling kan maken. Er is meer flexibiliteit.</p>
<p>Ik heb geen enkele behoefte om weer voltijd op een kantoor te gaan werken. Mijn concentratie is ook beter omdat er niemand om me heen is. Hoewel ik doof ben is het visueel heel storend op een locatie waar honderden mensen zijn die het kantoor in- en uitlopen.</p>
<p>Mijn werkgever zelf stimuleert hybride werken. Alle desktops zijn weg. Alle werknemers hebben nu een laptop. Als je wilt thuiswerken mag dat, als je op kantoor wilt werken kan dat ook. Hybride werken is nu de kern. Microsoft Teams is integrale software geworden waar tot vandaag nog steeds wekelijks afdelingsbrede meetings zijn, updates en dergelijke.</p>
<h2>De toekomst</h2>
<p>Het was een zware periode, vooral door persoonlijk omstandigheden. Maar in het eerste 1,5 jaar van de pandemie maakte technologie het mogelijk dat de wereld online samenkwam. Dankzij Teams en Zoom was ik altijd verbonden met anderen, van videochatten met vrienden en familie, online meetups tot online congressen. Chefs die vanuit hun eigen keuken mensen nieuwe gerechten leerden koken. We deelden allemaal samen de onwerkelijkheid dat de wereld stil stond. De pandemie toonde de kracht van goede technologie die mensen echt helpt. Ik hoop dat men deze lessen in de toekomst zal meenemen.</p>
</content>
</entry>
<entry>
<title>De uitvinding van het function keyword</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/de-uitvinding-van-het-function-keyword"/>
<updated>2022-12-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/de-uitvinding-van-het-function-keyword</id>
<content xml:lang="nl" type="html"><p>Ergens in een parallel universum dicht bij het jouwe... staat Steve Jobs op een groot podium.</p>
<p>Na de introductie van de iPhone 20 en de nieuwe
iMac air max, zegt Steve:</p>
<p>&quot;One more thing&quot;</p>
<p>&quot;Years ago when Apple acquired Netscape we tasked Brendan Eich to create JavaScript in 9 days. It was a tight deadline for sure, but he pulled through.&quot;</p>
<p>&quot;Here at Apple we often wonder, just as the the rest of you, what we would have gotten if we had given Brendan 10 days instead.&quot;</p>
<p>Plotseling dooft het licht. Het auditorium gesluierd in duisternis.</p>
<p>Het publiek houd zijn adem in... gaat het dan toch na al die jaren gebeuren...</p>
<p>&quot;<a href="https://www.youtube.com/watch?v=IFPwm0e_K98">Also sprach Zarathustra</a>&quot; begint te spelen.
Beelden schieten voorbij: man landt op de maan, klimaat crisis opgelost, vrede op aarde.</p>
<p>En dan verschijnt het in beeld, één woord.
Één magisch woord!</p>
<p>Het publiek begint te juichen, mensen vallen elkaar in de armen, emacs vs vim, spaces vs tabs, Tailwind vs CSS, het maakt niet uit.</p>
<p>&quot;Function&quot;</p>
<p>Steve Jobs spreekt met een glimlach:</p>
<p>&quot;The tyranny of the const lambda is finally at an end.&quot;</p>
<p>Terug naar ons universum.</p>
<p>Deze post gaat over iets waar ik me mateloos aan erger, namelijk: de &quot;const lambda&quot; of de &quot;const fat arrow&quot; function.,</p>
<p>Het idee achter het verhaal hierboven is het volgende: als het function keyword nu uitgevonden zou worden, zouden we nooit meer de &quot;const lambda&quot; gebruiken, en was iedereen nu bezig met blogposts schrijven over hoe geweldig het function keyword wel niet is.</p>
<p>Even een paar voorbeelden van de <code>const lambda</code>:</p>
<pre><code>// Een wiskundige berekening
const surfaceOfCircle = (diameter) =&gt; {
const radius = diameter / 2;
return radius * radius * Math.PI;
};
// Een React component
const Greeter = ({name, age}) =&gt; {
return &lt;p&gt;Hello {name}, you are {age} years old&lt;/p&gt;
};
</code></pre>
<p>Ik vind het &quot;signaal&quot; in deze code niet heel sterk.
Met &quot;signaal&quot; bedoel ik dat de schrijver de intentie, wat de code gaat doen, verbergt.</p>
<p>We lezen van links naar rechts: eerst staat de naam er, en dan pas dat het een functie is.</p>
<p>Neem de vorige twee voorbeelden, maar dan geschreven met het <code>function</code> keyword:</p>
<pre><code>// Een wiskundige berekening
function surfaceOfCircle(diameter) {
const radius = diameter / 2;
return radius * radius * Math.PI;
}
// Een React component
function Greeter({name, age}) {
return &lt;p&gt;Hello {name} you are {age} years old&lt;/p&gt;
}
</code></pre>
<p>Ik vind deze varianten in mijn bescheiden mening veel leesbaarder, het signaal, de intentie is sterker.</p>
<p>Van links naar rechts rusten mijn ogen op het keyword &quot;function&quot;, in één oogopslag weet ik wat er nu gaat komen... een functie.</p>
<p>Is er dan geen enkele reden om een lambda / fat arrow te gebruiken? Nee hoor: voor callbacks zijn ze ideaal. Ze nemen dan juist &quot;ruis&quot; weg.</p>
<p>Zoals bijvoorbeeld bij de verschillende array functions:</p>
<pre><code>const persons = [
{ name: &quot;Maarten&quot;, age: 33 },
{ name: &quot;Tosca&quot;, age: 31 },
{ name: &quot;Owen&quot;, age: 5 },
{ name: &quot;Jane&quot;, age: 2 },
];
const adults = persons
.filter(person =&gt; person.age &gt;= 18);
</code></pre>
<p>Ook hebben lambda's de mooie eigenschap dat ze de <code>this</code> niet manipuleren.</p>
<p>Neem het volgende voorbeeld dat geschreven is voordat de lambda beschikbaar was: het idee is dat de <code>birthday</code> pas na 1 seconde wordt uitgevoerd.</p>
<pre><code>var person = {
name: &quot;Maarten&quot;,
age: 33,
birthday: function () {
setTimeout(function() {
console.log(&quot;Birthday timeout&quot;, this);
this.age += 1;
}, 1000);
}
};
person.birthday();
</code></pre>
<p>In de code hierboven zit een subtiele bug, namelijk dat de &quot;this&quot; in de timeout niet naar &quot;person&quot; wijst maar naar de &quot;window&quot;.</p>
<p>Na 1 seconde is de <code>window.age</code> dus met plus 1 gedaan wat <code>NaN</code> (Not a Number) oplevert.</p>
<p>Vroeger pre lambda loste je dit zo op:</p>
<pre><code>var person = {
name: &quot;Maarten&quot;,
age: 33,
birthday: function () {
// Stel de &quot;this&quot; even veilig zodat
// het in de timeout gebruikt kan
// worden.
var self = this;
setTimeout(function() {
console.log(&quot;Birthday timeout&quot;, this, self);
// Hier self ipv this omdat this
// anders de `window` wijst.
self.age += 1;
}, 1000);
}
};
// Pas na 1 seconde gaat age omhoog
person.birthday();
</code></pre>
<p>Maar met lambda / fat arrow functions hoeft dit <code>self</code> trucje dus niet meer. Lambda functions behouden de <code>this</code>:</p>
<pre><code>const person = {
name: &quot;Maarten&quot;,
age: 33,
birthday() {
setTimeout(() =&gt; {
console.log(&quot;Birthday timeout&quot;, this);
this.age += 1;
}, 1000);
}
};
person.birthday();
</code></pre>
<p>Lambda functies zijn dus helemaal zo gek nog niet.</p>
<ul>
<li>Mijn advies samengevat is dus: gebruik het function keyword</li>
<li>om functies te definieren in plaats van &quot;const lambda&quot;</li>
<li>voor een sterker signaal.</li>
</ul>
<p>En gebruik lambda's voor callbacks, voor compactere code, en om vervelende this bugs te voorkomen.</p>
</content>
</entry>
<entry>
<title>How I stopped worrying and learned to love Docker</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/how-i-stopped-worrying-and-learned-to-love-docker"/>
<updated>2022-12-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/how-i-stopped-worrying-and-learned-to-love-docker</id>
<content xml:lang="nl" type="html"><p>Developen is natuurlijk het leukste als de omgeving waarop je werkt ook zonder issues werkt. Dat scheelt veel frustratie en je hoeft alleen maar na te denken over het schrijven van mooie code. Zo werkten we op mijn werk eerst met VirtualBox / Vagrant. We gebruikten één virtual machine waarop alle sites draaiden. Om een website draaiend te krijgen moesten we na een Git clone nog best veel handelingen verrichten om een website daadwerkelijk te kunnen gebruiken. Werkte <em>oké-ish</em>, maar daarna zijn we overgestapt naar Docker, en dat vind ik dus een ontzettende verbetering van mijn workflow. Maar ik hoor ook veel geluiden van front-end developers die al beginnen te huilen als ze in de buurt van Docker komen. Dus ik heb besloten uit te leggen hoe wij het ingericht hebben, in de hoop dat andere developers er hun voordeel mee kunnen doen.</p>
<p>Twee disclaimers:</p>
<ul>
<li>Eén: Er zijn veel manieren om Docker in te richten dus ik weet alleen dat onderstaande voor mij werkt met onze opzet.</li>
<li>Twee: ik ben geen back-end developer, dus ik weet niet exact waarom zaken zó ingericht zijn en of het beter of anders kan.</li>
</ul>
<h2>Waarom gebruiken we Docker?</h2>
<p>De marketing uitleg: Docker is een zogenoemd ‘containerization platform’ waarmee je sites en apps kan bouwen, deployen en onderhouden met behulp van containers.</p>
<p>Hoe werkt dat in de praktijk? Stel, je werkt met een team aan een site. Eén developer werkt op Windows, twee werken op Linux, en een ander weer op een macOS. Dan heb je op elk van deze computers in feite een andere omgeving, met evenveel variabelen waardoor zaken net weer anders kunnen werken. (En iedereen kent wel de uitdrukking: ‘Works on my machine’.)</p>
<p>Deze verschillen kan je elimineren door je site in te pakken in een Docker container. Dit kan je zien als een mini-virtual machine met dezelfde instellingen, die je commit in de repo. Dus iedereen die het project binnenhaalt kan aan de hand van deze instellingen dezelfde virtual machine aanmaken, en dus de site op exact dezelfde omgeving runnen.</p>
<p>Zo kunnen developers dus werken zonder zich druk te maken om de omgeving. Op mijn werk hebben we dit inmiddels <em>smooth</em> aan de praat voor iedereen, en het bevalt prima!</p>
<h2>De Happy Path: Wat doe ik als front-ender als alles goed gaat</h2>
<p>In het meest ideale geval verlopen de stappen als volgt:</p>
<ul>
<li><code>git clone</code> Ik clone de repo van onze git repository</li>
<li>Ik krijg een gezipte database (meestal vanuit de productie website, zodat deze lekker up-to-date is) aangeleverd, en zet die in de lege <code>/docker/database</code> directory. Voor multi-site systemen (meerdere websites die draaien op één codebase) zet ik de database een mapje dieper, maar het principe blijft hetzelfde.</li>
<li>In de root staat een /.env.example file met de Docker instellingen. Deze kopieer ik naar een nieuwe /.env file . Deze file staat in de .gitignore en wordt dus niet mee gecommit.</li>
<li>In een apart terminalvenster draai ik <code>docker compose up</code> en hops: mijn containers draaien! Dit venster laat ik open zodat ik eventuele foutmeldingen kan zien.</li>
<li>Bij mij betekenen bovenstaande stappen dat ik vervolgens my-website.localhost heb draaien, waar ik kan zien wat ik doe.</li>
</ul>
<p>Naast het bovenstaande heb ik als GUI Docker Desktop draaien, waar ik een visueel overzicht heb welke containers draaien. Daar kan ik eventueel ook een enkele container snel weggooien en herstarten indien nodig.</p>
<p><img src="https://www.fronteers.nl/_img/blog-anke-1.png" alt="Het Docker Desktop overzichtsvenster. In het groen zijn de draaiende containers weergegeven met relevante info over versies en poorten erachter. In het grijs de containers die ook aanwezig zijn maar nu niet draaien. Het oranje label geeft overigens aan dat er één container is die nog niet op een versie draait die compatible is met de M1 MacBook." /></p>
<p>Het Docker Desktop overzichtsvenster. In het groen zijn de draaiende containers weergegeven met relevante info over versies en poorten erachter. In het grijs de containers die ook aanwezig zijn maar nu niet draaien. Het oranje label geeft overigens aan dat er één container is die nog niet op een versie draait die compatible is met de M1 MacBook.</p>
<p>Bovenstaande workflow vereist eigenlijk geen enkele Docker kennis. Als ik een database heb en de repository, dan krijg ik de boel draaiend.</p>
<p>Als ik klaar ben met mijn project, of switch van project, ga ik naar het terminalvenster met de draaiende Docker container, en stop ik met ctrl-c alle containers van het project.</p>
<h2>Hoe zit deze opzet in elkaar?</h2>
<p>Wij ontwikkelen voornamelijk sites op het CMS Drupal, en onze opzet volgt het systeem van <a href="https://github.com/wodby/docker4drupal">Wodby</a> .</p>
<p>Een Docker container is een “soort van” kleine virtual machine. Docker maakt gebruik van ‘images’. Dit zijn instructiesets / commando’s waarmee de containers worden ingericht. Zo heb je bijvoorbeeld een PHP image, een Nginx image etc. Een PHP image zal dus bijvoorbeeld zorgen dat de juiste versie van PHP geïnstalleerd wordt op de PHP container. Het basisprincipe van Docker is dat je probeert om elke container maar één verantwoordelijkheid te geven. De PHP container is dus bijvoorbeeld alléén maar verantwoordelijk voor PHP en de Mysql container is alléén maar verantwoordelijk voor het draaien van Mysql.</p>
<p>Om te zorgen dat alle containers goed samenwerken maken we gebruik van Docker Compose [https://docs.docker.com/compose/ ]. Bij Docker Compose maak je gebruik van een YAML file om alle services van je applicatie te configureren: <code>/docker-compose.yml</code>. Daarin staat bv welke services (PHP, Apache, Nginx, MariaDB, node, elastic etc) je site of applicatie gebruikt en op welke poort een service draait. Deze file importeert op zijn beurt weer de variabelen die per omgeving in de hierboven genoemde .env file gezet zijn. Hierin staat bv <em>welke</em> versie van bovengenoemde service wordt gebruikt, en welke image moet worden binnen gehaald. Bij Flink maken we vaak ook gebruik van de images van <a href="https://hub.docker.com/u/wodby/#!">Wodby</a>, omdat deze goed configureerbaar zijn, over het algemeen goed up-to-date zijn en een volledig ecosysteem levert (PHP, Mysql, Nginx, etc.).</p>
<p>Bij het commando <code>docker compose up</code> worden de containers opgestart (en gedownload als ze nog niet beschikbaar waren), de services geïnstalleerd en samengevoegd tot een werkende omgeving. Er worden per Docker image commando’s uitgevoerd die in de docker-compose.yml staan. Zo wordt er voor de database container bijvoorbeeld gecheckt of er al een eerder gebruikte database container aanwezig is. Zo niet, dan bouwt Docker er eentje en importeert daarna de database die ik net in de /docker/database directory geplaatst heb.</p>
<h2>Deze Docker files hebben we in de root van onze sites staan</h2>
<pre><code>/docker
/database
/name-of-database.gzip
.env.example
.env ( = de door de gebruiker gemaakte kopie van .env. example)
docker-compose.yml
/web (de site)
+ de normale files die in de root van je repo staan
</code></pre>
<h2>Gaat alles dan altijd meteen goed?</h2>
<p>Nee. Sterker nog, in het begin heb ik heel veel moeten troubleshooten om dingen werkend te krijgen. Waar liep ik tegenaan?</p>
<h2>Containers crashten bij opstarten</h2>
<p>Ik was de eerste met een M1 MacBook op kantoor. En regelmatig werkte de specifieke versie van een container die in de .env file stond niet voor de M1. Deze heeft namelijk een nieuwe architectuur van de chip ten opzichte van oudere MacBooks, en dus ook aangepaste images nodig. Hier liep ik regelmatig tegen aan met bijvoorbeeld mariaDB en Nginx containers. Dus dat betekende zoeken tot je een versie had die wel op de M1 werkte en dat in je .env file aanpassen. En omdat de .env file in de .gitignore staat, blijft die wijziging alleen lokaal. (Ter referentie, dit geeft vaak de volgende error: <code>runtime: failed to create new OS thread (have 2 already; errno=22</code>)</p>
<h2>Geheugenproblemen</h2>
<p>Daarnaast heeft mijn MacBook maar 8gb geheugen. En dat is eigenlijk te weinig voor Docker, dat bij default ongeveer 6gb geheugen wil. Je kan het lager instellen (via Docker Desktop) maar naar minder dan 6gb luistert ie eigenlijk niet. En dat betekent dus dat je nog maar 2 gb over hebt voor de rest van je systeem. Spoiler: Dat is te weinig. In mijn geval betekent dat regelmatig mijn PhpStorm en/of Firefox herstarten om wat geheugen vrij te maken. Maar zorg dus dat je in ieder geval 16gb geheugen hebt, als je op een MacBook ontwikkelt.</p>
<h2>Wat gebruik ik daarnaast nog?</h2>
<p>In elke directory staat NVM (<a href="https://github.com/nvm-sh/nvm">Node Version Manager</a>), die ons de juiste Node versie serveert. Daarnaast natuurlijk een <code>package.json</code> waardoor we met <code>npm install</code> meteen de juiste versies van de benodigde node modules kunnen installeren.</p>
<p>Wij draaien Grunt met Browsersync om mijn scss te compileren en live updates te zien in de browser. (Gezien de tijd dat Grunt al meegaat hebben mensen hier vast een mening over, maar het draait en het draait snel en stabiel. ) Bij onze Docker containers gebruiken we de volgende opties van browsersync in de Gruntfile.js:</p>
<pre><code>options: {
watchTask: true,
proxy: '&lt;http://www-mysite-nl.localhost&gt;',
host: 'www-mysite-nl.localhost',
open: false
}
</code></pre>
<p>En om browsersync zonder problemen te draaien heb ik in mijn hostfile op de mac (/etc/hosts) de volgende regel staan: <code>127.0.0.1 www-mysite-nl.localhost</code></p>
<p>De <code>127.0.0.1</code> is op de Mac vooralsnog nodig, zonder deze extra aanwijzing werkt <code>www-mysite-nl.localhost:3000</code> niet als locatie voor de live update van browsersync.</p>
<p>Toelichting hierover van mijn back-end collega Paul: Windows / Docker op Windows kan tegenwoordig overweg gaan met subdomeinen van localhost. Mac kan dat (nog) niet. Een oplossing hiervoor kan zijn, om te werken op een daadwerkelijk domein die verwijst naar je localhost, bijv. een .dev domein. Voor nu plaatsen we op de Mac de domeinreferentie in de hosts file, wat het probleem ook oplost.</p>
<h2>Vergeet de README niet!</h2>
<p>Er zijn natuurlijk veel verschillende manieren van het opzetten van je Docker structuur. En de bedoeling van Docker is dat iedereen die het project cloned dezelfde omgeving kan gebruiken en dat het hun leven <em>makkelijker</em> maakt. Zorg dus dat je in de README van het project duidelijk omschrijft welke stappen er nodig zijn om deze Docker container aan de praat te krijgen. En dan liever teveel dan te weinig uitleg, want je wil ook je freelancers en stagiairs die minder kennis hebben van de ‘normale’ workflow in jullie bedrijf goed kunnen helpen.</p>
<h2>Docker compose HUP!</h2>
<p>Inmiddels hebben wij alle omgevingen <em>flawless</em> draaien op de computers van alle developers. Ik vind het onzettend fijn werken, omdat je met één command in de juiste directory, namelijk <code>docker compose up</code> , in een paar seconden exact de omgeving hebt die je eerder had draaien, totaal onafhankelijk van de andere projecten waar je aan werkt.</p>
<p>Ik hoop dat ik op deze manier een beetje inzicht heb kunnen geven in hoe ik met Docker werk, en de voordelen die het heeft als je het goed inricht. En het blijft een proces. Bij ons op het werk was het ook niet in één keer goed, maar omdat we er dagelijks gebruik van maken en tijd hebben gemaakt om de verbeteringen in alle sites door te voeren, hebben we nu een tamelijk <em>foolproof</em> implementatie waar de feedback van al onze collega’s in meegenomen is. Succes met je eigen opzet, en hopelijk is dit het einde van minimaal één geval van ‘works on my machine’.</p>
<h2>Dank!</h2>
<p>Veel dank aan mijn collega Paul Dudink, die bij ons op Flink de Docker omgevingen heeft ingericht en mij van veel extra informatie en aanvullingen voorzien heeft voor deze blogpost.</p>
<h2>Resources:</h2>
<ul>
<li><a href="https://github.com/docker/awesome-compose">kant en klare docker-compose.yml voorbeelden voor diverse omgevingen</a></li>
<li><a href="https://wodby.com/docs/1.0/stacks/drupal/local/">Wodby documentatie Docker voor Drupal installaties</a></li>
</ul>
</content>
</entry>
<entry>
<title>Wees (niet) slim en gebruik webstandaarden</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/wees-niet-slim-en-gebruik-webstandaarden"/>
<updated>2022-12-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/wees-niet-slim-en-gebruik-webstandaarden</id>
<content xml:lang="nl" type="html"><p>Aangezien dit een lang artikel is, eerst even in het kort:</p>
<ul>
<li>Gebruik van webstandaarden kunnen je helpen keuzes te maken;</li>
<li>Slimmere mensen dan ik hebben allerlei manieren bedacht om het wereldwijde web te gebruiken, inclusief allerlei randvoorwaarden en afwegingen;</li>
<li>Er bestaat een voorstel voor alles wat je maar kan bedenken;</li>
<li>Het web is niet gemaakt voor de browser;</li>
<li>Jij gebruikt webstandaarden.</li>
</ul>
<p>Ben je een front-end developer die meer wil weten over het internet of het wereldwijde web? Ben je een full-stack developer (in wat voor hoedanigheid dan ook) en wil je meer weten over webstandaarden? Wil je helpen met keuzes maken bij architectuur of design van een (web-)API (application programming interface)?</p>
<p>Als je op een van de bovenstaande vragen ja heb geantwoord, of je het een interessant onderwerp lijkt, dan is dit artikel voor jou!</p>
<p><em>💡 Doorgaans worden webstandaarden geschreven en gepubliceerd in het Engels. Alle links naar zo'n standaard, een RFC (wat dat is volgt), of media type registratie wijzen naar pagina's in het Engels</em>.</p>
<h2>Wat is het wereldwijde web?</h2>
<p>Om het over webstandaarden te hebben is het handig om eerst een aantal definities te benoemen en toe te lichten.</p>
<h2>HTTP</h2>
<p>HTTP staat voor Hypertext Transfer Protocol.</p>
<p>Een protocol is doorgaans een set van regels om een doel te bereiken. In dit geval gaat het om een communicatie en overdrachts protocol en beschrijft de syntax, semantiek, foutdetectie en -correctie, synchronisatie om het volgende te bewerkstelligen:</p>
<blockquote>
<p>&quot;...where hypertext documents include hyperlinks to other resources that the user can easily access.&quot; <a href="https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol"><em>Wikipedia</em></a></p>
</blockquote>
<p>Ofwel: <em>hypertext</em> documenten die <em>hyperlinks</em> bevatten naar andere <em>resources</em> die een <em>gebruiker</em> eenvoudig kan raadplegen. Wat deze begrippen inhouden volgt.</p>
<h2>Hypertext, hyperlinks, hypermedia</h2>
<p>&quot;Hyper-&quot; van de Griekse prefix &quot;ὑπερ-&quot;, hetgeen <em>over</em> of <em>super</em>, ofwel <em>meer dan</em> betekent.</p>
<ul>
<li><em>Hypertext</em> is tekst die digitaal wordt weergegeven, met referenties (jawel, de hyperlink) naar andere (hyper)tekst waar een gebruiker direct bij kan.</li>
<li><em>Hyperlink</em> is een link (een referentie) die een gebruiker toegang geeft tot de data achter die link.</li>
<li><em>Hypermedia</em> is een extensie van de term hypertext en beschrijft de non-lineaire (digitale) media dat platte tekst, hyperlinks, maar ook plaatjes, audio, en video bevat.</li>
</ul>
<p>Een voorbeeld van een <em>hypermedium</em> is het WereldWijde Web!</p>
<h2>HTML</h2>
<p><a href="https://html.spec.whatwg.org/">HTML</a> staat voor HyperText Markup Language.</p>
<p>Dit betekent dus ook dat <em>hypertext</em> niet hetzelfde is als <em>HTML</em>, maar een manier om hypertext <em>op te maken</em> (te markeren) zodat de data (de tekst, en bij hypermedia ook de andere inhoud) kan worden weergegeven of gerefereerd kan worden (juist, met <em>hyperlinks</em>).</p>
<p><a href="https://html.spec.whatwg.org/">De HTML standaard</a> is bedoeld om documenten te annoteren zodat ze kunnen worden weergegeven in een web browser. Daarmee is het een manier om hypertekst interactief te maken. De web browser is daarmee (ook) een stuk gereedschap om hyperlinks te volgen.</p>
<p>HTTP helpt ons HTML documenten te versturen. Het is immers een Hypertext <em>Transfer Protocol</em> voor documenten geschreven in Hypertext Markup Language.</p>
<h2>...en andere media dan?</h2>
<p>Als je het web surft, dan heb je doorgaans niet alleen met tekst — plat of opgemaakt — te maken. Je komt ook vaak genoeg andere inhoud tegen zoals plaatjes, audio, video, en andere niet-tekstuele inhoud.</p>
<p>De slimme mensen die HTTP tot leven hebben gebracht (en daarna verder hebben ontwikkeld), hebben een slimme manier bedacht om het mogelijk te maken dat HTTP meer beschrijft en aankan dan <em>alleen</em> hypertext en hypertext-documenten versturen. Dit is ondersteund in HTTP door het gebruik van metadata die, samen met de inhoud waar je om hebt gevraagd, wordt mee gestuurd.</p>
<p>Voor de ondersteuning van andere media dan HTML (en hypertext) wordt meestal gebruik gemaakt van een <em>Media type (MIME TYPE)</em>.</p>
<h2>Mediatype</h2>
<blockquote></blockquote>
<p>Op het web spreken we technisch van <em>representaties</em> van een <em>resource</em>. Het formaat van zo'n representatie (dus de syntax, de regels, het gebruik, de beperkingen, enzovoorts) noemen we ook wel een <em>media type</em>.</p>
<p>Een aantal voorbeelden van media types zijn:</p>
<ul>
<li><code>text/html</code></li>
<li><code>image/png</code></li>
<li><code>application/json</code></li>
</ul>
<p>Er zijn regels over de syntax en het gebruik van deze media types. We hebben met elkaar afgesproken hoe bepaalde binaire data kan worden geïnterpreteerd (gelezen) of worden gearrangeerd (geschreven). Een PNG plaatje is een PNG plaatje als we de binaire data <em>interpreteren</em> als PNG. Hoe dat voor PNG moet is opgeschreven en aangenomen als standaard alvorens het (publiek) te registreren.</p>
<h2>Het registeren van een media type?</h2>
<p>Juist. Hier zijn nog drie voorbeelden van media types:</p>
<ul>
<li><code>application/vnd.ms-powerpoint</code></li>
<li><code>application/graphql</code></li>
<li><code>application/vnd.xpbytes.errors.v1+json</code></li>
</ul>
<p>Het eerste beschrijft Microsoft Powerpoint bestanden, het tweede was lang de standaard-niet-standaard manier om GraphQL queries en antwoorden te beschrijven, en de laatste is één van de vele <em>vendor (<code>vnd</code>) specifieke</em> media types die intern op werk veel wordt gebruikt om foutmeldingen te beschrijven.</p>
<p>Er is een document (en standaard) dat beschrijft hoe je een media type kan registreren:</p>
<blockquote>
<p><a href="https://tools.ietf.org/html/rfc6838">RFC 6838: Media Type Specifications and Registration Procedures</a></p>
</blockquote>
<p>Het doel van het registreren van zo'n media type is dat het gebruikt kan worden op het internet, en dat we het er over eens kunnen worden hoe de data kan worden geïnterpreteerd. Er is geen verplichting (regel) om dit te doen voor media types die beginnen met <code>vnd.</code>, maar het process kan helpen met het schrijven, opschonen, en verbeteren van een specificatie.</p>
<p>Voor media types buiten de <code>vnd.</code> (vendor) en <code>prs.</code> (personal) boom — media types die niet beginnen met die prefix — bestaat de verplichting wel. Iets is officieel pas een media type als deze geregistreerd is.</p>
<h2>Request For Comments (RFC)</h2>
<p>Dat laatste document voor het registreren van een media type is een RFC: een <em>request for comments</em>. Het is een publicatie van een technisch document dat als doel heeft een <em>nieuwe standaard</em> te beschrijven of een <em>bestaande standaard</em> aan te passen (waardoor er een nieuwe standaard ontstaat).</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/image.png" alt="XKCD 927: Standards. Strip met drie panelen. Koptekst boven de panelen: &quot;How standards proliferate (see: A/C chargers, character encodings, instant messaging, etc.)&quot;. Eerste paneel: &quot;Situation: there are 14 competing standards&quot;. Tweede paneel: Er wordt gesproken: &quot;14?! Ridiculous! We need to develop one universal standard that covers everyone's use cases.&quot;. De reactie hierop is: &quot;Yeah!&quot;. Derde paneel: &quot;Soon: Situation. There are 15 competing standards.&quot;" /></p>
<p>Het is veelal de Internet Engineering Task Force (IETF) die zich hiermee bezig houdt. Deze <em>task force</em> die zal na dat een publicatie is beoordeeld door meerdere mensen, en commentaar is geleverd, er voor kunnen kiezen om een voorstel te publiceren als <em>internet standaard</em>.</p>
<p>En my oh my... er is een RFC voor écht alles.</p>
<h2>RFC voor alles</h2>
<p>Zojuist zijn al wat media types genoemd. Deze bestaan als gepubliceerde RFCs (en daarmee zijn het dus ook internet standaarden). Voorbeelden hiervan zijn:</p>
<ul>
<li><a href="https://www.iana.org/assignments/media-types/image/png"><em>image/png</em> registratie</a>: specificatie <a href="https://www.rfc-editor.org/rfc/rfc2083">RFC 2083</a>;</li>
<li><a href="https://www.iana.org/assignments/media-types/text/html"><em>text/html</em> registratie</a>: specificatie <a href="https://www.rfc-editor.org/rfc/rfc2854">RFC 2854</a> (voorheen <a href="https://www.rfc-editor.org/rfc/rfc1866">RFC 1866</a>);</li>
<li><a href="https://www.iana.org/assignments/media-types/application/json"><em>application/json</em> registratie</a>: specificatie <a href="https://www.rfc-editor.org/rfc/rfc8259">RFC 8259</a> (voorheen <a href="https://www.rfc-editor.org/rfc/rfc4627">RFC 4627</a>)</li>
</ul>
<p>Ontzettend handig, want als je wil weten of je iets wel of niet kan doen, hoe je dat dan doet, en wat de afspraken zijn, dan kan je deze documenten dus bestuderen en bijna altijd het antwoord er in terug vinden.</p>
<p>Met alles bedoel ik overigens wel écht <em>alles</em>. Hoe we platte text beschrijven vind je terug in <a href="https://www.rfc-editor.org/rfc/rfc822">RFC 822</a>, en dat stamt uit de tijd dat <em>het internet nog niet bestond</em> maar we nog spraken van <a href="https://en.wikipedia.org/wiki/ARPANET">ARPANET</a>. Hoe je tekst kan versturen over het internet (over HTTP) is te lezen in <a href="https://www.rfc-editor.org/rfc/rfc1521#section-7.1">RFC 1521</a>, maar ook HTTP zelf is beschreven in RFCs, waaronder:</p>
<ul>
<li><a href="https://datatracker.ietf.org/doc/html/rfc1945">RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0</a></li>
<li><a href="https://datatracker.ietf.org/doc/html/rfc9110">RFC 9110: HTTP Semantics</a></li>
<li><a href="https://datatracker.ietf.org/doc/html/rfc9111">RFC 9111: HTTP Caching</a></li>
<li><a href="https://datatracker.ietf.org/doc/html/rfc9112">RFC 9112: HTTP/1.1</a></li>
<li><a href="https://datatracker.ietf.org/doc/html/rfc9113">RFC 9113: HTTP/2</a></li>
<li><a href="https://datatracker.ietf.org/doc/html/rfc9114">RFC 9114: HTTP/3</a></li>
</ul>
<p>Dat er voor allerlei technische aspecten RFCs bestaan (die dus veelal worden aangenomen als Internet Standaard) is voor mij niet raar. Maar toen ik zei dat er een RFC bestaat voor alles bedoelde ik (nóg) meer. Dus om nog heel even door te ratelen heb ik nog drie voorbeelden.</p>
<h3>RFC 1121</h3>
<blockquote>
<p><a href="https://www.rfc-editor.org/rfc/rfc1121">RFC 1121</a></p>
</blockquote>
<p><em>Een verzameling gedichten</em>.</p>
<h3><a href="https://www.rfc-editor.org/rfc/rfc1925">RFC 1925</a></h3>
<pre><code>This memo documents the fundamental truths of networking for the Internet community.
[...]
**The Fundamental Truths**
(1) It Has To Work.
[...]
(3) With sufficient thrust, pigs fly just fine.
</code></pre>
<p>Twee waarheden:</p>
<ol>
<li>Een fundamentele waarheid over communicatie over en gebruikmakend van het internet: &quot;Het moet werken&quot;</li>
<li>Met voldoende stuwkracht kunnen varkens prima vliegen.</li>
</ol>
<h3><a href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119</a></h3>
<p>Maar ook randzaken die ontzettend belangrijk zijn als we het hebben over standaarden zijn terug te vinden in een RFC.</p>
<p>Degene die het meest voor komt is <a href="https://www.rfc-editor.org/rfc/rfc2119">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a>:</p>
<blockquote>
<p>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as described in RFC 2119.</p>
</blockquote>
<p>Er zijn nauwe definities voor de sleutelwoorden hier genoemd, en weten wat die definitie is helpt bij zowel het opstellen van als het lezen van een RFC en subsequent ook een Internet Standaard.</p>
<h2>Maar wat heb ik hieraan?</h2>
<p>Laten we beginnen met de vraag: <em>Voor wie is HTTP bedoeld?</em>. Je hebt het woord <em>gebruiker</em> een aantal maal gelezen, zonder dat ik heb gedefinieerd wie of <em>wat</em> een gebruiker is. Wat is dat, een gebruiker?</p>
<p>Het antwoord hierop kunnen we terug vinden in <a href="https://www.rfc-editor.org/rfc/rfc2616">RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1</a>:</p>
<blockquote></blockquote>
<p>Eerst wordt beschreven waarvoor HTTP kan worden gebruikt. En verderop staat de definitie:</p>
<pre><code>**user agent**
The client which initiates a request.
These are often browsers, editors, spiders (web-traversing robots), or other end user tools.
</code></pre>
<p>Hieruit volgt dat de HTTP standaard niet <em>alleen</em> bedoeld is voor mensen, en ook niet alleen voor browsers.</p>
<h2>HTTP: waar is het voor?</h2>
<p>Als het protocol niet alleen voor browsers of eind-gebruikers is, dan is er meer aan de hand. Deze standaard wil ons helpen meer te bereiken dan alleen hypertext en andere hypermedia over de netwerkkabel versturen naar onze computerschermen.</p>
<h2>⚡ HTTP is de oplossing voor zogenoemde <em>hard problems</em></h2>
<ul>
<li>Caching (veel user agents, één server);</li>
<li>Consistentie (data format, fouten, en het scheiden van data en fouten);</li>
<li>Interoperabiliteit (tussen verschillende implementaties);</li>
<li>(en meer).</li>
</ul>
<h2>Het wiel uitvinden</h2>
<p>Het is bij veel mensen bekend dat het over het algemeen een <em>heel</em> slecht idee is om zelf een versleuteling te verzinnen voor zaken die echt privé moeten worden. We zeggen dan ook wel &quot;Don't roll your own Encryption/Cryptography/Security&quot;. Op de security stackexchange zijn <a href="https://security.stackexchange.com/questions/6740/flaw-in-encryption-through-pseudorandom-number-stream-from-pgp-documentation">verschillende</a> <a href="https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own">vragen</a> te vinden over dit wel doen of waarom je dit niet doet en één van de beste antwoorden vind ik:</p>
<blockquote>
<p>If you are not convinced of &quot;Don't Roll Your Own [Cryptography/Security]&quot;, then you probably are not an expert and there are many mistakes you likely will make.</p>
</blockquote>
<p>&quot;Als je er niet van overtuigd bent dat het zelf verzinnen van een manier om te versleutelen of te beveiligen, dan ben je <em>waarschijnlijk</em> geen expert en zullen er veel fouten zijn die je gaat maken.&quot;</p>
<h3>Hoe relateert dat tot een webstandaard?</h3>
<p>Je hebt wellicht weleens de uitdrukking &quot;there's a package for that&quot; of &quot;there's a gem for that&quot; gehoord. Hetzelfde is bijna altijd waar voor meer abstracte problemen: &quot;there's a spec for that&quot;. Zelfs als er geen spec is, dan is er vaak wel een <em>proposal</em> of een <em>draft</em>. Dit betekent daardoor ook dat het onnodig is om het wiel uit te moeten vinden. Er is al iemand of een groep mensen geweest die over je probleem heeft nagedacht, en daar (hopelijk) wat slimme dingen over heeft opgeschreven.</p>
<p>En als je er <em>toch</em> voor kiest om zelf iets te verzinnen, dan kan je of leren van wat er al is, of je informatie opschrijven in een RFC formaat zodat <em>anderen</em> je standaard kunnen gebruiken. Dit maakt het weer makkelijker.</p>
<p>En als je met front-end (of back-end, of wat dan ook) te maken hebt, dan gebruik je <em>elke dag</em> al webstandaarden!</p>
<h3>Hoe voorkom ik dat het wiel opnieuw wordt uitgevonden?</h3>
<p>Er is helaas geen makkelijk antwoord op deze vraag, omdat je eigenlijk moet weten of inschatten of er voor iets een standaard bestaat. Het moment dat ik zelf kijk of er een standaard bestaat is tweevoudig: iets voelt <em>tegendraads</em> (moeilijker dan nodig), of iets klinkt complex.</p>
<p>Een aantal voorbeelden die hopelijk een tipje van de sluier kunnen oplichten:</p>
<h3>a. Interactie toevoegen aan HTML elementen*</h3>
<p>Ook ik heb voorheen gebruik gemaakt van <code>onclick=&quot;&quot;</code> attributen of het equivalent in JavaScript. Ik leerde daarna over het web gebruiken zonder muis (en ben zelf een veel-gebruiker van toetsenbord navigatie geworden), en om dan een &quot;knop&quot; klikbaar te maken is best wel wat extra JavaScript nodig. In de laatste jaren ben ik veel bezig geweest met toegankelijkheid. Om screenreaders een <code>div</code> te laten herkennen als knop, heb je <em>nog</em> meer code en markup nodig. Oef.</p>
<pre><code>&lt;!-- iets toegankelijker dan onclick=&quot;&quot; --&gt;
&lt;div
class=&quot;button&quot;
role=&quot;button&quot;
aria-pressed=&quot;false&quot;
tabindex=&quot;0&quot;
&gt;
My action
&lt;/div&gt;
&lt;script&gt;
// [...]
myActionElement.addEventListener(&quot;keydown&quot;, e =&gt; {
if (e.key === &quot; &quot; || e.key === &quot;Enter&quot; || e.key === &quot;Spacebar&quot;) {
e.target.setAttribute('aria-pressed', 'true')
}
});
// [...] up handler om te activeren als ie pressed was
// [...] blur handler om pressed weer weg te halen zonder activatie
// [...] disabled implementatie via aria-disabled
&lt;/script&gt;
</code></pre>
<p>De <a href="https://html.spec.whatwg.org/">HTML standaard</a> heeft een aantal hulpmiddelen om HTML interactief te maken, waaronder <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button">het button element</a>. Dit element heeft ondersteuning voor allerlei manieren van interactie. Volgens de MDN (Mozilla Developer Network) beschrijving is het <code>button</code> element een interactief element geactiveerd door een gebruiker met een muis, toetsenbord, vinger, spraakcommando, of andere toegankelijkheidtechnologie.</p>
<p>Daarnaast kan de actie ook worden geblokkeerd door het <code>disabled</code> attribuut te gebruiken, heeft het standaard een kenmerkende rol (namelijk <code>button</code>), is deze standaard focusbaar zonder <code>tabindex</code> en is geen custom CSS <em>nodig</em> om het er als een knop uit te laten zien.</p>
<p>Voordat ik een <code>div</code> gebruik is mijn regel dus: ben bekend met de huidig gangbare HTML elementen en hun doel.</p>
<h3>b. Veel gebruikers aankunnen met weinig serverkracht</h3>
<p>Ik heb gewerkt aan meerdere producten die dagelijks honderden, duizenden, of zelfs miljoenen gebruikers hadden. Servers zijn kostbaar, bandbreedte in <em>the cloud</em> al helemaal, en het aantal gebruikers is niet consistent.</p>
<p>Dit is een moeilijke uitdaging.</p>
<p>Als je zoekt hoe je het consistentie probleem kan oplossen kom je al gauw terecht op een techniek die auto-scaling heet: het semi-automatisch op en afschalen van servers om meer gebruikers tegelijk aan te kunnen wanneer het nodig is, en minder servers online te hebben wanneer dat niet nodig is. Als je iets langer doorzoekt zie je ook dat auto-scaling op zichzelf ontzettend moeilijk is om goed te doen. Bijvoorbeeld: wat zijn goede regels voor het op-en- afschalen? Wat is het limiet? Hoe ga je om met het langzaam opstarten van de servers (waardoor de regel om bij te schalen actief blijft)? De antwoorden variëren van &quot;it depends&quot; tot &quot;thoughts and prayers&quot;.</p>
<p>Nee, er moest een betere (en vooral stabielere) manier zijn om meer gebruikers aan te kunnen zonder dat dat heel veel geld kost.</p>
<p>Onze applicatie had meer gebruikers die pagina's wilden lezen dan bewerken. In HTTP termen, het meest voorkomende <em>werkwoord</em> was GET. Dat biedt mogelijkheden, want hoewel sommige pagina's gebruiker specifieke informatie bevatte, het meeste van de inhoud, en vooral ook de website voor het inloggen was voor iedereen hetzelfde. Ik had al vaker gebruik gemaakt van een Content Delivery Network (CDN) om media (plaatjes, videos, enzovoorts) sneller bij de bezoeker te brengen, waaronder Cloudflare. Amazon Web Services (AWS) heeft een eigen variant genaamd CloudFront, en zo zijn er nog velen. Wellicht kond ik hier gebruik van maken.</p>
<p>Alle CDNs hebben een variant van <em>caching</em>: het tijdelijk opslaan van informatie zodat je deze informatie niet opnieuw hoeft te berekenen of op te halen bij een opvolgend verzoek. Hoewel ze allemaal hun eigen implementatie hebben, ze ondersteunen (bijna) allemaal een gestandaardiseerde vorm: <a href="https://datatracker.ietf.org/doc/html/rfc9111"><em>HTTP Caching</em></a>. (Dit heet vaak <em>Origin Cache Control</em> mocht je het zoeken in jouw CDN). <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control">Het MDN artikel hierover</a> beschrijf veel van de opties, maar hier zijn er een aantal die wij gebruikten om de CDNs onze inhoud te laten cachen:</p>
<pre><code># Je mag de pagina echt niet cachen. Ook niet in de browser. Elk
# verzoek moet een nieuw antwoord genereren en tonen.
Cache-Control: no-store
</code></pre>
<pre><code># Bewaar dit voor 1 jaar in de cache. Dit wordt gebruikt voor
# bestanden met een hash / versie &quot;identifier&quot; die veranderd
# als het bestand wordt bijgewerkt, waardoor er een nieuwe
# url is.
#
# immutable zorgt ervoor dat browsers niet meer proberen
# conditionele verzoeken te doen om te kijken of de URL toch
# is bijgewerkt.
#
# public zorgt ervoor dat een verzoek's antwoord kan worden
# gedeeld. Oftewel: als iemand anders dit verzoek al heeft
# gedaan, dat kan dat gecachede antwoord worden gebruikt.
Cache-Control: public, max-age=31536000, immutable
</code></pre>
<pre><code># Bewaar dit voor 5 minuten, en markeer het daarna als muf.
# Dit wordt gebruikt voor paginas die niet elke seconde
# nieuwe informatie moeten laten zien, en waarbij het
# belangrijker is om wat oudere informatie te laten zien
# dan dat je niets laat zien.
#
## Dit is vaak waar, voor heel veel informatie op het
## internet!
#
## Gebruik het muffe opgeslagen antwoord nog maximaal 60
## seconden terwijl je op de achtergrond een vers antwoord
## ophaald. Gebruik het muffe opgeslagen antwoord nog een
## uur, als er een foutmelding is gegeneerd bij het ophalen.
Cache-Control: private, max-age=300, stale-while-revalidate=60, stale-if-error=3600
</code></pre>
<p>Ik kwam er ook achter dat sommige implementaties van HTTP Caching niet <em>spec-compliant</em> zijn. Ofwel: ze volgen niet de standaard. Cloudflare, bijvoorbeeld, respecteerd de <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary">Vary header</a> niet. Omdat ik wist dat er een standaard was en konden lezen wat de implicaties waren van het niet respecteren van deze header, hebb ik bewuste keuzes kunnen maken.</p>
<div class="note">Noot: Ga niet overal caching headers toevoegen. Vooral het gebruik van `max-age` op paginas die worden bijgewerkt kan problemen opleveren als je niet oplet dat dat verwijzingen naar oudere inhoud (zoals CSS en JavaScript bestanden) nog steeds werken tijdens </div>
<p>Oh en die performance? Bedenk je dat als je <code>public, max-age=60</code> toevoegt wat voor effect dat kan hebben op het aantal bezoekers op de server:</p>
<table>
<thead>
<tr>
<th>[Situatie]</th>
<th>[Bezoekers per minuut]</th>
<th>[Verzoeken per minuut]</th>
</tr>
</thead>
<tbody>
<tr>
<td>Geen caching</td>
<td>1000</td>
<td>1000</td>
</tr>
<tr>
<td><code>max-age=5</code></td>
<td>1000</td>
<td>~12</td>
</tr>
<tr>
<td><code>max-age=60</code></td>
<td>1000</td>
<td>~1</td>
</tr>
</tbody>
</table>
<p>Zelfs voor privé content die gemarkeerd was als <code>must-revalidate</code> (je moet de server vragen om te kijken of wat je in de cache hebt fris is of verouderd is), met een <code>max-age=0</code> (het antwoord is voor 0 seconden vers, en daarna muf), kan helpen. Als de server namelijk aangeeft dat wat de cache heeft nog steeds hetzelfde is (door middel van bijvoorbeeld een <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag">ETag vergelijking</a>) dan bespaar je nog steeds alle bandbreedte en tijd die het kost om die data te versturen en ontvangen.</p>
<p>Voordat ik dus een moeilijk uitdaging zelf probeer op te lossen kijk ik eerst of er een standaard voor bestaat. In dit geval was de oplossing die afdoende werkte de HTTP Caching standaard.</p>
<h3>c. Oude software accepteren terwijl de API (veel) is veranderd</h3>
<p>Dit is niet een frontend punt, maar full-stackers die bezig zijn met APIs schrijven of bedenken, kunnen hier wellicht ook iets aan hebben.</p>
<p>Het probleem is als volgt:</p>
<p>Ik schreef mee aan een systeem dat aan de server kant een API publiek beschikbaar stelde en die werd aangeroepen door allerlei andere systemen, waaronder een mobiele SDK (Software Development Kit). Zo'n SDK wordt dan onderdeel van één of meerdere apps en die apps worden gedistribueerd, meestal via de Google Play Store en Apple iTunes store. Dit betekent dat als er een wijziging nodig is in de API (in de server code), dat deze wijziging moet worden doorgevoerd in de SDK. De SDK update moet dan worden doorgevoerd in alle apps, en deze apps moeten worden gepubliceerd. Tot slot moeten de mensen die de app hebben geïnstalleerd de app bijwerken.</p>
<p>In andere woorden: je hebt een probleem, ofwel een moeilijke uitdaging!</p>
<p><a href="https://roy.gbiv.com/">Roy Fielding</a>, is een ontzettend slim persoon die heeft meegewerkt aan onder andere <a href="https://www.rfc-editor.org/rfc/rfc6570">URI Templates</a>, en was ook <a href="https://www.w3.org/TR/tracking-dnt/">editor van de &quot;Do No Track&quot; working group</a>. In 2013 zei Roy <a href="https://www.slideshare.net/evolve_conference/201308-fielding-evolve/31">tijdens een talk</a> dat de best practice voor het hanteren van een versie in een API is om <em>geen</em> versie te hanteren voor de gehele API. Ja, nou en, denk je misschien? Roy schreef zijn dissertatie over <a href="https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">Architectuur stijlen en het ontwerp van netwerk-gebaseerde software architectuur</a>. Wij kennen dit nu als <em>REST</em> (Representational State Transfer) en dat is eigenlijk de ruggengraat geworden van ontzettend veel moderne web interfaces.</p>
<p>Het leuke voor mij is dat Roy een vervolg heeft geschreven op zijn visie van REST, en dat heeft gepubliceerd als, jawel, een <a href="https://www.rfc-editor.org/rfc/rfc9205">RFC</a>, die is aangenomen als current best practice.</p>
<p>Ik zal niet teveel in details treden wat we hier allemaal van hebben gebruikt om ons probleem op te lossen, want dat is meerdere artikelen an sich, maar het komt samengevat neer op:</p>
<ul>
<li>Gebruik versies in media types (dus <code>application/vnd.fronteers.config.v1+json</code>);</li>
<li>Doe aan <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation">content-negotiation</a>: een tactiek waarbij de server kijkt naar de <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept">Accept header</a> van het verzoek en gebaseerd daarop een antwoord geeft met desbetreffende <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type">Content-Type header</a>;</li>
<li>Valideer antwoorden van de server in de server, en geef een foutmelding als het antwoord niet overeenkomt met een contract. In andere woorden: bepaal van te voren hoe een antwoord met een bepaalde <code>Content-Type</code> er uit gaat zien en forceer dat gedrag;</li>
<li>Ondersteun zo lang mogelijk een media type. Het is bijna altijd dezelfde informatie net iets anders gerepresenteerd, dus dit is vaak goedkoop om te doen. Je hoeft namelijk de code voor de oudere versies bijna nooit aan te raken.</li>
</ul>
<p>Om deze interessante uitdaging op te lossen kon ik dus gebruik maken van het denk werk van meerdere slimmen mensen (iedereen die heeft bijgedragen aan de RFC die uiteindelijk <em>best practice werd</em>) hetgeen er ook toe heeft geleid dat ik nu, vijf jaar later, nog steeds apps kan ondersteunen die versie 1 draaien van de API. Daarnaast konden de mobiele app developers <em>gradueel</em> upgraden: ze konden voor elk verzoek bepalen of ze het nieuwe gedrag wilden ondersteunen door met de <em>Accept</em> en <em>Content-Type</em> headers te spelen. Hier hebben een hele reeks web standaarden aan bijgedragen.</p>
<h3>d. Onenigheid over foutmeldingen</h3>
<p>Bij deze uitdaging was ik de frontender die een API moest gebruiken om een mobiele app én web applicatie te bouwen. Ik had invloed op de API omdat die werd geschreven door de klant! De uitdaging hier was drievoudig:</p>
<ol>
<li>De API gaf een <em>500 Server Error</em> als er iets mis ging, ook al was het een fout van mij.</li>
<li>De API gaf niet een consistente manier van fouten terug. Soms als een regel tekst (maar gemarkeerd als JSON, hoe dan?), soms als een JSON object met een key &quot;error&quot;, en soms weer wat totaal anders.</li>
<li>De API gaf foutmeldingen terug die niet duidelijk waren of niet hielpen bij het verhelpen van die foutmelding.</li>
</ol>
<p>Het eerste probleem was echt erg vervelend. Standaard schrijf ik mijn interactieve frontend code zo dat als het een <code>5xx</code> status code krijgt, dat ook echt wordt gezien als <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#server_error_responses">server gerelateerd probleem</a>. Bij het ophalen van informatie betekent dat ook dat ik automatisch nog een aantal pogingen deed. De klant klaagde erover dat ik &quot;veel verzoeken deed&quot;.</p>
<p><a href="https://httpwg.org/specs/rfc9110.html#status.500">RFC 9110</a> gaat over semantiek, waaronder ook de HTTP status codes. Omdat de foutcode 500 niet veel zegt en ook niet aangeeft of het een permanent of tijdelijk probleem is, en omdat de foutmeldingen in het antwoord ook niet hielp, koos ik ervoor om altijd opnieuw te proberen bij een 5xx code. Bij een 4xx code, hetgeen aangeeft dat er iets mis is met het verzoek zelf, deed ik dat niet.</p>
<p>Na ze te wijzen op de beschrijvingen in de standaard is de API bijgewerkt en gebruikt het zowel 4xx als 5xx codes, en dat was mooi, want het loste probleem 1 op en hielp ontzettend voor probleem 3.</p>
<p>Voor probleem 2 hadden we allebei geen goede ideeën. Uiteindelijk heb ik voorgesteld om een voorstel van iemand anders te gebruiken, en wel <a href="https://datatracker.ietf.org/doc/html/rfc7807">RFC 7807: Problem Details for HTTP APIs</a>.</p>
<p>Deze RFC introduceert een standaard formaat (geregistreerd met een media type <code>application/problem+json</code>) en hierdoor zien <em>alle</em> foutmeldingen er min of meer zo uit:</p>
<pre><code>HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en
{
&quot;type&quot;: &quot;https://example.com/probs/out-of-credit&quot;,
&quot;title&quot;: &quot;You do not have enough credit.&quot;,
&quot;detail&quot;: &quot;Your current balance is 30, but that costs 50.&quot;,
&quot;instance&quot;: &quot;/account/12345/msgs/abc&quot;,
&quot;balance&quot;: 30,
&quot;accounts&quot;: [&quot;/account/12345&quot;,
&quot;/account/67890&quot;]
}
</code></pre>
<p>In het kort:</p>
<ul>
<li><code>type</code> is altijd een URI die het type probleem identificeert. Het wordt sterk aangeraden om deze URI &quot;browsebaar&quot; te maken en dat deze wijst naar documentatie over de fout.</li>
<li><code>title</code> is een tekstuele samenvatting voor mensen! Deze kan worden vertaald door middel van <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation">Content-Negotiation</a> (aangeven welke talen je zou willen via <code>Accept-Language</code>, en de server kiest dan een ander antwoord gebaseerd op je verzoek).</li>
<li><code>detail</code>: is een tekstuele uitleg van het probleem, voor mensen! Dus geen computer bliep-die-bloep of SQL statements, of een <em>verbatim</em> foutmelding.</li>
<li><code>instance</code>: is een URI voor dit specifieke geval van deze fout.</li>
</ul>
<p>Doordat de <code>title</code> en <code>detail</code> velden verplicht zijn, werd de klant nu ook verplicht om de API betere foutmeldingen te laten geven (en hier heb ik ook bij geholpen).</p>
<p>Tot slot konden ze ook nog gradueel hun API bijwerken, omdat ik kon zien of iets in het juiste formaat zou moeten staan door de <code>Content-Type</code> van de foutmelding.</p>
<p>In dit geval heb ik dus meerdere standaarden gebruikt om tot een besluit te komen waarbij iedereen weet waar ze aan toe zijn, en anders dan &quot;hier is een idee, dit is al uitgewerkt&quot; hoefde ik het niet te beargumenteren, want het alternatief was de status quo die niet werkbaar was.</p>
<h3>e. Toegankelijke emails?</h3>
<p>Tot slot heb ik een voorbeeld waarbij een klant graag wilde dat ik een nieuwe gebruikersoptie implementeerde. Deze klant gaf aan dat leden niet allemaal de nieuwsbrief en updates konden lezen die per e-mail werden verstuurd.</p>
<p>Het verzoek was:</p>
<blockquote></blockquote>
<p>Het was relatief makkelijk voor mij om dit verzoek in te willigen, en zo gezegd, zo gedaan.</p>
<p>Twee weken later kreeg ik een belletje dat de oplossing niet werkte. Waarom niet? Een van de leden had in het profiel de e-mail op tekst gezet, maar klaagde nu dat de email overal alleen maar tekst was.</p>
<p>Wat was het echte probleem? Deze persoon gebruikte een tekst-only email client op sommige apparaten en kon HTML emails wel aan op andere apparaten. Ook gaf deze persoon aan dat dit probleem zich wel vaker voor deed, maar liet ook een paar voorbeelden zien van e-mails die het op alle apparaten correct deden.</p>
<p>Ik ben op zoek gegaan naar de webstandaard, want als meerdere applicaties allemaal het correcte gedrag laten zien, moet er bijna wel een standaard aan te pas zijn gekomen.</p>
<p>De oplossing vond ik in <a href="https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1.4">RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two</a>. Hierin staat beschreven hoe e-mails in elkaar zitten en hoe e-mail <em>readers</em> ze moeten behandelen. Hierin is ook beschreven hoe een speciale mediatype <code>multipart</code> kan worden gebruikt om een bericht te maken dat uit meerdere delen bestaat, en in het bijzonder <code>multipart/alternative</code>.</p>
<div class="note">Noot: `Multipart/alternative` may be used, for example, to send a message in a fancy text format in such a way that it can easily be displayed anywhere.</div>
<p>En dat was ook exact wat de e-mails deden die het lid liet zien.</p>
<pre><code>From: sender@example.com
To: recipient@example.com
Subject: Multipart Email Example
Content-Type: multipart/alternative; boundary=&quot;boundary-string&quot;
--your-boundary
Content-Type: text/plain; charset=&quot;utf-8&quot;
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Platte tekst email hier! Dit wordt gebruikt
als text/html niet werkt.
--boundary-string
Content-Type: text/html; charset=&quot;utf-8&quot;
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
&lt;h1&gt;Woopdiedoo html werkt!&lt;/h1&gt;
&lt;p&gt;Hier dan de HTML variant&lt;/p&gt;
--boundary-string--
</code></pre>
<p>Het was eenvoudig om de instelling weer weg te halen uit het gebruikersprofiel, en alle emails automatisch ook als platte tekst te laten zien.</p>
<p>Helaas is er niet veel meer ondersteuning dan <code>text/plain</code> en <code>text/html</code>, maar onlangs heeft Apple een nieuwe variant geïntroduceerd die <code>text/watch-html</code> gebruikt. Dit is speciaal voor de Apple Watch!</p>
<p>Enfin, de makkelijke oplossing hier was uiteindelijk niet de juiste. Hierbij was het dus zo dat de standaard veel meer gebruikscasussen had dan mijn simpele implementatie.</p>
<h2>Webstandaarden voor Fronteers</h2>
<p>Pakweg 2300 woorden verder en ik vertel je nu dat je al gebruik maakt van webstandaarden. En dan heb ik het niet eens over HTTP, of tools die gebruik maken van standaarden zoals formatters en linters.</p>
<h2>Produceer je HTML?</h2>
<h2>Schrijf je CSS?</h2>
<p>Dan heb je te maken met de vele CSS specificaties zoals <a href="https://www.w3.org/TR/mediaqueries-3/">mediaqueries</a>, <a href="https://www.w3.org/TR/selectors-3/">selectors</a>, en het <a href="https://www.w3.org/TR/css-box-3/">box-model</a>;</p>
<p>Interactiviteit via een taal zoals JavaScript of TypeScript?
Je houdt je waarschijnlijk zoveel mogelijk aan de <a href="https://www.ecma-international.org/publications-and-standards/standards/ecma-262/">ECMAScript standard</a>;</p>
<h2>Roep jij een API aan in JavaScript?</h2>
<p>Het is dan handig om te weten dat er een standaard is voor <a href="https://fetch.spec.whatwg.org/"><code>fetch</code></a> en ook voor <a href="https://xhr.spec.whatwg.org/"><code>xhr</code> (XMLHttpRequest)</a>;</p>
<h2>Bestanden uploaden via een formulier?</h2>
<p>Dan gebruik je <a href="https://www.ecma-international.org/publications-and-standards/standards/ecma-262/"><code>multipart/form-data</code></a></p>
<h2>Stuur je e-mails?</h2>
<p>Hallo daar <a href="https://www.rfc-editor.org/rfc/rfc5321.html"><em>S</em>imple <em>M</em>ail <em>T</em>ransfer <em>P</em>rotocol</a>. Lezen kan bijvoorbeeld via het oude <a href="https://tools.ietf.org/html/rfc1939"><em>P</em>ost <em>O</em>ffice <em>P</em>rotocol</a> of via het <a href="https://www.rfc-editor.org/rfc/rfc3501.html"><em>I</em>nternet <em>M</em>essage <em>A</em>ccess <em>P</em>rotocol</a>. De content en headers volgen <a href="https://www.rfc-editor.org/rfc/rfc2822">RFC 2822: Internet Message Format</a>, DomainKeys Identified Mail (DKIM) is <a href="https://www.rfc-editor.org/rfc/rfc6376">RFC 6375</a>, en het sturen van een e-mail als <em>zowel</em> HTML <em>als</em> platte tekst is mede mogelijk gemaakt door <a href="https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1.4"><code>multipart/alternative</code></a>.</p>
<h2>Te maken met 3D graphics?</h2>
<p>De standaard die je gebruikt is waarschijnlijk beschreven en onderhouden door de <a href="https://www.khronos.org/developers">Khronos Group</a></p>
<h2>Testen op toegankelijkheid?</h2>
<p>Je volgt hoogstwaarschijnlijk de <em>Web Content Accessibility Guidelines</em>, zoals beschreven in <a href="https://www.w3.org/TR/WCAG21/">de specificatie</a> van het W3C (World Wide Web Consortium).</p>
<p>Bovenstaande is maar een klein onderdeel van de vele vele standaarden waar je al met regelmaat gebruik van maakt, waar je op bouwt, waar je van profiteert. Hoe URLs werken, en wat de regels zijn voor een e-mail adres.</p>
<h2>Meedoen met het ontwikkelen van ons WWW</h2>
<p>Interesseert dit alles je en heb je ideeën over het web door-ontwikkelen? Ben je ergens tegen aan gelopen die een huidige standaard niet beschrijft? Er zijn ontzettend veel manieren om mee te doen.</p>
<ol>
<li>Veel van de organisaties die standaarden ontwikkelen en onderhouden kan je terug vinden op sites als GitHub.com. Voorbeelden hiervan zijn het <a href="https://github.com/w3c">WC3</a>, <a href="https://github.com/WICG">WICG</a>, <a href="https://github.com/whatwg">WhatWG</a> en <a href="https://github.com/tc39">TC39</a>. Ze hebben allemaal andere regels en richtlijnen, veelal beschreven in hun README en/of Code of Conduct. Dit is een van de eenvoudigste manieren om te zien welke discussies op dit moment leven.</li>
<li>Het WC3 heeft <a href="https://www.w3.org/">een eigen website</a>. Hier kan je alle werkgroepen en ander-soort samenkomen vinden. Lid worden van een groep is vaak ontzettend eenvoudig en als je het eenmaal bent, ben je vaak direct van harte welkom bij veel van de discussies.</li>
<li>De Web Incubator Community Group (WICG) heb ik nog niet genoemd. Deze groep ontwikkeld voorstellen voor nieuwe <em>features</em>! Je kan veel van deze features terug vinden op <a href="https://wicg.io/">hun website</a>, alsmede een link naar hun Discourse.</li>
<li>Dan hebben we de Web Hypertext Application Technology Working Group (WHATWG). Deze groep onderhoudt en ontwikkelt de HTML standaard! Hoe je daar mee aan kan doen staat uitgelegd op <a href="https://whatwg.org/">hun website</a>.</li>
<li>Voor JavaScript (en gerelateerde) is er <a href="https://tc39.github.io/ecma262/">de TC39 standaard</a>. De website zelf geeft aan dat eigenlijk alle contributies lopen via <a href="https://github.com/tc39/ecma262">hun GitHub</a>, maar er staat wel wat extra informatie op de website.</li>
</ol>
<h2>Is onderdeel worden van zo'n groep dan de enige manier?</h2>
<p><em>NEE!</em>. Je kan als individu reageren op issues, nieuwe voorstellen indienen, maar ook deelnemen aan evenementen gehost door de IETF. Er is een <a href="https://datatracker.ietf.org/">Datatracker</a> die <em>alle</em> voorstellen (aangenomen, klad, verlopen, enzovoorts) bijhoudt en beschrijft welke vragen open staan. Ook kan je hier terug vinden wanneer het volgende synchrone moment is om vragen te stellen over zo'n voorstel. Zelf heb ik hier een aantal keer aan meegedaan.</p>
<p>Er zijn leden van Fronteers die actief meewerken aan of hebben meegewerkt aan voorstellen van specificaties. Zij kunnen je waarschijnlijk net als ik vertellen dat dit niet altijd zonder <em>uitdagingen</em> gaat. Ontwikkeling duurt vaak lang en consensus bereiken is niet altijd mogelijk. Het zijn relatief logge machines. Aan de andere kant is het wel zo dat alles waar wij digitaal, online van genieten mede mogelijk is gemaakt door deze standaarden.</p>
<h2>Tot slot</h2>
<p>Door het gebruik van webstandaarden was het voor ons mogelijk om voor een klant met behulp van 5 developers in totaal (in de hele stack) een applicatie neer te zetten met meer dan 15 miljoen requests elke avond, 2.2 TB data per dag, met een <em>gemiddelde (en mediaan)</em> laadtijd van 35 ms gebruikmakende van één (relatief krachtige) server.</p>
<p>Door het gebruik van webstandaarden konden we tegen een andere klant zeggen: &quot;Jullie hebben klanten die screenreaders gebruiken? Dat is geen probleem. Daar zijn geen extra kosten aan verbonden.&quot; waarna ze erachter kwamen dat vrijwel de hele applicatie al enigszins tot goed toegankelijk was.</p>
<p>Door het gebruik van webstandaarden kunnen we veel eindeloze discussies voorkomen omdat we (bijna) altijd iets hebben om op terug te vallen en naar te refereren, en zo ook achterhalen of er een programmeer- of denkfout zit in onze code, of dat er een fout is gemaakt bij het <em>implementeren van een specificatie</em> in bijvoorbeeld een browser.</p>
<p>Ook jij gebruikt webstandaarden en dat is slim, dus ga zo door.</p>
</content>
</entry>
<entry>
<title>De slimmigheden in de standaardstylesheets van browsers</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/de-slimmigheden-in-de-standaardstylesheets-van-browsers"/>
<updated>2022-12-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/de-slimmigheden-in-de-standaardstylesheets-van-browsers</id>
<content xml:lang="nl" type="html"><p>Een marge van 8px om je hele pagina, koppen zijn uit zichzelf al groter en wie heeft dat afgrijselijke lettertype uitgekozen? Een &quot;ongestijlde pagina&quot; is stiekem helemaal niet zo ongestijld, maar bevat een flinke bak styling. Waar komt die stijl vandaan?</p>
<h2>Standaard browser stylesheets</h2>
<p>Die stijl komt uit de standaard browser stylesheets: CSS die je browser automatisch toevoegt aan iedere pagina. In tegenstelling tot wat je misschien verwacht staat deze standaard stijl letterlijk in CSS bestanden die de browser voor iedere pagina inlaadt:</p>
<ul>
<li>Gecko (Firefox): https://searchfox.org/mozilla-central/source/layout/style/res/html.css</li>
<li>Chromium (Chrome, Polypane e.a.): https://github.com/chromium/chromium/blob/main/third_party/blink/renderer/core/html/resources/html.css (Met wat extra CSS bestanden, bijvoorbeeld voor selectmenu, in hetzelfde mapje!)</li>
<li>Webkit (Safari): https://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css</li>
</ul>
<p>Iedere browser heeft zijn eigen standaard CSS en daar staan een hoop interessante dingen in. Hoewel dit geen geschiedenisles is, is het goed om te vermelden dat voor een lange tijd de stijl van elementen geen deel uitmaakte van de HTML specificatie. Iedere browser kon dus doen wat 'ie wilde.</p>
<p>Gelukkig probeerden browsers steeds meer hetzelfde te renderen (onder druk van web standards fanaten, bijvoorbeeld met de Acid en Acid2 tests) waardoor dit minder een probleem werd, en met <a href="https://www.w3.org/TR/CSS2/sample.html">HTML4</a> en later <a href="https://html.spec.whatwg.org/multipage/rendering.html">HTML5</a> werd een hoop van de standaard browser stylesheet vastgelegd.</p>
<p>Enfin, geen geschiedenisles dus. Maar als je nou echt wilt weten waarom er 8px marge op de <code>body</code> zit, heeft Miriam Suzanne <a href="https://www.miriamsuzanne.com/2022/07/04/body-margin-8px/">dat voor je uitgezocht</a>.</p>
<p>Wat we wel gaan doen is kijken wat voor interessante, slimme dingen er in die standaard stylesheets zit. De CSS die daar in staat kan namelijk precies geschreven worden op de capaciteiten van de browser, en per definitie hebben ze dus altijd toegang tot de meest nieuwe features in browsers. De stylesheets worden ook actief bijgehouden: de CSS van Webkit is voor het laasts op 16 juni dit jaar aangepast, die van Gecko op 16 september en Chromium voor het laatst ...twee uur geleden (9 november)!</p>
<h2>Dus dat voor leuke dingen staan er in?</h2>
<p>Voor het gemak slaan we de &quot;CSS Reset&quot; achtige dingen over. De standaard stylesheets voegen <code>display: none</code> en <code>display: block</code> toe op alle elementen die dat nodig hebben (en <code>display: table</code> op tables!) en tekstgroottes worden allemaal in <code>em</code> gezet zodat ze automatisch meeschalen. Dat is allemaal niet super spannend, dus gaan we niet verder op in.</p>
<h2>Logical properties</h2>
<p>Alle marges in een document zoals die boven en onder koppen en het inspringen van <code>ul</code>s en <code>blockquote</code>s komen uit deze standaard stylesheet. Maar in plaats van <code>margin-top</code> en <code>margin-bottom</code> gebruiken ze andere CSS properties: &quot;logical properties&quot;.</p>
<p>In plaats van <code>margin-bottom</code> gebruiken ze <code>margin-block-end</code> en in plaats van <code>margin-left</code> gebruiken ze <code>margin-inline-start</code>.</p>
<table>
<thead>
<tr>
<th>'oude' margins</th>
<th>Logical properties (voor NL)</th>
</tr>
</thead>
<tbody>
<tr>
<td>margin-top</td>
<td>margin-block-start</td>
</tr>
<tr>
<td>margin-bottom</td>
<td>margin-block-end</td>
</tr>
<tr>
<td>margin-left</td>
<td>margin-inline-start</td>
</tr>
<tr>
<td>margin-right</td>
<td>margin-inline-end</td>
</tr>
</tbody>
</table>
<p>Logical properties gebruiken niet de absolute richtingen top, right, bottom en left, maar block voor de flow richting en inline voor de tekst richting (in latijnse talen respectievelijk van boven naar beneden en van links naar rechts).</p>
<p>Het voordeel van deze logical properties is dat ze automatisch meeveranderen met de leesrichting van de pagina. In een pagina in het Arabisch staat <code>margin-inline-start</code> dus aan de rechterkant, niet aan de linkerkant. Dat scheelt weer typen.</p>
<h2><code>:is()</code> en <code>:-webkit-any()</code></h2>
<p>Voordat <code>:is()</code> er was, heette het <code>:matches()</code> en daarvoor heette het <code>:-moz-any()</code>/<code>:-webkit-any()</code>. Die laatste werd al in 2010(!) aan Firefox 4 toegevoegd als een manier om delen van selectors te groeperen, en het heeft dus een flinke tijd geduurd voordat we dat allemaal in ons dagelijkse leven konden gebruiken.</p>
<blockquote>
<p>Wil je daar meer over lezen? Check :where() :is() :has()? New CSS selectors that make your life easier</p>
</blockquote>
<p>De browsers zelf gebruiken het echter al een hele tijd. In HTML5 bestond het &quot;document outline algoritm&quot; en onderdeel daarvan was dat je meerdere H1s kon gebruiken als die maar telkens in een nieuwe section of article stonden. De browser zou ze dan magisch omtoveren tot H2, H3 enz.</p>
<p>Nu is dat algoritme er nooit gekomen, maar de stijl ervoor wel, en die zit er nog steeds in. Zo wordt de stijl voor de <code>h2</code> met de volgende selector beschreven:</p>
<pre><code>h2,
:is(article, aside, nav, section) h1 {
/* */
}
</code></pre>
<p>Hierdoor ziet de h1 in een article, aside, nav of section er dus hetzelfde uit als een H2. En hoe denk je dat ze dat met 4 niveau's diep geneste sections doen? Inderdaad, vier keer hetzelfde achter elkaar:</p>
<pre><code>h4,
:is(article, aside, nav, section)
:is(article, aside, nav, section)
:is(article, aside, nav, section)
h1 {
}
</code></pre>
<p>De grote vraag is nu of ze, met het verdwijnen van het algoritme, ook deze stijl weer weg gaan halen. Zoals je kan bedenken is het aanpassen van de standaard browser stijl niet zonder gevaren, en browsers mogen de miljoenen bestaande websites niet kapot maken. We gaan het zien.</p>
<p>Oh en die <code>:-webkit-any()</code>, die vinden we enkel nog terug in de CSS van Chromium. Gecko en Webkit zijn al overgestapt op <code>:is()</code>. 💪</p>
<h2>Case insensitive attribute matching</h2>
<p>Alle stylesheets maken uitgebreid gebruik van attribute selectors om bijvoorbeeld verschillende input types mee te selecteren, maar in het chromium stylesheet staat daar overal een &quot;i&quot; achter:</p>
<pre><code>input[type=&quot;search&quot; i] {
-webkit-appearance: searchfield;
box-sizing: border-box;
}
</code></pre>
<p>Die &quot;i&quot; kan je toevoegen om <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors#syntax">&quot;case insensitive&quot; te matchen</a>. Ongeacht of het attribuut hoofdletters of kleine letters gebruikt dus. Wanneer je geen controle hebt over hoe een attribuutwaarde geschreven is (bijvoorbeeld in een standaard stylesheet) kan dit handig zijn om toe te voegen en ook al gebruiken de andere browsers het niet in hun standaard stylesheet, ze ondersteunen het wel.</p>
<h2>Met CSS de alt tekst laten zien</h2>
<p>Wanneer een afbeelding niet geladen is laat de browser in plaats daarvan de alt tekst zien. Je verwacht misschien dat browsers hier in hun engine wat voor doen, maar Firefox lost dit op met CSS:</p>
<pre><code>img::before {
content: -moz-alt-content !important;
}
</code></pre>
<p>Die <code>-moz-alt-content</code> is er ééntje die je zelf niet mag gebruiken, dat is een interne waarde. Maar het gaat er om hoe dit er voor zorgt dat de alt-tekst zichtbaar is als de afbeelding niet geladen kan worden: Afbeeldingen in browsers zijn &quot;replaced content&quot;, dat betekent dat de browser de afbeelding als het ware bovenop je website plakt. Form controls zijn hier een ander voorbeeld van.</p>
<p>En omdat het replaced content is, kan je dus ook geen pseudo-content (met <code>::before</code>of <code>::after</code>) toevoegen aan afbeeldingen. Die worden door de browser genegeerd. Dus als de afbeelding werkt, doet deze CSS niks. Maar als de afbeelding niet geladen kan worden, wordt er niks <em>replaced</em> en werkt de pseudo content dus wel. En ziedaar: de alt tekst verschijnt.</p>
<h2>Vreemde code</h2>
<p>Ook staan er een aantal ongewone dingen in de stylesheets:</p>
<h2>Quirky ems</h2>
<p>Als je in de Chromium en Webkit stylesheets kijkt zie je daar een CSS unit die je waarschijnlijk niet kent: <code>__qem</code>. Die hoef je ook helemaal niet te kennen, maar Webkit (en Chromium, die daar op gebaseerd is) gebruikt deze eenheid om de juiste marges toe te kunnen passen in quirks mode. Heb je niks aan, maar leuk feitje om op de volgende Fronteersbijeenkomst te delen.</p>
<h2>internal-light-dark()</h2>
<p>In de stylesheet van Chromium zie je soms waar kleuren worden gedefinieerd een interessante CSS functie: -internal-light-dark() met twee waardes:</p>
<pre><code>input[type=&quot;range&quot; i] {
color: -internal-light-dark(#101010, #ffffff);
}
</code></pre>
<p>Deze functie kiest één van de twee kleuren afhankelijk van of er light of darkmode gebruikt wordt in de browser. Dat is een stuk compacter dan we momenteel met media queries kunnen doen:</p>
<pre><code>@media (prefers-color-scheme: light) {
input[type=&quot;range&quot; i] {
color: #101010
}
}
@media (prefers-color-scheme: dark) {
input[type=&quot;range&quot; i] {
color: #ffffff
}
}
</code></pre>
<p>Wie weet wordt deze functie in de toekomst ook voor ons gewone developers beschikbaar.</p>
<h2>Namespaces in CSS?</h2>
<p>Alle drie de stylesheets beginnen met dezelfde regel:</p>
<p>@namespace &quot;<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>&quot;;</p>
<p>Waarschijnlijk heb je dit nog nooit zelf toegevoegd (en dat hoeft ook niet), maar door deze regel weet je browser dus welke elementen je bedoeld met <code>body</code>, <code>div</code> en <code>p</code>, namelijk die uit de HTML namespace. Maar hoe komt het dan dat SVG elementen zoals <code>path</code> en <code>g</code> stijlen ook werkt? Dat is een slimmigheid van de HTML5 specificatie: SVG (en MathML) zijn bekende &quot;foreign elements&quot; en die krijgen automatisch de juiste namespace. Bedankt HTML5!</p>
<h2>FIXME</h2>
<p>In de stylesheets van Chromium en Webkit staat een interessante comment:</p>
<pre><code>/* page */
@page {
/* FIXME: Define the right default values for page properties. */
size: auto;
margin: auto;
padding: 0px;
border-width: 0px;
}
</code></pre>
<p>Een FIXME klinkt vrij urgent toch? Ik heb het even opgezocht en deze comment staat er sinds 2010 in. Zo urgent is het dus niet.</p>
<h2>Jouw vondsten</h2>
<p>Tot zover mijn &quot;deep dive&quot; door de standaard stylesheets van Chromium. Gecko en Webkit. Neem er vooral zelf ook een kijkje door en deel jouw vondsten in de reacties hieronder.</p>
</content>
</entry>
<entry>
<title>We leerden een steen hoe hij moest denken, maar nu heeft hij een paar bevooroordeelde meningen…</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/we-leerden-een-steen-hoe-hij-moest-denken-maar-nu-heeft-hij-een-paar-bevooroordeelde-meningen"/>
<updated>2022-12-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/we-leerden-een-steen-hoe-hij-moest-denken-maar-nu-heeft-hij-een-paar-bevooroordeelde-meningen</id>
<content xml:lang="nl" type="html"><p>Tegenwoordig kom je ze op steeds meer websites en in (web)applicaties tegen: Algoritmes. Complexe berekeningen op basis van een tal van datasets die samen het perfecte antwoord weten op jouw vraag, probleem of behoefte! Je komt ze tegen als je een film wilt kijken op Netflix, wanneer je een antwoord zoekt op Google en zelfs wanneer je je belastingaangifte doet! Deze kleine helpertjes zitten overal verstopt en zijn natuurlijk een geweldige oplossing voor automatisering, want een computer kan geen mening hebben, toch?</p>
<h2>Wat is een algoritme?</h2>
<p>Simpel gezegd is een algoritme een aantal vooraf ingestelde regels die helpen bij het komen tot een resultaat. We gebruiken dan ook al decennialang een vorm van algoritmes, we zijn ze alleen sinds kort gaan associëren met technologie. En hoewel algoritmes in de breedste zin interessant zijn, gaan we het hier vooral hebben over algoritmes in de context van onze steeds sneller groeiende tech wereld.</p>
<p>Algoritmes vergemakkelijken ons leven steeds meer, we krijgen content te zien op onze sociale media kanalen die ons interesseert, we komen sneller bij een nieuwe film op Netflix uit die op basis van onze kijkgeschiedenis goed bij ons past en zelfs in de medische wereld wordt geëxperimenteerd met het gebruik van algoritmes om zo sneller tot een voorlopige diagnose van een patiënt te komen! Echter is het niet altijd rozengeur en maneschijn in de wereld van algoritmes en zijn er zelfs redenen om de ontwikkelingen in de techniek slecht te noemen.</p>
<h2>Maar… Waarom zijn algoritmes dan slecht?</h2>
<p>Niet alle algoritmes zijn slecht, ze zijn in ieder geval veelal niet ontwikkeld met kwade bedoelingen, maar toch is dat vaak wel een onbedoelde uitkomst. Algoritmes worden gevoerd met data die verzameld wordt vanuit allerlei verschillende bronnen, dit kan data zijn op basis van het gebruik van platformen zoals bijvoorbeeld Youtube of Twitter, maar het kan ook op basis van de resultaten van een onderzoek zijn. Deze data kan om allerlei redenen onbewuste vooroordelen bevatten van degene die deze data verzamelt heeft, of op een andere manier beïnvloed worden door een geschiedenis van vooroordelen.</p>
<p>Een waargebeurd voorbeeld is als volgt:</p>
<p>Een bedrijf gebruikt een algoritme om zijn sollicitatieprocedure te verbeteren. Het algoritme krijgt hierbij een aantal succesvolle sollicitaties en een aantal niet succesvolle sollicitaties voorgeschoteld op basis van sollicitatieprocedures in de voorgaande jaren om hiervan te leren welke kandidaten bij het bedrijf passen. In theorie klinkt het als een mooie oplossing waardoor geen enkele kandidaat wordt afgewezen vanwege een oneerlijke mening van de recruiter, maar niets is minder waar. In het bedrijf werken namelijk grotendeels witte cis hetero mannen, een (onbewuste) keuze van de recruiters die in het verleden dit werk uitvoerde. Het algoritme wordt dus vanaf stap 1 gevoerd met data die in zijn kern al vol vooroordelen zit. Een systeem dat gevoerd word met data waarin een bepaald soort mens positiever uit de verf komt, zal datzelfde soort mens dan ook voorrang geven in de selectieprocedure.</p>
<h2>Wat kan <em>ik</em> er aan doen?</h2>
<p>Er zijn verschillende manieren om het gebruik van algoritmes te verbeteren, hieronder verdeel ik ze tussen wat je er als developer aan kunt doen en ook wat je er als gebruiker aan kunt doen. Een tip die in ieder geval voor beide groepen geldt is: Lees je in over het onderwerp!</p>
<h2>Wat kan ik als developer die met algoritmes werkt doen?</h2>
<ul>
<li>Zorg ervoor dat de data die je gebruikt om jouw algoritme te trainen uit een divers aanbod bestaat. Gebruik data uit meerdere bronnen waarvan ook vast te stellen is dat er diverse kandidaten deel waren van het onderzoek en/of de data die passief verzamelt is.</li>
<li>Betrekt zoveel mogelijke diverse kandidaten, maar ook mede developers in het process! Je hoeft natuurlijk niet als een soort pokemons van elke soort 1 te vangen, maar hoe meer ogen van verschillende achtergronden je kunt betrekken bij de ontwikkeling, hoe sneller ongewilde vooroordelen in de kiem gesmoord kunnen worden.</li>
<li>Let goed op of de data die je gebruikt stereotyperend kan zijn! Denk hierbij aan het voorbeeld van een algoritme wat getraind is op historische data van vooral witte cis hetero mannen, zorg ervoor dat je dit soort data sets vermijd of op zijn minst voorziet van een bepaalde context.</li>
</ul>
<h2>Wat kan ik als gebruiker van platformen met algoritmes doen?</h2>
<ul>
<li>Wees alert op de content waar je actief een reactie op geeft. Wees je daarbij bewust van het feit dat reageren op berichten die negatieve informatie delen het algoritme verteld dat jij (en potentieel anderen) deze content reactie waardig vinden en dus meer aandacht/een hogere positie verdient.</li>
<li>Ga bewust met je data om. Je hoeft geen digitale hermit te worden, maar denk goed na wanneer je informatie over jezelf online met een platform deelt, jouw informatie kan onbedoeld gevoed worden aan een algoritme.</li>
<li>Maak anderen bewust van de algoritmes die bestaan en deel ook tips over het vermijden van schadelijke algoritmes, hoe meer bewustwording er gecreëerd wordt hoe moeilijker het zal zijn voor bedrijven om algoritmes op een negatieve manier in te zetten.</li>
</ul>
<h2>Moeten we algoritmes dan helemaal afzweren?</h2>
<p>Algoritmes helemaal afzweren, dat hoeft zeker niet. Zolang we bewust en ethisch omgaan met de data die we gebruiken en de data die we over onszelf delen kunnen we samen hele mooie dingen maken. Wat zou het mooi zijn als we op een inclusieve en verantwoorde manier mensen sneller kunnen helpen bij bijvoorbeeld het vinden van een baan of werknemer, hulp bij medische problemen, maar ook zoiets simpels als het ontdekken van die nieuwe artiest wiens muziek je helemaal blij maakt! Al met al maken algoritmes ons leven makkelijker en hebben ze de potentie om veels goeds te doen voor technologische en sociale ontwikkelingen, maar dan moeten we wel allemaal ons steentje bij dragen.</p>
</content>
</entry>
<entry>
<title>Hoe ik mezelf leerde werken met Webflow + tips! (hoe jij jezelf iets nieuws kan leren)</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/hoe-ik-mezelf-leerde-werken-met-webflow-tips-hoe-jij-jezelf-iets-nieuws-kan-leren"/>
<updated>2022-12-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/hoe-ik-mezelf-leerde-werken-met-webflow-tips-hoe-jij-jezelf-iets-nieuws-kan-leren</id>
<content xml:lang="nl" type="html"><p>Toen Nederland in maart 2020 in lockdown ging, ben ik begonnen met leren coderen. Dit deed ik elke dag. Dat wierp zijn vruchten af want uiteindelijk kreeg ik een baan als developer.</p>
<p>Maar nog steeds maak ik elke dag tijd om te leren. Soms maar 15 minuten en soms wel een paar uur. Ondertussen ben ik het wel gewend om dagelijks bezig te zijn met leren coderen en is het een gewoonte geworden. Een goede gewoonte, want in onze branche is leren een vaardigheid die je veel gebruikt. Het is belangrijk om met de tijd mee te gaan en steeds weer wat nieuws te leren of het nu een andere werkwijze of een andere programmeertaal is.</p>
<p>Ik leer niet alleen in mijn vrije tijd, maar ook tijdens mijn werk besteed ik tijd aan leren. Zoals het CMS</p>
<h2>Webflow.</h2>
<p>Webflow is een platform, waarmee je websites kan maken. Daarbij gebruik je geen code maar werk je met een visueel canvas, waarin je als developer zelf een website op maat maakt door te slepen, klikken en typen. Je hebt dezelfde vrijheid wanneer je het zelf zou programmeren.</p>
<p><img src="https://www.fronteers.nl/_img/blog-rosita.jpg" alt="De editor in Webflow met links de instellingen van de website en het overzicht van alle gebruikte elementen op de huidige pagina, in het midden hetgeen dat je aan het maken bent en rechts het menu met instellingen van het geselecteerde element." /></p>
<p>De editor in Webflow, hier met een cloneable template gemaakt door Finsweet.</p>
<p>Zelf heb ik voornamelijk ervaring met het maken van websites met WordPress. <a href="https://www.websitebezorgd.nl/post/wat-is-webflow">Op mijn werk wordt er al een tijd gewerkt met Webflow</a>. Daarom leer ik nu te werken met dit CMS. Webflow werkt heel anders en zit anders in elkaar. WordPress moet je op een server installeren. Terwijl je Webflow in je browser kunt gebruiken en je hier geen aparte hosting voor nodig hebt.</p>
<p>Net als bij WordPress zijn er 1000 en 1 manieren om een website te bouwen. Elke developer heeft een eigen manier van werken. Dat komt de consistentie van de styling niet ten goede. Daarom is het handig om afspraken daarover te maken of bepaalde richtlijnen te volgen. Wij gebruiken daarvoor <a href="https://www.finsweet.com/client-first/docs">Client-First</a>, ontwikkeld door Finsweet. Client-First bestaat uit meerdere styleguides en methodes die zijn ontwikkeld om het bouwen van websites in Webflow makkelijker te maken.</p>
<p>Hoe ziet Client First er dan specifiek uit? In Client-First is de structuur en de opbouw van de pagina’s heel belangrijk. En is er een bepaald systeem om de classes een goede herkenbare naam te geven bijvoorbeeld <code>.section-home-hero</code>, voor de hero op de homepagina. Ook wordt er gebruik gemaakt van rem in plaats van pixels, met hier en daar een uitzondering. (bijvoorbeeld bij: <code>footer {border-top-width: 2px;}</code>).</p>
<div class="note">De naam Client-First betekent: 'We stellen de belangen van onze klanten voorop in het proces van het bouwen van een website in Webflow.'</div>
<p>Naast Client-First gebruiken we de <a href="https://library.relume.io/">Relume library</a>, een library met (heel veel!) verschillende componenten voor Webflow, die je in projecten kan gebruiken en aanpassen. Relume werkt ook goed samen met Client-First. Op deze manier kun je dus snel een mooie website neerzetten.</p>
<h2>Hoe ik leer Webflow te gebruiken</h2>
<p>Ik maakte een gratis starters account aan bij Webflow. Het is heel beperkt, maar goed genoeg om mee te oefenen. Toen ik voor het eerst de designer van Webflow zag, vond ik het nogal overweldigend. Je kunt er veel kanten mee op.</p>
<p>Gelukkig is er Webflow University. Hier kun je allerlei tutorials volgen om zo het CMS te leren kennen. De presentator is erg grappig by the way.</p>
<p>Om het platform beter te leren kennen, begon ik zelf een thema dat wij al op de plank hadden liggen, na te maken. Vervolgens ging ik verder met het volgen van tutorials door Finsweet op Youtube. En ook hierbij probeerde ik het pasgeleerde toe te passen tijdens het maken van mijn website in Webflow.</p>
<h2>Mijn tips om goed te kunnen leren</h2>
<p>De laatste jaren ben ik veel bezig geweest met leren. Ik heb voor mezelf ondertussen een manier gevonden die voor mij werkt:</p>
<p>Maak heel concreet wat je precies wilt leren.</p>
<p>Heel saai, maak je leerdoel zo SMART mogelijk. Je wordt er tijdens je opleiding niet voor niks mee dood gegooid. Mijn doel is: Aan het einde van dit jaar wil ik een maatwerkdesign kunnen bouwen in Webflow met behulp van Client-First.</p>
<h2>Herhalen</h2>
<p>Herhaal wat je hebt geleerd en pas het toe, dat werkt voor mij het beste. En ik denk maar zo: hoe vaker je iets herhaalt, hoe beter je erin wordt. De eerste keer dat ik een website moest verhuizen, ging dat niet goed. Maar hoe vaker ik het doe, hoe beter het gaat. Zo heb ik laatst succesvol een website verhuisd. Dat ging overigens niet geheel vlekkeloos, zoals gewoonlijk, maar ik heb het wel zelf kunnen oplossen.</p>
<h2>Regelmaat</h2>
<p>Neem regelmatig de tijd om te leren. Neem de tijd om bijvoorbeeld 2 keer in de week, of eens in de twee weken of net zoals ik elke dag even bezig te zijn met mijn online cursus op Codecademy. Plan die vaste momenten in.</p>
<h2>Pas toe wat je hebt geleerd</h2>
<p>Pas toe wat je hebt geleerd. Mijn ervaring is dat de stof die je hebt geleerd dan beter blijft hangen. Ik bekijk de tutorials over Client-First en Webflow, lees de documentatie van beiden en vervolgens probeer ik dat toe te passen in mijn project dat ik aan het bouwen ben in de designer.</p>
<p>Wanneer ik bezig ben om een website in WordPress te bouwen of dingen aan het doen ben in plain HTML en CSS, probeer ik de principes van Client-First toe te passen, waar dat mogelijk is. Je kunt namelijk prima het 4 pt systeem in rem toepassen in CSS. In WordPress kan dat ook, als het mogelijk is met het thema wat je gebruikt. Niet alle thema’s ondersteunen het gebruik van rem.</p>
<h2>Ga ermee aan de slag</h2>
<p>En als laatste: ga het gewoon doen. Als je te lang blijft hangen in het volgen van tutorials, leer je de dingen waar je tegenaan loopt, niet zelf op te lossen. Ga gewoon ermee aan de slag. Al doende leert men, en mijn ervaring daarbij is dat je het dan heel snel leert omdat het dan echt moet. Net als koken, als je net op jezelf bent gaan wonen. En hoe vaker je het doet, hoe beter het wordt, zoals ik eerder al schreef. En binnen de kortste keren ben jij een pro!</p>
</content>
</entry>
<entry>
<title>Nullish Coalescing en Optional Chaining</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/nullish-coalescing-en-optional-chaining"/>
<updated>2022-12-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/nullish-coalescing-en-optional-chaining</id>
<content xml:lang="nl" type="html"><p>Sinds ECMAScript 2020 zijn twee veelgevraagde features onderdeel geworden van de geliefde (en gehate) taal, JavaScript: de Nullish Coalescing operator en Optional Chaining. Beide zijn vooral <em>syntactical sugar</em>; een syntactische toevoeging voor iets wat we al konden schrijven, maar wel toevoegingen die welkom zijn, omdat ze code leesbaarder houden.</p>
<p>Beide features worden ondersteund door alle moderne browsers. Als je oude browsers moet ondersteunen, kan je ze nog steeds gebruiken door de code omzetten naar beter ondersteunde code middels compilers zoals TypeScript en Babel.</p>
<p>Voordat we deze nieuwigheidjes gaan verkennen, laten we eerst naar pre-ES2020 kijken zodat we begrijpen wat ze toevoegen.</p>
<h2>De Logical OR (<code>||</code>) operator</h2>
<p>De kans is groot dat je de Logical OR operator gebruikt hebt. Deze komt veel voor bij het omschrijven van (meerdere) condities in bijvoorbeeld <code>if</code> statements:</p>
<pre><code>// Als een product op voorraad is OF voorbesteld kan worden...
if (isInStock || isPreorderable) {
// Toon de bestelknop
}
</code></pre>
<p>Als je de naam van de operator en het voorbeeld ziet, wekt dit de indruk dat dit een operator voor twee booleans is. Als geen van de twee booleans <code>true</code> is, geeft de operator <code>false</code> terug. Als één of beide booleans <code>true</code> is, geeft het <code>true</code> terug. Deze beweringen kloppen, maar op een minder intuïtieve manier: het geeft de eerste waarde terug dat <em>truthy</em> is, en anders de laatste waarde. De operator werkt voor booleans, maar ook andere data types!</p>
<p>Omdat de logical OR operator één van de twee waardes terug geeft, ontstaat er een interessante eigenschap. Wanneer de waarde aan de linker kant <em>falsy</em> is (zoals een lege string), geeft de operator de rechter waarde terug. Dat kan erg handig zijn met fallback waardes:</p>
<pre><code>// Vul de variabel met de input waarde
// Als het veld leeg is, waardoor input.value een lege string is, vul met &quot;No name&quot;
const name = input.value || 'No name';
</code></pre>
<p>De flexibiliteit van deze operator is tevens het probleem. <em>Truthy</em> en <em>falsy</em> waardes zijn min of meer arbitrair en JavaScript doet aannames over specifieke waardes. Wellicht begrijp je dat <code>null</code> en <code>undefined</code> falsy waarden zijn. Een lege string (<code>&quot;&quot;</code>) en de cijfer nul (<code>0</code>) worden ook gezien als falsy waarden, ondanks dat die in sommige situaties gewenst zijn.</p>
<p>Stel, we maken het systeem om kaartjes te bestellen voor het Fronteers congres. Nadat iemand z’n bestelling heeft geplaatst, willen we het resterende aantal tickets bijwerken:</p>
<pre><code>ticketCount -= orderCount || 1;
</code></pre>
<p>Wanneer de gebruiker geen aantal opgeeft, bevat <code>orderCount</code> de waarde <code>null</code>, en anders een cijfer. Middels de OR operator doen we de aanname dat als gebruiker geen aantal heeft opgegeven, er één kaart besteld wordt. Alles lijkt te werken, totdat een gebruiker 9 kaartjes wilt bestellen, maar per ongeluk 0 invoert. Omdat 0 een falsy waarde is, word <code>ticketCount</code> verlaagd met de fallback waarde van 1. Het lijkt alsof er één kaart is besteld, ook al is dat niet zo.</p>
<p>Om dat geval af te vangen, moeten we specifieker zijn wanneer we de waarde als leeg achtten, zoals met een Ternary operator:</p>
<pre><code>ticketCount -= orderCount !== null ? orderCount : 1;
</code></pre>
<h2>De Nullish Coalescing (<code>??</code>) Operator</h2>
<p>Zoals we net zagen, zijn er gevallen waar we niet alle falsy waarden over één willen kam scheren, en bijvoorbeeld lege strings (<code>&quot;&quot;</code>) en het cijfer nul (<code>0</code>) behouden. Met de Nullish Coalescing operator, kan dat!</p>
<p>In principe werkt het nagenoeg hetzelfde als de Logical OR (<code>||</code>) operator, alleen geeft deze operator de linker waarde terug wanneer die niet <em>nullish</em> (<code>null</code> of <code>undefined</code>) is, en anders waarde rechts van de operator. Laten we het voorbeeld van ons bestelsysteem herzien met deze operator:</p>
<pre><code>ticketCount -= orderCount ?? 1;
</code></pre>
<p>Wanneer <code>orderCount</code> <code>null</code> is, geeft de operator de fallback waarde van 1 terug. Wanneer <code>orderCount</code> een cijfer bevat, ook nul (<code>0</code>), zal die waarde gebruikt worden.</p>
<p><code>x ?? y</code> is min of meer een shorthand voor de volgende expressie:</p>
<pre><code>x !== null &amp;&amp; x !== undefined ? x : y
</code></pre>
<p>Let op dat het gebruik van de Nullish Coalescing operator in een <code>if</code> statement verwarring kan veroorzaken.</p>
<pre><code>if (orderCount ?? false) {
// ...
}
</code></pre>
<p>Bovenstaande code herintroduceert hetzelfde probleem. Ook al zal de expressie <code>orderCount ?? false</code> werken zoals verwacht, indien <code>orderCount</code> 0 is, krijg je effectief <code>if (0)</code>, en zal de code niet uitgevoerd worden.</p>
<p>De Chaining (<code>.</code>) Operator</p>
<p>Misschien heb je wel eens JSON opgehaald via REST API en werd er conditioneel informatie teruggegeven, bijvoorbeeld o.b.v. een rol of rechten.</p>
<p>Stel, hebben een object ontvangen, <code>order</code>, en we willen de naam van de persoon uit een opdracht halen:</p>
<pre><code>const customerName = order.customer.name;
</code></pre>
<p>Wanneer <code>order</code> of <code>order.customer</code> bijvoorbeeld <code>null</code> is, geeft dit een error: <code>Uncaught TypeError: Cannot read properties of null</code>. Dit kan bijvoorbeeld gebeuren als een beheerder naar een bestelling wilt kijken, maar geen persoonsgegevens mag inzien.</p>
<p>We kunnen in meerdere stappen controleren of het veld, dat we uit willen lezen, bestaat. Misschien heb je wel eens dit soort code gezien of geschreven:</p>
<pre><code>const customerName = order
&amp;&amp; order.customer
&amp;&amp; order.customer.name;
</code></pre>
<p>Omdat deze situatie en daardoor dit soort controles vaak voorkomt, zijn er zelfs functies (zoals <code>[_.get()](https://lodash.com/docs/#get)</code> in lodash) geschreven en npm packages gepubliceerd om veilig informatie uit een onbekend object te halen zonder JavaScript errors te veroorzaken.</p>
<p>Voor een dynamische taal zoals JavaScript is het vreemd dat er geen ingebouwde manier is om veilig een object uit te lezen. Dat is verleden tijd dankzij de Optional Chaining operator!</p>
<h2>Optional Chaining ( <code>?.</code> )</h2>
<p>Optional Chaining maakt het uitlezen van object veel veiliger. We kunnen de Chaining operator (<code>.</code>) vervangen met deze nieuwe operator wanneer er onzekerheid is over het uit te lezen object. In andere programmeertalen is er een vergelijkbare operator die bekend staat als de Elvis operator (omdat die syntax, <code>?:</code> op twee ogen en een kuif lijkt).</p>
<p>Het voorbeeld van eerder kunnen we herschrijven naar:</p>
<pre><code>const customerName = order?.customer?.name;
</code></pre>
<p>Wanneer <code>order</code> of <code>order.customer</code> nullish is, krijgt <code>customerName</code> de waarde <code>undefined</code> in plaats van dat het een error veroorzaakt. We hoeven deze operator niet overal te gebruiken. Als we zeker weten dat <code>order</code> altijd een object is, is onderstaand voldoende:</p>
<pre><code>const customerName = order.customer?.name;
</code></pre>
<p>Ook kunnen we Optional Chaining combineren met Property Accessors (<code>obj['veld']</code>):</p>
<pre><code>const field = 'name';
const customerField = order.customer?.[field];
</code></pre>
<p>We kunnen met de operator ook de error <code>Undefined is not a function</code> voorkomen. Let op dat de Optional Chaining operator enkel controleert of een waarde niet-nullish is:</p>
<pre><code>const obj = {
myString: 'Not a function',
myFunction() {
// ...
},
};
//
// obj.myNullish is niet gedefinieerd in obj
obj.myNullish?.();
obj.myFunction?.();
// De waarde is niet nullish, maar proberen het aan te roepen als een functie, terwijl het een string is
obj.myString?.(); // Error: obj.myString is not a function
</code></pre>
<p>Dat we <code>undefined</code> terug krijgen wanneer een property niet bestaat, wat een nullish waarde is, betekent dat we dit kunnen combineren met de Nullish Coalescing operator!</p>
<pre><code>const customerOrderCount = order.customer?.orderCount ?? 'N/A';
</code></pre>
<p>Door deze operators te combineren, kunnen we code schrijven dat erg robuust is. Bovenstaande regel houdt niet alleen rekening met situaties wanneer <code>order.customer</code> of niet bestaat, bijvoorbeeld wanneer de gebruiker deze informatie niet mag zien, maar zal ook netjes nul teruggeven wanneer de klant nog geen orders heeft geplaatst. Elk alternatief is een stuk minder elegant:</p>
<pre><code>const customerOrderCount = (
order.customer &amp;&amp;
typeof order.customer.orderCount === 'number'
)
? order.customer.orderCount
: 'N/A';
</code></pre>
<h2>Conclusie</h2>
<p>Het komt vaak voor dat nieuwe ECMAScript features geen verandering betekenen voor de code die we dagelijks schrijven. Nullish Coalescing en Optional Chaining, daarentegen, wel.</p>
<p>De één is een zeer handige toevoeging voor het schrijven van condities en de ander om veilig objecten uit te lezen. Twee dingen die je vaak terug vindt in elke codebase van elk formaat. Ook al zijn het twee kleine operators, de impact is groot.</p>
</content>
</entry>
<entry>
<title>Een button ontwerpen, het lijkt zo simpel</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/een-button-ontwerpen-het-lijkt-zo-simpel"/>
<updated>2022-12-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/een-button-ontwerpen-het-lijkt-zo-simpel</id>
<content xml:lang="nl" type="html"><p>Een van de eerste zaken die ik in Adobe XD heb ontworpen, waren buttons voor het nieuwe design system van mijn werkgever. Onze producten bevatten vooral pagina’s met formulieren en daar horen buttons bij. In prototypes probeer ik die buttons zoveel mogelijk het gedrag mee te geven voor de uiteindelijke implementatie. In deze blogpost beschrijf ik mijn ervaringen met het maken van een button in Adobe XD, het gebruik ervan in prototypes en hoe bruikbaar de CSS is voor de ontwikkelaars.</p>
<h2>Een button ontwerpen</h2>
<p>Het ontwerp van een button begint met een rechthoek, een tekst en een icoontje op een artboard (een soort pagina). De rechthoek geef ik een witte achtergrond, een blauwe rand van 2 pixels en een schaduw. De hoeken van de rechthoek heb ik rond gemaakt met een border radius. Mijn button ziet er nu zo uit:</p>
<p><img src="https://www.fronteers.nl/_img/blog-jasha-1.png" alt="Ontwerp van een button. Een ovale witte knop met een blauwe rand. In de button een plus-icoon en de tekst Voeg toe" /></p>
<h2>Ontwerp van een button</h2>
<p>De rechthoek en tekst heb ik gegroepeerd en vervolgens een padding meegegeven. Voor tekstvlakken kun je de hoogte of breedte in Adobe XD flexibel maken zodat die automatisch schaalt als er meer of minder tekst in staat. Ik heb de breedte van het label flexibel gemaakt. In combinatie met de padding zorgt dat ervoor dat de button automatisch schaalt als ik het label aanpas.</p>
<p>Een button in HTML heeft verschillende states die de gebruiker van elkaar moet kunnen onderscheiden:</p>
<ul>
<li>standaard (default)</li>
<li>hover</li>
<li>focus</li>
<li>active</li>
<li>disabled</li>
</ul>
<p>Ook in Adobe XD kun je meerdere states aanmaken binnen een component. In dit geval heb ik voor de button een component aangemaakt met de bovenstaande vijf states. Elke state heeft een variant op de styling van de button, maar in de basis blijft het een vlak met een stuk tekst en dit vlak schaalt mee met de tekst.</p>
<h2>Interacties toevoegen</h2>
<p>Met Adobe XD kun je meer dan alleen statische pagina’s ontwerpen. Het ondersteunt ook interacties die je aan elke laag binnen je artboard kunt koppelen. Ik heb een interactie toegevoegd die vanaf de default naar de hover state van de button gaat als er met een muis overheen gaat. Dit komt overeen met het gedrag van een echte button in HTML. Ik heb nog twee interacties toegevoegd: de overgang naar de active state bij een “tap” (muisklik) en de overgang naar de focus state als de gebruiker op de tab toets drukt. Dit levert het volgende prototype op:</p>
<iframe src="https://player.vimeo.com/video/?texttrack=en" width="640" height="360" frameborder="0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen=""></iframe>
<p>De overgang tussen de standaard en de disabled state definieer ik niet als interactie binnen het component in Adobe XD. De disabled state heeft in het ontwerp wel een eigen uiterlijk: geen schaduw, grijze tekst en achtergrond.</p>
<h2>Verschillen met een echte button</h2>
<p>Het ontwerp van de button begint al redelijk te lijken op een echte button, maar er zijn wel wat verschillen. Deze verschillen zitten met name in de interacties die je in het prototype kunt maken voor de button, maar ook in de rendering.</p>
<p>Het eerste verschil zit in de focus state. Als een button focus heeft en de gebruiker vervolgens nog een keer de tab toets gebruikt, gaat de focus naar het volgende element op de pagina. Dat kan wel in Adobe XD maar is te omslachtig om in een prototype te verwerken.</p>
<p>Ik wilde de button een focusring meegeven. Deze focusring was in het ontwerp een tweede vlak met iets grotere afmetingen, maar daardoor versprong de button. Het is te begrijpen dat Adobe XD deze extra pixels als onderdeel ziet van de button. Uiteindelijk heb ik de outline uit het component gehaald.</p>
<p>Nog een verschil is het gedrag tijdens de klik op een button. Als je op een echte button klikt, zie je even de active state en vervolgens wordt de eigenlijke actie uitgevoerd. Dit is in Adobe XD niet mogelijk omdat je maar één overgang per interactie kunt instellen. De ontwerper moet een keuze maken tussen het laten zien van de active state of laten zien waar de button voor bedoeld is, bijvoorbeeld het versturen van een formulier. In het design system zie je de overgang naar de active state, terwijl in de prototypes de bedoelde actie te zien is.</p>
<h2>Hand-off naar de ontwikkelaar</h2>
<p>Het gaat natuurlijk niet alleen om het laten zien van een interactie van de button. Uiteindelijk zal een front-end developer een echte button maken in HTML en CSS en daar eventueel met JavaScript interactie aan toevoegen.</p>
<p>Adobe XD kan gedeeltelijk CSS tonen die bij de button hoort. Verwacht geen kant-en-klaar component van HTML en CSS, al zijn daar wel plugins voor. Je krijgt CSS met absolute positionering per laag: de rechthoek (achtergrond, border), het icoontje en het label. Ook alle andere afmetingen zullen absoluut zijn: in px, dp of pt. Als de ontwerper de kleuren een naam heeft gegeven, zie je die als CSS variabelen terug die gelden voor het hele ontwerp. Sowieso krijg je de kleur (ook) direct in de CSS op de manier waarop de ontwerper die heeft gedefinieerd: hex, rgba of hsla.</p>
<p>CSS variabelen voor het project gegenereerd door Adobe XD:</p>
<pre><code>:root {
/* Colors: */
--theme-background-hover: #EAEAF4;
--theme-color-darken: #423F9D;
--theme-color-primary: #2B24F5;
}
</code></pre>
<p>CSS fragment voor de box van de button gegenereerd door Adobe XD:</p>
<pre><code>/* Layout Properties */
top: 34px;
left: 34px;
width: 144px;
height: 40px;
/* UI Properties */
border: 2px solid var(--theme-color-primary);
background: #FFFFFF 0% 0% no-repeat padding-box;
box-shadow: 1px 1px 2px #00000054;
border: 2px solid #2B24F5;
border-radius: 20px;
opacity: 1;
</code></pre>
<p>CSS fragment voor de box van de button gegenereerd door Adobe XD:</p>
<pre><code>/* Layout Properties */
top: 41px;
left: 72px;
width: 86px;
height: 27px;
/* UI Properties */
color: var(--theme-color-primary);
text-align: left;
font: normal normal bold 20px/24px Open Sans;
letter-spacing: 0px;
color: #2B24F5;
opacity: 1;
</code></pre>
<p>De ontwerper kan een fontgrootte en line-height definiëren, de hoogte van de box van de button en zelfs de padding binnen die box. Verwacht echter geen margins of paddings in de CSS. Daardoor kan er een verschil ontstaan tussen het bedoelde ontwerp en de implementatie. Adobe XD berekent aan de hand van het lettertype de verwachte hoogte van de tekst, die niet per se overeenkomt met de hoogte in de browser. De ontwikkelaar kan wel de afmetingen van de box en de afstanden tussen elementen opvragen om te controleren of die overeenkomen met de implementatie.</p>
<p><img src="https://www.fronteers.nl/_img/blog-jasha-3.png" alt="Afstanden binnen de button volgens Adobe XD. Met stippellijntjes en ballonnetjes met cijfers laat Adobe XD zien hoe de uitlijning van de tekst is binnen de button" /></p>
<p>Afstanden binnen de button volgens Adobe XD.</p>
<p>Een mogelijkheid om documentatie of een commentaar toe te voegen tijdens het ontwerpen ontbreekt. Opmerkingen kun je alleen in de gepubliceerde online versie toevoegen. In ons design system heb ik van een aantal componenten de gewenste marges erbij gezet.</p>
<h2>Was het echt zo simpel?</h2>
<p>Het lijkt zo simpel: een button ontwerpen in Adobe XD en toepassen in een prototype. Toch is de werkelijkheid wat minder eenvoudig. De CSS geeft net een ander resultaat dan bedoeld in het ontwerp. De ontwikkelaar moet daardoor alsnog extra werk doen om de implementatie overeen te laten komen met het ontwerp.</p>
<p>Misschien heb ik de grenzen van Adobe XD opgezocht om een zo realistisch mogelijk prototype te maken. Aan de andere kant, als het een tool is om prototypes voor het web te maken, verwacht ik dat het zich ook zo kan gedragen als op het web.</p>
<p>Inmiddels ken ik de beperkingen van deze tool en weet ik ermee om te gaan. Zijn mijn verwachtingen te hoog geweest? Misschien is het voor een prototype voldoende om alleen de overgang van de ene naar de andere pagina te laten zien. Kan een ontwikkelaar verwachten dat een tool die geen button element kent, daar wel goede CSS voor genereert?</p>
<p>Nu sta ik voor de keuze: de beperkingen accepteren en bij Adobe XD blijven? Of Figma onder de knie krijgen en daar tegen (andere) grenzen aanlopen?</p>
</content>
</entry>
<entry>
<title>Een mobile app maken met JavaScript</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/een-mobile-app-maken-met-javascript"/>
<updated>2022-12-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/een-mobile-app-maken-met-javascript</id>
<content xml:lang="nl" type="html"><p>Je hebt op je telefoon vast ontelbare apps staan. Misschien heb je wel Netflix, Instagram, de app van Burger King, of de fitness app Sworkit. Wat hebben deze apps met elkaar gemeen? Ze zijn allemaal gemaakt met JavaScript. Verschillende JavaScript frameworks maken het nu mogelijk om ‘gewoon’ met JavaScript, HTML en CSS een mobile app te maken voor bijvoorbeeld iOS of Android. Maar wat komt er nog meer bij kijken als je jouw met JavaScript gemaakte app ook echt wil uitbrengen in de verschillende app stores? Dat probeer ik in deze blog uit te leggen.</p>
<h2>Swift, Kotlin of JavaScript</h2>
<p>Doorgaans worden apps voor iOS geschreven in Swift (dit gebeurde voorheen in Objective-C) en in Kotlin voor Android (voorheen Java). Natuurlijk kun je een van deze talen leren om een native app te maken. Zo heeft Apple bijvoorbeeld leermateriaal voor Swift ontwikkeld, speciaal voor kinderen.</p>
<p>Wil je liever geen nieuwe programmeertaal leren? Zoals gezegd hoeft dat ook niet. Netflix en Instagram bijvoorbeeld zijn gemaakt met React Native. De app van Burger King en Sworkit zijn gemaakt met Ionic en/of Capacitor. Met Ionic en Capacitor ben je zelfs niet eens afhankelijk van een specifiek JS-framework.</p>
<h2>Capacitor en NativeScript</h2>
<p>Capacitor is ontwikkeld door het team achter Ionic en kun je beschouwen als de opvolger van Cordova (wat weer de opvolger van Adobe's Phonegap was). Met Capacitor is het nog makkelijker geworden om een mobile app te maken, want je kunt dit integreren in elk modern front-end project. Of je nu Vue, React of Angular gebruikt. Je kunt zelfs vanilla JS schrijven.</p>
<p>Een ander framework dat je kunt gebruiken en vergelijkbaar is met Capacitor, is Nativescript. Wil je hiermee werken, dan kun je het beste de <em>get started</em> documentatie gebruiken van de desbetreffende frameworks. Die zijn beter en uitgebreider dan ik het kan uitleggen nu.</p>
<h2>En nu?</h2>
<p>Je hebt een app gemaakt met het JavaScript framework van je keuze. Het werkt in de browser, wat nu? Je eerste stap is om je app te testen in een emulator of op je eigen device. Zo weet je zeker dat de app die je wilt publiceren, ook daadwerkelijk werkt buiten de browser om.</p>
<h2>Xcode en Android Studio</h2>
<p>Met Xcode kun je je app testen voor alle Apple devices, voor Android heb je Android Studio nodig. Belangrijke opmerking hierbij is wel dat Xcode alleen beschikbaar is voor MacOS. Android Studio kun je voor meerdere besturingssystemen downloaden. Een extra tip is om altijd te testen op een echt toestel en niet volledig op een emulator te vertrouwen. Zo is het mij meerdere malen overkomen dat een app het in de emulator niet deed, maar op een telefoon wel zonder problemen werkte.</p>
<h2>App icons en splash screens</h2>
<p>Werkt je app? Gefeliciteerd! Het belangrijkste heb je nu gehad, maar je bent er helaas nog niet. Je app heeft een icon nodig dat op verschillende formaten en voor verschillende devices gemaakt moet worden. Dit geldt ook voor een <em>splash screen</em>*, het laadscherm dat je ziet voordat een app opent. Helaas hanteren zowel Android als iOS verschillende formaten voor zowel splash screens als icons, waardoor dit best wel een klus kan zijn. Gelukkig zijn er <a href="https://appicon.co/">verschillende online tools</a> die je daarbij kunnen helpen. Als zo’n tool ook de juiste folderstructuur aanhoudt, hoef je alleen de default icons in de desbetreffende directories te vervangen voor je eigen nieuwe afbeeldingen.</p>
<p>Een splash screen is iets ingewikkelder, voornamelijk door de grote verschillen tussen telefoons en tablets. Als je hierbij ervoor kiest om vanuit een bronbestand de verschillende formaten te genereren, is het belangrijk om je content te centreren in het design omdat je anders de kans hebt dat een deel niet zichtbaar is. Er zijn <a href="https://apetools.webprofusion.com/#/tools/imagegorilla">tools</a> die daar ook rekening mee kunnen houden, zodat je ook hierbij in een handomdraai de juiste bestanden kunt maken. Vervolgens is het toevoegen van de splash screens aan je app ook een kwestie van de default afbeeldingen vervangen. Je hoeft gelukkig niet met alle mogelijke formaten rekening te houden. Zowel Apple als Google gaan uit van een aantal vaste formaten.</p>
<h2>Google Play Console en App Store Connect</h2>
<p>Je hebt een werkende app, een app icon en een splash screen: je bent klaar om je app te uploaden naar de platforms van Google en Apple om je app te publiceren. Voor Android telefoons gebruik je Google Play Console, voor iOS is er App Store Connect. Bij beide platforms heb je een developer account nodig. Ook hierbij zou ik aanraden om de documentatie van de platforms zelf te lezen, omdat deze het wederom beter kunnen uitleggen dan ik dat kan. Belangrijk om te weten is dat een developer account bij Apple 99 euro per jaar kost, voor een Google Play Developer account ben je eenmalig 25 dollar kwijt. Voor beide heb je een credit card nodig.</p>
<h2>Testen</h2>
<p>Zowel App Store Connect als Google Play Console bieden je de mogelijkheid om gebruikerstests uit te voeren via de platforms. Je kunt hiervoor zelf mensen uitnodigen. Wat je nodig hebt is het e-mailadres van je proefpersonen. Alleen zij kunnen dan de versie van je app downloaden en gebruiken. Het is zelfs mogelijk om via deze platforms feedback te verzamelen, zodat je precies weet welke dingen je gebruikers tegen aan lopen.</p>
<h2>Previews, screenshots en feature graphics</h2>
<p>Nu je app getest is - en hopelijk goed bevonden - ben je er bijna. Je kunt nu het proces volgen om je app in te dienen voor beide app winkels en ook hierbij zijn weer een aantal dingen om aan te denken. Zo moet je een website opgeven, onder andere voor bijvoorbeeld een privacyverklaring. Ook heb je afbeeldingen nodig die bij je app getoond worden.</p>
<p>Ook voor deze previews en screenshots moet je verschillende formaten voorbereiden. Voor iOS bijvoorbeeld is op het moment van schrijven een screenshot van een 6.5” iPhone verplicht en een 12.9” iPad. Daarnaast heeft Google een “feature graphic”, een soort promotiebanner voor je app. Om dit soort previews te genereren zou ik ook aanraden om gebruik te maken van <a href="https://appscreens.com/">(online) software</a>. Zo’n tool kan automatisch alle formaten voor je genereren, zonder dat je voor elk device een apart design moet maken.</p>
<h2>Je app publiceren</h2>
<p>Als je alle afbeeldingen gemaakt hebt, ben je nu echt klaar om je app in te dienen. Dit is voornamelijk een kwestie van alle stappen doorlopen en gevraagde velden invullen. Vervolgens dien je je app in ter goedkeuring. Als je alle informatie hebt ingevuld, afbeeldingen geüpload en je app natuurlijk goed werkt en aan de voorwaarden voldoet, zou dit alleen nog een formaliteit zijn. Bij Apple wordt je app in de meeste gevallen binnen 24 uur gekeurd en gekeken of je app aan de richtlijnen van Apple voldoet. En dan staat je app die je helemaal met JavaScript gemaakt hebt, in de app stores!</p>
</content>
</entry>
<entry>
<title>Remix en Next.js: "echt" full-stack bestaat niet, of wel?</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/remix-en-next-js-echt-full-stack-bestaat-niet-of-wel"/>
<updated>2022-12-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/remix-en-next-js-echt-full-stack-bestaat-niet-of-wel</id>
<content xml:lang="nl" type="html"><p>Een goede blog begint altijd met een controversiële titel, zeggen ze toch? Maar er zit wel een gedachte achter.</p>
<p>Een &quot;echte&quot; full-stacker, die zijn ontzettend zeldzaam. In mijn jarenlange carrière heb ik er 1, misschien 2 ontmoet. Let wel, met &quot;echte&quot; full-stacker bedoel ik de term die HR en management helaas vaak gebruiken: iemand die 50% op front-end en 50% op back-end ingezet kan worden.</p>
<p>Dit is lastig, want front-end en back-end (in ieder geval de wat klassiekere variant) zijn twee complete disciplines. Ieder met hun eigen <em>languages</em> en <em>tools</em>, met hun eigen <em>best practices</em>, met hun eigen <em>thought leaders</em>, en ga zo maar door.</p>
<p>Op de werkvloer komt het geregeld voor dat IT-afdelingen zoeken naar (enkel) full-stack ontwikkelaars omdat die flexibel en -vooral- goedkoop zijn. Je krijgt 2 ontwikkelaars voor de prijs van één toch? In de praktijk krijg je meestal iemand die een expert is één discipline, en &quot;goed genoeg&quot; in de andere.</p>
<p>Goed, ik kan hier eindeloos over doorpraten, maar het punt is duidelijk: full-stack is moeilijk om goed te kunnen/doen.</p>
<p>Het is daarom geinig dat er de laatste jaren front-end meta-frameworks op zijn gekomen die front-enders stiekem in full-stack developers veranderen. We duiken in 2 frameworks die hier &quot;schuldig&quot; aan zijn: Remix en Next.js</p>
<p>Trouwens, &quot;schuldig&quot; moet je met een korrel zout nemen. Het is namelijk, als je het mij vraagt, een goede ontwikkeling.</p>
<h2>Wat zijn meta-frameworks?</h2>
<p>Remix en Next.js worden tegenwoordig vaak &quot;meta-frameworks&quot; genoemd, omdat ze meer doen dan alleen zorgen dat je met React een user interface kan bouwen. Meta-frameworks hebben ook controle over de server waar je applicatie op draait.</p>
<p>Dit is een hele grote reden waarom Remix (en Next.js) het zo makkelijk maken om full-stack te werken. Ze weten beide <em>welk</em> deel van je code server-side en welk deel client-side is. En daardoor kunnen ze een aantal aannames maken:</p>
<ul>
<li>Het is makkelijk om de code te splitten: de browser downloadt alleen de client-side code en niks van de server-side code waar het niks mee kan.</li>
<li>Routing kan worden ingebouwd en is niet meer enkel client-side: we gaan als het ware weg van de single-page applications en weer richting de multi-page applications.</li>
<li>De weg tussen client-side en server-side is makkelijker omdat die wordt gecontroleerd door het meta-framework. Dit zie je in zowel Remix als Next.js, waar de server-side code al geprocessed is (Next.js geeft je in zijn <code>NextAPIRequest</code> object een <code>[body</code> die al geparsed is door de <code>content-type</code> header](https://nextjs.org/docs/api-routes/request-helpers) (dit kan je uitzetten trouwens), Remix revalideert telkens de data nadat een <code>&lt;form/&gt;</code> is verstuurd).</li>
</ul>
<h2>Van de server naar de client naar de server</h2>
<p>Wat maakt het dan zo interessant om een meta-framework in te zetten? En belangrijker: hoe vertroebelt een meta-framework de grens tussen front-end en back-end? We pakken even Next.js als voorbeeld.</p>
<p>Begin november was het Next.js conference, waar één van de sprekers Theo Browne(<a href="https://twitter.com/t3dotgg">@t3dotgg</a>) was. In zijn presentatie spreekt hij over Next.js als back-end framework (dit klinkt heel bekend, maar ik beloof je dat ik het voorstel voor dit artikel eerder had ingeschoten bij Fronteers). Het stuk waar ik naar link gaat dieper in over de plek die Next.js inneemt op de reis van database via server naar de client.</p>
<p>Op die reis kunnen we een paar &quot;stations&quot; pakken:</p>
<ol>
<li>De database: er wordt een connectie gelegd met een database en data uitgevraagd.</li>
<li>Een request: er wordt een request via de server verstuurd en uitgevoerd.</li>
<li>HTML: er wordt HTML gegenereerd die naar de client wordt gestuurd.</li>
<li>Interactie: de HTML wordt gedownload en ingelezen, de JavaScript draait en het framework (in ons geval React) neemt het over.</li>
</ol>
<p>Hier wordt goed uitgelicht hoe een meta-framework als Next.js een bredere plek inneemt op die reis. Waar we eerst PHP gebruikten voor stations 1, 2 en 3, en HTML voor station 4, kunnen we met Next.js door alle stations gaan. In feite maakt Next.js het mogelijk om in onze applicatie (of website, waarom niet?) van database naar de client te gaan.</p>
<p>In het voorbeeld hieronder heb ik een simpele Next.js page, die op de server data ophaalt uit de database en vervolgens de pagina vult:</p>
<pre><code>// In db.js hebben we een connectie naar de database gemaakt
// db.js draait op de server (station 1)
import { db } from '../db';
// Het Page component rendert een pagina met de data die we
// van de server hebben gehaald
// Page() wordt gegenereerd op de server (station 3) maar draait
// op de client (station 4)
export default function Page({ products }) {
return (
&lt;div&gt;
&lt;h1&gt;Onze producten&lt;/h1&gt;
&lt;ul&gt;
{ products.map(product =&gt; (
// Een overzicht van een product
))}
&lt;/ul&gt;
&lt;/div&gt;
);
}
// getServerSide props vraagt data op uit de database
// Deze functie draait alleen op de server en wordt aangeroepen
// op page load (station 2)
export async function getServerSideProps() {
const products = await db.product.findMany();
// Pass data to the page via props
return { props: { products } };
}
</code></pre>
<p>Dit voorbeeld laat zien hoe je in 33 regels de hele reis van database naar client kunt maken. Meta-frameworks zoals Next.js en Remix maken veranderen de grens tussen &quot;puur&quot; front-end en full-stack, omdat ze ons een aantal voordelen bieden. Bijvoorbeeld de mogelijk dat we de hele reis in 1 taal kunnen doen (in plaats van te moeten switchen tussen PHP en HTML). Ook geven ze ons, als we TypeScript gebruiken, de mogelijkheid onze types te hergebruiken op zowel de client als de server. Dit geldt trouwens ook voor data validatie. Context-switching? Dat is nu een stuk minder geworden.</p>
<p>Meta-frameworks bieden ook al oplossingen voor het routen van je applicatie of website. In het geval van Remix en Next.js is date file-based: voor iedere route in je project maak je een bestand aan dat jouw pagina representeert.</p>
<p>Met de RFC over <a href="https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#basic-example">React Server Components</a> zien we dat React ook deze kant op aan het bewegen is. Je zien dat deze manier van denken steeds meer voeten aan de grond begint te krijgen in de wereld van front-end.</p>
<h2>Wat is Remix?</h2>
<p>Maar waar valt Remix in dit verhaal?</p>
<p>De meeste van ons kennen of werken met Next.js, dat pas geleden alweer versie 13 presenteerde met ontzettend veel nieuwe updates. Next.js presenteert zichzelf als hét React framework. Oftewel: de beste manier om een React applicatie te bouwen is met Next.js. Het React-team doet hieraan mee door Next.js aan te raden in <a href="https://beta.reactjs.org/learn/start-a-new-react-project#building-with-a-full-featured-framework">hun (nieuwe) documentatie</a> (wel met een <em>special mention</em> voor Remix!). Het is ook interessant dat een van de grootste nieuwe features in React, namelijk React Server Components, eerst gedebuteerd werd in een RFC voor Next.js 13 dan op de website van React zelf. Next.js heeft lang het React-landschap gedomineerd als framework. Tot nu toe, want ineens was daar Remix.</p>
<p>Remix is gemaakt door <a href="https://twitter.com/ryanflorence">Ryan Florence</a> en <a href="https://twitter.com/mjackson">Michael Jackson</a> (nee niet díe), de bedenkers van React Router. Zij wilden een framework maken dat focused op <a href="https://remix.run/blog/seed-funding-for-remix#web-standards-modern-ux">web standaarden en moderne UX</a> (dit zijn hun woorden). Remix richt zich op &quot;use the platform&quot; en maakt daar zoveel mogelijk gebruik van hoe een browser werkt of wat de HTTP standaard vertelt. Component-scoped CSS? Hier heb je geen CSS-In-JS of CSS Modules voor nodig, in Remix exporteer je een <code>links()</code> export voor je component of route en <a href="https://remix.run/docs/en/v1/guides/styling">Remix voegt een `` tag toe op de noodzakelijke routes</a>.</p>
<p>Progressive enhancement is ook een belangrijk onderdeel van de principes van Remix. Het is bijvoorbeeld niet alleen <em>makkelijk</em> om een werkende applicatie te bouwen in Remix dat client side <strong>geen JavaScript</strong> gebruikt, Remix duwt je zelfs die kant een beetje in. Een groot deel van applicatie functionaliteiten waar we tegenwoordig JavaScript voor inzetten, zoals het ophalen en versturen van form data, werkt in Remix simpelweg met een <code>&lt;form method=&quot;post&quot;&gt;</code>, een <code>loader</code> functie die aangeroepen wordt op GET requests (dus ook page loads, als je route een <code>loader</code> functie export) en een <code>action</code> functie die op POST (en PUT) requests draait. Is JavaScript niet beschikbaar op een browser? Dan wordt het formulier verstuurd via een redirect naar de server en terug naar de client (zoals we vroeger deden met PHP). Is JavaScript er wel? Dan wordt de request op de pagina zelf gedaan zonder redirect en krijgt de gebruiker automatisch de nieuwe data te zien.</p>
<p>Tot nu toe hebben we het op een redelijk luchtig niveau gehad over full-stack en meta-frameworks, maar je zou je kunnen afvragen <em>hoe</em> een meta-framework ons precies de full-stack kant induwt?</p>
<h2>Op weg naar full-stack</h2>
<p>We duiken die vraag in met hulp van een aantal voorbeelden. We zien ook hoe bepaalde dingen die we eerst aan de back-end zouden toeschrijven naar de front-end worden gehaald.</p>
<h2>Databases</h2>
<p>We beginnen met databases, want veel projecten zullen er een nodig hebben voor data opslag.</p>
<p>Traditioneel gesproken zal de client van een applicatie/website via een API data opvragen aan de server. Het is dan aan de server om een connectie met de database te leggen, data op te vragen, en het resultaat terug te sturen (of een foutmelding weer te geven indien nodig). Dit is natuurlijk helemaal prima, en in veel gevallen hoeft dit niet per se te veranderen. We kijken straks naar een manier om Remix of Next.js in te zetten in een architectuur met een externe database.</p>
<p>Wat nu mogelijk is, is om in Remix of Next.js direct een verbinding met je database te leggen. Dit wordt helemaal makkelijk als je een tool als <a href="https://www.prisma.io/">Prisma</a> inzet als ORM. Prisma gaf je al het voordeel om je ORM in JavaScript of TypeScript te schrijven (komen we toch weer terug op context switching), dat je vervolgens kwijt kon tussen je project en je database.</p>
<p>Die laag kan je nu direct in je project kwijt, door Prisma aan te roepen en vervolgens data uit te vragen of weg te schrijven. Dit kan je vervolgens meteen in je pagina kwijt.</p>
<p>Remix geeft een <a href="https://remix.run/docs/en/v1/guides/data-loading#databases">simpel voorbeeld hiervan</a>, maar dit is uiteraard ook in Next.js mogelijk.</p>
<h2>Proxy</h2>
<p>Inhakend op het database-verhaal: wat als je een front-end project wil omzetten naar een meta-framework maar de back-end met alle database operaties staan al vast?</p>
<p>Nou, als eerste wil ik je zeggen: je hoeft niet alles om te bouwen naar iets nieuws <em>omdat</em> het iets nieuws is. Als de infrastructuur rondom de back-end en database al staat, gebruik je lekker dat. Het scheelt een boel tijd en moeite voor iets dat al werkt.</p>
<p>Wat je <em>wel</em> kan doen, is de server van je meta-framework gebruiken als proxy. Dit biedt weer een boel nieuwe opties en mogelijkheden:</p>
<ul>
<li>Je kan requests load-balancen en responses cachen.</li>
<li>Je kan environment variables gebruiken voor bepaalde secret tokens.</li>
<li>Je kan de response van requests naar je database of een externe back-end muteren voor je het terugstuurt (hier kom ik straks nog op terug).</li>
</ul>
<p>In je meta-framework kan je je server inzetten om requests naar een (externe) back-end te sturen, eventueel voorzien van een authenticatie token.</p>
<p>In het voorbeeld hieronder gebruiken we Notion om een rij in een tabel (wat bij Notion een &quot;database&quot; heet) toe te voegen. Voor het voorbeeld gebruik ik Remix, maar dit is uiteraard ook mogelijk in Next.js.</p>
<pre><code>// ./app/notion.server.ts, wordt alleen op de server ingeladen
import { Client } from '@notionhq/client';
export const notionClient = new Client({
// Het authenticatie token is alleen in te lezen op de server
auth: process.env.NOTION_AUTH_TOKEN,
});
// ./app/routes/notion.ts
import { notionClient } from '../notion.server';
import type { ActionArgs } from '@remix-run/node';
// `action` functies worden door Remix aangeroepen wanneer bij
// POST en PUT requests. Deze draaien op de server
export const action = async ({ request }: ActionArgs) =&gt; {
// We parsen de body uit onze request. Als het verstuurd is
// door een `&lt;form/&gt;`, krijgen we een FormData object
const payload = await request.formData();
const data = Object.fromEntries(payload);
// We maken een nieuwe rij aan in de tabel,
// met de data die is versturd via het &lt;form/&gt;
const response = await notionClient.pages.create({
parent: {
// NOTION_CONTACT_FORM_TABLE_ID is alleen uit te lezen
// zien op de server
database_id: process.env.NOTION_CONTACT_FORM_TABLE_ID,
},
properties: {
// De data die je wilt weg schrijven in je tabel
...data,
}
});
if (!response.ok) {
// Er is iets fout gegaan, dus we sturen een error terug
// Omdat we de response `throw`'en, weet Remix dat er iets
// fout is gegaan. Hier kunnen wij dan weer op acteren
// Hier komen we later op terug
throw new Response(JSON.stringify({ status: 'error' }), {
status: 500,
});
}
// Notion heeft de rij gemaakt, we sturen een response terug
return new Response(JSON.stringify({ status: 'success' }), {
status: 201
});
};
</code></pre>
<p>Even een side note: Remix heeft helper functions zoals <a href="https://remix.run/docs/en/v1/api/remix#json"><code>json()</code></a> dat je kan gebruiken om response terug te sturen. Die helpers zijn kleine wrappers om het daadwerkelijke <code>Response</code> object heen. Voor dit voorbeeld wilde ik meer focussen op wat de server kan, dan hoe Remix specifiek werkt. Deze code kan je namelijk ook in Next.js gebruiken.</p>
<h2>Dure operaties off-loaden naar de server</h2>
<p>Het komt soms voor dat we een dure operatie moeten uitvoeren. Met &quot;duur&quot; bedoel ik dan een operatie die:</p>
<ul>
<li>Veel processorkracht kost;</li>
<li>Veel data heen of terugstuurt;</li>
</ul>
<p>Denk hierbij vooral aan het on-the-fly genereren van responsive afbeeldingen, het omgaan met grote payloads in requests of responses (scheelt weer een GraphQL server), het sanitizen van input data van de gebruiker, of het parsen van markdown uit de database naar HTML voor de client (zoals bij een blog).</p>
<p>Het idee is dat de servers draaien op hardware die gemaakt is om grote operaties efficiënt uit te voeren. De client is altijd afhankelijk van het apparaat dat de gebruiker heeft, hoeveel apps of programma's er toevallig tegelijkertijd aan het draaien zijn, en de internetverbinding of -abonnement dat de gebruiker heeft.</p>
<p>Door de dure operaties op de server plaats te laten vinden, kunnen we onze applicatie/website sneller laten reageren, kunnen we voorkomen dat er kostbare kilobytes over de lijn worden verstuurd en kunnen we (in erge gevallen) zelfs voorkomen dat onze applicatie of website crashed.</p>
<h2>Data mutaties</h2>
<p>Met data mutaties bedoel ik het lezen en schrijven van data. Meta-frameworks spelen hier heel handig op in omdat ze in staat zijn de mutaties optimaal in te plannen.</p>
<h2>Data lezen</h2>
<p>Wanneer je op de client-side een GET request doet voor data, moet eerst de JavaScript bundle worden gedownload en geparsed, voor React kan draaien om de request uit te voeren voor je component. Dit is in feite een waterval. We moeten namelijk steeds wachten op een stukje dat geladen wordt, voor we het volgende stuk kunnen ophalen.</p>
<p>Wat meta-frameworks kunnen doen, is de request voor de data op de server uitvoeren. In de tijd dat de client een JavaScript bundle krijgt om te download, te parsen en te draaien, kan de request uitspelen en kan de HTML-pagina worden gegenereerd met de opgevraagde data. We hoeven niet meer stapsgewijs de netwerk requests af te wachten. Performance!</p>
<h2>Data muteren</h2>
<p>Een ander voordeel is dat het makkelijker is om data te muteren. Dit is het beste uit te leggen aan de hand van een voorbeeldje.</p>
<p>Stel, we maken een website waarop iemand data van voertuigen uit kan lezen. Er is een database, die bereikbaar is via een REST API, waarbij we een simpele GET request kunnen sturen dat we als volgt kunnen typeren:</p>
<pre><code>interface VehicleQuery {
type: 'car' | 'bus' | 'truck';
licensePlate: string;
}
</code></pre>
<p>Iedere query geeft een antwoord met de gegevens van dat voertuig:</p>
<pre><code>interface VehicleDetails {
make: string;
model: string;
fuelType: string;
engineType: string;
maxOccupants: number;
ownerHistory: Owner[];
}
</code></pre>
<p>Onze opdracht is om een pagina te maken waarbij iemand zijn kentekenplaat in kan vullen en het merk en model terugkrijgt. Hoewel de API meer informatie kan ontvangen en teruggeven, moeten we voor onze pagina (zie het als een soort landingspagina) er meer voor zorgen dat er z.s.m. data op het scherm te zien is. We vragen dus alleen het kentekenplaat uit, want we stellen dat het voertuigtype (dat wel verplicht is in de query) altijd <code>car</code> zal zijn.</p>
<p>We pakken Remix even als voorbeeld:</p>
<pre><code>import type { json } from '@remix-run/node';
import type { ActionArgs } from '@remix-run/node';
import { useActionData } from '@remix-run/react';
// `~` is ge-aliased naar `./app/`
import type { VehicleQuery } from '~/models/Vehicle';
export const action = async ({ request }: ActionArgs) =&gt; {
const data = await request.formData();
const { licensePlate } = Object.fromEntries(data);
const query: VehicleQuery = {
type: 'car';
licensePlate,
};
const response = await fetch('/api/vehicles/query', {
method: 'POST',
body: JSON.stringify(query),
});
const { make, model } = await response.json();
return json({ make, model });
};
export default function VehicleInfoPage() {
const data = useActionData&lt;typeof action&gt;();
if (data) {
const { make, model } = data;
return (
&lt;div&gt;
De gegevens van het voertuig zijn:
&lt;ul&gt;
&lt;li&gt;Merk: { make }&lt;/li&gt;
&lt;li&gt;Model: { model }&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;
);
}
return (
&lt;form method=&quot;post&quot;&gt;
&lt;label&gt;
&lt;p&gt;Wat is het kenteken?&lt;/p&gt;
&lt;input name=&quot;licensePlate&quot; type=&quot;text&quot; /&gt;
&lt;/label&gt;
&lt;button&gt;Haal informatie op&lt;/button&gt;
&lt;/form&gt;
);
}
</code></pre>
<p>Wacht, <em>wat gebeurt hier?</em></p>
<p>We beginnen even met de pagina zelf, die laat namelijk een formulier zien waar iemand een kenteken kan invoeren. Zaken als styling is even weggelaten om het simpel te houden.</p>
<p>Wanneer op de knop geklikt wordt, zal Remix een POST request uitvoeren. Onder water wordt er veel gedaan, maar in ons voorbeeld gaat het erom dat de <code>action</code> functie wordt aangeroepen.</p>
<p>In de <code>action</code>, halen we uit de <code>request</code> het kenteken dat de gebruiker heeft ingevoerd. De query vraagt naast een kenteken ook om een voertuigtype, maar dat hoeft de gebruiker niet in te vullen. Wij zetten het naar <code>car</code>, en vullen de query aan met het kenteken en hoppa!</p>
<p>Dit is natuurlijk een erg simpel voorbeeld, maar als je wilt interacteren met een API dat veel data vraagt in zijn request én jij weet dat veel properties naar een standaard waarde worden ingesteld, <em>hoef je die niet te vragen in de request van jouw client naar de server</em>. Je stuurt enkel de data die daadwerkelijk ingevuld wordt door de gebruiker, vult het aan met alle standaard data (of aangevulde business logica, zoals misschien een <code>userID</code> dat je uit je sessie data haalt) en stuurt dit naar de client. In ons voorbeeld bevat <code>VehicleQuery</code> maar 2 properties, maar wat als je een API hebt dat 20-30 properties heeft waarvan 80% een standaard waarde heeft?</p>
<p>Dan het vervolg: de query is gelukt en we hebben informatie gekregen van de API. Er is meer data teruggekomen dan we daadwerkelijk nodig hebben, dus we pakken de velden die we wél willen (<code>make</code> en <code>model</code>), en sturen dit terug naar de client.</p>
<p>In de client kunnen we een check doen of er data is verstuurd van de server (dit is een Remix-specifiek iets, daar kom ik later op terug), en als dat het geval is laten we het antwoord van de server zien. Stel de API geeft een gigantische lading aan data terug, dan kan je op je server gemakkelijk de informatie uitpikken die je nodig hebt en dit terugsturen naar de client.</p>
<p><em>GraphQL, anyone?</em></p>
<p>Nu is de payload, zowel van de client naar de server als vice versa, zo klein mogelijk. Dit is ontzettend handig, want iedere kilobyte telt!</p>
<h2>Hergebruik van types en validatie</h2>
<p>Het is bij Remix en Next.js (en waarschijnlijk ook bij andere meta-frameworks) mogelijk om de types en validaties die je gebruikt in je code te delen tussen de client en de server.</p>
<p>Zo kan je een validatie function schrijven voor een e-mailadres. Die functie kan je gebruiken op de server om een inschrijfformulier te valideren voor je de data verwerkt in je database (want back-end validatie is essentieel in data verwerking).</p>
<p>Maar, in het kader van progressive enhancement, willen we ook het e-mailadres valideren als de gebruiker het e-mail veld heeft ingevuld en vervolgens naar een ander veld gaat.</p>
<p>In dit geval kunnen we dezelfde validatie functie gebruiken, en deze <em>op de client</em> draaien. We hergebruiken de validatie tussen de client en de server zonder problemen.</p>
<pre><code>// ./app/validations/email.ts
export function emailIsValid(email: string) {
return email.match(/^(([^&lt;&gt;()\\\\[\\\\]\\\\\\\\.,;:\\\\s@&quot;]+(\\\\.[^&lt;&gt;()\\\\[\\\\]\\\\\\\\.,;:\\\\s@&quot;]+)*)|(&quot;.+&quot;))@((\\\\[[0-9]{1,3}\\\\.[0-9]{1,3}\\\\.[0-9]{1,3}\\\\.[0-9]{1,3}])|(([a-zA-Z\\\\-0-9]+\\\\.)+[a-zA-Z]{2,}))$/);
}
// ./app/routes/contact.tsx
import type { ActionArgs } from '@remix-run/node';
import { json } from '@remix-run/node';
import { useActionData } from '@remix-run/react';
import { emailIsValid } from '~/validations/email';
interface SuccessfulContactFormResponse {
status: 'success';
}
interface FailedContactFormResponse {
status: 'error';
message: string;
}
type ContactFormResponse =
| SuccessfulContactFormResponse
| FailedContactFormResponse;
type ContactForm = {
email: string;
message: string;
};
export const action = async ({ request }: ActionArgs) =&gt; {
const data = await request.formData();
const { email, message } = Object.fromEntries(data) as ContactForm;
if (!emailIsValid(email)) {
// Het e-mailadres is niet geldig, dus we sturen een error response terug
const response: ContactFormResponse = {
status: 'error',
message: 'E-mail is niet correct',
};
return json(response, { status: 500 });
}
// Hier doen we iets met `message` om het te versturen
// of op te slaan.
const response: ContactFormResponse = { status: 'success' };
return json(response);
};
export default function ContactPage() {
const data = useActionData&lt;typeof action&gt;();
return (
&lt;form method=&quot;post&quot;&gt;
&lt;label&gt;
&lt;p&gt;E-mail:&lt;/p&gt;
&lt;input
name=&quot;email&quot;
type=&quot;email&quot;
aria-invalid={data?.status === 'error' ? true : undefined}
aria-describedby=&quot;email-error&quot;
/&gt;
{ data?.status === 'error' &amp;&amp; (
&lt;p id=&quot;email-error&quot;&gt;
{data.message}
&lt;/p&gt;
)}
&lt;/label&gt;
&lt;label&gt;
&lt;p&gt;Bericht:&lt;/p&gt;
&lt;textarea name=&quot;message&quot; /&gt;
&lt;/label&gt;
&lt;button&gt;Verzenden&lt;/button&gt;
&lt;/form&gt;
);
}
</code></pre>
<p>Zoals je ziet in het voorbeeld kunnen we hetzelfde principe toepassen voor TypeScript types: zowel de server als de client kan ze gebruiken.</p>
<div class="note"> Als je Remix al kent, zie je dat ik `useActionData<typeof action="">()` gebruik. In feite geeft dit al het correcte type mee voor `data` in mijn code editor en hoef ik die niet expliciet te typen voor TypeScript. Je kan het altijd nog expliciet meegeven aan `data` wanneer je het declareert.</typeof></div>
<h2>State management</h2>
<p>De diepe samenwerking tussen client en server in meta-frameworks komt ook van pas als het gaat om state management.</p>
<p>Over de jaren heen zijn er vele mogelijkheden gekomen om state management te doen in React. Dit komt met name omdat applicaties complexer worden én omdat data een steeds grotere rol aan het spelen is in die applicaties. Het komt er grofweg op neer dat een applicatie (dit geldt soms ook voor websites trouwens) rekening moet houden met 2 zaken:</p>
<ul>
<li>De application state, oftewel de <em>global state</em> van een applicatie;</li>
<li>Data mutaties, oftewel het aannemen, verwerken en weergeven van gebruikersdata;</li>
</ul>
<p>Meestal wordt er een state management library gekozen om dit allemaal in bij te houden. Daar komt ook bij dat in Create React App deze state management voornamelijk (of zelfs helemaal) op de client wordt gedaan. Maar het leuke van meta-frameworks is dat ze de mogelijkheid bieden hier slimmer mee om te gaan.</p>
<h2>Application state</h2>
<p>Eerst kijken we naar application state, wat wordt daar nou mee bedoeld?</p>
<p>In de meeste applicaties of websites wil je bepaalde states bijhouden zodat de gebruiker bijvoorbeeld functionaliteiten kan doen of instellingen wil bijhouden. Ik pak het voorbeeld van een <em>dark mode</em> toggle. Op de meeste applicaties of websites zit er in het menubalkje een knop waarmee je kan aangeven of je de lichte of donkere versie van de website wil zien.</p>
<p>Op mijn website zie je zo'n toggle button zitten, ik heb hem gefocused met mijn keyboard want waarom niet? ;)</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/advents-lody-1.png" alt="Mijn website in light mode, waarbij je een lichte achtergrond en donkere tekst ziet" /></p>
<p>Als je er op klikt verandert het kleurenschema in een donkere variant.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/advents-lody-2.png" alt="mijn website in dark mode, waarbij je een donkere achtergrond en lichte tekst ziet" /></p>
<p>De standaardmode van de website is <em>light mode</em>, dus als je de website bezoekt en je hebt nog geen voorkeur aangegeven door te klikken op de knop (of je hebt geen <code>prefers-color-scheme</code> instelling) is de achtergrond wit en de tekst donkerblauw.</p>
<p>Nu is het de bedoeling dat de mode die je kiest wordt onthouden op iedere pagina die je bezoekt. Klik je op de homepage op het zonnetje, wordt de achtergrond donkerblauw en de tekst wit. Dit krijg je dan ook te zien op ieder volgende pagina.</p>
<p>In een standaard React app kunnen we deze state onthouden met behulp van een state management library. Dit is zo simpel als het instellen van een default state, en wanneer op de knop wordt geklikt updaten we de default state met de nieuwe waarde. Hoe dit precies gaat verschilt een beetje per state management library, maar het eindresultaat is hetzelfde: de state wordt overal onthouden.</p>
<p>Hier is het wel belangrijk om even te benoemen dat die state meestal alleen lokaal wordt onthouden. Refresh je de pagina, verlies je de bijgewerkte state. Dit kan je makkelijk verhelpen door de state op te slaan in een cookie of <code>localStorage</code>.</p>
<p>Mijn website is gebouwd in Remix (surprise, surprise), en de manier hoe ik het oplos is simpelweg met cookies. De implementatie bestaat uit 3 punten:</p>
<ol>
<li>We maken een cookie die door de browsers wordt meegestuurd met iedere request.</li>
<li>We bouwen een <code>&lt;DarkModeToggle/&gt;</code> knop die via een prop weet of die aan of uit staat (en zijn icoontje aanpast) en een POST doet naar een endpoint op de server als je er op klikt.</li>
<li>We bouwen de endpoint op de server om de cookie aan te passen met de nieuwe dark mode state.</li>
</ol>
<h2>Stap 1: We maken een cookie die door de browsers wordt meegestuurd met iedere request.</h2>
<p>In simpele vorm ziet dit er zo uit, waarbij we beginnen met het maken van een cookie. Dit wordt dan door de browser meegestuurd met iedere request.</p>
<pre><code>// ./app/cookie.ts
import { createCookie } from '@remix-run/node';
export const userPrefs = createCookie('user-prefs', {
maxAge: 31536000, // a year
});
</code></pre>
<p>In <code>./app/root.tsx</code> kunnen we dit dan uitlezen. De <code>root</code> in een Remix applicatie is wat <code>_app</code> is binnen een Next.js applicatie. Alle routes worden hierin meegegeven en wij hebben de mogelijkheid om het skelet van de applicatie of website vorm te geven.</p>
<pre><code>import type { ActionArgs } from '@remix-run/node';
import {
Links,
LiveReload,
Meta,
Outlet,
Scripts,
ScrollRestoration,
} from '@remix-run/react';
import { userPrefs } from '~/cookies';
import DarkModeToggle from '~/components/DarkModeToggle';
export const loader = async ({ request }: LoaderArgs) =&gt; {
const cookieHeader = request.headers.get('Cookie');
const { darkModeEnabled = false } = await userPrefs.parse(cookieHeader);
return json({
darkModeEnabled,
});
};
export default function App() {
const { darkModeEnabled } = useLoaderData&lt;typeof loader&gt;();
return (
&lt;html lang=&quot;en&quot;&gt;
&lt;head&gt;
&lt;Meta /&gt;
&lt;Links /&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;header&gt;
&lt;DarkModeToggle isEnabled={darkModeEnabled} /&gt;
&lt;/header&gt;
&lt;Outlet /&gt;
&lt;ScrollRestoration /&gt;
&lt;Scripts /&gt;
&lt;LiveReload /&gt;
&lt;/body&gt;
&lt;/html&gt;
);
}
</code></pre>
<h2>Stap 2: We bouwen een <code>&lt;DarkModeToggle/&gt;</code> knop die via een prop weet of die aan of uit staat (en zijn icoontje aanpast) en een POST doet naar een endpoint op de server als je er op klikt.</h2>
<p>We bouwen een knop dat op basis van een prop (<code>enabled</code>) weet of dark mode aan staat of niet. In het geval dat het aan staat, laten we een ander icoontje zien en zetten we een andere waarde voor de POST request dan wanneer het uit staat.</p>
<p>In Remix zijn er meerdere manieren om data mutaties uit te voeren, waar ik later dieper op inga. Voor nu volstaat het om te zeggen dat <code>[useFetcher](&lt;https://remix.run/docs/en/v1/api/remix#usefetcher&gt;)</code> een <code>fetch</code> object teruggeeft dat we kunnen gebruiken om een request te doen zonder dat de pagina automatisch herlaad (alleen als alle JavaScript geladen is). <code>useFetcher</code> heeft veel meer handigheidjes ingebouwd zitten, zoals een check of een request &quot;pending&quot; is of niet.</p>
<pre><code>// ./app/components/DarkModeToggle.tsx
import Icon from '~/components/Icon';
import { useFetcher } from '@remix-run/react';
type Props = {
enabled: boolean | undefined;
};
const DarkModeToggle = ({ enabled }: Props) =&gt; {
const fetcher = useFetcher();
return (
&lt;fetcher.Form
action=&quot;/api/cookies&quot;
method=&quot;post&quot;
&gt;
&lt;input
type=&quot;hidden&quot;
name=&quot;action&quot;
value={enabled ? 'disable' : 'enable'}
/&gt;
&lt;button type=&quot;submit&quot;&gt;
&lt;Icon name={enabled ? 'moon' : 'sun'} /&gt;
&lt;/button&gt;
&lt;/fetcher.Form&gt;
);
};
export default DarkModeToggle;
</code></pre>
<h2>Stap 3: We bouwen de endpoint op de server om de cookie aan te passen met de nieuwe dark mode state.</h2>
<p>Op de server maken we een API route aan. In Next.js kan dit door een bestand genaamd <code>cookies.ts</code> aan te maken in de <code>./pages/api</code> map. Remix geeft je de mogelijkheid om zogenoemde <em>resource routes</em> aan te maken: routes zonder een React component export. Zelf vind ik het altijd fijner om deze resource routes te bundelen in een <code>/api/</code> folder zodat het duidelijk te zien is dat dit een andere soort route is.</p>
<p>We pakken de form data uit de request, kijken of dark mode aan-, of juist uitgezet is, en passen het cookie aan.</p>
<pre><code>// ./app/routes/api/cookies.ts
import { userPrefs } from '~/cookies';
import type { ActionArgs } from '@remix-run/node';
import { redirect } from '@remix-run/node';
type ActionData = {
action: 'disable' | 'enable';
};
export const action = async ({ request }: ActionArgs) =&gt; {
const cookieHeader = request.headers.get('Cookie');
const formData = await request.formData();
const cookie = (await userPrefs.parse(cookieHeader)) || {};
const { action } = Object.fromEntries(
formData,
) as unknown as ActionData;
if (action === undefined) {
throw new Error('An action is missing');
}
cookie.darkModeEnabled = action === 'enable';
return redirect('/', {
headers: {
'Set-Cookie': await userPrefs.serialize(cookie),
},
});
};
</code></pre>
<p>Et voilà. We hebben nu management van de state van de dark mode op onze website, zonder een state management library daarvoor te configureren. Deze state wordt onthouden en kan dus later (opnieuw) uitgelezen worden. In ons voorbeeld is dat via een cookie, maar het kan ook via <code>localStorage</code> of een database op de server.</p>
<h2>Data mutaties</h2>
<p>Een andere vorm van state management kan worden gedaan op data mutaties. Hierbij wordt data uitgelezen, bewerkt en wederom opgeslagen. Het heeft veel weg van application state, met een paar belangrijke verschillen:</p>
<ul>
<li>De <em>waarde</em> van de state is opgeslagen op de server in een data store (zoals een database, in tegenstelling tot een cookie).</li>
<li>De <em>houdbaarheidsdatum</em> van de state is langer dan een gebruikerssessie. Neem als voorbeeld een blog: de content (zoals de posts) &quot;leven door&quot; als ik klaar ben met het schrijven van een post en het tabblad weer sluit. Of ik op dat moment dark mode aan of uit heb staan (application state) is minder relevant en die state mag zelfs weer vergeten worden.</li>
</ul>
<p>De mensen van Remix hebben hier nog een uitgebreide post op geschreven die zeker het moeite waard is om te lezen: https://remix.run/blog/remix-data-flow. Ik jat een van de afbeeldingen die zij in hun post hebben geschreven, omdat dit het beste illustreert hoe Remix het state management overneemt als het gaat over data mutaties.</p>
<p>Door gebruik te maken van de <code>loader</code> en <code>action</code> functies, die worden uitgevoerd door respectievelijk een GET en POST request, kunnen we het managen van state verplaatsen van een library naar de server.</p>
<p>Voor ons voorbeeld nemen we een bewerkingsscherm voor een product, waarbij we twee velden hebben die we kunnen bewerken: product naam en prijs. Wanneer je op de knop &quot;Opslaan&quot; klikt, wordt de data meegenomen in de state en krijg je de bewerkingspagina weer te zien met daarin de nieuwe data.</p>
<p>In een traditionele React app zou een state management library ingezet kunnen worden om bij het submitten van het formulier, de ingevoerde data te pakken en de huidige state te verversen. Vervolgens wordt die state opgeslagen in de database en wordt ondertussen de huidige pagina ververst waardoor het bewerkingsscherm de laatste versie van deze data heeft.</p>
<p>Wat we zien in Remix, is dat tijdens het laden van de pagina de product data uit de database wordt gehaald. Vervolgens hebben we een React component dat de data uitleest van de server. Wanneer het formulier wordt verstuurd, wordt de data verwerkt en opgeslagen in de database, en vervolgens wordt de gebruiker weer doorgestuurd naar de bewerkingspagina, dat weer de (geüpdatete) data uit de database leest:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/advents-lody-3.png" alt="een codevoorbeeld van een product component dat een form bevat, en de loader functie voor de GET requests en action functie voor de POST request" /></p>
<p>In feite zien we hier de state machine: we &quot;updaten&quot; de state van een product door één van de velden te bewerken en vervolgens op te slaan. Remix voert de <code>action</code> functie uit, stuurt de gebruiker terug naar <code>/products/[product ID]/edit</code>, waar tijdens de page load data wordt uitgelezen uit de database met behulp van de <code>load</code> functie. Remix <em>rendert</em> het <code>Route</code> component dat de data van de server &quot;verwerkt&quot; in de HTML. De data stroomt via één route, de client blijft in sync met de server en je hoeft niet te letten op race conditions.</p>
<p>Ik wil je er ook even op wijzen dat er client-side geen JavaScript draait, en dat de inhoud van het formulier op de server gerenderd wordt. Dat betekent dat het ophalen van de nieuwe data en het zetten van de <code>defaultValue</code> van de twee inputs, <em>gebeurt op de server en niet de client</em>! Het scheelt dus ook dat we geen state management library hoeven te draaien op de client om dit werkend te krijgen.</p>
<p>Next.js biedt hier ook mogelijkheden voor, zowel out-of-the-box als met packages als <code>next-runtime</code> waar ik later op terugkom.</p>
<h2>Een diepere blik op Remix</h2>
<p>Goed, we hebben nu een aantal voorbeelden gezien waarin full-stack development een steeds grotere rol speelt in ons werk als front-end developer. We hebben ook gezien hoe meta-frameworks zoals Remix ons tonen hoe we bepaalde functionaliteiten of zelfs strategieën kunnen implementeren nu we zelf ook controle hebben over de server.</p>
<p>Ik wil dus even dieper ingaan op Remix zelf. Voor mij heeft Remix een aantal voordelen ten opzichte van Next.js als het gaat om het bouwen van een React project. Veel van de voorbeelden die ik zojuist liet zien maakten gebruik van Remix (ook al zijn ze allemaal ook in Next.js uit te voeren). Er zijn wel wat zaken die ik verder wil uitlichten:</p>
<ul>
<li>Routes, nested routes en resource routes.</li>
<li>Wat doen die <code>action</code>'s en <code>loader</code> functions nou precies?</li>
<li>Foutafhandeling in Remix: ErrorBoundaries en CatchBoundaries.</li>
<li>Forms</li>
</ul>
<h2>Routes, nested routes en resource routes</h2>
<p>Aan het hart van Remix staan routes. Dat is niet zo vreemd als je bedenkt dat de makers van React Router aan het roer staan bij Remix. De gedachte erachter is dat routes de ruggengraat van een applicatie of website is. En als je dat als uitgangspunt neemt, kan je een aantal aannames doen over het opvragen en binnenhalen van assets en data.</p>
<p>Voor Remix, de <code>routes</code> map is de belangrijkste map die je zult hebben. Alle <code>.jsx</code> of <code>.tsx</code> bestanden vormen uiteindelijk een route die je kan aanroepen via een URL.</p>
<p>Het mooie hier is dat Remix nested routes ondersteunt! Bij een <a href="https://remix.run/docs/en/v1/guides/routing#what-is-nested-routing">nested route</a> wordt de UI van een applicatie onderverdeeld in URL segments.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/advents-lody-4.png" alt="Alt: een afbeelding van een factuurdashboard met daarboven een menu dat aangeeft welke delen van een URL worden weergegeven in een interface zoals dit dashboard" /></p>
<p>In de afbeelding hierboven (gepakt van de website van Remix), zien we dat de route van het <code>&lt;Invoice/&gt;</code> component wordt gerepresenteerd in de URL door het factuurnummer (in dit geval <code>102000</code>).</p>
<p>Hoe ziet dit er dan uit in het project?</p>
<pre><code>app
├── root.jsx
└── routes
├── ... // andere routes
├── sales
│ ├── ... // andere nested routes
│ ├── index.jsx
│ ├── invoices
│ │ ├── $invoiceId.jsx
│ │ └── index.jsx
│ ├── invoices.jsx
└── sales.jsx
</code></pre>
<p>Voor <code>example.com/sales</code> worden 2 routes gerendered: <code>routes/sales.jsx</code> en <code>routes/sales/index.jsx</code>. In <code>sales.jsx</code> kan je de UI voor de &quot;Sales&quot; pagina zetten (in de screenshot kan dat dus de header met &quot;Sales&quot; zijn en het klik menuutje eronder). De <code>sales/index.jsx</code> route laat de standaard UI zien voor <code>example.com/sales</code>, bijvoorbeeld een placeholder of (in dit geval) alles onder het kopje &quot;Overview&quot;.</p>
<p>Klikt de gebruiker op &quot;Invoices&quot;, veranderd de URL naar <code>example.com/sales/invoices</code> en worden <code>routes/sales/invoices.jsx</code> en <code>routes/sales/invoices/index.jsx</code> geladen. In <code>invoices.jsx</code> kan de lijst met facturen worden geladen, in <code>invoices/index.jsx</code> kan bijvoorbeeld de kop &quot;Kies een factuur uit het linkerrijtje&quot; te zien zijn.</p>
<p>En dan als laatste: wanneer iemand op een factuur klikt. Iedere factuur weet zijn eigen factuur ID dus maken we een dynamische route aan voor het detail overzicht: <code>routes/invoices/$invoiceId.jsx</code>. Deze wordt alleen getoond als de URL een invoice ID heeft, zoals <code>example.com/sales/invoices/102000</code>. De <code>invoiceId</code> wordt in Remix meegegeven aan de <code>loader</code> functie, waarmee je in de database de factuurgegevens kan opvragen.</p>
<p>Het mooie is dat Remix dit niet alleen heel makkelijk maakt, maar de huidige staat van de UI is nu weergegeven in een URL. Dit kan je via een e-mail aan je collega's doorsturen en zij krijgen dan te zien wat jij ook ziet.</p>
<h2>Resource routes</h2>
<p>Er is nog een type route dat Remix kent, een <a href="https://remix.run/docs/en/v1/guides/resource-routes">resource route</a>. Een resource route is niks anders dan een route dat geen React component exporteert, maar wél requests kan behandelen. In Next.js zouden dit de routes zijn die je in de <code>/pages/api/</code> map plaatst. Je kan hiermee routes bepalen die alleen iets inladen of een actie uitvoeren. In het dark mode voorbeeld hierboven gebruik ik een resource route om de cookies van mijn website te updaten, maar je kan het ook gebruiken om bijvoorbeeld een PDF te genereren aan de hand van dynamische data.</p>
<p>Op mijn blog gebruik ik Plausible voor mijn analytics, en om adblockers te ontwijken laad ik het Plausible script niet rechtstreeks in mijn pagina in. Ik gebruik een resource route om het Plausible script <a href="https://github.com/lodybo/lodybo-nl/blob/main/app/routes/js/script%5B.js%5D.ts">te proxiën naar mijn pagina</a>.</p>
<h2><code>action</code> en <code>loader</code></h2>
<p>In het voorbeeld van de factuur dashboard zei ik dat de <code>routes/invoices/$invoiceId.jsx</code> een <code>loader</code> functie gebruikt om factuurgegevens op te vragen. Remix gebruikt <code>loader</code> en <code>action</code> functies voor data mutaties in je route. Deze zijn overigens niet verplicht voor een specifieke route, en je mag ook één van de twee gebruiken.</p>
<p>In het kort: <code>loader</code> functies draaien wanneer er data wordt opgevraagd (een GET request), en <code>action</code> functies draaien wanneer er iets met de data gedaan wordt (een POST, PUT of DELETE request).</p>
<p>Beide functies retourneren een response object. Deze heeft de vorm van het standaard <code>[Response</code> object](https://developer.mozilla.org/en-US/docs/Web/API/Response) dat bij <code>fetch</code> gebruikt wordt. Hier zie je dus goed dat Remix zich houdt aan web standaarden: een request object implementeert bijvoorbeeld de <code>[Request</code> interface](https://developer.mozilla.org/en-US/docs/Web/API/Request/Request) van <code>fetch</code>.</p>
<p>Door middel van het response object kan je Remix laten weten dat er een antwoord is met een bepaalde status (zoals <code>201</code> als je iets hebt aangemaakt in de database), of je kan de gebruiker redirecten naar een andere pagina (met een HTTP status code van <code>302</code>). Remix geeft je de <code>json()</code> en <code>redirect()</code> functies voor het gemak, <a href="https://github.com/remix-run/remix/blob/main/packages/remix-server-runtime/responses.ts#L18">want deze zijn niks anders dan wrappers om een <code>Response</code> object heen</a>.</p>
<p>Wat wél leuk is om te weten, is dat je een response ook kan <code>throw</code>'en!</p>
<h2>Foutafhandeling in Remix: ErrorBoundaries en CatchBoundaries</h2>
<p>Remix geeft je twee opties voor foutafhandeling: een <a href="https://remix.run/docs/en/v1/guides/errors">ErrorBoundary</a> en een <a href="https://remix.run/docs/en/v1/guides/not-found">CatchBoundary</a>. In het kort gebruik je de ErrorBoundary voor fouten die je niet anticipeert (zoals <code>500</code> server errors) en CatchBoundaries voor fouten die je anticipeert óf die de flow van je applicatie niet stopzetten (zoals <code>400</code> errors).</p>
<p>Het idee van het Remix-team is dat je <code>default export</code>, het React component dus, je happy path voorstelt. Voor de unhappy path kan je je logica verplaatsen naar een ErrorBoundary of CatchBoundary.</p>
<p>Beide boundaries kan je definiëren in de <code>root.tsx</code>, dat als basis voor iedere pagina gebruikt wordt. Maar de verborgen kracht is dat Remix ook boundaries op routeniveau ondersteunt. Met andere woorden, als er iets fout gaat in je route (of zelfs nested route!) wordt die ErrorBoundary of CatchBoundary getoond.</p>
<p>Terug naar het factuur dashboard, waar we op de URL <code>example.com/sales/invoices</code> een lijst met facturen hadden. Wat nou als je een factuur hebt aangeklikt van een factuur die inmiddels is verwijderd? Bijvoorbeeld omdat je die URL hebt doorgestuurd naar een collega en die kijkt een paar weken later in het systeem.</p>
<p>Stel, de code voor <code>routes/invoices/$invoiceId.jsx</code> is als volgt:</p>
<pre><code>export const loader = async ({ params }) =&gt; {
// &quot;$invoiceId.jsx&quot; wordt omgezet naar een 'invoiceId'
// property op het 'params' object.
const { invoiceId } = params;
const invoice = await db.invoices.find({id: invoiceId});
return json({ invoice });
};
export default function InvoiceDetails() {
const { invoice } = useLoaderData();
return (
&lt;Invoice details={invoice} /&gt;
);
}
</code></pre>
<p>Wanneer een factuur wordt opgevraagd dat niet meer bestaat, gaat de regel <code>const invoice = await db.invoices.find({id: invoiceId});</code> verkeerd: we krijgen dan geen invoice terug, terwijl ons React component daar wél van uitgaat. Wat we kunnen doen is in ons React component het scenario behandelen dat <code>invoice</code> niet aanwezig is.</p>
<p>Wat we ook kunnen doen is een CatchBoundary inzetten voor een 404 fout!</p>
<p>We kunnen de code voor <code>routes/invoices/$invoiceId.jsx</code> zo aanpassen:</p>
<pre><code>export const loader = async ({ params }) =&gt; {
const { invoiceId } = params;
const invoice = await db.invoices.find({id: invoiceId});
if (!invoice) {
throw new Response('missing invoice', {
status: 404,
});
}
return json({ invoice });
};
export default function InvoiceDetails() {
// ...
}
export function CatchBoundary() {
// 'caught' bevat nu de response object informatie
// Het is eigenlijk hetzelfde als useLoaderData
const caught = useCatch();
const params = useParams();
return (
&lt;h1&gt;Sorry&lt;/h1&gt;
&lt;p&gt;We konden geen factuur vinden met nummer { params.invoiceId }&lt;/p&gt;
);
}
</code></pre>
<p>Nou, als je collega een paar weken later in het systeem kijkt voor de inmiddels verwijderde factuur, krijgt die een foutmelding te zien. In het React component dat we als <code>default export</code> zetten hoeven we alleen rekening te houden met het happy path.</p>
<p>We kunnen dit ook inzetten voor fouten die we niet (kunnen) anticiperen. Dus als React component, de <code>loader</code> of een <code>action</code> functie een fout opgooit (of een Response met een error status code van 500), dan wordt de ErrorBoundary getoond:</p>
<pre><code>export const loader = async ({ params }) =&gt; {
// Dus als we hier een throw doen:
throw new Error('Something went wrong!');
};
export default function InvoiceDetails() {
// Of hier:
throw new Error('Something went wrong!');
}
export function CatchBoundary() {
// Dan wordt deze boundary NIET getoond
}
export function ErrorBoundary({ error }) {
// Maar deze wel!
// Pas op, geen 'use' hook hier. We krijgen de error
// doorgestuurd als prop.
console.error(error);
return (
&lt;h1&gt;Oeps...&lt;/h1&gt;
&lt;p&gt;Er is iets fout gegaan. Probeer het later opnieuw.&lt;/p&gt;
);
}
</code></pre>
<p>Als we dit allemaal onder elkaar zetten hebben we een happy en unhappy path voor een route, allemaal in 1 bestand!</p>
<p>Dit is voornamelijk handig wanneer je gebruikt maakt van een CRUD-flow, waarbij een gebruiker ook data kan aanleveren of bewerken.</p>
<h2>Forms</h2>
<p>Naast routes zijn forms ook een groot deel van een Remix applicatie. In de meest simpele vorm kan je een form en de afhandeling ervan als volgt bouwen:</p>
<pre><code>export default function Form() {
return (
&lt;form method=&quot;post&quot;&gt;
&lt;label for=&quot;username&quot;&gt;Gebruikersnaam&lt;/label&gt;
&lt;input type=&quot;text&quot; name=&quot;username&quot; id=&quot;username&quot; /&gt;
&lt;label for=&quot;password&quot;&gt;Wachtwoord&lt;/label&gt;
&lt;input type=&quot;password&quot; name=&quot;password&quot; id=&quot;password&quot; /&gt;
&lt;button type=&quot;submit&quot;&gt;Inloggen&lt;/button&gt;
&lt;/form&gt;
);
}
export const action = async ({ request }) =&gt; {
const body = await request.json();
const accessGranted = checkUserCredentials(body);
if (accessGranted) {
return redirect('/profile');
}
return json({ unauthorized: true }, { status: 403 });
};
</code></pre>
<p>Het leuke hiervan is dat dit werkt <em>zonder JavaScript</em>. Ik zei al eerder dat Remix je wel eens lichtjes in de richting van progressive enhancement duwt, dit is zo'n voorbeeld. Remix voert de volgende stappen uit wanneer iemand op &quot;Inloggen&quot; klikt:</p>
<ul>
<li>De browser serialiseert de data van het formulier in de body van een POST request;</li>
<li>De browser navigeert de gebruiker naar de endpoint van de form (in dit geval is het dezelfde URL, maar met <code>&lt;form action=&quot;/insert-endpoint-here&quot;</code> kan je dit veranderen);</li>
<li>De server verwerkt de request en stuurt een redirect naar de browser (in dit geval wederom naar dezelfde URL, maar dit kan je veranderen);</li>
<li>De browser herlaadt de pagina;</li>
</ul>
<p>Het is ook mogelijk om via <code>onsubmit</code> een <code>fetch</code> handler in te zetten zodat je het formulier kan verzenden en de nieuwe data in kan laden zónder page reload, zodra JavaScript is ingeladen. Maar Remix vangt dit al voor je af met hun <code>&lt;Form/&gt;</code> component.</p>
<p>Dit is een drop-in vervanging voor <code>&lt;form/&gt;</code>, werkt ook hetzelfde als er geen JavaScript is ingeladen, en doet een request zonder page load als JavaScript wél is ingeladen:</p>
<pre><code>export default function Form() {
return (
&lt;form method=&quot;post&quot;&gt;
&lt;label for=&quot;username&quot;&gt;Gebruikersnaam&lt;/label&gt;
&lt;input type=&quot;text&quot; name=&quot;username&quot; id=&quot;username&quot; /&gt;
&lt;label for=&quot;password&quot;&gt;Wachtwoord&lt;/label&gt;
&lt;input type=&quot;password&quot; name=&quot;password&quot; id=&quot;password&quot; /&gt;
&lt;button type=&quot;submit&quot;&gt;Inloggen&lt;/button&gt;
&lt;/form&gt;
);
}
</code></pre>
<p>Maar wat nou als we willen dat de verzend knop niet klikbaar is <em>terwijl</em> de gebruiker wil inloggen (en we dus maar één request naar de server per keer sturen)?</p>
<p>Gebruik <code>useTransition</code>:</p>
<pre><code>export default function Form() {
const transistion = useTransition();
return (
&lt;form method=&quot;post&quot;&gt;
&lt;label for=&quot;username&quot;&gt;Gebruikersnaam&lt;/label&gt;
&lt;input type=&quot;text&quot; name=&quot;username&quot; id=&quot;username&quot; /&gt;
&lt;label for=&quot;password&quot;&gt;Wachtwoord&lt;/label&gt;
&lt;input type=&quot;password&quot; name=&quot;password&quot; id=&quot;password&quot; /&gt;
{ // We hebben hier maar een component maar van gemaakt }
&lt;Button
showSpinner={ transition.state === 'submitting' }
&gt;
Inloggen
&lt;/button&gt;
&lt;/form&gt;
);
}
export const action = async ({ request }) =&gt; {
const body = await request.json();
const accessGranted = checkUserCredentials(body);
if (accessGranted) {
return redirect('/profile');
}
return json({ unauthorized: true }, { status: 403 });
};
</code></pre>
<p>Okee, maar niet alle formulieren zijn in essentie ook een navigatie actie? Denk aan een formulier om je op te geven voor een nieuwsbrief dat op alle pagina's van je website wordt getoond? Of een dark mode toggle voor je blog?</p>
<p>Voor deze zaken heeft Remix <code>useFetcher</code>. Deze geeft je een <code>fetch</code>-achtig object terug dat voor jou een <code>loader</code> of <code>action</code> functie kan aanroepen zonder dat de URL veranderd.</p>
<p>Een simpel voorbeeld van een scenario met <code>useFetcher</code> wijs ik je naar mijn eerdere code voor het dark mode toggle, of lees de <a href="https://remix.run/docs/en/v1/api/remix#usefetcher">Remix documentatie voor <code>useFetcher</code> eens door</a>.</p>
<h2>Optimistic UI</h2>
<p>Dit is een mooi kopje waar ik even in wil duiken. Remix maakt het mogelijk om het &quot;optimistic UI&quot; pattern in te zetten. Hierbij pak je een formulier voor bijvoorbeeld het maken of bewerken van een item of product, en wanneer het formulier wordt verstuurd laat je de server de data van dit product of item bewerken en opslaan in een database. Ondertussen laat jij in je UI &quot;alvast&quot; de pagina zien waarbij je de gegevens van het item of product weergeeft aan je gebruiker. Komt er ergens een foutmelding voorbij? Dan tonen we die, anders gaan we ervan uit dat de opsla-actie lukt en zouden we de gebruiker toch naar deze detailpagina doorsturen.</p>
<p>In het kort: we gaan ervan uit dat de opsla- of bewerkingsactie lukt en laten alvast zien waar je gaat eindigen.</p>
<p>De <a href="https://remix.run/docs/en/v1/guides/optimistic-ui">documentatie van Remix</a> legt dit concept haarfijn uit, beter dan ik het zou kunnen.</p>
<h2>Maar, hoe zit het dan met Next.js 13?</h2>
<p>Een paar weken geleden kwam de Layouts RFC uit van Next.js, waarin ze een plan presenteerden om naast de <code>pages/</code> folder nu ook een <code>app/</code> folder te ondersteunen. Binnen deze folder kon je dan nested routes, shared layouts en React server components gebruiken. Veel ideeën voelde bekend aan als je Remix had gebruikt, en ik heb het idee dat Vercel, het bedrijf achter Next.js, ook zeker goed had gekeken naar de manier waarom Remix werkte.</p>
<p>Dus, nu Next.js 13 uit is, wat is dan nog de meerwaarde van Remix?</p>
<p>Persoonlijk is voelt mij Remix nog steeds het fijnste als framework. Remix geeft mij het gevoel alsof ik mét het web platform, in plaats van óm het platform heen werk. Ik kan dit het beste uitleggen met wat voorbeelden.</p>
<h2>Progressive enhancement</h2>
<p>Dit is voor mij nog steeds een van de hoofdpunten: met Remix werk je makkelijker met progressive enhancement. De discussie over &quot;JavaScript enabled or disabled&quot; is nog steeds gaande, en het is ook niet iets waar ik nu een standpunt voor inneem. Wat ik wél merk, is dat het niet zo'n raar idee is dat je JavaScript niet wordt geladen of juist zo ontzettend traag dat je niet aan de slag kan. Enkele voorbeelden van scenario's die ik mee heb gemaakt waarin een gemiddelde JavaScript bundel niet of nauwelijks werd geladen waren tijdens een weekje op Center Parcs (zeker als meerdere mensen een laptop mee hebben), of als je in Eindhoven op het terras zit tijdens een thuiswedstrijd van PSV of een concert van Guus Meeuwis.</p>
<h2>In dat geval is het &quot;succes ermee!&quot;</h2>
<p>Het is niet zo dat ik met Remix nu ineens geen JavaScript verscheep naar de client, zeker wel. Maar ik merk dat ik, door het off-loaden van logica naar de server of de manier hoe data mutaties worden gedaan door forms, ik minder vaak JavaScript &quot;nodig&quot; heb in de client. De grootste boosdoener is voor mij, hilarisch genoeg, de <code>[classnames](&lt;https://www.npmjs.com/package/classnames&gt;)</code> package van npm.</p>
<p>En het is niet dat Next.js het je zo moeilijk maakt, <a href="https://nextjs.org/docs/accessibility#disabling-javascript">er is een stukje geschreven in hun documentatie</a>. Het leest wel minder zelfverzekerd dan de <a href="https://remix.run/docs/en/v1/guides/disabling-javascript">guide in de documentatie van Remix</a>.</p>
<p>Sterker nog, in de (naar mijn mening uitstekende) tutorial van Remix <a href="https://remix.run/docs/en/v1/tutorials/jokes#javascript">laten ze je pas client-side JavaScript toevoegen aan het einde ervan</a>. Dat is wel lef hebben als je het mij vraagt.</p>
<h2>SSR vs SSG</h2>
<p>Next.js ondersteund al sinds jaar en dag server-side rendering (SSR) en static site generation (SSG). Sinds een tijdje zit daar ook ISR (incremental static regeneration) bij, maar wat is nou het verschil tussen die drie?</p>
<h2>Server-side rendering (SSR)</h2>
<p>Bij SSR wordt de pagina op de server gerenderd en wordt de HTML naar de browser gestuurd. De browser download ondertussen ook de JavaScript bundel en voert die vervolgens uit. Als dat gebeurd, worden de dynamische elementen op de pagina geladen en kan de gebruiker interacteren met wat er op het scherm staat. Dat laatste heet <em>hydration</em>.</p>
<h2>Static site generation</h2>
<p>Bij SSG worden de HTML pagina's tijdens het bouwen van de site opgebouwd. Als je een framework als Next.js (of Gatsby, bijvoorbeeld) naar een database wijst met blog posts, zal er tijdens het bouwen van de site van iedere blog post een HTML pagina worden gemaakt. Dit wordt allemaal op de server gezet, maar als er een blogpost bij komt in de database (of gewijzigd wordt) moet de hele site opnieuw gebouwd worden.</p>
<h2>Incremental static regeneration</h2>
<p>Om dat laatste op te lossen heeft Next.js ISR ingebouwd, waarbij een (gedeeltelijke) rebuild van de site wordt gedaan als de data gerevalideerd wordt. Dit kan op basis van tijd, zoals &quot;iedere 60 seconden&quot;, of <em>on-demand</em>. In Next.js kan je een API route maken die Next.js verteld alles te <em>revalidaten</em> als je die endpoint raakt, bijvoorbeeld met een webhook.</p>
<p>Remix ondersteunt alleen SSR.</p>
<p>Static site generation (daar groepeer ik vanaf nu ook ISR onder), kwam vooral op in de tijd dat servers minder krachtig waren én ook niet al te goedkoop zijn. Voor websites met een zeg maar semi-dynamische content, zoals een blog, scheelde het geld als je die kon hosten op een CDN. Netlify heeft bijvoorbeeld een <a href="https://www.netlify.com/pricing/">gulle <em>free tier</em></a>, dus je kan makkelijk een blog draaien zonder al te veel extra kosten.</p>
<p>Tegenwoordig zijn servers niet alleen krachtiger en goedkoper geworden, de infrastructuur is ook een stuk beter. Het is tegenwoordig niet zo lastig meer om een netwerk van servers in te zetten als CDN. Hosting providers als DigitalOcean maken het makkelijk om meerdere servers (&quot;droplets&quot;) in meerdere regionen in te zetten, en <a href="http://fly.io/">Fly.io</a> heeft zelfs documentatie geschreven over <a href="https://fly.io/docs/reference/scaling/">het scalen in meerdere regio's</a>. <a href="http://fly.io/">Fly.io</a> wordt trouwens meestal aangeraden door het team van Remix zelf, omdat vinden dat een Remix site met correcte caching headers en gehost in meerdere regionen op <a href="http://fly.io/">Fly.io</a>, <a href="https://twitter.com/remix_run/status/1483514038323539972">dezelfde performance geeft als een site gemaakt met SSG</a>.</p>
<p>Of dat zo is, laat ik als een oefening voor de lezer.</p>
<p>Persoonlijk vind ik het juist fijn dat Remix alleen SSR ondersteund. Ik kan de <em>flow</em> makkelijk in mijn hoofd kwijt: eerst server rendering, dan client hydration. In feite zorg ik ervoor dat mijn routes en components werken op de server en makkelijk gehydrateerd kunnen worden. Browser API's doe ik in <code>useEffect</code>, maar dit komt niet eens zo vaak voor.</p>
<p>Bij Next.js projecten moet ik wel eens nadenken of ik kies voor één van de drie strategieën, en SSG/ISR brengen stiekem best wat complexiteit met zich mee. Je moet toch (op zijn een minst simpele vorm van) een build straat aanleggen dat verbonden is met je productie database en het maken van een endpoint om een incremental static regeneration af te vuren is altijd wat werk. Next.js maakt het trouwens in versie 13 wat makkelijk door <a href="https://beta.nextjs.org/docs/upgrade-guide#step-6-migrating-data-fetching-methods">een nieuwe API</a>. Deze werkt trouwens alleen in de <code>app/</code> folder.</p>
<h2>Forms</h2>
<p>Forms is iets dat vak genoemd wordt bij Remix pitches, zeker als het in vergelijking gaat met Next.js. Ik snap het wel, form handling gaat ook ontzettend goed in Remix en is, in mijn ogen, hetgeen dat 100% de visie en gedachtegoed van Remix &quot;ademt&quot;.</p>
<p>Nu is het in Next.js uiteraard mogelijk om met forms te werken, en behandelen ze zelfs <a href="https://nextjs.org/docs/guides/building-forms#part-5-form-submission-without-javascript">het gebruik van forms zonder JavaScript</a>. Maar in Remix voelt het allemaal meer vertrouwd, meer zoals het altijd zou moeten werken. Geen <code>onSubmit</code>'s en <code>event.preventDefault()</code>'s meer, geen handmatige <code>fetch</code> requests meer zodat je onmiddellijk het resultaat van een POST kan laten zien.</p>
<p>In Next.js is dit stuk wel veel verbeterd. Er is een hoofdstuk over data mutaties opgenomen in de <a href="https://beta.nextjs.org/docs/data-fetching/mutating">nieuwe beta documentatie van Next.</a><a href="https://www.notion.so/Remix-en-Next-js-echt-full-stack-bestaat-niet-of-wel-584cb14bdcaa47229bde5270b0f0f1c6">js</a>, en die voelt al meer vertrouwd. Belangrijk om te weten: op deze pagina is laat het team achter Next.js weten dat er een nieuwe RFC komt over data mutaties!</p>
<p>In de <code>pages/</code> folder is dit allemaal niet ondersteunt helaas. Om er op een (voor mij) logische manier mee te werken heb ik <code>[next-runtime](&lt;https://www.npmjs.com/package/next-runtime&gt;)</code> gebruikt in mijn Next.js projecten, waarbij ik POST requests binnen Next.js' <code>getServerSideProps</code> kan verwerken.</p>
<h2>Hoe zit het aan het einde van de dag?</h2>
<p>Nou, aan het einde van de dag ben ik ontzettend onder de indruk van Next.js 13. Ik ga er zeker induiken en ik ben ontzettend benieuwd naar de updates die er nog gaan komen.</p>
<p>Maar voor mij blijft Remix op nummer één staan. Voor mij &quot;klopt het&quot; gewoon, en kan ik ontzettend snel iets neerzetten. De <a href="https://remix.run/docs/en/v1/pages/stacks">starters kits</a> zijn belachelijk uitgebreid en production-ready, en de <a href="https://remix.run/docs/en/v1/tutorials/jokes">Jokes App tutorial</a> is één van de beste tutorials die ik heb gevolgd. Alles klikte toen ik die deed, en ik kan het je zeker aanraden.</p>
<p>Maar wat het belangrijkste is, van zowel Next.js als Remix: ze geven ons front-enders méér tools om ons werk te kunnen doen. Ze bieden meer ruimte en flexibiliteit in ons werk door de <em>server</em> mee te nemen als onderdeel van onze, tjsah, laat ik &quot;runtime environment&quot; zeggen. We opereren niet meer op de zwarte doos dat &quot;de browser van je gebruiker&quot; heet, maar geeft je een extra, betrouwbaar platform dat onderdeel is van je applicatie.</p>
<p>Het maakt ook bepaalde zaken zoveel makkelijker. We hoeven niet meer te wachten op een back-end developer die voor ons een proxy server moet bouwen zodat we een authenticatie token kunnen verbergen én CORS-fouten kunnen vermelden. We bouwen de proxy nu gewoon zelf.</p>
<p>Het maakt de back-end (developer) niet overbodig, het evolueert ons allemaal naar een volledige technologie stack.</p>
<p>Het evolueert ons allemaal naar full-stack.</p>
</content>
</entry>
<entry>
<title>Je eerste keer als spreker</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/je-eerste-keer-als-spreker"/>
<updated>2022-12-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/je-eerste-keer-als-spreker</id>
<content xml:lang="nl" type="html"><p>Misschien ken je het wel: Je zit in de zaal bij de <a href="https://fronteers.nl/congres">Fronteers conferentie</a>, ziet een spreker op het podium staan en denkt &quot;Hey, dat is misschien ook wel eens leuk om te doen&quot;. Of je ziet iemand uit je kring op het overzicht van sprekers staan van een conferentie in New York of Madrid en denkt &quot;wow! Dat is tof! Dat wil ik ook.&quot; Maar ja, hoe pak je dat aan, beginnen als spreker? Want is dat niet lastig? Waar moet ik het over hebben? En hoe maak ik zulke briljante slides en kom ik toch op de proppen met zulke verhalen?</p>
<p>Het lijkt soms best moeilijk. En geloof me, je kan het ook best moeilijk voor jezelf maken. Maar met jaren van ervaring met het spreken op conferenties kan ik zeggen: Je doet het vooral zelf. Het moeilijk maken dus. Want in de basis is het spreken op een conferentie niet heel veel anders als het uitleggen van een concept aan je collega, het presenteren van een design aan een klant of enthousiast vertellen over je hobby aan je beste vriend. Het enige verschil is dat podium.</p>
<h2>Maar waar begin ik dan?</h2>
<p>Nou ja, je begint bij het begin. En dat begin is eigenlijk: Bedenken waar je iets over wil vertellen. Dit hoeft niet per se iets te zijn waar je heel veel van weet, maar als je er al het nodige van weet maakt het alles wel makkelijker. Om echt te bepalen waar je het over wil hebben is het goed om eerst voor jezelf een lijst te maken van onderwerpen waar je interesse in hebt, waar je ook tegen een collega uitgebreid over kan vertellen en/of waar je collega's jou regelmatig vragen over stellen. Als je een lijstje hebt van een paar onderwerpen kies je degene die je het leukst vindt, of waarvan je zoiets hebt &quot;daar zie je maar weinig presentaties over&quot;. Hou er rekening mee dat je, afhankelijk van de conferentie, wel 30-45 minuten over het onderwerp moet kunnen praten. Het moet dus niet <em>te</em> specifiek zijn.</p>
<p>Staar je hier overigens niet op blind, want tijdens de ontwikkeling van je presentatie kan het best zijn dat je toch nog wel iets gaat schuiven met je onderwerp.</p>
<h2>Een onderwerp, en nu?</h2>
<p>Als je eenmaal een onderwerp hebt, dan ga je dat uitdiepen. Dit kan je bijvoorbeeld doen door een <a href="https://nl.wikipedia.org/wiki/Mindmap">mindmap</a> te maken, of een lijst met steekwoorden op te schrijven. Het kan ook helpen om een collega of vriend te vragen of je ze even mag uitleggen over dat onderwerp. Zodra je er op die manier over gaat nadenken kom je vanzelf op de belangrijke kernpunten van je uitleg. En het zal geen verrassing zijn dat die kernpunten dan ook de basis van je presentatie zullen zijn. Als je die basis hebt, dan kan je het verder gaan uitwerken. Wat mij soms helpt is om over het onderwerp een blogpost of zelfs een serie blogposts te schrijven. Tijdens het schrijven daarvan merk je vanzelf welke structuur, volgorde en stijl het beste werkt voor dat onderwerp. Je kan die blogposts direct publiceren, maar ook nog even bewaren voor later.</p>
<p>Als je basis staat en je hebt een gevoel voor de structuur dan kan je ook gaan werken aan je slides. Zoek een tool die prettig voor je werkt. Voor sommigen zijn dat traditionele tools als <a href="https://www.microsoft.com/en-us/microsoft-365/powerpoint">Powerpoint</a> of <a href="https://www.apple.com/keynote/">Keynote</a>, anderen vinden het heel prettig om te werken met <a href="https://revealjs.com/">revealjs</a>, <a href="https://impress.js.org/#/bored">impress</a> of bijvoorbeeld een tool als <a href="https://www.deckset.com/">Deckset</a>, of misschien zelfs <a href="https://prezi.com/">Prezi</a>. Doe wat onderzoek en kies de tool die je het prettigst lijkt. Uiteindelijk gaat het om de inhoud, en niet de tool die je ervoor gebruikt. Zo lang het maar prettig voor je werkt.</p>
<p>Verdeel nu eerst de kernonderwerpen over een aantal slides zodat de structuur van je slidedeck zichzelf al een beetje laat zien. Nu kan je de presentatie verder invullen. Daarbij kan je een aantal do's en don't goed ter harte nemen:</p>
<h2>Font</h2>
<p>Gebruik ten allen tijden een groot font. Zeker in een grote zaal moeten de mensen achterin ook iets kunnen lezen. Gebruik daarbij ook een duidelijk leesbaar font. Mensen moeten in 1 oogopslag kunnen zien wat er op je slide staat. En als je dan denkt &quot;maar dan kan ik niet alles kwijt wat ik kwijt wil&quot;, verwijs ik je door naar mijn volgende punt.</p>
<h2>Hou het kort</h2>
<p>Gebruik geen lange zinnen. Mensen zijn geneigd de zinnen te gaan lezen en terwijl ze lezen ben je ze kwijt als luisteraar. Mensen hebben namelijk moeite met multitasken. Terwijl zij de zin op je slide lezen luisteren ze niet, en tegen de tijd dat ze klaar zijn met lezen weten ze niet meer waar je het nou precies over hebt.</p>
<h2>Bulletpoints</h2>
<p>Gebruik geen lijstjes met bulletpoints, of minimaliseer het. In veel gevallen heeft het weinig meerwaarde om zo'n lijstje te maken, want je bespreekt (hopelijk!) maar 1 bulletpoint tegelijk. In plaats van een bulletpoint kan je ook gewoon een slide per onderwerp gebruiken, met op iedere slide 1 of 2 woorden (die je anders na de bulletpoint zou zetten). Door een slide per onderwerp te maken hou je focus, zowel in jouw verhaal als ook de focus van je luisteraar.</p>
<p>Mocht je toch ergens een reden hebben voor bulletpoints, zorg er dan voor dat ze niet allemaal tegelijk op het scherm verschijnen, maar pas zodra je klikt omdat je naar de volgende bulletpoint gaat. Dit wederom in verband met het risico dat mensen je hele lijstje in 1 keer gaan lezen, en dan ben je ze dus kwijt.</p>
<h2>Ondersteuning</h2>
<p>Je slides zijn er ter ondersteuning van je verhaal, niet voor de mensen die niet bij je presentatie waren. Zorg ervoor dat ze je verhaal dan ook ondersteunen. Zoek bijvoorbeeld een plaatje die goed past bij waar je het over hebt, en combineer dat plaatje met dat ene woord (OK, of misschien 2 woorden) waar je het over hebt. Een aanrader over dit onderwerp is het boek <a href="https://www.bol.com/nl/nl/p/slide-ology-art-science-of-presentatio/1001004006235650/?bltgh=mH34KHD3TfVLM-DsSU9A3w.2_6.10.ProductTitle">Slide:ology van Nancy Duarte</a>.</p>
<h2>Speaker notes</h2>
<p>Als je presentatietool het toestaat, schrijf in de speaker notes per slide de kernonderwerpen waar je het over wil hebben. Dit kunnen kernwoorden zijn, maar bijvoorbeeld ook belangrijke referenties zoals namen van schrijvers, boeken of blogposts die je zeker niet wilt vergeten of verkeerd wil uitspreken. De speaker notes zie je op je eigen scherm als je in presentatiemodus bent en de slides op het grote scherm te zijn zijn. Zie het als spiekbriefjes.</p>
<p>Wil je liever niet telkens op je scherm kijken, dan kan je ook overwegen om indexcards te gebruiken die je in je hand kan houden.</p>
<h2>Help! Ik heb een presentatie!</h2>
<p>Nu je een presentatie hebt wil je dat natuurlijk graag aan de wereld laten weten. Het is verleidelijk om direct conferenties aan te schrijven. Sommige conferenties werken op uitnodigingsbasis, anderen hebben van te voren een manier om je presentatie aan te melden zodat ze weten dat je die beschikbaar hebt. Maak een lijstje met conferenties waar je graag wil spreken en zorg dat je weet hoe je daar binnen kan komen.</p>
<p>Maar voordat je daadwerkelijk over gaat tot het benaderen van conferenties is het goed om te oefenen. Het klinkt misschien gek, maar thuis voor de spiegel is een goede eerste oefening. Zet je huisdier, een pluche beest, je huisgenoot of partner tegenover je zodat je het gevoel hebt dat je tegen iemand praat, en probeer je presentatie uit. Je merkt dan snel genoeg waar je misschien nog wat moet tweaken of zelfs alsnog de volgorde moet aanpassen omdat het dan beter werkt. Hou ook bij hoe lang je doet over je presentatie, want conferenties willen graag dat je presentatie netjes binnen hun schema past. Te kort of te lang is vervelend voor de organisatie van een conferentie.</p>
<p>Als je op deze manier wat geoefend hebt is de volgende stap om eens te kijken naar een klein gezelschap. Een gebruikersgroep of een groep collega's zijn vaak prima manieren om eens voor een groep te spreken en te wennen aan het idee dat er meerdere mensen naar je kijken terwijl je iets vertelt. Vraag ze om feedback voor verbetering. Je presentatie is een levend iets. Het is nooit af, je blijft er altijd aan werken, zelfs als je de presentatie op meerdere conferenties geeft.</p>
<p>En dan is het tijd om toch echt eens conferenties te benaderen. Begin bij de conferenties met een open call for proposals of call for papers. Hiervoor hebt je een goede, korte omschrijving nodig en een pakkende titel. Ook hier: Vraag feedback van vrienden en collega's, of check even met een ervaren spreker. De titel en omschrijving zijn vaak de basis waarop een conferentie je presentatie selecteert (of niet!) dus het moet vooral een beetje prikkelen.</p>
<p>Wees voorbereid op teleurstelling: Veel conferenties krijgen een veelvoud van het aantal open plekken in het schema aan voorstellen. Zo kan een conferentie met 7 plekken in het schema soms wel 100 voorstellen krijgen. De kans bestaat, zeker in het begin, dat je niet gekozen wordt.</p>
<p>Maar dit is het punt waar ik even terug wil komen op die blogposts. Nu je graag door een conferentie geselecteerd wil worden is het een goed moment om te laten zien dat jij echt wel iets weet van dit onderwerp. Publiceer je blogpost of serie blogposts over je onderwerp. Als het formulier van de conferentie een veld heeft met &quot;opmerkingen voor de organisatie&quot;, stuur vooral de links naar je blogposts mee om te laten zien dat je echt veel weet van dit onderwerp. Dit aakt de kans dat je geaccepteerd wordt een stuk groter.</p>
<h2>You've been selected</h2>
<p>En dan valt het mailtje in je mailbox. Een uitnodiging van een conferentie om te komen spreken. Nu gaat het er op aan komen. En goede voorbereiding is het halve werk. Zorg dus voor:</p>
<ul>
<li>Een goede laptop met je presentatiesoftware</li>
<li>Eventuele adapters voor VGA (ja echt!) en HDMI</li>
<li>Een USB stick met je presentatie als backup, met ook een PDF-versie van je slides</li>
<li>Een backup van je presentatie alsmede een PDF-versie van je slides, ergens in &quot;de cloud&quot;</li>
</ul>
<p>Zorg dat je op de conferentie altijd ruim op tijd aanwezig bent op de plek van je presentatie, zodat je op tijd je laptop kan aansluiten. Mocht er iets mis zijn dan heb je nog genoeg tijd om het te fixen.</p>
<p>En ik kan wel zeggen &quot;wees niet nerveus&quot; maar ik weet dat dat niet werkt. Zeker de eerste keer zal je nerveus zijn. Ga dus voor je naar de ruimte gaat eerst nog even naar het toilet.</p>
<h2>Kijk die mensen dan</h2>
<p>Daar sta je. Je gaat beginnen. Spreek rustig en duidelijk, en doe je verhaal. Je hebt dit voorbereid, je kent het verhaal, je hebt je index cards of je speaker notes, het komt goed. Iedereen in die zaal is daar om jou te zien shinen. Niemand is daar om je te zien mislukken. Een foutje kan. Een verspreking kan. Niets aan de hand. Doe je ding. Even de draad kwijt? Neem adem, neem een slok water, kom tot zinnen, check je speaker notes en ga verder. Het komt allemaal goed. Kijk tijdens het presenteren een beetje rond. Kijk niet 1 persoon aan, maar kijk gewoon een beetje rond. Je hoeft niet eens mensen recht aan te kijken, maar als je wat rondkijkt heeft iedereen het gevoel aangesproken te worden.</p>
<p>Als er aan het einde ruimte is voor vragen, wees daar ook niet bang voor. Je kent dit onderwerp, dus die vragen komen ook wel goed. En mocht je het antwoord niet weten, dan is dat ook geen probleem. Je kan vragen of iemand anders in de zaal het toevallig weet, of aanbieden om na afloop even samen met de vraagsteller het op te zoeken.</p>
<p>Zie je wel? Je kon het! Je hebt het gedaan. En als je een beetje bent zoals ik, dan ben je nu verslaafd en ga je nog veel vaker spreken.</p>
<h2>Na de presentatie</h2>
<p>Na de presentatie en het applaus komen er ongetwijfeld mensen op je af. Maar tenzij je de laatste spreker van de dag bent hebt je op dat moment nog wel een taak: Zorgen dat je spullen snel weg zijn zodat de volgorde spreker kan opbouwen. Dus ruim eerst even je spullen op, en mensen met vragen wijs je even de weg naar de deur, om even met je mee te lopen. Buiten de ruimte kan je rustig de tijd nemen om nog wat meer vragen te beantwoorden, maar dan kan het programma gewoon verder en hou je niemand op.</p>
<h2>Het is wel lastig hoor!</h2>
<p>Ik hoor het je al zeggen. &quot;Ik vind dit allemaal wel lastig hoor&quot;. Geen zorgen. Veel ervaren sprekers zijn bereid om nieuwe sprekers te helpen. Benader dus eens een spreker als je twijfelt. De meesten zullen je enthousiast hun anekdotes vertellen, en je helpen om je presentatie tot een succes te maken.</p>
<p>Tot snel op een conferentie!</p>
</content>
</entry>
<entry>
<title>Gezellig, een spelletje</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/gezellig-een-spelletje"/>
<updated>2022-12-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/gezellig-een-spelletje</id>
<content xml:lang="nl" type="html"><p>Je zit met de hele familie onder de kerstboom en de veilige gespreksonderwerpen raken uitgeput. Om het gezellig te houden stel je voor om een spelletje te doen. De meesten hebben wel zin in Scrabble, maar je kan die doos nergens vinden! Geen paniek, je bouwt gewoon je eigen spel. Met HTML en CSS timmer je dat bord zo in elkaar.</p>
<p>Bekijk het bord <a href="https://peterdoolaard.nl/blog/gezellig-een-spelletje-scrabble/">in real life action</a>.</p>
<p>CSS Grid Layout is een van de beste toevoegingen aan CSS van de laatste jaren. Kort gezegd definieer je daarmee een raster of grid van rijen en kolommen waarop je items plaatst, en die items kunnen meerdere rijen en kolommen overspannen. Het grid zelf kan volledig vastliggen of flexibel zijn. Zowel het aantal rijen en kolommen als de afmetingen van die rijen en kolommen kun je laten afhangen van de beschikbare ruimte.</p>
<p>Een van de grote voordelen is dat je dingen zo lekker makkelijk kunt stapelen. Niks <code>position: relative</code> en <code>position: absolute</code>. Plaats items gewoon in dezelfde kolom en rij. Posities schalen probleemloos mee met de container zonder gedoe met offsets.</p>
<p>Bij een CSS-grid heb je altijd een parentrelement en childelementen nodig. De parent is de container die de definitie van het grid bevat en de children zijn de items die in het grid komen te staan. Zonder children heb je dus geen zichtbare content in het grid.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/advents-peter-scrabble.png" alt="Een scrabblebord met daarop de woorden Fijne feestdagen, gelukkig nieuwjaar gespeld" /></p>
<h2>Een grid voor het spelbord</h2>
<p>Het ontwerp van een spelbord is een grid en bij Scrabble zie je dat heel duidelijk. Het bord bevat 225 vakjes verdeeld over 15 rijen en 15 kolommen. Je hebt dus 15 x 15 = 225 items nodig om het bord een gezicht te geven. Dat zijn 225 <code>span</code>-elementen waarvan de meeste een grijze achtergrond hebben. Een deel heeft een data-attribuut dat de bonus aangeeft, bijvoorbeeld ``data-bonus=&quot;3 x woord waarde&quot;`.</p>
<p>Zo ziet de gridefinitie eruit:</p>
<pre><code>.speelbord {
display: grid;
grid-template-columns: repeat(15, 4.25rem);
grid-template-rows: repeat(15, 4.25rem);
}
</code></pre>
<p>Het aantal <code>span</code>-elementen is gelijk aan het aantal rasterplaatsen (cellen). Daardoor is het niet nodig om elk item expliciet op zijn plek te zetten. De items lopen in volgorde van de HTML vanzelf het raster in vanaf rij 1, kolom 1 naar rij 15, kolom 15. Je moet wel zelf uittellen welke items een data-attribuut moeten hebben.</p>
<h2>Een oplossing voor de letters</h2>
<p>Ook de letters zijn griditems en moeten dus net als de bordvakjes in een gridcontainer staan. Het verschil is dat de letters een specifieke positie in het raster hebben. Ze kunnen dus sowieso niet automatisch het raster inlopen.</p>
<p>Je kúnt de letters onder het laatste <code>span</code>-element van het spelbord zetten. Daarmee voeg je ze toe aan het speelbordgrid. Maar zodra je een letter in het grid positioneert, valt het speelbord uit elkaar. De gepositioneerde letter neemt namelijk de plek in van een bordvakje dat geen vaste plek heeft. Daardoor schuift dat bordvakje een positie op en dat doen ook alle vakjes daarna.</p>
<p>Je hebt de keus uit twee oplossingen:</p>
<ol>
<li>
<ul>
<li>Geef alle 225 bordvakjes een positie in het grid met <code>grid-area: 1 / 1;</code> <code>grid-area: 1 / 2</code>; tot en met <code>grid-area: 15 / 15</code>.</li>
</ul>
</li>
<li>
<ul>
<li>Maak een tweede gridcontainer voor de letters, met precies dezelfde eigenschappen als het speelbord. Dit grid leg je boven op het speelbordraster. Nu hoef je alleen de letteritems op hun plek te zetten.</li>
</ul>
</li>
</ol>
<p>De eerste oplossing is een krankzinnig monnikenwerk en alleen aan te raden als je de feestdagen eigenlijk liever alleen doorbrengt.</p>
<p>Oplossing twee is veel minder werk en overzichtelijk, met alle letters bij elkaar in hun eigen container.</p>
<p>De grids moeten natuurlijk precies op elkaar liggen. Met een extra grid is dat geen enkel probleem. Zet het <code>.speelbord</code> en het <code>.lettergrid</code> samen in een nieuwe container met een griddefinitie voor één rij en één kolom (dus één cel):</p>
<pre><code>.buitengrid {
display: grid;
grid-template-columns: minmax(320px, 1fr);
grid-template-rows: minmax(320px, 1fr);
margin: 2px;
max-inline-size: 1020px;
}
</code></pre>
<p>Deze ene cel is responsive. De minimale maat is 320px en daarboven krijgt de cel zoveel ruimte als er is. De eenheid fr (fraction) is speciaal voor de gridlay-out toegevoegd aan CSS. Een fr staat voor een evenredig deel van de beschikbare ruimte. Voorbeeld: twee kolommen van elk 1fr krijgen elk de helft van de beschikbare ruimte. Zijn ze elk 2fr, dan krijgen ze ook elk de helft. Is de instelling 2fr en 1fr, dan krijgen ze respectievelijk twee derde en een derde. Op zo’n manier maak je elke gewenste verhouding.</p>
<p>Om ervoor te zorgen dat de tekst en de vakjes responsive zijn, is op het rootelement een tekstgrootte op basis van de viewport ingesteld. Het font is 1.55 maal de kleinste viewportafmeting, dat kan dus de breedte of de hoogte zijn. Op een iPhone SE (375 x 667) is het font 375/100 x 1.55 = 5.8px. Dat leest niet echt lekker, maar ja, je moet wel die 15 vakjes kwijt. Een 4K-televisie is een betere keus, met als kleinste afmeting 2160px en een fontgrootte van 33.46px.</p>
<pre><code>:root {
font-size: 1.55vmin;
}
</code></pre>
<p>Vervolgens plaats je het bordraster en het letterraster allebei in rij 1, kolom 1:</p>
<pre><code>.speelbord, .lettergrid {
grid-area: 1 / 1;
}
</code></pre>
<p>De eigenschap <code>grid-area</code> is een korte notatie voor <code>grid-row-start</code>, <code>grid-column-start,</code> <code>grid-row-end</code> en <code>grid-column-end</code>. Laat je de eindwaarde weg, dan is het item vanzelf 1 rij bij 1 kolom. Je kunt ook schrijven <code>grid-area: 1 / 1 / 2 / 2</code>. (Gebruik <code>grid-area</code> ook om items in <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/grid-template-areas">gebieden met een naam</a> te plaatsen.)</p>
<p>Voor de stapelvolgorde van het bord en de letters geldt de normale volgorderegel: later in de HTML ligt hoger op de stapel. Als het nodig is kun je de volgorde met <code>z-index</code> eenvoudig aanpassen. In de grid-context verander je met <a href="https://w3c.github.io/csswg-drafts/css-grid/#z-order">z-index de stapelvolgorde zonder dat je position</a> op iets anders dan <code>static</code> hoeft in te stellen.</p>
<h2>De speciale bordvakjes</h2>
<p>Met een algemene childselector op het spelbord krijgen alle speelvakjes dezelfde basisopmaak. Die vakjes zijn 4rem groot, terwijl de rastercellen 4.25rem zijn. Door de vakjes te centreren in de cel blijft er zo rondom wat witruimte tussen de vakjes.</p>
<pre><code>.speelbord &gt; * {
align-items: center;
background-color: lightgrey;
block-size: 4rem;
display: flex;
font-family: sans-serif;
font-variant: small-caps;
inline-size: 4rem;
text-align: center;
}
</code></pre>
<p>Elk vakje is een flexcontainer. De enige reden daarvoor is het makkelijke verticaal centreren. Het had wat dat betreft ook een gridcontainer kunnen zijn. Horizontaal is de tekst gecentreerd met <code>text-align</code>.</p>
<p>Voor de speciale vakjes hangt de opmaak af van het data-attribuut <code>data-bonus</code>. De tekst van <code>data-bonus</code> wordt ingelezen als content voor het pseudo-element <code>::before</code>. Met de attribuutselector ‘waarde moet beginnen met’ worden de verschillende stijlen toegepast.</p>
<pre><code>[data-bonus]::before {
content: attr(data-bonus);
}
[data-bonus^=&quot;3 x woord&quot;] {
background-color: red;
box-shadow: 0 0 2px 1px red;
}
</code></pre>
<h2>Opmaak van de lettervakjes</h2>
<p>De CSS voor de lettervakjes is wat uitgebreider, maar bijzonderheden zijn er niet. De letter komt uit een data-attribuut, net als de puntwaarde van de letter. Het vakje is een flexcontainer voor de uitlijning van de letter. De letterwaarde is absoluut gepositioneerd. Je zou dat allemaal kunnen vervangen door een grid, maar daar wordt de code niet beter of duidelijker van.</p>
<pre><code>&lt;span class=&quot;letter&quot; data-letter=&quot;F&quot; data-waarde=&quot;4&quot;&gt;&lt;/span&gt;
</code></pre>
<pre><code>.letter {
align-items: center;
background-color: hsl(33 100% 88%);
block-size: 4rem;
box-shadow: 1px 1px 4px hsl(33 100% 20%);
color: hsl(33 0% 5%);
cursor: pointer;
display: flex;
font-size: 2rem;
font-variant: small-caps;
inline-size: 4rem;
justify-content: center;
margin: 1px;
padding: .5rem;
position: relative;
text-transform: capitalize;
transform: translate(-1500px, -1500px);
}
.letter::before {
content: attr(data-letter);
}
.letter::after {
bottom: 0.5em;
content: attr(data-waarde);
font-size: 50%;
position: absolute;
right: 0.5em;
}
</code></pre>
<p>De regel <code>transform: translate(-1500px, -1500px)</code>; plaatst alle letters buiten beeld, zodat ze bij het laden van de pagina met een animatie op hun plek gezet kunnen worden. Het is een eenvoudige translate-animatie, maar je kunt het natuurlijk zo gek maken als je wilt.</p>
<p>De trigger zit in de letterselectors, dat zijn allemaal genummerde childselectors. De animatieregel bevat achtereenvolgens de naam van de animatie, de duur en het effect. Daarna komt de startvertraging en die is bij elke volgende letter wat langer, zodat de letters na elkaar worden geplaatst. Als laatste zorgt <code>forwards</code> ervoor dat het laatste beeld van de animatie blijft staan. Zonder die aanwijzing zou de letter gelijk weer uit beeld verdwijnen, volgens de transformregel in de klasse <code>.letter</code>.</p>
<pre><code>.letter:nth-child(10) {
grid-area: 6 / 6;
animation: drop-letter .5s ease-in-out 2.0s forwards;
}
@keyframes drop-letter {
0% {
transform: translate(-1500px, -1500px);
}
50% {
transform: translate(-250px, -250px);
}
100% {
transform: translate(0, 0);
}
}
</code></pre>
<p>Op dit punt heb je een scrabblebord waarop vanzelf letters worden geplaatst. Speelbaar is het nog niet. Daar ga ik een jaartje over nadenken!</p>
</content>
</entry>
<entry>
<title>Zure developers &amp; uitnodigende communicatie</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/zure-developers-uitnodigende-communicatie"/>
<updated>2022-12-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/zure-developers-uitnodigende-communicatie</id>
<content xml:lang="nl" type="html"><p>Iedereen kent ze wel. De zuurpruimen, de klagers. Niets is ooit goed genoeg, en het probleem ligt altijd bij de incompetentie van anderen. Misschien komt er wel meteen een naam en gezicht bij je in beeld. Ik geef toe, ik ben zelf ook niet vies van een beetje gezanik en gezeur.</p>
<p><em>De doelstelling van Fronteers is de professionalisering van het beroep front-end web development. Daarbij streven
wij naar erkenning, verbetering en ondersteuning van de (positie van) Nederlandstalige front-end webontwikkelaars.</em></p>
<p>Als je kijkt naar de doelstelling van onze vereniging dan is er zelfs na 15 jaar nog genoeg werk aan de winkel. De vraag is hoe we andere developers en stakeholders in onze doelen geïnvesteerd krijgen. We moeten immers een hoop mensen uitnodigen in ons wereldje, zodat ze zien wat wij zien. Genoeg van ons praten gelukkig al met developers, marketeers, product- en projectmanagers, designers, etc.</p>
<h2>Ontmoet de zuurpruim</h2>
<p>Maar daar is dan de zuurpruim. Die maakt iedereen die het niet snapt liever belachelijk. Die noemt React een div-soep. Tailwind CSS fans die snappen niets van <em>echte</em> CSS. En als iemand site een <code>&lt;div&gt;</code> als knop gebruikt, of niet toegankelijk is, dan kunnen ze beter iets anders met hun leven gaan doen.</p>
<p>Natuurlijk krijgt een conferentiespreker de lachers op de hand door een stukje lelijke DOM te laten zien. En kan men lekker <em>bonden</em> tijdens een borrel met front-end devs die het wel snappen. Maar wat mij betreft missen we vaak een kernwaarde die we nodig hebben om onze front-end wereld een stukje beter te maken. En die kernwaarde is <em>uitnodigend zijn</em>.</p>
<h2>Onze communicatie nodigt niet uit tot communiceren.</h2>
<p>Want leg eens uit: Hoe kom je af van je imposter syndroom als je fouten belachelijk worden gemaakt op een conferentiepodium? Waarom zou je de nieuwe mogelijkheden van CSS leren als jouw JavaScript oplossing als <em>dom</em> wordt bestempeld? Waarom zou je als designer HTML/CSS leren als een frontend developer zucht en puft als je een ontwerp aanlevert?</p>
<p>En daarom is mijn oproep in deze feestmaand om iets geduldiger te worden. Iets liever te zijn. Anderen meer uit te nodigen in je communicatie. Om een keer diep uit te ademen, te ontspannen, en te vragen:</p>
<ul>
<li>&quot;Mag ik je iets leren?&quot;</li>
<li>&quot;Mag ik je iets tofs laten zien?&quot;</li>
<li>&quot;Ik denk dat dit handiger kan, wil je weten hoe?&quot;</li>
<li>&quot;Kun je me uitleggen waarom je deze oplossing hebt gekozen?&quot;</li>
</ul>
<p>En misschien dat deze uitnodigende communicatie ervoor zorgt dat we geen tegenstanders zien, maar medestanders worden. En misschien, heel misschien... Leer je ook nog iets van een ander.</p>
<h2>Fijne feestdagen en een uitnodigend nieuw jaar!</h2>
</content>
</entry>
<entry>
<title>Ik ben een div</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/ik-ben-een-div"/>
<updated>2022-12-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/ik-ben-een-div</id>
<content xml:lang="nl" type="html"><p>Stond er wekenlang als werktitel in de planning. Klinkt niet echt veelbelovend. Ronduit saai eigenlijk.</p>
<p>Een div is vaag, en vooral nikszeggend.</p>
<p>'Does not inherently represent anything'.</p>
<pre><code>&lt;div&gt;&lt;/div&gt;
</code></pre>
<p>Daar kun je natuurlijk niet echt veel mee. En ook eigenlijk alles. Je kunt er van alles instoppen net als een kerstpakket, je kunt het een thema (of type) meegeven, en versiering, maar het blijft een ‘domme doos’.</p>
<p>Een div kun je overal voor gebruiken, het werkt altijd en doet wat je ervan verwacht. Oppervlakkig gezien. Want de div is ook onzichtbaar en betekenisloos.</p>
<pre><code>&lt;div
type=&quot;hidden&quot;
id=&quot;whatever&quot;
style=&quot;background-color:grey; background-position: inherit;&quot;&gt;
&lt;/div&gt;
</code></pre>
<p>En ik kan het weten, want ik ben er een.</p>
<p>Al jaren lang ben ik de Div van de afdeling. Ik doe mijn best om me aan te passen, <span> me best in, maar neem niet echt stelling. Het liefst zet ik mijzelf op een onopvallende background-position en doe zoveel mogelijk de dingen die van me verwacht worden.</span></p>
<p>Dat is de weg van de minste weerstand, maar ook risicoloos. Voor je het weet hoor je bij het onopvallende meubilair die niemand meer opmerkt, maar waar ook weinig collega's moeite mee hebben. Zoals een kantoorplant.</p>
<pre><code>&lt;div type=&quot;text&quot; id=&quot;succulent-plant&quot;&gt;Ik ben een kantoorplant&lt;/div&gt;
</code></pre>
<p>Het heeft met mijn persoonlijkheid te maken, en ook met een generatiekloofje. Als ouwe lul ben ik niet opgegroeid met computers, ook nog niet tijdens mijn opleiding tot grafisch vormgever. Op de kunstacademie werd eind jaren 80 ineens een zolderruimte ingericht met een aantal Apple computertjes en Aldus Freehand 2.0, en daar mochten we een uurtje per week mee klooien.
Pas rond mijn vijfigste ben ik web development in gerold, nu 6 jaar geleden. Dankzij een erfenis kon ik mezelf om laten scholen, en ik vond het allemaal geweldig.</p>
<p>Maar om als vrouw en 50 plusser nu het vak in te rollen, ervaar ik als een kleine cultuurshock. Een onzekere
persoonlijkheid maakt niet alleen dat je jezelf op de achtergrond houdt, maar ook dat als je vindt dat je een punt
hebt of ergens meer van weet dan je collega's, dat je toch gaat twijfelen aan je ideeën, want waarom zou ik in m'n eentje iets vinden waar al mijn jonge hoog opgeleide collega's anders over denken? Kom dan maar eens overtuigend uit de hoek. Een div die z'n mond open doet is op z'n zachtst gezegd even wennen.</p>
<p>Er werd ook een beetje lacherig op gereageerd. 'We hebben het al veel te druk, en het werkt toch? Het feit dat we iets opleveren is veel belangrijker. Dit heeft geen prioriteit.' Geef ze maar eens ongelijk. Dit is hun wereld, dus willen ze graag de div houden. In de code en in het team.</p>
<p>Maar vanaf dat moment begon ik ook serieus te twijfelen of ik dit soort werk wel wil doen. En dan bedoel ik het werken aan de technische kant van de frontend van een grote app, waar de kwaliteit van de HTML en CSS een ondergeschikte rol hebben. Misschien hou ik het vol omdat ik mezelf niet wil laten kennen en mensen om me heen trots op me zijn, en ik niemand teleur wil stellen. Misschien omdat ik eindelijk een volwaardig salaris kan verdienen. Misschien omdat ik al jaren mijn geld en vrije tijd besteed aan het leren programmeren, en ik niet durf toe te geven dat het mij misschien niet echt ligt. Maar om eerlijk te zijn word ik er ongelukkig van. Ik kom regelmatig thuis van mijn werk en trek een flesje open. Of mijn man vraagt hoe het gaat en dan voel ik ineens de tranen stromen. En ik ben alleen nog maar moe.</p>
<p>Ik ga de div hier niet uit de code halen maar wel uit mezelf.</p>
<p>En hopelijk ergens anders uit de code.</p>
<p>Want ik weet best wel waar ik wel gelukkig van word. En mijn zelfvertrouwen en energie weer terugkrijg. Van concepten bedenken en mooie dingen maken, van CSS, HTML en JavaScript, van design, van websites, illustraties en animaties. Dan ben ik geen div en stel me ook niet zo op. Dat maakt me ook veel toegankelijker.</p>
<p>Advent is, net als welke periode dan ook, een perfect moment om na te denken over het vervangen van een oude <code>&lt;jas&gt;</code> en in een andere rol te kruipen, eentje die beter bij me past en met betekenis. De geboorte van een <code>&lt;article&gt;</code>, voor onder de kerstboom. Bij deze. Of in dit geval; erin, voor wie de code reviewt. Of hang 'm in de kantoorplant, wie weet wat daar nog uit voortkomt.</p>
<pre><code>&lt;main&gt;
&lt;article&gt;
&lt;h1&gt;Fijne feestdagen!&lt;/h1&gt;
&lt;/article&gt;
&lt;/main&gt;
</code></pre>
<h2>En om de vooruitzichten nog iets mooier te maken:</h2>
<pre><code>body {
margin: 0;
height: 100vh;
color: gold;
}
main {
display: block;
margin: 0 auto;
padding: 3.125rem 1.875rem 0;
}
main article {
position: relative;
margin: 10% auto;
width: 12.5rem;
height: 12.5rem;
border-radius: 100%;
background-color: rgba(255,255,255,.75);
box-shadow: inset -2.5rem -3.75rem 2.5rem -1.875rem rgba(0,0,0,.4),
inset -3.125rem -2.5rem 15px 80px currentColor;
transition: 1s box-shadow;
}
h1 {
position: absolute;
top: 14rem;
text-align: center;
font-size: 2rem;
font-family: sans-serif;
color: darkgrey;
}
main article::before {
content: &quot;&quot;;
position: absolute;
left: 5.313rem;
top: -2.75rem;
width: 1.25rem;
height: 1.25rem;
border: solid 5px lightgrey;
border-radius: 100%;
}
main article::after {
content: &quot;&quot;;
position: absolute;
left: 4.625rem;
top: -1.375rem;
width: 2.5rem;
height: 1.25rem;
background: linear-gradient(80deg,#F7F7F7,silver) content-box;
border-style: solid;
border-width: 0 5px 7px;
border-color: lightgrey transparent;
border-radius: 100% / 25%;
}
</code></pre>
<p>Met dank aan <a href="https://codepen.io/Kseso/pen/wMvOxb">Kseso op Codepen</a></p>
</content>
</entry>
<entry>
<title>Valkuilen van toegankelijke componenten</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/valkuilen-van-toegankelijke-componenten"/>
<updated>2022-12-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/valkuilen-van-toegankelijke-componenten</id>
<content xml:lang="nl" type="html"><p>Al zijn je bouwblokken (componenten) nog zo mooi, je kan er nog steeds verkeerd mee bouwen!</p>
<p>Steeds vaker zie je dat componenten claimen toegankelijk te zijn. Dat klinkt goed: componenten die voor iedereen te gebruiken zijn, ook voor mensen met beperkingen! Wat zo’n claim precies inhoudt is niet altijd duidelijk. Daarnaast geeft het je als bouwer ook geen garanties. Je kan er nog steeds een zooitje van maken!</p>
<p>Wat kan er zoal misgaan? We bekijken een aantal veel voorkomende valkuilen.</p>
<h2>Waar zijn componenten goed voor?</h2>
<p>Componenten zijn geweldig voor alles wat je meer dan één keer moet doen. Je wil niet telkens je button of link opnieuw ontwerpen en bouwen. Dat is zonde van je tijd. Liever bouw je één versie die heel goed is, en dan kun je die hergebruiken. Waarom vaak iets half bouwen, als je ook al die tijd in één hele goede versie kan steken? Die ene versie kun je dan testen met verschillende browsers, mobiel, met screen readers en hopelijk zelfs met echte gebruikers!</p>
<p>Wat je dan ook meteen krijgt is consistentie. Daar maak je iedereen blij mee! Denk bijvoorbeeld aan een focus-state die overal hetzelfde is. Dat scheelt een hoop denkwerk.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toepassing-blog-erik-full.png" alt="Een plastic speelset geplaatst op de dakrand van een flat." /></p>
<p><em>Het zit hem helemaal in de toepassing.</em></p>
<h2>Pagina-specifiek: content</h2>
<p>De ene pagina is de andere niet. En juist in de onderdelen die variëren kan het natuurlijk alsnog verkeerd gaan.</p>
<h3>Content</h3>
<p>Een beetje een inkoppertje misschien maar goed om bewust van te zijn. Voor elke pagina schrijf je content. Die moet toegankelijk zijn. Hierbij kun je denken aan het vermijden van complex taalgebruik, en het vermijden van omschrijvingen op basis van specifieke zintuigen (zoals een “open de rode link” of “de tekst rechts hiervan”).</p>
<p>Content gaat ook verder dan paragraafjes en tekstblokjes. Vergeet niet je alternatieve teksten voor afbeeldingen, of captions en transcripties voor andere media-bestanden.</p>
<h3>De paginatitel</h3>
<p>Laat deze zoveel mogelijk overeen komen met de belangrijkste heading op je pagina (de <code>&lt;h1&gt;</code>) en de namen van de links die naar de pagina verwijzen. Als er herhalende delen in de titel zitten (zoals de naam van de website) plaats die dan zoveel mogelijk naar achter in de titel. Dit maakt scannen (ook met screen readers) makkelijker. Het unieke en onderscheidende deel komt vooraan.</p>
<p>Je krijgt in een webshop iets als: “Product - categorie - <a href="http://webshopnaam.nl/">webShopNaam.nl</a>”</p>
<h2>Pagina-specifiek: structuur</h2>
<p>Misschien heb je hier deels wel iets herbruikbaars voor, zoals templates. Dat is enorm fijn. De ervaring leert echter dat deze niet altijd beschikbaar zijn, en niet de prioriteit hebben.</p>
<h3>Landmarks</h3>
<p>Voor elke pagina wil je je landmarks op orde hebben:</p>
<ul>
<li>Plaats je navigatie in een <code>&lt;nav&gt;</code></li>
<li>Plaats de belangrijkste content in een <code>&lt;main&gt;</code></li>
<li>Gebruik aan het begin van je pagina een <code>&lt;header&gt;</code> en aan het eind een <code>&lt;footer&gt;</code></li>
<li>Heb je informatie die terzijde is? Gebruik dan een <code>&lt;aside&gt;</code></li>
</ul>
<h3>Heading structuur</h3>
<p>Je headings helpen mensen navigeren door je pagina. Net zoals je koppen kan scannen in een krant, zo wil je dat op een website ook.</p>
<p>De <code>&lt;h1&gt;</code> is voor de belangrijkste heading; voor waar je pagina overgaat. Daaronder wil je een soort boomstructuur maken van je headings. Alle content valt logischerwijs (zowel visueel als in code) onder één van je headings. Je gaat van hoofdonderwerp (<code>&lt;h1&gt;</code>) naar deel-onderwerp (<code>&lt;h2&gt;</code>), naar deel-deel-onderwerp (<code>&lt;h3&gt;</code>), en zo verder. Nooit meer dan één stap tegelijk vooruit.</p>
<h3>Focus volgorde</h3>
<p>Zorg ervoor dat elke pagina waar je met je tab-toets doorheen gaat logisch navigeert. Dit gaat makkelijker als je geen <code>tabindex</code> gebruikt met een waarde hoger dan 0. Ook creatief toepassen van CSS grid of flexbox kan de visuele volgorde laten afwijken van die in de code.</p>
<p>Wil je het je bezoeker helemaal makkelijk maken? Voeg een skip link toe. Dat is een (vaak verborgen) link aan het begin van de pagina waarmee je naar de content kan “springen”.</p>
<h2>Lastig te testen</h2>
<h3>Variaties van componenten</h3>
<p>Hoe meer features een component heeft, hoe groter de kans dat het mis gaat. Als component een boolean-attribuut, dark mode en twee responsive zoom-niveaus heeft, dan zit je al snel op (2x2x3=8) acht variaties die allemaal getest en onderhouden moeten worden. Let hier dus op! Als iedereen om je heen standaard dark mode aan heeft staan, reken maar op issues in light mode.</p>
<h3>Compositie</h3>
<p>Zodra je componenten gaat combineren kun je ook problemen voorzien. Het liefst zie je bijvoorbeeld dat formulieren als een compleet systeem ontwikkeld en gebundeld zijn. In formulieren combineer je vaak dezelfde componenten. Worden ze los geleverd dan kunnen er onverwachte (en ongeteste) situaties ontstaan. Weer een punt van aandacht!</p>
<p>Hieraan gerelateerd is ook het onderwerp van relaties. Alles wat je zelf aan elkaar knoopt is gevoelig voor fouten. Als je bovenaan je pagina een table of contents hebt, moet je goed opletten hoe die verbonden is aan de content van je pagina. Of wat dacht je van een formulier(veld) en een foutmelding of instructie? Relaties wil je zowel visueel als in de code helder hebben.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/advents-erik-2.jpeg" alt="Een projector hangt aan een muur. Een scherm hangt er opgerold boven. Het scherm kan zo niet uitgerold worden, en de projector kan er niet op projecteren." /></p>
<p><em>De juiste onderdelen in de verkeerde volgorde.</em></p>
<h3>Website-breed</h3>
<p>Zoals eerder benoemd zijn componenten goed voor consistentie. Is je set componenten nog niet heel volwassen of volledig, dan kan dit nog een punt van verbetering zijn.</p>
<p>Zo kunnen focus states tussen pagina’s en components nog verschillen als dit niet goed centraal bedacht en uitgevoerd is.</p>
<p>Een ander verbeterpunt in de bredere structuur is vaak de navigeerbaarheid. Je wil dat pagina’s op meer dan één manier te vinden en benaderen zijn. Denk aan een zoekfunctie of sitemap naast je menu-structuur. Typisch iets wat je niet kan oplossen met een component. Zorg dat al je pagina’s hier onderdeel van uitmaken en duidelijk vertegenwoordigd zijn.</p>
<h3>Voorbij de valkuilen</h3>
<p>Stel je waakt nu voor al deze valkuilen. Weet je dan zeker dat het goed komt? Nee, helaas! Je kan nog steeds het verkeerde component kiezen bijvoorbeeld! Je hebt geen garantie voor een toegankelijk eindresultaat. De kans dat het je lukt met toegankelijke componenten is wel vele malen groter dan zonder!</p>
<p>Componenten zijn als de basis van een huis. Bouw je met scheve kozijnen op drijfzand? Succes! Een stevig fundament met kwalitatieve onderdelen is wat je wil. Maar ook daarmee kun je een huis bouwen dat tekort schiet!</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/advents-erik-3.png" alt="Een muur met hoekjes en een bocht met een plint. De plint is in allemaal losse stukjes in een vergeefse poging om de vorm van de muur te volgen." /></p>
</content>
</entry>
<entry>
<title>Persoonlijke ontwikkeling</title>
<link href="https://www.fronteers.nl/nl/blog/2022/12/persoonlijke-ontwikkeling"/>
<updated>2022-12-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/12/persoonlijke-ontwikkeling</id>
<content xml:lang="nl" type="html"><p>Als front end developer bevindt je je in de luxe positie om in het midden te zitten van meerdere disciplines, zoals back end development, UX, design en project management. Doordat je daar in het midden zit heb je ook de mogelijkheid om je te bewegen of te verschuiven in één van die richtingen. Nu zal je daar natuurlijk niet altijd bewust mee bezig zijn, maar soms gebeurt dat van nature, zoals in mijn geval.</p>
<h2>Ome Robert vertelt</h2>
<p>Ikzelf heb ongeveer vijftien jaar voor verschillende kleine en grote agencies gewerkt en voor kleine en grote klanten websites gebouwd als front end developer.</p>
<p>Maar soms heb je zo’n moment in je carrière dat het een beetje begint te jeuken. Wil ik dit wel doen tot mijn pensioen? Hoever kan ik doorgroeien? Wil ik wel doorgroeien? Wil ik iets compleet anders gaan doen? En dan kom je erachter dat de positie die ik eerder beschreef eigenlijk wel verrekte handig is. Je kan natuurlijk ook compleet uit de IT stappen en dat hippe koffietentje willen beginnen… of: je blijft binnen je vakgebied en je kijkt wat breder naar de omgeving waar je in werkt.</p>
<p>Ik had dat dus in 2007. Ik heb toen de stoute schoenen aangetrokken en besloten om me te verdiepen in project management. Op eigen kosten een cursus gedaan, veel inlezen, maar natuurlijk: geen praktijkervaring. Toch besloot ik om wat open sollicitaties de deur uit te doen en zowaar ben ik aangenomen bij een bedrijf waar ik echt heel graag wilde werken! Supervet, maar ik kwam daar echt niet lekker uit de startblokken en ik kreeg weinig steun en hulp.</p>
<p>Dus terug naar front end development… en in 2015 kwam ik toevalligerwijs terecht bij Rietveld Licht. Geen agency, maar wel een webshop die heel veel liefde nodig had. Het grootste verschil: ik was de enige front end developer en mijn enige collega is een back end developer. En wat doe je dan als front end developer die (zoals ik) best wel veel met design bezig is: Lekker ontwerpen! En dan natuurlijk direct in HTML en CSS, want dat is waar ik me in thuis voel en wat ik kan dromen. En vanaf daar werd het eigenlijk steeds breder en leuker: Logo ontwerpen voor ons eigen internationale merk? Check! Me bemoeien met SEO, social media en marketing? Check! Enge dingen doen met Google Analytics en Tagmanager? Check!</p>
<p>Wat hierna komt? Geen idee. Lampen ontwerpen en ontwikkelen misschien?</p>
<h2>Het is ook nooit goed</h2>
<p>Nu denk je natuurlijk: ja Robert, leuk zo’n verhaal, maar wat kan ik ermee?</p>
<p>Ik denk dat het goed is om regelmatig eens van een afstandje te kijken naar waar je nu bent. Ben je een junior developer die nog nat is achter de oren of ben je een enorme senior die eigenlijk niet verder kan groeien? Waar liggen je interesses? Je échte interesses bedoel ik dan, die interesses waar je blij van wordt. Dat kan natuurlijk compleet front end gerelateerd zijn: misschien zit je met je hoofd compleet in React of Vue of ben je juist veel meer met HTML en CSS bezig. Of misschien heb je ook die jeuk die ik eerder beschreef en ben je veel meer nieuwsgierig naar de gebieden om je heen. Misschien wil je applicaties maken die front end developers helpen (hallo Kilian met je Polypane!). Of wil je net zoals ik veel meer met design bezig zijn en meer grafisch design doen of vind je de psychologische kant juist tof en wil je meer in de UX duiken van websites.</p>
<h2>Met een natte T</h2>
<p>Je hoeft niet voor altijd te blijven doen wat je nu doet. Dat is eigenlijk de boodschap die ik heb. Er zijn genoeg mogelijkheden om te groeien en of dat nu in de hoogte is (bijvoorbeeld van junior naar senior) of in een breedte (bijvoorbeeld van front end naar UX), dat bepaal je zelf. Je moet alleen wel stapjes durven te maken in de richting die jij wil.</p>
<p>Buiten dat is het goed om überhaupt meer kennis te krijgen van de gebieden om je heen. Je hoeft niet per sé een
specialist te zijn, maar als je meer <a href="https://agilescrumgroup.nl/t-shaped">T-shaped</a> bent wordt je veel
gevarieerder. Als persoon wordt je daardoor ook nog eens interessanter als je een nieuwe baan zoekt.</p>
<p>Om af te sluiten met een TL;DR: wordt bewust van je huidige positie, volg je interesses, blijf niet onnodig hangen in je huidige werk als je er niet gelukkig van wordt en blijf groeien.</p>
</content>
</entry>
<entry>
<title>Nieuw bestuurslid, Wim van Iersel</title>
<link href="https://www.fronteers.nl/nl/blog/2022/11/nieuw-bestuurslid-wim-van-iersel"/>
<updated>2022-11-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/11/nieuw-bestuurslid-wim-van-iersel</id>
<content xml:lang="nl" type="html"><p>Op de afgelopen ALV is Wim van Iersel toegetreden tot het bestuur. Hij stelt zich graag aan jullie voor!</p>
<p>Hoi allemaal,</p>
<p>Een kleine verrassing op de woensdagavond voor degene die de notulen van de <a href="https://www.fronteers.nl/nl/vereniging/bestuur/notulen/notulen-alv-4-november-2022">Algemene Ledenvergadering</a> nog niet gelezen hebben! Afgelopen vrijdag was de ALV van Fronteers in Utrecht. Daar was ik bij aanwezig als een van de leden van de kascommissie dit jaar en liep ik enigszins verrast naar buiten als het nieuwe bestuurslid van Fronteers.</p>
<p>Nu hoor ik jullie denken: hoe kan dat nu weer, er waren toch geen kandidaten aangekondigd op de website/in de e-mail? Dat klopt, maar toen duidelijk werd tijdens de ALV dat het bestuur zeker niet de minimale vereiste bezetting van drie (volgens statuten) zou halen door een gebrek aan nieuwe kandidaten, heb ik kenbaar gemaakt graag de rol van Penningmeester op me te willen nemen. Daarmee is één van de twee vrijgekomen posities in het bestuur voor de komende 3 jaar opgevuld. De vertrekkende bestuursleden zijn trouwens niet van plan de continuïteit van het bestuur in gevaar te brengen. We hebben wel een proeftijd afgesproken van drie maanden om even helemaal open kaart te spelen.</p>
<p>Wat ik jullie niet wil onthouden is dat de goed bedachte argumenten van Koen Willems een handje bijgedragen hebben aan mijn keuze om me last minute kandidaat te stellen. Mocht je nu denken ‘ik wil toch eigenlijk ook wel in het bestuur van Fronteers’ laat het dan gerust even weten!</p>
<p>Voor de oudgedienden van Fronteers ben ik waarschijnlijk wel een bekend gezicht. Ik ben al lid sinds de oprichtings-ALV die aansluitend gehouden werd aan Fronteers 2008 in Pakhuis De Zwijger. Als vrijwilliger heb met enige regelmaat de afgelopen jaren onderdeel uitgemaakt van de kascommissie; eerlijk gezegd ben ik de tel een beetje kwijt geraakt hoe vaak ik die taak samen met een van de andere vrijwillig(st)ers heb uitgevoerd, maar dat heb ik altijd met plezier gedaan en dan nu vanaf de andere kant.</p>
<p>Afsluitend wat kort over mezelf. Op Twitter bekend als <a href="https://twitter.com/banaan666">@banaan666</a> (voor zolang dat nog bestaat) en in het echte leven luister ik o.a. naar de naam Wim van Iersel. Ik werk als Webmaster/Front-end Web Developer (zo noem ik het zelf maar) bij de gemeente Tilburg. Ondertussen wel steeds minder met Front-end bezig in mijn dagelijks werk, maar ik probeer nog altijd op de hoogte te blijven van de laatste ontwikkelingen op ons vakgebied en deze toe te passen bij hobby projecten. Op dit moment ligt mijn focus vooral op Security/Common Ground/ITIL processen/a11y/etc.</p>
<p>Hopelijk treffen we elkaar binnenkort een keer bij een bijeenkomst ergens in Nederland of België.</p>
</content>
</entry>
<entry>
<title>Fronteers Boekenclub 3 - Design For The Real World</title>
<link href="https://www.fronteers.nl/nl/blog/2022/10/fronteers-boekenclub-3-papanek-design-for-the-real-world"/>
<updated>2022-10-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/10/fronteers-boekenclub-3-papanek-design-for-the-real-world</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 25 oktober bespraken we bij de derde Fronteers Boekenclub het boek <a href="https://thamesandhudson.com/design-for-the-real-world-9780500295335">&quot;Design for the Real World&quot; van Victor Papanek</a>.</p>
<p><img src="https://www.fronteers.nl/_img/papanek-design-for-the-real-world-200w.jpg" alt="Boekomslag voor &quot;Design For The Real World&quot; waarin de boektitel als losse woorden tussen een zin staat. De zin luidt: &quot;Design is composing an epic poem, executing a mural, painting a masterpiece, writing a concerto. But design is also cleaning and reorganizing a desk drawer, pulling an impacted tooth, baking an apple pie, choosing sides for a backlot baseball game, and educating a child&quot;" /></p>
<p>Bij de derde editie van de Fronteers boekenclub lazen we Design For The Real World van Victor Papanek. Het lukte bijna niemand van ons om het boek van kaft tot kaft uit te lezen. Dat lag niet aan de inhoud, maar wel aan de schrijfstijl en verouderde voorbeelden.</p>
<h2>Over het boek</h2>
<p>We hadden eigenlijk exact moeten afspreken welke editie we gingen lezen. Want er zijn nogal wat verschillende edities geweest van dit boek. Ik zelf had de derde editie uit 1985 (394 pagina’s, uitgever: Thames &amp; Hudson).
De eerste editie stamt uit 1971. Het is dus een loei-oud boek. Volgens sommigen is het een klassieker, voor anderen een verouderd boek.</p>
<h2>Wat we ervan vonden</h2>
<p>Tja. We waren het erover eens dat de boodschap van het boek absoluut de moeite waard is. Maar de schrijfstijl laat te wensen over.</p>
<p><em>Liesbeth</em>: Als ik het eindcijfer mag splitsen, dan geef ik het 2 sterren vanwege hoe slecht ik er doorheen kon komen en 5 sterren voor de hoofdboodschap. Die is komt eigenlijk gewoon neer op: “Design geen zinloze dingen”. Dat is een open deur misschien maar wel waar natuurlijk. Het boek begon enthousiast, maar zakte daarna in.</p>
<p><em>Adam</em>: Ik ben geen designer. Maar ik sluit me daarbij aan. 2 sterren voor de leesbaarheid. 4 voor de hoofdboodschap. Het manifest met 7 consumentenrechten op het einde van het boek spreekt me wel aan. Dat hebben we meer nodig.
Een veel beter boek over design is ‘The Design of Everyday Things’ van Donald Norman. Dat leert je beter kijken naar ontwerp dan dit boek.</p>
<p><em>Nina</em>: Ik ben eigenlijk verbaasd over de tijdloosheid van het boek. Van mij krijgt het boek 5 sterren. Vooral vanwege de visie van Papanek in die tijd en de tijdloosheid van zijn ideeën. Waarom is met deze ideeën nog zo weinig gedaan? Het is zo oud, en nog lijkt er niks veranderd bij bedrijven of bij ontwerpers. Waarom hebben we nog geen consumer manifesto? Voor mij was een eye-opener het hoofdstuk over alle verschillende blokkades. Welke factoren houden ons tegen bij nieuwe en innovatieve manieren om te ontwerpen. We zien niet allemaal hetzelfde. Papanek beschrijft die bekende <a href="http://home.snu.edu/~hculbert/see.htm">tekening waar je een oude vrouw of een jong meisje</a> in kunt zien.</p>
<p><em>Paul</em>: Ik geef het 3 sterren van de 5. Ik vond het een gedateerd, belegen boek. Het zou de leesbaarheid geholpen hebben als niet alle voorbeelden willekeurig gekozen leken. En het zou geweldig zijn geweest als de hoofdstukken een duidelijke samenvatting hadden gehad. Het lijkt ook wel alsof er maar twee soorten design bestaan in dit boek. Namelijk aan de ene kant het werk van Papanek. En aan de andere kant de rest, met slecht werk.</p>
<h2>FBC4: dinsdag 13 december</h2>
<p><img src="https://www.fronteers.nl/_img/de-it-girl-cover.png" alt="Boekomslag. Chantal Schinkels: &quot;De IT Girl - hoe overleef je een door mannen gedomineerde werkvloer&quot;. Uitgegeven door Van Duuren Management" /></p>
<p>Bij de vierde aflevering bespreken we <a href="https://chantalschinkels.nl/de-it-girl/">‘De IT-Girl’ van Chantal Schinkels</a>, met als ondertitel ‘Hoe overleef je een door mannen gedomineerde werkvloer’. &quot;Dit boek vertelt het eerlijke verhaal wat er momenteel in de Nederlandse tech sector afspeelt en wat we kunnen doen om daar verandering te brengen.&quot;</p>
<p><a href="https://www.meetup.com/fronteers-nl/events/289337720/">Aanmelden via Meetup</a></p>
</content>
</entry>
<entry>
<title>Schrijf mee aan de Fronteers Adventskalender 2022!</title>
<link href="https://www.fronteers.nl/nl/blog/2022/09/schrijf-mee-aan-de-fronteers-adventskalender-2022"/>
<updated>2022-09-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/09/schrijf-mee-aan-de-fronteers-adventskalender-2022</id>
<content xml:lang="nl" type="html"><p>In december keert de Fronteers Adventskalender terug. 24 blogs van 24 schrijvers over alles dat met front-end (en Fronteers) te maken heeft. En de schrijvers mogen een donatie van 75 euro uit de verenigingskas doen aan een goed doel naar keuze.</p>
<p>Tot 14 oktober kan iedereen zich aanmelden om een blog te schrijven. De deadline voor de bijdrages is 14 november. Je mag schrijven over elk onderwerp dat front-end gerelateerd is. Misschien heb je wel goede voornemens voor 2023 of wil je graag een terugblik op het afgelopen jaar maken. Heb je een belangrijke ontdekking gedaan, wil je iets wat je zelf hebt geleerd met iedereen delen? Je kunt ook een pleidooi maken voor jouw favoriete framework of een lijstje van tools/artikelen die jij op dit moment belangrijk vindt. Of misschien wil je graag schrijven over jouw ervaringen als front-end developer en waarom dit het mooiste werk van de wereld is. Denk ook eens aan het schrijven van een review, bijvoorbeeld over een Fronteers congres of workshop.</p>
<p>Wil je graag meeschrijven? Meld je dan voor 14 oktober aan, voor vragen kun je natuurlijk op het Fronteers Slack-kanaal terecht.</p>
</content>
</entry>
<entry>
<title>Meld je aan voor de ALV 2022!</title>
<link href="https://www.fronteers.nl/nl/blog/2022/09/meld-je-aan-voor-de-alv-2022"/>
<updated>2022-09-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/09/meld-je-aan-voor-de-alv-2022</id>
<content xml:lang="nl" type="html"><p>Op vrijdagavond 4 november vanaf 19:30 houden we onze jaarlijkse algemene ledenvergadering (ALV)! Alle leden zijn hiervoor van harte uitgenodigd, en we hopen nieuwe bestuursleden te verwelkomen!</p>
<p><a href="https://www.fronteers.nl/nl/blog/2022/09/meld-je-aan-voor-de-alv-2022#english-version">English version</a> below.</p>
<p>Is het je eerste keer op de (of überhaupt een) ALV? Tijdens de ALV nemen we als bestuur, vrijwilligers en leden samen de (financiële) staat van Fronteers door, en evalueren we hoe het gaat met de vereniging. Tot het begin van de vergadering kan elk lid een voorstel doen voor een agendapunt of een ter stemming te brengen onderwerp.</p>
<p>Het staat leden tot het begin van de ALV vrij voorstellen voor de agenda in te dienen. De voorlopige agenda staat hieronder. Wat in ieder geval zal worden behandeld zijn de jaarstukken van de vereniging over 2021, de financiën over 2022 en de nieuwe begroting voor 2023. Deze stukken zullen enkele dagen voor de ALV naar alle aangemelde aanwezigen worden opgestuurd. Mocht je niet aanwezig kunnen zijn, maar deze informatie wel willen inzien: laat het ons weten!
Notulen van de avond worden altijd zo snel mogelijk na de vergadering online gedeeld.</p>
<p>We zijn bovendien op zoek naar nieuwe bestuursleden om vanaf de komende ALV het stokje over te nemen van Sander Vink (penningmeester) en Anneke Sinnema (voorzitster). Leden kunnen zich kandidaat stellen tijdens de ALV waarna er een stemming volgt. Als bestuurslid help je mee de vereniging op de kaart te zetten en te houden. Je zorgt er voor dat commissies een zetje krijgen en dat vrijwilligers het zelfvertrouwen hebben om activiteiten te ontplooien voor de vereniging. We hebben de ambitie om weer vaker meetups en activiteiten te organiseren, zetten graag het Fronteerscongres voort, en bouwen door aan onze nieuwe website. Anneke, Sander en Edwin staan je graag te woord via Slack of bestuur@fronteers.nl als je ons hierin wilt helpen!</p>
<h2>Voorlopige agenda</h2>
<ul>
<li>Opening</li>
<li>Jaarrekening 2021</li>
<li>Bevindingen kascommissie</li>
<li>Benoeming nieuwe kascommissie</li>
<li>Financiën 2022</li>
<li>Begroting 2023</li>
<li>Benoeming nieuwe bestuursleden</li>
<li>Toelichting commissies</li>
<li>Rondvraag</li>
<li>Sluiting</li>
</ul>
<h2>Aanmelden</h2>
<p>Ben je van plan te komen, dan vragen we je vriendelijk je hiervoor in te schrijven, zodat we voorzieningen kunnen treffen voor de avond zelf.</p>
<h2>English version</h2>
<p><strong>Wednesday evening, the 4th of November starting at 19:30 we will have our annual membership meeting (ALV)! All members of Fronteers are welcome to sign up to join us.</strong></p>
<p>Is this your first time at the (or an) ALV (membership meeting)? The legal form of Fronteers is a dutch 'vereniging', which means we are obligated to have a meeting once a year with the board, volunteers and members to present and discuss the (financial) state of Fronteers. We will evaluate how Fronteers is doing and discuss what we can do to improve. Until the actual start of the meeting, any member can propose a topic for the agenda to be discussed and voted on by all present members.</p>
<p>We are also looking for new board members to take over from Sander Vink (treasurer) and Anneke Sinnema (chairwoman). Members can nominate themselves during the meeting, after which a vote will follow. As a board member you help to put and keep the association on the map. You ensure that committees are given a boost and that volunteers have the confidence to develop activities and take initiative. Anneke, Sander and Edwin are happy to speak to you via Slack or bestuur@fronteers.nl if you are interested!</p>
<p>Below, you'll find the provisional program of the evening. The financial documents of 2021, 2022 and plans for 2023 will be discussed and sent in advance to everyone that signed up for the ALV. If you can't attend but (as a member) want to get a copy of the documents, please <a href="mailto:penningmeester@fronteers.nl">send an e-mail to our treasurer</a>.</p>
<h2>(Provisional) Agenda</h2>
<ul>
<li>Opening</li>
<li>Financial Statements 2021</li>
<li>Findings of the treasury committee</li>
<li>Naming of the new treasury committee</li>
<li>Finances of 2022</li>
<li>Budget for 2023</li>
<li>Appointment of new board members</li>
<li>Report of committees</li>
<li>Round of questions</li>
<li>Close</li>
</ul>
<h2>Sign up</h2>
<p>If you plan to attend, please sign up, so we know how many members we can expect to join us and if we need to make provisions for a meeting in real life!</p>
</content>
</entry>
<entry>
<title>Fronteers Conference op 9 september 2022</title>
<link href="https://www.fronteers.nl/nl/blog/2022/08/fronteers-conference-op-9-september-2022"/>
<updated>2022-08-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/08/fronteers-conference-op-9-september-2022</id>
<content xml:lang="nl" type="html"><p>Nog anderhalve week te gaan totdat Fronteers Conference 2022 van start gaat op vrijdag 9 september, en er zijn nog kaarten verkrijgbaar! Locatie: Pathé Leidsche Rijn in Utrecht.</p>
<p>Onze sprekers brengen je helemaal up-to-date op het gebied van CSS, privacy, performance, typografie, en zetten je aan het denken op het gebied van het design proces en accessibility:</p>
<ul>
<li>Bramus Van Damme</li>
<li>Robin Marx</li>
<li>Maud Nalpas</li>
<li>Marie Van Driessche</li>
<li>Ulrike Rausch</li>
<li>Manuel Matuzović</li>
</ul>
<p>En als onze &quot;Master of Ceremonies&quot;, Floor Drees!</p>
<p>Dit jaar dus een andere locatie en wat kleinschaliger, maar daar zit natuurlijk een gedachte achter. Nieuwsgierig? Lees dan <a href="https://twitter.com/derSchepp/status/1562377149465731072">de tweet van een van onze organisatoren Christian</a> (let op, content in het Engels).</p>
<p>Meer informatie over de sprekers, de MC, de talks en kaarten kun je vinden op: <a href="https://fronteersconf.org/">fronteersconf.org</a>.</p>
<p>Wij kijken er ontzettend naar uit je daar te zien. Ben jij erbij?</p>
</content>
</entry>
<entry>
<title>Fronteers Boekenclub 2 - How Design Makes The World</title>
<link href="https://www.fronteers.nl/nl/blog/2022/06/fronteers-boekenclub-2-design-makes-the-world"/>
<updated>2022-06-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/06/fronteers-boekenclub-2-design-makes-the-world</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 7 juni bespraken we bij de Fronteers Boekenclub het boek <a href="https://designmtw.com/">&quot;How Design Makes The World&quot; van Scott Berkun</a>.</p>
<p><img src="https://www.fronteers.nl/_img/omslag-design-makes-the-world-scott-berkun-200w.jpg" alt="Boekomslag voor &quot;How Design Makes The World&quot;. Sommige letters zijn vervangen door producten als een hamburger, autowiel, Lego, de Eiffeltoren en een iPhone." /></p>
<p>Dit was de tweede keer dat we een boek bespraken. Leonard, Nina en Paul waardeerden het boek, al was de een enthousiaster dan de ander. De blurb beschrijft dit boek met:</p>
<blockquote>
<p>Everything we use, from social media, to our homes, to our highways, was designed by someone. What did they get right and where have they let us down? And how can we apply the lessons to what we make?</p>
</blockquote>
<h2>Over het boek</h2>
<p>Berkun is designer en product-owner bij WordPress-bedrijf Automattic en hij heeft meer boeken geschreven, onder meer ‘A Year Without Pants’ over remote werken. Design Makes The World gaat over heel veel verschillende onderwerpen met als rode draad: “Alles is het resultaat van ontwerpbeslissingen.” Voor sommigen is dat een open deur, voor anderen is dit een eye-opener. Ik zei ‘open deur’, en inderdaad: uiteraard komen <a href="https://99percentinvisible.org/article/norman-doors-dont-know-whether-push-pull-blame-design/">Norman doors</a> ter sprake.</p>
<p>Het is een niet al te dik boek met nogal een groot notenapparaat en index. Dus het leest rap weg. Het meandert alle kanten op en heeft een brede horizon aan onderwerpen. Dat maakt het misschien wat lastig om samen te vatten. Maar wat mij betreft is het belangrijkste punt van het boek dat er niet zoiets zwart-wits bestaat als ‘goed design’. Bij het beoordelen van iets wat je gaat ontwerpen, kun je jezelf deze vragen stellen:</p>
<ul>
<li>Wat wil je verbeteren?</li>
<li>Voor wie wil je dit verbeteren?</li>
<li>Op basis van welke criteria kun je dit succesvol noemen?</li>
<li>Wie zou last kunnen krijgen van je ontwerp-beslissingen?</li>
</ul>
<h2>Wat we ervan vonden</h2>
<p>We waren het eens over de leesbaarheid van het boek. Leuk geschreven, interessante voorbeelden en de vragen die je jezelf kunt stellen zijn nuttiger dan alleen ‘is het goed design’.</p>
<p><em>Nina</em>: Ik twijfelde tussen 4 of 5 sterren en ik geef het uiteindelijk vier sterren. Het boek heeft me een nieuwe kijk op de wereld gegeven. Alles is ontworpen. Ik wist dat wel, maar niet zo bewust. Het maakte me ook boos, vooral de voorbeelden hoe zaken soms met opzet onethisch worden ontworpen. We moeten meer tijd nemen om na te denken over de gevolgen van onze ontwerpbeslissingen. Inclusief ontwerpen is echt heel belangrijk. De checklist uit dit boek is nuttig en zal ik nog wel vaker gaan gebruiken.</p>
<p><em>Leonard</em>: Ik heb dit als luisterboek gelezen. Fijn boek, veel interessante onderwerpen. Ik kan nog niet echt voorbeelden geven van dingen die ik later nog eens kan hergebruiken. Het is geen boek met oplossingen; eerder is het de ontstaansgeschiedenis van dingen om ons heen met een verklaring waarom ze zijn zoals ze zijn. Ik leerde iets het ontstaan van ‘<a href="https://en.wikipedia.org/wiki/Planned_obsolescence">planned obsolesence</a>’: waarom bijvoorbeeld autofabrikanten elk jaar een nieuwe auto uitbrengen. Ik ben me nu meer bewust van de strijd die soms geleverd moet worden om iets wat goed ontworpen is en goed voor de mensen is, ook echt op de markt te krijgen.</p>
<p><em>Paul</em>: ik dub tussen 3 of 4 sterren. Laten we er 4 van maken. Ik vond het toch wel een potpourri met allerlei leuke feitjes die uiteindelijk ook iets met design te maken hadden. Pas op het eind werd het nuttig in hoofdstuk 19 (solutions create problems). Daar onstonden pas nieuwe inzichten voor me. Als in: &quot;Most design is redesign: applying what we know now to design choices made before us&quot;. Ik vond het leuk dat Berkun verwees naar <a href="https://www.mijksenaar.com/project/amsterdam-airport-schiphol-2-2/">de bewegwijzering op Schiphol</a> en breder nog, naar Nederland als land met een grote design-traditie. Dat zorgt inderdaad voor meer samenhang en duidelijkheid in een samenleving.</p>
<h2>FBC3: dinsdag 6 september</h2>
<p><img src="https://www.fronteers.nl/_img/papanek-design-for-the-real-world-200w.jpg" alt="Boekomslag voor &quot;Design For The Real World&quot; waarin de boektitel als losse woorden tussen een zin staat. De zin luidt: &quot;Design is composing an epic poem, executing a mural, painting a masterpiece, writing a concerto. But design is also cleaning and reorganizing a desk drawer, pulling an impacted tooth, baking an apple pie, choosing sides for a backlot baseball game, and educating a child&quot;" /></p>
<p>De derde aflevering van de Fronteers Boekenclub is op dinsdag 6 september tussen 20:00 en 21:30. Dan lezen we een klassieker uit 1971, namelijk Victor Papanek: “Design For The Real World”. Weer een boek over design, ja. Er begint een rode lijn te ontstaan.</p>
<p><a href="https://www.meetup.com/fronteers-nl/events/286424272/">Meld je aan voor het meelezen via Meetup</a>.</p>
</content>
</entry>
<entry>
<title>Fronteers is op zoek naar nieuwe bestuursleden!</title>
<link href="https://www.fronteers.nl/nl/blog/2022/04/fronteers-is-op-zoek-naar-nieuwe-bestuursleden"/>
<updated>2022-04-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/04/fronteers-is-op-zoek-naar-nieuwe-bestuursleden</id>
<content xml:lang="nl" type="html"><p>Wil jij graag Fronteers naar een hoger niveau tillen, ben je initiatiefrijk en hou je er van anderen te enthousiasmeren? Dan zijn we op zoek naar jou voor het bestuur van de vereniging!</p>
<figure class="simple-quote">
<div class="simple-quote_decorative-start" aria-hidden="true">{</div>
<div class="simple-quote-content">
<blockquote>
Als je in het bestuur zit geef je front-end ontwikkelaars in heel Nederland een stem
</blockquote>
<figcaption class="simple-quote-author">— Anneke Sinnema</figcaption>
</div>
<div class="simple-quote_decorative-end" aria-hidden="true">}</div>
</figure>
Als bestuurslid help je mee de vereniging op de kaart te zetten en te houden. Je zorgt er voor dat commissies een zetje krijgen en dat vrijwilligers het zelfvertrouwen hebben om activiteiten te ontplooien voor de vereniging. We hebben de ambitie om weer vaker meetups en activiteiten te organiseren, verlangen naar continuiteit voor het Fronteerscongres, en bouwen door aan onze nieuwe website.
<p>Fronteers zoekt in ieder geval nieuwe bestuursleden om vanaf de komende ALV het stokje over te nemen van Sander Vink (penningmeester) en Anneke Sinnema (voorzitster). Bij interesse gaan we graag eens het gesprek met je aan. Stuur een <a href="mailto:bestuur@fronteers.nl">e-mail naar het bestuur</a> of stuur een DM naar Anneke, Sander of Edwin via onze Slack. We verwachten wel dat vrijwilligers (en in het verlengde bestuursleden) lid zijn van Fronteers.</p>
<h3 class="h">
<a href="https://www.fronteers.nl/nl/vereniging/bestuur" target="_blank">LEES DE NOTULEN</a>
</h3>
<a class="curly-braces-bg banner_component" style="background-image: url()" href="https://www.fronteers.nl/nl/vereniging/bestuur" target="_blank">
<span class="visually-hidden">lees meer over het bestuur</span>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="72" height="72" viewBox="0 0 72 72" aria-hidden="true">
<defs>
<clipPath id="clip-Button_play">
<rect width="72" height="72"></rect>
</clipPath>
</defs>
<g id="Button_play" clip-path="url(#clip-Button_play)">
<rect width="72" height="72" fill="transparent"></rect>
<g id="Group_503" data-name="Group 503" transform="translate(-0.204)">
<circle id="Ellipse_4" data-name="Ellipse 4" cx="36" cy="36" r="36" transform="translate(0.204)" fill="#fe796a"></circle>
<path id="Path_120" data-name="Path 120" d="M35.213,0V13.347L17.606,25.291,0,13.347V0Z" transform="translate(26.874 53.282) rotate(-90)"></path>
</g>
</g>
</svg>
</a>
<style>
.banner_component {
display: flex;
place-content: center;
flex-wrap: wrap;
min-height: 250px;
inline-size: 70%;
background-repeat: no-repeat;
background-position: center;
background-size: cover;
}
.content-wrapper .banner_component {
margin-block-end: var(--spacing);
display: inline-flex;
}
@media all and (min-width: 46.875em) {
.content-wrapper .banner_component {
inline-size: 110%;
transform: translateX(-5%);
}
}
.banner_component::after {
content: " ";
inline-size: 100%;
block-size: 100%;
z-index: 1;
position: absolute;
background: rgba(0, 0, 0, 0.3);
top: 0;
}
.banner_component svg {
z-index: 2;
}
.banner_component:hover svg circle,
.banner_component:focus svg circle {
fill: var(--purple);
}
.banner_component:hover svg path,
.banner_component:focus svg path {
fill: white;
}
.banner_component .visually-hidden {
clip: rect(0 0 0 0);
clip-path: inset(50%);
block-size: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
inline-size: 1px;
}
@media all and (max-width: 46.874em) {
.banner_component {
-webkit-clip-path: none;
clip-path: none;
padding: var(--spacing) 6%;
min-height: 30vh;
width: 100%;
}
}
</style></content>
</entry>
<entry>
<title>Nieuw: de Fronteers boekenclub</title>
<link href="https://www.fronteers.nl/nl/blog/2022/04/de-eerste-editie-van-de-fronteers-boekenclub"/>
<updated>2022-04-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2022/04/de-eerste-editie-van-de-fronteers-boekenclub</id>
<content xml:lang="nl" type="html"><p>Afgelopen dinsdag was de eerste editie van de Fronteers boekenclub. Om de -zeg- 3 maanden bespreken we een boek, enigszins relevant voor ons vakgebied en kiezen we een nieuw boek uit voor de volgende keer. Lees je mee de volgende keer?</p>
<p><img src="https://www.fronteers.nl/_img/ethicaldesignhandbook.jpg" alt="" /></p>
<p>Bij de eerste editie van de Fronteers Boekenclub bespraken we ‘<a href="https://ethicaldesignhandbook.com/">The Ethical Design Handbook</a>’. We waren met z’n drieën en we waren eensgezind in ons oordeel over het boek: 3 uit 5 sterren. Het is net te oppervlakkig of niet praktisch genoeg. Voor mensen die niet veel te maken hebben gehad met ethische vragen zou het wel een eye-opener kunnen zijn.</p>
<p><em>Nina</em>: het is geen boek dat ik zou aanraden om iemand bewuster te maken van ethische kanten van design of development. Daarvoor is het net te oppervlakkig. Ik heb wel een paar nieuwe inzichten gehad.</p>
<p>Het stuk over cookie-waarschuwingen bijvoorbeeld was goed: het maakte duidelijk waarom cookie-waarschuwingen bedoeld zijn en waarom het zo moeilijk is om het ethisch goed te doen.</p>
<p>Ik ben me ook bewuster geworden van ‘dark patterns’. Ik verwacht niet dat ik in mijn dagelijkse praktijk veel heb aan dit boek. Het stuk over datamodellen en processen vond ik bijvoorbeeld te kort door de bocht om in de praktijk te kunnen gebruiken.</p>
<p><em>Hidde</em>: Het boek deed een beetje bijeengeraapt aan, met soms vage definities en vaak beperkte argumentatie. Ik vond het beter worden naarmate het praktischer werd, aan het einde. De best practices waren het beste gedeelte van het boek, al bleven ze vrij algemeen en beknopt.</p>
<p>De auteurs hielden een vrij specifieke definitie van ethiek aan, namelijk het centraal stellen van de mens en respect voor de mens. Het vakgebied ethiek kijkt vaak breder, bijvoorbeeld naar vragen als “hoe moet ik handelen?” en “wat zijn de gevolgen van handelen?”.</p>
<p>De focus op respect en de voorbeelden waren goed gekozen om ethiek toepasbaar te maken binnen organisaties, maar bij bijvoorbeeld “ethical KPIs” (leuk gevonden!) als “gebruikerstevredenheid” miste ik een uitkijk naar gevolgen: wat als gebruikers van een ontwerp tevreden zijn ten koste van de arbeidssituatie van anderen, zoals bij sommige taxi-applicaties?</p>
<p><em>Paul</em>: Ik zie ethisch denken als een spier die je regelmatig moet oefenen. Dit boek levert geen oefeningen op om die spier te trainen, maar het levert wel de redenen waarom je zou moeten trainen.</p>
<p>Knap vind ik dat het boek positief ingesteld blijft, ondanks de enorme hoeveelheid ethische blunders die ze hadden kunnen noemen.</p>
<p>De tussenstukken ‘uit de praktijk’ vond ik een goede toevoeging. Ik was erg blij toen ik het stuk las over Ling van Ling’s Cars: 'I soon realized that brutal honesty was needed when talking to new car buyers, which isn’t the normal approach to ethics and corporate standards. I’d describe my ethics as honesty wrapped in a boxing glove.'</p>
<p><em>Het volgende boek dat we gaan fileren is <a href="https://designmtw.com/buy/">'How Design Makes the World'</a> van Scott Berkun.</em></p>
<p><em>Meedoen? Meld je bij Paul van Buuren via de Fronteers Slack of meld je aan <a href="https://www.meetup.com/Fronteers-NL/events/285086437/">via meetup.com voor de volgende editie online meetup</a></em>.</p>
<p><em>Sowieso: schrijf je (gratis) in als lid van de <a href="https://www.meetup.com/Fronteers-NL/">Fronteers Meetup-groep</a> om op de hoogte gehouden te worden.</em></p>
</content>
</entry>
<entry>
<title>Meld je aan voor de ALV 2021</title>
<link href="https://www.fronteers.nl/nl/blog/2021/10/meld-je-aan-voor-de-alv-2021"/>
<updated>2021-10-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2021/10/meld-je-aan-voor-de-alv-2021</id>
<content xml:lang="nl" type="html"><p>Op maandagavond 25 oktober vanaf 20:00 houden we onze jaarlijkse algemene ledenvergadering (ALV)! Alle leden zijn hiervoor van harte uitgenodigd. De vergadering vindt vanwege het Coronavirus opnieuw online plaats, via Jitsi Meet. Vooraf software installeren op je computer is niet nodig, mocht je willen inbellen vanaf je telefoon, dan zijn er apps beschikbaar voor <a href="https://jitsi.org/downloads/">Android, iOS en F-Droid</a>!</p>
<p><a href="https://www.fronteers.nl/nl/blog/2021/10/meld-je-aan-voor-de-alv-2021#english-version">English version</a> below.</p>
<p>Is het je eerste keer op de (of überhaupt een) ALV? Tijdens de ALV nemen we als bestuur, vrijwilligers en leden samen de (financiële) staat van Fronteers door, en evalueren we hoe het gaat met de vereniging. Tot het begin van de vergadering kan elk lid een voorstel doen voor een agendapunt of een ter stemming te brengen onderwerp.</p>
<p>Het staat leden tot het begin van de ALV vrij voorstellen voor de agenda in te dienen. De voorlopige agenda staat hieronder. Wat in ieder geval zal worden behandeld zijn de jaarstukken van de vereniging over 2020, de financiën over 2021 en de nieuwe begroting voor 2022. Deze stukken zullen enkele dagen voor de ALV naar alle aangemelde aanwezigen worden opgestuurd. Mocht je niet aanwezig kunnen zijn, maar deze informatie wel willen inzien: <a href="mailto:penningmeester@fronteers.nl">laat het ons weten</a>!</p>
<p>Notulen van de avond worden altijd zo snel mogelijk na de vergadering online gedeeld.</p>
<h2>Voorlopige agenda</h2>
<ul>
<li>Opening</li>
<li>Jaarrekening 2020</li>
<li>Bevindingen kascommissie</li>
<li>Benoeming nieuwe kascommissie</li>
<li>Financiën 2021</li>
<li>Begroting 2022</li>
<li>Toelichting commissies</li>
<li>Stand van zaken nieuwe website</li>
<li>Rondvraag</li>
<li>Sluiting</li>
</ul>
<h2>Aanmelden</h2>
<p>Ben je van plan te komen, dan vragen we je vriendelijk je hieronder hiervoor in te schrijven, zodat we enigszins een idee hebben van de verwachte opkomst.</p>
<h2>English version</h2>
<p><em>Monday evening, the 25th of October starting at 20:00 we will have our annual membership meeting (ALV)! All members of Fronteers are welcome to sign up to join us. Due to the Coronavirus, the meeting will take place completely online through Jitsi Meet. You don't need to install software or register to use this service, but if you want to participate on your phone there is an app available on <a href="https://jitsi.org/downloads/">Android, iOS en F-Droid</a>.</em></p>
<p>Is this your first time at the (or an) ALV (membership meeting)? The legal form of Fronteers is a dutch 'vereniging', which means we are obligated to have a meeting once a year with the board, volunteers and members to present and discuss the (financial) state of Fronteers. We will evaluate how Fronteers is doing and discuss what we can do to improve. Until the actual start of the meeting, any member can propose a topic for the agenda to be discussed and voted on by all present members.</p>
<p>Below, you'll find the provisional program of the evening. The financial documents of 2020, 2021 and 2022 will be discussed and sent in advance to everyone that signed up for the ALV. If you can't attend but (as a member) want to get a copy of the documents, please send an <a href="mailto:penningmeester@fronteers.nl">e-mail to our treasurer</a>.</p>
<h2>(Provisional) Agenda</h2>
<ul>
<li>Opening</li>
<li>Financial Statements 2020</li>
<li>Findings of the treasury committee</li>
<li>Naming of the new treasury committee</li>
<li>Finances of 2021</li>
<li>Budget for 2022</li>
<li>Report of committees</li>
<li>State of affairs new website</li>
<li>Round of questions</li>
<li>Close</li>
</ul>
<h2>Sign up</h2>
<p>If you plan to attend, please sign up using the form below, so we know how many members we can expect to join us!</p>
</content>
</entry>
<entry>
<title>Een &quot;that's all folks&quot; animatie in CSS met slechts één div</title>
<link href="https://www.fronteers.nl/nl/blog/2021/01/thats-all-folks"/>
<updated>2021-01-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2021/01/thats-all-folks</id>
<content xml:lang="nl" type="html"><p>CSS is opgebouwd uit allemaal rechthoeken. Rechthoeken kunnen boven of onder andere rechthoeken liggen. Rechthoeken kunnen ook weer andere rechthoeken in zich hebben, en dan kan je er voor kiezen dat de binnenste rechthoeken ook buiten hun omringende rechthoek zichtbaar zijn (dat ze <em>overflowen</em>) of dat ze afgekapt worden door de omringende rechthoek (met overflow:hidden).</p>
<p>Maar als je wilt dat een rechthoek aan één zijde wel buiten de omringende rechthoek zichtbaar is, maar niet aan de andere kant, dan kan dat niet. Toch?</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/thats-all-folks/selection-633.png" alt="Drie vierkanten waarbij bij de eerste een binnenste element er uit komt met de tekst &quot;Dit kan&quot; er onder. Bij de tweede blijft het binnenste element binnen de zichtbare rand, hier staat &quot;Dit kan ook&quot; onder. Bij de derde komt het binnenste element aan de bovenkant er uit, maar aan de onderkant niet. Hier onder staat &quot;Dit kan ...niet&quot;." /></p>
<p>Misschien gaan er bij jou nu wel allemaal radertjes draaien: wat nou als ik de binnenste rechthoek kopieer en de helft clip en dan er precies boven positioneer dan lijkt het net alsof... Maar in principe kan je er niet voor kiezen dat één element aan bijvoorbeeld de bovenkant uitsteekt, maar niet aan de onderkant. Of toch wel?</p>
<h2>3D transformaties</h2>
<p>Een tijdje terug was ik een lijst aan het verzamelen van websites die <a href="https://polypane.app/css-3d-transform-examples/">interessant gebruik maken van CSS 3D transforms</a>. Met CSS 3D transforms kan je elementen in 3D roteren, transformeren en verplaatsen, en ook cross-browser werkt dat ondertussen gewoon prima.</p>
<p>Er zijn twee CSS properties die je moet inzetten om elementen in 3D te kunnen positioneren:</p>
<ul>
<li><code>perspective</code> met een waarde in pixels, om te bepalen hoe sterk het 3d effect moet zijn.</li>
<li><code>transform-style: preserve-3d</code>, om de browser te vertellen dat je de 3D-transformaties wilt behouden</li>
</ul>
<p>Toch zie je het niet veel gebruikt worden, en ook ik had er nog niet heel veel mee geprobeerd. Websites blijven toch een &quot;2d&quot; iets, een scrollende, platte pagina.</p>
<p>De meest interessante 3D transform die ik tegen kwam was deze:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/thats-all-folks/selection-630.png" alt="Drie vlakken die in 3d ruimte boven elkaar zweven." /></p>
<p>Hoewel je drie vlakken ziet, is dit slechts éen div. De andere twee vlakken zijn de <code>::before</code> en <code>::after</code>, die door middel van de <code>translate()</code> CSS functie omhoog en omlaag zijn verplaatst, en zo boven elkaar liggen.</p>
<p>Wat me daar op viel was hoe het <code>::after</code> element, wat normaal gesproken over een element ligt <em>achter</em> de div zelf zat. Dat kreeg de maker voor elkaar met <code>transform: translateZ(-1px);</code>.</p>
<p>Hoewel ik daarvoor al veel andere transforms had gezien was dit de eerste die me echt deed beseffen dat ik elementen in 3D ruimte aan het positioneren was. En als dat kan, dan kunnen ze elkaar dus ook doorkruizen:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/thats-all-folks/selection-631.png" alt="Twee vlakken die elkaar in 3D ruimte doorkruizen." /></p>
<p>Ik wist niet direct wat ik daar mee kon, maar niet veel later zag ik een plaatje van een tekenfilmfiguurtje wat uit een frame leek te komen: aan de onderkant zat het achter het frame, maar het gezicht aan de bovenkant kwam er uit. Zou ik dat met CSS kunnen namaken? En als extra uitdaging, met maar één element?</p>
<p>Ik zat wat te pielen en al vrij snel had ik dit:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/thats-all-folks/selection-632.png" alt="Een oranje vierkant dat door een blauwe rand steekt: aan de bovenkant zit het over de blauwe rand, maar aan de onderkant zit het achter de rand." /></p>
<p>In dit plaatje zie je één div met een <code>::before</code> en een <code>::after</code>. De div zelf is transparant, de <code>::before</code> heeft een border en de <code>::after</code> is op de X-as geroteerd. Doordat de div <code>perspective</code> heeft wordt alles in 3d gepositioneerd, en daarmee ligt het <code>::after</code> element aan de bovenkant <em>voor</em> de border, en aan de onderkant <em>achter</em> de border.</p>
<pre><code>div {
transform: perspective(3000px);
transform-style: preserve-3d;
position: relative;
width: 200px;
height: 200px;
}
div::before {
content: &quot; &quot;;
width: 100%;
height: 100%;
border:10px solid darkblue;
}
div::after {
content: &quot; &quot;;
position: absolute;
background: orangered;
width: 80%;
height: 150%;
display: block;
left: 10%;
bottom: -25%;
transform: rotateX(-10deg);
}
</code></pre>
<p>Klik door naar de <a href="https://codepen.io/Kilian/pen/ZEpQQdo">Codepen</a> om het in actie te zien.</p>
<h2>Tussendoor, <code>perspective</code></h2>
<p>Met perspective kan je aangeven hoever je als &quot;kijker&quot; af zit van z=0, wat je kan zien als &quot;de horizon&quot;. Hoe hoger het perspectief, hoe minder sterk het 3D effect (en hoe kleiner, hoe sterker het effect). Voor de meeste effecten is een perspectief van tussen de 500 en 1000 pixels prima, en je kan met dit getal spelen om het effect te krijgen wat je wilt.</p>
<p>Je kan dit vergelijken met perspectieftekenen. Als je twee horizonspunten dicht bij elkaar tekent heb je een sterk perspectief, maar als je ze ver van elkaar af tekent lijkt alles veel platter.</p>
<h2>Van rechthoeken naar cartoons</h2>
<p>De rechthoekjes zijn leuk, maar wat ik eigelijk wilde maken was dit:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/thats-all-folks/porky.jpeg-full.jpg" alt="Een filmcel van Porky Pig die uit een cirkel lijkt te komen met de tekst &quot;That's all folks&quot;." /></p>
<p>Het klassieke einde van de looney tunes cartoons, waarbij porky pig uit een cirkel tevoorschijn komt en &quot;that's all folks&quot; stottert. Een mooi uitgeknipte versie van Porky Pig in dit plaatje kon ik niet vinden, maar de <a href="https://en.wikipedia.org/wiki/Porky_Pig">wikipedia pagina</a> heeft een ander mooi uitgeknipt plaatje, dus die gebruiken we.</p>
<p>Om het effect te bouwen delen we het plaatje op in drie onderdelen:</p>
<ul>
<li>De blauwe achtergrond, dat is de div zelf</li>
<li>De rode cirkels, dit wordt de <code>::before</code></li>
<li>Porky Pig, die gebruiken we als <code>background</code> voor de <code>::after</code>.</li>
</ul>
<p>We beginnen met de div, dit wordt de achtergrond en ook de basis voor de rest van de onderdelen. Op deze div zetten we het eerder genoemde <code>perspective</code> en <code>transform-style</code>, samen met de achtergrondkleur en wat afmetingen:</p>
<pre><code>div {
transform: perspective(3000px);
transform-style:preserve-3d;
position: relative;
width: 200px;
height: 200px;
background: #4992AD;
}
</code></pre>
<p>Dan komen we bij het tweede onderdeel, de rode cirkels. Het &quot;element&quot; zelf moet hier transparant blijven, dat is het gat waar Porky zometeen doorheen komt. Hoe zorgen we dan voor de rode cirkels? We kunnen een border gebruiken zoals in het eerdere voorbeeld, maar daar hebben we er maar eentje van. In dit geval heb je een serie van cirkels, waar ook nog eens een kleurverloop in zit.</p>
<p>We kunnen dit namaken met box-shadows. Je kan meerdere box-shadows toevoegen en door een blur radius van 0 maar een grote spread radius te gebruiken kan je meerdere &quot;borders&quot; toevoegen.</p>
<pre><code>box-shadow: &lt;x-offset&gt; &lt;y-offset&gt; &lt;blur-radius&gt; &lt;spread-radius&gt; &lt;color&gt;
</code></pre>
<p>We gebruiken een border-radius die even groot is als de div zelf, waardoor de <code>::before</code> een cirkel wordt, en voegen daar de box-shadows aan toe. Wanneer je box-shadow gebruikt om een aantal rode cirkels te maken waar witte schaduwen met een blur radius op zitten, krijg je een effect wat erg dicht bij de afbeelding zit:</p>
<pre><code>box-shadow: 0 0 20px 0px #fff, 0 0 0 30px #CF331F,
0 0 20px 30px #fff, 0 0 0 60px #CF331F,
0 0 20px 60px #fff, 0 0 0 90px #CF331F,
0 0 20px 90px #fff, 0 0 0 120px #CF331F,
0 0 20px 120px #fff, 0 0 0 150px #CF331F;
</code></pre>
<p>We maken hier vijf cirkels van steeds 30 pixels breed. Iedere cirkel heeft een vlakke rode achtergrond en daarboven maken we met behulp van een witte schaduw met een blur radius van 20 pixels het kleurverloop-effect.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/thats-all-folks/selection-629.png" alt="De achtergrond en de cirkels in pure CSS, nog zonder Porky." /></p>
<p>Als laatste hebben we Porky, laten we beginnen met die op de plek neer te zetten waar we hem uiteindelijk willen hebben, maar voor nu nog vóór de cirkels.</p>
<pre><code>div::after {
position: absolute;
content: &quot; &quot;;
width:80%;
height:150%;
display: block;
left:10%;
bottom: -12%;
background:url(&quot;https://upload.wikimedia.org/wikipedia/en/thumb/8/88/Porky_Pig.svg/800px-Porky_Pig.svg.png&quot;) no-repeat center/contain;
}
</code></pre>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/thats-all-folks/selection-628.png" alt="Porky Pig is boven op de cirkels gepositioneerd." /></p>
<p>De afmetingen en positionering hier is een beetje willekeurig, ik heb gekeken wat voor het plaatje mooi uitkwam.</p>
<h2>De truuk</h2>
<p>Dan nu de truuk: Porky's benen moeten achter de rode cirkels, maar zijn hoofd en petje er boven. Om dit voor elkaar te krijgen moeten we zowel de cirkels als Porky in 3d-ruimte verplaatsen.</p>
<p>Als we Porky willen roteren, dan moeten we op een aantal dingen letten:</p>
<ul>
<li>Hij mag niet door de achtergrond clippen</li>
<li>We kunnen niet zo ver roteren dat de afbeelding vervormt</li>
<li>Hij moet met zijn benen achter en met zijn hoofd voor de cirkels zetten</li>
</ul>
<p>Om er voor te zorgen dat Porky niet door de achtergrond clipt doen we een aantal dingen. Eerst verplaatsen we de cirkels in de Z-as zodat ze dichter naar ons toe komen. Omdat <code>preserve-3d</code> aan staat betekent dat ook dat ze inzoomen, maar als we ze slechts een klein beetje naar voren verschuiven hebben we genoeg ruimte tussen de achtergrond en de cirkels:</p>
<pre><code>transform: translateZ(20px);
</code></pre>
<p>Vervolgens hebben we Porky zelf. Die gaan we op de x-as roteren, zo dat de bovenkant van de afbeelding dichterbij is dan de onderkant, bijvoorbeeld met</p>
<pre><code>transform: rotateX(-10deg);
</code></pre>
<p>Maar als we dat doen, zien we dat het er niet helemaal goed uit ziet, Porky zit nu namelijk deels verstopt achter de blauwe achtergrond, en bij de cirkels gaat er ook iets mis.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/thats-all-folks/selection-626.png" alt="Porky Pig wordt deels afgekapt door de achtergrond en door de cirkels." /></p>
<p>We kunnen dit proberen op te lossen door Porky ook dichterbij te halen, met <code>translateZ</code>, maar wat we beter kunnen doen is de plek waar we roteren te veranderen. Nu doen we dat namelijk in het midden van de afbeelding, waardoor het onderste deel naar achter gaat.</p>
<p>Als we aan de onderkant van de afbeelding draaien, of zelfs ietsje daar onder, dan draait Porky als het ware in zijn geheel naar ons toe. En omdat we de cirkels al dichterbij hebben gehaald, komt alles mooi uit:</p>
<pre><code>transform: rotateX(-10deg);
transform-origin:center 120%;
</code></pre>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/thats-all-folks/selection-627.png" alt="Porky Pig komt nu uit de cirkel: Zijn benen zitten achter de cirkels, maar zijn hoofd er boven." /></p>
<p>Mocht je nou in 3d willen zien hoe alles zich verhoud, kijk dan op deze code pen en klik op &quot;show debug&quot;.</p>
<p><a href="https://codepen.io/Kilian/pen/wvzMMEW">Codepen voorbeeld</a></p>
<h2>Animatie</h2>
<p>Nu hebben we Porky, en hij piept mooi achter de cirkels vandaan, maar als het een statisch plaatje blijft hadden we niet al deze moeite hoeven nemen. Door een animatie toe te voegen kunnen we de gelaagdheid zichtbaar maken en het effect versterken.</p>
<p>De animatie die ik wil maken doet het volgende: Porky begint klein, en vergroot dan vanuit de blauwe achtergrond naar over de rode achtergrond. Daar blijft hij even staan, en zoomt daarna weer terug.</p>
<p>Voor de beste prestaties gebruiken we ook voor de animatie <code>transform</code>, en omdat we dat doen moeten we zorgen dat de <code>rotateX</code> behouden blijft.</p>
<pre><code>@keyframes zoom {
0% {
transform: rotateX(-10deg) scale(0.66);
}
40% {
transform: rotateX(-10deg) scale(1);
}
60% {
transform: rotateX(-10deg) scale(1);
}
100% {
transform: rotateX(-10deg) scale(0.66);
}
}
</code></pre>
<p>Met <code>scale()</code> zoomen we in en uit, en omdat we al eerder de <code>transform-origin</code> hebben gezet, schaalt het vanuit midden onder, precies het effect wat we willen.</p>
<p>Door tussen 40% en 60% even te pauzeren hebben we dat moment rust als hij boven de rode cirkels zit.</p>
<p>Die animatie voegen we dan toe aan de <code>::after</code>. Om de animatie wat natuurlijker te laten verlopen gebruiken we een timing functie, &quot;ease-in-out&quot;, waardoor de animatie aan het begin en eind iets slomer gaat.</p>
<pre><code>div::after {
animation-name: zoom;
animation-duration: 4s;
animation-iteration-count: infinite;
animation-fill-mode:forwards;
animation-timing-function: ease-in-out;
}
</code></pre>
<p><a href="https://codepen.io/Kilian/pen/abmddja">Klik door naar de codepen</a> om te zien hoe het er nu uit ziet, maar we kunnen nog twee dingen aanpassen om het er nog nét iets leuker uit te laten zien:</p>
<ul>
<li>We kunnen meer diepte creeëren door een schaduw achter Porky te laten groeien, zodat het lijkt alsof Porky dichterbij komt</li>
<li>We kunnen Porky een beetje draaien tijdens de animatie waardoor het effect verstrekt wordt</li>
</ul>
<p>Die tweede kunnen we oplossen met <code>rotateZ</code>, maar voor die eerste moeten we nog een truukje uithalen. Omdat we een plaatje gebruiken kunnen we niet <code>box-shadow</code> gebruiken, die maakt namelijk een vierkant schaduwtje om het <code>::after</code> element.</p>
<p>In plaats daarvan kunnen gebruik maken van een <code>filter</code>. Wanneer je die gebruikt wordt er gekeken naar de ondoorzichtige pixels van een element, en die krijgen een schaduwtje. Voeg je dat samen, dan krijg je dit:</p>
<pre><code>@keyframes zoom {
0% {
transform: rotateX(-10deg) scale(0.66);
filter: drop-shadow(-5px 5px 5px rgba(0,0,0,0));
}
40% {
transform: rotateZ(-10deg) rotateX(-10deg) scale(1);
filter: drop-shadow(-10px 10px 10px rgba(0,0,0,0.5));
}
60% {
transform: rotateZ(-10deg) rotateX(-10deg) scale(1);
filter: drop-shadow(-10px 10px 10px rgba(0,0,0,0.5));
}
100% {
transform: rotateX(-10deg) scale(0.66);
filter: drop-shadow(-5px 5px 5px rgba(0,0,0,0));
}
}
</code></pre>
<p>En hier is de uiteindelijke Codepen:</p>
<p><a href="https://codepen.io/Kilian/pen/yLJBymR">Porky Pig &quot;That's all Folks&quot; in pure CSS</a></p>
<p>En zo hebben we een animatie gemaakt van Porky Pig die ons uitzwaait en rest mij enkel nog het volgende te zeggen: &quot;That's all Folks!&quot;</p>
</content>
</entry>
<entry>
<title>Basics van front-end testing</title>
<link href="https://www.fronteers.nl/nl/blog/2021/01/basics-van-front-end-testing"/>
<updated>2021-01-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2021/01/basics-van-front-end-testing</id>
<content xml:lang="nl" type="html"><p>Als front-end developer zullen de begrippen unit test, integration test en end-to-end test je waarschijnlijk wel bekend voorkomen. Maar wat is het en wanneer gebruik je welke test? Dit artikel is een kleine intro tot de verschillende soorten tests en tools die je als front-end developer tot je beschikking hebt om je code te testen en uiteindelijk de kwaliteit te verbeteren.</p>
<h2>Unit test</h2>
<p>Het begint meestal met unit tests. Een unit test is een test die een op zichzelf staand onderdeel van je code controleert. Bij een unit test is de context van de functie in de applicatie niet van belang. Er wordt puur getest of een functie bij dezelfde input altijd dezelfde output teruggeeft. Oftewel, als je <em>a</em> er in stopt, moet je altijd <em>b</em> terug krijgen.</p>
<p>Unit tests maken het ook mogelijk om alle mogelijke uitkomsten van een functie snel te controleren. Je hoeft dan niet je applicatie op te starten en handmatig de mogelijkheden te testen; je kunt de unit tests starten. Daarmee kun je tijdens het ontwikkelen tijd besparen en vervelende verrassingen voorkomen bij een acceptance test.</p>
<p>Zo is het bijvoorbeeld bij een checkout van een webshop belangrijk dat een klant een geldige postcode invult. Ter validatie van je code kun je een eenvoudige unit test maken. Stel dat dit je validatie functie is:</p>
<pre><code>function validatePostcode(postcode) {
const matches = postcode.match(/(?:&lt;getal&gt;\d\d\d\d) (?:&lt;letters&gt;[A-Z])/);
if (!matches) return false;
const number = parseInt(matches.groups.getal, 10);
const chars = matches.groups.letters;
// Check number range
if (number &lt; 1000 || number &gt; 9992) return false;
return true;
}
</code></pre>
<p>Dan kun je met deze unit test checken of je bij verschillende waardes de juiste <code>boolean</code> terug krijgt. Voor dit voorbeeld gebruik ik Jest, een JavaScript testing framework dat met vrijwel alle JavaScript frameworks werkt.</p>
<pre><code>// Import jest
test('validatePostcode should return true', () =&gt; {
expect(validatePostcode('1000 AA')).toBe(true);
expect(validatePostcode('7777 AA')).toBe(true);
expect(validatePostcode('9992 AA')).toBe(true);
});
test('validatePostcode should return false', () =&gt; {
expect(validatePostcode('000 AB')).toBe(false);
expect(validatePostcode('1000 A')).toBe(false);
expect(validatePostcode('0000 AB')).toBe(false);
expect(validatePostcode('0001 AB')).toBe(false);
expect(validatePostcode('9993 AB')).toBe(false);
});
</code></pre>
<p>Je kunt je waarschijnlijk wel voorstellen dat dit een hoop tijd bespaart. Je hoeft niet de website te openen en de checkout meerdere malen te doorlopen om verschillende postcodes te testen.</p>
<h2>Integration test</h2>
<p>Een integration test is een test waarbij in tegenstelling tot een unit test de context er wel toe doet. Je test meerdere onderdelen van een keten, bijvoorbeeld om te checken of een functie correct is aangeroepen. Voor een integration test kun je ook Jest gebruiken. Soms kan het benodigd zijn om bij een integration test bepaalde onderdelen van de applicatie te <em>mocken</em>. Stel je voor dat je een <em>submit</em> van een formulier wilt testen, dan kan het zijn dat je de uitkomst van een <em>api callback</em> moet mocken omdat je bij het uitvoeren van de test geen toegang hebt tot de API.</p>
<h2>End-to-end (e2e) test</h2>
<p>Een end-to-end test is een test waarbij het gedrag van de gebruiker wordt gesimuleerd, die verschillende scenario's probeert uit te voeren met een bepaalde gewenste uitkomst. Zo kun je de belangrijkste happy- en non-happy flows testen. Een end-to-end test is een blackbox test. De test heeft geen kennis van de code, maar voert acties uit: aanklikken van een button, invullen van een formulier, submit, etc. Unit tests behoren tot een whitebox test, de test roept direct de code aan.</p>
<p>Wat je vaak ziet is dat e2e tests worden geschreven met behulp van <em>cucumber</em> in het format <em>gherkin</em>. In leesbare taal staat uitgeschreven welke stappen uitgevoerd worden en vervolgens kunnen die stappen bij scenarios worden hergebruikt.</p>
<p>Je kunt <em>user stories</em> als uitgangspunt voor je scenario's. Het begint met een feature: ‘Als klant wil ik betalen’, met scenario’s als: ‘Als klant wil ik betalen met iDeal’. De focus ligt altijd op de business value die gecreëerd wordt voor een gebruiker. Zo'n leesbare e2e test kan er zo uitzien:</p>
<pre><code>Feature: Als klant wil ik betalen
Scenario: Als klant wil ik betalen met iDeal
Given Een correct ingevuld checkout formulier
When de klant probeert te betalen
Then de klant ziet de iDeal-pagina van de payment provider
</code></pre>
<p>Er zijn allerlei soorten software om een end-to-end tests uit te voeren. In het Angular ecosysteem is de combinatie Protractor met Selenium een bekende. Een andere interessante app is Cypress.io, waarbij je elke stap ook daadwerkelijk kunt zien gebeuren. Dit helpt bij het ontwikkelen van de tests. Als er iets onverwachts gebeurd, dan blijft het proces op de stap haken en kun je zien wat er aan de hand is.</p>
<h2>Testen, testen, testen</h2>
<p>Je weet nu waar te starten met front-end testing. Het is een goede basis, maar met unit tests, integration tests of end-to-end tests zijn we er helaas nog niet. Je hebt onder andere ook nog: acceptance tests door acceptanten, accessibility tests, cross browser compatibility tests, system integration testing (over meerdere delen van de keten testen) en natuurlijk visuele regressie testing. Front-end development is zo eenvoudig nog niet.</p>
</content>
</entry>
<entry>
<title>&quot;Even snel&quot; een project starten</title>
<link href="https://www.fronteers.nl/nl/blog/2021/01/even-snel-een-project-starten"/>
<updated>2021-01-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2021/01/even-snel-een-project-starten</id>
<content xml:lang="nl" type="html"><p>Je kent het wel, je wil even snel iets bouwen of wat code uitproberen. Je maakt een map aan, gooit daarin een index.html, een CSS bestand en een JavaScript bestandje, om vervolgens met wat code te rommelen. In dit voorbeeld heb je gewoon statische bestanden die je in een browser (naar keuze) kunt laden om te checken of het klopt wat je aan het maken bent.</p>
<p>Je kent het wel, je wil even snel iets bouwen of wat code uitproberen. Je maakt een map aan, gooit daarin een index.html, een CSS bestand en een JavaScript bestandje, om vervolgens met wat code te rommelen. In dit voorbeeld heb je gewoon statische bestanden die je in een browser (naar keuze) kunt laden om te checken of het klopt wat je aan het maken bent.</p>
<p>Als ik met een onderdeel bezig ben voor een project en het wil maar niet lukken, doe ik dit soms. Dan vind ik het handig als ik dat ene onderdeeltje even uit het grotere geheel kan halen om er los van het project mee aan de gang te gaan. Ik vind het zelf dan wel heel handig als de browser de pagina herlaad als ik iets aangepast heb. Maar dan komen er nog meer handelingen aan te pas voordat ik kan beginnen. Dat is allemaal best te doen, maar wat zou het toch handig zijn als dat met één commando veel sneller kan?</p>
<p>Natuurlijk kan dat! Ik heb in mijn <em>command line</em> een functie gemaakt die in een mum van tijd een klein projectje voor me aanmaakt, zodat ik snel iets uit kan proberen.</p>
<p>In het <em>config</em> bestand van de <em>command line</em> kun je namelijk zelf functies maken. De functie die ik gebruik ziet er als volgt uit:</p>
<pre><code>function basicsetup() {
mkdir /home/reneedekruijf/Bureaublad/&quot;$1&quot;
cd /home/reneedekruijf/Bureaublad/&quot;$1&quot;
mkdir /home/reneedekruijf/Bureaublad/&quot;$1&quot;/images
mkdir /home/reneedekruijf/Bureaublad/&quot;$1&quot;/js
mkdir /home/reneedekruijf/Bureaublad/&quot;$1&quot;/css
touch index.pug js/script.js css/style.css
code .
npm init -y
parcel serve index.pug --open
}
</code></pre>
<p>Als ik nu iets wil uitproberen, type ik in de terminal: <code>basicsetup &quot;testproject&quot;</code>. Er wordt nu een folder op mijn bureaublad aangemaakt met de naam <em>testproject</em>.</p>
<p>Deze functie <code>basicsetup</code> roep je aan door de naam in je CLI te typen, de functie wordt dan uitgevoerd. Ik heb op een paar plekken <code>$1</code> gebruikt. Dit is een variabele die je een willekeurige waarde mee kunt geven. Dit doe je door achter de functienaam de naam van je project in te voeren tussen aanhalingstekens. In dit geval wordt <code>$1</code> dus <em>testproject</em>. Die kun je vervolgens in de functie zo vaak als je wil terug laten komen.</p>
<h2>Wat doet deze code?</h2>
<p>Op de eerste regel maken we de folder aan door het commando <code>mkdir</code> te gebruiken, dit staat voor <em>make directory</em>.</p>
<p>Op de volgende regel gebruiken we <code>cd</code> (<em>change directory</em>) om in de folder <em>testproject</em> te komen, die we net hebben gemaakt. In de drie volgende regels gebruiken we weer <code>mkdir</code> om in de nieuw aangemaakte folder achtereenvolgens drie nieuwe folders te maken, een images-, een js- en css-folder.</p>
<p>Dan maken we met <code>touch</code> (hiermee kun je bestanden aanmaken) drie bestanden aan. Een CSS file en een JavaScript file en beide al meteen in de juiste folder. Als laatste van deze regels maken we een index.pug bestand in de root folder.</p>
<p>Deze <em>index</em> heeft niet de extensie <code>.html</code> maar <code>.pug</code>. <a href="https://pugjs.org/api/getting-started.html">PUG</a> is een templating taal voor HTML. Met PUG kun je met een aangepaste notatie HTML genereren. Ook kun je templates maken en je kunt variabelen gebruiken. De header of de footer zet je 1x op en die kun je steeds blijven gebruiken in al je bestanden, als je nu iets verandert in de header of footer dan hoef je dat maar 1x te doen. PUG-code moet alleen wel omgezet worden naar HTML (net zoals SASS ook omgezet wordt in CSS) en daar heb je tooling voor nodig, dat wordt in de laatste 2 regels van de <code>basicsetup</code> opgezet.</p>
<p>Met <code>code .</code> start ik <a href="https://code.visualstudio.com/">Visual Studio Code</a> op, dit is de code editor die ik graag gebruik. Als je een andere editor gebruikt dan komt hier het commando voor die editor te staan.</p>
<p>De laatste twee regels dienen meerdere doelen. Als je dit wilt laten werken op je eigen computer heb je <a href="https://nodejs.org/en/">Nodejs</a> nodig. Dit kun je gewoon installeren en is voor elk platform te downloaden. Zonder Nodejs kun je <code>PUG</code> niet gebruiken en werken de laatste twee regels dus ook niet.</p>
<p>De regel <code>npm init -y</code> zorgt ervoor dat je folder klaar wordt gemaakt voor het installeren van <em>NPM packages</em>, dit zijn kleine programmaatjes die je kunt installeren en die het leven van een developer makkelijker (kunnen) maken. Op <a href="https://www.npmjs.com/">https://www.npmjs.com/</a> kun je zoeken naar deze packages.</p>
<p><a href="https://parceljs.org/">Parcel</a> is zo'n NPM package en deze moet je van tevoren installeren. Op de site van <em>Parcel</em> kun je zien hoe dat moet. <em>Parcel</em> is een zogenaamde bundler en kan meerdere handige dingen voor je doen. Ik gebruik het hier vooral om mijn PUG code om te zetten naar HTML en ik gebruik het voor hot reloading. Dit laatste zorgt ervoor dat mijn browser automatisch wordt ververst als ik iets in de HTML, CSS of JavaScript aanpas. Je ziet dus meteen wat je aanpast in je code. Echt heel handig. Parcel werkt out-of-the-box. Je hebt daarvoor wel de laatste regel van de <code>basicsetup</code> functie nodig, dan wordt automatisch PUG omgezet naar HTML, en je krijgt hot reloading. Eigenlijk zorgt Parcel ervoor dat je een pagina in HTML krijgt met CSS en Javascript.</p>
<p>Dus wil je snel even wat dingetjes checken of uitproberen, dan kan deze functie je helpen. Door een kort commando in de <em>command line</em> heb je snel een basis setup waar je mee aan de slag kunt.</p>
</content>
</entry>
<entry>
<title>Not another JS framework - zelf een JavaScript framework schrijven</title>
<link href="https://www.fronteers.nl/nl/blog/2021/01/not-another-js-framework-zelf-een-javascript-framework-schrijven"/>
<updated>2021-01-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2021/01/not-another-js-framework-zelf-een-javascript-framework-schrijven</id>
<content xml:lang="nl" type="html"><p>React beter leren. Het staat al een hele tijd op mijn to do list, omdat we op mijn werk met React werken. Ik leer het beste door dingen te doen, maar ik hou niet van korte &quot;Hello World&quot; tutorials van een uurtje waarna je eigenlijk nog niets hebt geleerd. Daarom kreeg ik een studieopdracht op het werk: bouw React na. Mijn eigen JavaScript framework maken... Ik moest even slikken. Dat kan ik toch nooit?! Maar ik liet het even bezinken, kreeg wat eerste instructies en ging toen toch aan de slag. Omdat ik ook goed leer door op te schrijven wat ik heb gedaan, doe ik dat hier. Wellicht inspireert het jou om ook zoiets te proberen.</p>
<h2>Research</h2>
<p>Ik begon mijn research - uiteraard - met wat googlen. Ik kwam verschillende tutorials tegen die je er door heen loodsen om je eigen framework te maken, maar de moed zonk me in de schoenen. Oké, ik heb duidelijk een andere aanpak nodig. Ik begon de documentatie van React door te lezen en samen met de eerste instructies die ik had meegekregen - &quot;maak een <em>render</em> functie, gebruik <code>createElement</code>&quot; - maakte ik een plan van aanpak.</p>
<h2>Stap 0: Een naam</h2>
<p>Naamgeving: soms ook wel het moeilijkste deel van programmeren. Na lang nadenken en geen leuke namen, kies ik voor het meest flauwe dat ik kan bedenken. Ik noem mijn framework Clippy. <a href="https://knowyourmeme.com/memes/clippy">Wie kent 'm niet?</a></p>
<h2>Stap 1: Maak een statische render functie</h2>
<p>De belangrijkste functie uit React is waarschijnlijk wel <code>ReactDOM.render()</code>. Deze functie zorgt ervoor dat React elementen daadwerkelijk getoond worden.</p>
<p>Hier moet ik dus mee beginnen. Allereerst maak ik een index.html met een <code>&lt;div id=&quot;clippy&quot;&gt;&lt;/div&gt;</code>. In dit bestand wordt een clippy.js file aangroepen met als enige functie een <code>render</code> met een <em>hard coded</em> <code>div</code> en een <code>string</code> &quot;Hello Clippy&quot;.</p>
<pre><code>function render() {
const element = document.createElement(&quot;div&quot;);
const content = document.createTextNode(&quot;Hello Clippy&quot;);
const clippy = document.getElementById(&quot;clippy&quot;);
element.appendChild(content);
clippy.appendChild(element);
}
</code></pre>
<p>Hé, dat ging me iets makkelijker af dan ik had gedacht! Na een uur of twee van researchen, lezen en aan mijn eigen kunnen twijfelen, had ik dit zo staan. Een mooi voorbeeld dat ik beter gewoon kan beginnen en dingen doen.</p>
<h2>Stap 2: Dynamische content renderen met een <code>createClippyElement</code></h2>
<p>Dat het werkt met de te renderen <code>const</code> is een goede eerste stap, daar word ik blij van. Maar dit is niet hoe React er uit ziet. Hier wordt meestal JSX voor gebruikt. Dat ziet er bijvoorbeeld zo uit: <code>const element = &lt;h1&gt;Hello world!&lt;/h1&gt;</code>. Met Babel wordt deze JSX expressie <em>transpiled</em> naar een <code>React.createElement</code> functie.</p>
<p>De volgende stap is dus het maken van een <code>createClippyElement</code> functie. De functie krijgt drie parameters; een type <code>string</code> om aan te geven welk HTML element gerenderd moet worden; een props <code>object</code> dat bijvoorbeeld een className of inline styles bevat; en een <code>array</code> van children. Een child kan een nieuw <code>createClippyElement</code> zijn maar bijvoorbeeld ook een <code>string</code> met tekst. Voor nu doet deze functie nog niets anders dan de parameters returnen.</p>
<pre><code>function createClippyElement( type, props, children ) {
return {
type,
props,
children
}
}
</code></pre>
<p>De <code>render</code> functie moet iets herschreven worden, zodat ik het <code>createClippyElement</code> kan meegeven als parameter. Ik besluit om de props nog even achterwege te laten, maar eerst te zorgen dat ik een HTML element met content kan laten renderen.</p>
<p>Dat valt op zich wel mee. Zo zou ik er al zijn:</p>
<pre><code>function render( clippy, container ) {
let element = document.createElement( clippy.type );
let content = document.createTextNode( clippy.children )
element.appendChild(content);
clippy.appendChild(container);
}
</code></pre>
<h2>Stap 3 en 4: render children én grandchildren</h2>
<p>Maar wat als een child zelf children heeft? En die ook weer? Ik maak een aparte <em>recursive</em> functie, die dit oppakt. Na een hoop <em>console loggen</em> en een pair programming sessie heb ik het uiteindelijk voor elkaar.</p>
<pre><code>function createChildElements( element, children ) {
for( let i = 0; i &lt; children.length; i++ ) {
let child = children[ i ];
let childElement;
if ( typeof child === &quot;string&quot; ) {
childElement = document.createTextNode( child );
}
if ( typeof child === &quot;object&quot; ) {
childElement = document.createElement ( child.type );
if ( child.children.length &gt; 0 ) {
childElement = createChildElements( childElement, child.children );
}
}
element.appendChild( childElement );
}
return element;
}
</code></pre>
<p>De <code>render</code> functie moet nu ook iets aangepast worden om de <code>createChildElements</code> functie te gebruiken. Dat ziet er als volgt uit:</p>
<pre><code>function render( clippy, container ) {
let element = document.createElement( clippy.type );
if( clippy.children.length &gt; 0 ) {
element = createChildElements( element, clippy.children );
}
container.appendChild( element );
};
</code></pre>
<p>Met nog geen vijftig regels code kan ik nu mijn eigen componenten maken én renderen.</p>
<h2>Hoe nu verder?</h2>
<p>Ik had graag een mooie werkende versie van mijn eigen React-inspired framework willen laten zien, maar... zo ver ben ik nog niet. In dit studieproject gaan nog heel wat uren zitten. Zo wordt het belangrijk om props te kunnen renderen en wil ik er nog in duiken hoe state en lifeycle in React werkt.</p>
<p>Maar op deze manier ben ik er in geslaagd om een opdracht die me onmogelijk leek, toch vorm te geven! Het is voor mij een goede manier om te leren. Ik word uitgedaagd, heb iets om naar toe te werken en leer op mijn eigen manier en tempo. Ideaal!</p>
<h2>Zelf aan de slag?</h2>
<p>Wil je zelf eens zien hoe deze functies nu samen komen en zorgen dat je een HTML element kunt renderen op een pagina? Probeer <a href="https://codepen.io/joseewouters/pen/VwKQdpd">deze CodePen</a> eens uit! Je kunt ook proberen om op basis van mijn code zelf verder te gaan om te kijken of je bijvoorbeeld props kunt toevoegen.</p>
</content>
</entry>
<entry>
<title>Labels zijn niet altijd wat ze lijken: hoe wordt de Accessible Name berekend?</title>
<link href="https://www.fronteers.nl/nl/blog/2021/01/labels-zijn-niet-altijd-wat-ze-lijken-hoe-wordt-de-accessible-name-berekend"/>
<updated>2021-01-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2021/01/labels-zijn-niet-altijd-wat-ze-lijken-hoe-wordt-de-accessible-name-berekend</id>
<content xml:lang="nl" type="html"><p>Sinds november ben ik aan de slag als Web Accessibility Consultant bij <a href="https://www.elevenways.be/">Eleven Ways</a>. Het toegankelijk maken van websites (zodat iedereen ze kan gebruiken) is altijd al een onderwerp geweest waar ik me graag voor wilde inzetten.</p>
<p>Al tijdens mijn eerste werkweek leerde ik iets wat me verraste. Ik herinner me dat ik luidop “Woah!” zei tegen mijn computerscherm. Dat “iets” is de zogeheten <em>Accessible Name</em>. Omdat er niet veel Nederlandstalige artikelen over te vinden zijn, wijd ik er graag een stukje aan.</p>
<h2>Wat is de Accessible Name?</h2>
<p>Er zijn een aantal HTML-elementen die interactief zijn. Het gaat dan om elementen als links, knoppen, invoervelden, selectievakjes en keuzelijsten.</p>
<p>In de richtlijnen voor toegankelijkheid zegt het W3C in <a href="https://www.w3.org/Translations/WCAG21-nl/#label-in-naam">Succescriterium 2.5.3</a> over interactieve elementen het volgende:</p>
<blockquote>
<p>Bij componenten van de gebruikersinterface met labels die tekst of afbeeldingen van tekst bevatten, bevat de naam de tekst die visueel wordt weergegeven.</p>
</blockquote>
<p>Dat is een mond vol. Het komt erop neer dat alle interactieve componenten zowel een <em>label</em> als een <em>naam</em> moeten krijgen.</p>
<p>Maar zijn labels en namen niet hetzelfde? Nee. Het <em>label</em> is wat gebruikers typisch op het scherm zien. De <em>naam</em> is wat hulpsoftware ziet. Hulpsoftware haalt de <em>naam</em> uit de zogeheten <a href="https://developer.mozilla.org/en-US/docs/Glossary/Accessibility_tree">Accessibility Tree</a>, die op haart beurt een vereenvoudiging is van het Document Object Model.</p>
<p>Anders gezegd: een <em>label</em> wordt <em>visueel</em> weergegeven, maar een naam wordt enkel opgepikt door hulptechnologieën als schermlezers en spraaksoftware. De <em>naam</em> is dus extra belangrijk om interactieve elementen toegankelijk te maken. In WCAG-jargon noemen we deze naam daarom (toepasselijk, en om verwarring te voorkomen) graag de <a href="https://www.w3.org/TR/accname-1.1/">Accessible Name</a>.</p>
<p>(Noot: dit succescriterium hangt nauwe samen met <a href="https://www.w3.org/Translations/WCAG21-nl/#naam-rol-waarde">Succescriterium 4.1.2</a> dat voorschrift dat elementen een correcte naam (<em>name</em>), rol (<em>role</em>) en waarde (<em>value</em>) moeten hebben.)</p>
<h2>Hoe wordt de Accessible Name bepaald?</h2>
<p>De Accessible Name wordt volgens onderstaande rangorde bepaald (van belangrijkst naar minst belangrijkst):</p>
<ol>
<li>Het <code>aria-labelledby</code> attribuut (waarde van attribuut is de id-waarde van een element dat elders staat, vaak een <code>&lt;p&gt;</code>. Werking vergelijkbaar met anchor-links)</li>
<li>Het <code>aria-label</code> attribuut (waarde van attribuut is gewoon tekst)</li>
<li>Het <code>&lt;label&gt;</code> element (bij formulieronderdelen)</li>
<li>Het <code>value</code> attribuut (bij formulieronderdelen)</li>
<li>Het <code>alt</code> attribuut (enkel bij afbeeldingen)</li>
<li>Inhoud tussen begin- en eindtag (bij links en knoppen)</li>
<li>Het <code>title</code> attribuut</li>
</ol>
<p>Er wordt dus in eerste instantie gekeken of een <code>aria</code>-attribuut aanwezig is.</p>
<p>En nu komen we bij de crux van het hele verhaal.</p>
<ul>
<li>Als een element <em>nog geen naam</em> had dat uit de punten 3 t/m 7 gehaald kan worden, wordt die <em>toegevoegd</em> door de waarde van het <code>aria-labelledby</code> of het <code>aria-label</code> attribuut</li>
<li>Als een element <em>al een naam</em> had dat uit de punten 3 t/m 7 gehaald kan worden, wordt die <em>vervangen</em> door de waarde van het <code>aria-labelledby</code> of het <code>aria-label</code> attribuut</li>
</ul>
<p>Een <code>aria-label</code> of <code>aria-labelledby</code> krijgt dus <em>altijd</em> voorrang.</p>
<p>(Merk op dat deze berekening gebeurt op basis van de <a href="https://www.w3.org/TR/accname-1.1/">Accessible Name and Description Computation 1.1</a>-specificatie van het W3C. De meeste Accessibility API’s in browsers en besturingssystemen houden zich hier netjes aan.)</p>
<h2>Voorbeelden</h2>
<p>Laten we even naar een eenvoudig voorbeeld kijken:</p>
<pre><code>&lt;a href=&quot;/overons&quot; title=&quot;Ons bedrijf&quot;&gt;Ons familiebedrijf&lt;/a&gt;
</code></pre>
<p>Visueel zal <em>Ons familiebedrijf</em> getoond worden. Het <code>title</code> attribuut wordt genegeerd door hulpsoftware omdat het de laagste prioriteit heeft. De inhoud tussen de begin- en eindtag krijgt voorrang.</p>
<p>(Merk op dat in sommige situaties het <code>title</code> attribuut toch wordt opgepikt door hulpsoftware, maar dan uitsluitend als “tooltip”. Omdat je er nooit zeker van kan zijn dat de informatie wordt voorgelezen, is het dus geen goed idee om essentiële informatie te verstoppen in een <code>title</code> attribuut.)</p>
<p>Voorbeeld twee:</p>
<pre><code>&lt;a href=&quot;lego.html&quot;&gt;
&lt;img src=&quot;lego.png&quot; alt=&quot;Lego Modular Assembly Square&quot;&gt;
150 euro
&lt;/a&gt;
</code></pre>
<p>Deze link zal door hulpsoftware worden opgelezen als: <em>Lego Modular Assembly Square 150 euro</em>. De alt-tekst <em>en</em> de tekst worden hier bij elkaar opgeteld.</p>
<p>Dit is bijvoorbeeld ook de reden waarom een populair UI-patroon als <em>cards</em> vaak toegankelijkheidsproblemen vertonen. Lees de uitstekende <a href="https://adrianroselli.com/2020/02/block-links-cards-clickable-regions-etc.html">blog van Adrian Roselli</a> of de <a href="https://www.nomensa.com/blog/2020/how-build-accessible-cards%E2%80%93block-links">blog van Nomensa</a> daar maar eens over.</p>
<p>Een laatste voorbeeld:</p>
<pre><code>&lt;a href=&quot;lego.html&quot; title=&quot;Mijn Lego pagina&quot; aria-label=&quot;Mijn hele dure Lego-winkel&quot;&gt;
&lt;img src=&quot;lego.png&quot; alt=&quot;Lego Modular Assembly Square&quot;&gt;
150 euro
&lt;/a&gt;
</code></pre>
<p>Vind je het addertje onder het gras? Dit is wat er gebeurt:</p>
<ul>
<li>Het <code>title</code> attribuut wordt genegeerd, omdat er tekst staat tussen de begin- en eindtag.</li>
<li>De tekst ‘150 euro’ en de alt-tekst van het plaatje worden bij elkaar opgeteld omdat deze tussen de begin- en de eindtag staan.</li>
<li>Maar — en dit is belangrijk — beide waarden worden vervolgens <em>overschreven</em> door het <code>aria-label</code> attribuut dat op het <code>&lt;a&gt;</code> element is geplaatst.</li>
</ul>
<p>De link zal uiteindelijk klinken als <em>Mijn hele dure Legowinkel</em>. De naam en de prijs van het product worden dus <em>niet</em> langer opgepikt, en dat is natuurlijk niet de bedoeling. Wees dus extra voorzichtig met het gebruik van ARIA-labels.</p>
<h2>Hoe kun je de Accessible Name controleren?</h2>
<p>In de Developer Tools van Chrome kun je de Accessibility Tree inspecteren. Zo krijg je een idee van hoe de naam van een specifiek element berekend wordt.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/accessiblename-chrome.jpeg" alt="De Accessibility Tree in Chrome dat de naam en rol van een element laat zien" /></p>
<p>(Dat kan overigens ook in andere browsers.)</p>
<p>Natuurlijk kan je ook zelf de proef op de som nemen en je pagina testen met een echte screenreader als Jaws, NVDA of VoiceOver. Zo kan je zelf horen hoe je knoppen, links en andere interactieve elementen worden opgelezen.</p>
<h2>Oefening:</h2>
<p>Wat wordt de Accessible Name van deze button? (dank aan Erik Kroes voor deze leuke instinker!) Laat een reactie achter met je antwoord!</p>
<pre><code>&lt;button type=&quot;button&quot; aria-labelledby=&quot;button&quot; aria-label=&quot;click here&quot; title=&quot;click&quot;&gt;
&lt;img alt=&quot;click me&quot;&gt;
&lt;/button&gt;
</code></pre>
<h2>Bronnen en verder lezen</h2>
<ul>
<li><a href="https://www.w3.org/TR/accname-1.1/">W3C - Accessible Name and Description Computation 1.1</a></li>
<li><a href="https://webaim.org/articles/label-name/">WeAIM - Decoding Label and Name for Accessibility</a></li>
<li><a href="https://developer.paciellogroup.com/blog/2017/04/what-is-an-accessible-name/">The Paciello Group - What is an accessible name?</a></li>
<li><a href="https://simplyaccessible.com/article/accessible-name/">Simply Acessible - Demystifying the accessible name?</a></li>
<li><a href="https://hiddedevries.nl/en/blog/2019-04-18-naming-things-to-improve-accessibility">Hidde de Vries - Naming things to improve accessibility</a></li>
</ul>
</content>
</entry>
<entry>
<title>Beveiligde gegevens ophalen met OpenID Connect en access tokens</title>
<link href="https://www.fronteers.nl/nl/blog/2020/12/beveiligde-gegevens-ophalen-met-openid-connect-en-access-tokens"/>
<updated>2020-12-31T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/12/beveiligde-gegevens-ophalen-met-openid-connect-en-access-tokens</id>
<content xml:lang="nl" type="html"><p>Wat hebben de website van je bank, een webshop en Twitter gemeen? Ze hebben een publiek gedeelte en tonen daarnaast content op basis van je account. Nadat je bent ingelogd, kun je bij je bank je saldo bekijken, geld overmaken of een nieuwe pas aanvragen. Op de webshop kun je eerdere bestellingen raadplegen of je verlanglijstje bijwerken. Bij Twitter kun je tweets plaatsen, notificaties ontvangen of je profiel aanpassen.</p>
<p>Het is wel de bedoeling dat de frontend de gegevens van de juiste gebruiker toont. In deze blogpost lees je hoe dat kan met het gebruik van OpenID Connect en access tokens.</p>
<h2>Sessies</h2>
<p>Als alle pagina's volledig op de server worden gerenderd, hoef je als front-ender je alleen bezig te houden met de opmaak van de inlogpagina. Bij het opvragen van een beveiligde pagina stuurt de server je door naar de inlogpagina. De gebruiker vult een gebruikersnaam en wachtwoord in. Als deze juist zijn, maakt de server een sessie aan en zet de identifier van deze sessie in een cookie. Bij elke (beveiligde) pagina stuurt de browser het sessiecookie mee en de server geeft de persoonlijke content terug zolang de sessie geldig is.</p>
<p>Bij client side rendering kun je dit nog steeds doen. Vraag je beveiligde gegevens op of wil je gegevens wijzigen, dan kan het antwoord een http response status 401 zijn: authorisatie vereist. Op basis van deze response laat je de gebruiker inloggen. Ook dan kan de server een sessiecookie meesturen waardoor de volgende requests wel de beveiligde gegevens kunnen opvragen of aanpassen.</p>
<p>De backendontwikkelaar of de beheerder moeten hier wel extra moeite voor doen. Sessies zijn normaal gesproken gebonden aan een server. Doe je een request op een andere server, dan zal deze opnieuw vragen om in te loggen. Bij een wat grotere website heb je al snel te maken met meerdere servers om beschikbaarheid te garanderen. Ook hier zijn oplossingen voor: de gebruiker elke keer op dezelfde server uit laten komen of de sessies synchroniseren tussen de servers. Dit zullen backend developers en beheerders moeten inregelen.</p>
<p>Grotere websites kunnen uit verschillende backend applicaties bestaan die onderling geen sessies uit kunnen wisselen maar wel willen weten wie er ingelogd is. Elke backend applicatie zou dan zowel verantwoordelijk zijn voor het inloggen als het teruggeven van de juiste gegevens.</p>
<h2>JSON Web Tokens</h2>
<p>Een alternatief voor sessiecookies is het gebruik van tokens die je per request meestuurt. Deze tokens kunnen willekeurige, niet te voorspellen strings zijn, maar ook <a href="https://en.wikipedia.org/wiki/JSON_Web_Token">JSON Web Tokens</a>. Een JSON Web Token (JWT, uit te spreken als &quot;dzjôht&quot;) bestaat uit drie delen: een header, de payload en een signature (handtekening).</p>
<p>De payload is een JSON object met “claims”, bijvoorbeeld de geldigheid, voor wie het token bestemd is, je gebruikersnaam, e-mailadres of abonnement. Een voorbeeld van de payload van een JWT:</p>
<pre><code>{
&quot;sub&quot;: &quot;jasha&quot;,
&quot;iss&quot;: &quot;https://example.com/op&quot;,
&quot;aud&quot;: [&quot;Fronteers&quot;]
}
</code></pre>
<p>In dit voorbeeld heeft de payload van de JWT drie claims: sub (gebruiker) en iss (issuer) en aud (audience). Deze claims worden later uitgelegd. Wanneer de frontend mijn profiel opvraagt bij de server, stuurt deze de JWT mee met het request. De backend valideert de JWT en stuurt vervolgens mijn profiel terug naar de frontend.</p>
<h2>Validatie: signature</h2>
<p>Hoe kun je een JWT valideren? De uitgever van de JWT zal de header en payload ondertekenen met een JSON Web Key (JWK). Hierbij wordt een cryptografisch algoritme gebruikt. De meest veilige variant werkt met een geheime en een publieke sleutel. De uitgever gebruikt de geheime sleutel om de signature aan te maken. De ontvanger kan vervolgens met de publieke sleutel deze handtekening valideren. Als deze validatie slaagt, weet de ontvanger dat er niet met de JWT is gerommeld. Hierbij is het van groot belang dat die geheime sleutel ook echt geheim blijft.</p>
<p>Om de handtekening te valideren moet de ontvanger de publieke sleutel en het algoritme wel weten. Dit kan op twee manieren: de uitgever stelt een lijst van publieke sleutels online beschikbaar met het bijbehorende algoritme. Deze lijst bevat vaak de huidige sleutel, maar ook de vorige en een toekomstige zodat de uitgever een nieuwe set sleutels kan gaan gebruiken zonder dat de eindgebruiker hier last van heeft. Het kan ook dat de publieke sleutels en het algoritme voor een deployment worden uitgewisseld, bijvoorbeeld via e-mail. Een nadeel is dat deze lijst handmatig moet worden bijgewerkt.</p>
<h2>Validatie: claims</h2>
<p>De payload van een JWT kan (optionele) claims bevatten met betrekking tot de geldigheid:</p>
<ul>
<li><code>iss</code> (issuer): een unieke identifier voor de uitgever. Is deze anders dan je verwacht, dan kun je de JWT niet vertrouwen.</li>
<li><code>aud</code> (audience): een lijst van identifiers voor de ontvangers. Alleen als de identifier van jouw applicatie er tussen staat, hoor je de JWT te vertrouwen. Waarom is dit een lijst? Een JWT mag je namelijk doorgeven aan bijvoorbeeld je backend. Ook de backend applicaties kunnen in de <code>aud</code> claim voorkomen en die kunnen zelf dan weer de JWT valideren en gebruiken voor het teruggeven van data.</li>
<li><code>sub</code> (subject): unieke identifier van de gebruiker.</li>
<li><code>exp</code> (expiration time): timestamp tot wanneer deze JWT geldig is. Is deze tijd verstreken, dan dien je de JWT niet meer te accepteren.</li>
<li><code>nbf</code> (not before): timestamp vanaf wanneer deze JWT geldig is. Is deze tijd nog niet bereikt, dan mag je deze JWT nog niet accepteren.</li>
</ul>
<p>Door de combinatie van de handtekening en deze claims kunnen de frontend en diverse backend services onafhankelijk van elkaar beslissen tot welke (beveiligde) gegevens de gebruiker op dat moment toegang heeft. Hierdoor is het niet meer nodig sessies te synchroniseren.</p>
<h2>OpenID Connect</h2>
<p>Hoe kom je aan een JWT? Hiervoor zijn standaarden ontwikkeld. Een daarvan is <a href="https://openid.net/">OpenID Connect</a> (OIDC). OpenID Connect is een laag bovenop <a href="https://oauth.net/">OAuth 2.0</a>. Waar OAuth alleen de authorisatie regelt (wat mag je), regelt OIDC ook de authenticatie (wie ben je). In het vervolg behandel ik ze als één standaard waarbij ik de termen van OpenID Connect gebruik.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/oidc-schema-4.svg" alt="Schematische weergave van gegevens ophalen met OpenID Connect" /></p>
<p>Jouw webapplicatie (een Relying Party, RP, genoemd in OpenID Connect) doet een authenticatieverzoek bij de OpenID Provider (OP, de server). Ik zou je aanraden hiervoor een bestaande library te gebruiken. De OpenID Foundation heeft een aantal <a href="https://openid.net/certification/#RPs">libraries gecertificeerd</a>, wat betekent dat ze aan de specificaties voldoen voor een RP implementatie.</p>
<p>De OpenID Provider kan je vragen in te loggen, maar als er al een bestaande sessie is, mag die vaak hergebruikt worden. Hoe je inlogt verschilt per OP. Eventueel zal de OP jou toestemming vragen om bepaalde gegevens te delen met de RP of acties toe te staan. Dit soort schermen heb je waarschijnlijk wel gezien als je op een website inlogt met je Facebook of Google account. Na succesvolle authenticatie via de OpenID Provider ontvangt de Relying Party maximaal 3 tokens: een ID token, een access token en een refresh token.</p>
<h2>ID token</h2>
<p>De OpenID Provider kan een ID token teruggeven. Een ID token is een JWT met <a href="https://openid.net/specs/openid-connect-core-1_0.html#Claims">claims</a> voor onder andere de tijd en wijze van authenticatie, maar ook gegevens over de gebruiker zoals naam, e-mailadres, telefoonnummer, adres en geboortedatum. Als de OP een ID token met daarin bijvoorbeeld de naam van de gebruiker meestuurt, kun je die informatie direct gebruiken voor personalisatie van je website.</p>
<h2>Access token</h2>
<p>Het access token gebruik je om beveiligde gegevens op te halen of te wijzigen in je backend. Je stuurt het access token met elk request naar de backend mee. Vroeger was dit vaak een willekeurige string. De backend controleerde vervolgens bij de OpenID Provider of het access token geldig was, bij welke gebruiker dit hoorde en welke toestemmingen er waren gegeven. Tegenwoordig is een access token vaker een JWT, zodat deze controle niet meer strict noodzakelijk is. De geldigheid, gebruiker en toestemmingen (scopes) kunnen immers als claims in de JWT staan. De backend kan bij elk request de geldigheid controleren en heeft daardoor geen sessie meer nodig.</p>
<h2>Refresh token</h2>
<p>Access tokens zijn beperkt geldig, variërend van enkele minuten tot een dag of zelfs langer. De OpenID Provider bepaalt en stuurt deze mee in de response naar de Relying Party. Met het access token kan ook een refresh token meegestuurd worden. Als de Relying Party ziet dat het access token bijna verloopt, of als dit token geweigerd wordt door de backend, dan kan het met een refresh token bij de OP een nieuw access token ophalen. Dit refresh token moet daarom zo veilig mogelijk bewaard worden. De RP moet dit refresh token ook niet delen met de backend of andere sites. Er zijn nog geen echt veilige mogelijkheden om gegevens in de browser op te slaan. <a href="https://developer.mozilla.org/nl/docs/Web/API/Window/sessionStorage"><code>sessionStorage</code></a> is op dit moment acceptabel voor het opslaan van een refresh token, maar scripts die toegang hebben tot de DOM kunnen je <code>sessionStorage</code> uitlezen.</p>
<p>Bij Relying Parties die via de backend access tokens aanvragen, is de geldigheid van refresh tokens vaak onbeperkt of voor een langere periode. Voor client side applicaties, zoals bijvoorbeeld een React app, is het advies om een refresh token beperkt geldig te laten zijn tot maximaal een aantal uren gerekend vanaf de uitgifte van het eerste access token na inloggen. Gedurende die geldigheid kan de RP nieuwe access tokens aanvragen. Is ook de geldigheid van de refresh tokens verlopen, dan moet de gebruiker opnieuw inloggen.</p>
<h2>Verschuiving van verantwoordelijkheden</h2>
<p>Wordt het voor jou als frontender nou echt makkelijker om OpenID Connect en access tokens te gebruiken ipv klassieke sessies met een simpel inlogformulier? Waarschijnlijk niet, want nu is de frontend verantwoordelijk voor het zo veilig mogelijk opslaan van tokens en nieuwe tokens aan te vragen als de oude (bijna) verlopen zijn.</p>
<p>Bij volledig publieke websites heb je meestal geen tokens nodig, maar bij gepersonaliseerde websites kun je hier wel mee te maken krijgen. Een reden kan zijn dat het inloggen, het teruggeven van je bestelgeschiedenis en het beheren van je favorieten door drie verschillende webapplicaties wordt afgehandeld. Voor de gebruiker is dit echte één website waarvoor die verwacht met één keer inloggen bij al diens gegevens te kunnen.</p>
<p>In de backend wordt het wel eenvoudiger. Er is geen synchronisatie van sessies nodig, slechts één applicatie houdt zich bezig met het uitgeven van de tokens, terwijl de andere applicaties los van elkaar de access tokens kunnen consumeren voor het teruggeven of wijzigen van beveiligde gegevens.</p>
</content>
</entry>
<entry>
<title>Een betere sfeer begint bij jezelf (en eindigt bij je collega's)</title>
<link href="https://www.fronteers.nl/nl/blog/2020/12/een-betere-sfeer-begint-bij-jezelf-en-eindigt-bij-je-collegas"/>
<updated>2020-12-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/12/een-betere-sfeer-begint-bij-jezelf-en-eindigt-bij-je-collegas</id>
<content xml:lang="nl" type="html"><p>Laten we voor 2021 als goed voornemen noteren dat we het nieuwe jaar fijner met elkaar omgaan. Dat we wat meer naar elkaar omkijken, beter samenwerken in het signaleren van eenzaamheid en er voor waken een negatieve impact te hebben op het werkplezier van onze collega's.</p>
<p>Ik heb helaas meegemaakt hoe het is om in een toxische omgeving te werken. Ik had daarna een vol jaar nodig om terug mezelf te worden. Dat is ondertussen een aantal jaar geleden maar ik denk er nog vaak over na wat ik anders had kunnen doen om de sfeer te verbeteren (en niet wekelijks huilend thuis te komen). In dit blog wil ik graag jou ook aan het denken zetten over de sfeer op je werk, en de rol die je daarin speelt.</p>
<p>Eerst gaan we samen kijken wat de situatie bij jou op je werk is. Pak pen en papier, en turf hoe vaak je op een van onderstaande stellingen met 'ja' antwoordt! Er zitten positieve en negatieve stellingen bij, maar welke dat zijn is redelijk subjectief.</p>
<p><em>Als ik in een Slack kanaal om hulp vraag bij mijn lokale omgeving...</em></p>
<ul>
<li>krijg ik meestal geen reactie</li>
<li>is het wachten op de reactie &quot;RTFM&quot;</li>
<li>krijg ik een prive-berichtje van een collega met feedback over de vraag, maar geen antwoord</li>
<li>moet ik kiezen uit meerdere mensen die me wel willen helpen</li>
<li>kom ik altijd bij dezelfde persoon uit</li>
</ul>
<p><em>Tijdens een team-overleg...</em></p>
<ul>
<li>houd ik soms dingen voor mezelf omdat ik bang ben voor de mening van anderen</li>
<li>lopen de gemoederen soms hoog op en worden mensen boos of emotioneel</li>
<li>staat er altijd wel een kaartje in de positieve kolom over de sfeer in het team</li>
<li>merk ik dat sommige collega's vooral met andere dingen bezig zijn</li>
<li>wordt er vaak over dezelfde zaken geklaagd, maar blijven concrete oplossingen uit</li>
</ul>
<p><em>Er zijn collega's...</em></p>
<ul>
<li>die het echt niet begrijpen, dus ik steek daar geen tijd en energie in</li>
<li>die echt onwijs bot zijn en je soms behandelen alsof je dom bent</li>
<li>die eigenlijk altijd aan het woord zijn tijdens een meeting</li>
<li>die me een veilig gevoel geven</li>
<li>die zo'n impact op het team hebben, dat wanneer ze een week met vakantie zijn, iedereen leuker tegen elkaar is</li>
</ul>
<p><em>Mijn werkgever of manager...</em></p>
<ul>
<li>luistert naar feedback maar doet er vervolgens niets mee</li>
<li>geeft me in het openbaar kritiek maar complimenten 1 op 1</li>
<li>verwacht dat ik werk in mijn vrije tijd</li>
<li>heeft een 'old boys network' om zich heen van favoriete collega's, waar ik niet bij hoor</li>
<li>lijkt te denken dat mijn werk niets voorstelt</li>
</ul>
<p><em>Nadat ik de werkdag afsluit...</em></p>
<ul>
<li>voel ik me overprikkeld en druk</li>
<li>heb ik een gevoel van opluchting dat de dag er op zit</li>
<li>ga ik lekker ontspannen koken of sporten</li>
<li>heb ik de neiging om te klagen over mijn werk</li>
<li>voel ik me wel eens eenzaam</li>
</ul>
<p>Ja? Heb je het geturfd? Heb je vaker dan 10 keer 'ja'? Hoe voel je je daarbij?</p>
<p>Hoe goed de cultuur op je werk bij je past, verschilt per mens. Misschien hou je wel van een competitieve omgeving waar iedereen wat meer met zichzelf bezig is. En soms geven plagerijtjes jou juist het gevoel erbij te horen. Maar wat de één geen probleem vindt kan juist voor de ander meewerken aan het langzaam verpieteren van de goede sfeer tussen collega's, en daarmee een enorme impact hebben op hoe lekker jij in je vel zit.</p>
<p>Ik pluk nu drie stellingen uit het lijstje hierboven waarvan ik denk dat ze onderschat worden, terwijl ze wel een probleem (kunnen) vormen.</p>
<h2>Als ik in een Slack kanaal om hulp vraag bij mijn lokale omgeving krijg ik meestal geen reactie</h2>
<p>Mensen kijken bij jou op je werk eigenlijk nooit naar Slack. Of er is niemand die zich direct aangesproken voelt om te reageren op je vraag (laat staan met een botte reactie &quot;RTFM, read the fucking manual&quot;, welke op een heel ander niveau problematisch is). Maar wat doet dit met jou? Moedigt dit je aan om zelf op onderzoek uit te gaan? Voel je je genegeerd? Voel je je tot last van anderen?
Als je je genegeerd voelt kan dit een trigger zijn om het probleem te veel bij jezelf te leggen waardoor je onzekerder wordt en de drempel om om hulp te vragen hoger wordt. Dit werkt een sfeer met een incrowd (de mensen die elkaar wel helpen) en een 'ieder voor zich' mentaliteit uiteindelijk in de hand.</p>
<h2>Subtiele sfeerverkwanselaars</h2>
<p>Als je niet degene bent die dit vaak overkomt, kijk dan eens naar jouw aandeel in hoe je team met vragen omgaat. Negeer je mensen als ze een lastige vraag hebben? Hiermee geef je mensen het idee dat ze niet gezien worden? Plaats je alleen een (lollige) emoji als reactie? Dat is passief aggressief gedrag waarmee je eigenlijk iemand laat weten dat je ze gezien hebt, maar alsnog negeert. Of ben je diegene die met flauwe grappen reageert, maar nooit degene die een poging doet tot het verhelpen van het probleem? Wat je namelijk met dat laatste doet is de vraag niet alleen negeren, maar ook de aandacht van de vraag af halen.</p>
<h2>Tip voor sfeerverbeteraars</h2>
<p>Collega's die wat onzeker zijn aangelegd vinden het vaak moeilijk om een vraag te stellen in een openbaar kanaal. Dat ze het toch doen is dapper en zegt tegelijk dat ze zich op dit moment nog veilig voelen om zich kwetsbaar op te stellen (en dit is MEGA belangrijk voor een goede sfeer).
Het helpt daarom al als je interacteert met de vragensteller in het openbaar om te kijken tot welk punt je ze zou kunnen helpen, of om het probleem te verduidelijken. Heb je zelf op dat moment geen tijd om iemand te helpen, stuur dan een berichtje met de vraag of ze al geholpen zijn, en bied anders aan om op een ander moment mee te kijken. Kijk eventueel met je team of er een betere plek is om vragen te stellen zodat ze beter gezien worden. Of is er een manier om het helpen van collega's in te bouwen in je werkschema?</p>
<h2>Als ik in een Slack kanaal om hulp vraag is het wachten op de reactie &quot;RTFM&quot;</h2>
<p>Ik kan me voorstellen dat dit je ontmoedigt om vragen te stellen, want dit is een onwijs toxische reactie. Het gaat er namelijk van uit dat jij niet eerst zelf dingen hebt geprobeerd of hebt geprobeerd te googelen. Het gaat er ook van uit dat de documentatie alle verschillende mogelijke gevallen behandelt, en als zodanig jouw vraag tot een domme vraag maakt.</p>
<h2>Subtiele sfeerverkwanselaars</h2>
<p>Als je iemand bent die dit of iets dat hier in het verlengde van ligt graag tegen collega's zegt of typt, dan wil ik je vragen om nog eens goed te kijken naar jouw prioriteiten op je werk. Wat is het dat jouw tijd en werk belangrijker maakt dan die van je collega's? Naast dat je collega met deze variant van &quot;wat een domme vraag zeg&quot; niet geholpen is, zet je vooral een sfeer neer waarin mensen zien dat je subtiel belachelijk gemaakt wordt als je een vraag stelt. En geef je een voorbeeld aan de mensen die naar jou opkijken dat dit de manier is waarop je met elkaar omgaat.
(En oh, staat het werkelijk in de handleiding? Geef dan een link naar de juiste pagina. Ik moet overigens het eerste in-house documentatiesysteem nog tegenkomen dat compleet en up to date is en niet alleen de basis behandelt, maar ook goed helpt met troubleshooting!)</p>
<p>Het idee van &quot;domme vragen&quot; is er een die ten grondslag ligt aan een toxische werksfeer. De gedachte dat ergens iets meer over weten jou een speciaal aanzien geeft binnen het team is een valstrik voor onzekere mensen. Alleen meer weten dan anderen (en dat op die manier uitdragen) maakt namelijk niet dat mensen echt respect voor jou en je kennis zullen hebben, het maakt dat men weet dat ze vooral naar jou toe moeten komen als er iets te 'halen' valt, niet om iets te 'brengen' (positiviteit, gezelligheid).</p>
<h2>Tip voor sfeerverbeteraars</h2>
<p>Als jij gul bent met je kennis, in plaats van krampachtig en gierig, komen mensen bij je voor je gezelschap. En als je zelf af en toe laat weten aan collega's dat je iets niet weet en ergens hulp bij kunt gebruiken, draag je bij aan een veilige werksfeer, waar je als team voor elkaar klaar staat en samen problemen oplost.</p>
<p>Hoe je als team omgaat met de &quot;domste vragen&quot; van collega's laat zien hoe emotioneel intelligent als bedrijf bent. Het zorgt er ook voor dat er minder verloop is bij je bedrijf en dat je met elkaar de werkdruk verdeelt. Spreek elkaar hier op aan, link collega's dit blog en werk samen naar een positieve, leergierige cultuur!</p>
<h2>Tijdens een teamoverleg merk ik dat sommige collega's vooral met andere dingen bezig zijn</h2>
<p>We zitten allemaal wel eens in een meeting die niet vooruit te branden is. Waar iedereen nog helemaal in de sfeer van het vorige of volgende weekend zit, moe is, of waar je gewoon geen duidelijke bijdrage aan weet mee te geven. Een goede gespreksleider voelt dit aan en probeert hier iets aan te doen. Bijvoorbeeld door het gesprek efficienter te laten verlopen, de groep aanwezigen te beperken of gewoon de vergadering in te korten.Desondanks zijn sommige collega's wel erg snel geneigd om gewoon door te blijven werken terwijl anderen aan het woord zijn, of met hun telefoon te gaan spelen. Of de camera tijdens de online call uitgeschakeld te houden en niet duidelijk deel te nemen aan de meeting.</p>
<h2>Subtiele sfeerverkwanselaars</h2>
<p>Focus bewaren tijdens een meeting, zeker als die online is in verband met thuiswerken, is best lastig. Maar het is heel onfatsoenlijk als je (zichtbaar!) andere dingen zit te doen tijdens een bijeenkomst waar net iemand een verhaal zit te vertellen. Als het moeilijk is om je te concentreren, waar komt dat dan door? En wat kun je daar zelf aan verbeteren? Als dat wat je aan het doen bent belangrijker is dan de vergadering, is het beter om uit het overleg te stappen. Dit geldt natuurlijk niet voor iets als een scrum retrospective.
Het kan super fijn zijn om je camera uit te laten tijdens een online meeting, ik weet het. Maar je helpt er een ander niet mee als je ze dwingt om tegen een logo (of tijdens een meeting: een muur van logo's) aan te kijken. Als jij de eerste bent die de camera inschakelt, geef je het goede voorbeeld en laat je de spreker zien dat je naar ze luistert!</p>
<h2>Tip voor sfeerverbeteraars</h2>
<p>De verantwoordelijkheid voor het goed verlopen van een bijeenkomst ligt bij de scrummaster (of de teamleider), maar mogelijk is er wel ruimte voor jou om te kijken hoe je de meeting vlotter zou kunnen trekken. Is het nodig dat iedereen erbij is? Kun je vragen of iedereen de camera aan kan zetten? Is het het format van de meeting? Zou je een timer kunnen instellen voor de verschillende onderdelen? Helpt het om collega's even bij de les te houden door ze te betrekken in het gesprek? Als je scrum gebruikt, is dit misschien (heel meta) ook een goed onderwerp voor tijdens de volgende retrospective.</p>
<h2>De rode draad</h2>
<p>Misschien zijn deze punten heel voor de hand liggend, maar hopelijk is je een rode draad opgevallen: Als je je kwetsbaar durft op te stellen, en de mensen waarmee je werkt laat zien dat je ze ziet, kun je de sfeer op je werk positief beinvloeden. Ik denk eigenlijk dat de meeste toxische werkomgevingen zijn ontstaan uit het tegenovergestelde: het gevoel van ego, het idee dat empathie geen plek heeft in de techwereld, het idee dat je als manager, teamleider of senior ontwikkelaar alles hoort te weten en dat het je baan kost als je toegeeft dat je iets niet weet.</p>
<p>Mensen laten zien dat je ze 'ziet' kan op zoveel manieren. Vragen hoe het met iemand gaat waarvan je weet dat ze het nu moeilijk hebben met de Coronacrisis. Tijdens een vergadering iemand die minder vaak gehoord wordt naar hun mening vragen. Of in het openbaar noemen hoe goed die collega ergens in is. Iemand die je minder vaak spreekt kun je eens privé vragen of ze je kunnen helpen als '<a href="https://en.wikipedia.org/wiki/Rubber_duck_debugging">rubber eendje</a>'. Samen een taai probleem oppakken tijdens een peer programming sessie (en ja, dit kan ook online! Bijvoorbeeld met <a href="https://code.visualstudio.com/blogs/2017/11/15/live-share">Visual Studio Live Share</a>.).</p>
<p>Heb je collega's die zich zo gedragen zoals je herkent uit dit blog? Zijn er mensen die opmerkingen maken die best rot aankomen, en die niet snappen dat dat meewerkt aan een nare werksfeer? Geef het een paar dagen en check dan even bij die persoon waar dit vandaan komt. Maar vraag vooral het doelwit van de opmerkingen privé hoe de opmerking bij ze aankwam, en hoe je ze kunt ondersteunen als het weer voorkomt. Uiteraard geldt dit helemaal als je racisme of seksisme constateert, het lijkt me vrij logisch dat subtiele opmerkingen op dit vlak nog wel het dodelijkst zijn voor een veilig gevoel op het werk en <em>bad behaviour</em> op dit vlak mogen we nooit tolereren.</p>
<p>Werk je nou bij een bedrijf waar de sfeer al zo slecht is dat je super overprikkeld of vol negativiteit de dag afsluit? Jij hebt zelf invloed op de sfeer, maar die sfeer is niet afhankelijk van jou alleen! Zorg dat een vervelende tijd in een slecht team je niet breekt en verpest voor een positievere werkervaring. Want hoe cynischer je wordt, hoe moeilijker het wordt om plezier te hebben in je werk.</p>
<p>Kortom: laten we allemaal in 2021, in deze onzekere tijden, eerlijk kijken naar ons eigen gedrag, en onze bijdrage aan de onderlinge sfeer en het geluk van anderen. Want juist nu is het belangrijk dat we elkaar hier doorheen helpen, mentaal net zo goed als fysiek met mondkapjes en anderhalve meter afstand. Ik help jou er ook graag doorheen. Stuur me gerust een berichtje op <a href="https://twitter.com/anneke">twitter</a> of <a href="https://www.linkedin.com/in/annekesinnema/">linkedin</a> als je naar aanleiding van deze blog vragen hebt of iemand nodig hebt die je aanmoedigt om vooral elders werk te zoeken :-)</p>
</content>
</entry>
<entry>
<title>Introductie Web Components</title>
<link href="https://www.fronteers.nl/nl/blog/2020/12/introductie-web-components"/>
<updated>2020-12-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/12/introductie-web-components</id>
<content xml:lang="nl" type="html"><p>Web components is een W3C webstandaard waarmee je, eenvoudig gezegd, je eigen HTML-tags kunt maken.</p>
<p>Het toevoegen van een plattegrond op je webpagina kan dan zo eenvoudig zijn als het toevoegen van deze tag:</p>
<pre><code>&lt;g-map latitude=&quot;52.3812258&quot; longitude=&quot;4.9001255&quot;&gt;&lt;/g-map&gt;
</code></pre>
<p>Met web components kan je component-gebaseerd werken zonder dat je een JavaScript framework nodig zoals Angular, React of Vue. De tag moet wel beschikbaar gemaakt worden in de pagina met JavaScript. Hier komen we nog op terug.</p>
<p><a href="https://en.wikipedia.org/wiki/Web_Components#History">Volgens Wikipedia</a> werden web components geïntroduceerd door <a href="https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell">Alex Russell van Google tijdens de Fronteers Conferentie in 2011</a>.</p>
<p>De specificatie is na een aantal langdurige wijzigingen eindelijk gereed en wordt nu door alle <a href="https://caniuse.com/custom-elementsv1">moderne browsers</a> ondersteund.
Oudere browsers kunnen web components gebruiken in combinatie met polyfills.</p>
<p>Begonnen als zo'n polyfill is het door Google ontwikkelde <a href="https://www.polymer-project.org/">Polymer</a>. Hiermee konden web components al worden gebruikt terwijl browsers nog geen ondersteuning hadden.
Het is het enige bekende framework met web components als basis.</p>
<p>Sinds 2018 zijn van dit project nog twee delen over die ook nu handig zijn als je met web components aan de slag gaat:</p>
<ul>
<li><a href="https://lit-element.polymer-project.org/">LitElement</a>: een basisclass voor Web Components.</li>
<li><a href="https://lit-html.polymer-project.org/">lit-html</a>: een templating library gebaseerd op JavaScript template literals (dus gebruik makend van <code>${var}…</code>).</li>
</ul>
<h2>Technologieën</h2>
<p>Web Components is een verzamelnaam van drie webtechnologieën: Shadow DOM, Custom Elements en HTML Templates.</p>
<h2>Shadow DOM</h2>
<p>Met Shadow DOM is het mogelijk om binnen je eigen tag een hele HTML-structuur op te nemen inclusief CSS en JavaScript die is afgeschermd van de rest van de pagina, zodat conflicten met de rest van de pagina worden vermeden.</p>
<p>In de browser inspector is het mogelijk om in de Shadow DOM te kijken:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/shadow-root.png" alt="Een screenshot van Firefox Devtools, waarin de shadow DOM van een element wordt gemarkeerd met &quot;#shadow-root&quot;" /></p>
<h2>Custom Elements</h2>
<p>Een Custom Element is een JavaScript class waarmee je het gedrag van het element definieert.</p>
<h2>HTML Templates</h2>
<p>Alle HTML die tussen <code>&lt;template&gt;</code> en <code>&lt;/template&gt;</code> staat wordt door de browser niet geparsed, dus CSS, JavaScript en bijvoorbeeld afbeeldingen worden niet uitgevoerd en gedownload. Dit template kan je met JavaScript kopiëren en in je Custom Element gebruiken, waarna het wel wordt geparset. Meer over het template element vind je op
<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template"><template>: The Content Template element op MDN</template></a>.</p>
<h2>Code voorbeeld</h2>
<p>Hieronder staat de de code van een waarschuwings-component dat verder nog niet veel kan.</p>
<pre><code>// Definieer het MyWarning Custom Element
class MyWarning extends HTMLElement {
// De constructor wordt aangeroepen als van de class
// een instantie wordt gemaakt
constructor() {
super();
// Maak een shadow DOM en verbind die aan dit custom element
this.attachShadow({mode: 'open'});
// Vul de shadow DOM met HTML
this.shadowRoot.innerHTML = `
&lt;style&gt;
div {
padding: 20px;
border: 5px solid red;
}
&lt;/style&gt;
&lt;div&gt;
&lt;slot&gt;
&lt;/div&gt;
`;
}
}
// Definieer een my-warning tag en koppel deze aan het custom
// element MyWarning
customElements.define('my-warning', MyWarning);
</code></pre>
<p>Dit custom element zou je als volgt in HTML kunnen gebruiken:</p>
<pre><code>&lt;my-warning&gt;Dit is een waarschuwing&lt;/my-warning&gt;
</code></pre>
<p>In de browser ziet dit er zo uit:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/my-warning.png" alt="Een blok met een rode rand met daarin de tekst &quot;Dit is een waarschuwing&quot;" /></p>
<p>Je kan de code en het resultaat ook bekijken en aanpassen in deze <a href="https://codepen.io/edwinm/pen/QWKMaKy">Codepen</a>.</p>
<p>Wat misschien het eerste opvalt is het gebruik van het koppelteken in de HTML-tag. Dit is om onderscheid te maken tussen web components en &quot;native&quot; HTML-tags en is dus verplicht als het om web components gaat.</p>
<p>In het JavaScript zien we dat de Shadow DOM wordt gevuld met CSS en HTML-code. <code>&lt;slot&gt;</code> is de plaatshouder voor de inhoud van de <code>&lt;my-warning&gt;</code>-tag.</p>
<p>Door het gebruik van de Shadow DOM is de toegepaste CSS alleen geldig binnen deze Shadow DOM en nooit op de rest van de pagina.</p>
<ul>
<li>Dit custom element kan worden uitgebreid met verschillende &quot;levenscyclus functies&quot;, die worden aangeroepen als het bijvoorbeeld aan de pagina wordt toegevoegd wordt of juist wordt verwijderd.</li>
<li>Je kan de attributen uitlezen, reageren als de waarde van een attribuut verandert en je kan net als gewone HTML-elementen events afvuren.</li>
<li>Op <a href="https://developers.google.com/web/fundamentals/web-components/customelements">Web Fundamentals</a> wordt uitgebreid beschreven hoe je een custom element maakt.</li>
</ul>
<p>Miniplugje: een paar onderdelen van een Web Component zijn wat omslachtig en niet zo declaratief. Om dit te verbeteren heb ik de lichtgewicht <a href="https://github.com/edwinm/web-component-decorator">web-component-decorator</a> geschreven. Je hebt hiervoor wel TypeScript nodig.</p>
<h2>Customized built-in elements</h2>
<p>Met customized built-in elements kan je deze notatie gebruiken:</p>
<pre><code>&lt;button is=&quot;my-super-button&quot;&gt;Klik mij&lt;/button&gt;
</code></pre>
<p>Dit is een bestaand HTML-element die met het is-attribuut wordt uitgebreid naar een custom element. Een groot voordeel van deze notatie is dat je progressive enhancement kan toepassen: de button werkt in elke browser, ook als deze geen web components ondersteunt. Als JavaScript en web components wel beschikbaar zijn, dan krijgt de bezoeker een rijkere &quot;my-super-button&quot; custom element.</p>
<p>Als je op de <a href="https://caniuse.com/custom-elementsv1">caniuse pagina</a> kijkt, dan zal je zien dat Safari deze customized built-in elements niet ondersteunt. De toepassing hiervan wordt daardoor erg beperkt en dat is erg jammer.</p>
<h2>Bibliotheken</h2>
<h2>Webcomponents.org</h2>
<p>Het <a href="https://www.webcomponents.org/">webcomponents.org</a> project heeft als doel om een complete bibliotheek aan te bieden van Web Components. Iedereen kan web components toevoegen, vergelijkbaar met npmjs.com.</p>
<h2>Open Web Components</h2>
<p>Het <a href="https://open-wc.org/">Open Web Components</a> project is gebaseerd op LitElement en lit-html uit het Polymer-project, maar uitgebreid met verschillende tools om het ontwikkelen makkelijker te maken, zoals build- en test-scripts.</p>
<h2>Web Components in Angular, Vue en React</h2>
<p>Het idee van Web Components is niet nieuw. Diverse JavaScript-frameworks bieden ook componenten aan. Het voordeel van web components is dat ze native zijn en je niet aan een bepaald framework vast zit.</p>
<p>Bedrijven die jaren geleden hebben geïnvesteerd in AngularJS en zagen dat hun codebase van de een op de andere dag was verouderd bij de introductie van Angular 2, weten wat het nadeel is van framework-afhankelijkheid. Bijvoorbeeld ING werkt nu wereldwijd met web components. Ze hebben zelfs hun componentenbibliotheek <a href="https://lion-web-components.netlify.app/">Lion Web Components</a> voor iedereen beschikbaar gemaakt.</p>
<p>Het voordeel van web components is dat je daarin je componenten kunt schrijven en die vervolgens in elk ander framework kunt gebruiken. Of toch niet?</p>
<p>In Angular en Vue kan je prima web components gebruiken, precies zoals je gewend bent in dat framework. Je kunt Angular- en Vue-componenten ook goed omzetten in web components.</p>
<p>In <a href="https://custom-elements-everywhere.com/">Custom Elements Everywhere</a> staat een lijst van alle bekende frameworks en hoe goed ze met custom elements omgaan. Spoiler: React is de enige spelbreker.</p>
<p>In React moet je extra toeren uithalen om web components te kunnen gebruiken. Het toekennen van datastructuren aan een attribuut of het luisteren naar events werkt namelijk anders. Het werkt alleen als je eerst een referentie maakt naar het web component en vervolgens met die referentie het web component gebruikt. Handig is anders.</p>
<p>Binnen React kan je ook een component omzetten naar een web component, maar daar heb je wel externe wrappers voor nodig. Hopelijk gaat React snel beter om met web components.</p>
<h2>Conclusie</h2>
<p>Web components zijn heel krachtig en te gebruiken op zowel moderne als oudere browsers. Als je al een framework gebruikt, dan is het misschien niet zo nuttig. Maar wil je framework-onafhankelijk zijn of juist een lichtgewicht (JAMStack) website met snelle laadtijden bouwen, dan zijn web components een voor de hand liggende keus.</p>
</content>
</entry>
<entry>
<title>Bewustwording, de noodzaak van echte verhalen over ontoegankelijkheid</title>
<link href="https://www.fronteers.nl/nl/blog/2020/12/bewustwording-de-noodzaak-van-echte-verhalen-over-ontoegankelijkheid"/>
<updated>2020-12-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/12/bewustwording-de-noodzaak-van-echte-verhalen-over-ontoegankelijkheid</id>
<content xml:lang="nl" type="html"><p>In mijn vele gesprekken met mensen over toegankelijkheid komt vaak het woord &quot;bewustwording&quot; voorbij. De reden dat websites of diensten ontoegankelijk zijn is vaak geen onwil, maar eerder het feit dat men er gewoonweg niet bij stilstaat dat het voor een grote groep mensen ontoegankelijk is.</p>
<p>Ik merk zelf ook dat ik beter snap hoe ontoegankelijk een website kan zijn voor bijvoorbeeld iemand die blind is als ik het van hun zelf verneem. Zoals een keer bij een workshop, dat ik iemand die blind was door bol.com zag navigeren met een screenreader. Het was voor het eerst dat ik een real world case zag, met uitleg van de persoon zelf over hoe lastig het is om een bepaald produkt te vinden op de site. En hoe ze dan uiteindelijk via Google op een specifieke term zoeken, om op bol.com alsnog die ene product pagina te bereiken.</p>
<p>Dat was zo'n openbaring dat ik nu, jaren later, er nog over praat.</p>
<h2>Twee soorten toegankelijkheid talks</h2>
<p>Er zijn twee soorten talks over toegankelijkheid. Eén vertelt over hoe je een website toegankelijk kan maken. En de andere over hoe ontoegankelijk websites zijn voor mensen met een bepaalde beperking.</p>
<p>Er zijn mensen die goed kunnen uitleggen hoe je je website beter toegankelijk maakt, over de valkuilen en andere technische dingen zoals ARIA. Maar de ervaring zelf, de hindernissen, de frustraties; Dat kan niemand beter vertellen dan diegenen die het dagelijks meemaken.</p>
<p>Ik heb een talk gemaakt over Inclusive Design gebaseerd op mijn eigen persoonlijke verhaal en mijn ervaringen in combinatie met mijn kennis van front-end developing. Ik kwam op dit idee door gesprekken met developers, mensen met een beperking en product owners, én door zelf een keer aan een klas van studenten Communication &amp; Multimedia Design (CMD) te vertellen over de hindernissen die ik dagelijks tegenkom.</p>
<p>Het was natuurlijk niet makkelijk. Ik heb er hard over nagedacht of ik aan wildvreemden wilde vertellen over hoe ik disabled geworden ben, over die periode in mijn leven. Maar voor mij weegt zwaarder dat ik wil dat de wereld om mij heen toegankelijker wordt voor iedereen. En dat kan alleen door onze ervaringen en verhalen te delen.</p>
<p>Ondertussen heb ik mijn talk 4 keer mogen geven en heb ik goede feedback gekregen. Altijd over het feit dat men geen idee had over de dagelijkse hindernissen. Zoals een verplicht telefoonnummerveld in een formulier, maar géén tekstveld om door te kunnen geven dat ik doof ben en niet gebeld wil worden (en liever via SMS of e-mail benaderd wil worden).</p>
<p>Mijn verhaal maakt het 'echter' voor mensen, in plaats van alleen gebruik te maken van persona's bij het ontwerpen en coden van een website. Een persona is maar een snapshot van iemand met een beperking. Het maakt geen diepe indruk om zo de noodzaak van toegankelijkheid te benadrukken.</p>
<p>Als meer organisatoren van conferenties, bedrijven en hogescholen/universiteiten, ervaringsdeskundigen zouden uitnodigen om een talk te geven over toegankelijkheid aan de hand van hun eigen ervaringen en verhalen zou dat de bewustwording enorm bevorderen.</p>
<p>Met betere bewustwording worden mensen meer gemotiveerd om te zorgen dat websites voldoen aan toegankelijkheidseisen.</p>
</content>
</entry>
<entry>
<title>Dingen gedaan krijgen</title>
<link href="https://www.fronteers.nl/nl/blog/2020/12/dingen-gedaan-krijgen"/>
<updated>2020-12-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/12/dingen-gedaan-krijgen</id>
<content xml:lang="nl" type="html"><p>Hoe kan je nou zoveel mogelijk halen uit de schaarse tijd die je thuis hebt met alle afleidingen die daar bij komen?</p>
<p>Het is een gevleugelde zin geworden dit jaar: &quot;Het zijn rare tijden&quot;. Het gaat dan natuurlijk over de Corona-crisis. We hebben een aantal dingen, zowel zakelijk als privé anders moeten inrichten de afgelopen tijd. Thuis werken is één van die aanpassingen. Het werk moet gedaan worden, maar hoe doe je dat? Developers zijn zogenaamde kenniswerkers en het werk dat we doen kan heel complex zijn en de nodige concentratie vergen, thuis werken kan dan een uitdaging zijn. Vaak moet je een werkruimte (als die er al is natuurlijk) delen met je partner en vaak lopen er ook nog een paar kinderen rond die voor de nodige afleiding kunnen zorgen. Daarnaast hebben we nog meer afleiding dan normaal, we moeten immers ook bereikbaar zijn, dus de smartphone en de email zorgen, misschien wel meer dan normaal, voor afleiding.</p>
<p>Er zijn boeken vol geschreven over dit onderwerp en waarschijnlijk hebben we er allemaal wel een paar gelezen. Degene mij het meeste heeft gebracht is &quot;<a href="https://www.calnewport.com/books/deep-work/">Diep werk</a>&quot; van <a href="https://www.calnewport.com/">Cal Newport</a>.</p>
<h2>Diep Werk</h2>
<blockquote>
<p>Professionele activiteiten die het uiterste van je cognitieve vaardigheden vergen en die in een toestand van afleidingsloze concentratie worden uitgevoerd.</p>
</blockquote>
<p>De benaming &quot;Diep werk&quot; komt trouwens van de schrijver, Cal Newport, zelf. Het is geen term uit de medische wereld.</p>
<p>Diep werk is dus moeilijk denkwerk dat zonder afleiding wordt uitgevoerd. Dit kan bijvoorbeeld een complex code probleem zijn, een boek wat je altijd hebt willen schrijven of iets anders waarbij veel denkwerk of een diepe concentratie nodig is. Dit lukt niet als er kinderen in huis zijn die aandacht vragen en ook niet als je constant e-mails of appjes krijgt die beantwoord moeten worden. Het is dus belangrijk dat je in een toestand komt waarin je door niks wordt afgeleid en je je volledige aandacht kunt richten op die ene taak.</p>
<p>In de moderne tijd heb je twee dingen nodig om goed te kunnen functioneren:</p>
<ol>
<li>Het vermogen om snel moeilijke dingen ter leren</li>
<li>Het vermogen om zowel kwalitatief als in snelheid op hoog niveau te werken</li>
</ol>
<p>Des te beter je je kunt concentreren op 1 taak (diep werk) des te makkelijker zullen beide punten je afgaan. Het is bewezen dat mensen slecht meerdere dingen tegelijk kunnen doen, de meeste mensen zijn niet goed in multitasking.</p>
<p>Uit onderzoek is gebleken dat bij de overgang van taak A naar taak B je aandacht niet direct meeverhuisd. Je aandacht blijf eigenlijk voor een deel nog een tijdje hangen aan taak A. Hoe sterker de rest-aandacht aan A is hoe slechter je taak B uitvoert. Dus is het belangrijk om je volledig te focussen op 1 taak zonder tussendoor te switchen naar een andere. De vijand van diep werk is oppervlakkig werk, dat zijn werkzaamheden als het lezen van email, appjes beantwoorden, even op Facebook kijken enzovoort. Zo gauw je aandacht wordt getrokken door oppervlakkig werk ben je los van je diepe werk en zal het langer duren voor die belangrijke taak af is. En misschien had het resultaat ook wel beter kunnen zijn, als je niet was afgeleid. Die ene taak is belangrijk en heeft voorrang op alles. De oppervlakkige taken zijn veel minder belangrijk en kunnen wel wachten tot later.</p>
<h2>Hoe dan?</h2>
<p>Hoe zorg je er nu voor dat je in een staat en in een omgeving bent waarin diep werken mogelijk wordt? Dit kan op vele manieren en is voor iedereen anders. De ene persoon sluit zich weken op in een klooster, de ander staat om 5 uur op en werkt tot 8 uur diep om daarna een normale werkdag vol afleiding te volgen.</p>
<p>Als je meer over dit onderwerp wilt weten raad ik je aan om het boek van Cal Newport te lezen. Ik heb voor mezelf een paar dingen waar ik me op een werkdag aan probeer te houden, om zo geconcentreerd mogelijk te kunnen werken.</p>
<ol>
<li><em>Plan je dag.</em> Begin elke ochtend met het plannen van je dag. In de ochtend ben je meestal op je best, helder en fit. Naarmate de dag vordert neemt het vermogen om moeilijke dingen te doen af. De meeste mensen kunnen maar een paar uur per dag diep werken. Dus plan de belangrijkste of moeilijkste dingen in de ochtend. En de rest in de middag. Ben je niet fit of te moe? Probeer dan wel iets te doen maar doe iets makkelijks, bijvoorbeeld de boekhouding.</li>
<li><em>Doe 1 taak tegelijk.</em> Dus hou je aan je planning. Je kunt dit doen door grote taken op te delen in kleinere en je dagen op te delen in blokken (blokken van een halfuur of van een uur). Probeer de taak waaraan je werkt af te maken. Lukt dat niet in de tijd die je van te voren bedacht hebt, dan kan het zijn dat je te weinig tijd hebt ingepland of dat de deeltaken nog steeds te groot zijn. Je wordt hier beter in door het vaak te doen.</li>
<li><em>Prioriteren.</em> Ik weet niet of dit voor iedereen geldt, maar ik wil altijd te veel doen. Ik heb te veel ideeën en zou op 1 dag duizend dingen willen doen. Dit gaat natuurlijk niet, dus probeer voor jezelf op een rijtje te krijgen wat voor jou de belangrijkste dingen zijn die af moeten. Je kunt bijvoorbeeld een lijstje maken met hoofd- en bijzaken en daar eventueel deadlines aanhangen. Het lijstje met bijzaken zijn dingen die niet zo heel belangrijk zijn en die dus ook geen haast hebben. Die doe je als je tijd over hebt. De hoofdzaken moeten wel snel af en zijn belangrijk. Ook in deze lijst zou je een een volgorde aan kunnen brengen, dus het belangrijkste bovenaan en het minst belangrijke onderaan.</li>
<li><em>Zorg voor een goede werkplek.</em> Het beste is een plek waar je alleen kunt zitten. De ruimte moet zo min mogelijk afleiden. Laat je gezin weten dat je daar zit en dat je niet gestoord wilt worden als de deur dicht zit. Je kunt ook tijden afspreken, zodat iedereen weet dat je op die momenten niet gestoord kunt worden. Heb je zo'n plek niet dan kun je ook kijken of werken met een koptelefoon iets voor je is. Ik gebruik zelf de app <a href="http://brain.fm/">brain.fm</a> deze heeft speciale muziek waarmee je diep kunt werken. Ook op Spotify zijn er diverse afspeellijsten te vinden die voor een juiste concentratie kunnen zorgen, zoals <a href="https://open.spotify.com/playlist/37i9dQZF1DWXLeA8Omikj7">Brainfood</a> en <a href="https://open.spotify.com/playlist/37i9dQZF1DWZeKCadgRdKQ">Deep Focus</a></li>
<li><em>Geen sociale media of email.</em> Check tijdens het diep werken geen email, lees geen appjes, ga niet online (behalve als je iets op moet zoeken) en beantwoordt geen telefoontjes. Met andere woorden: richt je op de geplande taak en laat je door niks afleiden. Mijn telefoon staat op stil als ik aan het werk ben. Plan ook blokken in, bij voorkeur in de middag, voor dit soort dingen en probeer je daar aan te houden. Je moet natuurlijk wel communiceren met je collega's. Je zou kunnen kijken of ook dat in te plannen is. Dus aan het einde van de ochtend een uurtje of aan het eind van de dag. Dit kan je dan zowel met bellen als met sociale media doen. Waarschijnlijk vinden je collega's dit ook wel een goed idee, aangezien het hen ook meer rust en structuur kan geven.</li>
</ol>
<p>Het is moeilijk om werk te doen tussen de vele afleidingen die er zijn een dag. Maar diep werken zonder afleidingen is te leren. Probeer voor jezelf een manier van werken te creëren die voor jou werkt en probeer je er aan te houden. Uiteindelijk wordt het makkelijker, al doende leert men.</p>
</content>
</entry>
<entry>
<title>Anke en de eerste stapjes in het land van Drupal Theming</title>
<link href="https://www.fronteers.nl/nl/blog/2020/12/anke-en-de-eerste-stapjes-in-het-land-van-drupal-theming"/>
<updated>2020-12-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/12/anke-en-de-eerste-stapjes-in-het-land-van-drupal-theming</id>
<content xml:lang="nl" type="html"><p>Halverwege 2020 switchte ik van baan, en begon ik als front-ender bij een webbureau dat voornamelijk met het CMS Drupal werkt. Ik heb nooit veel met Drupal gewerkt, maar front-end is front-end, toch?</p>
<p>Wrong!</p>
<p><a href="https://benchmarks.it.unt.edu/sites/default/files/drupal-humor1_0.gif">Deze cartoon</a> over de Drupal learning curve had me al genoeg moeten waarschuwen. :) Drupal is groot, massief, en kan ontzettend veel. Maar alles zit er dus ook in, op een grote en massieve manier. Niks lean en snel. Maar als je het Drupal-beest eenmaal een beetje doorhebt, valt het best te temmen. In dit artikel deel ik een aantal dingen die ik de afgelopen maanden heb geleerd.</p>
<h2>Drupal dicteert je templates.</h2>
<p><em>Om te beginnen een disclaimer: Dit gaat over Drupal 8. Eerdere versies van Drupal werkten wat anders met de templates.</em></p>
<p>De basis van Drupal is als elk ander CMS: de redactie managed de content in het CMS, en aan de voorkant komt er een mooie site uitrollen. Maar bij Drupal wordt ook de functionaliteit grotendeels binnen het CMS opgezet, deels ondersteund door modules. De templates voor de voorkant staan daar weer als losse laag op.</p>
<p>Bij ons op het werk bestaat een team uit een ontwerper, een front-ender en een back-ender. De back-ender bouwt de functionaliteit, en ik zet daar de voorkant tegenaan. Deze functionaliteit kan bijvoorbeeld één, of een combinatie van de volgende dingen zijn:</p>
<ul>
<li>Node (Een 'entity')</li>
<li>User (Ook een 'entity')</li>
<li>Taxonomy (Een hierarchische onderverdeling van elementen)</li>
<li>Block (Losse elementen. Dit kan ook een onderdeel van bovenstaande elementen zijn)</li>
<li>View (Een bepaalde weergave van één van bovenstaande elementen)</li>
<li>Paragraph (De redactie kan content stapelen in verschillende paragraphs. Dit komt uit de paragraph module, maar wordt heel veel gebruikt.)</li>
</ul>
<p>Deze lijst is niet compleet, maar geeft wel een goed beeld van de mogelijkheden. Als je bijvoorbeeld gebruik maakt van custom modules, horen daar weer eigen elementen bij.</p>
<p>Alles in deze lijst heeft zijn eigen template. De pagina die je uiteindelijk ziet, is dus een combinatie van heel veel geneste templates, die door Drupal op volgorde gezet worden.</p>
<p>In tegenstelling tot andere CMS'sen waarmee ik gewerkt heb, begin je dus <em>niet</em> met het bouwen van een template waar je later functionaliteit in zet, maar beter werk je andersom. Drupal zet de templates voor je neer.</p>
<h2>Welke template gebruiken?</h2>
<p>Je start met uitzoeken welke van de templates op de pagina je moet hebben. Hoe je daar achter komt? Kijk in je broncode!</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/2020/twig-debug.png" alt="Een screenshot van de Drupal template suggesties. Een lijstje templates in de inspector, waarvan eentje als actief is aangeduid met een kruisje." /></p>
<p><em>De Drupal template suggesties in je inspector. De onderste is het minst specifiek, de bovenste het meest. Het kruisje geeft de gebruikte template aan.</em></p>
<p>De <a href="https://www.drupal.org/docs/theming-drupal/twig-in-drupal/debugging-twig-templates">Twig debugging</a> optie binnen Drupal geeft voor elke template een aantal templatenamen, van breed <code>( node.html.twig)</code> naar heel specifiek <code>(node--agenda-detail--full.html.twig)</code>. Maak de template aan die je nodig hebt, kopieer de twig uit de standaard gebruikte core-template, en ga hierin aan de slag met je eigen HTML!</p>
<h2>Template voorbeeld</h2>
<p>Een voorbeeld van de vereenvoudigde template <code>node--agenda-detail--full.html.twig</code> voor een fictieve agenda pagina:</p>
<pre><code>
{# We zetten een aantal praktische basisclasses #}
{\% set classes = [
'node',
'node--type-' ~ node.bundle|clean_class,
'agenda-detail',
node.isPromoted() ? 'node--promoted',
node.isSticky() ? 'node--sticky',
not node.isPublished() ? 'node--unpublished',
view_mode ? 'node--view-mode-' ~ view_mode|clean_class,
] %}
&lt;article{{ attributes.addClass(classes) }}&gt;
{# De titel #}
&lt;h1 class=&quot;agenda-detail__page-title&quot;&gt;{{ node.title() }}&lt;/h1&gt;
{# De organisator + een labeltje dat we vertalen met de 't' functie #}
&lt;p class=&quot;agenda-detail__organizer&quot;&gt;
{{ 'Organized by:'|t }} {{ content.field_organizer.0 }}
&lt;/p&gt;
{# De output van de optionele introductie #}
{%- if content.field_intro.0 -%}
&lt;div class=&quot;agenda-detail__intro&quot;&gt;
{{ content.field_intro.0 }}
&lt;/div&gt;
{%- endif -%}
{# De output van de (agenda)data #}
{{ content.field_agenda_data }}
{# De output van de content, in dit geval in de module 'paragraphs' #}
{{ content.field_paragraphs }}
{# De output van een contactveld #}
{{ content.field_contact }}
{# Een knop om je in te schrijven, mits je ingelogd bent #}
{%- if logged_in == false -%}
&lt;a href=&quot;/login?destination={{ url }}&quot;&gt;
{{ 'Log in to sign up'|t }}
&lt;/a&gt;
{%- else -%}
&lt;a target=&quot;{{ button.target }}&quot; class=&quot;button&quot; href=&quot;{{ button.url }}&quot;&gt;
{{ button.text|t }}
&lt;/a&gt;
{%- endif -%}
&lt;/article&gt;
</code></pre>
<p>In bovenstaande template heb je alle ruimte om je eigen CSS en HTML toe te voegen.</p>
<h2>Geen logica in templates</h2>
<p>Bijna alle logica gebeurt in Drupal. Hoewel de Twig prima logica kan afhandelen, worden de templates in Drupal puur voor output gebruikt. Je gebruikt hoogstens een eenvoudig <em>if-statement</em> voor een check.</p>
<p>Logica aanpassen doe je binnen het CMS, of liever nog: binnen een custom module. Bij ons wordt dit laatste gedaan door de back-ender. Custom modules zijn eenvoudiger te lezen dan wanneer de logica bijvoorbeeld in Drupal zelf zou zitten (en daarmee in de database). Dit kan een groot voordeel zijn voor support achteraf. Bijvoorbeeld: Een kleurselector toevoegen aan een taxonomieterm kan prima in het CMS zelf, maar wil je die kleur vervolgens gebruiken in alle artikelen die die term hebben, dan is het verstandiger om die logica in een custom module te zetten. In de templates heb je dan een simpele variable en geen logica in de database. Op basis van die module maak je dan de html voor de toonbare site in je templates.</p>
<p>Het klinkt ontzettend rigide, en dat is het ook. Maar het heeft ook een groot voordeel: Het is namelijk superconsequent.</p>
<h2>Superconsequent en modulair</h2>
<p>Omdat het zo consequent is in de templates, zijn herhalende onderdelen ook heel snel op andere plekken in te zetten. Alles wat je al eens gebouwd hebt, kan overal gebruikt worden. En ziet er ook hetzelfde uit. <em>Als</em> je tenminste je CSS ook goed modulair gehouden hebt.</p>
<p>Elk onderdeeltje in Drupal heeft een eigen onderscheidende class, naast de algemene classes. Een paragraaf heeft bijvoorbeeld:</p>
<pre><code>paragraph paragraph--text paragraph--text-button paragraph--type--paragraph-text-button paragraph--view-mode--default
</code></pre>
<p>...</p>
<p>I know, I know.</p>
<p>Sommige classes komen uit Drupal zelf, sommige heb ik gezet. Maar ook dit <em>hoeft</em> niet en alles kan je overschrijven in de template. Maar het is wél bruikbaar! Doordat het zo modulair is opgezet, dwingt het je je CSS ook modulair op te zetten. Maak bijvoorbeeld een <code>paragraphs/paragraph--text-button.scss</code> en importeer die in je stylesheet. Dit herhaal je voor de andere onderdelen en je hebt een supernette directory met allemaal losse stylesheetjes per onderdeel. Mijn directories met SCSS zijn bijvoorbeeld 'base, layout, paragraphs, nodes'. Overzichtelijk, en fijn voor je collega's en future-me.</p>
<p>Zoals je net vast al gespot hebt, wordt er gebruik gemaakt van de BEM methode voor naamgeving (Block Element Modifier). BEM is ook modulair en ook consequent, en leent zich goed voor styling in Drupal. (<a href="http://getbem.com/">Meer over BEM</a>.)</p>
<p>Drupal splitst alles graag op in aparte stylesheets en scripts. Als je in je ontwikkelsite naar de broncode kijkt zie je daar ook een ontzettende lijst aan css en js staan, afkomstig van modules en onderdelen. Voor de productiesite kan je dit samenvoegen en cachen. Maar niet alleen voor je productiesite wordt gecached, wat ons brengt bij het volgende punt:</p>
<h2>Let op de caching</h2>
<p>De kans dat je minutenlang aan het refreshen bent en er dan achter komt dat je naar een gecachte pagina zit te kijken is bij Drupal groot. Drupal cached alles heel hard. Standaard wordt ook voor niet ingelogde bezoekers alles gecached. De JS, de CSS en ook je templates.</p>
<p>Let dus goed op dat je wel ingelogd bent bij het developen. Daarnaast zijn er soms verschillende views voor niet-ingelogde en wel-ingelogde bezoekers, zoals bijvoorbeeld het inlogscherm voor een 'mijn' omgeving. Dan is het dus weer handig om tussendoor in- en uit te loggen of in ieder geval een <em>incognitoscherm</em> ernaast te houden. Het clearen van de cache doe je in dat geval tussendoor via Drupal in je andere tab, of je gebruikt daarvoor <em>Drush</em> op de commandline.</p>
<h2>Werken met git? Drush is je vriend!</h2>
<p>Zoals met bijna alles dat je tegenwoordig ontwikkelt, kan je bij Drupal ook goed werken met versiebeheer, zoals bijvoorbeeld git.</p>
<p><a href="https://www.drush.org/"><em>Drush</em></a> is de commandline shell voor Drupal, en is onontbeerlijk als je met collega's aan hetzelfde project werkt. Zo wil je om de cache te clearen regelmatig even een <code>drush cr</code> (cache:rebuild) uitvoeren om zeker te zijn dat alles goed staat na een pull.</p>
<p>Een ander voorbeeld: Drupal slaat configuratie op in de database. Dat komt dus niet in git. Als je een lokale database hebt draaien, maar je collega heeft nieuwe functionaliteit toegevoegd, kan je dat met drush in jouw database importeren. Je collega exporteert de configs met <code>drush cex</code> (config:export), deze maakt nette .yml files die je in git kan zetten. Jij importeert met <code>drush cim</code> (config:import) deze configs uit deze .yml files in jouw database en je kan aan het werk.</p>
<p>Een paar andere handige drush commands:</p>
<ul>
<li><code>drush status</code> ( geeft de status van de site, welke db gebruikt wordt en meer)</li>
<li><code>drush updatedb</code> (update je database na een drupal update)</li>
<li><code>drush locale:check</code> / <code>locale:update</code> (check voor nieuwe vertalingen / importeer deze vertalingen)</li>
</ul>
<h2>Twig als templatetaal</h2>
<p>Ik noemde het net al. Drupal gebruikt vanaf versie 8 standaard de templatetaal <a href="https://twig.symfony.com/">Twig</a>! Twig is cool! Twig is leesbaar! Twig is mijn lievelingstemplatetaal, vanwege de leesbaarheid en alle mogelijkheden.</p>
<pre><code> {\% if node.keyvisual.0 is empty %} Doe iets {\% endif %}
</code></pre>
<p>Hoe leesbaar wil je het hebben? Twig zorgt voor prettige overzichtelijke templates. Als je het nodig zou hebben zou je ook eenvoudige logica in Twig kunnen uitvoeren, maar zoals ik net al uitlegde, wordt de meeste logica binnen Drupal afgehandeld.</p>
<p>Als je meer wil lezen: Twig heeft <a href="https://twig.symfony.com/doc/2.x/">superfijne documentatie</a> én een leuk plantje als mascotte. Just saying.</p>
<h2>Het CMS en de leercurve</h2>
<p>Bovenstaande lijst is bij lange na niet volledig, en is slechts een snelle conclusie na een paar maanden werken met Drupal. Ik hoop dat het wel een goed beeld geeft van hoe anders het werken is met Drupal dan met andere CMS'en.</p>
<p>Het is een flinke leercurve, maar ik merk dat ik door de consequentheid van het CMS zelf ook gedwongen wordt om mijn code strakker en beter op te zetten, en dat het me een betere front-ender heeft gemaakt. Een aanrader om eens mee te werken!</p>
</content>
</entry>
<entry>
<title>Semantiek, wat betekent het?</title>
<link href="https://www.fronteers.nl/nl/blog/2020/12/semantiek-wat-betekent-het"/>
<updated>2020-12-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/12/semantiek-wat-betekent-het</id>
<content xml:lang="nl" type="html"><p>Als men het heeft over de kwaliteit van HTML-code gaat het vaak over semantiek. Maar wat is nou semantiek? Wat is semantische HTML, en waarom zou je je er wat van aantrekken?</p>
<h2>Wat is semantische HTML?</h2>
<p>Semantiek is het communiceren van je intentie door middel van je gekozen HTML. Dit garandeert niet de correcte uitkomst, maar als je een andere intentie communiceert dan de uitkomst, dan klopt het sowieso niet.</p>
<p>Een bekende HTML-tag is bijvoorbeeld de <code>&lt;h1&gt;</code>. Deze tag wordt vaak gebruikt voor de belangrijkste kop (heading 1) op een pagina.</p>
<pre><code>&lt;h1&gt;Semantiek, wat betekent het?&lt;/h1&gt;
</code></pre>
<p>De tag of het element communiceert de intentie: dit is de belangrijkste kop, dit is waar de pagina over gaat. Als er (bijvoorbeeld door een fout in het CMS) een heel artikel in een <code>&lt;h1&gt;</code> staat dan komt het resultaat niet overeen met de intentie.</p>
<p>Op dezelfde manier kun je een link (<code>&lt;a&gt;</code>) maken die nergens heen gaat, of een knop (<code>&lt;button&gt;</code>) die niks doet. Met semantische HTML geef je je intentie aan. Dat is de eerste stap. Om het resultaat er op aan te laten sluiten is een volgende stap.</p>
<p>Je kan het vergelijken met TypeScript of andere talen die typing bevatten. Deze kunnen niet alleen data bevatten, maar ook iets zeggen over de data die ze bevatten.</p>
<h2>Wat doet semantiek?</h2>
<p>Zoals aangegeven geeft semantiek de intentie weer van een element. Als tools op deze intentie kunnen vertrouwen (de semantiek zegt iets over de data in de elementen) dan kunnen ze de inhoud van de elementen voor allerlei doeleinden gebruiken.</p>
<p>Enkele voorbeelden:</p>
<ul>
<li><em>Readability tools -</em> Er zijn tegenwoordig talloze manieren om teksten in een leesbaarder formaat door te nemen. Soms staan ze op zichzelf zoals Pocket en Instapaper, maar in Firefox en Safari zitten ze ook ingebouwd. Je kan een bestaande webpagina op een andere (leesbaardere) manier presenteren.</li>
<li><em>Vertalings tools -</em> Tools als Google Translate kunnen gebruiken maken van de context die je als developer communiceert.</li>
<li><em>Assistive technology -</em> Software zoals screen readers (“voorleessoftware”) informeren hun gebruikers over de semantische waarde van de HTML die ze lezen. Zo kan een gebruiker begrijpen of iets hoofd- of bijzaak is, en of iets een paragraaf of een lijst is.</li>
<li><em>Mensen die je code lezen -</em> Het klinkt misschien voor de hand liggend, maar leesbare code is prettige code om mee te werken. HTML code schrijf je vaak ook niet alleen voor jezelf maar voor anderen, of zelfs voor jezelf op een ander moment. Helder geschreven HTML is beter leesbaar en tijdsbestendiger.</li>
<li><em>Custom CSS, adblocking, etc -</em> Eigenlijk alles wat in je code &quot;hookt&quot; heeft baat bij leesbare, bestendige en robuuste code. Als een bezoeker Custom CSS heeft voor leesbare headings, dan moeten er wel headings zijn.</li>
<li><em>SEO -</em> Zoekmachines zijn soms net gebruikers. Ook zij willen weten wat voor informatie je aanlevert en wat de context van die informatie is.</li>
</ul>
<p>Door structuur in je code te creëren eindig je niet met &quot;los zand&quot;. Het geeft houvast aan iedereen die er mee moet werken: developers, bezoekers en tools.</p>
<h2>Hoe doe ik het goed?</h2>
<p>Betekent dit dat je <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element">alle HTML-elementen</a> uit je hoofd moet kennen? Nee, dat niet. Al zijn het er niet eens zo veel.</p>
<p>Het is wel leuk om te kijken welke elementen je allemaal kent! Heb je de <a href="https://codepen.io/plfstr/full/zYqQeRw">HTML Tags Memory Test</a> al geprobeerd?</p>
<h2>Wat wil ik communiceren?</h2>
<p>Deze vraag is heel waardevol in heel veel situaties. Als je HTML schrijft en je voegt een element toe, bedenk dat of dit element je intentie goed weergeeft. Schrijf je een paragraaf? Dan voelt het logisch om een <code>&lt;p&gt;</code> te gebruiken. Doe je iets voor puur visuele redenen, zonder dat je een specifieke intentie wilt communiceren? Dan kun je misschien prima uit de voeten met een <code>&lt;div&gt;</code> of een <code>&lt;span&gt;</code> (deze elementen voegen niks toe in de communicatie).</p>
<p>Gebruik je daarentegen een <code>&lt;div&gt;</code> of een <code>&lt;span&gt;</code> terwijl je juist wel een specifieke intentie wil overbrengen? Misschien wil je dan even in de lijst van <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element">alle HTML-elementen</a> kijken of er een passend alternatief is.</p>
<h2>Is mijn pagina structuur helder?</h2>
<p>Elke pagina heeft baat bij een goede structuur. Zoals een krant leunt op secties, katernen en heldere koppen, zo werkt het ook bij een pagina op het web (en de onderliggende HTML).</p>
<p>Kijk of je je pagina in kan delen met duidelijke HTML landmarks zoals <code>&lt;header&gt;</code>, <code>&lt;main&gt;</code>, <code>&lt;aside&gt;</code> en <code>&lt;footer&gt;</code>. Een landmark werkt net als een herkenningspunt in het echte leven. Als een dorp vijf kerktorens heeft dan wordt het lastig om te zeggen &quot;bij de kerktoren rechts&quot;.</p>
<p>Daarnaast kun je (ook net als bij een krant) headings gebruiken. De <code>&lt;h1&gt;</code> is de hoofdkop van de pagina; deze geeft aan waar de hele pagina over gaat. Technisch gezien valt alle content hieronder. Als je onder de <code>&lt;h1&gt;</code> een kopje wil gebruiken, gebruik dan de <code>&lt;h2&gt;</code>. Alles wat in de code onder de <code>&lt;h2&gt;</code> valt, moet hier logischerwijs in de content ook onder vallen. Je creëert een hiërarchie met je koppen. Sla geen koppen over (ga niet van <code>&lt;h2&gt;</code> naar <code>&lt;h4&gt;</code>) en plaats alleen iets onder een kop als het er logischerwijs onder valt.</p>
<h2>Is dat het?</h2>
<p>Ja, zo'n beetje wel eigenlijk. Communiceer zo duidelijk mogelijk wat de intentie van je code is (meta data) en laat je intentie geen lege belofte zijn.</p>
</content>
</entry>
<entry>
<title>Meld je aan voor de ALV 2020</title>
<link href="https://www.fronteers.nl/nl/blog/2020/09/meld-je-aan-voor-de-alv-2020"/>
<updated>2020-09-21T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/09/meld-je-aan-voor-de-alv-2020</id>
<content xml:lang="nl" type="html"><p>Op woensdagavond 14 oktober vanaf 20:00 houden we onze jaarlijkse algemene ledenvergadering (ALV)! Alle leden zijn hiervoor van harte uitgenodigd. De vergadering vindt dit keer vanwege het Coronavirus online plaats, via Jitsi Meet. Vooraf software installeren op je computer is niet nodig, mocht je willen inbellen vanaf je telefoon, dan zijn er apps beschikbaar voor <a href="https://jitsi.org/downloads/">Android, iOS en F-Droid</a>!</p>
<p><a href="https://www.fronteers.nl/nl/blog/2020/09/meld-je-aan-voor-de-alv-2020#english-version">English version</a> below.</p>
<p>Is het je eerste keer op de (of überhaupt een) ALV? Tijdens de ALV nemen we als bestuur, vrijwilligers en leden samen de (financiële) staat van Fronteers door, en evalueren we hoe het gaat met de vereniging. Tot het begin van de vergadering kan elk lid een voorstel doen voor een agendapunt of een ter stemming te brengen onderwerp.</p>
<p>Het staat leden tot het begin van de ALV vrij voorstellen voor de agenda in te dienen. De voorlopige agenda staat hieronder. Wat in ieder geval zal worden behandeld zijn de jaarstukken van de vereniging over 2019, de financiën over 2020 en de nieuwe begroting voor 2021. Deze stukken zullen enkele dagen voor de ALV naar alle aangemelde aanwezigen worden opgestuurd. Mocht je niet aanwezig kunnen zijn, maar deze informatie wel willen inzien: laat het ons weten!<br />
Notulen van de avond worden altijd zo snel mogelijk na de vergadering online gedeeld.</p>
<h2>Voorlopige agenda</h2>
<ul>
<li>Opening</li>
<li>Jaarrekening 2019</li>
<li>Bevindingen kascommissie</li>
<li>Benoeming nieuwe kascommissie</li>
<li>Financiën 2020</li>
<li>Begroting 2021</li>
<li>Herbenoeming Anneke Sinnema</li>
<li>Herbenoeming Edwin Martin</li>
<li>Toelichting commissies</li>
<li>Evaluatie W3C-lidmaatschap</li>
<li>Rondvraag</li>
<li>Sluiting</li>
</ul>
<h2>Aanmelden</h2>
<h2>English version</h2>
<p><strong>Wednesday evening, the 14th of October starting at 20:00 we will have our annual membership meeting (ALV)! All members of Fronteers are welcome to sign up to join us. Due to the Coronavirus, the meeting will take place completely online through Jitsi Meet. You don't need to install software or register to use this service, but if you want to participate on your phone there is an app available on <a href="https://jitsi.org/downloads/">Android, iOS and F-Droid</a></strong></p>
<p>Is this your first time at the (or an) ALV (membership meeting)? The legal form of Fronteers is a dutch 'vereniging', which means we are obligated to have a meeting once a year with the board, volunteers and members to present and discuss the (financial) state of Fronteers. We will evaluate how Fronteers is doing and discuss what we can do to improve. Until the actual start of the meeting, any member can propose a topic for the agenda to be discussed and voted on by all present members.</p>
<p>Below, you'll find the provisional program of the evening. The financial documents of 2019, 2020 and 2021 will be discussed and sent in advance to everyone that signed up for the ALV. If you can't attend but (as a member) want to get a copy of the documents, please <a href="mailto:penningmeester@fronteers.nl">send an e-mail to our treasurer</a>.</p>
<h2>(Provisional) Agenda</h2>
<ul>
<li>Opening</li>
<li>Financial Statements 2019</li>
<li>Findings of the treasury committee</li>
<li>Naming of the new treasury committee</li>
<li>Finances of 2020</li>
<li>Budget for 2021</li>
<li>Reappointment Anneke Sinnema</li>
<li>Reappointment Edwin Martin</li>
<li>Report of committees</li>
<li>Evaluation W3C membership</li>
<li>Round of questions</li>
<li>Close</li>
</ul>
<p>Van deze ALV zijn de notulen beschikbaar:</p>
<p><a href="https://fronteers.nl/vereniging/bestuur/notulen/notulen-alv-14-oktober-2020">Notulen ALV 14 oktober 2020</a></p>
</content>
</entry>
<entry>
<title>Resultaten Fronteers enquete 2020</title>
<link href="https://www.fronteers.nl/nl/blog/2020/07/resultaten-fronteers-enquete-2020"/>
<updated>2020-07-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/07/resultaten-fronteers-enquete-2020</id>
<content xml:lang="nl" type="html"><p>In juni hebben we een enquete gehouden onder leden van Fronteers en front-end developers.</p>
<p>We vroegen developers die wel en niet lid zijn van de vereniging, naar informatie zoals hun salaris, regio, ervaringsniveau, en specifieke Fronteers-gerelateerde zaken. Niet alleen om feedback voor het bestuur en de commissies te verzamelen maar ook om een beter beeld te krijgen van wat onze beroepsgroep bezig houdt! We bedanken de 97 personen die de tijd hiervoor uittrokken.</p>
<p><a href="https://www.fronteers.nl/vereniging/resultaten-fronteers-enquete-2020">Hier zijn de resultaten van de enquete!</a></p>
</content>
</entry>
<entry>
<title>Online meetup met Rachel Andrew en Darice de Cuba</title>
<link href="https://www.fronteers.nl/nl/blog/2020/06/online-meetup-met-rachel-andrew-en-darice-de-cuba"/>
<updated>2020-06-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/06/online-meetup-met-rachel-andrew-en-darice-de-cuba</id>
<content xml:lang="nl" type="html"><p>Vrijdag 19 juni organiseren we onze allereerste online bijeenkomst! We hebben een korte workshop, 2 talks én een quiz in de planning staan.</p>
<p>De bijeenkomst begint om 19:00 en is gratis en voor iedereen toegankelijk. <a href="https://twitter.com/HenriHelvetica">Henri Helvetica</a> zal de rol van gastheer op zich nemen, <a href="https://twitter.com/rachelandrew%5D">Rachel Andrew</a> zal ons leren over CSS-specificaties en ons bijpraten over de nieuwste ontwikkelingen in CSS, en <a href="https://darice.org/">Darice de Cuba</a> zal een talk geven over inclusive design.</p>
<p>Het volledige programma en overige informatie kun je vinden op <a href="https://www.fronteers.nl/nl/activiteiten/2020/online-meetup">onze bijeenkomstpagina</a> en op <a href="https://www.meetup.com/Fronteers-NL/events/271326914/">Meetup</a>.</p>
<p>De livestream is vanaf 18:45 te volgen via <a href="https://www.youtube.com/watch?v=N2tvZ4P44jY">Youtube</a>.</p>
</content>
</entry>
<entry>
<title>Vier de Dag van Front-end Development virtueel mee</title>
<link href="https://www.fronteers.nl/nl/blog/2020/04/vier-de-dag-van-front-end-development-virtueel-mee"/>
<updated>2020-04-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/04/vier-de-dag-van-front-end-development-virtueel-mee</id>
<content xml:lang="nl" type="html"><p>Zaterdag 4 april vieren we weer Dag van Front-end Development. We doen dit keer digitaal, onder andere met een front-end pubquiz. Vier jij als front-end developer deze dag met ons mee?</p>
<p>Om 20:00 uur openen de deuren van onze virtuele zaal en kan iedereen die dat wil <a href="https://meet.google.com/uwo-jfot-cuz">joinen via Google Meet</a>. Vervolgens zullen we om 20:20 uur met z'n allen proosten op ons mooie werk. Let op: het is wel 'BYOD': bring your own drink. Aansluitend begint de front-end pubquiz, die we zullen spelen via de app Kahoot. Natuurlijk zijn er ook prijzen te winnen!</p>
<p>Let op: voor de beste ervaring is het handig om twee devices te gebruiken. Een waarop je Google Meet hebt en de vragen van de pubquiz kunt zien en een met Kahoot. Kahoot toont namelijk de vragen niet, alleen antwoord-opties.</p>
<p>English
April 4th is Day of Front-end Development and we will celebrate this with an online meeting and a front-end pub quiz. We will open our virtual doors at 20:00h and we will toast to our beautiful line of work at 20:20h. You can <a href="https://meet.google.com/uwo-jfot-cuz">join our Google Meet</a>. Please remember, it's 'BYOD': bring your own drink. After our toast we will start a front-end pubquiz, which we will play with the app Kahoot. This quiz will be in English and of course there will be prizes to win.</p>
<p>Note: it's best to have two devices available to play the pub quiz. One with the Google Meet where we will share the questions and one with Kahoot, because Kahoot only shows available answers, not the questions.</p>
</content>
</entry>
<entry>
<title>Ledenkorting voor masterclass Vue.js</title>
<link href="https://www.fronteers.nl/nl/blog/2020/03/ledenkorting-voor-masterclass-vue-js"/>
<updated>2020-03-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/03/ledenkorting-voor-masterclass-vue-js</id>
<content xml:lang="nl" type="html"><p>Op donderdag 14 en vrijdag 15 mei organiseert De Voorhoede een <a href="https://www.voorhoede.nl/nl/events/vue-masterclass-3/">Vue.js Masterclass</a> in Amsterdam. Leden van Fronteers ontvangen 10% korting op deze Masterclass. In een tweedaagse workshop leer je alles wat je moet weten om een snelle en volwaardige web app te bouwen met Vue.</p>
<p>Vue.js (vuejs.org) is één van de populairste JavaScript frameworks om web apps mee te bouwen. En dat is logisch. Vue is toegankelijk omdat het dichtbij de webstandaarden blijft. Het is een compleet framework, met een groot ecosysteem dat je ondersteunt bij het bouwen van complete web apps.</p>
<p>In de tweedaagse workshop van de Voorhoede bouw je je 'eigen versie van Slack' met Vue. Van basisconcepten tot geavanceerde patronen en hoe je jouw Vue app naar productie krijgt.</p>
<h2>Dag 1 - Introductie in Vue:</h2>
<p>De masterclass begint met de basisconcepten van Vue; werken met componenten, hun levensduur, eigenschappen, methodes en content slots; het managen van data en state; en animaties in Vue.</p>
<h2>Dag 2 - Gevorderd in Vue:</h2>
<p>Je leert hoe je opschaalt en je Vue app inricht voor productie; met vue-cli, vue-router, single file components en smart vs dumb components; je leert state management met Vuex; maakt gebruik van async actions om APIs te koppelen; en leert over error handling en optimaliseren van je app.</p>
<h2>Praktisch</h2>
<p>De masterclass zal gehouden worden op 14 &amp; 15 mei en vindt in principe plaats op het kantoor van de Voorhoede op de Rijnsburgstraat 9 in Amsterdam. Mochten de huidige omstandigheden daar om vragen dan zullen we dit naar een online workshop aanpassen; de workshop gaat dus sowieso door! Fronteers-leden krijgen 10% korting op de prijs van de masterclass (zonder korting is deze €399 voor één dag, of €599 voor beide dagen). Bij de toegang zijn koffie, lunch, en een drankje na afloop inbegrepen. <a href="https://www.voorhoede.nl/nl/events/vue-masterclass-3/">Meer informatie is te vinden op de website van de masterclass</a>.</p>
<p>Mocht je gebruik willen maken van deze korting, <a href="mailto:bestuur@fronteers.nl">stuur dan een e-mail naar het bestuur</a>. Zoals gebruikelijk geldt deze actie alleen voor leden die op dit moment al lid zijn.</p>
</content>
</entry>
<entry>
<title>Met Fronteerskorting naar dsgnday en CSS Day 2020</title>
<link href="https://www.fronteers.nl/nl/blog/2020/01/met-fronteerskorting-naar-dsgnday-en-css-day-2020"/>
<updated>2020-01-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2020/01/met-fronteerskorting-naar-dsgnday-en-css-day-2020</id>
<content xml:lang="nl" type="html"><p>Op 11 en 12 juni houdt Web Conferences Amsterdam voor maar liefst de achtste keer <a href="https://cssday.nl/2020">CSS Day</a>. Sinds een paar jaar wordt CSS Day voorafgegaan door een dag met presentaties rond een aan webdevelopment verwant thema. Dit jaar betekent dat een comeback van dsgnday!</p>
<p>Net als voorgaande jaren krijgen Fronteers-leden korting op dit congres. Wanneer je lid bent betaal je niet 600 maar 500 euro voor een kaartje voor beide dagen, of 275 in plaats van 325 voor een eendagskaartje (alle bedragen exclusief BTW). Het aanbod is geldig voor mensen die op dit moment al lid zijn, en je kunt ervan gebruik maken door <a href="mailto:bestuur@fronteers.nl">een email naar het bestuur</a> te zenden. Je ontvangt dan een eenmalig te gebruiken kortingslink waarmee je je kaart kunt kopen.</p>
<p>Bekijk voor meer informatie over de line-up de <a href="https://cssday.nl/2020">website van CSS Day</a> en volg <a href="https://twitter.com/cssdayconf">CSS Day op Twitter</a> of <a href="https://www.linkedin.com/showcase/cssday/">op LinkedIn</a> voor aankondigingen rond de laatste sprekers!</p>
</content>
</entry>
<entry>
<title>We wish you...</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/we-wish-you"/>
<updated>2019-12-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/we-wish-you</id>
<content xml:lang="nl" type="html"><p>These last days of the year are a time to look back at what you did the past year and to look forward to what's to come. At Fronteers we can look back at a great year. We became a member of the <a href="https://www.fronteers.nl/nl/blog/2019/01/fronteers-is-w3c-lid">W3C</a>, <a href="https://vimeo.com/channels/fronteersconf19">Fronteers Conference</a> was amazing as always and we hosted a couple of awesome <a href="https://fronteers.nl/workshops">workshops</a>.</p>
<p>And we also have a lot to look forward to. We're gonna present a new design for our identity, we're starting work at our new website and of course there will be more workshops and in the autumn another edition of Fronteers Conference.</p>
<p>We hope you had a great 2019 and we wish you a happy christmas and a sparkling 2020. Of course, our volunteers have some new year's wishes for you too.</p>
<h2>Jewwy</h2>
<pre><code>#fronteers + .everyone::before {
content: 'Happy New Year !';
position: absolute;
z-index: 2020;
background: #f2bb00;
color: #000
}
</code></pre>
<h2>Jules</h2>
<p>Happy and accessible 2020!</p>
<h2>Job</h2>
<p>While twenty-nineteen's almost empty
this new year has potential a-plenty
The fronteers volunteers
wish you a splendid new year's.
All the best to you in twenty-twenty!</p>
<h2>Claudia</h2>
<p>Best wishes for 2020 &amp; let’s build a more <code>#00FF00</code> web together! 💚</p>
<h2>Paul</h2>
<p>The Web is for Everyone. For you, you, you and you! And you. And a happy 2020!</p>
<h2>Bernard</h2>
<p>Have fun breaking your new year's resolutions! Wishing you all the best for 2020!</p>
<h2>Michael</h2>
<p>Best wishes for you and your loved ones for 2020!</p>
<h2>Iain</h2>
<p>Keep building a better web and a better world in 2020! Happy holidays and the best wishes for 2020.</p>
<h2>Koen</h2>
<p>Let's make the web a little more awesome in 2020. Have a great year!</p>
<h2>Josee</h2>
<p>I wish you a lovely, happy and fun 2020! Let's all do our share to make the world and the web a little better every day.</p>
<h2>Board - Anneke, Edwin, Sander</h2>
<p>The board of Fronteers wishes all front-end developers fantastic and semantic, styles with smiles, possibly some high-end destructuring assignment and above all, creativity aplenty in 2020!</p>
<h2>What are your plans and wishes for 2020?</h2>
</content>
</entry>
<entry>
<title>Cybersecurity: 4 tips voor developers</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/cybersecurity-4-tips-voor-developers"/>
<updated>2019-12-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/cybersecurity-4-tips-voor-developers</id>
<content xml:lang="nl" type="html"><p>Denk je het volgende hypothetische scenario eens in: maandagochtend kom je op je werk. Je bent wat vroeger dan normaal, vandaag zelfs de eerste van je team. Terwijl de koffiemachine druk aan het malen is, maalt jouw hoofd ook. Deadlines, volle backlogs, sprintmeetings. Drukke dag. Je opent je e-mail. Een bericht valt op: vannacht om 02:47:35 was het systeem een minuut heel langzaam. Hoewel het niet jouw taak is, besluit je toch even te gaan kijken.</p>
<p>“Dit is wel heel vreemd”, denk je bij jezelf. Je hart begint harder te kloppen en je denkt: “met één medewerkeraccount zijn betaalinformatie en andere privé-gegevens van klanten bekeken in minder dan 53 seconden?” Je realiseert direct dat Herman dit niet zelf zou kunnen hebben gedaan. Sterker nog, hij zou niet eens toegang tot dit deel van de applicatie moeten hebben.</p>
<p>Het kleinste datalek kan een bedrijf al in een zeer slecht daglicht zetten. Als front-end developer heb je zeker invloed op welke beveiligingsmaatregelen genomen worden en kun je concrete voorstellen aan je projectmanager voorleggen. Maak in deze blog kennis met de basisterminologie en leer een aantal maatregelen die je kunt nemen. Inclusief kant-en-klare user stories.</p>
<h2>Wat is hier gebeurd?</h2>
<p>Uit het onderzoek in ons hypothetische scenario is gebleken dat Herman in de gedeelde kantine gebruik heeft gemaakt van de openbare wifi. Wat hij niet door had, is dat zijn laptop net overgeschakeld was naar dit netwerk. Wat hij ook niet wist, was dat er op dat moment een aanvaller op het netwerk zat met een proxy wifi station en al het verkeer erlangs leidde. En laat het nou ook zo zijn, dat Herman opnieuw moest inloggen, omdat hij op het nieuwe netwerk zat. Hij waande zich veilig op het bedrijfsnetwerk en dacht nog: &quot;ik kan nog geen koffie halen of ik moet alweer inloggen&quot;.</p>
<p>In de tussentijd zit de aanvaller klaar: zij heeft haar aanval zo opgezet dat het doelwit niets door heeft. Ze kan alle pagina's zien en zodoende ook de logingegevens achterhalen. Zo kwam de aanvaller aan de logingegevens van Herman. En daar stopte het niet. Zij kon het verkeer onderscheppen en dat gaf haar inzicht in de opzet van applicatie.</p>
<p>Hoewel de rol van Herman maar klein was, laat de directeur er beslist geen gras over heen groeien: hij wordt bij binnenkomst direct apart genomen en op non-actief gezet.</p>
<h2>Wat ging er wel goed?</h2>
<p>Goede punten zijn er ook. Uit dit verhaal blijkt dat bepaalde acties gelogd worden met het bijbehorende account en dat er monitoring is van bijzonderheden, zoals errors, laadtijden en dergelijke.</p>
<p>Hieronder volgen een aantal suggesties die je kunt uitvoeren waardoor een dergelijke aanval veel lastiger succesvol uit te voeren is.</p>
<h2>Begrippen</h2>
<p>De browser doet bij een bezoek van een website een <em>HTTP request</em> en daarop volgt bij succes dan een reponse die verdeeld is in <em>response headers</em> en een <em>reponse body</em> (bijv. HTML, CSS en JS). In deze headers kun je informatie kwijt die de browser gebruikt om bepaalde maatregelen in te schakelen.</p>
<p><em>Mitigatie:</em> <a href="https://nl.wikipedia.org/wiki/Mitigatie">Mitigatie</a> is matiging, verzachting, vermindering. Of een aanval(ler) succesvol is, ligt aan veel factoren. In de context van cybersecurity betekent dit dat een beveiligingsmaatregel ervoor zorgt dat een mogelijk aanval minder succesvol, moeilijker of helemaal onmogelijk wordt.</p>
<h2>1. Bescherm je cookie</h2>
<p>User story: bescherm gebruikers tegen session hijacking</p>
<p>De eerste tip is cookie-hygiëne. Zorg ervoor dat (sessie)cookies beschermd zijn met deze extra (los van elkaar te gebruiken) instellingen: HttpOnly, Secure en SameSite. Hiermee wordt session hijacking en CSRF (Cross Site Request Fogery) lastig voor een aanvaller.</p>
<p>HttpOnly cookies hebben een bijzondere eigenschap: ze kunnen niet worden uitgelezen of bewerkt door de browser. Dus ook niet door third-party scripts. HttpOnly cookies kunnen alleen worden ingesteld door de server en worden alleen automatisch meegestuurd bij elke HTTP-request. Dit is handig voor sessiecookies.</p>
<p>Door een cookie de Secure-flag te geven, wordt deze alleen verstuurd over HTTPS-verbindingen door de browser.</p>
<p>De SameSite-flag is relatief nieuw en daarin kun je aangeven dat een cookie uitsluitend naar zijn eigen domein verstuurd mag worden: <code>SameSite=strict</code>. Zo voorkom je dat jouw cookies bij HTTP-requests naar andere domeinen meegestuur worden. <a href="https://web.dev/samesite-cookies-explained/">Lees meer over SameSite cookies</a>.</p>
<h2>2. Gebruik een XSRF-cookie</h2>
<p>User story: bescherm gebruikers tegen CSRF</p>
<p>Een moderne browser geeft een XSRF-cookie alleen mee aan POST-, PUT-, DELETE-requests die naar dezelfde domein gaan. Dit biedt zo een extra check om CSRF-aanvallen te voorkomen. Als deze cookie niet aanwezig is, is de gebruiker niet geauthenticeerd.</p>
<pre><code>X-CSRF-Token: value
</code></pre>
<p>De naam token suggereert dat hier een token voor gegenereerd moet worden, dit is echter optioneel. Hier kan elke value worden gebruikt. Uiteraard kun je er natuurlijk wel een token inzetten, als je dat zo wenst.</p>
<h2>3. Content Security Policy, in kort: CSP</h2>
<p>User story: gebruikers moeten maximaal beschermd zijn tegen XSS (Cross Site Scripting)</p>
<ul>
<li>Browsers bevatten steeds meer features, variërend van toegang tot de camera en microfoon tot het sturen van notificaties.</li>
<li>Stel dat een aanvaller het voor elkaar krijgt om een klein stukje JavaScript aan een pagina toe te voegen, dan heeft hij of zij toegang tot alle features, formulieren en andere acties van een gebruiker. De verkregen gegevens kunnen dan weer doorgestuurd worden naar een andere website.</li>
<li>Zo kan een aanvaller potentieel gevoelige gegevens skimmen (ofwel ‘steelt’). Denk bijvoorbeeld aan creditcard-gegevens op een checkout-pagina, logingegevens of BSN-nummers op een pagina van een zorgverzekeraar. Een gebruiker heeft dit niet door en kan zich hier nauwelijks tegen wapenen.</li>
</ul>
<p>Gelukkig is dit te mitigeren met behulp van Content Security Policy (CSP). Moderne browsers ondersteunen dit sinds kort.
Met behulp van CSP kun je exact specificeren bij het inladen van de pagina welke onderdelen van de browser gebruikt mogen worden, vanaf welke domein en zelf met welke hash. Als de websites dan toch een van deze features aanroept of een script probeert in te laden, dan faalt dit. Zo wordt het voor aanvallers iets lastiger: voordat ze een script kunnen uitvoeren moet eerst CSP worden uitgeschakeld.</p>
<p>Implementatie van CSP kan op twee manieren: je kunt een HTTP-header toevoegen of in de HTTP-reponse een <code>&lt;meta&gt;</code>-tag toevoegen. Op de website van MDN kun je <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP">uitstekende voorbeelden</a> vinden.</p>
<p>Soms is de implementatie hiervan niet eenvoudig. Het is bijvoorbeeld lastig als je website veel third party scripts inlaadt of vanaf meerdere domeinen api calls moet doen. Wat je dan als tussenmaatregel zou kunnen doen is het beschermen van bepaalde pagina's met gevoelige gegevens. Op een login- of betaalpagina bijvoorbeeld wil je geen third party scripts draaien.</p>
<p>Doel: Voorkom dat een pagina iets kan doen wat je niet nodig hebt, maar een aanvaller wellicht wel. Door exact te specificeren welke features een browser mag gebruiken, kun je bepaalde aanvalsvectoren onmogelijk maken of het effect ervan beperken.</p>
<h2>4. Mitigeer downgrade aanval</h2>
<p>User story: als gebruiker wil ik <em>altijd</em> een HTTPS-verbinding.</p>
<ul>
<li>Veel websites met een HTTPS-verbinding kunnen ook nog bereikt worden via HTTP.</li>
<li>Een aanvaller kan proberen om de gebruiker om te leiden naar de HTTP-versie en zo het verkeer monitoren of zelf bewerken, zoals bij Herman in ons hypothetische verhaal.</li>
<li>Dit heet een <strong>downgrade aanval</strong>. Hier kun je twee maatregelen tegen nemen om dit (deels) te voorkomen.</li>
</ul>
<p><em>A.</em> Gebruik HSTS (HTTP Strict Transport Security) door dit HTTP-responseveld toe te voegen: <code>Strict-Transport-Security: max-age=60000</code>. Als een browser dit detecteert, onthoudt deze voor een bepaalde periode dat altijd de HTTPS-website geopend moet worden.</p>
<p><em>B.</em> Mochten er nou toch nog non-HTTPS verbindingen worden gemaakt, zorg er dan voor dat elk HTTP-request automatisch wordt geredirect naar HTTPS. Dit kun bij Apache in de .htaccess ingestellen of bijv. met Express (Node.js webserver) met middleware.</p>
<h2>Hier stopt het niet... een paar tips</h2>
<p>De hierboven genoemde maatregelen zijn maar een kleine selectie van acties die je zelf concreet kunt nemen. Er is nog veel meer mogelijk. Kijk bijvoorbeeld eens naar onderstaande tips.</p>
<ul>
<li>Luister naar de podcast <a href="https://darknetdiaries.com/">Darknet Diaries</a>.</li>
<li>Voeg 2FA toe met bijvoorbeeld een time-based one-time password.</li>
<li>Laat een penetration test uitvoeren. Probeer maximaal te leren van zo'n team dat langs komt en lees het verslag van top tot teen.</li>
<li>Leer meer over <a href="https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy">Same Origin Policy</a>.</li>
<li>Leer meer over <a href="https://developer.mozilla.org/nl/docs/Web/Security/Subresource_Integrity">Subresource Integrity</a>.</li>
<li>Lees <a href="https://www.securitydrops.com/">Security Droplets</a></li>
<li>Pas op met deze header <code>Access-Control-Allow-Origin: *</code>. Een aantal van de hierboven beschreven maatregelen kunnen minder effectief gemaakt worden.</li>
<li>Bespreek het onderwerp ‘cybersecurity’ in je team. Er is een goede kans dat er iemand bij zit die direct wat verbeterpunten weet om Herman te redden.</li>
</ul>
<p>Op naar een veiliger decennium!</p>
<h2>Over Melle Wynia</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/melle.jpg" alt="Foto van Melle Wynia" class="floating-portrait" />
Melle Wynia werkt als freelance front-end developer/consultant/architect. Voor zijn klanten sluit hij aan bij hun teams om kennis over te dragen, de kwaliteit te waarborgen, beveiliging op peil te brengen en nieuwe features te realiseren. Tot zijn tools behoren onder andere Node, Angular en Vue.js.
Melles donatie gaat naar de Hersenstichting.
</content>
</entry>
<entry>
<title>Clichés op het web</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/cliches-op-het-web"/>
<updated>2019-12-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/cliches-op-het-web</id>
<content xml:lang="nl" type="html"><p>Letterlijk is een ‘cliché’ een metalen plaat waarmee je illustraties kunt afdrukken. Figuurlijk is een cliché een afgesleten manier van spreken of denken. De eerste keer dat je een grap maakt, is ‘ie leuk. De tweede keer is ‘ie al minder. Na tien keer is ‘ie saai. Clichés zijn de doodgeslagen cola van je denkvermogen, om het op z’n BLØFs te zeggen.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/king-pepermunt-cliche.jpg" alt="Een cliché voor reclame voor King pepermunt" /></p>
<p class="note">
Een cliché voor reclame voor King pepermunt
</p>
<p>Clichés zijn niet per definitie onwaar of fout. Het kan heel handig zijn om in clichés te denken. Het is doodvermoeiend en zonde van je tijd om altijd overal over na te denken. Clichés helpen je dan, zodat je niet te lang hoeft na te denken. Maar je moet niet alles geloven wat je denkt, want soms is wat je denkt gewoon fout.</p>
<p>Sommige clichés zijn bijna niet uit te roeien. “Als anderen het doen, zal het wel goed zijn.” Een klant van me vroeg laatst wanneer ik een cookie-waarschuwing op de site zou plaatsen. Waarom? Omdat iedereen het doet, dus hoort een cookie-waarschuwing op elke website.</p>
<p>Aaargh.</p>
<h2>Cliché 1: ‘Een plaatje zegt meer dan 1000 woorden’</h2>
<p>Sure, maar welke 1000 woorden zegt jouw plaatje? Zegt je plaatje “Ik had geen tijd om een goede foto te zoeken”?</p>
<h2>Plaatjes-omdat-het-moet</h2>
<p>We zijn gewend geraakt aan enorme hero images, schermvullend en topzwaar. Hierdoor denken we dat bij elk bericht een foto hoort. Het probleem is dat niet iedereen een geweldige foto-bibliotheek ter beschikking heeft. Het resultaat? Websites vol plaatjes-omdat-het-moet. Het liefst clipart met teksten die verkeerd afgesneden worden. Fotoredactie is het ondergeschoven kindje van modern webwerk.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/screenshot-frankwatching-20191127.jpg" alt="Screenshot van Frankwatching.com (november 2019)" /></p>
<p class="note">
Screenshot van Frankwatching.com (november 2019)
</p>
<h2>Stockfoto’s</h2>
<p>Niet iedereen heeft een geweldige smaak of fantasie, sorry dat ik het zeg. En even een plaatje googelen is een fluitje van een cent.</p>
<p>Resultaat? “<a href="https://paulvanbuuren.nl/aap-eet-banaan/">Aap eet banaan</a>“, een uitdrukking van ontwerpers voor een ontwerp dat er te dik bovenop ligt. Denk aan een hamer als logo voor een timmerman. Een aap-eet-banaan-slogan is: ‘Voor al uw timmerwerk’.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/google-image-search-01-ariane-the-overused.jpg" alt="Ariane The Overexposed Stockphoto Model" /></p>
<p class="note">
Ariane The Overexposed Stockphoto Model
</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/google-image-search-02-succes.jpg" alt="Zoek op “Success”" /></p>
<p class="note">
Zoek op “Success”
</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/google-image-search-03-men-shaking-hands.jpg" alt="Zoek op “Men shaking hands”" /></p>
<p class="note">
Zoek op “Men shaking hands”
</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/google-image-search-04-boys-toys.jpg" alt="Zoek op “Boy toys”" /></p>
<p class="note">
Zoek op “Boy toys”
</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/google-image-search-05-girls-toys.jpg" alt="Zoek op “Girl toys”" /></p>
<p class="note">
Zoek op “Girl toys”
</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/google-image-search-07-woman-eating-salad.jpg" alt="Zoek op “Woman eating salad”" /></p>
<p class="note">
Zoek op “Woman eating salad”
</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/google-image-search-06-hackers.jpg" alt="Zoek op “Hacker”" /></p>
<p class="note">
Zoek op “Hacker”
</p>
<h2>Icoontjes</h2>
<p>En icoontjes? Breek me de bek niet open over icoontjes. Alles wordt begrijpelijker door icoontjes zeg je? Hmmm, kijk ‘<a href="https://vimeo.com/251649861">Repelsteeltje – Guess My Name</a>’ nog eens terug, een hilarische presentatie van Mallory van Achterberg over onbegrijpelijke icoontjes.</p>
<h2>Cliché 2: klik hier en lees meer</h2>
<p>Opa vertelt: er is een tijd geweest dat het internet zo nieuw was dat je alles moest uitleggen. Dat was de tijd dat we URLs in reclame volledig uitspelden. “Ga naar haa tee tee pee dubbele punt slash slash wee wee wee nu punt en el voor het laatste nieuws”, ofzo. Je wist niet beter, je had niets anders. Dus je moest ook het principe van een klikbare link uitleggen. Uit die tijd stamt de irritante gewoonte om ‘klik <a href="http://click-here.nl/">hier</a>‘ als linktekst te gebruiken. ’t Liefst 1 woord ja.</p>
<h2>Klik me dan, als je kan</h2>
<p>Moet ik nog vertellen waarom dat een slechte gewoonte is? Ten eerste geldt: hoe kleiner het klikbare gedeelte, hoe moeilijker het is om er op te klikken (zie deze <a href="https://www.interaction-design.org/literature/topics/fitts-law">uitleg van Fitt’s Law</a>). Ten tweede: ‘hier’ beschrijft niet waar je heen gaat. Je vertelt je gebruiker niet wat hij op die nieuwe URL kan verwachten. Dat is niet aardig. Wees aardig voor je bezoeker.</p>
<h2>Lees meer, meer, meer!</h2>
<p>De tweelingbroer van Klik Hier is Lees Meer. Ook met ‘lees meer’ vertel je niet waar je naartoe gaat. Je hebt pech als je afhankelijk bent van een screenreader om wijs te worden uit een pagina met twintig keer een link met ‘lees meer’ als tekst. Beschrijf met je linktekst alsjeblieft waar je heen gaat en maak deze tekst uniek voor je webpagina. Mocht je omwille van het design van je pagina toch veroordeeld zijn tot korte linkteksten, gebruik dan een list. Gebruik bijvoorbeeld het <a href="https://www.w3.org/WAI/GL/wiki/Using_aria-label_for_link_purpose">‘aria-label’-attribuut als alternatief</a>, of gebruik de titel van de pagina waarnaar je verwijst als linktekst, maar <a href="https://a11yproject.com/posts/how-to-hide-content/">verberg die louter visueel</a>.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/lees-meer-boeken.jpg" alt="Stapels boeken" /></p>
<p class="note">
Dit is een prima aansporing: “Lees meer”, als je bedoelt: lees meer boeken
</p>
<p>Klik anders hier even: <a href="http://click-here.nl/">click-here.nl</a></p>
<h2>Cliche 3: Social media-knoppen</h2>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/vijf-knoppen-om-een-pagina-te-delen-facebook-twitter-whatsapp-linkedin-email.jpg" alt="Social media knoppen" /></p>
<p class="note">
Klik hier
</p>
<p>Die knoppen om een pagina te delen op social media? Ze werken amper. Ik ken geen onderzoeken die aantonen dat ze een groot effect hebben op het wel of niet delen van een pagina. Maximaal 1% van je bezoekers gebruikt die knoppen om een pagina te delen.</p>
<p>Waar ze wel goed voor zijn? Eh.</p>
<p>Ze zijn vooral bedoeld om je opdrachtgever het fijne gevoel te geven helemaal hip &amp; happening te zijn, want als je niet op sociale media meedoet besta je niet.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/satansboek.jpg" alt="Satansboek" /></p>
<p>Afhankelijk van hoe je die knoppen implementeert kun je het <a href="https://satansboek.nl/">satanische Facebook</a> helpen om je bezoeker over het hele internet te achtervolgen.</p>
<p>Hmmm, privacy.</p>
<h2>Cliche 4: lage bounce rate</h2>
<p>Bounce rate is een marketingterm voor het percentage van je bezoekers die na het eerste bezoek aan je site weer vertrekken; “Hee, hoi” en ze stuiteren weer door, zeg maar. Hoe lager je bounce rate, hoe meer je bezoekers doorklikken naar een volgende pagina op je site.</p>
<p>Een hoge bounce rate is niet erg.</p>
<p>Sterker nog: een hoge bounce rate zou kunnen betekenen (aanname!) dat je bezoeker exact gevonden heeft wat hij (m/v/a) wilde. Na zijn succesvolle bezoek aan je website sloot hij zijn laptop, ging naar huis en knuffelde zijn kind, zijn hond en zijn kat.</p>
<p>Wil je je bezoeker tevreden stellen of wil je ‘m bezigheidstherapie geven?</p>
<h2>Cliche 5: cookie-waarschuwingen</h2>
<p>Het web is ziek. Cookie-waarschuwingen zijn daar het symptoom van. Veel websites staan vol meuk om elke klik vast te leggen: pixels, beacons, fingerprinting, dynamic cookies, en what have you not. Anno 2019 is het web een panopticum waarin elke stap van je bezoeker doorgegeven wordt aan de Googles, Facebooks en geheime diensten van deze wereld. Dankzij Edward Snowden kennen we de details en ja, die zijn echt heel erg. <a href="https://www.wired.com/story/billion-records-exposed-online/">Onze gegevens liggen inmiddels op straat</a>.</p>
<h2>Cookies tegen heug en meug</h2>
<p>Cookie-waarschuwingen zijn bedoeld als pleister, om bezoekers meer controle te geven over hun gegevens. Helaas komen de meeste cookiemeldingen neer op: “Cookies: we zetten ze en we laten alle advertentieboeren ook meekijken en je hebt het er maar mee te doen.” Ik denk even aan de <a href="https://nos.nl/op3/artikel/2273929-gevolgd-op-internet-honderden-websites-schenden-je-privacy.html">1000 ongevraagde cookies op de site van TV Rijnmond</a>.</p>
<h2>Aksie, harde aksie!</h2>
<p>Daarom denk ik dat het goed is dat we als front-enders veel meer weerstand bieden tegen mogelijke schendingen van de privacy van onze bezoekers. Vraag je bij elk formulier dat je maakt bijvoorbeeld:</p>
<ul>
<li>Waarom vraag ik dit van de gebruiker?</li>
<li>Moet ik een binair geslacht weten? Welke ramp gebeurt er als ik straks niet iemand aanspreek met ‘Geachte mevrouw’, maar met ‘Hallo’ of ‘Goedendag’?</li>
<li>Moet ik echt een telefoonnummer vragen?</li>
<li>Wat gebeurt er straks met al deze gegevens?</li>
<li>En wat als deze gegevens op straat komen te liggen?</li>
</ul>
<p>Uiteraard wil je weten hoeveel bezoekers je hebt op je site. Maar moet je echt Google mee laten kijken? Google weet welke zoektermen je bezoeker gebruikte en dankzij je niet-geanonimiseerde Analytics-tracker weet het ook hoe snel je bezoeker weer wegstuiterde van je site. Gebruik betere analytics tools, die niet stiekem data doorverkopen aan adverteerders. Advertentieboeren zijn de keyloggers van het internet. Het is tijd dat we het heft weer in eigen hand nemen. Baas over eigen data.</p>
<h2>Cliche 6: formuliervelden zonder labels</h2>
<p>Ik denk dat het onkunde is dat er zoveel formulieren zonder fatsoenlijke labels te vinden zijn. Het is nogal simpel. Heb je een <code>&lt;input&gt;</code> dan hoort daar een <code>&lt;label&gt;</code> bij. Geen mitsen, geen maren: er hoort een label bij. Ik herhaal het even: geen placeholder, geen vet tekstje. Nee, een zichtbaar <code>&lt;label&gt;</code>.</p>
<pre><code>&lt;label for&quot;tralala&quot;&gt;
&lt;input type=&quot;text&quot; id=&quot;tralala&quot; name=&quot;voornaam&quot; placeholder=&quot;Je voornaam&quot; value=&quot;&quot; /&gt;
&lt;/label&gt;
</code></pre>
<p>Weet je wat daar zo handig van is? Je vertelt daarmee aan je gebruiker wat hij moet doen.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cliches/lift-knopjes.jpg" alt="Liftknopjes zonder nummer" /></p>
<p class="note">
O jee, geen labels. Wat nu? [Het origineel is trouwens niet veel beter](https://www.reddit.com/r/CrappyDesign/comments/78gcgt/this_elevator_button_panel/).
</p>
<h2>Cliche 7: niet-onderstreepte links</h2>
<p>Er zijn designers die zeggen: “Onderstreepte links zijn niet mooi.” Ik vind: suck it, hou je links herkenbaar. Vanaf het begin der tijden zijn links onderstreept en blauw. Heb je de link al bezocht dan is de link paars. Wapper je er met je muis overheen, dan wordt ‘ie rood. Zo deden we dat vroeger, zo deden onze voorouders het, zo deden de Neanderthalers het. Links zijn onderstreept.</p>
<h2>“Ja maar, ik heb m’n links een andere kleur gegeven!”</h2>
<p>Prima, maar wat als je bezoeker nou moeite heeft met kleuren zien? Dan is het heel fijn om niet op kleur alleen te vertrouwen. Dus ik zeg: onderstreping. Superhandig.</p>
<h2>Conclusie?</h2>
<p>Ik heb een paar willekeurige clichés gekozen om over te klagen. Waar dit wat mij betreft op neerkomt is:</p>
<ul>
<li>Hoe minder je bezoeker hoeft na te denken over je site hoe beter het is.</li>
<li>Hoe minder meuk wij vragen van onze bezoeker, hoe beter het voor hem is.</li>
<li>Hoe beter we nadenken over het hoe en waarom we websites maken, hoe beter het voor iedereen is.</li>
</ul>
<p>We moeten wat liever zijn voor onze bezoekers en de boel niet te moeilijk maken.</p>
<p>Vrede op aarde.</p>
<p>(Dit is een vertaling van een praatje dat ik eerder gaf bij de Fronteers Jam Sessions in oktober.)</p>
<h2>Over Paul van Buuren</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/paul.jpg" alt="Foto van Paul van Buuren" class="floating-portrait" />
Paul van Buuren maakt websites sinds 1998. Zijn vooropleiding heeft niks met webdesign te maken, want dat bestond domweg nog niet. Onder de noemer WBVB Rotterdam werkt hij als zelfstandige voor diverse opdrachtgevers. Z'n specialiteit is het maken van toegankelijke WordPress-sites. Hij praat opvallend vaak in algemeenheden en tegeltjeswijsheden.
Pauls donatie gaat naar KiKa.
</content>
</entry>
<entry>
<title>Rustig aan de gourmet dankzij Cypress.io</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/rustig-aan-de-gourmet-dankzij-cypress-io"/>
<updated>2019-12-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/rustig-aan-de-gourmet-dankzij-cypress-io</id>
<content xml:lang="nl" type="html"><p>De feestdagen, dagen vol met eten, gezelligheid en nog meer clichés, komen er weer aan. Het laatste wat je op deze dagen wilt: een telefoontje over code die niet werkt. Last minute op kerstavond uitrollen vond je al geen goed idee, maar nu heb je er dubbel spijt van.
Maar hoe is dit te voorkomen, behalve door niet op kerstavond nog iets uit te rollen? Hoe kun je met een gerust hart aanschuiven bij de gourmet met de wetenschap dat bijvoorbeeld de login-knop op je site nog steeds inlogt? Wellicht is <a href="http://cypress.io/">Cypress.io</a> wel het overwegen waard...</p>
<h2>Wat is Cypress?</h2>
<p>Zelf hoorde ik een tijdje terug voor het eerst over Cypress. Met dit open source Javascript framework kun je end-to-end tests schrijven voor praktisch alles wat in een webbrowser draait. <em>Met welk framework de applicatie of website ook gebouwd is (React, Angular, Vue), het is allemaal te testen met Javascript!</em></p>
<p>Cypress is een overkoepelend framework dat verschillende tools samenbrengt. Het bevat bekende test-tools als Mocha, Chai en Sinon. En doordat al deze tools dus al aanwezig zijn, kun je je focussen op wat echt belangrijk is: het schrijven van tests.</p>
<p>Na het lezen van wat algemene verhalen over dit framework, werd ik al enthousiast over de mogelijkheden:</p>
<ul>
<li><em>Timetravel.</em> Iedere stap tijdens een test is een snapshot. Je kunt via de GUI iedere stap van je test los bekijken om te checken waar het mis gaat.</li>
<li><em>Debuggen met Chrome Devtools.</em> Je kunt (in iedere stap) snel debuggen met de vertrouwde Chrome Devtools.</li>
<li><em>‘Not flaky’.</em> Geen async hel, Cypress wacht netjes op de state die jij wilt, tot het testen verder gaat.</li>
<li><em>Het is Javascript!</em> Dus als Front-ender met enige Javascript kennis kun je supersnel beginnen met het schrijven van tests.</li>
<li><em>Goede documentatie.</em> De site bevat goede en uitgebreide documentatie met veel voorbeelden.</li>
<li><em>Cypress heeft een GUI.</em> Tests zijn gemakkelijk te starten, volgen en stoppen in een duidelijke Graphical User Interface.</li>
</ul>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cypress-io/image001.png" alt="De Cypress GUI a.k.a. test runner" /></p>
<p><em>Kortom: er zijn een hoop mooie features die het gourmetten op kerstavond een stuk aangenamer maken.</em></p>
<h2>OK, ik heb ook een project dat ik wil testen! Wat moet ik doen?</h2>
<p>Het installeren van Cypress is zo gedaan. Volgens de documentatie zou je binnen 60 seconden je eerste tests moeten kunnen draaien. Wellicht wat overdreven, maar heel veel scheelt het niet.</p>
<p>Om Cypress via npm te installeren, is het uitvoeren van het volgende script in je projectmap voldoende.</p>
<pre><code>$ npm install cypress --save-dev
</code></pre>
<p>De Cypress test runner kun je vervolgens openen via NPX:</p>
<pre><code>$ npx cypress open
</code></pre>
<p>Deze is ook te openen via een NPM script. Voeg hiervoor het volgende toe aan je <em>package.json</em>:</p>
<pre><code>{
&quot;scripts&quot;: {
&quot;cypress:open&quot;: &quot;cypress open&quot;
}
}
</code></pre>
<p>Hiermee kun je met onderstaand NPM commando de Cypress test runner openen.</p>
<pre><code>$ npm run cypress:open
</code></pre>
<h2>De Test Runner</h2>
<p>Na het openen van Cypress verschijnt de test runner. Hierin krijg je een overzicht van alle test-bestanden die er in je project zitten. Deze kunnen los van elkaar gestart worden, maar je kunt er ook voor kiezen om alle tests achter elkaar te draaien.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cypress-io/image003.png" alt="Cypress mappenindeling" /></p>
<p>Bij het installeren en de eerste keer openen van Cypress is er al automatisch een map cypress aangemaakt in je project. Deze bevat zelf ook weer diverse mappen, met daarin voorbeeldbestanden. De testscripts kun je terugvinden en toevoegen in <em>integration</em>. Dit is de belangrijkste map voor nu.Tijd voor een nieuwe test!</p>
<h2>Je eerste test: de login pagina</h2>
<p>Stel je voor: inloggen is een belangrijke pagina van je site en moet altijd bereikbaar zijn via een grote button ‘inloggen’. Dan zou een logische eerste test zijn: wanneer de gebruiker op de inloggen button klikt, wordt hij/zij dan doorverwezen naar de juiste pagina?</p>
<p>Om te starten maak je eerst een nieuw bestand aan in de <em>integration</em> map. Laten we deze <em>login.spec.js</em> noemen (of waar je je goed bij voelt). Zoals je zult zien, het bestand zal meteen getoond worden in de test runner, mits je deze al open hebt staan.</p>
<p>De test kunnen we als succesvol beschouwen wanneer:</p>
<ol>
<li>De login button bestaat</li>
<li>Deze aangeklikt kan worden</li>
<li>De gebruiker naar <em>/login</em> wordt doorverwezen</li>
</ol>
<pre><code>describe('Login page test', function() {
it('Visits the loginpage', function() {
cy.visit('https://localhost:8000')
cy.get('#login-button').click();
cy.url().should('include', '/login');
})
})
</code></pre>
<p>Wanneer je eerder tests met Mocha hebt geschreven zal bovenstaande syntax je al voor een groot deel bekend voor komen. Cypress heeft Mocha’s <em>bdd syntax</em> overgenomen waarmee je je tests kunt opbouwen. Je kunt dus zaken als <code>describe()</code>, <code>context()</code>, <code>it()</code> en <code>beforeEach()</code> gewoon blijven gebruiken.</p>
<p>In het script gaan we er van uit dat de te testen pagina op localhost draait. De eerste stap navigeert naar deze omgeving. Vervolgens kun je met <code>cy.get()</code> een element selecteren op basis van CSS-class. De <code>.click()</code> functie simuleert een klik op het element. In de laatste regel van de test wordt er een voorwaarde gesteld dat de url in ieder geval <em>/login</em> zou moeten bevatten.</p>
<p>Nu de test geschreven is, kan deze gestart worden in de test runner. Nu is het een kwestie van achterover leunen en hopen dat alle test-opdrachten succesvol kunnen worden afgerond.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/cypress-io/image005.png" alt="De test runner in actie. Bron: cypress.io" /></p>
<p>De test wordt in een browser uitgevoerd en je kunt meteen iedere stap meekijken. Aan de linkerkant van je scherm worden meteen alle stappen / interacties op de pagina getoond. Via deze tijdlijn kun je terug gaan naar iedere stap in de test en de DOM op dat specifieke moment bekijken en… manipuleren via de Chrome dev tools. Dankzij deze tijdmachine kun je precies zien wanneer een bepaalde bug zich voordoet en deze meteen debuggen!</p>
<p>Ik geef toe, het is een simpele test, maar het toont aan hoe makkelijk je kunt starten met het schrijven van tests. Je kunt met heel basale zaken beginnen en deze steeds verder uitbreiden.</p>
<h2>Nog een test: het inlogformulier</h2>
<p>Dat de login pagina bereikbaar is, is fijn, maar een succesvolle inlog geeft nog iets meer rust. Daarom is het tijd om het script nog iets uit te breiden (of je voegt een nieuw test-script toe):</p>
<pre><code>describe('Login', () =&gt; {
it('User login works', () =&gt; {
cy.visit('http://localhost:3000/account/login/');
cy.get('[name=&quot;email&quot;]').type('pieter@test.com');
cy.get('[name=&quot;password&quot;]').type('ditiseentest');
cy.get('.container-login button').click();
cy.url().should('include', '/accountmanagement');
expect(cy.contains('Hoi Pieter!')).toBeTruthy;
cy.screenshot();
});
});
</code></pre>
<p>Het <code>.type()</code> commando geeft de mogelijkheid om inputs te vullen met content en zorgt ervoor dat er getest kan worden of de gebruiker succesvol ingelogd kan worden.</p>
<h2>Screenshots / videos</h2>
<p>Wanneer tests falen maakt Cypress automatisch screenshots voor je. <em><em>Deze screenshots van falende tests komen automatisch terecht in de map cypress/screenshots gevolgd door een map met de naam van de test.</em></em> Wil je screenshots op bepaalde momenten in de test laten maken? Ook dat kan. De regel</p>
<pre><code>cy.screenshot();
</code></pre>
<p>maakt een screenshot van de hele pagina op het moment dat jij dat wil. Wel even opletten: Cypress verwijdert alle screenshots voor het <code>cypress run</code> commando.</p>
<h2>Configuratie in Cypress.json</h2>
<p>Behalve de <em>cypress</em>-map, wordt er ook een <em>cypress.json</em>-bestand aangemaakt in de root folder van je project. In dit bestand kunnen algemene configuraties van en voor je tests worden gezet. Hierbij kun je denken aan het instellen van een baseurl (deze wordt als prefix gebruikt voor alle <code>cy.visit()</code> en <code>cy.request()</code> commando’s), timeouts, mappen waar bijvoorbeeld screenshots geplaatst moeten worden en de viewport.</p>
<p>Voorbeeldje: wanneer je je de <code>baseUrl</code> aanpast in de <em>config</em> naar:</p>
<pre><code>{
&quot;baseUrl&quot;: &quot;http://localhost:3000&quot;
}
</code></pre>
<p>zorgt dit er voor dat</p>
<pre><code>cy.visit(&quot;/login&quot;);
</code></pre>
<p>eigenlijk navigeert naar <em>http://localhost:3000/login</em>.</p>
<p>De waardes in de configuratie kunnen tijdens het testen nog wel worden overschreven door een <code>--config flag</code> toe te voegen in je CLI.</p>
<pre><code>cypress run --config viewportWidth=1280,viewportHeight=720
</code></pre>
<p>Ook kunnen de waardes in je script zelf worden overschreven:</p>
<pre><code>Cypress.config('pageLoadTimeout', 100000)
</code></pre>
<p>Is de uitkomst van je test niet helemaal zoals je die verwacht en vermoed je dat de configuratie de boosdoener is? In de <em>settings</em>-tab wordt een ‘gecompileerde’ versie van de gebruikte config weergegeven.</p>
<h2>Custom Commands</h2>
<p>Wanneer je in verschillende tests telkens dezelfde acties uit moet voeren, dan kun je overwegen om een <em>custom command</em> toe te voegen aan je tests. De Cypress API is ingericht op het toevoegen (of aanpassen) van Cypress commando’s. Wanneer je altijd wil testen met een ingelogde gebruiker, dan kun je hier een standaard commando maken.</p>
<p>Zo’n custom commando kun je toevoegen aan <em>commands.js</em>, welke je kunt vinden in de <em>/cypress/support</em> map, en kan er als volgt uit zien:</p>
<pre><code>Cypress.Commands.add('login', () =&gt; {
const user = {
email: 'admin@site.com',
password: 'test123' //natuurlijk alleen op local test ;)
}
cy.request({
url: '/login',
method: 'POST',
body: {
email: user.email,
password: user.password,
}
})
});
</code></pre>
<p>Het custom command <code>cy.login()</code> kun je nu in al je testscripts gebruiken. Bijvoorbeeld aan het begin van iedere test:</p>
<pre><code>describe('Cart page', () =&gt; {
before(() =&gt; {
cy.login()
});
it('Click cart button', () =&gt; {
cy.visit('http://localhost:3000/');
cy.get('#cart-button').click();
cy.url().should('include', '/cart');
});
});
</code></pre>
<h2>XHR Calls</h2>
<p>Met Cypress is ook het testen van XHR calls geen probleem. Het geeft je zelfs de keuze om de response ‘origineel’ te houden, of om deze te manipuleren. Door het intact laten van de response kan door een lange response tijd je tests vertragen. Daarom is het ‘mocken’ van een response, ook wel <em>stubbing</em> genaamd, het overwegen waard. Dit zorgt voor een snelle afhandeling van XHR calls, meestal binnen 20ms! Het mocken van de response kan met een paar regeltjes code:</p>
<pre><code>cy.server() // Response mocken (stubbing) aanzetten
cy.route({
method: 'GET', // Route alle GET requests
url: '/users/*', // met url dat '/users/*' matched
response: [] // geeft volgende response
})
</code></pre>
<p>Dit is de snelste optie, maar er is een mooiere oplossing voor het mocken van de data: het gebruik van <em>fixtures</em>.</p>
<p>Een <em>fixture</em> is een verzameling van data in een bestand dat tijdens de test gebruikt kan worden. Deze <em>fixture</em> bestanden kun je vinden in de <em>cypress/fixtures</em> map en kunnen onder andere gebruikt worden voor het mocken van XHR-responses.</p>
<p>Wanneer je de response van een zoekopdracht wil mocken, dan kun je een JSON bestand met zoekresultaten in de fixtures map plaatsen, uiteraard in hetzelfde format als dat je in ‘real life’ zou verwachten. Deze data kun je includen op de volgende manier:</p>
<pre><code>cy.server();
cy.route('GET', '/search/*', 'fixture:searchresult.json');
</code></pre>
<p><em>Fixtures</em> kunnen ook als alias worden ingeladen. Voordeel hiervan is dat je de data nog bijvoorbeeld zou kunnen manipuleren voordat je het als response teruggeeft:</p>
<pre><code>cy.server();
cy.fixture('searchresult.json').as('searchJSON')
cy.route('GET', '/search/*', '@searchJSON');
</code></pre>
<p>Niet alleen van <em>fixtures</em>, maar ook van de <code>cy.route()</code> kan een alias gemaakt worden waardoor er verder in je code naar verwezen kan worden. Bijvoorbeeld om aan te geven dat er gewacht moet worden:</p>
<pre><code>cy.route('GET', '/search/*').as('search');
cy.wait('@search'); //Wacht op response van de zoek call
cy.get('h2').should('contain', 'Gevonden resultaten'); //Ga verder
</code></pre>
<h2>Redt Cypress mijn gourmet?</h2>
<p>Een doorgewinterde expert in Cypress ben ik nog niet, maar na een tijdje werken ben ik nog steeds enthousiast over dit (gratis) product.</p>
<p>Behalve de al beschreven mogelijkheden biedt Cypress nog heel veel meer. Zo kan Cypress worden toegevoegd aan je Continuous Integration proces. In <a href="https://docs.cypress.io/guides/guides/continuous-integration.html#Examples">de documentatie van Cypress over continuous integration</a> kun je tal van voorbeelden vinden voor providers als Bitbucket, Docker, GitLab en Jenkins. Het <a href="https://dashboard.cypress.io/">Cypress Dashboard</a> geeft overzicht van alle uitgevoerde tests.</p>
<p>Ook zijn er verschillende plugins beschikbaar om bijvoorbeeld screenshots te vergelijken en is er ook aan <em>code coverage</em> gedacht. Kortom: er is nog genoeg te ontdekken over het testen met deze tool.</p>
<p>Natuurlijk is het niet alleen maar rozengeur en maneschijn. Zo kunnen tests alleen in Javascript geschreven worden. Voor Front-end developers natuurlijk geen probleem, maar voor andere developers misschien wel een reden om voor een ander framework te kiezen. Wat mij betreft het grootste minpunt van Cypress is dat er (op dit moment) alleen getest kan worden in Chrome of Electron. Cross-browser testen voor bijvoorbeeld Edge en Firefox is er dus helaas nog niet bij.</p>
<p>Maar ondanks dat kan Cypress bij veel projecten een groot deel van de kopzorgen die je als developer kan hebben wegnemen. Het zorgt er in ieder geval voor dat ik komende kerstdagen met een gerust hart nog een stukje kip en champignon in mijn pannetje gooi…</p>
<h3>Pieter Beekman</h3>
<img src="https://www.fronteers.nl/_img//adventskalender/pieter(1).jpg" alt="Foto van Pieter" class="floating-portrait" />
<p>Pieter is frontend developer bij Dekbed Discounter en werkt hier aan diverse platforms. Met de andere frontenders probeert hij iedere dag (nog) betere conversies te behalen door het toepassen van betere, snellere en mooiere code. Als zijn VS Code even uitstaat speelt hij het liefste boardgames.
Pieters donatie gaat naar KiKa.</p>
</content>
</entry>
<entry>
<title>Hoe pak je de opbouw van een website aan?</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/hoe-pak-je-de-opbouw-van-een-website-aan"/>
<updated>2019-12-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/hoe-pak-je-de-opbouw-van-een-website-aan</id>
<content xml:lang="nl" type="html"><p>Het opbouwen van een website gaat meestal niet over één nacht ijs en vergt kennis en inzicht. Toch zijn er heel wat zaken die je ook zelf kan uitwerken.</p>
<h2>Stap 1: Bepaal jouw doelgroep</h2>
<p>Wanneer je je doelgroep helder hebt, kun je ook beter het doel van je website bepalen. Wanneer ouderen jouw doelgroep zijn, zullen zij niet snel online een afspraak inplannen, maar eerder telefonisch contact met je willen opnemen.</p>
<h2>Stap 2: Bepaal het doel van je website</h2>
<p>Wat wil je dat je bezoekers gaan doen? Wil je dat ze jouw blogposts gaan delen, wil je dat ze rechtstreeks een afspraak inplannen of wil je dat ze jou gaan bellen? Het kan natuurlijk ook zijn dat jouw website puur informatief wordt. Een schot voor open doel; Houd hierbij rekening met je doelgroep.</p>
<h2>Stap 3: Basiskennis</h2>
<p>Een pagina van een website is grofweg onderverdeeld in 3 onderdelen.</p>
<ul>
<li>De header is het bovenste deel van je website. Het is gelijk ook één van de belangrijkste onderdelen. Als je header niet goed of onlogisch is ingedeeld, dan zullen bezoekers afhaken en je pagina weer verlaten. Dat is natuurlijk niet wat je wilt! Zorg voor een goede indeling van je header. Begin met je logo en een duidelijk navigatiemenu. Je kan eventueel nog wisselen met je logo bijvoorbeeld links of rechts van het menu. Of juist boven het menu. Je header is in de basis op iedere pagina gelijk.</li>
<li>Content is het middelste gedeelte van je pagina. Hierin komt jouw verhaal, jouw oplossing voor het probleem van je klanten en jouw informatie. Dit gedeelte is op iedere pagina anders.Je content kan bestaan uit foto’s, teksten, tabellen, video’s etc. Maar maak er geen circus van.</li>
<li>De footer. Dit is het onderste deel van je website. Hierin staat je KvK nummer, privacyverklaring en copyright. Dit is voornamelijk bij een kleine footer. Bij een grote footer vind je vaak menu-items, inschrijving nieuwsbrief, Google Maps, social media pictogrammen, etc. Je footer is, net zoals je header, op iedere pagina gelijk. In de footer is onwijs veel mogelijk, maar bedenk wel dat de footer vaak het laatste is wat de bezoeker van je website ziet.</li>
</ul>
<p>Daarnaast is de Call To Action een belangrijk onderdeel. Een Call To Action (afgekort CTA) is een button waarmee je de bezoekers triggert om datgene te doen, wat het doel van jouw website is. Bijvoorbeeld: “Wil je in 10 weken 20 kilo afvallen?” Button: Download brochure. Of “Wil jij meer grip op je financiën?” Button: Ja, dat wil ik! Met bijvoorbeeld een link naar je online agenda of contactformulier.</p>
<h2>Stap 4: Brainstormen</h2>
<p>De brainstorm is bedoeld om zoveel mogelijk toffe ideeën op papier te krijgen over de inhoud van je website, je diensten en producten. Maar ook over het ontwerp en misschien zelfs wel over je marketing. Alles mag en niets is te gek.
Spui met een paar mensen zoveel mogelijk ideeën en zet ieder idee apart op een memo. Neem hier rustig de tijd voor en ga liever aan de keukentafel zitten dan relaxt op de bank.</p>
<h2>Stap 5: Categoriseren</h2>
<p>Na de brainstorm ga je alle ideeën categoriseren. Je gaat ze bundelen op A4’tjes. Je maakt een A4 voor de footer, de header en de content van de pagina’s. Wanneer je een aantal memo’s hebt waar bijvoorbeeld e-mail adres, contactformulier en adres op staat, kun je deze op een A4 plakken en deze Contact noemen. Dit wordt dan de content van de Contact-pagina. Inschrijving nieuwsbrief of een Instagramfeed wil je misschien wel in de footer. Ideeën over kleuren, lettertypes, beeldmateriaal, etc. kun je weer bij Design kwijt. Zo kun je structuur aanbrengen aan al je toffe ideeën.</p>
<h2>Stap 6: Menustructuur maken</h2>
<p>Nu je alles gecategoriseerd hebt, heb je in de basis ook de pagina’s die op je website komen. Het is belangrijk dat je pagina’s op een logische manier in het menu komen. Dit kun je het beste doen door het uit te tekenen in een Flowchart.
Je diensten kun je bijvoorbeeld op een pagina zetten, maar je kunt er ook voor kiezen om onder het kopje Diensten een submenu te maken. Diensten - Webdesign, Logo ontwerp, Huisstijl</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/marieke-webdesign-flowchart.png" alt="Voorbeeld van een flowchart" /></p>
<p class="note">
Voorbeeld flowchart
</p>
<h2>Stap 7: Bepaal de inhoud van je homepage</h2>
<p>Je homepage is de etalage van je website. Deze pagina is vaak anders van opbouw dan je overige pagina’s. Je bezoekers willen op je homepage kunnen zien:</p>
<ul>
<li>Wie je bent</li>
<li>Wat je doet</li>
<li>Wat je voor je bezoeker kan betekenen.</li>
</ul>
<p>De basis voor de opbouw van je website heb je nu staan. De volgende stap is het uitdenken van je huisstijl. Lettertypes, vormgeving en kleuren. Hier kan een grafisch vormgever je goed in adviseren.</p>
<p>Over Marieke
/adventskalender/marieke-webdesign.png
Marieke Kuit, dat ben ik. Aangenaam! Geboren en getogen in het pittoreske Noord-Hollandse Sint Maartensbrug. Waar ik heb geleerd normaal te doen, want dan doe ik al gek genoeg. Nuchter te zijn, hard te werken, maar vooral mezelf te zijn. Zonder opsmuk, gewoon puur.
Mariekes donatie gaat naar KiKa.)</p>
</content>
</entry>
<entry>
<title>Maak deze kerst een vriend blij met lekker makkelijke collapsibles</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/maak-deze-kerst-een-vriend-blij-met-lekker-makkelijke-collapsibles"/>
<updated>2019-12-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/maak-deze-kerst-een-vriend-blij-met-lekker-makkelijke-collapsibles</id>
<content xml:lang="nl" type="html"><p>Ik heb een paar vreemde gewoonten. Een ervan is dat ik op iedere website met een accordeon of een FAQ mijn code inspector even opengooi. Gewoon om te checken of de developers <code>&lt;details&gt;</code> en <code>&lt;summary&gt;</code> gebruikt hebben voor het open- en dichtklapgebeuren. Je zou namelijk wel gek zijn om deze handige HTML-elementen niét te gebruiken in 2019. Helaas moet ik in de meeste gevallen mijn code inspector hoofdschuddend weer sluiten.</p>
<p>Als jouw reactie nu <em>duh!</em> is, dan hoef je natuurlijk niet verder te lezen. Dan stuur je dit artikel gewoon naar een onfortuinlijke developer die collapsibles nog met de hand in elkaar puzzelt. Like an animal. Zo heb jij je goede decemberdaad gesteld, en hebben we samen het web weer een stukje makkelijker en toegankelijker gemaakt.</p>
<h2>Het open- en dichtklapgebeuren?</h2>
<p>Een collapsible is een dingetje dat je kunt open- en dichtklappen om informatie te tonen of te verbergen. Je vindt ze overal op het web: in FAQ’s, in formulieren en in de filternavigatie op webshops.</p>
<p>Moeilijk is het niet om ze te bouwen: je hebt een <code>onclick</code> event nodig, een snuifje CSS en enkele regels JavaScript om te <em>togglen</em>.</p>
<p>Maar er is meer: een <em>toegankelijke</em> collapsible moet je ook kunnen bereiken en bedienen met het toetsenbord. Bovendien moet een screenreader de <em>status</em> van de collapsible (open of dicht) kunnen oppikken. Daarvoor moet je met <code>aria-expanded</code> in de weer. Voor je het weet, voel je de verleiding om er een jQuery plugin tegenaan te gooien. Niet nodig.</p>
<h2>Lekker makkelijk</h2>
<p>Nieuw zijn ze niet, maar het heeft een tijd geduurd voor de ondersteuning in alle browsers goed werd. Daarom lijken sommige developers ze vergeten te zijn. Maak dus (opnieuw) kennis met <code>&lt;details&gt;</code> en <code>&lt;summary&gt;</code>:</p>
<pre><code>&lt;details&gt;
&lt;summary&gt;Wat is groen en heeft een gewei?&lt;/summary&gt;
&lt;p&gt;Een dophertje.&lt;/p&gt;
&lt;/details&gt;
</code></pre>
<p>Als je op <code>summary</code> klikt, kan je de vraag open- en dichtklappen. Geen JavaScript of CSS nodig en toegankelijk ‘out of the box’. Het werkt perfect in <a href="https://caniuse.com/#search=details">bijna alle browsers</a> en tot wanneer de Chromium-gebaseerde verse van Edge uit beta is, kan je nog steeds <a href="https://github.com/mathiasbynens/jquery-details">Mathias Bynens’ (allereerste) <code>detail</code> polyfill</a> uit 2012 gebruiken.</p>
<h2>Wacht! Kan ik zo’n collapsible ook opsmukken?</h2>
<p>Zeker. Je kan zowel de <code>summary</code> als de <code>details</code> prima stijlen en binnen de <code>summary</code> kan je je eigen markup gebruiken.</p>
<p>Als je geen fan bent van de standaard focus ring, kan je die vervangen door iets aantrekkelijkers. Zorg er wel voor dat je de focus ring niet weghaalt, want dat is heel vervelend voor gebruikers die de muis niet kunnen gebruiken.</p>
<p>Ik snap ook dat je heel graag het pijltje zélf wilt stijlen, want in de meeste browsers is dat standaard een zwart driehoekje. Ook dat is makkelijk:</p>
<pre><code>summary {
list-style-image: url(pijltje.svg);
}
</code></pre>
<p>Voor browsers die op Webkit zijn gebaseerd (zoals Safari), moet je wel even deze extra selector toevoegen:</p>
<pre><code>summary::-webkit-details-marker {
background: url(pijltje.svg);
color: transparent;
}
</code></pre>
<p>Wat helaas niet zo makkelijk kan, is het veranderen van de aanwijsrichting van je eigen pijltje. Als je dat echt wilt, moet je alsnog met JavaScript aan de slag, maar laat dat de pret niet bederven.</p>
<p>Lees meer <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary">over <code>details</code> en <code>summary</code> op MDN</a>.</p>
<h2>Over Roel van Gils</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/roel.jpg" alt="Foto van Roel van Gils" class="floating-portrait" />
Roel noemt zichzelf een Digital Accessibility Nerd. Met zijn bedrijf Eleven Ways (gevestigd in Gent) helpt hij overheden en bedrijven die hun websites en apps voor zoveel mogelijk mensen toegankelijk willen maken. Roel steekt ook wel eens een handje toe bij het organiseren van Fronteers-bijeenkomsten in Vlaanderen. Hij twittert als [@roelvangils](https://twitter.com/roelvangils).
Roels donatie gaat naar de Hersenstichting.
</content>
</entry>
<entry>
<title>Waarom een hobbyproject (niet) belangrijk is</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/waarom-een-hobbyproject-niet-belangrijk-is"/>
<updated>2019-12-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/waarom-een-hobbyproject-niet-belangrijk-is</id>
<content xml:lang="nl" type="html"><p>Veel developers kennen het wel: een hobbyproject om nieuwe dingen te leren, je mee uit te leven en andere dingen te kunnen programmeren dan in het dagelijkse werk vaak mogelijk is. Zeker met alle snelle veranderingen in de front-endwereld, is het een goede manier om 'bij te blijven'. Maar is het echt zo belangrijk om als front-end developer een hobbyproject te hebben?</p>
<h2>Waarom een hobbyproject belangrijk is</h2>
<h2>Om nieuwe ontwikkelingen te proberen</h2>
<p>Voor veel front-enders is ondersteunen van IE11 nog de dagelijkse praktijk. De realiteit is daarbij dat je niet zomaar nieuwe technieken kunt gebruiken zoals CSS Grid of ES6 - tenzij je <em>progressive enhancement</em> toepast of gebruik maakt van <em>postprocessors</em> en <em>transpilers</em>. Maar ook dan is het door legacy code of voor onderhoudbaarheid niet altijd realistisch om meteen de nieuwste ontwikkelingen in je werk toe te passen.</p>
<p>Een persoonlijk project, bijvoorbeeld een eigen website, is dan de ultieme <em>playground</em> om wel met nieuwe technieken aan de slag te gaan. Soms zien dat soort projecten nooit het daglicht, maar geven ze je wel de kans om iets uit te proberen en te besluiten of je dit in je werk wilt gaan gebruiken. Laten zien dat je iets al hebt uitgeprobeerd kan ook net dat zetje zijn dat je collega's nodig hebben om te besluiten het ook in werkprojecten te gebruiken.</p>
<h2>Je eigen klant zijn</h2>
<p>Voor je persoonlijke projecten ben je product owner en developer tegelijk. Jij bepaalt welke browsers je ondersteunt, welke tech stack je gebruikt en hoe het eruit gaat zien. Maar misschien ken je het spreekwoord wel: <em>doctors are the worst patients.</em> Ik denk dat we ook gerust kunnen zeggen: developers zijn de ergste product owners. Je hebt je nieuwe design nog niet live staan of je hebt alweer nieuwe ideeën over hoe de website eruit moet zien. En wat bezielde je een paar maanden geleden toen je voor die tech stack koos? Nu zou je het helemaal anders doen... Bij een hobbyproject zelf de eindverantwoordelijke en uitvoerder zijn, kan ervoor zorgen dat je opeens een stuk meer respect of begrip krijgt voor de klanten of product owners waar je in je werk dagelijks mee te maken krijgt.</p>
<h2>Geen restricties</h2>
<p>Er is niemand — nou ja, misschien je partner — die zegt hoeveel tijd je mag besteden aan het ontwikkelen van een nieuwe feature. Dat geeft je ook de mogelijkheid om helemaal uit te zoeken waarom iets niet werkt en waarom een bepaalde bug optreedt, waar in je werk wellicht besloten wordt om het dan maar anders te doen. Door het wel uit te zoeken, kan je veel leren.</p>
<p>Maar het tegenovergestelde is ook waar. In plaats van tot in de puntjes uit te zoeken waarom iets niet werkt, kun je ook besluiten dat goed genoeg, goed genoeg is. Vooral in situaties waarbij je je code voor een groot deel zou moeten refactoren om een kleine bug op te lossen, kun je voor je eigen projecten er ook voor kiezen dat die bug niet zo erg is. Een heerlijk bevrijdend gevoel soms.</p>
<h2>Nieuwe dingen leren</h2>
<p>Veel front-end developers hebben via hun werk wel ruimte om te leren, bijvoorbeeld om als UI developer meer over JavaScript te leren of juist als JavaScript developer meer over CSS. Maar als je graag een nieuwe taal wil leren en daar in je werk geen ruimte voor is, dan zijn hobbyprojecten bij uitstek geschikt. Het geeft je ook de mogelijkheid om niet-werkgerelateerde programmeertalen te leren. Misschien wil je wel leren om een Arduino of Raspberry Pi te programmeren of vind je het leuk om jezelf en je creativiteit op de proef te stellen met het ontwikkelen van een game.</p>
<h2>Waarom een hobbyproject niet belangrijk is</h2>
<h2>Nieuwe ontwikkelingen horen bij je werk</h2>
<p>Zoals gezegd gaan ontwikkelingen in het vakgebied van de front-ender soms razendsnel. Het is dan ook een onderdeel van ons werk om hierin mee te gaan. Niet veel van van ons zullen nog een <code>&lt;table&gt;</code> element gebruiken voor een layout. Als je bijvoorbeeld graag CSS Grid wil leren of op de hoogte wilt blijven van nieuwe JavaScript features, zou je dit niet in je vrije tijd hoeven doen. Het is goed als werkgevers deze ruimte voor persoonlijke en werkgerelateerde ontwikkeling bieden.</p>
<h2>Risico op een burnout</h2>
<p>Het kan zijn dat je hobby je werk is en dat is natuurlijk geweldig. Maar hoe leuk je je werk vindt, het is belangrijk om genoeg rust te hebben. Door in je vrije tijd ook met programmeren en nieuwe dingen bezig te zijn, kun je snel opbranden. Veel front-end developers voelen de druk om op de hoogte te blijven van alle nieuwe ontwikkelingen en werken om die reden aan hobbyprojecten. Vraag je bij projecten in je vrije tijd af of je eraan werkt omdat je het leuk vindt of omdat je het gevoel hebt dat het moet.</p>
<h2>Balans is belangrijk</h2>
<p>Of je nu wel of niet aan persoonlijke projecten werkt, is een keus die je voor jezelf moet maken. Laat je daarbij niet opjagen door bijvoorbeeld je werkgever of collega's. Developer zijn betekent niet dat je in je vrije tijd moet programmeren. Je werkgever zou je tijd moeten bieden om nieuwe dingen te leren, zodat jij je vrije tijd kunt gebruiken voor de dingen die je het liefste doet.</p>
<h2>Over Josee Wouters</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/josee-500x500.png" alt="Foto van Josee" class="floating-portrait" />
Josee werkt als developer bij Yoast en hoewel ze daar meer als een full-stack developer werkt, ligt haar hart (ook) bij front-end. Ze is actief als vrijwilliger bij Fronteers en werkt in haar vrije tijd af en toe aan haar app "What Dinner?".
Josee's donatie gaat naar Stem op een vrouw.
</content>
</entry>
<entry>
<title>Het belang van een style guide</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/het-belang-van-een-style-guide"/>
<updated>2019-12-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/het-belang-van-een-style-guide</id>
<content xml:lang="nl" type="html"><p>In de meeste organisaties waar ik heb gewerkt, is er wel een UX-designer aanwezig. Deze levert de designs aan waarin je duidelijk kunt zien hoe een UI is opgebouwd en vind je uitleg over hoe bepaalde elementen zich tot elkaar verhouden. Ook vind je vaak styleregels. Bijvoorbeeld welke fonts er gebruikt worden, welke fontgroottes moeten er worden toegepast en bij hoeveel woorden wordt een tekst afgekapt en toont er een 'read more' tekst. Allemaal zaken waar we als front-end developer vaak niet meer over hoeven na te denken. Toch zijn er een aantal zaken die van belang zijn als je een consistente UI wilt bouwen.</p>
<h2>Building blocks</h2>
<p>De User Experience designer heeft de verschillende kleurenpaletten geaccordeerd gekregen, de typografie uitgewerkt, en het iconenset aangeleverd. Nu is het nog van belang dat deze elementen consistent worden toegepast in de HTML en CSS. Om dit zo goed mogelijk voor elkaar te krijgen zijn style guides in het leven geroepen. Deze kunnen onderdeel uitmaken van een groter geheel, zoals een design system.</p>
<h2>CSS en HTML style guide</h2>
<p>Veel developers ontwikkelen een eigen stijl van het schrijven van hun code. Dit is in de basis helemaal niet erg. Zeker niet als het gaat om een project wat je in je eentje draait. Tot het moment daar is dat je werk van een collega moet overnemen. Bootstrap classes overheersen de HTML. Classnames als <code>row</code>, <code>col-sm-6</code> en <code>container-fluid</code>. Irritaties doemen op. Dat terwijl er bij de vorige vergadering nog geroepen is dat we geen Bootstrap grids meer toepassen sinds we Flexbox en CSS Grid breed geaccepteerd hebben in onze layouts.</p>
<p>Dit is een typische situatie waar een HTML/CSS style guide goed van pas kan komen. Een eerste stap om deze situatie in de toekomst te voorkomen zou zijn om een aantal regels vast te stellen. Regels omtrent het schrijven van je HTML en CSS. Dit hoef je vaak niet zelf te verzinnen, gezien er vele bedrijven zijn die al een style guide openbaar beschikbaar hebben. Deze zou je als een soort boilerplate kunnen gebruiken om je eigen regels vast te stellen. Een veelgebruikte <a href="https://github.com/airbnb/css/">CSS style guide</a> in ons vakgebied is die van AirBnB. Daarin wordt bijvoorbeeld vastgelegd dat een combinatie van OOCSS en BEM een geoorloofde methodiek is voor het schrijven van je CSS. Ook lezen we dat het gebruik van ID’s in je html een anti pattern is, gezien je hiermee te veel specificiteit in je HTML aanbrengt. Niet herbruikbaar dus. Zomaar een aantal regels uit deze style guide. Deze regels maken je codebase consistenter en dwingen jou en je collega's tot het schrijven van kwalitatievere code.</p>
<h2>Pattern libraries</h2>
<p>Een pattern library is een verzameling van alle designelementen voor een User Interface. Veel van deze patronen komen meerdere keren terug in een website. Een UI toolkit als <a href="https://fbrctr.github.io/demo/">Fabricator</a> of <a href="https://patternlab.io/demos.html">Pattern Lab</a> kunnen je helpen om documentatie over de geschreven code en patronen vast te leggen. Handig dus voor een nieuwe collega!</p>
<p>Andere goede eigenschappen van een pattern library?</p>
<ul>
<li>Het zal consistentie en cohesie aanbrengen in je codebase en uitstraling</li>
<li>Het versnelt je hele teams workflow, dus je bespaart tijd en geld</li>
<li>Meer samenwerking tussen alle disciplines binnen een projectteam</li>
<li>Creëer op deze manier een gedeelde taal die over meerdere disciplines gebruikt wordt</li>
<li>Het opbreken van een interface in herbruikbare componenten</li>
<li>Een goede style guide informeert het team over welke tools zij op het moment in hun gereedschapskist hebben zitten</li>
<li>Waarborgt documentatie om nieuwe collega’s of andere partijen snel up to speed te krijgen</li>
<li>Genereert regels omtrent het gebruik</li>
<li>Efficiënter onderhoud aan je codebase</li>
<li>Het maakt cross-browser/device, performance, en accessibility testen makkelijker</li>
</ul>
<h2>Design System</h2>
<p>Een pattern library en een CSS/HTML style guide maken onderdeel uit van het design system. Een design system is een compleet pakket met design en codestandaarden. Om deze standaarden waar te maken maak je gebruik van uitgebreide, aanwezige documentatie en codevoorbeelden. Een design system leidt in development teams daardoor vrijwel altijd tot een samenhangende, consistente gebruikerservaring voor de eindgebruiker van je website.</p>
<p>Bij mijn huidige opdrachtgever zijn we onlangs gestart met <a href="https://bradfrost.com/blog/post/atomic-web-design/">Atomic Design</a>. We gebruiken Pattern Lab als toolkit en we hebben strengere regels ingesteld als het gaat om schrijven van code. Door onze codestandaard strenger van elkaar te reviewen en te accorderen, denken we een goede basis te hebben gelegd voor een toekomstbestendige, consistente basis in onze codebase.</p>
<p>Maak jij in je huidige werk gebruik van een style guide en/of een pattern libary of zou dit juist goed zijn in de toekomst te gaan doen? Deel je ervaring!</p>
<h2>Over Sander</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/sanderlangendoen.jpg" alt="Foto van Kilian" class="floating-portrait" />
Ik ben Sander Langendoen. Freelance front-end developer. Momenteel werkzaam voor WPG Media en Uitgevers. Ik ben blij elke dag betaald mijn hobby te mogen uitvoeren.
Sanders donatie gaat naar de Hersenstichting
</content>
</entry>
<entry>
<title>Fronteers vote for the W3C Technical Architecture Group</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/fronteers-vote-for-w3c-tag"/>
<updated>2019-12-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/fronteers-vote-for-w3c-tag</id>
<content xml:lang="nl" type="html"><p>In January, W3C members are voting for four seats on the Technical Architecture Group. Since Fronteers is a W3C member, we also have a vote, which our representative Rachel Andrew will cast on behalf of us.</p>
<p>Just like half a year ago, we call all Fronteers members to share their list of top candidates. This time for the W3C Technical Architecture Group (TAG). The result of the internal Fronteers vote will be transmitted to Rachel.</p>
<p>This vote is only open to Fronteers members; if you're not a member you cannot vote.</p>
<p>The Fronteers Slack contains a #w3c-fronteers channel that is open only to members, and where questions can be asked and discussions can be held. Please ask for access in the general Fronteers channel or by a DM to a board member.
In this channel Rachel has also given her personal recommendation.</p>
<h2>The Technical Architecture Group</h2>
<p>The TAG is a special working group within the W3C, chartered with stewardship of the Web architecture. You can find out more about this group on the <a href="https://www.w3.org/2001/tag/">W3C TAG website</a>.
Web architecture refers to the underlying principles that should be adhered to by all Web components, whether developed inside or outside W3C. The architecture captures principles that affect such things as understandability, interoperability, scalability, accessibility, and internationalization. Further explanation can be found in the <a href="https://www.w3.org/2004/10/27-tag-charter.html">TAG Charter</a>.</p>
<p>There's also a blog in which members of the working group regularly provide updates. For example, earlier this year Hadley Beeman wrote an article entitled <a href="https://www.w3.org/blog/TAG/2019/05/30/our-ethics-drive-the-architecture-of-the-web/">Our ethics drive the architecture of the web</a> in which she explained how the members of the TAG influence the web we build on: &quot;A big part of our job as the TAG is to help spec authors with their ideas for a new feature on the web. We help them think about things like how their proposal could work with other features, whether it might have unintended consequences, and how they can learn from someone else’s similar experience.&quot; To help put the logic under their advice into a clear document, the group created a draft for <a href="https://w3ctag.github.io/ethical-web-principles/">Ethical Web Principles</a>.</p>
<h2>Candidates</h2>
<p>The four candidates for the three seats are:</p>
<ul>
<li>Rossen Atanassov (Microsoft Corporation)</li>
<li>David Baron (Mozilla Foundation)*</li>
<li>Kenneth Rohde Christiansen (Intel Corporation)*</li>
<li>Lukasz Olejnik (W3C Invited Expert)*</li>
</ul>
<p>An asterisk (*) indicates that the nominee is a current participant.
<a href="https://www.w3.org/2019/12/03-tag-nominations">All candidates provided statements on what they hope to achieve</a>.</p>
<h2>Voting procedure</h2>
<p>Fronteers members can mail their vote to secretaris@fronteers.nl. The vote should be an ordered list, with your personal top candidate coming first, your next candidate coming second, and so on.</p>
<p>After a membership check, your vote will be added to the general pool. Your top candidate will get 4 points, your second candidate 3 points, etc. If you do not include all four candidates on your list, the missing candidates will get 0 points.</p>
<p>Fronteers voting closes on Friday the 3rd of January at 24:00 o'clock. The Fronteers board will create an ordered list, with the first candidate being the one who received most points, then the one with the second-most points and so on. Rachel Andrew will break any ties.</p>
<p>Rachel will cast the Fronteers vote later that week, before the W3C deadline of 10th of January. W3C will announce the results on 14 January 2020.</p>
</content>
</entry>
<entry>
<title>Toegankelijkheid begint bij het eerste design</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/toegankelijkheid-begint-bij-het-eerste-design"/>
<updated>2019-12-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/toegankelijkheid-begint-bij-het-eerste-design</id>
<content xml:lang="nl" type="html"><p>Al bij het ontwerpen van een nieuwe site is het belangrijk om rekening te houden met toegankelijkheid. Als toegankelijkheidsonderzoeker kom ik bij het testen van websites vaak problemen tegen die al in de designfase zijn veroorzaakt.
Wanneer je als front-ender weet waar je op kunt letten, dan kun je al heel vroeg in het bouwproces de juiste vragen stellen aan designers. Zo kunnen veel problemen al voor de livegang opgelost worden. En is er veel minder reparatie achteraf nodig.</p>
<p>In dit artikel wil ik graag ingaan op een aantal punten die van belang zijn als je een design moet omzetten in een HTML-webpagina.</p>
<p><a href="https://www.fronteers.nl/nl/blog/2019/12/toegankelijkheid-begint-bij-het-eerste-design#de-onzichtbare-user-experience">De onzichtbare user experience</a>
<a href="https://www.fronteers.nl/nl/blog/2019/12/toegankelijkheid-begint-bij-het-eerste-design#de-zichtbare-user-experience">De zichtbare user experience</a>
<a href="https://www.fronteers.nl/nl/blog/2019/12/toegankelijkheid-begint-bij-het-eerste-design#afsluitend">Afsluitend</a></p>
<h2>De onzichtbare user experience</h2>
<p>Een design is heel visueel. Er zijn mooie schetsen gemaakt die tonen hoe de nieuwe site eruit moet gaan zien. Medewerkers van een designbureau zijn er vaak niet op getraind om rekening te houden met de user experience van mensen die slecht of niet kunnen zien.</p>
<p>Met name voor blinden, die het scherm helemaal niet kunnen zien en daarom werken met een screenreader, moet ook een structuur aanwezig zijn die zij kunnen gebruiken. Een soort onzichtbare user experience. Ontwerp je deze structuur goed, dan is hij ook nuttig voor andere soorten hulpapparatuur, zoals spraakbedieningssoftware.</p>
<p>Deze onzichtbare informatie is iets waar een designer prima rekening mee kan houden. Als developer kun je de informatie meenemen als je begint met bouwen. Nauw overleg tussen designer, developer en contentmanager is in deze startfase essentieel.</p>
<h2>Koppenstructuur</h2>
<p>Een goede koppenstructuur helpt je screenreadergebruikers enorm op weg. Zij kunnen een koppenlijst opvragen die fungeert als inhoudsopgave van de site. Zo navigeren zij snel naar de gezochte informatie op de pagina.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-eerste-design/koppenlijst-voiceover-homepage-volkskrant.png" alt="Screenshot koppenlijst VoiceOver, homepage Volkskrant, allemaal verkeerd gebruikte h4's en h3's" /></p>
<p class="note">
Een screenshot van een koppenlijst in VoiceOver, homepage volkskrant.nl
</p>
<p>Designers maken visueel wel koppen, maar denken vaak niet na over de kopniveaus. Het is ook de taak van contentmanagers of content designers om over dit soort informatiestructuren na te denken. Hebben ze dat niet gedaan, dan is het aan de developer of de toegankelijkheidsadviseur om vragen te gaan stellen.</p>
<h3>Wat is de h1 van deze pagina?</h3>
<p>Het is 'best practice' dat elke webpagina een h1 heeft die zegt waar de pagina over gaat. Dit hoeft niet de eerste kop van de pagina te zijn. Het kan bijvoorbeeld de eerste kop in het main-element zijn, die beschrijft waar de unieke content op deze pagina over gaat, bijvoorbeeld 'Paspoort aanvragen' op een gemeentesite, of de kop van het artikel op een nieuwssite.</p>
<h3>Zijn er kopniveaus overgeslagen?</h3>
<p>Sla geen kopniveaus over. Spring dus niet van <code>h2</code> naar <code>h4</code>. Een screenreadergebruiker kan snel het idee krijgen dat hij informatie mist.</p>
<h3>Staat alle content onder de juiste kop?</h3>
<p>Zorg ervoor dat alle content onder de juiste kop staat. Dit gaat vaak mis bij zogenaamde <em>'chapeaus'</em> (tekst boven kopjes). Zie bijvoorbeeld het screenshot hieronder. Hier zie je een nieuwsblokje van de homepage van <a href="https://www.volkskrant.nl/">de Volkskrant</a> en informatie uit de <a href="https://developer.mozilla.org/en-US/docs/Tools/Accessibility_inspector">toegankelijkheidsinspector van Firefox</a>.</p>
<p>Deze elementen zijn in het nieuwsblokje aanwezig:</p>
<ol>
<li>een afbeelding met <code>alt=&quot;Cruciale fase in impeachment-onderzoek: levert ambassadeur hét bewijs tegen Trump?&quot;</code> (Een kanttekening: Dit is een slechte alt-tekst, omdat hij informatie dubbelt en bovendien niet beschrijft wat er op de afbeelding te zien is (zes portretfoto's).)</li>
<li>een h4 met de tekst 'NIEUWS IMPEACHMENT TRUMP'</li>
<li>een h3 met de tekst 'Cruciale fase in impeachmentonderzoek: levert ambassadeur hét bewijs tegen Trump'?</li>
</ol>
<p>De afbeelding en de h4 vallen bóven de h3 die beschrijft waar dit blokje over gaat. Ze vallen dus in de koppenstructuur onder de h3 van het vorige blokje. Op het moment van schrijven was dat het kopje &quot;Manifestatie van start: ‘We schrijven geschiedenis!’&quot;, over de staking van ziekenhuispersoneel. Erg verwarrend.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-eerste-design/heading-levels-volkskrant.png" alt="Verkeerde koppenstructuur bij nieuwsblokje homepage Volkskrant, eerst h4 (chapeau) en dan h3" /></p>
<p class="note">
Een chapeau met h4 staat boven de kop met h3, volkskrant.nl
</p>
<h3>Moet dit wel een kop zijn?</h3>
<p>Koppen zijn nodig om de content eronder te beschrijven. Staat er geen content onder een kop, dan is een h-element niet op zijn plaats. Opnieuw: Een screenreadergebruiker kan het idee krijgen dat hij informatie mist als er wel een kop is, maar geen content.</p>
<h2>Semantische structuur</h2>
<p>Screenreadergebruikers hebben heel veel verschillende manieren om te navigeren. Naast koppenlijsten en linkslijsten zijn ook <em>landmarks</em> heel nuttig.</p>
<p>Denk bij het uitwerken van het design na: Wat is de <code>header</code>, <code>main</code>, <code>aside</code>, <code>footer</code>, <code>nav</code>, van deze pagina? En als er van een element meer dan één op de pagina voorkomt, hoe noem je ze dan? Je kunt ze een naam geven met <a href="https://www.w3.org/TR/wai-aria-1.1/#aria-label"><code>aria-label</code></a> of met <a href="https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby"><code>aria-labelledby</code></a>.</p>
<p>Denk erom: divs en spans betekenen niets voor hulpapparatuur! Voor toegankelijkheid is het altijd het beste om semantische elementen te gebruiken waar dat kan.</p>
<h2>Labels</h2>
<h3>Zichtbare labels</h3>
<p>In mijn ideale wereld hebben iconen, formuliervelden, knoppen, enzovoort, altijd een zichtbaar tekstlabel. Designers laten dit graag weg, omdat minder tekst zorgt voor een 'cleaner' ontwerp.</p>
<p>Maar als je spraakbediening gebruikt, hoe weet je dan hoe een formulierveld heet als het tekstlabel onzichtbaar is? Of stel, je bent cognitief beperkt. Hoe weet je dan waar al die iconen voor staan? Zelfs ervaren internetgebruikers kennen vaak de betekenis van een icoon niet, zoals blijkt uit de <a href="https://vimeo.com/251649861">Fronteers Jam Session</a> die Mallory van Achterberg hield.</p>
<p>Zichtbare labels zijn ook erg belangrijk voor bijvoorbeeld mensen met concentratieproblemen of een kort werkgeheugen. Placeholders verdwijnen, tooltips vallen niet altijd op. Je helpt iedereen met het invullen van een formulier door altijd zichtbare labels te plaatsen. Het is dan altijd mogelijk om nog een keer na te gaan wat je moet invullen in het veld waar je bent.</p>
<h3>Iconen</h3>
<p>Is het onontkoombaar om een icoon te plaatsen zonder tekst? De ervaring leert dat vaak vergeten wordt een tekstalternatief te bieden. Meestal kan dat prima met een <code>alt</code>-attribuut op de afbeelding, of met een visueel verborgen tekst in een <code>span</code>.</p>
<h3>Formuliervelden</h3>
<p>Als in het design echt geen zichtbare labels voor formuliervelden gewenst zijn, zorg er dan in ieder geval voor dat de labels wel bestaan en beschikbaar zijn in de toegankelijkheidslaag. En dat ze op de juiste manier gekoppeld zijn aan het betreffende veld.</p>
<p>Zorg ook voor een tekst voor knoppen, ook al zijn de teksten niet zichtbaar. Zo blijven ze bruikbaar voor mensen die de pagina niet kunnen zien.</p>
<h2>Skiplink</h2>
<p>Als je een website gebruikt met een muis, een touchpad of een ander point-and-click-apparaat, dan is het geen enkel probleem om snel het gewenste element te bereiken. Voor toetsenbordgebruikers die alleen een tabtoets tot hun beschikking hebben is het heel vervelend om steeds door herhalende blokken tekst heen te moeten navigeren. Tientallen keren de tabtoets indrukken is veel werk. Denk bijvoorbeeld aan alle links in een menu.</p>
<p>Omzeilende links (skiplinks) bieden hier vaak uitkomst. Mocht je je daar nog niks bij kunnen voorstellen, kijk dan bijvoorbeeld op de site van <a href="https://www.rijksoverheid.nl/">Rijksoverheid</a>. Gebruik je tabtoets om te navigeren. Als de pagina geladen is, verschijnt bij de eerste tab de skiplink met de tekst 'Ga direct naar inhoud'. Activeer je deze link, dan sla je het menu over en komt je toetsenbordfocus meteen in de inhoud van de pagina terecht.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-eerste-design/screenshot-skiplink-rijksoverheid.png" alt="Screenshot skiplink Rijksoverheid.nl" /></p>
<p class="note">
Zo ziet de skiplink eruit op Rijksoverheid.nl
</p>
<p>Omzeilende links zijn niet alleen handig voor de hoofdinhoud van een pagina, maar ook voor andere belangrijke plekken op de pagina, zoals de zoekfunctie, een blok met contactinformatie of een lijst met filters bij een zoekresultatenpagina. Er kunnen dus meerdere skiplinks bestaan die leiden naar verschillende belangrijke onderdelen van een pagina.</p>
<p>Een skiplink wordt door een designer vaak niet ontworpen. Vraag aan de designer dus hoe de skiplink eruit moet zien.</p>
<h2>De zichtbare user experience</h2>
<p>Een groot deel van de toegankelijkheidsproblemen bevindt zich in het zichtbare deel van de website, met name voor slechtzienden of kleurenblinden. Ook moet bij het bouwen van een site rekening worden gehouden met ziende toetsenbordgebruikers.</p>
<h2>Kleurgebruik</h2>
<p>Een goede contrastverhouding is nodig om alle informatie op de pagina te kunnen waarnemen. Slecht contrast is al jaren nummer 1 op de lijst met toegankelijkheidsproblemen. Toch zijn er nog altijd designers en huisstijlontwerpers die kiezen voor kleurpaletten met lichte tinten.</p>
<p>Al bij het ontwerpen van een nieuwe huisstijl zou iemand alert moeten zijn op de kleuren van bijvoorbeeld het logo. Hoewel logo's van de toegankelijkheidsrichtlijnen niet hoeven te voldoen aan contrasteisen, nemen mensen de kleuren wel vaak over bij het maken van bijvoorbeeld infographics of pdf's.</p>
<h3>Heeft deze tekst voldoende contrast?</h3>
<p>Meet in het design de kleuren van de teksten en hun achtergrond na met een kleurcontrasttool, bijvoorbeeld de <a href="https://developer.paciellogroup.com/resources/contrastanalyser/">Colour Contrast Analyser</a>.</p>
<p>Houd hierbij rekening met de <a href="https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html">juiste contrastratio's volgens WCAG</a>:</p>
<ul>
<li>Minimaal 4,5:1 bij gewone tekst</li>
<li>Minimaal 3:1 bij grote tekst (18pt of 14pt vet)</li>
<li>Denk eraan: De lettergroottes in WCAG zijn in punten. 14pt en 18pt zijn equivalent aan ongeveer 18.5px en 24px</li>
</ul>
<p>Je kunt bij de designer ook een lijst met gebruikte kleuren opvragen en deze in een <a href="http://contrast-grid.eightshapes.com/">kleurenmatrix</a> zetten. Hier zie je van verschillende kleurencombinaties of ze voldoen aan de vereiste contrastratio.</p>
<h3>Heeft dit interactieve element voldoende contrast?</h3>
<p>Sinds 2018 is er versie 2.1 van WCAG. Hierin is ook een eis opgenomen voor het <a href="https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html">contrast van interactieve componenten</a>. Dat wil zeggen dat ook knoppen, formuliervelden, en dergelijke duidelijk zichtbaar moeten zijn met behulp van voldoende contrast. Een ratio van minimaal 3:1 is hier vereist.</p>
<p>De eisen zijn een beetje ingewikkeld, maar het is wel de moeite waard om je hierin te verdiepen. Het gaat immers om de bruikbaarheid van de site. Kan iemand iets niet zien, dan kan hij het ook niet gebruiken.</p>
<h3>Een hoogcontrastknop, moet dat echt?</h3>
<p>Nog altijd zijn er designers en opdrachtgevers die denken dat een ontwerp met slecht contrast geen probleem is, als je maar een hoogcontrastknop op je site zet. En strikt genomen valt er tijdens een toegankelijkheidsonderzoek niets af te keuren wanneer er een goed functionerende hoogcontrastknop op een site staat.</p>
<p>Toch zijn er een paar grote bezwaren tegen een hoogcontrastknop. Allereerst is het niet gebruiksvriendelijk. Mensen die de knop nodig hebben moeten hem eerst zien te vinden, en dat kan een uitdaging zijn als je slechtziend bent. Daarnaast vergt het veel extra werk om een tweede stylesheet te maken voor hoog contrast. Het kost bovendien meer onderhoud.</p>
<p>Een hoog contrastknop is symptoombestrijding. Als je hem nodig hebt, betekent dat dat je een ontoegankelijke huisstijl hebt. Het levert je ook problemen op met pdf’s, powerpoints et cetera. Als toegankelijkheidsonderzoeker vind ik vrijwel altijd plekken in een site waar het contrast niet in orde is, ook al staat de hoogcontrastknop aan. Het beste is om één versie van de stylesheet te maken met kleuren die voldoende contrast hebben.</p>
<h3>Moet je kleur kunnen zien om iets te snappen?</h3>
<p>Informatie op een site moet niet alleen aan de kleur herkenbaar zijn. Denk bijvoorbeeld aan links in lopende tekst. Designers vinden onderstreping van links vaak niet mooi, maar het helpt je bezoekers enorm als ze links goed kunnen herkennen.</p>
<p>Ook in bijvoorbeeld grafieken is het belangrijk dat de informatie ook te begrijpen is als je kleuren niet (goed) kunt onderscheiden.</p>
<h2>Focus- en hoverstijl</h2>
<p>Bij het ontwerpen van een site wordt vaak niet gedacht aan de focus- en hoverstijl. Met name de focusstijl moet voldoende duidelijk zijn voor toetsenbordgebruikers. Zij kunnen zo zien waar zij zijn op de pagina.</p>
<p>Heeft een designer geen focus- en hoverstijl ontworpen, vraag er dan om. Zet voor focus zeker geen <code>outline: none;</code> in je CSS zonder een vervangende stijl te schrijven.</p>
<h2>Responsive design</h2>
<p>WCAG 2.1 heeft een <a href="https://www.w3.org/WAI/WCAG21/Understanding/reflow.html">succescriterium 1.4.10 Reflow</a>. Dit succescriterium gaat uit van een viewport van 320 CSS pixels breedte. Houd hier rekening mee wanneer wordt ontworpen en gebouwd wordt voor mobiel, zodat horizontaal scrollen niet nodig is en er geen functionaliteit verdwijnt.</p>
<h3>Foutmeldingen in formulieren</h3>
<p>Vaak wordt door designers niet gedacht aan het ontwerpen van een formulierstijl, met name foutmeldingen. Het is voor ziende gebruikers belangrijk dat de foutmeldingen niet alleen in kleur worden weergegeven en dat de kleuren die worden gebruikt, voldoende contrast hebben.</p>
<p>Denk ook na over wat de ervaring wordt voor blinde gebruikers: Hoe gaan zij weten dat er iets niet klopt? Karl Groves legt op zijn blog uitgebreid uit hoe je <code>aria-describedby</code> kunt gebruiken voor <a href="https://karlgroves.com/2011/10/10/accessible-form-labeling-instructions">toegankelijke foutmeldingen</a>.</p>
<h2>Afsluitend</h2>
<p>Natuurlijk is er nog veel meer te vertellen over design en toegankelijkheid. Zeker de wat complexere gevallen verdienen veel meer aandacht dan in dit artikel past.</p>
<p>Harris Schneiderman gaf eind november een webinar met de titel <a href="https://www.youtube.com/watch?v=5gFSru8yGaU">'Translating Design Wireframes into Accessible HTML/CSS'</a> voor Smashing Magazine. Wil je meer weten over tabvolgorde, roles, accessible names, values/states en focusmanagement, kijk dan vooral die video.</p>
<p>Voor een <a href="http://iacobien.nl/artikelen/contrast-van-tekst-met-achtergrondkleur-op-een-toegankelijke-site/">zeer uitgebreid artikel over contrast</a> kun je kijken op de site van mijn collega Iacobien Riezebosch.</p>
<p>Vragen kun je altijd stellen in het accessibility-kanaal van de <a href="https://fronteers-slack.herokuapp.com/">Slack van Fronteers</a>.</p>
<h2>Over Marjon</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-eerste-design/marjon-bakker.jpg" alt="Foto van Marjon" class="floating-portrait" />
Marjon Bakker is sinds 2017 adviseur digitale toegankelijkheid bij [Firm Ground](https://www.firmground.nl). Zij werkt het liefst op het snijvlak tussen communicatie en frontend development, met oog voor bruikbaarheid van websites voor alle bezoekers. Ze heeft zich gespecialiseerd in technisch onderzoek en het uitwerken van praktische oplossingen voor developers en opdrachtgevers. Haar toegankelijkheidswerkzaamheden sluiten goed aan en bouwen voort op haar eerdere werkervaring als webredacteur en communitymanager.
Marjons donatie gaat naar Bits of Freedom.)
<h4>Contact</h4>
<ul>
<li><a href="mailto:marjon@firmground.nl">marjon@firmground.nl</a></li>
<li><a href="https://www.linkedin.com/in/marjonbakker/">LinkedIn</a></li>
<li><a href="https://twitter.com/MarjonBakker">Twitter</a></li>
</ul>
</content>
</entry>
<entry>
<title>WordPress for developers who hate WordPress</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/wordpress-for-developers-who-hate-wordpress"/>
<updated>2019-12-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/wordpress-for-developers-who-hate-wordpress</id>
<content xml:lang="nl" type="html"><p>WordPress is now over sixteen years old. In those sixteen years it’s grown to power over 33% of the ten million most popular websites. And yet, the most popular system for publishing websites is one of the most hated systems for developers. At least according to the Stack Overflow developer survey who ranked WordPress as the most dreaded platform to work with this year. It has been in the top three for years now.</p>
<p>WordPress has a reputation among developers that it’s cumbersome, slow to load and insecure. This is true in a lot of cases, but I’d like to show you that it is possible to build modern and easy to maintain websites, plugins and themes with WordPress.</p>
<p>This article is divided into four parts:</p>
<ol>
<li><a href="https://www.fronteers.nl/nl/blog/2019/12/wordpress-for-developers-who-hate-wordpress#why-should-you-still-care-about-wordpress">Why should you (still) care about WordPress?</a></li>
<li><a href="https://www.fronteers.nl/nl/blog/2019/12/wordpress-for-developers-who-hate-wordpress#wordpress-modern-parts">WordPress’ modern parts</a></li>
<li><a href="https://www.fronteers.nl/nl/blog/2019/12/wordpress-for-developers-who-hate-wordpress#how-to-get-around-all-that-other-legacy">How to get around all that other legacy?</a></li>
<li><a href="https://www.fronteers.nl/nl/blog/2019/12/wordpress-for-developers-who-hate-wordpress#why-should-you-still-care-about-wordpress">The last remaining caveats</a></li>
<li><a href="https://www.fronteers.nl/nl/blog/2019/12/wordpress-for-developers-who-hate-wordpress#conclusion">Conclusion</a></li>
</ol>
<p>So if you’re either stuck working on a WordPress website, or you think that a huge part of the web shouldn’t be a blind spot in your knowledge; it’s time to pay attention.</p>
<h2>Why should you (still) care about WordPress?</h2>
<p>WordPress’ market share is an obvious reason to keep an eye on it. It’s the most used CMS by far, and that’s because it’s easy to set up, relatively cost-effective and because it’s widely supported by developers, agencies and hosting companies. This ease of use attracts a lot of people clicking together a site. And while this is a perfectly valid way to get a site up and running, it isn’t what most developers are looking for in a platform. The fact that WordPress is used this way, however, doesn’t mean it <em>has</em> to be used this way.</p>
<p>WordPress is the biggest content-creating platform where you are still owner of your own content. A service like Medium, for instance, is currently using other people’s content to sell their subscriptions. It’s one of the reasons why Signal vs Noise, the well-known blog by the people at Basecamp, switched back to WordPress. It’s also the reason many big content corporations like Time and CNN are fans of the platform.</p>
<p>If content ownership isn’t important to you, maybe money is: Premium WordPress themes and plugins are million to billion dollar markets. While the products are relatively cheap, they’re sold to a large volume of clients. A big bonus is that these clients are getting more used to subscription models. This means that they are getting comfortable in continuously paying for updates and support on the plugins and themes they buy, making premium WordPress themes and plugins a very stable business.</p>
<p>WordPress is committed to backwards compatibility; they don’t want to break millions of websites. If you’re new to developing for WordPress this can be the cause of a lot of development grievances. It can definitely make your initial development-run a lot harder. But that backwards compatibility also has a positive effect: after the initial build time your project will require a lot less updates to stay compatible. This is true for websites, but also for plugins and themes. As a testament to this feature: I personally had to update a WordPress website that was running version 2.9, which was ten years old at the time. The website kept running without issues after I updated everything. That’s pretty remarkable in a world where an <code>npm update</code> command will probably break my application.</p>
<h2>WordPress’ Modern Parts</h2>
<p>In 2013 a strapping young WordPress developer by the name of Ryan McCue started working on a modern REST API for WordPress. Although It wouldn’t be added into WordPress core until much later, this would prove to be the spark for much of WordPress’ modern nuts and bolts.</p>
<h2>REST API</h2>
<p>The WordPress REST API allows you to basically do anything with WordPress’ content, media and settings in a predictable and RESTful way. It’s a breath of fresh air for anyone who’s accustomed to the many different PHP-based API’s that WordPress offers. Requests are made to endpoints using a request method and output is provided in the form of JSON objects. Authentication for the baked-in endpoints happens automatically.</p>
<p>Now the endpoints that come shipped with WordPress core are pretty basic. Content-wise they only allow you to fetch the default post-types (posts and pages). Luckily adding a new endpoint doesn’t require a lot of code:</p>
<pre><code>namespace MyPlugin;
class Endpoint{
/**
* Register this endpoint
*/
public function register(){
register_rest_route(
'my-plugin/v1',
'/my-endpoint',
[
'methods' =&gt; 'GET',
'callback' =&gt; [ $this, 'callback' ]
]
);
}
/**
* Provide the callback
*/
public function callback(){
return 'Hello World!';
}
}
</code></pre>
<p>In this example we register an endpoint called “my-endpoint” in the REST namespace “my-plugin”. This means that when we make a GET request to the url <code>https://example.com/wp-json/my-plugin/v1/my-endpoint</code>, we’ll get the “Hello World” string back.</p>
<p>The callback can return pretty much anything you’d like. Anything more complicated than a string will automatically be converted into a JSON response.</p>
<p>If you like to process POST, PULL or DELETE requests, you can just change the method you’ve registered the rest route with:</p>
<pre><code>/**
* Register this endpoint
*/
public function register(){
register_rest_route(
'my-plugin/v1',
'/custom-delete-function',
[
'methods' =&gt; 'DELETE',
'callback' =&gt; [ $this, 'callback' ]
]
);
}
/**
* Provide the callback
*/
public function callback( \WP_REST_Request $request ){
$params = $request-&gt;get_json_params();
if( wp_verify_nonce( $params['my_nonce'], NonceHelper::DELETE_ACTION ) ){
wp_delete_post( $params['post_id'] );
}
return null;
}
</code></pre>
<p>This example adds a DELETE Rest-method and checks if the nonce accompanying the request is valid with a class called <code>NonceHelper</code>, that isn’t included in this example. If the nonce is valid, it deletes the post as requested.</p>
<p>If GraphQL is more your jam, you can also look into <a href="https://www.wpgraphql.com/">WP GraphQL</a>, which adds a full GraphQL to your installation. It's well documented and very developer-friendly.</p>
<h2>Modern Javascript in WordPress</h2>
<p>Built on top of this REST API is a layer of modern JavaScript. Automattic, the company behind the dot-com version of WordPress, started moving the entire WordPress admin interface for their platform over to a REST-api powered React app in 2014. They released this app as a completely open source project called <a href="https://github.com/Automattic/wp-calypso">Calypso</a>.</p>
<p>Although the project is very popular and sees continued improvement, it will not be added to WordPress core. It’s a separate app for managing your WordPress site. So if you’re creating a new website and you’re looking for a solid CMS but with a modern and extendable interface, you might be right picking Calypso and WordPress.</p>
<p>However, Calypso is only a small part of how modern JavaScript found it’s way into WordPress. The big project in this space currently is the relatively new WordPress editor dubbed “Gutenberg”.</p>
<h2>Gutenberg</h2>
<p>Matt Mullenweg, co-founder of WordPress, announced this full JavaScript content editor based on React components during his keynote at Europe’s biggest WordPress conference in 2017. The deadline of December 2017 proved to be overly ambitious and eventually got pushed back a full year. The current version of Gutenberg available in WordPress is stable and fast. Like any piece of software, though, Gutenberg has its fair share of open issues, it will continue to see big improvements over the coming years.</p>
<p>It’s being developed as a WordPress plugin and will get committed to WordPress core incrementally. That way it’s a lot easier for both the core and Gutenberg teams to keep iterating. It’s really build with extensibility in mind. The editor revolves around blocks of content that the admin user specifies. Adding or removing blocks for certain types of content is relatively easy, if you’re familiar with modern JavaScript and React. Here’s an example of a custom Gutenberg block:</p>
<pre><code>//fetch certain functions and components from
//core WordPress JS libraries:
const { registerBlockType } = wp.blocks;
const { __ } = wp.i18n;
const { RichText } = wp.editor;
registerBlockType(
'namespace/block',
{
title: &quot;__( 'Custom Block', 'namespace' ),&quot;
description: __( 'Adds a custom block', 'namespace' ),
category: 'common',
attributes: {
hello: {
type: 'string',
selector: 'h4',
default: 'Hello World'
}
},
edit( props ){
const { attributes: { hello }, className, setAttributes } = props;
return (
&lt;section className={ className }&gt;
&lt;RichText
tagName=&quot;h4&quot;
value={ hello }
placeholder={ __('Write your hello world', 'namespace') }
onChange={ (value) =&gt; setAttributes({ hello: value }) }
/&gt;
&lt;/section&gt;
)
},
save( props ){
const { attributes: { hello }, className } = props;
return (
&lt;section className={ className }&gt;
&lt;h4&gt;{hello}&lt;/h4&gt;
&lt;/section&gt;
)
}
}
);
</code></pre>
<p>In this example we use the native function of <code>registerBlockType</code> to create a “Hello World” block. The only thing this block does is create an input with the default value “Hello World” and echo that input’s eventual value in a <code>&lt;section&gt;</code> and <code>&lt;h4&gt;</code>.</p>
<p>Let’s loop through that code really quick:</p>
<ol>
<li>It registers the block with a certain title and description. It also adds it to a block category</li>
<li>It lists all attributes of the block. In this case a string by the name of ‘hello’</li>
<li>It renders a field in the <code>edit()</code> function, dictating what to show in the WordPress admin</li>
<li>It renders the section in the <code>save()</code> function, telling WordPress how to save the data in this block.</li>
</ol>
<p>You may have noticed the reference of the <code>&lt;RichText&gt;</code> component. This is an example how you can easily add your own (React) components to Gutenberg for custom functionality and extensibility. You could always break down the <code>edit()</code> and <code>save()</code> function into smaller components if they get too complicated, for instance.</p>
<p>For getting to know Gutenberg’s new APIs and gizmos I’d recommend <a href="http://gutenberg.courses/">the Gutenberg development course by Zac Gordon</a>. I also created a simple <a href="https://github.com/lucprincen/my-plugin">boilerplate plugin to write your own Gutenberg blocks, which can be found on Github</a>.</p>
<h2>WP CLI</h2>
<p>WP CLI is a command line tool for WordPress. It was started in 2011 by <a href="https://scribu.net/">Cristi Burcă</a> and within a year was a very popular project in the WordPress ecosystem. It allows you to do everything the WordPress admin UI can do and more, all from the comfort of your command line. The best part about WP CLI is that you’re able to chain commands together and, for instance, update all plugins at once, regenerate all media files to work with new crops or flush those pesky rewrites. If you’re considering working with WordPress again, I would always include WP CLI in your toolbox.</p>
<p>Just as Gutenberg, WP CLI was build with extensibility in mind. I include some custom WP CLI commands in most of my projects nowadays. These commands either simplify development or automate certain tasks, like fetching data from an external API.</p>
<p>Here’s an example of a WP CLI class registering two commands:</p>
<pre><code>namespace MyPlugin\Cli;
use WP_CLI;
use WP_CLI_Command;
/**
* Register the various WP CLI commands
*/
class Register extends WP_CLI_Command{
/**
* Migrate database tables
*
* @return void
*/
public function migrate()
{
( new \MyPlugin\Database\Migrations() )-&gt;run();
}
/**
* Fetch external data plugin
*
* @return data
*/
public function fetch_data()
{
( new \MyPlugin\Api\Controller() )-&gt;fetch_data();
}
}
WP_CLI::add_command( 'myplugin', 'MyPlugin\Cli\Register' );
</code></pre>
<p>This example adds the command <code>myplugin</code> to your WP CLI command list. It registers two sub-commands <code>migrate</code> and <code>fetch_data</code>, which are just the function names of this class. Both those functions neatly defer their work to different classes. If you have tasks in the WordPress admin that can be automated, or triggered by a single button-click, it’s worth writing a small command for them, so you can quickly run them from the terminal.</p>
<h2>How to get around all that other legacy?</h2>
<p>Despite of all the modern JavaScript and a consistent and easy way to handle your data-streams, WordPress is still a legacy system build upon a sixteen-year old foundation. We need some outside help to get around all of this aging technology.</p>
<h2>Embracing modern PHP</h2>
<p>Just like WordPress, PHP doesn’t have a good name when it comes to modern development. It’s still widely known as the tinkering script-kiddy language it was ten years ago. Lucky for us, PHP has made great strides in the past couple of years. Ever since 5.3 we’ve got a full and modern OOP stack with namespaces, interfaces and abstract classes. And that has only gotten better with the various PHP 7 releases.</p>
<p>The examples used earlier in this article all are set up with namespaces and structured in a modern way, a thing still sorely lacking in most code examples in the WordPress docs. If you’d like to change that, the <a href="https://make.wordpress.org/docs/">WordPress docs team</a> is always looking for talented people to update documentation.</p>
<p>Stuff like <a href="https://thewebtier.com/php/psr4-autoloading-php-files-using-composer/">autoloaders based on namespaces</a>, proper <a href="https://phpunit.de/">php unit testing</a> along with <a href="https://github.com/fzaninotto/Faker">fake data</a> are all becoming commonplace among PHP developers.</p>
<h2>Dependency management with Composer</h2>
<p>Another great addition of modern PHP is the use of dependency management. Composer is an open source project that enables you to load in different PHP libraries for use in your own project. Most of the available open source packages are available via Packagist. WordPress plugins that are available in the public WordPress plugin directory are automatically available in Composer via the excellent <a href="https://wpackagist.org/">wpackagist</a> service. Most of your other required (legacy) packages can be loaded in through Composers’ VCS option.</p>
<p>There’s still an asterisk in working with composer in WordPress, though. This depends on the scope of what you’re trying to build, but a single plugin should deal with vendor packages in a different way than a full website project. One of the more interesting projects in this space is <a href="https://coenjacobs.me/projects/mozart/">Mozart by Coen Jacobs</a>, which tries to have all dependencies in a WordPress install play nice with each other.</p>
<h2>SVN to GIT</h2>
<p>The default code repository of WordPress is SVN. The entire plugin and theme repository runs on this, as do all (automated) updates in the WordPress interface. Personally, I don’t really like SVN. The tools and ecosystem surrounding SVN simply aren’t as good as the tools surrounding Git. Luckily there are plenty of workarounds available for this. If you’re planning on releasing a plugin to the WordPress repository, but you’d like to maintain it using Github, use the excellent <a href="https://github.com/10up/actions-wordpress">Github actions for WordPress by 10up</a>. If you don’t really like Github there’s other excellent options like this <a href="https://github.com/GaryJones/wordpress-plugin-svn-deploy">Git to SVN deploy script by Gary Jones</a>.</p>
<p>Getting this workaround up-and-running is a lot faster than waiting for WordPress core to start adopting Git, I can assure you that much.</p>
<h2>Deploying WordPress</h2>
<p>Deployments in the WordPress ecosystem still depend on (s)FTP for a large part of the community. It’s one of the reasons why WordPress is known as an amateur platform. But that doesn’t mean that SFTP is the only option for deployment. You’re more than welcome to use regular GIT for deploying your WordPress websites, for instance. Capistrano is another interesting option and there’s also plenty of bash-tools available that work with WP CLI.</p>
<p>There are a bunch of WordPress-only hosts that also have excellent deployment options, like <a href="https://wpengine.com/git/">WP Engine’s custom GIT option</a>, that also runs your tests and checks for compatibility issues with all other code that is running outside of your repo.</p>
<p>How you deploy really depends on how you handle updates within WordPress, so let’s look into that as well.</p>
<h2>Dealing with updates</h2>
<p>So the big question in dealing with updates is if you are okay with your users updating plugins themselves through the admin. Giving your users that option is a smart and safe thing to do if you know and trust the third-party code you’re working with.</p>
<p>If you’re not comfortable with handing over control of your stack to people logging into WordPress admin, then it’s possible to take that power away from them. However, stopping updates altogether isn’t a viable option due to security issues. In this case updates should regularly happen through the command-line or your deploys. In any case I’d recommend leaving third party code (like plugins) out of your repository and using either composer and git hooks or a WP CLI method to keep your website up-to-date. The best solution is definitely dependent on what you’re building and how many third party packages you would need.</p>
<h2>The last remaining caveats</h2>
<p>Despite all of these improvements to the WordPress ecosystem, there are still areas that will confront you with WordPress’ age and the fact that you’re working with legacy software. There really aren’t that many great solutions for these issues, but I’ll try to ease the pain as much as possible in this chapter.</p>
<h2>Data handling and database structure</h2>
<p>WordPress introduces thirteen database tables on install. It doesn’t provide a way for developers to create new ones and mainly focuses on adding APIs for dealing with the existing tables. WordPress suggests to put every piece of extra information surrounding posts, terms and users in so called <code>meta</code> tables. These tables contain an <code>id</code> to the original object, and a <code>key</code> and <code>value</code> field. This data model might be flexible, but it’s far from optimized and it will get abused in a lot of cases.</p>
<p>There are great options out there for creating your own data models on top of the existing ones. <a href="https://github.com/corcel/corcel">This library incorporating Laravel Eloquent into WordPress</a> comes to mind. There’s also a <a href="https://github.com/woocommerce/woocommerce-product-tables-feature-plugin">beta plugin available that will add custom database tables to Woocommerce</a> that greatly improves speed, but other than that there aren’t a lot of out-of-the-box fixes for this at the moment.</p>
<p>There’s a lot in development surrounding Gutenberg’s data handling that is pretty exciting though and seeing as Gutenberg is eventually going to dictate every aspect of WordPress, this will inevitably lead to better performance and a cleaner data-model. Just don’t hold your breath until then.</p>
<h2>The ecosystem</h2>
<p>Science-fiction writer Theodore Sturgeon was asked once why 90% of the science-fiction novels that got published where crap. To which he responded; “90% of everything is crap”. This idea is commonly referred to as “Sturgeon’s Law” and it is very much in effect when it comes to WordPress themes, plugins and other WordPress-related work.</p>
<p>This can give the entire ecosystem an amateur-feel and makes it really hard for people trying to figure out good WordPress-based solutions. There isn’t really a great answer for this except asking other people more familiar with WordPress.</p>
<p>Both the <a href="https://make.wordpress.org/chat/">international</a> and the <a href="https://nl.wordpress.org/team/">Dutch WordPress slack-channels</a> are filled with people who work with WordPress on a professional level. These channels are a great place to ask a question or two about which plugin is right for the job.</p>
<h2>Conclusion</h2>
<p>While WordPress is in a lot of ways an ancient piece of software, there are a lot of positive things happening in the WordPress ecosystem. It might be fun to completely write off WordPress due to its age, but its market share keeps growing. So why not look a bit further at WordPress’ modern bits and re-evaluate if this really can’t be part of your toolbox? If not, then no worries; at least you’ve read up on the newer capabilities of the platform and can make a more informed decision for your next project.</p>
<h3>About Luc Princen</h3>
<p>/adventskalender/luc-princen.jpg
Luc Princen is an independent developer and designer from The Netherlands specializing in WordPress and frontend development. He loves open source, elegant code, fast load times, Dungeons &amp; Dragons and playing the occasional (grand) strategy game. You can find him on Twitter with the handle <a href="https://twitter.com/LucP">@LucP</a>.
Luc's donation will go to Dutch charity <em>Stem op een Vrouw</em>.</p>
</content>
</entry>
<entry>
<title>Een andere manier</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/een-andere-manier"/>
<updated>2019-12-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/een-andere-manier</id>
<content xml:lang="nl" type="html"><p>De kracht van het internet is dat de technieken relatief eenvoudig te gebruiken zijn. Gedreven door het idee dat er binnen enkele seconden iets op het scherm moet staan lijkt het tegenwoordig noodzakelijk om een Single Page App op te tuigen die begint vanuit het neerzetten van placeholders, waarin vervolgens content wordt geladen vanuit GraphQL en REST API’s. Vergelijk dat eens met de eenvoud van weleer, waarbij je HTML en CSS kon uploaden met een FTP programma…</p>
<p>Weinig ontwikkelaars weten nog precies wat ze doen, met als prototypische voorbeeld het “deze-div-is-een-button” tot gevolg. Of de site werkt zonder JavaScript is iets wat naderhand bedacht wordt, bijvoorbeeld omdat iemand zich druk maakt om zoekmachines die geen JavaScript begrijpen. Het lijkt wel alsof JavaScript noodzakelijk is voor een optimale UX (voor animatie-liefhebbende 40-minners met goed zicht dan).</p>
<p>Maar kan waargenomen snelheid niet ook als “progressive enhancement” aangeboden worden? Als iets zonder JavaScript kan werken, moet het toch ook gewoon zonder kunnen werken. Maar pure HTML en CSS net zo snel laten reageren als een moderne “Single-Page-App” / Webpack-compilatie (als het eenmaal geladen is) is niet altijd even gemakkelijk. Je zit dan toch snel van pagina naar pagina te navigeren, waarbij die met wisselende snelheden reageren. Hoe los je dat dan op?</p>
<p>De twee technieken die ik in deze blog introduceer komen uit de wereld <a href="https://rubyonrails.org/">Ruby on Rails</a>. Dit is een “back-end framework”, maar deze bibliotheken zijn onafhankelijk van dit framework te gebruiken.</p>
<p>Een belangrijke pijler voor de ontwikkelaars achter Ruby on Rails — en dus ook deze projecten — is “convention over configuration”: liever dat iets direct goed werkt dan dat je dagen aan het sleutelen bent om alleen al de basis goed werkend te krijgen. Het is dan ook sterk geopinieerd. Werk ermee zoals het bedoeld is en je kunt je concenteren op de inhoud in plaats van bijzaken. Omdat het idee van progressive enhancement redelijk centraal in het gedachtegoed zit kan ik er goed mee leven.</p>
<p>De technieken die ik behandel zijn <a href="https://github.com/turbolinks/turbolinks">Turbolinks</a> (voor het sneller laten laden van volledige pagina’s) en het meer recente Stimulus (voor het verrijken van pagina’s). Beide zijn pragmatische keuzes en relatief kleine verbeteringen die geen gigantische koerswisseling betekenen ten opzichte van “traditioneel” ontwikkelen op basis van HTML en CSS.</p>
<h2>Turbolinks</h2>
<p>Turbolinks is conceptueel voor een webontwikkelaar wellicht het eenvoudigst te begrijpen van de twee technieken. Wat als je, wanneer je binnen dezelfde site navigeert — in plaats van de browser te vragen de hele pagina te verversen — je de te presenteren HTML pagina pakt en slechts de DOM nodes in de body vervangt (plus onder andere de titel). Het is een idee dat geïnspireerd is op <a href="https://github.com/defunkt/jquery-pjax">pjax</a>, maar pjax was afhankelijk van jQuery.</p>
<p>Met deze oplossing hoeven de CSS en JavaScript dan niet meer opnieuw gedownload en geanalyseerd te worden en je kunt bijvoorbeeld JavaScript aan <code>document</code> binden die langer leeft dan dat enkele pagina bezoek. Wanneer JavaScript aan staat vangt Turbolinks bijna onzichtbaar het openen van links af en toont wanneer mogelijk direct pagina’s uit de cache waardoor er bijna direct resultaat wordt getoond (welke bij een update wordt ververst). Geen JSON API’s of veranderingen op de server nodig. Een slimmigheid aan de voorkant die ‘traditionele’ websites sneller laat werken en tussentijds haperen van bijvoorbeeld externe lettertypen voorkomt.</p>
<h2>Implementatie</h2>
<p>Om Turbolinks te gebruiken voeg je deze regel toe aan de <code>&lt;head&gt;</code> van je HTML:</p>
<pre><code>&lt;script src=&quot;https://cdn.jsdelivr.net/npm/turbolinks@5.2.0/dist/turbolinks.js&quot; integrity=&quot;sha256-iM4Yzi/zLj/IshPWMC1IluRxTtRjMqjPGd97TZ9yYpU=&quot; crossorigin=&quot;anonymous&quot;&gt;&lt;/script&gt;
</code></pre>
<p><a href="https://www.npmjs.com/package/turbolinks">Turbolinks is ook een package in NPM</a>, dus je kunt ook je favoriete workflow gebruiken met <code>yarn</code> of <code>npm</code>.</p>
<p>Het is dan:</p>
<pre><code>$ npm install --save turbolinks
</code></pre>
<p>en om het te starten:</p>
<pre><code>var Turbolinks = require(&quot;turbolinks&quot;)
Turbolinks.start()
</code></pre>
<p>De eerste pagina aanroep zal met Turbolinks 9.4kB (met gzip) meer wegen.</p>
<p>Dat is het. Er zijn vervolgens wat opties om bijvoorbeeld expliciet aan te geven externe bronnen wél opnieuw moeten worden geladen en wanneer een bijzondere pagina niet geladen dient te worden (zoals op <a href="https://www.fronteers.nl/nl/blog/2019/12/(https://murb.github.io/turbolinks-stimulus-fronteers/geen_turbolinks.html)">mijn Turbolinks-demo</a>)</p>
<h2>En “Native”?</h2>
<p>Het leuke aan Turbolinks is dat er ook native implementaties mogelijk zijn events koppelen uit webpagina’s. Zo kun je relatief eenvoudig web-gestuurde semi-native apps bouwen. Het gaat echter te ver om hier diep op in te gaan.</p>
<h2>Demo</h2>
<p>Open de ‘<a href="https://murb.github.io/turbolinks-stimulus-fronteers/geen_turbolinks.html">geen Turbolinks' demo</a>. De menu items gebruiken wel Turbolinks na de eerste klik en wanneer je het netwerkverkeer bekijkt zie je het verschil. Helaas is het verschil met deze zeer compacte statische pagina’s lastig te zien, maar als de CSS, Javascript en andere zaken complexer worden en een pagina soms vertraagd wordt door bijvoorbeeld een database query dan is het verschil in snelheid goed te merken.</p>
<h2>Nadelen</h2>
<p>De twee belangrijkste nadelen zijn het ontbreken van een <code>document.load</code> en het feit dat de hele DOM wordt vervangen.</p>
<p><code>document.load</code> is vooral voor analytics-systemen en libraries zoals jQuery een aandachtspunt: alle functies die gebonden zijn aan events die standaard aangeroepen worden bij het laden van een pagina moeten mogelijk opnieuw worden gebonden aan events die Turbolinks stuurt bij het navigeren naar een andere pagina.</p>
<p>Een ander punt om in de gaten te houden is dat de volledige DOM relatief ‘dom’ wordt vervangen. Mooie overgangstransities zijn wat lastiger te doen, al zijn er <a href="https://github.com/turbolinks/turbolinks/issues/184#issuecomment-451688212">workarounds</a> te vinden die de eenvoudige werkwijze vervangen met een implementatie die de inhoud van de nieuwe en de huidige pagina-inhoud vergelijkt en netjes bijsnijdt waar nodig.</p>
<h2>Stimulus</h2>
<p>Turbolinks brengt op zich al meer een ervaring van een Single Page App zonder gelijk alles wat fijn is aan het maken van ‘traditionele’ pagina’s overboord te gooien, maar het is niet ideaal voor alles; soms wil je wat interactiviteit toevoegen.</p>
<p>Er zijn mensen die niet van frameworks houden. Maar wanneer je vaker van project wisselt is de kracht van een framework wel dat ze enige houvast bieden voor andere ontwikkelaars doordat ze goed gedocumenteerd zijn.</p>
<p>Terzijde: er zijn ook ontwikkelaars die liever dichter bij webstandaarden blijven en daarom bijvoorbeeld <a href="https://github.com/w3c/webcomponents/">WebComponents</a> omarmen. Ik weet het zelf zozeer nog niet en ben meer gecharmeerd van kleine, comfortabelere stappen: stappen die niet direct het vorige volledig breken zonder polyfills.</p>
<p>Stimulus is vooral een handvat om JavaScript-code consistent te laten werken: een logische ordening. Voor dat Stimulus er was en nadat ik gestopt was met jQuery, schreef ik al voor kleinere projecten veelal JavaScript die reageerde op data-attributen, maar wanneer er het aantal acties groter wordt is het onderhoud van een goede naamgeving toch wel lastig. En grotere JavaScript projecten waaraan ik werkte bestonden toch veelal uit de bekendere frameworks die zware maar algemeen bekende structuur oplegden, maar met code dat ook ergens weer wrong omdat het eigenlijk niet de manier is waarop ik het liefst front-end-code zou willen schrijven.</p>
<p>Toen ik Stimulus zag was het voor mij dus al snel een aha-moment, al moest ik nog even wachten voordat ik het concreet kon gaan gebruiken op een nieuw project. In plaats van mijn oude manier — waarbij ik acties koppelde aan DOM-nodes middels data-attributen, waarbij al die acties bestonden in dezelfde scope — middels een Controller structuur waarin een omsluitend element aangeeft welke Controller binnen dat element het gedrag bepaalt.</p>
<h2>Implementatie</h2>
<p>Wil je écht niets te maken hebben met Yarn en/of NPM (als je bijvoorbeeld even wilt experimenteren), doe dan:</p>
<pre><code>&lt;script src=&quot;https://cdn.jsdelivr.net/npm/stimulus@1.1.1/dist/stimulus.umd.js&quot; integrity=&quot;sha256-mUuPeK7DRsoSOwJJcvbcMgWsqAVPJs7X8K/h7NxXQj4=&quot; crossorigin=&quot;anonymous&quot;&gt;&lt;/script&gt;
</code></pre>
<p>Maar <a href="https://www.npmjs.com/package/stimulus">je kunt Stimulus dus ook gewoon op npm vinden</a>. Stimulus maakt je pagina een kleine 9,81kB zwaarder (met gzip). HTML en JavaScript zijn traditioneel gescheiden. In JavaScript definieer je een Controller:</p>
<pre><code>const application = Stimulus.Application.start()
</code></pre>
<pre><code>application.register(&quot;validator&quot;, class extends Stimulus.Controller {
static get targets() {
return [ &quot;name&quot; ]
}
method() {
// doe iets
}
}
</code></pre>
<p>(Ik gebruik hier de wat uitgebreidere syntax die werkt als je Stimulus hebt geladen via de <code>&lt;script&gt;</code>-tag)</p>
<p>En de HTML die erbij hoort kan iets zijn als:</p>
<pre><code>&lt;form data-validator=&quot;validator&quot;&gt;
&lt;label&gt;Naam
&lt;input
name=&quot;name&quot;
data-target=&quot;name&quot;
data-action=&quot;change-&gt;method&quot;
/&gt;
&lt;/label&gt;
&lt;/form&gt;
</code></pre>
<p>Op ieder <code>'change'</code> event dat het input-veld genereert wordt <code>method()</code> aangeroepen in de <code>'validator'</code>-controller.</p>
<p>Zoals <a href="https://stimulusjs.org/handbook/building-something-real">de makers van Stimulus ook al zeggen</a>:</p>
<blockquote></blockquote>
<p>Ze noemen dat <em>Resilient UI’s</em>. Ik weet niet of ze het boek <a href="https://resilientwebdesign.com/">Resillient Web Design van Jeremy Keith</a> hebben gelezen, maar het ademt dezelfde geest.</p>
<h2>Demo</h2>
<p><a href="https://murb.github.io/turbolinks-stimulus-fronteers/stimulus.html">Een Stimulus-demo is hier te vinden</a> en voel vrij om de broncode te bekijken.</p>
<h2>En nu verder?</h2>
<p>Ga vooral naar de website om meer te leren over <a href="https://stimulusjs.org/">Stimulusjs.org</a>. Moet je nu alles omgooien om alles met Stimulus te doen? Zeker niet.</p>
<h2>Tot slot</h2>
<p>Frameworks bepalen hoe je werkt. Dit kan soms bevrijdend zijn, omdat je er sneller door kunt werken en gemakkelijker kunt communiceren met je collega’s. Soms kan het echter ook beperkend zijn, omdat je een heel ecosysteem aan plugins en compilers in wordt getrokken waardoor je na iedere update vaak weer in configuratiebestanden bepaalde details zit te configureren omdat <em>weet jij veel</em>. Laat staan dat je tijd hebt om je druk te maken over het werkend houden van de isomorphic rendering-setup en toegankelijkheid.</p>
<p>De frameworks/bibliotheken/libraries — <em>hoe je het ook wilt noemen</em> — die ik in deze post heb geïntroduceerd zijn mijns inziens niet van die laatste categorie. Het zijn dusdanig kleine toevoegingen dat het in het frameworkgeweld van vandaag de dag bijna niet meer lijkt op te vallen. Turbolinks is bijna een onzichtbare verbetering wanneer je al gewend was om alle JavaScript-initialisaties niet op de <code>load</code> en/of <code>DOMContentLoaded</code>-events te binden (een gewoonte die er wellicht door jQuery in is geslopen). De bibliotheken bieden structuur, maar zijn ook overzichtelijk.</p>
<p>Besef ook dat veel van de grotere frameworks van grote organisaties komen. Grote organisaties hebben veelal andere problemen dan kleinere. Misschien lossen die frameworks ook wel problemen op die jij nooit zult ervaren. Groter is niet altijd beter.</p>
<h2>Verder experimenteren?</h2>
<p>Je kunt mijn demopagina’s clonen met git:</p>
<pre><code>git clone https://github.com/murb/turbolinks-stimulus-fronteers.git
</code></pre>
<p>Sorry, geen hot reloading, maar met bijvoorbeeld Python (<code>python -m SimpleHTTPServer 8000</code>) of Ruby (<code>ruby -rwebrick -e'WEBrick::HTTPServer.new(:Port =&gt; 4000, :DocumentRoot =&gt; Dir.pwd).start'</code>) kun je er snel mee experimenteren.</p>
<p>Over Maarten
<img src="https://www.fronteers.nl/_img/adventskalender/maarten.jpeg" alt="Foto van maarten" class="floating-portrait" />
Maarten Brouwers is freelance ontwikkelaar van webapplicaties. Heeft een liefde voor standaarden en het vinden van De Juiste Manier. Hij combineert dat graag met interesse voor de eindgebruiker, maar zit net zo lief diep in server side Ruby (veelal on Rails) code. Blogt onregelmatig op <a href="http://murb.nl/">murb.nl</a>.
Maartens donatie gaat naar Bits of Freedom.)</p>
</content>
</entry>
<entry>
<title>Hoe ik zelf een browser schreef</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/hoe-ik-zelf-een-browser-schreef"/>
<updated>2019-12-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/hoe-ik-zelf-een-browser-schreef</id>
<content xml:lang="nl" type="html"><p>Zelf een browser schrijven klinkt als een slecht idee, zeker als je zelf een front-end developer bent en dus helemaal geen C++ of andere native taal kent. Toch besloot ik een aantal jaar geleden om te kijken of ik het kon en ondertussen is mijn browser nu doorontwikkeld tot serieus product.</p>
<h2>Hoe kom je er op?</h2>
<p>In 2015 besloot ik, zoals veel web designers en developers, over te stappen van Photoshop naar Sketch. Al heel snel kon ik daar goed mijn weg in vinden en vooral de manier waarop je in Sketch <em>artboards</em> kon maken vond ik erg fijn, waarmee je designs van verschillende afmetingen naast elkaar kon zetten. Al snel had ik een indeling waarbij alle responsive varianten van een paginaontwerp naast elkaar stonden, waardoor ik een heel goed overzicht kreeg van wat ik nou eigenlijk aan het ontwerpen was.</p>
<p>En toen ging ik terug naar de browser, waar ik telkens maar één viewport kon zien en de hele tijd bezig was de afmetingen van de browser of de responsive design tools te veranderen. Je kon niet gemakkelijk even twee afmetingen met elkaar vergelijken en in vergelijking met Sketch voelde dat nogal karig.</p>
<p>Rond dezelfde tijd was ik aan het spelen met <a href="https://electronjs.org/">Electron</a>, een framework waarmee je desktop applicaties kunt maken met webtechnieken. Ik besloot om een prototype te ontwikkelen waarin je dezelfde website in meerdere viewports naast elkaar zag, net zoals mijn indeling in Sketch. Na een paar avonden klooien had ik iets wat al best fijn werkte:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/eigen-browser/screenshot-polypane-prototype.png" alt="Screenshot van het eerste prototype" /></p>
<p>Je kon er niet echt veel mee, maar je kon een URL invullen en die werd dan getoond in meerdere afmetingen. Best cool!</p>
<p>Electron bleek een goede keuze te zijn. Niet alleen was het daarmee mogelijk om met mijn bestaande kennis van webontwikkeling een ‘echte’ browser te maken, maar die browser gebruikte ook een up-to-date versie van Chromium en de Chromium developer tools. Hoewel je altijd in andere browsers moet testen, hoefde ik me er geen zorgen over te maken dat bepaalde webtechnieken niet werkte in mijn browser en kon ik de developer tools gebruiken die ik al gewend was.</p>
<p>Met dat prototype ging ik zelf werken en al snel merkte ik dat ik veel sneller ontwerpen kon implementeren omdat ik niet meer bezig was met het managen van mijn browserafmetingen en me enkel bezig hoefde te houden met de site. Dit verbeterde proces scheelde me uiteindelijk uren per week.</p>
<p>Door het zelf te gebruiken merkte ik ook wat ik miste en al snel begon ik functies toe te voegen: “standaard” browserfuncties zoals navigatie en het tonen van de paginatitel, het kunnen toevoegen van nieuwe schermen en de mogelijkheid om screenshots maken van alle schermen samen (ideaal om naar klanten te sturen).</p>
<p>Ik besloot de browser te delen met andere developers en al snel begon ik met hun feedback nieuwe dingen toe te voegen: het in en uit kunnen zoomen van alle schermen in de browser zoals je dat ook zo gemakkelijk in Sketch kan doen, standaard schermafmetingen gebaseerd op zowel populaire telefoons als de media queries van de site zelf, en het synchroniseren van scrollen en hovers tussen alle schermen (zodat als je in het éne schermpje iets deed dat ook in alle andere schermen gebeurde).</p>
<h2>Doorontwikkeling</h2>
<p>Met iedere functie die ik toevoegde begon ik me meer en meer af te vragen waarom andere browsers dit niet ook doen. Maar Chrome, Firefox en vrienden zijn helemaal niet voor ontwikkelaars gemaakt. Er zijn namelijk veel meer reguliere gebruikers, die helemaal nooit developer tools nodig hebben. Developers zijn stiekem maar een piepkleine doelgroep voor ze en hoewel de developer tools die de browsers hebben echt fantastisch zijn, wordt er in de rest van de browser simpelweg geen rekening met ontwikkelaars gehouden.</p>
<p>Door de feedback die ik op mijn browser kreeg was ik er inmiddels achter hoeveel beter een browser kan werken voor front-enders als de <em>hele</em> interface gericht is op hun werk. Hierdoor besloot ik mijn browser als serieus product aan te gaan bieden. Sinds het begin van dit jaar ben ik fulltime bezig met het doorontwikkelen en mijn ideeën en die van gebruikers te implementeren. Daar zijn nieuwe functies als full-page screenshots, live reloading en device emulation uit gekomen.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/eigen-browser/screenshot-polypane-now.png" alt="Screenshot van de browser nu" /></p>
<h2>Browsers kunnen zoveel meer</h2>
<p>Browsers kunnen veel meer doen voor front-end developers. Een browser heeft zoveel informatie over een site die handig is voor de developer die met een site bezig is, maar die informatie wordt nergens getoond. Denk aan welke responsive afmetingen je allemaal in je CSS gebruikt. Als dat er heel veel zijn of ze zitten dicht op elkaar, dan heb je waarschijnlijk de mogelijkheid om dit drastisch te versimpelen en je CSS beter onderhoudbaar te maken.</p>
<p>Veel functies die we nu door middel van allemaal losse scriptjes en tooltjes gebruiken — zoals live reloading, je site vergelijken met het goedgekeurde design en layout debugging met iets als <a href="http://pesticide.io/">Pesticide</a> — zijn veel toegankelijker en gemakkelijker te bedienen als ze direct in een browser zitten.</p>
<p>De browser weet ook veel over hoe toegankelijk een site is. Missende alt-teksten, onlogische kopvolgorde en onvoldoende contrast tussen tekst en achtergrond zijn allemaal problemen die je browser weet of kan berekenen. En als <em>renderer</em> kan je browser ook kleurenblindheid of andere visuele beperkingen simuleren.</p>
<p>Goede toegankelijkheid is minstens even belangrijk als een mooi responsive ontwerp en door bovenstaande functies prominent aan te bieden in mijn browser verwacht ik dat developers die functies eerder gebruiken. Nu hoeven ze niet van tevoren al te weten dat je kleurenblindheid kan simuleren of dat je met live reloading nooit meer op die reload-knop hoeft te klikken. Doordat de browser deze opties al in zich heeft kom je er mee in aanraking.</p>
<p>Natuurlijk ben ik niet de enige: ook Firefox heeft recentelijk een aantal mooie toegankelijkheidsfuncties toegevoegd. Nadeel blijft wel dat deze “verstopt” zitten achter een tabje in de developer tools en zo verborgen blijven voor de developers die daar niet zelf naar op zoek gaan.</p>
<p>Buiten deze functies zijn er zoveel dingen die voor developers belangrijk zijn waar je nu niet bij kan of diep voor in de developer tools moet duiken. Wat dacht je van een mooi overzicht van je cookies en localStorage? Of informatie over je HTTP-verbinding. Misschien gaat iedere link op je site via een 302 redirect omdat je slashes op een andere manier gebruikt dan de server. Als front-end developer wil je dat weten, want iedere 302 maakt je site een paar milliseconden trager. Ik ben dus voorlopig nog niet klaar met de doorontwikkeling.</p>
<h2>Een eigen browser maken, gek?</h2>
<p>Na het gedaan te hebben kan ik zeggen: ja, wel een beetje. Maar ik heb iets gemaakt waar ik heel trots op ben en waar veel mensen dagelijks profijt van hebben. Het front-end werkveld is in de afgelopen jaren veel complexer geworden en lijkt soms wel dagelijks of zelfs per uur te veranderen. Daardoor is het gemakkelijk om je <em>overwhelmed</em> te voelen of je vooral bezig te houden met alles wat nieuw is en je minder bezig te houden met hoe effectief je nou zelf werkt. Het verbeteren van je proces — bijvoorbeeld door het gebruiken van een browser die je in je werkzaamheden ondersteunt — kan je uren per week tijdswinst opleveren. Zo gek is dat nog niet.</p>
<h2>Over Kilian</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/eigen-browser/kilian.png" alt="Foto van Kilian" class="floating-portrait" />
Kilian Valkhof is ruim 15 jaar front-end ontwikkelaar en ontwikkelt de browser [Polypane](https://polypane.app/). Fronteersleden kunnen Polypane [met korting gebruiken](/nl/blog/2019/05/25-procent-fronteers-korting-op-nieuwe-browser-polypane).
Kilians donatie gaat naar Stem op een vrouw.
</content>
</entry>
<entry>
<title>De full-stack mythe</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/de-full-stack-mythe"/>
<updated>2019-12-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/de-full-stack-mythe</id>
<content xml:lang="nl" type="html"><p>Een aantal jaar geleden was het web nog een stuk eenvoudiger. We gebruikten HTML en CSS om onze websites te maken, met eventueel wat JavaScript om het geheel een beetje <em><em>schwung</em></em> te geven. Had je dynamische content, dan maakte je een back-end in bijvoorbeeld PHP met eventueel een MySQL-database erachter. Als web developer was het niet ongewoon om op deze manier van voor tot achter met een website bezig te zijn.</p>
<p>Maar de tijd heeft niet stil gestaan. Onze computers werden beter, onze browsers werden beter en onze tools werden beter. Niet alleen de techniek is veranderd, vooral ook de rol ervan. Het web heeft heeft een centrale plek in de maatschappij gekregen - tot het punt dat we bijna allemaal altijd en overal verbonden zijn - waardoor we hogere eisen stellen aan toegankelijkheid, gebruiksvriendelijkheid, en veiligheid.</p>
<p>Ons werk is complexer geworden en er wordt meer van ons verwacht. Ieder aspect van het werk is nu een volwaardig expertisegebied geworden. Waar we eerst web developers waren, zijn we nu UX developers, accessibility experts, back-end engineers, DevOps engineers, ga zo maar door. Het is simpelweg niet meer realistisch om van iemand te verwachten om alle kneepjes van web development te beheersen. En toch zijn er talloze developers - waaronder ikzelf - die zichzelf 'full-stack' noemen en zijn er vele vacatures die erom vragen. Hoe zit dat dan?</p>
<h2>Wat betekent full-stack?</h2>
<p>Een full-stack developer is een <em>jack of all trades</em> en daarmee tegelijk doorgaans ook een <em>master of none</em>. Full-stack is een bewuste keuze om <em>niet</em> te specialiseren, of juist te specialiseren in niet-gespecialiseerd zijn. Als full-stacker ben je breed inzetbaar en kun je systemen in principe van voor tot achter ontwikkelen. In plaats van dieptekennis van één of enkele technieken zorg je dat je kennis hebt van wat er <em>op dat moment</em> nodig is. Is er een tijdje meer behoefte aan front-endwerk dan ben je een tijdje vooral front-ender, ligt er meer back-endwerk dan ben je even back-ender. Een voordeel dat je ook hebt is dat je als een soort 'lijmlaag' kan dienen binnen een team: je kunt eenvoudiger communiceren met verschillende gespecialiseerde developers omdat je een basis deelt.</p>
<p>Die afwisseling is alleen niet gratis. Omdat je je aandacht verdeelt over verschillende onderwerpen zul je niet zo productief zijn als een specialist in het gebied, óf je moet concessies doen op kwaliteit. Uiteindelijk is full-stack niets meer dan een compromis tussen kwaliteit en productiviteit aan de ene kant en flexibiliteit aan de andere. En dat laatste wil nog weleens over het hoofd gezien worden. Er heerst bij werkgevers vaak nog de mythe dat je developers kunt vinden die alles kunnen. Vacatures vragen regelmatig om developers die zowel front- als back-end beheersen, want waarom zou je meerdere specialisten inhuren als je ook developers in kunt schakelen die gewoon alles kunnen? Het scheelt gewoon gedoe. Wat ook niet helpt is dat front-end op sommige plekken nog steeds een ondergeschoven kindje is, iets 'voor erbij'.</p>
<p>Een full-stack developer is niet beter dan een gespecialiseerde developer, en vice versa. Vraag je jezelf af wat voor jou de beste keus is, dan is het enige korte antwoord daarop: <em><em>It Depends™</em></em>. Het hangt van de situatie af.</p>
<h2>De juiste keuze</h2>
<p>Voor developers hangt die keuze op dit moment vooral af van persoonlijke voorkeur. We zitten voorlopig nog in een situatie dat er aan vacatures geen tekort is, dus écht verkeerd kun je niet gaan. In alle gevallen moet je zorgen dat zorgen dat je de fundamentele bouwstenen van je vakgebied beheerst. Frameworks en libraries komen en gaan, maar talen en protocollen, bijvoorbeeld HTML, CSS en HTTP, zijn <em><em>here to stay</em></em> en geven in alle gevallen een stabiele basis om op voort te borduren. Als full-stacker moet je meer fundamentals beheersen, als gespecialiseerde developer bouw je er vooral meer op.</p>
<p>Kies je ervoor om full-stack developer te zijn of te worden? Weet dat je niets weet: accepteer dat ieder onderdeel van je werk een complex en dynamisch vakgebied is en dat je nooit alles kunt bijhouden. Denk je daar anders over, dan is dat waarschijnlijk <a href="https://nl.wikipedia.org/wiki/Dunning-krugereffect">dunning-kruger</a> in actie. Er hoeft echter ook niet van je verwacht te worden dat je alles meteen kan en de sleutel tot succes is vooral het kunnen focussen op wat er op dat moment qua skillset nodig is.</p>
<p>Ben je werkgever en zoek je naar nieuwe developers? Zoek dan niet automatisch naar full-stack developers omdat dat het makkelijkst lijkt. Wees je bewust van de voor- en nadelen en besluit op basis van wat jij specifiek nodig hebt. Als klein team met onvoorspelbaar werk kun je waarschijnlijk het beste uit de voeten met developers met bredere kennis. Heb je een groter team of is je werklast voorspelbaarder dan heb je waarschijnlijk het meeste aan meer gespecialiseerde ontwikkelaars. Weet je nog niet helemaal wat je nodig hebt, probeer dáár dan eerst achter te komen voordat je een full-stack vacature uitzet waarmee je gespecialiseerdere developers vaak buiten de deur houdt.</p>
<h2>Balans</h2>
<p>De laatste jaren is 'full-stack' binnen de front-endwereld bijna een vies woord geworden, een symbool voor hoe front-end onderschat wordt en voor onrealistische verwachtingen in vacatures. Dat is jammer, want ik denk dat zowel full-stack als meer gespecialiseerde developers een enorme toegevoegde waarde hebben op het web. Persoonlijk haal ik mijn voldoening uit de afwisseling, maar tegelijk werk ik het liefst samen met experts omdat we daardoor veel van elkaar kunnen leren. Uiteindelijk is het vooral belangrijk om hier een balans in te vinden, want daar zal ons werk alleen maar beter van worden.</p>
<p>Over Koen
<img src="https://www.fronteers.nl/_img/adventskalender/koen.jpeg" alt="Foto van koen" class="floating-portrait" />
Koen Kivits is een full-stack web developer in Eindhoven. Hij hobbyt op <a href="https://github.com/koenkivits">zijn Github</a>, tweet op <a href="https://twitter.com/koenkivits">zijn Twitter</a> en blogt op <a href="https://koen.kivits.com/">zijn website</a>.
Koens donatie gaat naar Bits of Freedom.)</p>
</content>
</entry>
<entry>
<title>CSS Custom Properties, Cascading Variables en het Einde van de Stijl</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/css-custom-properties-cascading-variables-en-het-einde-van-de-stijl"/>
<updated>2019-12-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/css-custom-properties-cascading-variables-en-het-einde-van-de-stijl</id>
<content xml:lang="nl" type="html"><p>Het is al heel lang mogelijk om de CSS-stijl vanuit HTML te bepalen met het <code>style</code> attribuut:</p>
<pre><code>&lt;div style=&quot;color: red; border: 1px solid red&quot;&gt;Waarschuwing&lt;/div&gt;
</code></pre>
<p>Hetzelfde geldt voor JavaScript met de <code>style</code> property:</p>
<pre><code>element.style = &quot;color: red; border: 1px solid red&quot;;
</code></pre>
<p>Dit is erg onhandig, want nu staan de CSS-stijlen verspreid over meerdere bestanden, wat het onderhoud lastig maakt. Wil je een stijl die je vanuit HTML of JavaScript gezet hebt, wijzigen via CSS, dan moet je <code>!important</code> gebruiken, wat het nog onhandiger maakt. Al snel ontstond de <em>best practice</em> om alle CSS alleen in CSS-bestanden te beschrijven en <code>style</code> niet meer te gebruiken, maar stijlen onder te brengen in <code>classes</code> en die vanuit HTML of JavaScript aan of uit te zetten.</p>
<pre><code>.warning {
color: red;
border: 1px solid red;
}
</code></pre>
<p>De HTML wordt dan:</p>
<pre><code>&lt;div class=&quot;warning&quot;&gt;Waarschuwing&lt;/div&gt;
</code></pre>
<p>En de JavaScript wordt:</p>
<pre><code>element.classList.add(&quot;warning&quot;);
</code></pre>
<p>Nu zou ik dit artikel kunnen eindigen met het advies om nooit meer het HTML-attribuut <code>style</code> en de JavaScript-property <code>style</code> te gebruiken, maar je had vast al gezien dat dit artikel nog wat langer is. Er zijn namelijk situaties waarin je in JavaScript een waarde berekent die je in een stijl wil gebruiken. Je berekent bijvoorbeeld een kleur of je gebruikt een complexe berekening om een x-positie uit te rekenen. Je kan dan weer de style-property erbij pakken en de <code>color</code> of de <code>left</code> properties veranderen. Maar dan heb je weer dezelfde problemen als hierboven beschreven. Wat als je later een ander element ook deze kleur wil geven? En niet <code>left</code>, maar <code>transform</code> wil gebruiken? Dan heb je toch weer een probleem.</p>
<h2>CSS variabelen</h2>
<p>Gelukkig is daar een oplossing voor, die inmiddels door <a href="https://caniuse.com/#feat=css-variables">alle moderne browsers</a> wordt ondersteund: <a href="https://www.w3.org/TR/css-variables/">CSS Custom Properties for Cascading Variables</a>, kortweg CSS variabelen. Hoe werken CSS variabelen? Laten we beginnen met een voorbeeld in CSS:</p>
<pre><code>:root {
--warning-color: orange;
}
.warning {
color: var(--warning-color, red);
border: 1px solid var(--warning-color, red);
}
</code></pre>
<p>Binnen CSS kan je dus een custom property zetten en die op verschillende plekken weer gebruiken. Het aanpassen van de waarde is hierdoor veel eenvoudiger geworden. Een CSS custom property zet je op dezelfde manier als een CSS property, maar ze beginnen altijd met '--'. Het uitlezen doe je met <code>var(--varname)</code>. De optionele tweede parameter van <code>var()</code>, in het voorbeeld hierboven <code>red</code>, is de default waarde voor het geval de variabele <code>--warning-color</code> (nog) niet is gezet. Het is belangrijk om te weten dat deze variabelen dezelfde regels voor cascading volgen als alle andere CSS properties, vandaar ook de naam Cascading Variables.</p>
<h2>Custom Properties of Variables?</h2>
<p>De termen custom properties en variables lijken in teksten over dit onderwerp door elkaar te worden gebruikt, maar wat is nou wat? In CSS heb je een declaratie zoals <code>color: white</code>. Links van de dubbele punt staat de property en rechts daarvan de waarde. Als de property met '--' begint, is het altijd een custom property. Als je deze aan de rechterkant van de dubbele punt gebruikt in een <code>var()</code>-functie, dan is het een variabele.</p>
<h2>JavaScript</h2>
<p>In JavaScript is het mogelijk om een waarde te geven aan een CSS custom property waarna je in CSS precies kan bepalen wat je ermee doet. Het veranderen van de property <code>--warning-color</code> doe je in JavaScript als volgt:</p>
<pre><code>element.style.setProperty(&quot;--warning-color&quot;, &quot;maroon&quot;);
</code></pre>
<p>De waarschuwing uit het eerdere voorbeeld zal nu kastanjebruin worden. Om een variabele in het hele document te kunnen gebruiken, zet je deze op het root element:</p>
<pre><code>document.documentElement.style.setProperty(&quot;--warning-color&quot;, &quot;maroon&quot;);
</code></pre>
<p>Was de strekking van dit artikel niet om nooit meer <code>style</code> te gebruiken? Nu doen we het toch. Oké, we laten dan één uitzondering toe, namelijk om <code>setProperty()</code> te kunnen gebruiken.</p>
<h2>Rekenen</h2>
<p>Met CSS variabelen kan je ook rekenen. Stel, je hebt een box waarvan in JavaScript is bepaald dat je die 80 pixels van de linkerkant wil weergeven:</p>
<pre><code>boxElement.style.setProperty(&quot;--box-left&quot;, &quot;80px&quot;);
</code></pre>
<p>Maar in je CSS weet je dat je daar ook de linkermarge bij moet optellen, die je ook in een CSS-variabele hebt opgeslagen. Dan kan je CSS er als volgt uitzien:</p>
<pre><code>:root {
--margin-left: 10px;
}
.box {
position: relative;
left: calc(var(--box-left) + var(--margin-left));
}
</code></pre>
<p>De <code>left</code>-property van de box wordt nu <code>90px</code>.</p>
<h2>Geen eenheid</h2>
<p>Nog beter is om in de <code>setProperty</code>-functie geen eenheid zoals <code>px</code> te gebruiken. Die kan je het best bepalen waar dat hoort: in de CSS. Neem bijvoorbeeld een voortgangsindicator die van 0 naar 100 loopt.</p>
<pre><code>document.documentElement.style.setProperty(&quot;--progress&quot;, bytes/totalBytes * 100);
</code></pre>
<p>Je CSS kan er dan zo uitzien:</p>
<pre><code>.progress-box {
background-color: deepskyblue;
width: calc(var(--progress) * 0.6rem);
height: 1rem;
}
</code></pre>
<p>Als de voortgang 40% is, dan zal de breedte gelijk zijn aan 40 × 0,6rem = 24rem.</p>
<h2>Media queries</h2>
<p>CSS variabelen zijn heel goed te gebruiken in media queries. Bijvoorbeeld om op hele kleine schermen alle marges klein te maken om alles nog goed te laten passen:</p>
<pre><code>:root {
--margin: 8px;
}
@media (max-width: 360px) {
:root {
--margin: 2px;
}
}
.some-text-box {
margin: var(--margin);
}
</code></pre>
<h2>Theming</h2>
<p>Je kan een theme natuurlijk heel eenvoudig houden met een voor- en achtergrondkleur en een paar classes. Maar als je sommige teksten, randen of iconen bepaalde accentkleuren wil geven, dan wordt het met op de oude manier snel erg omslachtig. CSS variabelen zijn hier juist heel geschikt voor. Ook bijvoorbeeld voor <em>dark mode</em>, waarbij de dark/lightmodus van de pagina meeverandert met die van het besturingssysteem:</p>
<pre><code>:root {
--background: white;
--text: black;
--accent: lightblue;
}
@media (prefers-color-scheme: dark) {
:root {
--background: black;
--text: white;
--accent: purple;
}
}
html {
color: var(--text);
background-color: var(--background);
}
.some-box {
border: 3px solid var(--accent);
}
</code></pre>
<p>Je kan op deze manier met verschillende kleurenpaletten werken en deze in de CSS toekennen aan verschillende properties, in dit geval de <code>border</code>.</p>
<h2>Variëren met kleuren</h2>
<p>Met een beetje creativiteit kan je ook kleuren variëren. Dat werkt het beste als je <code>hsl()</code> of <code>hsla()</code>-notatie gebruikt. Je kan bijvoorbeeld de tint (hue) vastleggen in een variabele en in de CSS allerlei variaties definiëren:</p>
<pre><code>:root {
--theme-hue: 120; /* 120 is green */
}
.themed-box {
color: hsl(var(--theme-hue), 50%, 90%);
background-color: hsl(var(--theme-hue), 50%, 30%);
border: 2px solid hsl(var(--theme-hue), 100%, 50%);
}
</code></pre>
<p>Door nu enkel <code>--theme-hue</code> te veranderen van bijvoorbeeld 120 (groen) in 0 (rood), verandert ook de stijl van <code>.themed-box</code>, inclusief alle variaties op die kleur. Natuurlijk kan je op deze manier ook de verzadiging (saturation) wijzigen om een pagina/element feller of ingetogener te maken. Of de helderheid (lightness) wijzigen om een pagina lichter of donkerder te maken. Combineer deze techniek met calc, media queries, theming en dark mode en er gaat een nieuwe wereld open. Je zal buiten vast een regenboog zien. En misschien wel een eenhoorn!</p>
<h2>Browser variabelen</h2>
<p>Naast <code>var()</code> voor het uitlezen van CSS-variabelen, bestaat er ook <code>env()</code> voor het uitlezen van browser-omgevingsvariabelen. Op dit moment (2019) zijn er vier van deze omgevingsvariabelen
gedefinieerd: <code>safe-area-inset-top</code>, <code>safe-area-inset-right</code>, <code>safe-area-inset-bottom</code> en <code>safe-area-inset-left</code>. Deze vier variabelen geven de afstand van de rand aan waarbinnen de inhoud geheel te bekijken is. Denk bijvoorbeeld aan een rond horloge met daarop een rechthoek met tekst. De variabelen geven de afstanden aan van de rechthoek tot de randen van het scherm. Een voorbeeld in CSS:</p>
<pre><code>.safe-box {
position: absolute;
top: env(safe-area-inset-top, 8px);
right: env(safe-area-inset-right, 8px);
bottom: env(safe-area-inset-bottom, 8px);
left: env(safe-area-inset-left, 8px);
}
</code></pre>
<p>Bij <code>env()</code> is, net als bij <code>var()</code>, de tweede parameter de default parameter als de variabele niet is gezet.</p>
<h2>Preprocessors</h2>
<p>Ik heb meerdere projecten gezien waarbij Sass of Less alleen werd gebruikt om een rij waarden aan variabelen toe te kennen om die vervolgens in de rest van de style sheets te gebruiken. Is het dan niet handiger om de preprocessor weg te laten en CSS variabelen te gebruiken? Ik denk van wel. In het buildproces sla je een stap over en bijvoorbeeld het debuggen wordt een stuk makkelijker.</p>
<h2>Internet Explorer 11</h2>
<p>En Internet Explorer 11 dan? Nee, die ondersteunt helaas geen CSS variabelen. In oktober 2019 had IE11 wereldwijd een <a href="https://gs.statcounter.com/browser-version-market-share#monthly-201811-201910">marktaandeel van 1,8%</a>. Wil je deze browser (en andere oude browsers) toch ondersteunen, dan kan je <em>graceful degradation</em> toepassen, wat eigenlijk altijd wel een goed idee is:</p>
<pre><code>.warning {
color: red;
color: var(--warning-color, red);
border: 1px solid red;
border: 1px solid var(--warning-color, red);
}
</code></pre>
<p>In dit geval wordt de waarschuwing in oude browsers altijd rood weergegeven. Het is misschien niet precies de kleur die de ontwerper had bedacht, maar een gebruiker van zo'n oude browser is al blij als een website bruikbaar is.</p>
<h2>Toekomst</h2>
<p>Lea Verou wilde ook diagrammen in CSS kunnen tekenen, inclusief schuine verbindingslijnen. Dat gaat nog niet goed met alleen <code>calc()</code>, want daar heb je ook trigonometrische functies voor nodig. Op het moment van schrijven, in 2019, wordt er <a href="https://github.com/w3c/csswg-drafts/issues/2331">gewerkt</a> om de functies <code>sin()</code>, <code>cos()</code>, <code>tan()</code>, <code>acos()</code>, <code>asin()</code>, <code>atan()</code>, <code>atan2()</code>, <code>hypot()</code>, <code>sqrt()</code> en <code>pow()</code> aan CSS toe te voegen.</p>
<h2>Breinbreker</h2>
<p>Tot slot een leuk stukje code uit een <a href="https://twitter.com/micahgodbolt/status/1131626097349496833?s=20">tweet van Micah Godbolt</a> om even over na te denken. Welke kleur is &quot;Hello World&quot;?</p>
<pre><code>&lt;style&gt;
#blue { --myVar: blue }
.red { --myVar: red }
&lt;/style&gt;
&lt;div style='--myVar: pink'&gt;
&lt;div id='blue'&gt;
&lt;div class='red'&gt;
&lt;span style='color: var(--myVar)'&gt;Hello World&lt;/span&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
</code></pre>
<p>Bedenk eerst zelf wat je antwoord zal zijn en kijk daarna pas naar het <a href="https://codepen.io/edwinm/pen/bGGOdpa">antwoord</a>. Aan de stembalkjes in de <a href="https://twitter.com/micahgodbolt/status/1131626097349496833?s=20">tweet</a> te zien, zitten er nogal wat mensen naast. Bedenk ook waarom het juiste antwoord het juiste antwoord is.</p>
<h2>Over Edwin Martin</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/edwin.jpg" alt="Foto van Edwin Martin" class="floating-portrait" />
Edwin is freelance frontend webontwikkelaar en woont in Hilversum. Hij [blogt](https://bitstorm.org/), twittert in het Engels over frontendzaken op [@edwinmdev](https://mobile.twitter.com/edwinmdev/) en schrijft af en toe [stukjes code](https://github.com/edwinm).
Edwins donatie gaat naar Bits of Freedom.
</content>
</entry>
<entry>
<title>8 Rare Tips Waarvan Toegankelijkheidsexperts Niet Willen Dat U Ze Weet!</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/8-rare-tips-waarvan-toegankelijkheidsexperts-niet-willen-dat-u-ze-weet"/>
<updated>2019-12-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/8-rare-tips-waarvan-toegankelijkheidsexperts-niet-willen-dat-u-ze-weet</id>
<content xml:lang="nl" type="html"><p><em>Nummer 4 Zal Je Een Epileptische Aanval Geven!</em></p>
<p>Deze titel is geschreven als een zogenaamde <a href="https://nl.wikipedia.org/wiki/Clickbait">clickbait-titel</a> en ironisch bedoeld. Clickbait-titels presenteren vaak misleidende tips als een vorm van krachtige geheime kennis. In dit geval willen toegankelijkheidsexperts niet dat je deze tips kent omdat ze een slecht advies zijn. Dit zijn tips die je niet moet volgen.</p>
<h2>1. Het gebruik van afkortingen verbetert je leesbaarheidsscore</h2>
<blockquote>
<p><em>&quot;Een goede FK-score is belangrijk voor A11Y vanwege de U in WCAG's POUR.&quot;</em></p>
</blockquote>
<p>Het maken van begrijpelijke inhoud is een kernprincipe van de Web Content Accessibility Guidelines (WCAG). Leesbaarheid is een groot deel van het creëren van begrijpelijke inhoud. Ik heb zelf vaak moeite om eenvoudige taal te schrijven. Ik gebruik meestal lange woorden en zinnen die eindeloos lijken. Om dingen gemakkelijker te maken, gebruiken ik en vele anderen een leesbaarheidstool. Ik typ dit momenteel in <a href="http://hemingwayapp.com/">Hemingway</a>: een eenvoudige schrijfapp die een leesbaarheidsscore toont. Deze score is gebaseerd op een <a href="https://nl.wikipedia.org/wiki/Leesbaarheid">Flesch – Kincaid leesbaarheidstest</a>. De test neemt het totale aantal zinnen, woorden en lettergrepen, en berekent er een score uit.</p>
<p>Door mijn score in de gaten te houden, kan ik me concentreren op het doel van mijn tekst: een boodschap duidelijk overbrengen. Er zijn echter enkele valkuilen. Woorden met weinig lettergrepen scoren beter dan woorden met veel lettergrepen. Afkortingen worden vaak geteld als woorden met weinig lettergrepen. Zoals we kunnen leren van WCAG: <a href="https://www.w3.org/WAI/WCAG21/Understanding/abbreviations.html">afkortingen kunnen lezers verwarren</a>. Dus hoewel afkortingen een hogere score geven kunnen ze vaak beter worden vermeden. Hetzelfde geldt voor een andere voorkeur van leesbaarheidsscores. Je krijgt een betere score door korte zinnen te gebruiken. Maar wanneer je woorden begint weg te laten om zinnen in te korten, is het eindresultaat mogelijk minder leesbaar.</p>
<p>Een Flesch-Kincaid-score is een geweldige maatstaf om je te concentreren op leesbaarheid, maar het is niet het uiteindelijke doel van je tekst.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/04-12-2019-1.png" alt="Een heel smal bord met de tekst &quot;geen alcohol voorbij dit punt&quot;. Er zijn gemiddeld 2 letters op elke regel. De tekst is vrijwel onleesbaar en ziet eruit als een lijst met afkortingen." /></p>
<h2>2. Pagina's die WAI-ARIA gebruiken zijn minder toegankelijk</h2>
<p>In februari 2019 deed WebAIM een geautomatiseerde toegankelijkheidstest op 1.000.000 webpagina's. Zo'n enorme dataset geeft veel inzicht in de huidige status van het web. Er zijn veel <a href="https://webaim.org/projects/million/">interessante conclusies</a> te trekken uit de resultaten. Eén daarvan was: &quot;Startpagina's met ARIA hadden gemiddeld 26.7 meer detecteerbare fouten dan pagina's zonder ARIA&quot;. Dat is een behoorlijk demotiverende statistiek.</p>
<p>Ik vind het echter behoorlijk begrijpelijk. ARIA is een complexe techniek. Een van de belangrijkste toepassingen voor ARIA is dat ontwikkelaars hun eigen toegankelijke widgets en elementen kunnen maken die niet beschikbaar zijn als native HTML-elementen. Dit betekent dat wanneer je ARIA op een pagina vindt, dit waarschijnlijk wordt gebruikt om een technisch complex component te maken. Met complexe componenten neemt de kans op problemen aanzienlijk toe.</p>
<p>Moet je ARIA dan niet gebruiken? Nou <a href="https://www.w3.org/TR/using-aria/">als je het niet nodig hebt, gebruik het dan niet</a>.Maar in sommige gevallen heb je misschien geen andere optie. Er is geen <code>&lt;tablist&gt;</code> of <code>&lt;tabpanel&gt;</code> in HTML. De <a href="https://www.w3.org/TR/wai-aria-practices/">ARIA Authoring Practices</a> laten een geweldige manier zien om zo'n Tab-widget te bouwen. Maar hun voorbeeld zal niet volstaan zonder aria.</p>
<p>De echte tip is niet om ARIA op zichzelf te vermijden, maar om het gebruik van ARIA te vermijden in situaties waar dit niet nodig is.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/04-12-2019-2.png" alt="Een kleine papieren paraplu bedekt nauwelijks een open kroonsteen met electriciteitsdraden. Het vormt een hopeloos schild tegen regen." /></p>
<h2>3. Geautomatiseerde tests dekken slechts 20% van WCAG</h2>
<p>Veel cijfers worden rondgeslingerd in gesprekken en presentaties over geautomatiseerde toegankelijkheid. En of je nou denkt dat tests 10% tot 30% van de mogelijke problemen dekken, of 20% van de WCAG-criteria, het maakt niet echt uit.</p>
<p>Elk probleem gevonden door een geautomatiseerde test kost 0 moeite. Dat is het belangrijke nummer. Dit zijn problemen zonder onderzoekskosten, beschikbaar op elk punt van een development life cycle. Daarnaast kan 20% van de WCAG criteria de oorzaak zijn van 60% van je problemen. Geautomatiseerd testen vindt het laaghangende fruit. Mijn ervaring is dat laaghangend fruit het meest voorkomende soort fruit is.</p>
<p>Voeg een handmatige toetsenbordtest toe aan je automatische test en je zal waarschijnlijk de overgrote meerderheid van je problemen vinden. Een handmatige toetsenbordtest bestaat uit het volgende:</p>
<ol>
<li>Ga door je pagina met de <tab> -toets.</tab></li>
<li>Zorg ervoor dat elk interactief element kan worden bereikt.</li>
<li>Zorg ervoor dat elk interactief element kan worden gebruikt.</li>
<li>Zorg ervoor dat de volgorde logisch is.</li>
<li>Zorg dat de focus zichtbaar is.</li>
<li>Doe hetzelfde in omgekeerde volgorde met <shift> + <tab>.</tab></shift></li>
</ol>
<p>Gefeliciteerd, je kan nu moeiteloos veel problemen vinden!</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/04-12-2019-3.png" alt="Een betegelde muur heeft een uitsparing in de vorm van een wastafel en zijn silhouette. De wasbak was er duidelijk eerder dan de muur." /></p>
<h2>4. Je kan een toegankelijk alternatief aanbieden</h2>
<p>WCAG heeft een soort ontsnappingsmechanisme voor mensen die van uitvluchten houden. Wanneer je een pagina hebt die niet conformeert aan WCAG, kun je een <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conforming-alt-versions-head">‘conforme alternatieve versie'</a> aanbieden. Het moet dezelfde informatie en functionaliteit bieden. Het moet bereikbaar zijn op een manier die geen barrières kent. Een <a href="https://www.w3.org/WAI/WCAG21/Understanding/three-flashes-or-below-threshold.html">constant knipperende</a> pagina met een link naar een overeenkomstige alternatieve versie is geen oplossing. Knipperende pagina's kunnen epileptische aanvallen veroorzaken. Een bezoeker die aanvallen van lichtflitsen ervaart zal daar waarschijnlijk last van hebben voordat die de alternatieve versie bereikt.</p>
<p>Als je een conforme pagina kunt bouwen, waarom zou je dan toch proberen om een alternatieve versie te maken? Het is gemakkelijk twee keer het werk, wat niemand leuk vindt. Maar het is ook zonde voor je gebruikers. Het verbergt alle toegankelijkheidsverbeteringen voor mensen die zich mogelijk niet identificeren als gehandicapt. Ze kunnen echter wel profiteren van deze verbeteringen. Een opgelost toegankelijkheidsprobleem betekent vaak een verbeterde gebruikerservaring voor iedereen. Door iedereen dezelfde inclusief ontworpen ervaring te geven, geef je mensen met een handicap de bevestiging dat ze erbij horen. Ze zijn niet een alternatieve versie die verborgen zit achter een link.</p>
<h2>5. Schrijf uitgebreide aria-labels voor blinden</h2>
<p>Helaas ben ik wel eens labels tegengekomen die specifiek geschreven waren voor mensen met een visuele beperking. Een voorbeeld was iets wat eenvoudige navigatie op een website had moeten zijn. Visueel had het duidelijke labels en het was eenvoudig te gebruiken. Het bevatte links met beknopte namen die overeenkwamen met hun bestemming, zoals 'home' en 'instellingen'. Het gebruik van een screen reader was echter een heel andere ervaring. Het menu had een label dat klonk als: &quot;Dit hoofdmenu is waar u de website kunt navigeren&quot;. De link naar instellingen was gelabeld met: &quot;Met de instellingenpagina kunt u dingen wijzigen zoals uw accountnaam of contactgegevens&quot;.</p>
<p>Hoewel goed bedoeld, helpt het niemand. Blind zijn betekent niet dat je niet weet waar een menu voor is, of wat een instellingenpagina je kan bieden. Door mensen te behandelen alsof ze hulpeloos zijn, zullen ze zich hulpeloos voelen. Het is een beetje de mansplaining van de toegankelijkheid. Ablesplaining?</p>
<p>Bij het schrijven van zogenaamde ‘accessible names’ schrijf je <a href="https://www.w3.org/TR/wai-aria-practices-1.1/#naming_effectively">korte functionele aria-labels</a> die mensen snel kunnen onderscheiden. <a href="https://adrianroselli.com/2019/10/stop-giving-control-hints-to-screen-readers.html">Gebruiksinstructies zijn ook niet nodig</a> .</p>
<h2>6. Slechts een klein aantal van onze klanten heeft een handicap</h2>
<p>Dit is een misvatting die me altijd blijft verbazen. Meer dan 15% van de wereldbevolking heeft een handicap. Wanneer meer dan 1 miljard mensen problemen hebben met toegang tot digitale informatie en diensten, noemen we dat niet een klein aantal.</p>
<p>Misschien heb je inderdaad een website met weinig gehandicapte bezoekers. Heb je overwogen dat dit eigenlijk een goede reden is om het toegankelijk te maken? Vergroot je bereik. Onderscheid je van anderen. De <a href="https://www.w3.org/WAI/business-case/">business cases voor toegankelijkheid</a> zijn er genoeg.</p>
<p>De discussie mag echter nooit over het aantal mensen gaan. Praten over cijfers wekt de indruk dat er ergens na veel rekenen, er een redelijke hoeveelheid mensen is die je wel wil discrimineren en uitsluiten. Als iemand je om cijfers vraagt, vertel diegene dan dat het de verkeerde vraag is om te stellen. Zelfs al zijn de aantallen klein, ze doen er niet toe.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/04-12-2019-4.png" alt="Een parkeerplek die is gemarkeerd als toegankelijk is omgeven door een aaneengesloten stoeprand" /></p>
<h2>7. De standaard focusindicator is veilig</h2>
<p>Veilig is hier een gevaarlijk woord, maar technisch gezien is een standaard focusindicator <a href="https://www.w3.org/WAI/WCAG21/Techniques/general/G165">toegestaan</a> door WCAG. Als je puur en alleen WCAG op de letter wil volgen, ben je hier klaar (hoewel sommige mensen dit succescriterium van WCAG zo interpreteren dat het wijzigen van de achtergrondkleur de standaardfocusindicator ongeldig kan maken).</p>
<p>De kans is groot dat de standaardfocusindicator heel moeilijk te zien is op delen van je website. Je kan waarschijnlijk iets veel beters maken dan deze standaardindicator. Als je enige doel is om WCAG te halen, doe je het toegankelijkheidsequivalent van &quot;<a href="https://en.wikipedia.org/wiki/Teaching_to_the_test">Teaching to the test</a>&quot;. Je scoort misschien goed op de korte termijn, maar als je erkent dat WCAG slechts een hulpmiddel is en geen doel, kunnen er op de lange termijn veel grotere winsten worden behaald.</p>
<p>Het is wel goed om te weten dat <a href="https://blogs.windows.com/msedgedev/2019/10/15/form-controls-microsoft-edge-chromium/">standaard focusindicatoren steeds beter worden</a>.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/04-12-2019-5.png" alt="Een stopcontact waar water uit giet" /></p>
<h2>8. Onderscheid elementen op je pagina met een mooi fontje</h2>
<p>In WCAG Succescriterium 1.4.1 staat dat we niet puur en alleen kleur kunnen gebruiken om iets te communiceren. Een voorbeeld van hoe het niet moet kan zijn dat je je fouten in een formulier met rood markeert. Of als binnen een navigatie de kleur van de huidige pagina verschilt van de andere links. Een ander bekend voorbeeld is het hebben van blauwe links op je pagina, maar zonder de kenmerkende underline. Door alleen op kleur te vertrouwen, sluit je mensen uit die beperkt (kleuren) zien.</p>
<p>Er zijn veel manieren om dit op te lossen, omdat het criterium behoorlijk vergevingsgezind is. Gebruik gewoon geen kleur als je enige visuele communicatiemiddel. Je kunt een passende foutmelding toevoegen aan je rode markeringen. Je kunt in je navigatie de huidige pagina dikgedrukt maken. Je kan ervoor zorgen dat je <a href="https://adrianroselli.com/2019/01/underlines-are-beautiful.html">links onderstreept zijn</a>.</p>
<p>Of ... je kan het lettertype van je links wijzigen. Technisch gezien zou je helemaal conformeren aan WCAG. Je kunt het lettertype zelfs wijzigen in Wingdings, het beroemde Windows-lettertype dat volledig uit pictogrammen bestaat. Volledig onleesbaar, maar geldig voor het 1.4.1 criterium. Een kleine verandering van je kerning, lijnhoogte, lettergrootte ... elke minimale verandering niet op kleur gebaseerd is voldoet.</p>
<p>WCAG heeft vier principes en 1.4.1 valt onder de eerste van vier: Perceivable. Wat u communiceert, moet voor iedereen waarneembaar zijn. Minimale veranderingen zijn een teken van minimale inzet en volgen niet de bedoeling van dit principe. Je wil duidelijk waarneembaar communiceren</p>
<p>Creatieve oplossingen zijn vaak minder effectief dan conventies. Het wijzigen van een lettertype kan nutteloos zijn voor een gebruiker die een aangepast lettertype heeft die de jouwe overschrijft.</p>
<p>Als je een toegankelijkheidstip ziet, bedenk dan of deze daadwerkelijk iets toevoegt voor je eindgebruiker . Als het niets verbetert aan hun ervaring, wees dan kritisch. De toegankelijkheidsgemeenschap is open en gastvrij. Voel je altijd vrij om de mening van anderen te vragen.</p>
<h2>Over Erik Kroes</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/erik-kroes.png" alt="Foto van Erik" class="floating-portrait" />
Erik werkt bij ING aan de toegankelijkheid van het design system en is een toegankelijkheidsadviseur voor [Eleven Ways](https://twitter.com/elevenways_be). Hij is mede-organizator van [Idea11y](https://twitter.com/idea11y), de Inclusive Design & Accessibility meetup. Je kunt hem vinden op [Twitter,](https://twitter.com/erikkroes) waar hij ook af en toe serieus is.
Eriks donatie gaat naar de Hersenstichting.
</content>
</entry>
<entry>
<title>Goeie docs = Happy devs</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/goeie-docs-happy-devs"/>
<updated>2019-12-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/goeie-docs-happy-devs</id>
<content xml:lang="nl" type="html"><p>Je hebt een geweldige app gemaakt, een mooie site gebouwd of een stevig CMS in elkaar gezet. Maanden werk. Je snapt zelf helemaal hoe het in elkaar zit. En dan komen ze: de vragen. Vragen van anderen die met jouw product aan de slag gaan.</p>
<p>Een draagvlak krijgen voor je app, script, plugin of anderszins, valt of staat bij goede documentatie. Gebruikers zijn ongeduldig, ze zoeken iets dat snel werkt. En als ze zich in de steek gelaten voelen zonder goede documentatie, zoeken ze door naar de volgende app. Want: als iets niet meteen werkt én je snapt ook nog eens de documentatie niet, voel je je dom of vind je de app dom. Niemand wil zich dom voelen, dus als er geen (goede) docs zijn en iemand worstelt met het starten met je app raak je die gebruiker snel kwijt. Dit zegt niks over hoe goed je applicatie is, maar de waarheid is dat niets zichzelf verkoopt, hoe goed het ook is.</p>
<p>Zorg je echter voor goede documentatie — met een goede ‘getting started’ en een paar stap-voor-stap secties — dan krijgt je gebruiker snel resultaat. Ze hebben iets werkend in no-time, hun initiële probleem of behoefte is opgelost en ze voelen zich succesvol en blij. En blije gebruikers zijn goede ambassadeurs voor je product.</p>
<p>Wellicht heb je al documentatie geschreven (goed zo!), of moet je er nog aan beginnen. Net zoals het bouwen van je app een vak is, is het maken van duidelijke documentatie ook een specialiteit op zich. In deze blog wil ik je wat tips geven om je op weg te helpen. Ik zal ingaan op code comments, READMEs en uitgebreidere documentatie.</p>
<h2>Denkers en doeners</h2>
<p>Niet iedereen neemt op dezelfde manier informatie op. Sommige mensen proberen graag eerst zelf wat, terwijl anderen zich liever eerst goed inlezen. En weer een derde groep kijkt graag juist een video met uitleg. In de didactiek worden dit leerstijlen genoemd. Er wordt uitgegaan van vier verschillende leerstijlen. Eenvoudig gezegd zijn dit ‘waarnemen’, ‘ervaren’, ‘denken’ en ‘doen’. Als je dit in gedachten neemt is het niet gek dat jouw manier van uitleggen misschien niet bij iedereen aansluit die iets wil leren over jouw product. En dat het geen gek idee is om bepaalde informatie op meerdere manieren aan te bieden.</p>
<h2>Geen documentatie</h2>
<p>Laten we bij het begin beginnen. De beste documentatie is <em>geen documentatie</em>. Dit lijkt een open deur, maar als je applicatie zo duidelijk is dat er geen extra uitleg nodig is dan is dat natuurlijk een <em>win</em>. Zorg dus dat je bij de basis, het ontwerp en het opzetten van je applicatie, al rekening houdt met je gebruikers en kijkt wat de logische stappen zijn die mensen doen. Test regelmatig in het wild, en als mensen steeds dezelfde fout maken of je dezelfde vraag stellen kan je op die plek vast iets verbeteren.</p>
<h2>Code comments</h2>
<p>Een eenvoudige en snelle versie van documentatie zijn comments in de code. Je hebt bijvoorbeeld een open source applicatie gebouwd waarmee anderen ook aan de slag moeten. Of je hebt gewerkt aan een project dat jij en je team langere tijd moeten onderhouden. Dan wil je in de code ook comments opnemen om zaken uit te leggen. Het is verrassend hoeveel je in de toekomst vergeten kan zijn van het project dat je nu uit je hoofd kent.</p>
<p>Vrijwel iedereen compileert zijn JS en CSS, dus comments nemen geen ruimte meer in op je productieserver. Er is niet zoiets als ‘teveel comments’ als dat nodig is voor je code.</p>
<pre><code>/* Theme colors, defined by corporate identity (version 1.3, august 2019) */
root: {
--themecolor-primary: #ff0099;
--themecolor-secondary: #ff6600;
}
</code></pre>
<p>Houd het leesbaar, kort en bondig. Je schrijft comments die door een mens gelezen moeten worden. Gebruik duidelijke taal en korte zinnen.</p>
<pre><code>/* Run initial checks for page setup. Checks the viewport width
* and does some actions for the UI based on screen size
*/
preLoadChecks();
</code></pre>
<p>Magic numbers? Het liefst gebruik je zo min mogelijk <em>magic numbers</em> in je code. Toch gebruikt? Leg uit waarom.</p>
<pre><code>width: 200px; /* Magic number, needs fixing! Exact width of logo,
looks best on mobile like this */
</code></pre>
<p>Vraag jezelf af wat er zo ingewikkeld is aan dit stukje code, en probeer dat in ‘leken’-taal te verwoorden. Ook voor <em>future you</em>.</p>
<pre><code>/* First, get the height of the viewport. Use this value to calculate
* the color using the script from github.com/awesome-script. Second,
* create the variables of the theme based on these colors.
*/
</code></pre>
<h2>READMEs</h2>
<p>Een goede README in je git repository laat je project opvallen in de massa andere projecten op GitHub. Dus je schrijft een kickass README die net zo goed is als je repo. Het is ook is een manier om te zorgen dat mensen betrokken worden bij je project. Het gebruik van screenshots en beeld trekt snel de aandacht omdat dat een manier is om snel informatie over te brengen. En een verzorgde README wijst ook op een net, verzorgd project.</p>
<p>Je README moet voldoende info bevatten om mensen snel op weg te helpen. Denk daarbij aan:</p>
<ul>
<li>Een introductie. Wat voor project is dit? Wat doet het en voor wie is het? Hou het simpel met heldere taal en korte zinnen.</li>
<li>Wat maakt dit project zo uniek en speciaal? Bezoekers die op GitHub zoeken naar een geschikte app of plugin, willen snel kunnen vergelijken.</li>
<li>Screenshots en/of code voorbeelden.</li>
<li>Welke specs zijn nodig?</li>
<li>Welke stappen zijn nodig voor de installatie?</li>
<li>Hoe kan je meehelpen? Laat mensen weten hoe ze kunnen bijdragen aan je project.</li>
<li>Credits! Wie hebben er meegebouwd?</li>
<li>Is er een licentie, en zo ja, welke?</li>
</ul>
<h2>Documentatiesites</h2>
<p>Voor de grotere projecten maak je een documentatie-website. Een handleiding waarin je je gebruiker bij de hand neemt om de applicatie zo goed mogelijk te gebruiken. Met de verschillende leerstijlen in gedachten kan je verschillende ingangen maken voor gebruikers. Bijvoorbeeld - Een stap-voor-stap uitleg. Voor het opzetten van een installatie of een eerste demo. De doeners in je doelgroep worden hier blij van! - Via een inhoudsopgave op kernwoorden. - Een serie video tutorials</p>
<ul>
<li>Een stap-voor-stap uitleg. Voor het opzetten van een installatie of een eerste demo. De doeners in je doelgroep worden hier blij van!</li>
<li>Via een inhoudsopgave op kernwoorden.</li>
<li>Een serie video tutorials</li>
</ul>
<p>Veel mensen starten met <strong>doen</strong>. Ze installeren je applicatie en klikken er in rond. Als het goed is zit je applicatie duidelijk in elkaar en snappen mensen direct wat ze moeten doen. Komen ze een hobbel tegen, dan gaan ze op zoek naar de docs.</p>
<h2>Schrijftips</h2>
<p>Geen enkele gebruiker die ik ken pakt eerst de docs om te lezen, om daarna pas te starten. Mensen komen pas bij je documentatie uit als er een probleem is. Ze zoeken op een kernwoord naar een oplossing. Spreek deze bezoekers daarom aan met de volgende punten in gedachten:</p>
<p>Gebruik kernwoorden die ook in de applicatie gebruikt worden. Let op de exacte bewoordingen van onderdelen en knoppen.</p>
<p>Maak de pagina snel scanbaar met tussenkopjes. Niet meer dan één of twee paragrafen per kopje. Toch te lang? Verdeel je tekst dan onder in delen.</p>
<p>Focus niet op het <em>happy path</em>: het scenario waarbij alles vlekkeloos verloopt in je applicatie. Immers, gaat alles goed, dan komen mensen in eerste instantie niet bij je docs kijken. Geef bij elke stap een paar voorkomende problemen en hoe die op te lossen.</p>
<p>Gebruik de exacte bewoording van foutmeldingen. Gebruikers <em>google-en</em> immers vaak de melding en komen zo direct op jouw site waar de oplossing staat.</p>
<p>Vermijd wollig taalgebruik en schrijf actief. ‘<em>You will see the big red button on the top. Press this to go to the configuration page where you can edit the settings</em>’ wordt: ‘<em>Edit the configuration settings by pressing the ’config’ button</em>’.
Eenvoudig: Hoe kortere zinnen (én woorden!), hoe makkelijker leesbaar. En geen enkele gebruiker heeft ooit geklaagd dat iets ‘te makkelijk leesbaar’ was.</p>
<p>Mensen leren van fouten van anderen. Kom je zelf een foutmelding tegen die niet gedocumenteerd is? Draag bij aan de documentatie door bijvoorbeeld een pull request.</p>
<p>Teveel uitleg nodig? Dat kan een hint zijn dat je code of app op die plek niet helemaal lekker loopt. Kijk altijd of je applicatie zelf op dat punt wellicht verbeterd kan worden.</p>
<p>Geef codevoorbeelden die direct knip- en plakbaar zijn, en een basis zijn om uit te werken. Voeg eventueel uitgecommentarieerde opties toe in deze voorbeeldcode.</p>
<pre><code>var myColorpicker = new Colorpicker ('.colorpicker-container', {
// Optional parameters
swatches: 'large', // small, medium, large, huge
name: true // true: shows names, false: swatch only
})
</code></pre>
<h2>Voeg beeld en video toe</h2>
<p>Om weer even terug te komen op de leerstijlen: Als je je documentatie kan voorzien van beeldmateriaal, zoals video of screenshots, maak je het voor veel mensen bruikbaarder en sneller te snappen. Zorg ook voor goede alt-teksten van je beeld en captions bij je video’s om rekening te houden met toegankelijkheid. Op de Mac kan je tegenwoordig binnen iOS en OSX een schermvideo opnemen, of je gebruikt een app zoals <a href="https://recordit.co/">Recordit</a>.</p>
<p>En als uitsmijter: vraag hulp. Je hoeft niet alles zelf te doen en anderen helpen je graag een handje bij proeflezen of testen. De frisse blik van een ander kan je zeker helpen bij het verbeteren van je docs, want sommige zaken zijn voor jou wel logisch maar hebben voor een ander juist wat toelichting nodig.</p>
<p>Dit waren mijn tips. Hopelijk helpt deze blog je op weg als je de volgende keer aan de slag gaat met het schrijven van een README of documentatie. Succes!</p>
<h2>Meer informatie?</h2>
<ul>
<li>Tips voor code comments op Hongkiat: <a href="https://www.hongkiat.com/blog/source-code-comment-styling-tips/">Source Code Comment Styling: Tips and Best Practices</a></li>
<li>Tips voor een goede README op Medium: <a href="https://medium.com/@meakaakka/a-beginners-guide-to-writing-a-kickass-readme-7ac01da88ab3">A Beginners Guide to writing a Kickass README</a></li>
<li>Hoe schermvideo’s opnemen op de Mac: <a href="https://support.apple.com/en-us/HT207935">Apple: How to record the screen on your iPhone, iPad, or iPod touch</a> <a href="https://support.apple.com/en-us/HT208721">Apple: How to record the screen on your Mac</a></li>
</ul>
<h2>Over Anke Willems</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/anke.jpeg" alt="Foto van anke" class="floating-portrait" />
Anke is webdesigner en front-end developer bij Two Kings. In een eerder leven was ze grafisch ontwerper (met drukwerk en papier en zo), maar digitaal vind ze toch echt leuker. Heeft een grote liefde voor het maken van kleine gebruiksaanwijzingen die op een post-it moeten passen. Maakte de afgelopen twee jaar ook de sketch notes van de Fronteers Conferentie.
Ankes donatie gaat naar Stem op een vrouw.
</content>
</entry>
<entry>
<title>Een eigen kalendercomponent bouwen</title>
<link href="https://www.fronteers.nl/nl/blog/2019/12/een-eigen-kalendercomponent"/>
<updated>2019-12-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/12/een-eigen-kalendercomponent</id>
<content xml:lang="nl" type="html"><p>Het is natuurlijk belangrijk componenten in je applicatie niet allemaal zelf te maken, maar gebruik te maken van het enorme assortiment aan componenten die al geschreven zijn door anderen. Het kost immers tijd om dingen zelf te maken en dus ook geld. Maar soms is het ook goed om eens kritisch te kijken naar welke functionaliteiten je daadwerkelijk benut van het component dat je gebruikt en is het ook gewoon leuk en leerzaam om zelf iets te bouwen.</p>
<p>Zo deden wij dat bij Withlocals voor onze datepicker- kalender- en agenda-componenten. Er zijn bij ons ongeveer 2000 gebruikers die iedere dag hun beschikbaarheid bijwerken, dus de agenda is een cruciaal onderdeel van ons platform. Veel kant-en-klare kalendercomponenten op het web zijn echter te uitgebreid voor ons, omdat ze moeten werken voor iedere mogelijke use-case.</p>
<h2>Stap 1: datastructuur</h2>
<p>Als je per maand het aantal dagen weet en hoe je dit kunt vertalen naar een visuele weergave van een kalender wordt alles een stuk eenvoudiger. Naast het aantal dagen in de maand willen we ook tonen op welke dag de maand begint.</p>
<p>Het beste zou dus zijn als we een functie hadden die deze informatie teruggeeft voor een maand. In het <code>[Date](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date)</code> object is al de nodige data beschikbaar</p>
<h2>Aantal dagen in een maand</h2>
<p>Het aantal dagen in een maand is uit te rekenen met <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getDate">de getDate method van het Date object</a>.</p>
<p>De constructor van <code>Date</code> vraag om de parameters <code>year</code>, <code>month</code> en <code>day</code>. Als we <code>day</code> op 0 zetten wordt de laatste dag van de vorige maand gebruikt. <code>new Date(2020, 1, 0)</code> is dus niet 0 februari maar 31 januari. We kunnen dus als volgt het aantal dagen in een maand uitrekenen:</p>
<pre><code>function getDaysInMonth(year, month) {
return new Date(year, month + 1, 0).getDate();
}
const daysInJanuary = getDaysInMonth(2020, 0); // 31
</code></pre>
<h2>Begin van een maand</h2>
<p>De <code>[getDay()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getDay)</code> method van een <code>Date</code> object geeft terug welke weekdag — van 0 tot en met 6, waarbij 0 zondag is — een datum is. Dat kunnen we gebruiken om de weekdag van de eerste dag van een maand te bepalen:</p>
<pre><code>function getStartOfMonth(year, month) {
return new Date(year, month, 1).getDay();
}
const startOfJanuary = getStartOfMonth(2020, 0); // 3 = woensdag
</code></pre>
<h2>Genereren van een maand</h2>
<p>Een tweedimensionale array van de maand kunnen we vervolgens als volgt berekenen:</p>
<pre><code>function generateMonth(year, month) {
const startOfMonth = getStartOfMonth(year, month);
const daysInMonth = getDaysInMonth(year, month);
const amountOfWeeks = Math.ceil((startOfMonth + daysInMonth) / 7);
return Array(amountOfWeeks)
.fill()
.map((_, week) =&gt; {
return Array(7).fill().map((_, day) =&gt; {
const dayOfTheMonth =
(week * 7) -
(startOfMonth - 1) +
day;
if (dayOfTheMonth &lt; 1 ||
dayOfTheMonth &gt; daysInMonth
) {
return null;
}
return dayOfTheMonth;
});
});
}
const january = generateMonth(2020, 0);
/* =&gt;
* [
* [null, null, null, 1, 2, 3 ,4],
* [5, 6, 7, 8, 9, 10, 11],
* [12, 13, 14, 15, 16, 17, 18],
* [19, 20, 21, 22, 23, 24, 25],
* [26, 27, 28, 29, 30, 31, null]
* ]
*/
</code></pre>
<p>In de output van <code>generateMonth()</code> is er al bijna een kalender te zien. Op mijn <a href="https://codepen.io/klaasvaak/pen/pooYEGe?editors=0011">CodePen met bovenstaande functies</a> kun je de output voor het gehele jaar 2020 zien.</p>
<h2>Stap 2: de view</h2>
<p>Nu de kalender al bijna te zien is in de data kan dit relatief ‘eenvoudig’ vertaald worden naar HTML en CSS. In het volgende voorbeeld is dit gedaan met behulp van React.</p>
<p>De volgende componenten zien hiervoor gemaakt:</p>
<ul>
<li><code>Day</code> (rendert een enkele dag)</li>
<li><code>Week</code> (rendert meerdere <code>Day</code> componenten)</li>
<li><code>Month</code> (rendert meerdere <code>Week</code> componenten en de labels voor de dagen van de week)</li>
<li><code>Calendar</code> (rendert de huidige <code>Month</code> componenten)</li>
</ul>
<p>Op CodeSandbox is het <a href="https://codesandbox.io/s/heuristic-mestorf-oxmtu">het volledige voorbeeld van een simpele kalenderweergave</a> te zien.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/02-12-2019-1.png" alt="Voorbeeld van versimpelde kalenderweergave" /></p>
<p>Voor een meer uitgebreide versie kan je naast extra styling ook denken aan event handlers voor datumselectie en het formatteren van de datums met bijvoorbeeld <a href="https://momentjs.com/">moment.js</a> of <a href="https://date-fns.org/">date-fns</a>.</p>
<h2>Stap 3: internationalisatie</h2>
<p>In bovenstaande voorbeelden werd zondag steeds gebruikt als begin van de week, maar als dit een andere dag moet zijn kunnen we de dataset daarvoor aanpassen.</p>
<p>De output van <code>generateMonth()</code> voor januari 2020 zag er zo uit:</p>
<pre><code>[
[null, null, null, 1, 2, 3 ,4],
[5, 6, 7, 8, 9, 10, 11],
[12, 13, 14, 15, 16, 17, 18],
[19, 20, 21, 22, 23, 24, 25],
[26, 27, 28, 29, 30, 31, null],
]
</code></pre>
<p>Als de week op maandag zou beginnen moet alles 1 naar links opschuiven en zou het er dus zo uitzien:</p>
<pre><code>[
[null, null, 1, 2, 3, 4 ,5],
[6, 7, 8, 9, 10, 11, 12],
[13, 14, 15, 16, 17, 18, 19],
[20, 21, 22, 23, 24, 25, 26],
[27, 28, 29, 30, 31, null, null]
]
</code></pre>
<p>Aan <code>generateMonth</code> voegen we een parameter toe die aangeeft wat het begin van de week is. Zondag (de default) is 0, maandag is 1, etc cetera. Binnen <code>generateMonth</code> wordt deze parameter gebruikt om op de juiste manier een kalender te genereren door een offset te berekenen</p>
<pre><code>const sundayBasedOffset = getStartOfMonth(year, month);
let realOffset = sundayBasedOffset - startOfCalendarWeek;
if (realOffset &lt; 0) {
realOffset = 7 + realOffset;
}
const daysInMonth = getDaysInMonth(year, month);
const amountOfWeeks = Math.ceil((realOffset + daysInMonth) / 7);
</code></pre>
<p><a href="https://codesandbox.io/s/vigorous-tesla-97y6s">Op CodeSandbox vind je een voorbeeld van deze berekening.</a></p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/02-12-2019-2.png" alt="Een voorbeeld van een kalendercomponent waarbij de begindag van de week kan worden ingesteld" /></p>
<h2>De mogelijkheden</h2>
<p>Nu het duidelijk is hoe een kalender te genereren kun je de logica op verschillende manieren gebruiken. Zoals bijvoorbeeld in een datepicker of een daterange-picker:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/02-12-2019-3.gif" alt="Een daterange-picker" /></p>
<h2>Een daterange-picker</h2>
<p>Ook kun je dezelfde logica in een agenda gebruiken:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/02-12-2019-4.gif" alt="Toepassing van het component in een kalender-app" /></p>
<p>Wie weet volgt er binnenkort nog een vervolgpost voor de toegankelijkheid van deze componenten.</p>
<h2>Over Joep van der Heijden</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/joep.jpeg" alt="Foto van joep" class="floating-portrait" />
Sinds een kleine 3 jaar is Joep lead front-end developer bij de startup Withlocals in Eindhoven waar hij een team van 5 front-enders leidt. Naast het werk houdt hij zich bezig met het organiseren van de Eindhoven Developers Meetup, waar je elke meetup een kijkje neemt bij een anderbedrijf in de regio Eindhoven.
Joeps donatie gaat naar Bits of Freedom.
</content>
</entry>
<entry>
<title>A write up of the W3C TPAC 2019</title>
<link href="https://www.fronteers.nl/nl/blog/2019/10/a-write-up-of-the-w3c-tpac-2019"/>
<updated>2019-10-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/10/a-write-up-of-the-w3c-tpac-2019</id>
<content xml:lang="nl" type="html"><p>This year the W3C Technical Plenary and Advisory Committee Meeting (TPAC) was held in Fukuoka, Japan. As part of my work representing Fronteers in the W3C I attended the two Advisory Committee (AC) meetings held at TPAC, along with the CSS Working Group meeting days. In this post I will highlight some of the things that might be of interest to Fronteers members. I hope this gives a good overview of the breadth of things discussed.</p>
<p>This year TPAC was held in Fukuoka, Japan. As part of my work representing Fronteers in the W3C I attended the two Advisory Committee (AC) meetings held at TPAC, along with the CSS Working Group meeting days. In this post I will highlight some of the things that might be of interest to Fronteers members. I hope this goves a good overview of the breadth of things discussed.</p>
<p>Two public documents that give an great overview of the recent work of the W3C are the <a href="https://www.w3.org/2019/09/factsheet.html">W3C Factsheet</a>, and the <a href="https://www.w3.org/2019/09/w3c-highlights/">W3C Strategic Highlights</a> document. These documents give a good picture of what is happening at the W3C in a straightforward manner.</p>
<p>In addition to these documents a financial report was shared which is <em>member-only</em>. If any Fronteers member wishes to view any member-only document, or have further details of anything discussed here, please let me know, I'll be happy to share those with you.</p>
<p>The Tuesday meeting began with an update from the CEO Jeff Jaffe. This introduced some of the topics that would be discussed later in the meeting and reminded us of the fact that in May this year the W3C and the WHATWG succesfully completed the negotiation of a Memorandum of Understanding rooted in the mutual belief that that having two distinct specifications claiming to be normative is generally harmful for the Web community.</p>
<p>We then moved onto discussion of the W3C becoming a legal entity, and the various legal and administrative matters that this would entail.</p>
<p>The second half of the meeting moved into shorter updates about various areas of the W3C and lightning talks.</p>
<h2>Update on Web of Things</h2>
<p>There are two groups dealing with WoT in the W3C, an <a href="https://www.w3.org/WoT/IG/">Interest Group</a> which is open to anyone, and a <a href="https://www.w3.org/WoT/WG/">Working Group</a> open only to W3C Members and Invited Experts, in common with all Working Groups.</p>
<p>In June this year a WoT workshop was held in Munich, and the <a href="https://www.w3.org/TR/2019/CR-wot-architecture-20190516/">Architecture</a> and <a href="https://www.w3.org/TR/2019/CR-wot-thing-description-20190516/">Thing Description</a> were published as Candidate Recommendations on 16 May 2019.</p>
<h2>Globalization and Inclusion</h2>
<p>In this session we heard about the work to make the W3C more inclusive and global. This work falls into categories of Diversity and Inclusion, Facilitation and Culture, and Tools. There are efforts in place across these areas which are owned by members of the Advisory Board (AB).</p>
<p>The area of Diversity and Inclusion achieved the sponsorship of seven people from diverse backgrounds to come to TPAC this year. Funds for this were raised from 10 W3C members and one individual sponsor.</p>
<p>As a CSS Working Group member I experience one change made in the area of Facilitation and Culture in that one CSS Working Group meeting per month has moved to a timezone more friendly to people in the Asia and Pacific region. This aims to include more people in the meetings than would otherwise be able to participate.</p>
<p>In the area of Tools, one area under development is the facilitation of translation for meetings to enable people to participate in their own language, rather than needing to be an English speaker. Other subjects in this area are the use of online tools such as Google Docs which are not accessible in all areas of the world, this is a good reminder to those of us in countries where we can easily access these things that not everyone can.</p>
<h2>Code of Ethics and Professional Conduct</h2>
<p>As a follow-on from the discussion on globalization and inclusion was a session on the Code of Ethics and Professional Conduct (CEPC) being discussed by the Positive Work Environment Community Group.</p>
<p>The group are working to update the CEPC following feedback and referencing other best practices for Codes of Conduct. In addition to producing a document, the group is helping to train people as ombuds who will help in situations where the code has been broken, or when someone has a concern.</p>
<p class="note">
The group are keen to receive feedback on the draft, which you can find [here](https://w3c.github.io/PWETF/).
</p>
<h2>Incubation</h2>
<p>Fronteers members might be familiar with the Web Incubation Community Group (WICG), which is a place where new web platform ideas can be proposed and discussed outside of a Working Group. In general new platform features should start life here, so this is likely to be the initial place to post if you have an idea which isn't an edit to an existing spec for example.</p>
<p>Chris Wilson gave a presentation about the <a href="https://github.com/wicg/">WICG</a> and other places for incubation, and explained the incubation process for new web platform ideas.</p>
<ol>
<li>here’s a problem space to solve” → (public!)</li>
<li>WICG post →</li>
<li>Work with community, prototype solutions →</li>
<li>&quot;Minimum Viable Design&quot; - get web developers to try it out</li>
<li>Community-building, iteration, graduation, →</li>
<li>WG (horizontal review, iterate, lock down, implementations) →</li>
<li>W3C Recommendation</li>
</ol>
<p class="note">
As anyone who has seen one of my talks knows, I am very keen to encourage web designers and developers to get involved with web platform features. So do take a look at [the threads in the WICG discussions](https://discourse.wicg.io/), and see if there are features you have use cases for.
</p>
<h2>Lightning talks</h2>
<p>The session finished with the following lightning talks, designed to highlight different areas of work across the W3C:</p>
<ul>
<li>SVG - Amelia Bellamy-Rhoyds, Invited Expert</li>
<li>VR and AR on the Web - Ada Rose Cannon, Samsung</li>
<li>Web beyond the browser - Hyojin Song, LG</li>
<li>Second Screen on the Web - Mark Foltz, Google</li>
</ul>
<h2>Continuous Standards Development</h2>
<p>THe first session of the Thursday meeting was on proposed updates to the process by which specifications on the Recommendation track are worked on, in particular what happens when specifcations in Candidate Recommendation (CR) status need an edit. The current workflow is cumbersome and often means that the spec in CR is quite outdated when compared to the latest Editor's Draft.</p>
<p>There are a range of proposals to help improve this process, which should ultimately help in making the published documents more useful to refer to.</p>
<h2>Mini App standardization and next steps</h2>
<p>While we in the West tend to hear a lot about PWAs, in China hybrid web and mobile apps are popular, these use web technologies within a native wrapper. The <a href="https://www.w3.org/2018/chinese-web-ig/">Chinese Web Interest Group</a> are working to standarize this technology. This is a fairly new group, and this session was an update on their activities.</p>
<h2>PWAs and Project Fugu</h2>
<p>The aim of Project Fugu is:</p>
<blockquote>
<p>&quot;Enable web apps to do anything native apps can, by exposing the capabilities of native platforms to the web platform, while maintaining user security, privacy, trust, and other core tenets of the web.&quot;</p>
</blockquote>
<p>There are various APIs being developed to meet this aim, their progress can be tracked on the <a href="https://developers.google.com/web/updates/capabilities">Capabilities Landing Page</a> or the <a href="https://www.fronteers.nl/nl/blog/2019/10/bit.ly/fugu-api-tracker">Fugu API Tracker</a>.</p>
<p>How the world pays online - an update on the Web Payments Community Group</p>
<p>The <a href="https://www.w3.org/community/webpayments/">Web Payments Community Group</a> work on a family of specifications. You might be familiar with the <a href="https://www.w3.org/TR/payment-request/">Payment Request API</a>, which is the most mature of these specifications and is an API to allow a payment request to be invoked in the browser.</p>
<p>The Group are working on moving Payment Request to Proposed Recommendation, and trying to encourage wider use of these specifications.</p>
<h2>CSS Working Group Meetings</h2>
<p>We also had two days of CSS Working Group meetings at TPAC, although I had to miss some of the Tuesday afternoon to attend the AC meeting.</p>
<p>A highlight for me was to get a resolution on an outstanding issue meaning that I could publish a new Working Draft of the <a href="https://www.w3.org/TR/css-multicol-1/">Multiple-column Layout specification</a>. This WD includes the edits I made after the specification reading workshop that Fronteers members took part in earlier this year.</p>
<p>In addition it was resolved that the <a href="https://www.w3.org/TR/css-writing-modes-3/">CSS Writing Modes</a> specification could go to Proposed Recommendation (PR) Status. This is the last step before it becomes a W3C Recommendation. It was especially nice that it went to PR while we were in Japan, given that Writing Modes is key to being able to set vertical modes such as Japanese.</p>
<p>If any Fronteers member wants to know more about any of the above, please get in touch with me, It's part of my role to pass on any relevant information, or put you in touch with the right people to help.</p>
<p class="note">
Members of Fronteers are encouraged to seek access to a members-only channel on our Slack space. If you haven't joined it yet, you can [sign up for our Slack automatically](https://fronteers-slack.herokuapp.com/). To join the members-only channel, send a private message to Anneke Sinnema (@anneke).
</p>
</content>
</entry>
<entry>
<title>Meld je aan voor de ALV 2019</title>
<link href="https://www.fronteers.nl/nl/blog/2019/10/meld-je-aan-voor-de-alv-2019"/>
<updated>2019-10-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/10/meld-je-aan-voor-de-alv-2019</id>
<content xml:lang="nl" type="html"><p>Op vrijdagavond 29 november houden we onze jaarlijkse algemene ledenvergadering (ALV) in Utrecht! Alle leden zijn hiervoor van harte uitgenodigd. De vergadering vindt dit keer plaats op een nieuwe locatie, Collectiv (Creative Valley) direct grenzend aan Utrecht Centraal Station!</p>
<ul>
<li><a href="https://www.fronteers.nl/nl/blog/2019/10/meld-je-aan-voor-de-alv-2019#english-version">English version</a> below -</li>
</ul>
<p>Is het je eerste keer op de (of überhaupt een) ALV? Tijdens de ALV nemen we als bestuur, vrijwilligers en leden samen de (financiële) staat van Fronteers door, en evalueren we hoe het gaat met de vereniging. Tot het begin van de vergadering kan elk lid een voorstel doen voor een agendapunt of een ter stemming te brengen onderwerp.</p>
<p>Voor de mensen die van ver of direct vanuit hun werk komen zal er vanaf 18:00 een klein buffet klaar staan (vis, vlees en vegetarisch - broodjes, soep en een warm item). De vergadering zelf begint om 18:30 uur. We verwachten dat de totale vergadering twee uur zal duren, maar de ervaring leert dat het nog weleens wil uitlopen. We doen ons best dit zoveel mogelijk te beperken.</p>
<p>De lokatie is dit keer aangrenzend aan het station en hierdoor extra makkelijk te bereiken met het openbaar vervoer. Loop het Centraal Station uit aan de centrumkant. De entree van Creative Valley bevindt zich rechts van Albert Heijn, tegenover Boots. <a href="https://www.creativevalley.nl/images/downloads/route/CV_U_CS_Routebeschrijving_V002A.pdf">Klik hier voor een volledige routebeschrijving (pdf)</a>.
We zitten in ruimte <a href="https://www.creativevalley.nl/collectiv/ruimtes/the-workshop">The Workshop</a>.
De vergaderruimte is goed bereikbaar met een lift en zit om de hoek van een gehandicaptentoilet. Er is voor zover wij weten geen ringleiding aanwezig.</p>
<p>Het staat leden tot het begin van de ALV vrij voorstellen voor de agenda in te dienen. De voorlopige agenda staat hieronder. Wat in ieder geval zal worden behandeld zijn de jaarstukken van de vereniging over 2018, de financiën over 2019 en de nieuwe begroting voor 2020. Deze stukken zullen enkele dagen voor de ALV naar alle aangemelde aanwezigen worden opgestuurd. Mocht je niet aanwezig kunnen zijn, maar deze informatie wel willen inzien: laat het ons weten!
Notulen van de avond worden altijd zo snel mogelijk na de vergadering online gedeeld.</p>
<h2>Voorlopige agenda</h2>
<ul>
<li>Opening</li>
<li>Jaarrekening 2018</li>
<li>Bevindingen kascommissie</li>
<li>Benoeming nieuwe kascommissie</li>
<li>Financiën 2019</li>
<li>Begroting 2020</li>
<li>Herbenoeming Sander Vink</li>
<li>Toelichting commissies</li>
<li>Evaluatie congres</li>
<li>Evaluatie W3C-lidmaatschap</li>
<li>Presentatie nieuwe branding</li>
<li>Rondvraag</li>
<li>Sluiting</li>
</ul>
<h2>Aanmelden</h2>
<p>Ben je van plan te komen, dan vragen we je vriendelijk je hieronder hiervoor in te schrijven, zodat we enigszins een idee hebben van de verwachte opkomst.</p>
<h2>English version</h2>
<p>Friday evening, the 29th of november we will have our annual membership meeting (ALV) in Utrecht! All members of Fronteers are welcome to sign up to join us. The meeting will take place at the Collectiv (location Creative Valley), which sits directly besides the Utrecht Central Station.</p>
<p>For people joining us directly from work or other obligations we will have a small buffet ready at 18:00 (with fish, meat, and vegetarian options - sandwiches, a soup and a warm item). The meeting itself will commence at 18:30. We expect the total meeting to take two hours, but we know from experience that it can run late. We will make a conscious effort to try and avoid this.</p>
<p>Is this your first time at the (or an) ALV (membership meeting)? The legal form of Fronteers is a dutch 'vereniging', which means we are obligated to have a meeting once a year with the board, volunteers and members to present and discuss the (financial) state of Fronteers. We will evaluate how Fronteers is doing and discuss what we can do to improve. Until the actual start of the meeting, any member can propose a topic for the agenda to be discussed and voted on by all present members.</p>
<p>The meeting will take place at Collectiv (location Creative Valley), which sits directly besides the Utrecht Central Station and is easy to reach with public transport. Exit the station by following the 'centrum' signs. The entrance of Creative Valley is to the right of the Albert Heijn supermarket, accross from a Boots pharmacy. <a href="https://www.google.com/maps/place/Creative+Valley+UCS/@52.0910516,5.1082429,17z/data=!3m1!4b1!4m5!3m4!1s0x47c66f63ca43903b:0x283dbd4a2edcd271!8m2!3d52.0910516!4d5.1104316">Map of the location (GoogleMaps)</a>.
We'll be in the space called <a href="https://www.creativevalley.nl/collectiv/ruimtes/the-workshop">The Workshop</a>.
There is an elevator present and there is an accessible toilet around the corner from the meeting room. As far as we know there is no ring line system present.</p>
<p>Below, you'll find the provisional program of the evening. The financial documents of 2018, 2019 and 2020 will be discussed and sent in advance to everyone that signed up for the ALV. If can't attend but (as a member) want to get a copy of the documents, please <a href="mailto:penningmeester@fronteers.nl">send an e-mail to our treasurer</a>.</p>
<h2>(Provisional) Agenda</h2>
<ul>
<li>Opening</li>
<li>Financial Statements 2018</li>
<li>Findings of the treasury committee</li>
<li>Naming of the new treasury committee</li>
<li>Finances of 2019</li>
<li>Budget for 2020</li>
<li>Report of committees</li>
<li>Evaluation of the conference</li>
<li>Evaluation of our first year of W3C-membership</li>
<li>Presentation of our new branding</li>
<li>Round of questions</li>
<li>Close</li>
</ul>
</content>
</entry>
<entry>
<title>Schrijf mee aan de Adventskalender 2019!</title>
<link href="https://www.fronteers.nl/nl/blog/2019/10/schrijf-mee-aan-de-adventskalender-2019"/>
<updated>2019-10-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/10/schrijf-mee-aan-de-adventskalender-2019</id>
<content xml:lang="nl" type="html"><p>De Fronteers Adventskalender is terug! 24 blogs van 24 schrijvers over uiteenlopende front-end onderwerpen. Wil jij graag een blog schrijven voor Fronteers, meld je nu dan aan. Tot 31 oktober kan iedereen een voorstel indienen voor een blog. Schrijvers mogen een donatie van 75 euro uit de verenigingskas doen aan een goed doel.</p>
<ul>
<li>English below -</li>
</ul>
<p>Je mag schrijven over elk onderwerp dat front-end gerelateerd is. Denk bijvoorbeeld aan blogs over accessibility, tools, UX/UI, frameworks. Wil je schrijven over iets dat je geleerd hebt dit jaar, of wil je juist dit moment aangrijpen om zelf iets nieuws te leren en daarover te schrijven? Het kan allemaal. Blogs mogen in het Nederlands of Engels geschreven worden, met een voorkeur voor Nederlands.</p>
<p>Aanmelden om mee te schrijven kan tot en met 31 oktober via marketing@fronteers.nl of door het onderstaande formulier in te vullen. We ontvangen daarbij graag een onderwerp/titel, in welke taal je wilt schrijven en een korte uitleg waar het artikel over zal gaan. In de eerste week van november maken we de schrijvers bekend. Maandag 25 november is de deadline voor het aanleveren van je artikel.</p>
<p>Namens de auteurs zal Fronteers een donatie van 75 euro per schrijver aan een goed doel doen. De schrijvers mogen zelf kiezen uit een van deze goede doelen: Hersenstichting, KWF, KiKa, Bits of Freedom of Stem op een Vrouw. Er is dit keer een keuze gemaakt uit een aantal goede doelen om onze penningmeester wat werk uit handen te nemen.</p>
<h2>English</h2>
<p>The Fronteers Advent Calendar is back! 24 writers and 24 blog posts about various front-end topics. If you want to write one of these blog posts, you can sign up now. Everybody can send in a proposal, until October 31st. All writers can donate 75 euros from the association to a charity.</p>
<p>You may write about every topic related to front-end development. For example, about accessibility, tools, UX/UI, frameworks. Blog posts can be written in English or Dutch.</p>
<p>You can send in your proposal until October 31st by mailing to marketing@fronteers.nl or by filling in the form below. We would like to receive a topic/title, language and a short synopsis of your blog post. In the first week of november we'll announce the writers for this years advent calendar. The deadline for sending in your blog post is november 25th.</p>
<p>On behalf of the authors, Fronteers will donate 75 euros for each writer to a charity of their choice. Writers can choose between one of these charities: Hersenstichting, KWF, KiKa, Bits or Freedom or Stem op een Vrouw. This year we made a selection of charities to make our treasurer's job a bit easier.</p>
</content>
</entry>
<entry>
<title>Diversiteit/Inclusie en Fronteers</title>
<link href="https://www.fronteers.nl/nl/blog/2019/10/diversiteit-inclusie-en-fronteers"/>
<updated>2019-10-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/10/diversiteit-inclusie-en-fronteers</id>
<content xml:lang="nl" type="html"><p>Fronteers heeft dit jaar een aantal dingen achter de schermen opgepakt die een investering vormen voor de toekomst van de vereniging. Zo hebben we een aantal merk-identiteitssessies gedaan om het DNA van de vereniging te ‘vinden’. Daar kwam onder andere uit dat toegankelijkheid (in de breedste zin van het woord) erg belangrijk voor ons is als vereniging.</p>
<p>We bedoelen daar niet alleen web-accessibility mee. Het verwelkomen en op weg helpen van nieuwe leden en collega’s, het faciliteren van kennisdeling, en het organiseren van netwerkevents en congres hebben allemaal gemeen dat iedereen die dingen met webtechnieken dingen doet zich in principe welkom moet voelen bij Fronteers. Het web is voor iedereen, en wij zijn dat ook! Het moet niet uitmaken wat je afkomst, geaardheid en kleur is of dat je een beperking hebt.</p>
<p>De wens om open en inclusief te zijn is er altijd geweest, maar goede bedoelingen alleen leiden niet vanzelf tot een cultuur waar het compleet vanzelfsprekend is om met iedereen rekening te houden. Daar brengen we als Fronteers graag verandering in!</p>
<p>Daarom hebben we in juni met een aantal (niet)-vrijwilligers een avond gepraat over het thema diversiteit en inclusie, om niet in de laatste plaats eens kritisch naar onszelf te kijken. Daar kwamen een aantal aanbevelingen uit die we delen met de verschillende commissies.</p>
<h2>De belangrijkste punten</h2>
<ul>
<li>de code of conduct die we nu voor het congres hebben, en de aparte code of conduct die we voor Slack hebben, willen we na een redactieslag breder trekken zodat deze voor alle bijeenkomsten van Fronteers geldt.</li>
<li>als we een bijeenkomst of evenement organiseren, willen we dat de lokatie zo toegankelijk mogelijk is. Dit zouden we het liefst toetsen met behulp van een door een commissie samen te stellen document. Hiernaast willen we bij de aankondiging van de bijeenkomst duidelijk communiceren welke faciliteiten er beschikbaar zijn zodat ieder de eigen geinformeerde keuze kan maken of zij gaan deelnemen aan het evenement. Het zou helemaal fantastisch zijn als geinteresseerden ook gemakkelijk kunnen doorgeven wat hun reden is om niet te komen, zodat we hiervan kunnen leren.</li>
</ul>
<h2>Commissie</h2>
<p>Wat we heel graag willen is een commissie Diversiteit en Inclusie vormen met een mix van ervaringsdeskundigen en experts uit de accessibility-wereld die samen ervaring en kennis kunnen combineren.</p>
<p>De kerntaken van de commissie zouden dan het eerste jaar als volgt zijn:</p>
<ul>
<li>vormen van een team (en aanmoedigen van ervaringsdeskundigen tot deelname)</li>
<li>adviseren en uitdagen van het bestuur</li>
<li>aanmaken van een checklist voor het voorbereiden van bijeenkomsten, workshops en congres (lokatie, voeding, etc)</li>
<li>bloggen over dit thema voor of namens Fronteers voor kennisdeling</li>
<li>andere commissies helpen met best practices en bijstaan bij morele/ethische dilemma's (de beste keuze is soms niet de makkelijkste!)</li>
</ul>
<p>Zou je graag deel willen nemen aan dit initiatief en denk je dat je een bijdrage kan leveren aan bovenstaande? We kunnen je hulp goed gebruiken. <a href="mailto:bestuur@fronteers.nl">Stuur een e-mail naar het bestuur</a>.</p>
</content>
</entry>
<entry>
<title>Met korting naar performance.now()</title>
<link href="https://www.fronteers.nl/nl/blog/2019/09/met-korting-naar-performance-now"/>
<updated>2019-09-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/09/met-korting-naar-performance-now</id>
<content xml:lang="nl" type="html"><p>Op 21 en 22 november organiseert Web Conferences Amsterdam voor de tweede keer <a href="https://perfnow.nl/">performance.now()</a>; opnieuw met 14 sessies over de stand van zaken in front-end performance.</p>
<p>Fronteers-leden krijgen korting op dit congres. Ze betalen 550 in plaats van 650 euro voor een kaartje (exclusief BTW). Het aanbod is geldig voor mensen die op dit moment al lid zijn, en je kunt ervan gebruik maken door<a href="mailto:bestuur@lists.fronteers.nl"> een email naar het bestuur</a> te zenden. Je ontvangt dan een kortingscode waarmee je je kaart kunt kopen.</p>
<p>Uitgekozen door program co-chairs <a href="https://timkadlec.com/">Tim Kadlec</a> en <a href="https://tammyeverts.wordpress.com/">Tammy Everts</a>, zullen de sprekers een wijd gebied aan onderwerpen behandelen, inclusief JavaScript, CSS, performance culture, responsive design, performance budgets, frameworks, monitoring, browsers, mobile devices en perceived performance. (Excuus voor alle Engelse termen; zo gaat het nou eenmaal in de webwereld.)</p>
<p>Donderdag 21 en vrijdag 22 november, <a href="https://perfnow.nl/venue">Het Compagnietheater</a>, Amsterdam, en Fronteers-leden betalen 550 euro voor een kaart. Komt dat zien!</p>
</content>
</entry>
<entry>
<title>Fronteers vote for the W3C Advisory Board elections</title>
<link href="https://www.fronteers.nl/nl/blog/2019/05/fronteers-vote-for-the-w3c-advisory-board-elections"/>
<updated>2019-05-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/05/fronteers-vote-for-the-w3c-advisory-board-elections</id>
<content xml:lang="nl" type="html"><p>In May, W3C members are voting for seven seats on the Advisory Board. Since Fronteers is a W3C member, we also have a vote, which our representative Rachel Andrew will cast on behalf of us.</p>
<p>Still, we should provide Rachel with the vote she's going to cast. In order to do that we call all Fronteers members to cast their vote. The result of the internal Fronteers vote will be transmitted to Rachel.</p>
<p>This vote is only open to Fronteers members; if you're not a member you cannot vote.</p>
<p>The <a href="https://fronteersnl.slack.com/">Fronteers Slack</a> now contains a w3c-fronteers channel that is open only to members, and where questions can be asked and discussions can be held. Please ask for access in the general Fronteers channel.</p>
<h2>The Advisory Board</h2>
<p>The <a href="https://www.w3.org/2002/ab/">W3C Advisory Board</a> provides advice on general issues such as strategy, management, legal matters, process, and conflict resolution. Members serve in an individual capacity, and not as representatives of their parent organisations.</p>
<p>More details, as well as the current make-up of the Board can be found at <a href="https://www.w3.org/2002/ab/">the Advisory Board page</a>.</p>
<h2>Candidates</h2>
<p>The twelve candidates for the seven seats are:</p>
<ul>
<li>Tantek Çelik (Mozilla)</li>
<li>Heejin Chung (Samsung)</li>
<li>Elika J Etemad aka fantasai (W3C Invited Expert)</li>
<li>Aaron Gustafson (Microsoft)</li>
<li>Nigel Megitt (BBC)</li>
<li>Charles McCathie Nevile (ConsenSys) *</li>
<li>Avneesh Singh (DAISY Consortium)</li>
<li>Eric Siow (Intel)</li>
<li>Alan Stearns (Adobe)</li>
<li>Léonie Watson (TetraLogical) *</li>
<li>Chris Wilson (Google)</li>
<li>Judy (Hongru) Zhu (Alibaba) *</li>
</ul>
<p>An asterisk * denotes a current Advisory Board member who is up for reelection.</p>
<p>All candidates provided <a href="https://www.w3.org/2019/05/02-ab-nominations">statements</a> on what they hope to achieve.</p>
<h2>Voting procedure</h2>
<p>Fronteers members can mail their vote to <a href="mailto:secretaris@fronteers.nl">secretaris@fronteers.nl</a>. The vote should be an ordered list, with your personal top candidate coming first, your next candidate coming second, and so on.</p>
<p>After a membership check your vote will be added to the general pool. Your top candidate will get 12 points, your second candidate 11 points, etc. If you do not include all twelve candidates on your list, the missing candidates will get 0 points.</p>
<p>Fronteers voting closes on Monday 27th of May. The Fronteers board will create an ordered list, with the first candidate being the one who received most points, then the one with the second-most points and so on. Rachel Andrew will break any ties.</p>
<p>Rachel will cast the Fronteers vote later that week, before the W3C deadline of 30 May.</p>
<h2>Fronteers vote</h2>
<p>11 members voted, and the resulting Fronteers vote was the following, in this order:</p>
<ol>
<li>Elika J Etemad aka fantasai (W3C Invited Expert)</li>
<li>Léonie Watson (TetraLogical) *</li>
<li>Tantek Çelik (Mozilla)</li>
<li>Judy (Hongru) Zhu (Alibaba) *</li>
<li>Alan Stearns (Adobe)</li>
<li>Aaron Gustafson (Microsoft)</li>
<li>Chris Wilson (Google)</li>
<li>Avneesh Singh (DAISY Consortium)</li>
<li>Nigel Megitt (BBC)</li>
<li>Heejin Chung (Samsung)</li>
<li>Charles McCathie Nevile (ConsenSys) *</li>
<li>Eric Siow (Intel)</li>
</ol>
<h2>Results</h2>
<p>The <a href="https://www.w3.org/blog/news/archives/7762">result</a> of the full W3C vote was:</p>
<ul>
<li>Elika J Etemad aka fantasai (W3C Invited Expert)</li>
<li>Charles McCathie Nevile (ConsenSys) *</li>
<li>Avneesh Singh (DAISY Consortium)</li>
<li>Eric Siow (Intel)</li>
<li>Léonie Watson (TetraLogical)*</li>
<li>Chris Wilson (Google)</li>
<li>Judy (Hongru) Zhu (Alibaba)*</li>
</ul>
<p>Congratulations to all newly elected or re-elected AB members.</p>
</content>
</entry>
<entry>
<title>25% Fronteers-korting op nieuwe browser Polypane</title>
<link href="https://www.fronteers.nl/nl/blog/2019/05/25-procent-fronteers-korting-op-nieuwe-browser-polypane"/>
<updated>2019-05-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/05/25-procent-fronteers-korting-op-nieuwe-browser-polypane</id>
<content xml:lang="nl" type="html"><p>Fronteers-lid Kilian Valkhof heeft een browser gemaakt voor front-end ontwikkelaars: <a href="https://polypane.rocks/">Polypane</a>. In deze browser kan je als ontwikkelaar je site tegelijkertijd op verschillende devices en viewports zien, waardoor het ontwikkelen van responsive websites en apps gemakkelijker en beter gaat.</p>
<p>Leden krijgen 25% korting op een abonnement op de browser. De korting aanvragen kan door een mailtje te sturen naar <a href="mailto:bestuur@fronteers.nl">het bestuur</a> onder vermelding van &quot;korting Polypane&quot;. De korting blijft gedurende de looptijd van het abonnement actief!</p>
<p>Polypane is gebaseerd op Chromium en bevat naast de Chromium developer tools en de weergave van sites op meerdere formaten nog meer handige functies. Zo kan je direct een overzicht krijgen van je responsive breakpoints, kan je een screenshot genereren van alle apparaten en kan je snel layout-bugs oplossen met de CSS layout debugging tools. Voor meer informatie, kijk op <a href="https://polypane.rocks/">Polypane.rocks</a>.</p>
</content>
</entry>
<entry>
<title>Win een gratis kaartje voor Frontend United</title>
<link href="https://www.fronteers.nl/nl/blog/2019/05/win-een-gratis-kaartje-voor-frontend-united"/>
<updated>2019-05-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/05/win-een-gratis-kaartje-voor-frontend-united</id>
<content xml:lang="nl" type="html"><p>17 en 18 mei wordt de 10e editie van <a href="https://www.frontendunited.org/">Frontend United</a> georganiseerd, met topsprekers als Una Kravets, Jeremy Keith, Vitaly Friedman, Rachel Andrew, Lea Verou en Chris Lilley. Fronteers mag als hoofdsponsor 4(!) kaartjes verloten!</p>
<p>Frontend United is een jaarlijks congres waarbij de developer centraal staat, volledig gerund door vrijwilligers. Het doel is om developers en designers van verschillende achtergronden bij elkaar te brengen om kennis, ervaringen en ideeën te delen. Als lid voor Fronteers krijg je sowieso <a href="https://www.fronteers.nl/nl/blog/2019/03/met-korting-naar-frontend-united">20% korting op de kaartjes</a>.</p>
<p>Wil je kans maken op de gratis tickets? Het enige dat je hoeft te doen is reageren op deze blogpost. Je hoeft hiervoor geen lid te zijn van Fronteers. Op dinsdag 14 mei kiezen wij willekeurig 4 winnaars onder de inzendingen. Succes!</p>
</content>
</entry>
<entry>
<title>W3C Advisory Committee - initial report</title>
<link href="https://www.fronteers.nl/nl/blog/2019/05/w3c-advisory-committee-initial-report"/>
<updated>2019-05-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/05/w3c-advisory-committee-initial-report</id>
<content xml:lang="nl" type="html"><p>In April I headed to Quebec City in order to attend my first Advisory Committee (AC) Meeting on behalf on Fronteers. While I have been a CSS Working Group memeber for some time, as an Invited Expert I had no interaction with the AC, so this first meeting was a chance for me to discover how it functions and to start to build a plan for how I should gather information and share that with Fronteers.</p>
<p>The AC is a committee made up of a representative from each member organisation. Therefore I was attending the committee meetings as a representative of Fronteers. Below are a few notes. Some materials were classed as member only, however, and we need to find a way to share these materials with Fronteers members only.</p>
<h2>Pre-meeting Day</h2>
<p>There was a session before the meeting designed for new representatives. It filled in some of the blanks for me about how the W3C, and the AC in particular operates, and allowed me to put faces to names of people I had seen mentioned in emails. The session was essentially a set of presentations about different parts of the W3C. It also helped me to understand how other representatives work within their organisations and the W3C.</p>
<h2>Day One</h2>
<p>The meeting runs as a series of presentations on a subject, after which members who have questions or comments queue at the mic to ask their question. Some materials presented are made publicly available, others are member only. The <a href="https://www.w3.org/2019/04/w3c-highlights/Overview.html">Strategic Highlights Overview</a> is public.</p>
<p>There was a good discussion about diversity in the W3C. Of particular use to me was the discussion <em>A, B, C's of being an AC rep</em>, which included questions such as:</p>
<ul>
<li>&quot;How do I weigh in on something that I don't understand?&quot;</li>
<li>Importance of voting</li>
<li>How information gets circulated by the AC Rep between their boss/colleagues and W3C</li>
</ul>
<p>This third issue is the one I think we need to think about, as being a representative of a volunteer organisation is not a usual thing in the W3C, and we have to figure out how to do this. That process in itself may be useful for any future organisation who wishes to follow our lead.</p>
<p>[Fronteers note: we will get back to this topic eventually, but right now we're not totally sure how to set this up.]</p>
<p>I presented on What's New In CSS, during a set of lightning talks on Day 1. You can find <a href="https://noti.st/rachelandrew/Kr6L2U/whats-new-in-css">my slides here</a>.</p>
<h2>Day Two</h2>
<p>I had to leave to catch a flight at lunch time on Day 2, to an event booked prior to my taking up the role with Fronteers. However, as it happened, much of the meeting happened before lunch. There was a very interesting discussion led by the Chinese Interest Group, they described the Quick Apps and Mini Apps which share some features of PWAs.</p>
<p>There was discussion of the W3C Patent Policy and also horizontal review of specifications. There was an interesting discussion on privacy issues. The <a href="https://www.w3.org/Privacy/">Privacy Interest Group</a> (PING) are keen to involve people who have an interest in privacy matters. There was also a session on Web Authentication.</p>
<p>After this I left to get stuck in a snowstorm for hours at Quebec airport!</p>
<h2>Using the Fronteers Vote</h2>
<p>Most people at the AC meeting are the representative of a company or organisation which is a W3C member, and have routes within their company to transmit information. Fronteers is a little different, and we will have to find a way of making decisions and then transmitting them to me. This is especially urgent when it comes to voting for Advisory Board members. That vote is coming up; the deadline is 30 May.</p>
<p>[Fronteers note: We'll publish a separate blog post about the AB voting. Meanwhile, members should take a look <a href="https://www.w3.org/2019/05/02-ab-nominations">at this page</a>, where the candidates and procedure are presented. You have a vote on this!]</p>
<h2>The Next Meeting</h2>
<p>The next AC Meeting will be at TPAC on 16-20 September in Fukuoka, Japan. The CSS Working Group will also meet that week. I will attend and send a similar report to Fronteers.</p>
</content>
</entry>
<entry>
<title>Donderdag 4 april: Dag van Front-end Development</title>
<link href="https://www.fronteers.nl/nl/blog/2019/04/donderdag-4-april-dag-van-front-end-development"/>
<updated>2019-04-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/04/donderdag-4-april-dag-van-front-end-development</id>
<content xml:lang="nl" type="html"><p>Fronteers roept donderdag 4 april (4-04) uit tot de Dag van Front-end Development, een feestelijke dag om het beroep van front-end developer te vieren. Op deze dag organiseert Fronteers een aantal meetups voor front-end developers om nieuwe mensen en vakgenoten te leren kennen. In Den Haag, Eindhoven, Enschede, Groningen en Nijmegen kunnen vakgenoten en geīnteresseerden elkaar ontmoeten onder het genot van een hapje en drankje.</p>
<p>‘In steeds meer organisaties zijn front-end developers aanwezig,’ vertelt Anneke Sinnema, voorzitter van Fronteers. ‘Een front-end developer werkt aan hetgeen jij als gebruiker ziet aan een website of (web-)applicatie. Daarmee is een front-end developer de spil tussen gebruikers, vormgevers en back-end developers. Om hierbij stil te staan, roept Fronteers 4 april uit tot Dag van Front-end Development. Dit wordt een vrolijke, feestelijke dag om het beroep van front-end development te vieren. Front-enders kunnen deze dag vieren bij een van de <a href="https://www.fronteers.nl/nl/blog/2019/03/fronteers-organiseert-vijf-casual-meetups">meetups</a> die wij op 4 april organiseren.’</p>
</content>
</entry>
<entry>
<title>Fronteers organiseert vijf casual meetups</title>
<link href="https://www.fronteers.nl/nl/blog/2019/03/fronteers-organiseert-vijf-casual-meetups"/>
<updated>2019-03-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/03/fronteers-organiseert-vijf-casual-meetups</id>
<content xml:lang="nl" type="html"><p>Op donderdag 4 april 2019 houdt Fronteers op vijf locaties tegelijk een borrel voor front-end developers en hen die dat willen worden. De meetups zijn open en informeel en opgezet om nieuwe mensen en vakgenoten te ontmoeten onder het genot van een hapje en een drankje. Iedereen is uitgenodigd, ook als je niet lid bent van Fronteers.</p>
<p>In Groningen, Eindhoven, Enschede, Nijmegen en Den Haag verwelkomen respectievelijk Joël, Koen, Anneke, Josee en Jewwy je in een lokale gelegenheid om samen met jou en collega's een drankje te doen.</p>
<p>Je bent vanaf 19:00 welkom bij een van de volgende locaties:</p>
<p>(Eerste drankje is op rekening van Fronteers!)</p>
<ul>
<li>Groningen: Devhouse Spindle (met <a href="https://twitter.com/pm5544">Joël Kuijten</a>) <a href="https://www.meetup.com/nl-NL/Fronteers-NL/events/259726189/">Meld je aan</a></li>
<li>Eindhoven: The Commons Restaurant (met <a href="https://twitter.com/koenkivits">Koen Kivits</a>) <a href="https://www.meetup.com/nl-NL/Fronteers-NL/events/259726277/">Meld je aan</a></li>
<li>Enschede: Perron 22 (met <a href="https://twitter.com/asinnema">Anneke Sinnema</a>) <a href="https://www.meetup.com/nl-NL/Fronteers-NL/events/259726351/">Meld je aan</a></li>
<li>Nijmegen: Guesthouse Vertoef (met <a href="https://twitter.com/codergirlNL">Josee Wouters</a>) <a href="https://www.meetup.com/nl-NL/Fronteers-NL/events/259726410/">Meld je aan</a></li>
<li>Den Haag: MingleMush (met <a href="https://twitter.com/jewwyq">Jewwy Qadri</a>) <a href="https://www.meetup.com/nl-NL/Fronteers-NL/events/259726132/">Meld je aan</a></li>
</ul>
<p>ENGLISH:</p>
<p>On Thursday the 4th of April 2019 Fronteers is hosting a meetup in 5 different locations at the same time. If you are a front-end Developer, aspire to be one or work in the field of front-end, you are all welcome to join us for drinks. These meetups are welcoming and informal and are setup to meet new people and mingle, there will be no presentations or loud music. Everyone is invited, even non Fronteers members!</p>
<p>In Groningen, Eindhoven, Enschede, Nijmegen and Den Haag some great people from Fronteers will be welcoming you for a nice evening with chats and drinks. Join us from 19:00 h in one of the following locations.</p>
<p>(Note: First drink is on Fronteers!)</p>
<ul>
<li>Groningen: Devhouse Spindle (hosted by <a href="https://twitter.com/pm5544">Joël Kuijten</a>) <a href="https://www.meetup.com/nl-NL/Fronteers-NL/events/259726189/">RSVP</a></li>
<li>Eindhoven: The Commons Restaurant (hosted by <a href="https://twitter.com/koenkivits">Koen Kivits</a>) <a href="https://www.meetup.com/nl-NL/Fronteers-NL/events/259726277/">RSVP</a></li>
<li>Enschede: Perron 22 (hosted by <a href="https://twitter.com/asinnema">Anneke Sinnema</a>) <a href="https://www.meetup.com/nl-NL/Fronteers-NL/events/259726351/">RSVP</a></li>
<li>Nijmegen: Guesthouse Vertoef (hosted by <a href="https://twitter.com/codergirlNL">Josee Wouters</a>) <a href="https://www.meetup.com/nl-NL/Fronteers-NL/events/259726410/">RSVP</a></li>
<li>Den Haag: MingleMush (hosted by <a href="https://twitter.com/jewwyq">Jewwy Qadri</a>) <a href="https://www.meetup.com/nl-NL/Fronteers-NL/events/259726132/">RSVP</a></li>
</ul>
</content>
</entry>
<entry>
<title>Met korting naar Frontend United</title>
<link href="https://www.fronteers.nl/nl/blog/2019/03/met-korting-naar-frontend-united"/>
<updated>2019-03-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/03/met-korting-naar-frontend-united</id>
<content xml:lang="nl" type="html"><p>Op 17 en 18 mei vindt <a href="https://www.frontendunited.org/">Frontend United</a> in Utrecht plaats. Onder de eerste sprekers bevinden zich helden als Jonathan Snook, Vitaly Friedman, Rachel Andrew, Jeremy Keith, Una Kravets, Lea Verou en Chris Lilley.</p>
<p>Leden van Fronteers krijgen 20% korting op de toch al betaalbare tickets. Het aanbod is geldig voor mensen die op dit moment al lid zijn. Door een <a href="mailto:bestuur@lists.fronteers.nl">e-mail naar het bestuur</a> te sturen, kun je hier gebruik van maken. Je ontvangt dan een speciale link waar je je congrestickets kunt kopen.</p>
<p>Op de donderdag voor de conferentie (16 mei) zijn <a href="https://www.frontendunited.org/workshops">workshops</a> te volgen, van ondermeer Vitaly Friedman, Rachel Andrew en Lea Verou. Je hoeft geen ticket te hebben voor de conferentie om een ticket voor de workshops te kopen.</p>
<p>Frontend United is een jaarlijks congres, volledig gerund door vrijwilligers, waarbij de developer centraal staat. Het doel is om front-end developers en designers van verschillende achtergronden bij elkaar te brengen om kennis, ervaringen en ideeën te delen.</p>
</content>
</entry>
<entry>
<title>Denk mee over de toekomst van Fronteers</title>
<link href="https://www.fronteers.nl/nl/blog/2019/02/denk-mee-over-de-toekomst-van-fronteers"/>
<updated>2019-02-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/02/denk-mee-over-de-toekomst-van-fronteers</id>
<content xml:lang="nl" type="html"><p>Op 15 februari deed een select groepje Fronteers-leden mee met een identiteitssessie om te onderzoeken waar we ons met Fronteers op zouden moeten focussen. Het was een ontzettend waardevolle (en leuke) avond!</p>
<p>We hebben in kleine groepjes onze visie gegeven over stellingen op het gebied van de front-end wereld. Hoe ziet ons vak er in de toekomst uit? Wat begrijpen onze werk- en opdrachtgevers minder goed? Wat zijn dingen waar we niet zonder kunnen? Wat is uniek aan onze community? En wat hebben front-enders volgens ons écht nodig om hun werk in de toekomst goed te kunnen doen?</p>
<p>Binnenkort volgt er een vervolgsessie waarin we de resultaten van deze sessie gaan bespreken. Maar voor het zover is, willen we graag van jou als lid of niet-lid horen hoe jij tegen bepaalde zaken aankijkt. Ready for Branding, de partij die we hebben ingeschakeld voor deze sessie, heeft een korte vragenlijst voorbereid. Doe je mee? Het kost je maximaal vijf minuten.</p>
<p><a href="https://fannyevers.typeform.com/to/ENwnlf">Vul de enquete hier in</a></p>
<p>Alvast bedankt! We houden je op de hoogte van de resultaten via het blog en onze social media.</p>
</content>
</entry>
<entry>
<title>Looking back at the Fronteers Ladies Dinner</title>
<link href="https://www.fronteers.nl/nl/blog/2019/02/looking-back-at-the-fronteers-ladies-dinner"/>
<updated>2019-02-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/02/looking-back-at-the-fronteers-ladies-dinner</id>
<content xml:lang="nl" type="html"><p>It was months ago when Anneke approached me with the idea to organize a ladies dinner for frontend developers. I was definitely excited and wanted to be a part of it. Not because nowadays it’s common to organize an IT event with special motivation for women, but I just really miss to have a cozy chat with women.</p>
<p>We were twelve women in the room from at least four different nationalities. Hey! I know what you’re thinking, but I can assure you that Netherlands has more than twelve female frontend developers. The night started at 18:00, we started eating ~19:30 and we had a nice chat until 22:00. This was the summary of the night by numbers. I know... This a boring habit from work. I cannot stop organizing my thoughts with bullets, numbers, etc.</p>
<p>What did it really mean for me? First of all, I was proud of all those smart and strong willed women. If you follow an IT career, it’s common to get an advice to change your path to become a sales person or manager with the reasoning that programming is too geeky for you. I felt normal when everyone admitted experiencing impostor syndrome once in a while. It was funny that most of us felt a sort of guilt while discussing our salary. I was so happy to discover all new and interesting game and movie suggestions, puzzled when the waiter gave a nice introductory speech for the people who ordered cheese and then laughed so hard when he came up with this funny and imaginary story about crème brûlée when I insisted for an explanation. It was refreshing to observe the commonalities of our challenges and realized that I started to ignore them just because I’m the minority.</p>
<p>Last but not least, I was glad to be a part of this dinner and I would like to thank Fronteers for its special support.</p>
</content>
</entry>
<entry>
<title>Met korting naar CSS Day</title>
<link href="https://www.fronteers.nl/nl/blog/2019/02/met-korting-naar-css-day"/>
<updated>2019-02-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/02/met-korting-naar-css-day</id>
<content xml:lang="nl" type="html"><p>Op 13 en 14 juni organiseert Web Conferences Amsterdam voor de zevende keer <a href="https://cssday.nl/">CSS Day</a>. Dit jaar is het congres uitgebreid met een UI Special op de donderdag, gevolgd door de eigenlijke CSS Day op vrijdag.</p>
<p>Zoals eveneens al zeven jaar het geval is, krijgen Fronteers-leden korting op dit congres. Ze betalen 500 in plaats van 600 euro voor een kaartje voor beide dagen, of 275 in plaats van 325 voor een eendagskaartje (alle bedragen exclusief BTW). Het aanbod is geldig voor mensen die op dit moment al lid zijn, en je kunt ervan gebruik maken door <a href="mailto:bestuur@lists.fronteers.nl">een email naar het bestuur</a> te zenden. Je ontvangt dan een kortingscode waarmee je je kaart kunt kopen.</p>
<p>Op UI Special kan je <a href="https://cssday.nl/2019/speakers">grote namen</a> als Jared Spool, Brad Frost, en Josh Clark verwachten, maar ook ten onrechte minder bekende namen als Başak Haznedaroğlu en Hakim El Hattab. Zij zullen een brede waaier van UI-gerelateerde zaken bespreken.</p>
<p>CSS Day zelf staat gedeeltelijk in het teken van de verhouding tussen CSS en JavaScript; Natalya Shelburne en Lara Schenck zullen hier een presentatie over geven, terwijl <a href="https://cssday.nl/2019/speakers">andere sprekers</a>, zoals fantasai of Steve Schoger er wellicht ook wat aandacht aan zullen besteden. Het is tenslotte een hot topic.</p>
<p>Donderdag 13 en vrijdag 14 juni, <a href="https://cssday.nl/2019/venue">Het Compagnietheater</a>, Amsterdam, en Fronteers-leden betalen 500 euro voor een tweedaagse kaart. Komt dat zien!</p>
</content>
</entry>
<entry>
<title>Fronteers and W3C - first quarterly report</title>
<link href="https://www.fronteers.nl/nl/blog/2019/02/fronteers-and-w3c-first-quarterly-report"/>
<updated>2019-02-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/02/fronteers-and-w3c-first-quarterly-report</id>
<content xml:lang="nl" type="html"><p>Last week our W3C representative, Rachel Andrew, came to Amsterdam to talk about her W3C work and give an interesting workshop; essentially giving her first quarterly report. This post gives a quick overview based on the notes I took during the discussion.</p>
<p>On Thursday we <a href="https://meetup.com/Fronteers-NL/events/258152423/">met up</a> at <a href="https://www.werkspot.nl/">Werkspot</a>. With 43 reservations and an actual turnout of 31, we had a no-show of only 25%, which is not bad for a free event.</p>
<p>Rachel first gave a <a href="https://noti.st/rachelandrew/9R7PMY">presentation</a> about the specifications W3C is currently working on. Then we seamlessly moved into a discussion of first the details of some specs, then the details of Fronteers' involvement in W3C, and finally the goals and expectations we at Fronteers have of our membership.</p>
<p>The audience loved the idea of a meet-up about upcoming specs, and about understanding those specs. The Friday workshop (see below) was also considered an excellent idea, and there was a clear demand for more of this sort of content, as well as blog posts. Web developers need more skills in understanding specifications.</p>
<p>So we're going to organise more meet-ups and workshops around W3C specifications. <a href="https://www.meetup.com/Fronteers-NL/">Subscribe to our Meetup channel</a> to stay informed. (And don't be afraid of occasional Dutch texts; all W3C-themed activities will take place in English.)</p>
<p>Communications and discussions about our W3C membership take place on our <a href="https://fronteersnl.slack.com/">Slack channel</a>. Although most of our channels are in Dutch, the W3C channel is entirely in English. Rachel participates in the discussions as well. Non-members are explicitly invited to <a href="https://fronteers-slack.herokuapp.com/">join</a> - the more people we have, the better we can function.</p>
<h2>Our membership</h2>
<p>We spent part of the time on outlining how our membership is going to work in practice.</p>
<p>Rachel will notify us of interesting upcoming specs, or important changes to existing ones. Also, she will spend time figuring out what's going on at W3C, and identifying issues that Fronteers should have an opinion on. Fronteers opinions count as web developers' opinions, and W3C loves feedback from the field. Therefore it could be that our opinions carry more weight than our formal vote would suggest.</p>
<p>We have one vote out of 451 at W3C. Rachel will cast that vote, but Fronteers members can instruct her how to cast our vote. The issue here is that there isn't all that much voting going on. Rachel is going to find out how much there actually is.</p>
<p>Occasionally there appears to be a vote in the Advisory Committee, where Rachel is our representative as well. The AC discusses policies for W3C as a whole, but the details are unclear at this moment. Fortunately there is a course for new AC members, and Rachel is going to participate. She'll likely have a better understanding of what the AC actually does after she's done.</p>
<p>W3C does not vote on specifications. Instead, it uses an objection-based system. That is, members can object to a spec, or even a feature. If that happens, the objections are discussed and resolved, if possible. If no one has objections (and that's usually the case), the spec moves on. Usually it's browser vendors that object.</p>
<p>Theoretically, Fronteers could raise objections. This is simultaneously a very powerful and a very annoying thing to do, and raising objections over minor issues will get you taken less seriously by other members. Therefore this should be an action of last resort, and not something to be used on a whim. Still, if the situation is just right, Rachel might use our objection to call for a pause in order to get more web developer feedback - but if she does so, we're supposed to deliver good, to-the-point, reality-grounded feedback.</p>
<p>Also, we might use our influence and the formal W3C procedures to stop one browser from being able to define how the web should be - if that should become necessary.</p>
<h2>Fronteers tasks</h2>
<p>Other than supporting Rachel, Fronteers can do a few more quite important things. We need to gear up to fulfill our role as representatives of web developers. We need a larger cohort of people involved in the spec-creation process that Rachel can warn if something important is coming up. We also need to know what we're talking about, which means studying the specs. This, and not voting or raising objections, is the meat of our membership.</p>
<p>Another important issue is creating test cases and test suites. Theoretically, a specification is supposed to have a full test suite that browser vendors can use to test their implementation. In practice - not so much. The spec writers don't have a lot of time, and volunteers are hard to find because writing good tests is really really hard. (I should know; I've done it for fifteen years.) On tbe plus side, writing tests is an excellent way to really get to know a specification.</p>
<h2>Outreach to JavaScripters</h2>
<p>Fronteers has a secondary objective with our W3C membership: growing our own membership. One section of the web development world that's somewhat underrepresented at Fronteers is JavaScript developers. We could use our W3C membership to reach out to them.</p>
<p>Although ECMA, and not W3C, sets the direction of JavaScript the language, W3C still specifies some JavaScript APIs such as Houdini or the CSS Object Model, which are also interesting to JavaScripters. Also, the CSS-in-JS discussion that's currently going on can be traced back to the fact that currently there is no good way of organising your CSS declarations. This is something W3C could conceivably do something about. Also, this is something we could organise a meet-up around, maybe together with <a href="https://www.meetup.com/AmsterdamJS/">AmsterdamJS</a>. (Also, too, maybe we should consider an ECMA membership in the long run?)</p>
<h2>Workshop spec reading</h2>
<p>On Friday, Rachel gave her first Spec Workshops, where we read the entire <a href="https://drafts.csswg.org/css-multicol/">Multicol Editor's Draft</a> and gave detailed feedback. (Note that the draft has already changed in order to accomodate part of what we discussed.)</p>
<p>This was very interesting, not only to us participants, but also to Rachel herself, whose attention was called to several problems she hadn't noted before; for instance with terminology, unclear sentences, wrong examples, and so on.</p>
<p>I didn't keep detailed notes during the workshop, so this brief summary will have to do. We did decide that this was definitely something we should repeat, since it yielded quite a bit of good, actionable feedback.</p>
<h2>Conclusion</h2>
<p>All in all Rachel's first quarterly report was a resounding success that gave us a lot of useful pointers for the next few months. Becoming an influential W3C member is going to be a lot of work, but we've done a tiny bit of that work last week.</p>
</content>
</entry>
<entry>
<title>Some sad news about Spring Conference</title>
<link href="https://www.fronteers.nl/nl/blog/2019/02/some-sad-news-about-spring-conference"/>
<updated>2019-02-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/02/some-sad-news-about-spring-conference</id>
<content xml:lang="nl" type="html"><p>Fronteers' <em>reason d’etre</em> is to support and educate front-end developers in the Netherlands. For this reason since 2007, we have held a yearly conference which over the last decade-and-a-bit has grown to attract more than 500 front-enders from all over Europe. In 2016, a one-off Spring Conference was held as a special event, and inspired by the success of that conference we were looking forward to hosting another on april 5th this year.</p>
<p>Unfortunately we have had to simmer down our ambitions and have had to make the difficult decision to cancel Spring Conference. The main reason is that our timing wasn't right: the amount of effort required to coordinate, organise, follow up and make decisions was more than the time we had available between re-energizing ourselves after the main conference and the holiday season. We were too late in getting all the materials necessary to announce ticket sales on time.</p>
<p>While selling tickets is important for any paid event, Fronteers is not a commercial enterprise. We organise meetups, conferences and workshops to help better our fellow developers and improve the tech climate in the Netherlands. It is important to us to do this right, or not at all. We should definately not attempt to sell tickets, and risk letting speakers down or having our attendees booking non-refundable hotel rooms. This is why we announce this cancellation today and not further down the road.</p>
<p>Naturally the speakers that agreed to come have been informed and will be covered for any costs made so far. People who bought an early bird ticket for Spring Conference will be given the choice to be reimbursed, or be given a discount for the conference in October.</p>
<p>Even though cancelling Spring Conference was an incredibly tough decision to make, especially for the conference committee that spent a lot of time on curating a wonderful line-up, we do know front-enders in the Netherlands aren’t left without some great alternatives to attend this spring and we heartily recommend them:</p>
<ul>
<li><a href="https://react.amsterdam/">React Amsterdam</a>, April 10-12, 2019, Kromhouthal, Amsterdam</li>
<li><a href="https://www.frontendunited.org/">Frontend United</a>, May 17-18, Utrecht</li>
<li><a href="https://cssday.nl/2019">CSS Day/UI Day</a>, June 13-14, Compagnietheater, Amsterdam (we are in the process of discussing a member discount for CSS Day, so please contact the board if you're interested to go!)</li>
</ul>
<p>In the meantime, the conference team has already started working on the line-up for the fall Fronteers Conference (to be held October 3 and 4)! <em>Watch this space for more news on that soon!</em></p>
</content>
</entry>
<entry>
<title>Fronteers is W3C lid</title>
<link href="https://www.fronteers.nl/nl/blog/2019/01/fronteers-is-w3c-lid"/>
<updated>2019-01-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/01/fronteers-is-w3c-lid</id>
<content xml:lang="nl" type="html"><p>Vorige week is Fronteers dan eindelijk officieel lid van W3C geworden, en is Rachel Andrew officieel onze vertegenwoordiger geworden, zoals we hebben besloten op de laatste ALV.</p>
<p>Er waren wat bureaucratische hikjes, waardoor het allemaal iets langer heeft geduurd dan gedacht, maar we zijn er nu toch echt. Kijk voor de grap eens <a href="https://www.w3.org/Consortium/Member/List#xF">hier op de W3C ledenlijst</a> of <a href="https://www.w3.org/Style/CSS/members.en.php3">op de CSS Working Group ledenlijst</a>. Staat cool, toch?</p>
<p>Fronteers is echter niet lid geworden omdat dat zo cool staat. We wilden zorgen dat front-end ontwikkelaars vertegenwoordigd worden in W3C - check. We wilden zorgen dat Rachel Andrew haar werk voort kan zetten - check. We willen op een of andere manier zorgen dat front-end ontwikkelaars wereldwijd zich meer betrokken gaan voelen bij het werk dat W3C doet - dit wordt een lange-termijnproject, dus nog geen check.</p>
<p>En wat willen we verder eigenlijk? Hoe gaan we front-enders wereldwijd meer betrekken? Willen we bepaalde CSS-ideeën sneller implementeren - of juist tegenhouden? Willen we een vinger in de pap en een vertegenwoordiger in de commissie voor meer dan alleen CSS?</p>
<p>Om deze en dergelijke vragen te bespreken, gaan we een serie meet-ups organiseren. De eerste daarvan staat al vast: <a href="https://www.meetup.com/Fronteers-NL/events/258152423/">donderdag 7 februari te Amsterdam</a>. Rachel zal een overzicht geven van haar werk bij W3C, en daarna gaan we in discussie over Fronteers en W3C, waarbij waarschijnlijk de bovenstaande vragen aan bod gaan komen.</p>
<p>Dus: schrijf je in. Of niet, maar denk dan in elk geval over de vragen na, en geef je antwoord in een comment of bij een latere meet-up.</p>
<p>In elk geval is dit hopelijk het begin van iets moois en goeds.</p>
</content>
</entry>
<entry>
<title>De eerste workshops van 2019</title>
<link href="https://www.fronteers.nl/nl/blog/2019/01/de-eerste-workshops-van-2019"/>
<updated>2019-01-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2019/01/de-eerste-workshops-van-2019</id>
<content xml:lang="nl" type="html"><p>Er zijn nog plaatsen beschikbaar bij de eerste workshops van 2019! Eind januari kun je met Phil Hawsworth het serverless landschap verkennen in <a href="https://www.fronteers.nl/workshops/workshop-netlify-static-site-generators">Netlify en static site generators</a>. Een maand later volgt een deep dive in <a href="https://www.fronteers.nl/workshops/progressive-web-apps">Progressive Web Apps</a>. Ook in 2019 krijgen leden 100 euro korting op de toegangsprijs, en betaal je dus slechts 150 euro voor een leerzame dagtraining!</p>
</content>
</entry>
<entry>
<title>Met Fronteers het nieuwe jaar in</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/met-fronteers-het-nieuwe-jaar-in"/>
<updated>2018-12-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/met-fronteers-het-nieuwe-jaar-in</id>
<content xml:lang="nl" type="html"><p>Het afgelopen jaar, mijn eerste jaar als voorzitter van Fronteers, was een veelbewogen jaar! Als doorsnee lid had ik geen idee van het werk dat er in zit om de vereniging draaiend te houden. Laat staan hoeveel energie er in gaat steken nieuwe initiatieven te ontplooien! Ik ben tevreden dat er zoveel gelukt is:</p>
<p>We waren in 2018 voor het eerst in een aantal jaar weer aanwezig op de <a href="https://newyear.isoc.nl/">ISOC nieuwjaarsborrel</a>, hielden een eigen nieuwjaars- en zomerborrel, een flink aantal succesvolle workshops, voor het eerst het <a href="https://fronteers.nl/congres/2018">Fronteers congres</a> in het DeLaMar theater, en we stemden tijdens de ALV vóór het voorstel om als Fronteers lid te worden van het W3C.
Ondertussen is het lidmaatschap van het W3C een feit en treffen Peter-Paul Koch en Thijs Reijgersberg de laatste voorbereidingen aan een speciale meetup met Rachel Andrew (onze toekomstige vertegenwoordigster binnen het W3C) voor een workshop spec-reading op 7 en 8 februari.</p>
<p>De rest van de vereniging zit ook niet stil: Zo is onze <a href="https://www.fronteers.nl/nl/vereniging/commissies/congres">congrescommissie</a> al druk bezig met het uitzoeken en uitnodigen van sprekers voor Spring Conference. Dit eendaags congres wordt in april gehouden. Ik mag nog niet zoveel verklappen, maar de vier sprekers die tot nu toe ja hebben gezegd zijn niet de minsten! <a href="http://tickets.fronteers.nl/">Ik zou het wel weten ;-)</a></p>
<p>In januari gaan het bestuur en het marketingteam samen een branding- en identiteitssessie doen. De <a href="https://www.areyoureadyfortakeoff.nl/work/fronteers-2016/">designers die je kent van de huisstijl van Fronteers Conference</a> gaan ons in het nieuwe jaar als overkoepelende vereniging helpen met het neerzetten van een huisstijl waar we de komende jaren herkenbaar mee voor de dag kunnen komen. Hier kijk ik ontzettend naar uit. Het congres is natuurlijk een paradepaardje van de vereniging, maar voor veel van onze internationale bezoekers lijkt het net alsof Fronteers en Fronteers Conference een en hetzelfde zijn. Het is hoog tijd dat we uit die schaduw stappen en ons wat meer laten zien!</p>
<p>Ook in het eerste kwartaal vindt er een <a href="https://www.fronteers.nl/nl/activiteiten/2019/ladies-dinner">Ladies' Dinner</a> plaats (donderdag 10 januari), en doen we op vrijdag 25 januari een kick-off voor de nieuw te vormen websitecommissie! Na druk gesprek op Slack is gebleken dat een aantal mensen (waaronder ikzelf) wel zin hebben om op een open source wijze aan de slag te gaan met een nieuwe website. Het is de bedoeling dat de commissie een vaste wekelijkse bijdrage doet (om het momentum te behouden) maar dat iedereen bij wijze van pull requests kan bijdragen. We hopen met bijzondere gasten dit proces aan te kleden op een leuke en leerzame manier! Lijkt dit je leuk, reageer dan even bij dit blogbericht.</p>
<p>En wat te denken van de workshops die nu al zijn ingepland voor het nieuwe jaar? Op 25 januari komt Phil Hawksworth over voor een <a href="https://fronteers.nl/workshops/workshop-netlify-static-site-generators">workshop over Netlify en Static Site Generators</a>. Netlify is een ultra-moderne webhost waar veel bekende collega-developers al tijden razendenthousiast over zijn. Een maand later, op 22 februari, komt Jad Joubran met een <a href="https://fronteers.nl/workshops/progressive-web-apps">workshop Progressive Web Apps</a>. En later in het jaar komt <a href="https://www.kassenaar.com/">Peter Kassenaar</a> langs om een Nederlandstalige vervolgworkshop te geven over Javascript.</p>
<p>Alleen al opsommen waar we op dit moment mee bezig zijn laat zien dat we druk zijn, en dan zijn er nog een aantal zaken waar het echt te vroeg voor is om ze aan te kondigen. Maar dat 2019 een goed jaar wordt voor de vereniging, daar twijfel ik niet aan! Jullie gaan het merken :-)</p>
<p>Mocht er in de loop van het jaar nog tijd, energie en menskracht over zijn, dan zou ik het zelf in ieder geval heel tof vinden om verder na te denken over wat Fronteers voor front-end developers kan betekenen. Een tijd geleden schreef ik bijvoorbeeld een voorsteltekst voor werkgevers die niet goed bekend zijn met ons expertisegebied - 'Hoe schrijf je een front-end vacature' - en daar hoop ik nog steeds iets meer mee te doen. Zo wordt er namelijk naar mijn idee in veel te veel vacatures gevraagd naar ervaring met tools, en niet naar basiskennis en kernkwaliteiten.</p>
<p>Ik vind het ook leuk om in mijn vrije tijd rustig om me heen te kijken naar de parallellen die te vinden zijn met andere (vak)verenigingen. Bijvoorbeeld de NVM, waarvan de beroepstitel makelaar (net als &quot;front-end developer&quot;) niet beschermd is (al was het dat bij hen ooit wel). Hoe gaan zij daar mee om, op welke manier houden zij zichzelf relevant? En welke dingen doet bijvoorbeeld een organisatie als het Keurmerk Kwaliteitsvakman voor hun leden waar wij iets van kunnen opsteken?
Moeten we aan bedrijven met kleine front-end teams meer consultancy taken aan gaan bieden? Bijvoorbeeld het uitvoeren van onafhankelijke code-reviews, usability-onderzoeken en webtoegankelijkheidstests? Moeten we een grotere rol spelen in het organiseren van meetups dan we nu doen?</p>
<p>Je merkt het: genoeg energie en ideëen om een positieve invulling te geven aan het verenigingswerk.
Mocht je hierover eens met me willen babbelen, kun je me vinden op <a href="https://www.fronteers.nl/blog/2016/02/fronteers-op-slack">Slack</a> en op <a href="https://twitter.com/asinnema">Twitter</a>!</p>
<h2>Over Anneke Sinnema</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/anneke.png" alt="Foto van anneke" class="floating-portrait" />
Anneke Sinnema is een freelance front-end developer uit Enschede. Met haar voorzitterschap van Fronteers probeert Anneke een positieve bijdrage te leveren aan het dagelijks werk van collega developers.
<p>Donatie
Mijn donatie gaat naar <a href="https://www.unicef.nl/wat-is-unicef-basics">Unicef</a>, als bijdrage voor hun actie om kinderen in het Syrisch oorlogsgebied te voorzien van kleding, dekens en en schoon water.</p>
</content>
</entry>
<entry>
<title>Fuck the system, be nice</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/fuck-the-system-be-nice"/>
<updated>2018-12-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/fuck-the-system-be-nice</id>
<content xml:lang="nl" type="html"><p>Het is de tijd voor de goede voornemens. Laat me je helpen een fijnere collega te worden met 5 Ware Waarheden om een leukere collega en een betere front-ender te zijn.</p>
<h2>TL;DR:</h2>
<ul>
<li>wees bescheiden</li>
<li>omring je niet met klonen van jezelf</li>
<li>deel je kennis</li>
<li>laat je inspireren door kunst</li>
<li>zeur niet</li>
</ul>
<h2>1: Jij bent niet je gebruiker</h2>
<p><img src="https://www.fronteers.nl/_img/adventskalender/assumption-is-the-mother-of-all-fuck-ups-576x576.png" alt="Tegeltje met de tekst: &quot;Assumption is the mother of all fuck ups&quot;" /></p>
<p>Eigenlijk zijn toegankelijkheidsrichtlijnen een grote les in nederigheid. Elk succescriterium is een herinnering: niet iedereen is zoals jij. Er zijn mensen die het web anders gebruiken dan jij. Ja echt, sorry. Je kunt nooit alle mogelijke scenario’s testen en ondervangen. Maar je kunt er wel rekening mee houden dat je site-bezoeker niet exact denkt of doet als jij verwacht.</p>
<p>Er zijn bijvoorbeeld mensen die amper een muis gebruiken en alles met een toetsenbord doen. Dus daarom test je of je site het doet met alleen toetsenbordbediening. Er zijn mensen die zo kippig zijn dat ze hun computer in hoog-contrastmodus gebruiken met een heel grote letter. Daarom gebruik je bijvoorbeeld schaalbare lettergroottes in plaats van pixels, want je wil dat de tekst fatsoenlijk meegroeit als de gebruiker inzoomt, om maar eens succescriterium 1.4.4 als voorbeeld te nemen. En je test of je site nog steeds begrijpelijk is als geen scripts of stylesheets geladen zijn. Er zijn volslagen idiote types – zoals ik – die beleefd alle cookies weigeren omdat ze zo min mogelijk gevolgd willen worden op het web (en ook om het web stuk te maken, ook dat). Ik accepteer alleen cookies als ik moet inloggen of als ik een webshopwinkelwagentje vul. Als je cookies nodig hebt, is het dus handig dat je eerst checkt of er überhaupt cookies geplaatst mogen worden.</p>
<ul>
<li>Hoe houd je een website begrijpelijk als je weet dat ‘ie gebruikt kan worden via een desktop, een screenreader, iemands commandline, een</li>
<li>ereader, een smartwatch? Hou je er rekening mee dat niet iedereen zo</li>
<li>goed kan lezen als jij? Ingewikkeld? Ingewikkelde dingen simpel maken is het mooiste in dit vak.</li>
</ul>
<h2>2: Liever één goed elftal dan elf goede ééntallen</h2>
<p><img src="https://www.fronteers.nl/_img/adventskalender/zoeaven.jpg" alt="Tuterdetuut: alle soldaten in het gelid. 12 Zoeaven (Franse militairen) met een geweer en een pofbroek." /></p>
<p>Tegeltjesgrootmeester Cruyff zei: “<a href="https://tegelizr.nl/tegeltje/wat-heb-je-nou-liever-n-goed-elftal-of-elf-goede-ntallen">Wat heb je nou liever: één goed elftal of elf goede ééntallen?</a>” Ik weet niks over voetbal. Maar ik weet wel dat diversiteit je team goed doet.</p>
<p>Het is makkelijker om je in te leven in je gebruikers als je meerdere perspectieven aan het werk hebt. Dat kan gaan om subtiele dingen als
woorden. Als je een webshop hebt voor de Nederlandse en Belgische markt, tutoyeer je dan wel of niet? Het kan ook iets minder subtiel, zoals een zeeppomp die <a href="https://www.youtube.com/watch?v=1lgDiAInFLY">donkere huid niet herkent</a>. Of die tijd dat Google een zoekopdracht als “She invented” corrigeerde naar “<a href="http://blogoscoped.com/archive/2007-05-24-n36.html">He invented</a>”.</p>
<p>Een diverser team voorkomt dat je verder kijkt dan een doelgroep van “latte drinkende, blanke, hoger opgeleide, brildragende, rechtshandige Randstedelingen met een licht bierbuikje”. Bekijk de <a href="https://vimeo.com/277243126">presentatie van Jenny Shen op CSS Day 2018</a> nog eens.</p>
<h2>3: Door kennis te delen, vermeerder je kennis</h2>
<p>Als je bang bent voor kritiek is het doodeng om je werk te laten zien aan je collega’s. Door dat niet te doen bespaar je jezelf weliswaar de kans op kritiek, maar je ontneemt je jezelf ook de kans om iets te leren. Je collega’s weten niet wat je kunt en hebben geen idee waar ze je bij zouden kunnen helpen. En ze leren niks van je. Door alles stilletjes voor jezelf te houden, ontloop je ook alle complimenten. Dat moeten we niet willen met z’n allen.</p>
<p>Schrijf stukjes, geef presentaties. Hou je portfolio manisch up-to-date. Wees trots op wat je maakte. En realiseer je dat als je volgend jaar kijkt naar wat je dit jaar maakte, je alweer een stuk meer weet en het misschien heel anders zou doen. Een dag niet geleerd is een dag niet geleerd tenslotte.</p>
<p>Het web is bedoeld om open te zijn. In 20 jaar tijd is een totaal nieuwe infrastructuur ontstaan voor het delen en vermeerderen van kennis. En als je wilt kun je daaraan bijdragen. Help bij grote of kleine open source projecten. Linux, WordPress (of Drupal, ja ja…), Wikipedia, allemaal voorbeelden van inmiddels essentiële open source projecten door duizenden vrijwilligers voor miljoenen dankbare gebruikers.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/be-the-pull-request.png" alt="Foto van Mahatma Ghandi met de tekst: &quot;Be the pull request you want to see in this world - het handige neefje van Mahatma Ghandi&quot;" /></p>
<h2>4: Ars longa, vita brevis (het leven is kort, de kunst is lang)</h2>
<p><img src="https://www.fronteers.nl/_img/adventskalender/piet-mondriaan-1921---composition-en-rouge-jaune-bleu-et-noir-768x766.jpg" alt="Schilderij van Piet Mondriaan met vlakken in diverse kleuren waaronder rood, blauw, geel, wit, zwart en grijs" /></p>
<p>Er zijn bibliotheken volgeschreven over kunststromingen en hoe die ons dagelijks leven hebben beïnvloed. We gebruiken het woord als pittoresk om een landschap te waarden; daarmee zeggen we eigenlijk dat het landschap net zo mooi is als een plaatje van een landschap.</p>
<p>Aangezien het web nog jong is zijn er nog niet veel kunsthistorische beschouwingen geschreven over webdesign. Maar we zijn als webbouwers schatplichtig aan vele kunstenaars en ambachtslui voor ons. Denk aan compositie en vlakverdeling. Denk aan typografie. Aan kleurgebruik. Ons werk is onmogelijk zonder de grote makers en doeners voor ons.</p>
<p>Dus daarom: dompel jezelf onder in design, kunst, boeken. Wat je daar leert komt op een onverwacht moment weer van pas.</p>
<p>Voorbeelden? Zie Jen Simmons lekker klooien met Mondriaan en CSS Grid: <a href="https://www.youtube.com/watch?v=qNtJ5p3h2A4">responsive Mondrian (YouTube)</a> / <a href="https://codepen.io/jensimmons/pen/mrNvPZ/">responsive Mondrian (codepen)</a>. En dit <a href="http://www.la-trahison-des-images.be/">is zeker geen responsive Magritte-pijp</a>.</p>
<h2>5: Fuck the system, be nice</h2>
<p><img src="https://www.fronteers.nl/_img/adventskalender/wim-heitinga-spreekt.png" alt="Screenshot van een kritisch linkedin-commentaar van een front-ender. Tekst: &quot;Echt serieus? Wat een slechte websites hebben overheidsinstanties. Waar gaat al dat geld naar toe? Gemeente Rotterdam, Gemeente Delft. Ik als webdeveloper kom er zelfs niet uit. Ik krijg programmeererrors te zien. WTF?!? Hebben jullie dan niet gehoort van gebruiksvriendelijkheid, UX? Ik wil best een presentatie komen geven, want het is duidelijk nog niet bekend bij jullie.. #shittysites #vanonzecenten I can’t believe it&quot;" /></p>
<p>Het screenshot hiernaast was de aanleiding voor dit artikeltje. Dit is niet de manier om je professioneel te presenteren. Dit is een onderdeel van een zeur- en afzeikcultuur waar we vanaf moeten. Wat weet je nou na het lezen van dit berichtje? We weten dat deze Wim een probleem had; ergens kwamen programmeerfouten aan het licht. Kun je daaruit afleiden dat overheidsinstanties een slechte site hebben? Van iemand die alleen klaagt en geen aanwijzing geeft over waar wat misgaat en ook geen oplossing aandraagt verwacht ik geen constructieve presentatie over UX of gebruiksvriendelijkheid. Met dit soort berichten diskwalificeer je jezelf.</p>
<p>Er zit ook een lichte vorm van zelfoverschatting in. Dat Wim het niet begrijpt, betekent niet dat anderen dom zijn. Ik had het net over de angst voor kritiek. Om die angst te verminderen moeten we milder zijn voor elkaar en over elkaars werk. Sowieso staat voorop: die collega is een mens, net als jij. Van louter hot-takes wordt de wereld niet beter. Wim had beter kunnen zeggen: “Ik zag op die-en-die plek deze programmeerfout. En dit is hoe je die oplost.”</p>
<p>Sociale media lijken een lavastroom van permanente woede. Wie de wereld door de bril van sociale media bekijkt, denkt al gauw dat de wereld alleen bestaat uit ellende en #ophef. Maar dit is voor een groot gedeelte het gevolg van hoe dat soort media werken. Kranten kunnen niet zonder dagelijkse boosmakertjes. De beste remedie tegen dat soort ophef is je te realiseren dat de veel berichten geplaatst worden als mensen op de plee zitten. Is wel zo.</p>
<blockquote>
<p>“Algorithms that maximize attention give an advantage to negative messages. People tend to react more to inputs that land low on the brainstem. Fear and anger produce a lot more engagement and sharing than joy. The result is that the algorithms favor sensational content over substance.”</p>
</blockquote>
<p>Daarom: doorbreek de sleur van het afzeiken en het zeuren. Wees specifiek en oplossingsgericht. Kraak niemand af.
En als je ideeën, systemen wilt afkraken: gebruik humor en argumenten.</p>
<p>Fuck the system, be nice.</p>
<h2>Over Paul van Buuren</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/paul.jpg" alt="Foto van Paul van Buuren" class="floating-portrait" />
Paul van Buuren maakt websites sinds 1998. Zijn vooropleiding heeft niks met webdesign te maken, want dat bestond domweg nog niet. Onder de noemer WBVB Rotterdam werkt hij als zelfstandige voor diverse opdrachtgevers. Z'n specialiteit is het maken van toegankelijke WordPress-sites. Hij praat opvallend vaak in algemeenheden en tegeltjeswijsheden.
Donatie:
Z'n donatie gaat naar KIKA, Stichting Kinderen Kankervrij. Ik weet hoe erg het is als kinderen ziek worden en ik wil zoveel mogelijk doen om ziekte te voorkomen of te genezen.
</content>
</entry>
<entry>
<title>Wat ik leerde van twaalf uur tekenen tijdens Fronteers</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/wat-ik-leerde-van-twaalf-uur-tekenen-tijdens-fronteers"/>
<updated>2018-12-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/wat-ik-leerde-van-twaalf-uur-tekenen-tijdens-fronteers</id>
<content xml:lang="nl" type="html"><p>Naast de vele technische blogposts in de adventskalender, gaat deze post over tekenen. Of eigenlijk ‘Sketchnotes’. Je ziet ze steeds meer op Twitter en andere sociale media, en het tekenen van die oh zo mooie notities wordt vaak gezien als het grootste goed in de Instagram- en YouTube-wereld. En jazeker, het helpt je vast ook nog om beter te concentreren, de stof te snappen en wellicht ook nog meteen de wereldvrede te starten! Superfijn natuurlijk, maar daar ga ik het niet over hebben. Alhoewel, een beetje wereldvrede is al een mooi streven.</p>
<h2>Tekenen? Analoog bedoel je?</h2>
<p>Even een paar stappen terug. Ik ben webdesigner en front-ender, maar heb de kunstacademie (grafisch ontwerpen) gedaan. Een potlood is voor mij dus geen eng ding en ik teken al mijn hele leven. Als kind tekende ik bij de boodschappenlijstjes van mijn ouders en tijdens besprekingen teken ik vaak snelle schetsen om voor mezelf dingen duidelijk te maken. Dit was de disclaimer.</p>
<p>Na Fronteers 2017 heb ik een aantal snelle schetsen gemaakt over een paar talks. Dat beviel me en het leek me een goede uitdaging (ik maak het mezelf nooit makkelijk) om in 2018 <em>alle</em> talks te tekenen. Dat bleek afgelopen oktober neer te komen op een stoomcursus sketchnotes. Twee keer acht talks zijn namelijk best veel tekeningen.</p>
<h2>Wat ik leerde van het tekenen van 16 talks op Fronteers 2018:</h2>
<h2>Sketchnotes verduidelijken een verhaal, maar een goed verhaal helpt ook bij goede sketchnotes</h2>
<p>Als het verhaal een duidelijke lijn heeft, kan je je notes goed ordenen en tekent het heel makkelijk. Er zit immers al een structuur in. Bam! Lekker makkelijk. Dat is meteen een goede test van de kwaliteit van het praatje. Dwarrelige praatjes tekenen gewoon veel moeilijker, net als dat het moeilijker is daar gewone geschreven notities van te maken.</p>
<p>Daarnaast: Het zijn jouw notes. Als jij dit de hoofdpunten vond en de dingen die je het meest aanspraken, dan zijn die ook goed.</p>
<h2>Kies het medium waarin je het snelste werkt.</h2>
<p>Snel, sneller, snelst. Iedereen die wel eens een <a href="https://vimeo.com/110569646">talk van Sara Soueidan</a> gezien heeft, weet wat ik bedoel. Dus werk met de tools die voor jou het snelste werken. Voor mij is dat pen en papier, voor anderen wellicht iPad en Pencil. Het nadeel van analoog is dat je niet weet hoe je je ruimte op je papier verdeelt (Hoe lang is de talk? Wat voor hoofdpunten?), maar hey, zoals ik al zei, ik hou er niet van om het mezelf makkelijk te maken.</p>
<h2>Neem een voorsprong als dat kan</h2>
<p>Ik ken een livetekenaar die van te voren de talks opvraagt om te weten wat de hoofdpunten zijn en zodat hij alvast kan oefenen op bijvoorbeeld het portret van de spreker. Dat is natuurlijk slim! Betere ordening en geen verrassingen.</p>
<h2>Omgaan met je ruimte</h2>
<p>Je weet vaak juist niet hoe lang de talk duurt, je kent de inhoud niet en je kan dus van tevoren niet werken aan zoiets als een opmaak. Problemen met de verdeling van je ruimte op papier? Dat gebeurt altijd. Pijlen en stippels kunnen dan heel goed een leesvolgorde aangeven. Snel en makkelijk, want snelheid is key.</p>
<h2>Gelijke dingen? Gelijke vormen!</h2>
<p>Blijken er ineens hoofdpunten in te zitten? Wordt de lijn na de halve talk pas duidelijk? Zet er een lijntje omheen, maak het <em>bold</em> of onderstreep het. Met andere woorden: zet de termen die bij elkaar horen visueel bij elkaar. Dan kan het vervolgens overal op je vel papier staan, je oog plakt het wel aan elkaar.</p>
<h2>Verdeel en heers</h2>
<p>Af en toe is het verhaal gewoon niet duidelijk. Onlogische stukjes talk, je raakt de draad een beetje kwijt… Soms zet je dat deel er gewoon niet in en dan blijkt dat je notes veel duidelijker zijn zonder die stukjes. Bedenk dat het <em>jouw</em> notities zijn, die niet de letterlijke weergave van de spreker hoeven te zijn.</p>
<h2>Recycle wat de spreker al voor je heeft gedaan</h2>
<p>Komt de spreker met een opsomming? Een duidelijk diagram? WIN! Dat is makkelijk en overzichtelijk! Maak er een duidelijke weergave van in je tekening. Je hebt de tijd toch niet om er zelf wat voor te verzinnen.</p>
<h2>Helder moment? Voeg toe!</h2>
<p>Voeg vooral eigen conclusies toe als je die trekt. Ik herhaal het nogmaals; het zijn <em>jouw</em> notities, dus het kan vaak de boel nog meer verduidelijken om die conclusie gewoon toe te voegen.</p>
<h2>Sketchnotes als feedback</h2>
<p>Ik kreeg een onverwachte opmerking van animator Chris Gannon, één van de sprekers van dit jaar: hij was ontzettend blij met de sketchnotes, want dan kon hij zien of zijn verhaal overkwam en of ik dezelfde hoofdpunten eruit gehaald had. Vervolgens heeft hij ze aan vrouw en kinderen gestuurd, die het ontzettend leuk en onmiskenbaar een talk van hem vonden. Dat was echt een geweldig compliment!</p>
<h2>Maar hoe dan?</h2>
<p>Je stijl van tekenen? Snel en schetsmatig, geen detail. Kan je niet goed tekenen? Een schets van een smiley of een stick figure is <em>ook</em> een mensje, die herkent iedereen. En geloof me, tijd voor details heb je <em>echt</em> niet. Nope. Het zijn tenslotte ‘sketchnotes’, geen ‘Van Gogh notes’. Maar achteraf wat kleurtjes toevoegen kan altijd.</p>
<h2>Betere concentratie en wereldvrede</h2>
<p>Last but not least: het viel me op dat ik door de concentratie die ik nodig heb tijdens de talks (afdwalen kan niet) heel helder bleef. Iets dat nog wel eens een uitdaging kan zijn met twee dagen conferencen. Daarnaast snap je inderdaad de talks beter omdat je zelf de conclusies trekt en de lijnen legt. Relaxed luisteren is het niet, maar goed, dat kan altijd nog op de volgende keer Fronteers.</p>
<p>De sketchnotes van Fronteers 2018 kan je <a href="https://twitter.com/i/moments/1049300181647282178">hier</a> terugkijken</p>
<p>Meta alert: Natuurlijk heb ik deze blogpost ook uitgetekend, hieronder de sketchnotes van de sketchnotes!</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/blogpost-sketchnotes-anke-small.jpeg" alt="De sketchnote van de sketchnotes" /></p>
<h2>Over Anke Willems</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/anke.jpeg" alt="Foto van anke" class="floating-portrait" />
Anke is webdesigner en frontend developer bij Two Kings in Den Haag. Ze houdt zich bezig met alles vanaf het eerste gesprek met de klant, via het inventariseren van alle wensen en daarvoor de UX uitwerken tot het bouwen van de templates. In een eerder leven was ze grafisch ontwerper (met drukwerk en papier en zo), maar digitaal vind ze toch echt leuker. Heeft een grote liefde voor het maken van kleine gebruiksaanwijzingen die op een post-it moeten passen. Motorrijder, breimuts en poezenvrouwtje.
Donatie
Het Haags Dierencentrum is het dierenasiel in Den Haag. Ze zijn voor de meest basic dingen, zoals een nieuwe operatietafel of een nieuw dak op de kattenverblijven afhankelijk van donaties. Omdat ik vind dat ze ontzettend goed werk verrichten sponsor ik ze graag.
</content>
</entry>
<entry>
<title>CSS en JavaScripters</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/css-en-javascripters"/>
<updated>2018-12-21T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/css-en-javascripters</id>
<content xml:lang="nl" type="html"><p>Een probleem dat ik de laatste twee of drie jaar steeds vaker zie opduiken, is dat het lijkt alsof een boel JavaScripters, vooral diegenen die in grote toolchains hebben geïnvesteerd, niet meer zo goed weten hoe CSS werkt.</p>
<p>Om daar wat aan te doen heb ik het plan opgevat hier een boek aan te wijden. Dit artikel is een soort voorschot daarop. Bovendien is het leuke van de Fronteers-crew dat de meeste mensen vloeiend zijn in zowel CSS als JavaScript en dat ik hier dus wellicht wat nuttige feedback kan krijgen.</p>
<p>Het boek gaat niet noodzakelijkerwijs door CSS heen om aan JavaScripters duidelijk te maken wat de cascade is, waar display voor dient, en hoe backgrounds werken. In plaats daarvan wil ik een aantal basisconcepten en -problemen bespreken en hoop ik op wat feedback - vooral van JavaScripters die wat slechter in CSS zijn.</p>
<p>Dit artikel beschrijft twee van die basisconcepten, is geschreven als vingeroefening, en in de hoop wat goede argumenten en suggesties los te maken.</p>
<h2>CSS als JSON</h2>
<p>Eén idee dat ik had, is om CSS uit te leggen als een soort JSON-bestand. Mijn analogie gaat op dit moment als volgt:</p>
<p>Stel dat je de opdracht krijgt om een JSON-bestand te herschrijven. Dit bestand wordt later in de toolchain ingevoerd in een module waar je geen toegang toe hebt maar wel incomplete documentatie van kunt inzien, en die module genereert uit de JSON-gegevens een webpagina. Aan jou de taak deze webpagina te herzien.</p>
<p>Een JSON-bestand is geen programma, in plaats daarvan geeft het instructies aan een programma. Deze instructies hoeven niet in een logische volgorde te staan: de properties in een JSON-bestand worden niet noodzakelijkerwijs in volgorde behandeld. In plaats daarvan zoekt de interpretatie-module op naam naar bepaalde properties, en dan naar andere, en maakt het niet uit waar in het JSON file ze staan.</p>
<p>Als je aan het werk gaat en proefversies van de JSON door de module heen haalt, merk je al snel dat sommige JSON-wijzigingen tot grote veranderingen in de webpagina leiden. Sommige van die veranderingen zijn beschreven in de documentatie, maar andere niet - of niet erg duidelijk. Naarmate je project vordert, leer je steeds meer over hoe de interpretatie-module eigenlijk werkt en hoe je de JSON moet herschrijven om de webpagina te verbeteren.</p>
<p>CSS is een soort van JSON. CSS is ook geen programma of programmeertaal. In plaats daarvan geeft het instructies aan een gespecialiseerde module, de CSS Engine. Deze module zorgt ervoor dat de CSS wordt geīnterpreteerd en er, idealiter, een webpagina op het scherm verschijnt die er uit ziet zoals jij bedoeld hebt.</p>
<p>Sommige CSS-declaraties veroorzaken een klein effect: het gebruiken van een bepaald lettertype, een bepaalde kleur, of tekst-decoraties. Andere zijn veel grootschaliger van opzet: ze bepalen de volledige layout van de pagina en in sommige gevallen treden er complexe wisselwerkingen op waardoor je pagina er niet meer uitziet zoals je zou willen. Terwijl je CSS schrijft en herschrijft, begin je steeds beter te begrijpen hoe de CSS engines werken.</p>
<p>Slaat deze vergelijking ergens op? Zou dit helpen om CSS-basisconcepten aan JavaScripters uit te leggen? Zijn er wijzigingen nodig? Ik hoor je commentaar graag.</p>
<h2>Global scope</h2>
<p>Het belangrijkste punt is echter de cascade. De cascade lijkt een van de grootste struikelblokken voor JavaScripters te zijn - niet omdat ze hem niet zouden begrijpen, maar omdat ze hem liever niet gebruiken.</p>
<p>Als je klassieke CSS schrijft, is namelijk elke declaratie global; dat wil zeggen dat het op elk element van toepassing is dat aan de selector voldoet. CSS'ers voelen nu een massieve &quot;duh!&quot; vanuit hun onderbuik opborrelen, maar het is belangrijk te beseffen dat dit voor JavaScripters een serieus probleem is. Gij zult uw variabelen niet global maken. En CSS declaraties zijn een soort variabelen, dus die zult gij evenmin global maken. Dus.</p>
<p>Ze hebben hier een punt, soort van. Je <code>div + p</code> selector kan fantastisch werken in de hoofdkolom van je site, maar irritante bij-effecten geven als je eenmaal aan de zijbalk werkt - of erger nog, als je een HTML-snippet van een externe bron aan de pagina toevoegt. We willen graag onze selector beperken tot de hoofdkolom waarvoor hij bedoeld is. In JavaScript-termen: we willen de scope van onze selector bepalen.</p>
<p>Voor dit probleem zijn twee oplossingen. De eerste is class names voor alles gebruiken; en dit is het kernconcept van populaire CSS-methodologieën zoals met name BEM. In ons voorbeeld wordt het dus iets als <code>section.hoofdkolom div + p</code>, en de stijlen werken niet meer door op andere pagina-elementen.</p>
<h2>CSS-in-JS</h2>
<p>JavaScripters gebruiken echter geen BEM, want echte JavaScripters gebruiken geen CSS-methodologieën. In plaats daarvan wordt het gebruik van CSS-in-JS steeds populairder. Het is belangrijk te beseffen dat CSS-in-JS een afgeleide is van de class name-strategie.</p>
<p>Zie bijvoorbeeld <a href="https://css-tricks.com/css-modules-part-1-need/">deze introductie tot CSS Modules</a> of <a href="https://hackernoon.com/all-you-need-to-know-about-css-in-js-984a72d48ebc">dit artikel over CSS-in-JS</a>. In beide gevallen zorgt een script er voor dat de CSS die je in je module definieert, met een class name wordt versterkt en aan de HTML-pagina wordt toegevoegd. Het script genereert dus op de achtergrond de class names die de gegenereerde CSS nodig heeft.</p>
<p>Persoonlijk ben ik geen groot voorstander van CSS-in-JS, maar ik geef grif toe dat dat gedeeltelijk komt doordat ik de jaren 2001-05 heb besteed aan front-enders te leren hun CSS en JavaScript juist te scheiden. Het is niet makkelijk om weer afscheid te nemen van deze manier van denken, vooral niet als CSS-in-JS gedeeltelijk staat voor &quot;zo, nu hoef ik geen CSS meer te leren.&quot;</p>
<p>Niettemin zal ik CSS-in-JS serieus moeten bestuderen en de mogelijkheid moeten overwegen dat het de juiste oplossing voor het probleem is. Op dit moment weet ik dat nog niet - argumenten en suggesties zijn welkom.</p>
<p>Bovendien: zelfs als CSS-in-JS de juiste oplossing is, is de global scope van CSS wel een probleem? Of lijkt het alleen maar een probleem als je teveel JavaScript hebt geschreven en nooit geleerd hebt op een CSS-manier te denken? (Vooropgesteld dat er een CSS-manier van denken bestaat.) Ook hier zijn argumenten en suggesties welkom.</p>
<h2>Web Components</h2>
<p>Er is maar één oplossing voor het probleem van de global scope die echt anders is dan class names en dat is Web Components, uitgevonden en uitgedragen door Google. (Ligt het aan mij, of lukt het nou echt niet om Web Components serieus van de grond te krijgen in front-end development?)</p>
<p>Bij Web Components gebruik je de <a href="https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM">Shadow DOM</a> om een deel van je HTML te isoleren van de rest van de pagina, en als je in dat deel CSS definieert, geldt die CSS alleen voor het geīsoleerde gedeelte. In zekere zin is dit een betere oplossing dan BEM/CSS-in-JS, aangezien de HTML en CSS nu <em>echt</em> een aparte module vormen in plaats van class names te gebruiken om dit te emuleren.</p>
<p>Zijn Web Components beter dan CSS-in-JS? Slechter? Of zijn ze bedoeld voor anderssoortige situaties? Ook hier zijn argumenten en suggesties welkom.</p>
<h2>Conclusie</h2>
<p>Om CSS aan JavaScripters te leren, is het noodzakelijk te denken zoals JavaScripters denken. Ik heb geen idee of dat in het bovenstaande gelukt is, maar dat is een van de redenen dat ik dit publiceer. Laat maar weten wat je vindt - vooral als je kracht eerder in JavaScript dan in CSS ligt.</p>
<p>En als alles perfect loopt, ligt het boek rond maart 2020 in de winkel.</p>
<p>Over Peter-Paul Koch
<img src="https://www.fronteers.nl/_img/adventskalender/ppk.jpg" alt="Foto van ppk" class="floating-portrait" />
Peter-Paul Koch is front-end consultant en congresorganisator te Amsterdam. Hij bestudeerde browsers op https://quirksmode.org, praat wat, schrijft wat, runt samen met Krijn Hoetmer <a href="https://cssday.nl/">CSS Day</a> en <a href="https://perfnow.nl/">performance.now()</a>, richtte ooit tussen de bedrijven door Fronteers en het Fronteers-congres op, en zoekt nu naar nieuwe manieren om moderne front-enders te behoeden voor dezelfde fouten die tien of twintig jaar geleden zijn gemaakt.</p>
<p>Donatie: Bits of Freedom</p>
</content>
</entry>
<entry>
<title>Min of meer toegankelijk</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/min-of-meer-toegankelijk"/>
<updated>2018-12-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/min-of-meer-toegankelijk</id>
<content xml:lang="nl" type="html"><p>Ik werk al jaren aan een toegankelijk web. Toegankelijk voor iedereen. Rekening houdend met verschillende manieren van waarnemen, bedienen en begrijpen van content. En het web moet beschikbaar zijn op elk platform waar je een website mee kan bezoeken. Zo heeft Sir Tim Berners-Lee het world wide web ooit neergezet.</p>
<p>Niet eerder is er zo hard gewerkt aan toegankelijkheid als het afgelopen jaar. Jarenlang is de Nederlandse overheid hierin koploper. Maar andere branches zoals onderwijs, banken en zorg zijn met een inhaalslag bezig. Sommige gedreven door wetgeving en dreiging van rechtszaken, zoals je in Amerika veel ziet. Meer nog omdat er binnen organisaties mensen rondlopen die de noodzaak en de winst zien van een toegankelijke dienstverlening.</p>
<p>Hoe ontoegankelijk het web is blijkt soms als je een actie niet kunt afronden omdat JavaScript fouten bevat. Onlangs kon ik mijn reis niet bekijken via een van de reisplanners omdat er een knop niet werkte. Veelal worden websites en webapplicaties op grote schermen op een snel en stabiel netwerk ontwikkeld. Onderweg heb je doorgaans in auto, bus of trein niet de mogelijkheid om achter zo'n scherm te zitten (met uitzondering van de Tesla dan).</p>
<p>Het web is heel toegankelijk begonnen met alleen tekst. De eerste website van Berners-Lee is zo'n website die het nu nog steeds doet. Zie <a href="http://info.cern.ch/hypertext/WWW/TheProject.html">World Wide Web</a></p>
<h2>Afbeeldingen</h2>
<p>Daar begon het gedonder. We konden afbeeldingen publiceren. Mensen die niet in staat zijn om een afbeelding te bekijken missen ineens de informatie die op de afbeelding staat. Dan hadden we ook ineens downloadtijden... het begin van toegankelijkheidsproblemen.</p>
<h2>Tables voor design</h2>
<p>Eind jaren '90 gingen we helemaal los. We wilden mooi design en animated gifs; liefst in de beste browser van die tijd. Om dat voor elkaar te krijgen gebruikten we de tabel, de pixel.gif en menuitem1.gif om het ontwerp pixelprecies te krijgen. En we gebruikten tools die automatisch HTML voor je maakte, dat ook niet altijd voldeed aan de standaarden. Semantiek en toegankelijkheid waren niet de grootste aandachtspunten. Werkend krijgen in alle browsers wel.</p>
<h2>Flash (niet het Queen-nummer uit 1980)</h2>
<p>Begin deze eeuw werd Flash populair. Zo slecht was Flash niet; je kon er toegankelijk mee bouwen. Het vergde kennis van de scripttaal om dat voor elkaar te krijgen. Maar in de praktijk waren er vrijwel geen toegankelijke websites met Flash te vinden. Hoe robuust Flash is kan je terugzien op archive.org. Veel Flash-sites tonen daar een lege ruimte.</p>
<h2>Mobiel/tablet</h2>
<p>De komst van kleinere schermen zorgde voor nieuwe uitdagingen. Pixelprecies hoefde niet meer. We gaan responsive. Alle functies en content op het grote scherm moeten ook beschikbaar zijn op het kleine scherm. De uitdaging is dat teksten niet in een verkeerde achtergrondkleur belanden of buiten het scherm terechtkomen. Ook sticky menu's, cookiemeldingen en reageerknoppen vormen vaak een belemmering om eenvoudig de content waar te nemen.</p>
<h2>Flat design</h2>
<p>Knoppen worden vlakken, invoervelden worden vlakken, het hele design bestaat uit vlakken. Interactieve elementen zijn vaak nauwelijks herkenbaar. Alles krijgt steeds lichtere kleuren. De kunst van het weglaten wordt op belangrijke elementen toegepast. Je weet soms niet waar je moet klikken, wat je moet klikken en waarop je geklikt hebt. Nieuwe toegankelijkheidsproblemen duiken op zoals labels die ontbreken en contrast dat te laag is.</p>
<h2>JavaScript frameworks</h2>
<p>Het nieuwe Flash. Zonder front-endkennis ben je in staat om supersnel een website of webapplicatie neer te zetten, die helaas te vaak ontoegankelijk is. Dit kan aan de tool liggen. Toegankelijkheid (en semantiek) zit er dan in de basis niet in. En als het er wel in zit, dan is niet duidelijk vastgelegd hoe je met de code om moet gaan om de toegankelijkheid niet stuk te maken. Of zou het ook aan de developer liggen?</p>
<h2>Advies</h2>
<p>Zorg dat je voldoende kennis hebt van HTML, CSS en WAI-ARIA als je een website of webapplicatie moet bouwen. Tools zijn mooie dingen mits je ze goed gebruikt. Zorg dat je kennis hebt van de standaarden. Iedereen kan een muurtje metselen. Alleen als een metselaar dit doet heb je meer zekerheid dat het muurtje recht is en blijft staan.</p>
<h2>Quick wins</h2>
<ul>
<li>Gebruik Google: zoek naar &quot;accessibility&quot; of &quot;wcag&quot; in combinatie met de tool waarmee je wilt werken. De zoekresultaten kunnen een indicatie zijn of er aan toegankelijkheid is gedacht.</li>
<li>Vraag experts of ze goede bronnen kennen van een specifieke tool.</li>
<li>Vraag bij leveranciers door tot ze kunnen aantonen dat ze een tool hebben waarmee je een toegankelijke website mee kan bouwen.</li>
<li>Volg een training. Er zijn meerdere goede trainers in binnen- en buitenland.</li>
<li>Heb je zelf net niet de expertise huur dan iemand parttime in in je project. Met weinig, maar wel de juiste middelen kan je een boel bereiken.</li>
</ul>
<h2>Over Jules Ernst</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/jules.jpg" alt="Foto van Jules Ernst" class="floating-portrait" />
[Jules Ernst](https://www.200ok.nl/) weet heel veel van digitale toegankelijkheid. Hij helpt organisaties om digitale toegankelijkheid te realiseren en te borgen. Dit doet hij door mee te werken in projecten, trainingen en workshops te geven en websites en webapplicaties te onderzoeken op toegankelijkheid.
<p>Donatie: <a href="https://www.niketan.nl/">Niketan</a>
Kinderen met een beperking een kans geven. Ze de mogelijkheid geven dat ze later zelf keuzes kunnen maken. Niketan is een bijzondere stichting die zich daarmee bezig houdt en waarvan je zeker weet dat je geld goed besteed wordt.</p>
</content>
</entry>
<entry>
<title>Webdeveloper worden zonder (dure) opleiding</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/webdeveloper-worden-zonder-dure-opleiding"/>
<updated>2018-12-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/webdeveloper-worden-zonder-dure-opleiding</id>
<content xml:lang="nl" type="html"><p>Na lang wikken en wegen ben je eruit, je wilt (front-end) webdeveloper worden. Maar waar begin je? Ga je een (HBO)-opleiding doen of meld je je aan voor een coding bootcamp? Er zijn verschillende routes die je kunt nemen:</p>
<ul>
<li>Zit je momenteel nog op de middelbare school? Volg dan een opleiding als Communication &amp; Media Design aan een hogere school. Hier leer je namelijk veel meer vaardigheden, die niet direct iets met het vak te maken hebben, maar waar je wel ontzettend veel aan hebt in je latere carrière. Daarnaast is de tijd als student ook ontzettend nuttig omdat je hier - onbewust - erg veel leert over het volwassen leven, vooral als je op kamers gaat.</li>
<li>Ben je al werkende en overweeg je een carrièreswitch naar webdeveloper? Er zijn genoeg (gratis) manieren om je om te scholen naar webdeveloper. Het volgen van een dure (hbo) opleiding of bootcamp is helemaal niet nodig.</li>
</ul>
<p>In deze blogpost laat ik zien dat het helemaal niet veel geld hoeft te kosten om je om te scholen naar webdeveloper. Er zijn ontzettend veel gratis resources te vinden op het internet. Ook als je al werkzaam bent als webdeveloper, maar je wilt graag meer leren, heb je waarschijnlijk ook wat aan deze blogpost. Of je nou beginner bent of gevorderde, veel van deze resources zijn nuttig voor iedereen. Volg je nu een hbo-opleiding, dan raad ik ook zeker aan om af en toe een cursus of naslagwerk erbij te pakken. Voor het gemak gaan we er even vanuit dat je een absolute beginner bent.</p>
<p><a href="https://www.codecademy.com/">Codecademy</a></p>
<p>Codecademy maakt je op een simpele en leuke manier wegwijs in de wereld van het programmeren. Allereerst kies je een programmeertaal of framework die je wilt leren, bijv. HTML, CSS, JavaScript, jQuery of Python. Vervolgens krijg je kleine opdrachtjes die je direct in het venster kan uitvoeren. Je krijgt ook direct feedback op je werk en het nodigt je uit om steeds door te gaan, waardoor je voor je het weet de basis onder de knie hebt. De meeste cursussen zijn gratis, al bieden ze ook een Pro-abonnement (ongeveer 20 dollar per maand) en Pro Intensive programma’s aan. Dit laatste is een online bootcamp waarbij je bijvoorbeeld leert een front-end applicatie of web API van de grond af op te bouwen, en hier krijg je een certificaat voor. Deze bootcamps kosten ongeveer 200 dollar en duren 8 weken.</p>
<p><em>Prijs:</em> Gratis / 20 dollar per maand / 200 dollar per bootcamp</p>
<p><a href="https://www.freecodecamp.org/">FreeCodeCamp</a></p>
<p>FreeCodeCamp is een community die honderden video’s en tutorials aanbiedt voor het leren van web development. Hier heb je in totaal 6 paden die ieder 300 uur aan content bevatten. Dit is in totaal dus 1800 uur, wat neer komt op een jaar fulltime leren (met 7 weken vakantie). Ik begrijp dat dit erg overweldigend kan zijn, maar je bent natuurlijk niet verplicht al deze uren hieraan te besteden. Het zogenaamde curriculum is op elk moment vrij in te zien en je kunt dus zelf bepalen welke onderwerpen je graag wilt leren. En het grootste voordeel? Het is helemaal 100% gratis!</p>
<p><em>Prijs:</em> Gratis</p>
<h2>De basis onder de knie</h2>
<p>Nu je de basis onder de knie hebt, begint pas de echte uitdaging. Want vanuit hier zijn er verschillende paden die je kunt bewandelen. Dit ligt helemaal aan jouw wensen en niveau. Wel raad ik je aan om eerst de fijne kneepjes van het vak te leren alvorens je meteen in complexe onderwerpen duikt. Wil je bijvoorbeeld graag React leren, maar heb je nog niet veel ervaring met JavaScript? Duik dan eerst nog eens wat dieper in de materie van JavaScript.</p>
<p>Er zijn online verschillende (uitgebreide) handleidingen/boeken die helemaal niets kosten, maar waar je ontzettend veel van kan leren op het gebied van JavaScript, een taal die ontzettend krachtig is, maar ook wat eigenaardigheden kent.</p>
<ul>
<li><em>You Don’t Know JavaScript</em> van <em>Kyle Simpson</em></li>
</ul>
<p><a href="https://github.com/getify/You-Dont-Know-JS">You Don’t Know JavaScript</a> (vaak afgekort tot YDKJS) is een serie boeken die open-source op GitHub in te zien zijn. Voor een kleine meerprijs zijn ze te downloaden als e-book en voor een iets hogere meerprijs zijn ze ook te koop als fysiek boek. In deze serie komen bijna alle kenmerken van de taal aan bod, een must-read voor iedereen die JavaScript wil leren.</p>
<p><em>Prijs:</em> Gratis</p>
<ul>
<li><em>The Complete JavaScript Handbook</em> van <em>Flavio Copes</em></li>
</ul>
<p>In wezen een erg lang <a href="https://medium.freecodecamp.org/the-complete-javascript-handbook-f26b2c71719c">Medium-artikel</a>, maar dit artikel bevat wel alles wat je moet weten over JavaScript. Een stuk korter en dus ook minder gedetailleerd dan de YDKJS-boeken omdat Flavio hier de 80/20 regel toepast: Leer 80% van JavaScript in 20% van de tijd.</p>
<p><em>Prijs</em>: Gratis</p>
<h2>Interactieve cursussen</h2>
<p>Heb je net als ik het concentratievermogen van een pot pindakaas, en leer je liever op een interactieve manier, zoals bij het eerder genoemde Codecademy het geval is? Er zijn tal van videocursussen beschikbaar die je kunt volgen.</p>
<ul>
<li><a href="http://www.wesbos.com/">Wes Bos</a></li>
</ul>
<p>Wes Bos is een Canadese webdeveloper die zich tegenwoordig vooral bezig houdt met de ontwikkeling van videocursussen. Deze zijn gruwelijk populair onder front-end webdevelopers en dat is zeer terecht. De cursussen zijn veelal erg diepgaand en relatief goedkoop. Voor 140 euro krijg je bijv. toegang tot de ES6 voor Everyone cursus, die bestaat uit 7 uur aan videomateriaal waar je alles leer wat ook in The Complete JavaScript Handbook beschreven wordt. Daarnaast heeft hij ook een podcast, <a href="http://www.syntax.fm/">Syntax.fm</a>) waar hij samen met Scott Tolinski vrijwel wekelijkse interessante onderwerpen betreffende front-end web development bespreekt.</p>
<p><em>Prijs:</em> $70 - $140 per cursus</p>
<ul>
<li><a href="https://www.pluralsight.com/">Pluralsight</a></li>
</ul>
<p>Pluralsight biedt veel verschillende cursussen aan die gericht zijn op vrijwel alle development functies. Niet enkel front-end, maar ook backend, devops, sysops en security onderwerpen worden hier behandeld. Wat ik persoonlijk een hele fijne feature vindt van Pluralsight, is dat je per onderwerp een soort IQ test kan doen van grofweg 20 vragen, waarop je ‘skill level’ berekend wordt. Op basis van dit skill level worden je videocursussen per onderwerp aangeraden. Dit is vooral fijn voor mensen die al wat ervaring hebben en niet uren aan materiaal door willen werken dat ze al kennen. De meeste videocursussen zijn kort, tussen de 2 en 10 uur. Aan dit alles hangt echter wel een relatief hoog prijskaartje. Hier betaal je namelijk per maand of per jaar voor onbeperkt toegang tot alle beschikbare cursussen.</p>
<p><em>Prijs:</em> $29 per maand / 299 per jaar</p>
<ul>
<li><a href="https://www.udemy.com/">Udemy</a></li>
</ul>
<p>Udemy is een platform voor videocursussen die zich niet enkel richt op web development. Eigenlijk kun je hier voor elk onderwerp wel een cursus volgen. Hier staan echter wel veel goede front-end web development cursussen op, dus deze mag niet in dit lijstje ontbreken. De meeste cursussen kosten oorspronkelijk tussen de 150 en 300 euro, maar er is eigenlijk altijd wel een actie waardoor je maar 10 tot 15 euro voor een cursus bestaat.</p>
<p>Hier enkele voorbeelden van cursussen waar ik erg veel aan heb gehad:</p>
<ul>
<li><a href="https://www.udemy.com/the-complete-web-developer-zero-to-mastery/">The Complete Web Developer: Zero To Mastery - Andrei Nagoie</a></li>
<li><a href="https://www.udemy.com/the-complete-junior-to-senior-web-developer-roadmap/">The Complete Junior To Senior Web Developer Roadmap - Andrei Nagoie</a></li>
<li><a href="https://www.udemy.com/understand-javascript/">JavaScript: Understanding the Weird Parts - Anthony Alicea</a></li>
</ul>
<p>Als je je wil verdiepen in React, Angular of Vue (of vele andere onderwerpen) kan ik de cursussen van <a href="https://www.udemy.com/user/maximilian-schwarzmuller/">Maximilian Schwarzmüller</a> aanraden.</p>
<p><em>Prijs:</em> $150 - $300 per cursus (maar in de (vrijwel permanente) sale $10 - $15 per cursus)</p>
<h2>Conclusie</h2>
<p>Met dit overzicht heb ik er de volste vertrouwen in dat je zonder al te veel geld uit kan geven erg veel kan leren op het gebied van front-end web development. En onthoud dat je in dit vak nooit uitgeleerd bent, en er dus constant nieuwe dingen zijn te leren, ook al heb je al decennia lang ervaring. Als laatste wil ik meegeven dat het vooral belangrijk is dat je aan de slag gaat. De theorie is belangrijk, maar het in de praktijk brengen is het allerbelangrijkste. Heb je momenteel nog geen baan als front-end webdeveloper? Ga zelf aan de slag met een tof project, knutsel wat in elkaar en gooi het op Github. Dan heb je meteen wat om te laten zien tijdens een sollicitatiegesprek. Het hoeft niet perfect te zijn, want je zult er hoe dan ook van leren. Weet je niet wat je dan moet maken? Begin met iets (relatiefs) simpels als een simpele website over je cavia. Deze maak je daarna responsive zodat deze er ook mooi uitziet op je telefoon. Daarna bouw je een rekenmachine, of een Boter, Kaas en Eieren spel. Zolang je plezier hebt in wat je doet, komt de rest vanzelf wel goed.</p>
<p>Het lijstje hierboven is zeker niet volledig, en er zijn er nog veel meer te noemen, maar dan werd het wel een erg lange blogpost. Desalniettemin, hier nog wat honorable mentions:</p>
<h2>Artikelen</h2>
<p><a href="https://medium.com/zerotomastery/learn-to-code-in-2018-get-hired-and-have-fun-along-the-way-b338247eed6a">Learn to code in 2018, get hired and have fun along the way - Andrei Neagoie</a></p>
<p><a href="https://medium.com/zerotomastery/dont-be-a-junior-developer-the-roadmap-9fde5cf384bb">Don’t be a junior developer - Andrei Neagoie</a></p>
<h2>Overige</h2>
<p><a href="https://github.com/kamranahmedse/developer-roadmap">The Webdeveloper Roadmap 2018 - Kamran Ahmed</a></p>
<h2>Code challenges</h2>
<p><a href="http://www.codewars.com/">Codewars</a></p>
<p><a href="http://www.hackerrank.com/">Hackerrank</a></p>
<h2>Videocursussen</h2>
<p><a href="https://tylermcginnis.com/courses/">Tyler McGinnis</a></p>
<p><a href="https://www.leveluptutorials.com/">Level Up Tutorials - Scott Tolinski</a></p>
<p><a href="https://learnjavascript.today/">Learn JavaScript Today - Zell Liew</a></p>
<h2>Over Tim Oerlemans</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/tim-oerlemans.png" alt="Foto van Tim" class="floating-portrait" />
28 jaar, 3 jaar ervaring en momenteel werkzaam als front-end webdeveloper bij TrueLime in Breda. Leergierig en wil constant nieuwe dingen leren.
<p>Donatie: NSGK</p>
</content>
</entry>
<entry>
<title>Lettertypes op het web, wat kan ik ermee?</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/lettertypes-op-het-web-wat-kan-ik-ermee"/>
<updated>2018-12-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/lettertypes-op-het-web-wat-kan-ik-ermee</id>
<content xml:lang="nl" type="html"><p>In het begin van het web was dat niet zo veel: de browser deed alles voor je. Het enige waar je controle over had was je HTML. Met semantische <a href="https://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html">HTML-tags</a> gaf je betekenis aan stukjes van je pagina, zoals <code>&lt;h1&gt;</code> tot <code>&lt;h6&gt;</code> voor kopjes. Je browser besloot dan hoe dat er uit zag. Zo werden kopjes in hoofdletters weergegeven op monochrome tekst-terminals, of groter en dikgedrukt in grafische browsers.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/lettertypes/blog-1.png" alt="Screenshot van Mosaic 1.0 met het Choose Font menu opengeklapt: Gebruikers konden voor elk soort tag instellen hoe het er uit zag." /></p>
<p>In de loop van de jaren werd gelukkig steeds meer mogelijk. Zo kregen we met <a href="https://www.w3.org/MarkUp/html-spec/html-spec_5.html">HTML 2.0</a> niet alleen meer semantische tags zoals <code>&lt;em&gt;</code> en <code>&lt;strong&gt;</code>, maar ook de typografische tags waarmee we tekst expliciet vet (<code>&lt;b&gt;</code>), cursief (<code>&lt;i&gt;</code>) of monospaced (<code>&lt;tt&gt;</code>) konden maken.</p>
<p>Met <a href="https://www.w3.org/TR/2018/SPSD-html32-20180315/#body">HTML 3.2</a> kregen we controle over de tekstkleur op een pagina, als mede meer tags zoals onderstrepen (<code>&lt;u&gt;</code>), super- en subscript tekst (<code>&lt;sup&gt;</code>, <code>&lt;sub&gt;</code>) en meer. Ook kregen we de inmiddels befaamde <code>&lt;font&gt;</code> en <code>&lt;basefont&gt;</code> tags. Officieel kon je hier tekstkleur en lettergrootte mee kiezen, maar als gevolgd van de <a href="https://thehistoryoftheweb.com/browser-wars-part-2/">browser oorlog</a> die op dat moment gestreden werd, werd ook het <code>face</code> attribuut al snel ondersteund. Hiermee konden we eindelijk bepalen welk lettertype onze site gebruikte.</p>
<p>Niet dat er veel keuze was, je was beperkt tot het gebruiken van een lettertype dat gebruikers op hun computer hadden staan. In praktijk betekende dit je te beperken tot één van de elf <a href="https://web.archive.org/web/19990117012320/http://www.microsoft.com:80/typography/faq/faq8.htm">TrueType core fonts for the Web</a> van Microsoft.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/lettertypes/blog-7.png" alt="Afbeelding van de elf core fonts for the web: Andale Mono, Arial, Arial Black, Comic Sans MS, Courier New, Georgia, Impact, Times New Roman, Trebuchet MS, Verdana en Webdings" /></p>
<h2>CSS</h2>
<p>De semantische visie kwam terug met HTML 4.0 tegen het einde van 1997. <code>&lt;font&gt;</code> was weer weg, samen met <code>&lt;fontbase&gt;</code>, <code>&lt;s&gt;</code>, <code>&lt;strike&gt;</code> en <code>&lt;u&gt;</code>, en CSS werd echt de manier om stijling te doen. Bijvoorbeeld:</p>
<pre><code>body {
font-family: Andale Mono, Courier New, Courier, monospace;
}
</code></pre>
<p>De pagina krijgt als standaard lettertype Andale Mono, als die niet beschikbaar is Courier New of anders Courier. Als geen van de gekozen lettertypes beschikbaar valt de browser terug op het ingebouwde <code>monospace</code>.</p>
<h2>Webfonts</h2>
<p>Naast ingebouwde lettertypes hebben we tegenwoordig de mogelijkheid om webfonts te gebruiken. Er zijn verschillende bestandsformaten voor (web)fonts, en het is makkelijk daar in verdwaald te raken. Afhankelijk van welke browsers je nog wil ondersteunen heb je genoeg aan WOFF2 (Web Open Font Format 2.0) of anders WOFF2 met een fallback naar WOFF. Lettertype in een ander formaat? Er zijn tegenwoordig genoeg tools online die een lettertype zo voor je kunnen converteren.</p>
<p>Een webfont maak je beschikbaar door een <code>@font-face</code> blok op te nemen in je CSS:</p>
<pre><code>@font-face {
font-family: 'mijn lettertype';
src: url('mijn.woff2') format('woff2'),
url('mijn.woff') format('woff');
}
</code></pre>
<p>Nu kan je ‘mijn lettertype’ gebruiken alsof het elk ander lettertype is.</p>
<p>Met webfonts gaat een hele wereld open qua mogelijkheden, maar hou er rekening mee dat er gebruikers zijn die je mooie font niet zullen zien: ze hebben misschien een trage internet verbinding of blokkeren webfonts wegens privacy redenen. Dus het blijft handig iets van een fallback te blijven gebruiken.</p>
<p>Als een pagina met webfonts laadt, gaat de tekst op de pagina door twee fases heen: eerst is tekst onzichtbaar (de blokkeerperiode) en als het te lang duurt voor een lettertype gedownload is wordt daarna een fallback gebruikt (de wisselperiode).</p>
<p>Door <code>font-display</code> toe te voegen aan je @font-face kan je browsers een hint geven over wat ze moeten doen als een lettertype nog aan het downloaden is:</p>
<ul>
<li><code>block</code> Een korte blokkeerperiode en een oneindige wisselperiode, voor als je koste wat kost je webfont wil gebruiken.</li>
<li><code>swap</code> Een extreem korte blokkeerperiode en een oneindige wisselperiode. Voor als het het belangrijkste is dat tekst snel leesbaar is, maar je eigenlijk niet zonder je webfont wil.</li>
<li><code>fallback</code> Een extreem korte blokkeerperiode en een korte wisselperiode. Voor als je graag je webfont wil gebruiken, maar als een bezoeker al tekst aan het lezen is, wil je hem niet afleiden door van lettertype te wisselen.</li>
<li><code>optional</code> Een extreem korte blokkeerperiode en geen wisselperiode. Voor als een webfont een leuk extraatje is.</li>
</ul>
<h2>Bold, bolder, boldst</h2>
<p>In tegenstelling tot wat je in bijv. Word ziet, is op het web dikgedrukte tekst geen kwestie van aan of uit, maar een schaal van 9 verschillende diktes, genaamd 100 tot 900. Op deze schaal is normale, niet vette tekst 400, en vette tekst 700. Je kan <code>normal</code> gebruiken ipv 400 en <code>bold</code> ipv 700.</p>
<pre><code>p.dik-gedrukt {
font-weight: 700;
}
</code></pre>
<p>Als je een webfont gebruikt, heb je voor elke <code>font-weight</code> een apart bestand nodig:</p>
<pre><code>@font-face {
font-family: 'mijn lettertype';
font-weight: 400; /* standaard waarde, mag je ook weglaten. */
src: url('mijn-normaal.woff2') format('woff2');
}
@font-face {
font-family: 'mijn lettertype';
font-weight: 700;
src: url('mijn-vet.woff2') format('woff2');
}
</code></pre>
<p><img src="https://www.fronteers.nl/_img/adventskalender/lettertypes/blog-6.png" alt="Afbeelding van de negen diktes van het lettertype Exo 2" /></p>
<h2>Stretch</h2>
<p>Lettertypes hebben soms meerdere breedtes, deze kan je kiezen met <code>font-stretch</code>. Er zijn 9 waardes: <code>ultra-condensed</code>, <code>extra-condensed</code>, <code>condensed</code>, <code>semi-condensed</code>, <code>normal</code>, <code>semi-expanded</code>, <code>expanded</code>, <code>extra-expanded</code> en <code>ultra-expanded</code>. Sinds kort mag je ook percentages gebruiken zodat je een oneindig aantal breedtes kan hebben, maar dat ondersteunen veel browsers nog niet. <code>normal</code> komt dan overeen met 100%, <code>ultra-condensed</code> met 25% en <code>ultra-expanded</code> met <code>200%</code>.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/lettertypes/blog-8.png" alt="Afbeelding van Encode Sans met 5 verschillende breedtes." /></p>
<h2>Cursief vs obliek</h2>
<p>Veel lettertypes hebben een cursieve (italic in het Engels) variant. Deze kan je gebruiken met <code>font-style: italic;</code>. Tekst simpelweg schuin zetten kan met <code>font-style: oblique;</code>, sommige variabele lettertypes hebben tegenwoordig ook ondersteuning voor tekst onder een specifieke hoek schuin te zetten: <code>font-style: oblique 14deg;</code>. Meer over variabele lettertypes later.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/lettertypes/blog-5.png" alt="Afbeelding van het lettertype Jost* in drie varianten: romein, obliek en cursief." /></p>
<p>Als het lettertype dat je gebruikt geen italic, bold of small-caps ondersteunt, kan een browser die voor je nadoen. Meestal niet zo mooi als een ‘echte’ bold, italic of small-caps, maar het kan goed genoeg zijn. Als je niet wil dat je browser die eigenschappen faket, kan je het uit zetten met <code>font-synthesis: none;</code>. Browser ondersteuning hiervoor is helaas <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis#Browser_Compatibility">belabberd</a>.</p>
<h2>Overhang</h2>
<p>Overhang (kerning in het Engels) tussen verschillende lettercombinaties kan bepaald worden door een lettertype. Dit zorgt voor fijner lezende tekst. Normaalgesproken staat dit aan, maar dit kan uit gezet worden met <code>font-kerning: none;</code>.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/lettertypes/blog-4.png" alt="Afbeelding van Abril Fatface met overhang aan en uit." /></p>
<h2>Ligaturen</h2>
<p>Met ligaturen worden een set aan gliefen die naast elkaar staan vervangen door een enkele. Een veel voorkomend voorbeeld is de lettercombinatie <code>f</code> <code>i</code>. Maar hou er rekening mee dat ligaturen taalafhankelijk kunnen zijn. Het turks bijvoorbeeld heeft zowel de letter <code>i</code> als <code>ı</code> (een i zonder punt). Met een normale fi ligatuur valt dat verschil weg, een goed lettertype houdt hier rekening mee, zorg dus altijd voor de juiste <code>lang</code> attributen in je pagina.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/lettertypes/blog-2.png" alt="Afbeelding van fi en fı zonder ligaturen, en met ligaturen in het Nederlands en Turks." /></p>
<p>Ligaturen worden in verschillende categorieën onderverdeeld die individueel aan en uitgezet kunnen worden. De fi ligatuur valt onder de alledaagse ligaturen (<code>common-ligatures</code>).</p>
<p>Verder zijn er de:</p>
<ul>
<li>Discrete ligaturen (<code>discretionary-ligatures</code>); deze zijn puur voor de mooi, leuk voor kopjes of logo’s maar vaak niet fijn in lopende tekst.</li>
<li>Historische ligaturen (<code>historical-ligatures</code>); ligaturen die vroeger gebruikt werden maar nu verwarrend zouden zijn.</li>
<li>Contextuele ligaturen (<code>contextual</code>); vooral gebruikt door handschriftlettertypes, om letters mooi aan elkaar te laten sluiten.</li>
</ul>
<p>Een lettertype bepaalt zelf welke standaard aan of uit staan en met <code>font-variant-ligatures</code> kan je dit aanpassen:</p>
<pre><code>h1 {
font-variant-ligatures: common-ligatures discretionary-ligatures;
}
</code></pre>
<h2>Cijfers</h2>
<p>Sommige lettertypes hebben meerdere sets getallen waar je uit kan kiezen:</p>
<p>Met <code>font-variant-numeric: lining-nums;</code> of <code>font-variant-numeric: oldstyle-nums;</code> kan je kiezen tussen moderne getallen die op de basislijn staan en oude getallen die er onder hangen.</p>
<p>Met <code>font-variant-numeric: proportional-nums;</code> of <code>font-variant-numeric: tabular-nums</code> kan je kiezen tussen cijfers met variabele of vaste breedte, wat soms handig kan zijn voor tabellen, rekening nummers etc.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/lettertypes/blog-3.png" alt="Afbeelding van proportional-nums en tabular-nums in Times New Roman, lining-nums en oldstyle-nums in Garamond" /></p>
<p>Andere opties zijn: <code>slashed-zero</code> voor een streep door (of stip in) het cijfer 0, om meer onderscheid te maken met de hoofdletter O. Met <code>diagonal-fractions</code> en <code>stacked-fractions</code> kunnen breuken netter weergegeven worden en met <code>ordinal</code> blijven cijfers normaal maar worden alle letters superscript, voor het gebruik als rangtelwoorden (1e).</p>
<h2>Stijlvariaties</h2>
<p>Lettertypes kunnen variaties van gliefen bevatten. Denk aan extra sierlijke varianten van hoofdletters of een ronde g inplaats van een bolletjes-g.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/lettertypes/blog-9.png" alt="Afbeelding van alternatieve gliefen in Plex, het nieuwe lettertype van IBM." /></p>
<p>Variaties vallen in de volgende categorieën:</p>
<ul>
<li>Historische gliefen (<code>hist</code>). Gliefen die nu niet meer gebruikt worden, denk aan de <a href="https://nl.wikipedia.org/wiki/Lange_s">lange S</a>.</li>
<li>Sets van alternatieve gliefen (<code>ss01</code> .. <code>ss20</code>). Denk aan de verschillende vormen van letters zoals de a en g.</li>
<li>Krullen en tierlantijntjes (<code>swsh</code>, <code>cswh</code>). Denk aan extra krullen aan hoofdletters.</li>
<li>Ornamenten (<code>ornm</code>). Denk aan bloempjes, <a href="https://en.wikipedia.org/wiki/Fleuron_(typography)">blaadjes</a> en andere losstaande symbolen.</li>
<li>Annotaties (<code>nalt</code>). Denk aan omcirkelde of negatieve tekens.</li>
</ul>
<p>Ondersteuning door browsers van <code>font-variant-alternates</code> is nog <a href="https://caniuse.com/#feat=font-variant-alternates">vrij matig</a>, dus voorlopig raad ik aan om <code>font-feature-settings</code> te gebruiken. De syntax hier voor is niet echt vriendelijk:</p>
<pre><code>body {
font-feature-settings: &quot;hist&quot; on, &quot;ss01&quot; on, &quot;swsh&quot; 2;
}
</code></pre>
<h2>Variabele lettertypes</h2>
<p>Als je alle 9 diktes gebruikt op een site, heb je 9 verschillende bestanden nodig, die allemaal door bezoekers gedownload moeten worden.</p>
<p>Daar komt gelukkig langzamerhand verandering in: Variabele lettertypes zijn een relatief nieuwe ontwikkeling waarbij je maar één bestand hoeft te downloaden. Makers van variabele lettertypes bouwen als het ware knoppen in waar je met CSS aan kan draaien. Deze knoppen kunnen de meest uiteenlopende dingen aanpassen aan het uiterlijk van het lettertype. Met variabele lettertypes zijn zelfs meer dan de 9 diktes beschikbaar, en kan je alles tussen <code>font-weight: 1;</code> en <code>font-weight: 1000</code> gebruiken. Browser ondersteuning <a href="https://caniuse.com/#feat=variable-fonts">wordt steeds beter</a>.
<video controls="" width="480" height="270">
<source src="https://www.fronteers.nl/archief/_downloads/2018/adventskalender/2019-vf.mp4" type="video/mp4" />
Download de <a href="https://www.fronteers.nl/nl/blog/2018/12/archief/_downloads/2018/adventskalender/2019-vf.mp4">mp4</a> video.
</video>
Je kan variabele lettertypen gebruiken met fallback naar niet-variabele lettertypen:</p>
<pre><code>@font-face {
font-family: 'mijn lettertype';
src: url('mijn-lettertype-vf.woff') format('woff-variations'),
url('mijn-letertype.woff') format('woff');
}
@font-face {
font-family: 'mijn lettertype';
font-weight: bold;
src: url('mijn-lettertype-vf.woff') format('woff-variations'),
url('mijn-letertype-bold.woff') format('woff');
}
}
/****/
strong {
font-weight: 650; /* wordt afgerond naar 700 door browsers die variabele lettertypes nog niet snappen. */
}
</code></pre>
<p>Variabele lettertypes kunnen potentieel nog veel meer dan het standaard css properties zoals <code>font-weight</code>, <code>font-stretch</code> en <code>font-style</code>. Deze extra eigenschappen kan je een waarde geven met <code>font-variation-settings: {vierlettercode} {waarde}</code>. Hiervoor moet je de vierlettercode van de eigenschappen die je aan wil passen weten, zowel als de minimale en maximale waarde voor die eigenschappen.</p>
<p>Het lettertype 'Jam' heeft bijvoorbeeld 4 eigenschappen: &quot;Bang!&quot;, &quot;Crumble!&quot;, &quot;Splatter!&quot; en &quot;Punch!&quot; die elk een waarde tussen de 1 en 5 moeten hebben:</p>
<pre><code>p {
font-family: &quot;Jam&quot;, monospace;
font-variation-settings: &quot;wght&quot; 3.8, &quot;crum&quot; 3, &quot;spla&quot; 5, &quot;punc&quot; 0;
}
</code></pre>
<h2>Toekomst</h2>
<p>De volgende ontwikkeling die er aan zit te komen zijn kleurenlettertypes: meerdere kleuren in een lettertype, die met CSS aan te passen zijn. Zo zouden 💛 en 💙 de juiste fronteers-kleuren gegeven kunnen worden.</p>
<h2>Wat kan mijn lettertype?</h2>
<p>Heel veel van de genoemde functionaliteit hangt af van de lettertypes zelf, dus hoe kom je er achter wat je lettertype kan? Aanbieders van lettertypes geven gelukkig steeds beter in vertellen wat lettertype kunnen, kijk onder het kopje “Features” of “OpenType features”. Als ze een lijst van gliefen hebben kan je daar ook al vaak het een en ander aan zien: zijn er ligaturen? Verschillende cijfer-vormen?</p>
<p>Je kan fonts uploaden naar een site zoals <a href="https://wakamaifondue.com/">wakamaifondue</a> (spreek uit “What can my font do?”).</p>
<p>Probeer het uit! Met een snel inelkaargeflanst pagina’tje kan je leuk experimenteren.</p>
<pre><code>&lt;!DOCTYPE html&gt;
&lt;html lang=&quot;{taal}&quot;&gt;
&lt;head&gt;
&lt;style&gt;
@font-face {
font-family: '{naam}';
src: url('{font.woff2}'), format('woff2');
}
body {
font-family: '{naam}';
font-variant-ligatures: common-ligatures discretionary-ligatures;
}
&lt;/style&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;p&gt;Welke ligaturen zou dit lettertype hebben? Fi FL Th Qu fi fl ffi ffl st ct th tt qu&lt;/p&gt;
&lt;/body&gt;
&lt;/html&gt;
</code></pre>
<h2>Over Amy Davis</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/amy.jpg" alt="Foto van Amy Davis" class="floating-portrait" />
Ik ben opgegroeid met computers, en altijd gefascineerd geweest door het web, HTML, CSS en JS. In het dagelijkse leven ben ik Senior Front-end developer bij [B-ware Business Software](https://www.b-ware.com). Sinds 2016 ben ik lid van Fronteers en de meeste dagen te vinden op de [Fronteers Slack](https://fronteers-slack.herokuapp.com/). Mijn favoriete kleur is #6c48a4.
<p>Donatie: Wikimedia Foundation
Ik vind het prachtig om een artikel te schrijven over dingen waar ik verstand van heb en zo anderen verder te helpen. Dé organisatie die dit faciliteert op wereldwijde schaal is de <a href="https://wikimediafoundation.org/">Wikimedia Foundation</a>, bekend van Wikipedia en <a href="https://wikimediafoundation.org/our-work/wikimedia-projects/">vele andere crowd-sourced projecten</a>.</p>
</content>
</entry>
<entry>
<title>&quot;Ik doe ook front-end&quot;</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/ik-doe-ook-front-end"/>
<updated>2018-12-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/ik-doe-ook-front-end</id>
<content xml:lang="nl" type="html"><p>Nadat ik kennis heb gemaakt met een Poolse collega bij het koffiezetapparaat, bevliegt mij weer eens een terugkerend vraagstuk. Mijn Poolse collega blijkt een back-end developer te zijn die in een geheel Pools team werkt voor mijn nieuwe opdrachtgever. Terwijl ik tijdens het tappen van mijn espresso uitleg dat ik tijdelijk word ingehuurd als front-end developer, reageert hij direct “Yes, I do front-end too”. Ik dwaal direct af, nadenkend over zijn skills, gezien hij aangeeft een back-end developer te zijn. Ik zie front-end development als een specifiek vakgebied, waar je bepaalde skills voor nodig hebt. Terwijl ik teruglopend naar mijn plek hem nog eens profileer, vraag ik mezelf af; wat voor type front-end developer ben ik zelf eigenlijk?</p>
<h2>Onzekerheid</h2>
<p>Ook ik stop mensen graag in hokjes en geef iemand ongemerkt toch een bepaald profiel. Zou hij oog hebben voor UX? Zou hij pixel-perfect werken? Of voegt hij gewoon soms CSS aan zijn werk toe en doet hij daarom ook front-end? Dit is mijn eerste week bij een nieuwe opdracht. Altijd spannend om weer in aanraking te komen met nieuwe collega’s. Je probeert je weg weer opnieuw te vinden. De onzekerheid slaat soms toe. Terwijl ik juist heel goed weet wat ik kan, weet waar ik goed in ben, merk ik toch dat ik altijd onzeker ben over die ene techniek, waar je al maanden net nog iets meer over wilt weten om er een zelfverzekerd praatje over te houden.</p>
<h2>Communicatief</h2>
<p>Bij iedere nieuwe opdracht moet je iedereen leren kennen. Vaak als freelancer zijn er geen kennismakingsgesprekken met collega’s. In de eerste dagen probeer ik dan te ontdekken wat de mensen daar precies doen. Wie heb je waarvoor nodig? En ook belangrijk, wat kunnen ze precies? Ik kom er in een gesprek achter, dat ik voer met een directeur binnen dit bedrijf, dat in deze organisatie waarde wordt gehecht aan developers met een full stack skillset. Interessante informatie: gezien ik als front-ender goeie kennis heb van HTML, CSS en Javascript, maar toch met jarenlange PHP ervaring, voel ik me tijdens dat gesprek toch wat ongemakkelijk.</p>
<p>Toch twijfel ik over zijn keuze. Zijn alleen full stack developers een goeie keuze voor je eindproducten? Voor wat betreft communicatie denk ik dat front-end developers over het algemeen toch wat meer outgoing zijn dan bijv. back-enders. Makkelijk communiceren is een voordeel. Zo ben je daardoor benaderbaar en is het zelf ook weer makkelijk om wat aan iemand te vragen. Als je bijvoorbeeld niet doorvraagt waarom een bepaalde keuze is gemaakt op design vlak, weet je nooit waarom je het implementeert.</p>
<h2>Oog voor detail en design</h2>
<p>Als front-end developer neem je wat skills mee. Over het algemeen ben je als front-end developer iemand die oog heeft voor detail en gevoel heeft voor UX. Net iets meer padding tussen de kolommen, zodat de content rustiger oogt? De scrollbare tabel juist animeren, zodat de gebruiker nog beter begrijpt hoe deze gescrollt kan worden? Zou mijn collega back-end developer en mijn ‘naar fullstack developers zoekende’ directeur dat principe begrijpen?</p>
<h2>Hongerig naar nieuwe technieken</h2>
<p>Gezien het landschap in front-end land met een rap tempo veranderd, moet je eigenlijk wel hongerig zijn naar nieuwe technieken. Relatief nieuwe CSS modules als Flexbox en CSS Grid worden geadopteerd als de standaard in menig webproject. En Javascript frameworks als Vue en React zijn bijvoorbeeld ook alweer enige tijd niet weg te slaan uit een willekeurige front-end vacature. Ben je er niet mee bekend? Dan kom je op sommige opdrachten niet on-board. Kun je nagaan wat je moet beheersen als fullstack developer?</p>
<h2>“Jij past toch de kleuren aan”</h2>
<p>Aan de andere kant merk ik ook af en toe dat er soms erg makkelijk over front-end werk wordt gedacht. “Oh, jij past toch de kleuren aan”, zei een consultant laatst tegen mij. Klopt! Dat doe ik zeker. En daarvoor heb ik SASS-variabelen gemaakt, zodat wanneer je de klant adviseert de groentint iets donkerder te maken in verband met webrichtlijnen, alles in één keer door het hele project veranderd. Je kunt het ‘m wellicht niet kwalijk nemen, maar het geeft wel aan dat niet iedereen weet wat we doen. Misschien ligt daar ook een communicatieve rol voor een front-end developer?</p>
<h2>Oplevering</h2>
<p>Aan het eind van de dag zal het project worden opgeleverd. Ik ben er van overtuigd dat het resultaat van het project er visueel gezien anders uitziet als een back-end developer die ook front-end werk erbij doet. Je hebt immers niet voor niets een front-end specialist. Een ultiem voorbeeld kwam mij onlangs voorbij toen ik een berg luiers voor mijn dochter bestelde bij Kruidvat Online. Je wordt netjes doorverwezen naar Ogone Payments. Bekijk het zelf. Het werkt. Alles wat je hieronder ziet is functioneel. Precies wat een back-end developer moet doen. Alleen, als ik nog maar naar de ‘Ga verder’ button kijk, gaat het bij mij enorm kriebelen. Je snapt vast wat ik bedoel. Er zit niet eens styling op. Verder staat er dan wel een Norton logo bij, maar dan nog oogt het bij mij nog steeds een beetje ‘unsecure’. Het heeft wat mij betreft meer een beetje de stijl van van een oplichter, die me een email stuurt om mij in te laten loggen bij mijn bank. Ik ben er dan ook echt van overtuigd dat een specialist als een front-end developer wel degelijk een andere denkwijze heeft dan andere specialisten.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/ogone-payments.png" alt="Betaalpagina van Ogone Payments" /></p>
<h2>Wat vind jij?</h2>
<p>Wat voor skills en persoonlijke vaardigheden dient een front-end developer eigenlijk nog meer te hebben volgens jou?</p>
<h2>Over Sander Langendoen</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/sanderlangendoen.jpg" alt="Foto van Sander Langendoen" class="floating-portrait" />
Ik ben Sander Langendoen. Freelance Front-end Developer. Front-end development blijft voor mij een nog niet uitgespeelde game. Ik ben blij dat ik iedere dag betaald mijn hobby mag uitoefenen.
Donatie
The Face This foundation is een stichting die Indonesische schooltjes in nood helpt. Ze vragen de leerlingen tekeningen te maken, en vragen op hun beurt getalenteerde artiesten de tekeningen te verwerken op t-shirt prints. Heb jij een cool shirt of hippe trui. Met de opbrengst van de shirts supporten ze weer de schooltjes.
</content>
</entry>
<entry>
<title>Een API schrijven als een front end developer</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/een-api-schrijven-als-een-front-end-developer"/>
<updated>2018-12-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/een-api-schrijven-als-een-front-end-developer</id>
<content xml:lang="nl" type="html"><p>De laatste 12 maanden ben ik aan de slag gegaan om een “beer-API” te bouwen. De voornaamste reden om een API te bouwen was om te oefenen. En nu laat ik graag zien hoe ik het heb aangepakt. Hopelijk inspireert het jou ook om zelf een API te bouwen, ook als front-end developer! Na dit artikel kun je zelf een kleine API bouwen. Je zou bijvoorbeeld een database kunnen bijhouden met boeken die je hebt gelezen.</p>
<h2>Wat gaan we bouwen?</h2>
<p>Een verkleinde versie van mijn beer-api. Deze versie vraagt biertjes op uit mijn database. Het bevat 1 route, 1 controller, 1 service en 1 view. De view bestaat uit JSON. Het product wat we gaan bouwen kun je vinden op <em><a href="https://github.com/Thomas-Machielsen/beer-api-tutorial/tree/master/final">GitHub</a></em>.</p>
<h2>Technologie die we gaan gebruiken</h2>
<p>Als front-ender kies je er natuurlijk voor om zoveel mogelijk met JavaScript te doen. De meest voor de hand liggende keuze is dan ook Node.js voor de back-end.</p>
<p>Als database heb ik gekozen voor MySQL, omdat ik er al ervaring mee had. Aangezien ik geen MySQL queries wil schrijven gebruik ik <em><a href="http://docs.sequelizejs.com/">Sequelize</a></em>. Sequelize is een JavaScript <em>ORM</em> <a href="https://en.wikipedia.org/wiki/Object-relational_mapping">(Object Relational Mapping)</a> zodat je met JavaScript queries kan schrijven.</p>
<p class="note">
(Ik heb gekozen voor MySQL in dit project maar als ik het weer zou doen, zou ik kiezen voor Mongo of een andere NoSQL taal. NoSQL sluit namelijk beter aan bij JavaScript.)
</p>
<pre><code>this.UserSchema.User.findAll({
attributes: [&quot;username&quot;, &quot;role&quot;],
})
.then(users =&gt; resolve(users))
.catch(reject);
</code></pre>
<p><em>Een sequelize query die alle usernames en beroepsrollen uit de “user” tabel haalt (SELECT username, role from USERS)</em></p>
<p>Als laatste heb ik het populaire <em><a href="https://www.express.com/">Express Framework</a></em> gebruikt. Dit is een eenvoudig en snel in te zetten framework om web applicatie’s te bouwen.</p>
<p class="note">
Express was echter geen goede keus voor dit project omdat ik enkel JSON terug ga sturen, Polka zou een betere keuze zijn geweest. Express heeft namelijk een rendering engine in zich maar dat is in dit specifieke geval overkill.
</p>
<h2>Projectstructuur</h2>
<p><img src="https://www.fronteers.nl/_img/adventskalender/projectstructuur.png" alt="De projectstructuur" /></p>
<p>Om een overzichtelijk project te hebben is het van belang dat je van te voren nadenkt over de projectstructuur. Ik maak gebruik van MVCS (Model Controller View Service), een variant van <a href="https://nl.wikipedia.org/wiki/Model-view-controller-model">MVC</a>.</p>
<p>Een model representeert data, bijvoorbeeld een rij uit de bier-tabel in de database. De controller is een dunne laag tussen de view en de service. De controller vraagt data uit de service en geeft deze data door aan de view. De view in mijn geval is 1 regel code in de controller die de JSON rendert.</p>
<pre><code>res.json({ data: results });
</code></pre>
<p>Nu er een structuur is, kan ik beginnen met bouwen!</p>
<h2>Stap 1: de server starten</h2>
<p>Ik begin met app.js, het startpunt van de applicatie. Hierin start ik de app op en begin ik ook met importeren van packages.</p>
<pre><code>require('dotenv').config();
const express = require('express');
const app = express();
const defaultPort = 3030;
const port = process.env.PORT || defaultPort;
app.listen(port, () =&gt; console.log(`App listening at http://localhost:${port}`)); //eslint-disable-line no-console
</code></pre>
<p>Als je naar <em><a href="https://github.com/Thomas-Machielsen/beer-api-tutorial/tree/master/v1">GitHub</a></em> gaat zie je hoe het project er nu uit ziet.</p>
<p>Het valt je misschien op dat er process.env.PORT staat. Dit zijn <em><em>environment variabelen</em></em>. Deze sla je op in een .env file. Dit is configuratie van een server maar deze configuratie wil je per server instellen. Als ik dit hardcoded erin zou zetten en het dan zou pushen naar de server zou de applicatie kapot gaan. En dan zou ik andere code moeten pushen en dat willen we niet. Dit is gebaseerd op het principe “<em><em>config in the environment</em></em>” van de website <em><a href="https://12factor.net/config">12 factor</a></em>.</p>
<p>Als je dit zou opstarten krijg je een console message. Heel leuk natuurlijk maar verder doet het nog niks.</p>
<h2>Stap 2: routes</h2>
<p>Om verder te gaan wil ik mock data laten zien als de gebruiker naar localhost:3030/api/beers gaat. Hiervoor hebben we een route nodig. Een route is een stukje code die bepaalt waar een request heen gaat. De request is in dit geval /api/beers (een <em><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET">GET</a></em>). In de route vertellen we dan wat er moet gebeuren als /api/beers wordt aangeroepen.</p>
<p>Allereerst gaan we in app.js zeggen dat we gebruik gaan maken van routes.</p>
<pre><code>require('dotenv').config();
const express = require('express');
const app = express();
const defaultPort = 3030;
const port = process.env.PORT || defaultPort;
const router = require('./routes');
app.use(router);
app.listen(port, () =&gt; console.log(`App listening at http://localhost:${port}`)); //eslint-disable-line no-console
</code></pre>
<p>De regel <code>const router = require(‘./routes’);</code> is een verwijzing naar waar het bestandje met routes staat. Vervolgens vertellen we de app deze routes te gebruiken door app.use aan te roepen met als argument router.</p>
<p>In de root van het project maak je een bestandje aan ‘routes.js’. En in dit bestand zet je:</p>
<pre><code>const { Router } = require('express');
const router = module.exports = Router();
// Controllers
const beerCtrl = require('./controllers/beersCtrl');
router.get('/api/beers', [beerCtrl.getBeer]);
</code></pre>
<p>Hierin gebruiken we de router van express. Met router.get zeggen we dat de router moet luisteren naar HTTP methode GET. Als er dus een GET methode komt op /api/beers gaat de applicatie naar de beerCtrl waarin weer een functie staat die ‘getBeer’ heet.</p>
<p>Aangezien we nu een verwijzing hebben naar de beerCtrl moeten we natuurlijk ook de controller maken. De controller haalt data op uit de service en geeft deze door aan de view.</p>
<pre><code>const Sequelize = require(&quot;sequelize&quot;);
const BeerSchema = require(&quot;../schemas/Beer&quot;);
const RatingSchema = require(&quot;../schemas/Rating&quot;);
const BeersService = require(&quot;../services/beers&quot;);
const { STATUSCODES } = require('../constants');
const Beers = new BeersService(Sequelize, BeerSchema, RatingSchema);
const getBeer = (req, res) =&gt; {
Beers.getBeer(req)
.then(results =&gt; res.json(results))
.catch(err =&gt; {
res.status(STATUSCODES.NOT_FOUND);
res.json(err);
});
};
module.exports = { getBeer };
</code></pre>
<p>De controller moet communiceren met de service dus we requiren de BeerService en vervolgen instantiëren we hem door er <em><a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/new">New</a></em> op aan te roepen. Daarna roepen we de functie getBeer van de service aan. We gebruiken hier de request (req) en result (res) objecten van Express. Vervolgens pakken we deze resultaten van de service en renderen we ze terug als JSON. Dan zit er nog wat error handling in maar dat ga ik nu niet behandelen.</p>
<p>Nu moet de Service natuurlijk gemaakt worden. Maak nu een folder aan en noem die services. Vervolgens maken we een bestandje aan: 'beers.js'.</p>
<pre><code>module.exports = class BeersService {
getBeer() {
return new Promise(resolve =&gt; {
resolve({ data: 'beers' })
});
}
};
</code></pre>
<p>Er is voor gekozen om hier gebruik te maken van een class, dit is echter niet per se nodig. Je zou ook een gewone functie kunnen gebruiken.</p>
<p>Als je nu naar localhost:3030/api/beers gaat zie je JSON met daarin “data: ‘beers’”.</p>
<p>Maar dit is mock data. We willen natuurlijk echte data. Op <em><a href="https://github.com/Thomas-Machielsen/beer-api-tutorial/tree/master/v2">GitHub</a></em> zie je nu de huidige status.</p>
<h2>Stap 3: koppelen met echte data</h2>
<p>In het mapje final zit een schema voor de database, database.sql. Als je dit installeert en verbindt met de app kun je dit gedeelte ook draaien. Je kan natuurlijk altijd gewoon blijven lezen.</p>
<p>Zoals ik al eerder aangaf gebruik ik sequelize zodat ik op een JavaScript manier queries kan bouwen en geen SQL queries hoef te schrijven. Eerst moeten we schema’s definiëren. We definiëren hoe de database tabellen in elkaar zitten. Dit komt overeen met hoe de database in elkaar zit. Maak een folder aan en noem die <code>schemas</code>, zet hier Beer.js in.</p>
<pre><code>const dbConfig = require(&quot;../config/db&quot;);
const Sequelize = require(&quot;sequelize&quot;);
const Beer = dbConfig.db.define(&quot;Beer&quot;, {
name: Sequelize.STRING,
userId: Sequelize.INTEGER,
style: Sequelize.STRING,
brewer: Sequelize.STRING,
desc: Sequelize.TEXT
});
const associations = (Rating) =&gt; {
Beer.hasMany(Rating);
};
module.exports = { Beer, associations };
</code></pre>
<p>In dit bestand zeggen we dat er een Beer schema is, die definiëren we met Sequelize. We doen ook een association, hiermee verbinden we het Rating schema met het Beer Schema. Dit hebben we nodig om joins op de query uit te voeren. We zeggen dat één bier (één rij in de tabel) meerdere ratings kan hebben. (Meerdere mensen kunnen hetzelfde biertje raten.)</p>
<p>Hetzelfde doen we voor ratings. Zet dit in Rating.js:</p>
<pre><code>const dbConfig = require(&quot;../config/db&quot;);
const Sequelize = require(&quot;sequelize&quot;);
const Rating = dbConfig.db.define(&quot;Rating&quot;, {
rating: Sequelize.INTEGER,
userId: Sequelize.INTEGER,
beerId: Sequelize.INTEGER
});
const associations = (Beer) =&gt; {
Rating.belongsTo(Beer);
};
module.exports = { Rating, associations };
</code></pre>
<p>De dbConfig bevat informatie om te verbinden met de database. Dit bestand bevat bijvoorbeeld inlog gegevens voor de database.</p>
<pre><code>const Sequelize = require(&quot;sequelize&quot;);
const db = new Sequelize(
process.env.DATABASE_NAME,
process.env.DATABSE_USER,
process.env.DATABASE_PASSWORD,
{
host: process.env.DATABASE_HOST,
dialect: &quot;mysql&quot;,
pool: {
max: 5,
min: 0,
idle: 10000
}
}
);
module.exports = { db };
</code></pre>
<p>Om ervoor te zorgen dat onze beer-service gebruik kan maken van Sequelize, moeten we sequelize beschikbaar maken. We zouden in services/beers.js Sequelize kunnen requiren maar dan kunnen we Sequelize niet mocken. Om in een later stadium services/beers.js te kunnen testen moeten we Sequelize kunnen mocken. Daarvoor gaan we alle dependencies meegeven als een argument aan de service. Dit doen we in de controller.</p>
<pre><code>const Sequelize = require(&quot;sequelize&quot;);
const BeerSchema = require(&quot;../schemas/Beer&quot;);
const RatingSchema = require(&quot;../schemas/Rating&quot;);
const BeersService = require(&quot;../services/beers&quot;);
const { STATUSCODES } = require('../constants');
const Beers = new BeersService(Sequelize, BeerSchema, RatingSchema);
const getBeer = (req, res) =&gt; {
Beers.getBeer(req)
.then(results =&gt; res.json(results))
.catch(err =&gt; {
res.status(STATUSCODES.NOT_FOUND);
res.json(err);
});
};
module.exports = { getBeer };
</code></pre>
<p>Je ziet hier dat ik Sequelize, BeerSchema en het RatingSchema meegeef aan de service. Deze manier van dependencies meegeven aan code wordt ook wel <em><em>dependency injection</em></em> genoemd.</p>
<p>Aangezien we deze dependencies meegeven aan de beer-service moeten we ook zorgen dat de beer-service deze gebruikt.</p>
<p>Dit doen we door een <em><em>constructor</em></em> toe te voegen. Een constructor is een methode van een klasse. De constructor wordt als eerste uitgevoerd zodra de klasse wordt geïnitialiseerd.</p>
<pre><code>constructor(Sequelize, BeerSchema, RatingSchema) {
this.Sequelize = Sequelize;
this.BeerSchema = BeerSchema;
this.RatingSchema = RatingSchema;
}
</code></pre>
<p><em>De constructor in services/beers.js</em></p>
<p>Van de biertjes die we gaan selecteren willen we enkele dingen weten. We zijn geïnteresseerd in de attributen &quot;id&quot;, &quot;name&quot;, &quot;style&quot;, &quot;brewer&quot; en de gemiddelde “rating”. De attributen die we gaan selecteren slaan we op in een aparte functie. Dit volgens het principe <em><a href="https://www.bol.com/nl/f/clean-code-a-handbook-of-agile-software-craftsmanship/9200000033313462/">“<em>functions should do one thing”</em>.</a></em></p>
<p>Hetzelfde gaan we doen voor het koppelen van de twee schema’s.</p>
<pre><code>constructor(Sequelize, BeerSchema, RatingSchema) {
this.Sequelize = Sequelize;
this.BeerSchema = BeerSchema;
this.RatingSchema = RatingSchema;
this.makeAssocations();
this.saveSelectors();
}
makeAssocations() {
this.RatingSchema.associations(this.BeerSchema.Beer);
this.BeerSchema.associations(this.RatingSchema.Rating);
}
saveSelectors() {
this.attributesArrayWithId = [&quot;id&quot;, &quot;name&quot;, &quot;style&quot;, &quot;brewer&quot;];
this.starAttribute = [
[this.Sequelize.fn(&quot;AVG&quot;, this.Sequelize.col(&quot;rating&quot;)), &quot;stars&quot;]
];
};
</code></pre>
<p><em>De constructor in services/beers.js. We slaan de attributen op die we willen opvragen en we koppelen de databases.</em></p>
<p>Nu is het tijd om de query te maken. Zoals reeds gezegd is Sequelize een ORM. Een ORM mapped objecten naar relaties. Een query bouw je dus op uit objecten. Omdat database code async is, werkt sequelize met promises. (Async, await werd destijds nog niet ondersteund, nu wel).</p>
<pre><code>this.BeerSchema.Beer.findAll({
attributes: this.attributesArrayWithId,
required: false,
include: [
{
model: this.RatingSchema.Rating,
attributes: this.starAttribute
}
],
raw: true,
nest: true,
group: [&quot;id&quot;],
where: helpers.getParams(req.params.id)
})
</code></pre>
<p>Hierin wordt gezegd BeerScheme kijk naar de database definitie “Beer”. (Een verwijzing naar Beer in schemas/Beer.js). Vervolgens voeren we het Sequelize commando “findAll” uit. Dit betekent dat ik alle rijen terug wil, die voldoen aan de requirements. (Er bestaat bijvoorbeeld ook findOne). Daarna geef ik op welke attributen ik terug wil zien, zoals aangegeven in de vorige stap.</p>
<p>Daarna include ik de rating tabel. (required, raw &amp; nest sla ik even over, dat is configuratie van Sequelize)</p>
<p>Vervolgens group ik het op id. Dan is er nog een where clause, die verwijst naar een functie namelijk ‘helpers.getParams’. Dit is een helper functie, die of een leeg object meegeeft of een id. In een later stadium kan je met behulp van dat id één biertje opvragen.</p>
<pre><code>this.BeerSchema.Beer.findAll({
attributes: this.attributesArrayWithId,
required: false,
include: [
{
model: this.RatingSchema.Rating,
attributes: this.starAttribute
}
],
raw: true,
nest: true,
group: [&quot;id&quot;],
where: helpers.getParams(req.params.id)
})
</code></pre>
<p>Uit Sequelize komt een promise dus die gaan we opvangen. We kijken eerst of er resultaat is. Zo niet gaan we gelijk weg uit de promise. Dit noem je ook wel het <em><a href="http://rikschennink.nl/thoughts/the-bouncer-pattern/">“bouncer pattern”</a></em>. Het moment dat je weet dat een functie niks meer doet, ga je er gelijk uit weg. Het voordeel is dat je er plattere code door krijgt. Wat weer beter leesbaar is.</p>
<p>Mocht de code echter wel resultaten geven, dan geven we een bericht terug aan de controller. De controller verwacht echter een promise dus we moeten alles nog wrappen in een promise.</p>
<pre><code>getBeer(req) {
return new Promise((resolve, reject) =&gt; {
this.BeerSchema.Beer.findAll({
attributes: this.attributesArrayWithId,
required: false,
include: [
{
model: this.RatingSchema.Rating,
attributes: this.starAttribute
}
],
raw: true,
nest: true,
group: [&quot;id&quot;],
where: helpers.getParams(req.params.id)
})
.then(beers =&gt; {
if (beers.length === 0) { reject(NO_BEERS); }
resolve({
success: true,
beers
});
})
.catch(e =&gt; {
reject(e);
});
});
}
</code></pre>
<p>De volledige code is wederom te vinden op <em><a href="https://github.com/Thomas-Machielsen/beer-api-tutorial/tree/master/final">GitHub</a></em>.</p>
<h2>Conclusie</h2>
<p>Je hebt nu hopelijk genoeg informatie om als hobby-project zelf een API te bouwen. Natuurlijk is dit een versimpelde versie, er zitten bijvoorbeeld geen gebruikers in. De biertjes zijn niet aan te passen, niet te verwijderen en nieuwe toevoegen kan ook nog niet. Toch hoop ik dat dit een basis is voor iedereen om eens zelf een API te bouwen. Want als FED is het erg leerzaam (en leuk!) om zelf een API te bouwen.</p>
<p>En als je interesse hebt in een grotere variant, de volledige code is natuurlijk op <em><a href="https://github.com/Thomas-Machielsen/beer-api">GitHub</a></em>.</p>
<h2>Over Thomas Machielsen</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/thomas.jpeg" alt="Foto van thomas" class="floating-portrait" />
Thomas is een front end developer bij Mirabeau. Daar werkt hij aan allerlei toffe projecten. Dat is ook precies wat die doet in z'n vrije tijd! Zolang het JavaScript is, wordt Thomas gelukkig!
<p>Donatie: Longfonds</p>
</content>
</entry>
<entry>
<title>Beginnen met WebBluetooth</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/beginnen-met-webbluetooth"/>
<updated>2018-12-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/beginnen-met-webbluetooth</id>
<content xml:lang="nl" type="html"><p>Het web is traditioneel altijd goed geweest in het praten met servers. De hele infrastructuur van het web is erop gebaseerd. Maar nu het web dankzij Progressive Web Apps naar native applicaties toe beweegt, hebben we ook de mogelijkheden van native apps nodig. Het ophalen en tonen van tekst, afbeeldingen en formulieren is niet meer genoeg.</p>
<p>Het web is traditioneel altijd goed geweest in het praten met servers. De hele infrastructuur van het web is erop gebaseerd. Maar nu het web dankzij Progressive Web Apps naar native applicaties toe beweegt, hebben we ook de mogelijkheden van native apps nodig. Het ophalen en tonen van tekst, afbeeldingen en formulieren is niet meer genoeg.</p>
<p>Het aantal nieuwe specificaties dat de afgelopen paar jaar is geïmplementeerd is enorm. We hebben specificaties voor 3D, zoals WebGL en binnenkort WebGPU. We kunnen audio streamen, video kijken en de webcam als input device gebruiken. Code schrijven die bijna net zo snel is als native code, met behulp van WebAssembly. En ondanks dat het web oorspronkelijk altijd een netwerkverbinding nodig had, kunnen we nu offline websites en apps maken dankzij Service Workers. Dat is geweldig, maar op één gebied liepen we nog achter op native apps: het praten met andere apparaten.</p>
<p>WebBluetooth is een nieuwe specificatie die beschikbaar is in Chrome en Samsung Internet, die ons in staat stelt om rechtstreeks vanuit de browser te praten met Bluetooth Low Energy apparaten.</p>
<p>Elke dag worden er meer dan 10 miljoen apparaten met Bluetooth-ondersteuning gemaakt. Dat is inclusief computers en mobieltjes, maar ook apparaten zoals hartslagmeters en glucosemeters, IoT-apparaten zoals lampen, en speelgoed zoals op afstand bestuurbare auto's en drones.</p>
<h2>Het saaie theoretische gedeelte</h2>
<p>Omdat Bluetooth geen webtechnologie is, komen de woorden die gebruikt worden ons minder bekend voor. Daarom leg ik kort de terminologie uit en hoe Bluetooth werkt.</p>
<p>Elk Bluetooth-apparaat is een 'Central'-apparaat, of een 'Peripheral'. Alleen central-apparaten kunnen verbindingen maken, en central-apparaten kunnen alleen met peripherals praten. Een voorbeeld van een central-apparaat is een computer of een mobiele telefoon.</p>
<p>Een peripheral kan zelf geen verbinding maken en kan alleen met een central-apparaat praten. Bovendien kan het maar met één central-apparaat tegelijkertijd praten. Een peripheral kan niet met een andere peripheral praten.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/bluetooth/central-peripherals.png" alt="Voorbeelden van central en peripherals" /></p>
<p>Een central-apparaat kan met meerdere peripherals tegelijkertijd praten en zou berichten kunnen doorsturen tussen peripherals. Een hartslagmonitor kan niet praten met lampen, beide zijn peripherals. Maar het is mogelijk een programma te schrijven dat draait op het central-apparaat, dat de hartslag uitleest en de lampen rood maakt als de hartslag boven een bepaalde grens komt.</p>
<p>Als we over WebBluetooth praten, dan praten we over een specifiek gedeelte van de Bluetooth-specificatie met de naam Generic Attribute Profile, die een niet zo logische afkorting heeft: GATT. Omdat GAP al in gebruik was.</p>
<p>En dan praten we niet meer over central-apparaten en peripherals, maar over clients en servers. Je lampen zijn servers. Dat klinkt misschien vreemd, maar het wordt logisch als je er wat langer over nadenkt. Net als een browser, die een connectie maakt met een server op het internet, maakt de client - de telefoon of computer - een connectie met de GATT-server in de lamp.</p>
<p>Elke server biedt één of meerdere services aan. Sommige van deze services zijn gedefinieerd door de standaard, maar je kunt ook je eigen services maken. In het geval van de hartslagmonitor is er een officiële service gedefinieerd in de standaard. Voor de lamp is dat er niet, en elke leverancier probeert hetzelfde probleem opnieuw op te lossen. En iedereen natuurlijk op een andere manier.</p>
<p>Elke service heeft één of meerdere characteristics. Elke characteristic heeft een value welke gelezen of geschreven kan worden. Vergelijk het met een array van objects, met elk object een aantal properties welke een value hebben.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/bluetooth/array-of-objects.png" alt="Array of objects" /></p>
<p>Maar anders dan properties van objecten, worden de services en characteristics niet geidentificeerd met een naam. Elke service en characteristic heeft een unieke UUID die 16 of 128 bits lang kan zijn. Officieel is de 16 bit UUID gereserveerd voor de standaard services, maar dat is een regel die vrijwel niemand volgt.</p>
<p>En tot slot, elke value bestaat uit één of meerdere bytes. Geen strings, of objects, maar enkel een aantal bytes, elk met een waarde van 0 tot 255.</p>
<h2>Hoe ziet een Bluetooth-lamp er uit</h2>
<p>Laten we naar een echt Bluetooth-apparaat kijken: een Mipow Playbulb Sphere. Je kunt een app gebruiken, zoals BLE Scanner of nRF Connect om connectie te maken met het apparaat, en dan alle services en characteristics bekijken. In dit geval gebruik ik de BLE Scanner-app voor iOS.<iframe src="https://player.vimeo.com/video/?texttrack=en" width="640" height="360" frameborder="0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen=""></iframe>Het eerste wat je ziet als je een connectie maakt met de lamp, is een lijst van alle services. Er zijn een aantal standaard services, zoals 'device information' en de 'battery' service. Maar er zijn ook een aantal eigen services. Ik ben vooral geïnteresseerd in de service met de 16 bit UUID <code>0xff0f</code>. Als je deze service bekijkt, zie je een lange lijst met characteristics. En ik heb geen idee wat de meeste van deze characteristics doen, het is geen onderdeel van de standaard, er is helaas geen beschrijving en ze hebben alleen een nietszeggende UUID.</p>
<p>De eerste characteristic met de UUID <code>0xfffc</code> is interessant. Het heeft een value van vier bytes. Als we de value van deze bytes veranderen van <code>0x00000000</code> naar <code>0x00ff0000</code> dan wordt de lamp rood. Veranderen we de value naar <code>0x0000ff00</code> dan wordt de lamp groen, en met de value <code>0x000000ff</code> wordt de lamp blauw. Dit zijn RGB-kleuren en die komen exact overeen met de hex-kleuren die we ook gebruiken voor HTML en CSS. Maar wat doet die eerste byte? Als we de value veranderen naar <code>0xff000000</code> dan wordt de lamp wit.</p>
<p>De lamp bevat 4 LED's en door deze vier bytes te veranderen kunnen we de intensiteit van elk van deze LED's veranderen. En door de intensiteit van de individuele LED's te veranderen kunnen we elke kleur maken die we willen.</p>
<h2>De WebBluetooth API</h2>
<p>Het is mooi dat we een native app kunnen gebruiken om de kleur van een lamp te veranderen, maar hoe doen we dat met de browser? Met de kennis van Bluetooth en GATT die we net hebben opgedaan is dit relatief simpel. Dankzij de WebBluetooth API hebben we maar een paar regels JavaScript nodig om de kleur van de lamp te veranderen.</p>
<h2>Connectie maken met het apparaat</h2>
<p>Het eerste dat we moeten doen is het opbouwen van de connectie van de browser naar het apparaat. We roepen de function <code>navigator.bluetooth.requestDevice()</code> aan met een configuratie-object als parameter. Dat object bepaalt welk apparaat we willen gebruiken en welke services beschikbaar moeten zijn via de API. In het voorbeeld hieronder filteren we de lijst met apparaten op basis van de naam van het apparaat. We willen alleen apparaten zien waarvan de naam begint met 'PLAYBULB'. We specificeren ook dat we de service <code>0xff0f</code> willen gebruiken.</p>
<p>Omdat de requestDevice() function een promise teruggeeft, kunnen we het resultaat 'await-en'.</p>
<pre><code>let device = await navigator.bluetooth.requestDevice({
filters: [
{ namePrefix: 'PLAYBULB' }
],
optionalServices: [ 0xff0f ]
});
</code></pre>
<p>Zodra we deze function aanroepen krijgen we een venster te zien met een lijst van alle apparaten die voldoen aan de filters die we hebben opgegeven. We moeten nu handmatig het apparaat selecteren en handmatig hiermee verbinden. Dit is een essentiële stap, omdat we niet willen dat een willekeurige website zomaar verbinding kan maken met apparaten, of alleen al kan zien welke apparaten je allemaal in huis hebt. De gebruiker heeft de controle.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/bluetooth/connect.png" alt="Bluetooth apparaat verbinden" /></p>
<p>Nu we toegang hebben tot het apparaat kunnen we een connectie maken met de GATT-server door de function connnect() aan te roepen op de gatt property van het device object dat we zojuist terug hebben gekregen. Ook hier kunnen we weer wachten op het result door middel van await.</p>
<pre><code>let server = await device.gatt.connect();
</code></pre>
<p>We hebben nu toegang tot de server en kunnen de function getPrimaryService() aanroepen met de UUID van de service die we willen gebruiken as parameter. En wederom wachten we op het resultaat door middel van await.</p>
<pre><code>let service = await server.getPrimaryService(0xff0f);
</code></pre>
<p>Daarna roepen we de function getCharacteristic() aan met de UUID van de characteristic die we willen gebruiken als parameter.</p>
<pre><code>let characteristic = await service.getCharacteristic(0xfffc);
</code></pre>
<p>We hebben nu de characteristic die we nodig hebben om te lezen en schrijven.</p>
<h2>Schrijven van de value</h2>
<p>Om value te kunnen veranderen moeten we de functie writeValue van de characteristic aanroepen met de value die we willen veranderen als parameter.</p>
<p>De value is altijd een ArrayBuffer. Omdat we een ArrayBuffer niet direct kunnen bewerken, gebruiken we in plaats daarvoor een 'typed array'. Een typed array is een ArrayBuffer met een bepaald formaat, en in ons geval gebruiken we het <code>Uint8Array</code> formaat. De reden dat we geen normale array kunnen gebruiken is dat normale arrays ook andere soorten van data en zelfs lege plekken kunnen bevatten. Een 'typed array' bestaat maar uit één type en is altijd aansluitend. Het formaat <code>Uint8Array</code> betekent dat de array unsigned is en dus geen negatieve getallen kan bevatten; alleen hele getallen kan bevatten; en tevens 8 bits is en dus alleen de waarden 0 tot 255 kan bevatten. Met andere woorden: een array van bytes.</p>
<pre><code>characteristic.writeValue(
new Uint8Array([ 0, r, g, b ])
);
</code></pre>
<p>We weten al hoe deze specifieke lamp werkt. We hebben vier bytes nodig, één voor elke LED. Elke byte heeft een waarde van 0 tot 255 en in dit geval willen we alleen rood, groen en blauw gebruiken. We laten de LED voor wit uit, door de waarde 0 te gebruiken.</p>
<h2>Lezen van de value</h2>
<p>Als we de huidige kleur van de lamp willen weten, dan kunnen we de readValue() function aanroepen en await gebruiken om het resultaat af te wachten.</p>
<pre><code>let value = await characteristic.readValue();
let r = value.getUint8(1);
let g = value.getUint8(2);
let b = value.getUint8(3);
</code></pre>
<p>De value die we terugkrijgen is altijd een DataView van een ArrayBuffer en biedt een aantal functions om data uit de arraybuffer te halen. In ons geval zijn we weer geïntereseerd in de individuele bytes. We gebruiken de getUint8() function met de index van de byte in de array die we willen ophalen als parameter.</p>
<h2>Notificaties wanneer de value verandert</h2>
<p>Als de value van de characteristic op het apparaat verandert, dan is het makkelijk dat de app hiervan op de hoogte wordt gehouden. Niet echt nuttig voor een lamp, maar voor een hartslagmonitor is het onmisbaar. We willen niet elke seconde opnieuw handmatig de huidige waarde ophalen.</p>
<pre><code>characteristic.addEventListener(
'characteristicvaluechanged', e =&gt; {
let r = e.target.value.getUint8(1);
let g = e.target.value.getUint8(2);
let b = e.target.value.getUint8(3);
}
);
characteristic.startNotifications();
</code></pre>
<p>Om een callback te krijgen wanneer de value verandert moeten we de function addEventListener() aanroepen met de parameter 'characteristicvaluechanged' en een callback function.</p>
<p>Zodra de value verandert wordt de callback function aanroepen met een event object als parameter. De value is een property van de target property van het event en weer een DataView van een ArrayBuffer. Daarna kunnen we de individuele bytes opnieuw uit de ArrayBuffer halen door middel van de getUint8() function.</p>
<p>De bandbreedte van het Bluetooth-netwerk is beperkt, daarom moeten we handmatig de notificaties starten door startNotifications() aan te roepen op de characteristic. Zou dit standaard aan staan, dan zou het netwerk overspoeld worden door onnodige data. En bovendien, deze apparaten gebruiken vaak batterijen en elke byte die we niet hoeven te versturen zal het leven van de batterij verlengen, omdat de interne radio van het apparaat niet zo vaak gebruikt hoeft te worden.</p>
<p>En dit is ongeveer 90% van de WebBluetooth API en alles wat je moet weten om te beginnen. Door een paar functions aan te roepen en 4 bytes aan te passen kunnen we een web app maken die de kleuren van je lampen kan aanpassen. Een paar regels meer en je kunt een speelgoedauto besturen of zelfs een drone laten vliegen. En met steeds meer Bluetooth-apparaten op de markt zijn de mogelijkheden eindeloos.<iframe src="https://player.vimeo.com/video/?texttrack=en" width="640" height="360" frameborder="0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen=""></iframe>## Meer informatie:</p>
<ul>
<li><a href="https://webbluetoothcg.github.io/web-bluetooth/">De WebBluetooth specification</a></li>
<li><a href="https://bluetooth.rocks/">WebBluetooth demos op Bluetooth.rocks</a></li>
<li><a href="https://github.com/BluetoothRocks">Source code van de demos</a></li>
<li><a href="https://github.com/opengatt/registry">GATT registry met documentatie voor een aantal apparaten</a></li>
</ul>
<h2>Over Niels Leenheer</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/niels.jpg" alt="Foto van Niels Leenheer" class="floating-portrait" />
Niels is een browser-geek. Vanaf het moment dat iemand hem de allereerste Nexus browser op een NeXT Cube liet zien is hij bezig met browsers. Niels is de maker van HTML5test.com, de CSS selector test, spreekt op conferenties en zit sinds 2018 in de congrescommissie van Fronteers.
<p>Donatie: KWF Kankerbestrijding</p>
</content>
</entry>
<entry>
<title>Hoe een blinde klant zich heel even miljonair waande</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/hoe-een-blinde-klant-zich-heel-even-miljonair-waande"/>
<updated>2018-12-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/hoe-een-blinde-klant-zich-heel-even-miljonair-waande</id>
<content xml:lang="nl" type="html"><p>Tijdens een screenreader demo zorgt het wel eens voor verwarring (of hilariteit) als een Engelse afkorting met een sappig Vlaams accent wordt opgelezen, of wanneer een screenreader iets onverstaanbaars uitkraamt. In uitzonderlijke gevallen leest een screenreader ook iets voor wat er helemaal niet lijkt te staan. <em>Weird</em>!</p>
<p>Front-endontwikkelaars die hun werk testen met een screenreader — dat is een prima gewoonte — komen hierdoor wel eens in de verleiding om 'ter verduidelijking' verborgen stukjes tekst toe te voegen, of te vervangen door iets anders (bijvoorbeeld met behulp van een <code>aria-label</code>).</p>
<p>Is dat nou echt nodig? Of maakt het je webinhoud juist minder toegankelijk? Dat onderzoek ik voor je in dit artikel.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/euros-full.jpg" alt="Collage: stapel eurobiljetten en icoon van een luidspreker" /></p>
<h2>What the FAQ?</h2>
<p>Wat volgt, is een eerder extreem voorbeeld, maar het zet de toon. Een tijd geleden stootte ik op deze vraag in een discussiegroep:</p>
<p>&quot;Help! Jaws (een populaire screenreader) leest de link 'FAQ' in onze navigatie voor als <em>f*ck</em>. Dat wil ik niet. Hoe los ik dat op?&quot;</p>
<p>Behulpzame mensen suggereerden vervolgens vanalles, gaande van het toevoegen van een <code>&lt;abbr title=&quot;Veelgestelde vragen&quot;&gt;</code> tot het vervangen van het woord <em>FAQ</em> door <em>F.A.Q.</em> (waardoor de letters afzonderlijk worden uitgesproken). Het slechtste advies was wellicht om het woord FAQ met behulp van een <code>aria-label</code> te vervangen door het fonetische <em>F E Cue</em> (omdat dat met een Nederlandse stem dan net zo klinkt als FAQ in het Engels).</p>
<p>De tipgevers leken ervan uit te gaan dat iedere screenreader <em>dezelfde</em> text-to-speech (TTS) engine gebruikt (met dezelfde uitspraakregels) en dat TTS de <em>enige</em> manier is waarop blinde gebruikers tekst en webinhoud consumeren.</p>
<p>Wat ze ook over het hoofd zagen, is dat <em>F E Cue</em> in (refreshable) braille vast nog meer wenkbrauwen doet fronsen dan wanneer FAQ als <em>F*ck</em> wordt uitgesproken. De meeste blinden gebruiken TTS en braille immers naast (en door) elkaar, bijvoorbeeld voor het invullen van formulieren en het verbeteren van teksten (een dt-fout kan je immers niet horen).</p>
<h2>Wat is dan de juiste aanpak?</h2>
<p>Een goede raad is om je niet al te druk te maken om zo'n <em>slip of the (synthetic) tongue</em>. Ik zou hoogstens adviseren het woordje FAQ te voorzien van een <code>lang=&quot;en&quot;</code> attribuut. Hierdoor zal een screenreader in de meeste gevallen tijdelijk omschakelen naar een Engelstalige TTS engine voor het oplezen van dat ene woordje. Dat zou je overigens ook kunnen doen wanneer je een Engelse uitdrukking gebruikt, zoals <em>a slip of the tongue</em> dus.</p>
<p>In theorie zou je er ook met CSS voor kunnen zorgen dat een string uitgespeld wordt, bijvoorbeeld door een eenvoudige helper class te gebruiken:</p>
<pre><code>.speak-literal {
speak: literal-punctuation;
}
</code></pre>
<p>Helaas werkt dat dan weer enkel op iOS, dus ook daar kan je niet op vertrouwen.</p>
<p>Maar, omdat je aandringt: hier zijn drie verschillende manieren waarop FAQ kan weerklinken door de speakers van je gebruiker:</p>
<ul>
<li>FAQ wordt netjes (als een letterwoord) gespeld door <em>Alex</em> (een Amerikaanse mannenstem die standaard bij macOS zit).</li>
<li>FAQ wordt (voluit) opgelezen als 'Frequently Asked Questions' door <em>Nora</em> of <em>Samantha</em> (populaire stemmen in VoiceOver op iOS).</li>
<li>FAQ klinkt <em>inderdaad</em> als <em>F*ck</em> uit de (synthetische) mond van de meeste Nederlandse stemmen van fabrikant Nuance, die bijvoorbeeld populair zijn bij Windows-gebruikers.</li>
</ul>
<h2>Let it go</h2>
<p>Je kunt nooit met zekerheid weten welke synthetische stem je gebruiker verkiest of geïnstalleerd heeft, laat staan hoe geavanceerd de <em>voice heuristics</em> zijn die de TTS engine hanteert bij het omzetten van tekst naar kunstmatige spraak. Straks meer over de werking van die heuristics.</p>
<p>Je kan bijgevolg helemaal niet voorspellen hoe <em>FAQ</em> (of een ander woord) zal klinken op het device van jouw gebruiker.</p>
<h2>Hoe werkt dat dan?</h2>
<p>Windows, macOS, iOS en Android hebben een ingebakken Speech API. Die zorgt ervoor dat software-ontwikkelaars gemakkelijk een stem kunnen geven aan hun applicaties. Ook screenreaders als Jaws en VoiceOver maken gebruik van die functionaliteit.</p>
<p>Zo'n Speech API werkt maar in één richting: de screenreader stuurt strings (woorden of lappen tekst) naar de Speech API en geeft hierbij hoogstens aan met <em>welke stem</em> (en dus ook in welke taal) en met <em>welke spreeksnelheid of toonhoogte</em> die fragmenten voorgelezen moeten worden. Dat doet zo'n kunstmatige stem vervolgens plichtsgetrouw, zonder zich bewust te zijn van de context.</p>
<p>(Die stukjes tekst haalt de screenreader overigens eerst — via een Platform API — op uit de <em>accessibility tree</em> van je browser, maar dat is een verhaal voor een andere keer.)</p>
<h2>Stephen Hawking on steroids?</h2>
<p>Kunstmatige stemmen (in alle mogelijke talen) worden tegenwoordig gewoon meegeleverd met het OS. Voor Windows, macOS en Android zijn bovendien diverse <em>third party</em> stemmen te koop die ontwikkelaars via dezelfde API’s kunnen aanspreken. Sommige van die stemmen klinken tegenwoordig verbazend natuurgetrouw (<a href="https://deepmind.com/blog/wavenet-generative-model-raw-audio/">Google Wavenet</a>, anyone?), maar dat is niet per se wat een screenreadergebruiker wil.</p>
<p>Screenreadergebruikers bepalen helemaal <em>zelf</em> welke stemmen hen het meeste comfort bieden. De meeste gebruikers verkiezen hierbij efficiëntie boven 'menselijkheid'.</p>
<p>Een vriend van me is blind. Hij zweert bij een (stokoude) robotische stem met een erg hoge spreeksnelheid (Stephen Hawking on steroids, zeg maar). Voor een ongetraind oor klinkt dat als een onverstaanbaar geratel, maar voor hem is het een uiterst effectieve manier om snel informatie te 'op te nemen'. Het gaat immers veel sneller dan braille lezen, en misschien zelfs sneller dan 'gewoon' lezen (met je ogen dus).</p>
<h2>Voice Heuristics</h2>
<p>TTS engines zitten vol met regeltjes of 'heuristics'. Die zijn bedoeld om de stem zo natuurlijk mogelijk te doen klinken, en zijn verschillend naargelang de stem, de taal, de fabrikant en de versie van de stem (yes, ook stemmen krijgen wel eens een update).</p>
<p>Als een TTS engine té slim wordt, loopt het wel eens mis. Straks meer, maar eerst: speeltijd.</p>
<h2>Tem die stem!</h2>
<p>Om een idee te krijgen hoe die 'regeltjes' werken, is het leuk om zelf wat te experimenteren met hoe verschillende strings voorgelezen worden met verschillende stemmen.</p>
<p>Op macOS kan je in een Terminal-venster het <code>say</code> commando uitvoeren. Met <code>-v</code> kies je de stem. Ga naar <em>Systeemvoorkeuren → Spraak</em> om te zien welke stemmen beschikbaar zijn op jouw computer (of tik <code>say -v ?</code> in de Terminal).</p>
<h2>Enkele leuke voorbeelden:</h2>
<pre><code>say &quot;Lodewijk IV&quot; -v Xander # klinkt als &quot;Lodewijk Vier&quot;
say &quot;Louis IV&quot; -v Alex # klinkt als &quot;Louis The Fourth&quot;
</code></pre>
<h2>Hé, wat is ie slim! Of toch niet?</h2>
<pre><code>say &quot;:-)&quot; -v Alex # klinkt als &quot;&quot; (stilte)
say &quot;:-)&quot; -v Ellen # klinkt als &quot;Blije smiley&quot;
say &quot;(*)&quot; -v Alex # klinkt als &quot;Asterisk&quot;
say &quot;(*)&quot; -v Ellen # klinkt als &quot;&quot; (stilte)
</code></pre>
<p>Je leest (hoort) het goed: de Vlaamse stem Ellen negeert deze drie opeenvolgende karakters (haakje open, asterisk, sluitend haakje) gek genoeg helemaal. Best lastig wanneer je wilt aangeven wanneer iets verplicht in te vullen is. Hier zou een <code>aria-label=&quot;Verplicht&quot;</code> bijvoorbeeld uitkomst kunnen bieden.</p>
<h2>Maar, wat denk je van deze?</h2>
<pre><code>say &quot;1/12/2018&quot; -v Xander # klinkt als &quot;1 december 2018&quot;
say &quot;1/12/2018&quot; -v Alex # klinkt als &quot;January 12, 2018&quot;
</code></pre>
<p>Wacht, wat? Dit zijn toch precies dezelfde strings? Probeert de TTS Engine ons te slim af te zijn?</p>
<p>Xander is een Nederlandse stem, Alex een Amerikaanse. Als je een Amerikaan van vlees en bloed zou vragen om &quot;1/12/2018&quot; voor te lezen, zou hij het net zo interpreteren (en voorlezen) als Alex. Als 12 januari dus. Slim toch, van die computerstem?</p>
<p>En toch zie je dat developers in meertalige applicaties helemaal overboord gaan met dynamisch gegenereerde <code>aria-label</code>'s om ervoor te zorgen dat datums, prijzen, tijdstippen etc. 'juist' opgelezen worden. Helemaal niet nodig, en een vorm van over-engineering waarmee ze het zich enkel lastig maken.</p>
<p>Als je hierop let, gaat het vanzelf goed:</p>
<ul>
<li>Zorg ervoor dat je de (natuurlijke) taal goed aangeeft (bv. met een <code>lang</code> attribuut op het <code>&lt;html&gt;</code> element) zodat de screenreader een TTS engine aanspreekt die de juiste taal spreekt.</li>
<li>Respecteer simpelweg lokale regels over de notatie van datums: als je applicatie in het Nederlands wordt weergegeven, gebruik je <code>dd/mm/jjjj</code>. In het Engels wordt dat <code>mm/dd/yyyy</code>. Dan gaat het vanzelf goed.</li>
</ul>
<h2>Hoe een blinde klant zich heel even miljonair waande</h2>
<p>Ik sluit af met een <em>true story</em>. Deze (sterk vereenvoudigde) markup oogt onschuldig, zeg nu zelf. (Ik heb het stukje HTML geplukt uit de webapplicatie van een bank.)</p>
<pre><code>&lt;h1&gt;Transacties&lt;/h1&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;span class=&quot;date&quot;&gt;1/12/2018&lt;/span&gt;
&lt;span class=&quot;amount&quot;&gt;€ 50&lt;/span&gt;
&lt;span class=&quot;from&quot;&gt;R. Van Gils&lt;/span&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;span class=&quot;date&quot;&gt;31/11/2018&lt;/span&gt;
&lt;span class=&quot;amount&quot;&gt;€ 25&lt;/span&gt;
&lt;span class=&quot;from&quot;&gt;M. Rutte&lt;/span&gt;
&lt;/li&gt;
&lt;/ul&gt;
</code></pre>
<p>Je weet natuurlijk dat <code>&lt;span&gt;</code>'s <em>inline level</em> HTML-elementen zonder semantische eigenschappen zijn. Daarom worden het bedrag en de naam in de accessibility tree 'versmolten' tot de strings <code>€ 50 R. Van Gils</code> en <code>€ 25 M. Rutte</code>. Dat gebeurt overigens ook wanneer de <code>&lt;span&gt;</code>'s met <code>display: flex</code> of <code>display: block</code> worden uitgelijnd (of anderszins opgesmukt), want daar heeft een screenreader lak aan.</p>
<p>De TTS engine zal opnieuw zijn (of haar) beste beentje voorzetten om de aangeleverde strings zo menselijk mogelijk voor te lezen. Dat is immers haar (of zijn) enige taak.</p>
<p>Voor bovenstaand voorbeeld klinkt dat (alweer afhankelijk van de gebruikte TTS engine) ongeveer zo:</p>
<ul>
<li>Kopniveau 1: Transacties</li>
<li>Lijst met 2 items</li>
<li><em>Vijftig euro R. Van Gils</em></li>
<li><em>Vijfentwintig miljoen euro Rutte</em></li>
<li>Einde van lijst</li>
</ul>
<p>Wat? 🙆♀️ Vijfentwintig miljoen? Dat klopt natuurlijk niet. De helpdesk van deze bank reageerde met ongeloof toen een blinde klant dit probleem meldde, en ook de testers wisten er in eerste instantie geen raad mee.</p>
<p>Maar, je begrijpt intussen waar het aan ligt: een gebrek aan semantiek in combinatie met 'slimme' voice heuristics. De voorletter 'M.' zorgt er namelijk voor dat de string <code>€ 25 M. Rutte</code> geïnterpreteerd (en opgelezen) wordt als <em>Vijfentwintig miljoen euro Rutte</em>.</p>
<p>Is het een edge case? Tja, wel eentje die zich voordoet bij alle mensen die M. als voorletter hebben in hun naam. Is het makkelijk te voorkomen? Zeker! Je hoeft dit niet te patchen met <code>aria-label</code>'s. Je lost het simpelweg op door headings, paragrafen en lijsten te gebruiken in plaats van <code>&lt;span&gt;</code>'s. Of wat had je gedacht?</p>
<h2>Conclusie</h2>
<p>Je zal het altijd zien: als je paginasemantiek fout zit (of ontbreekt), gaat de accessibility van je website ook de mist in. Niet enkel omdat het dan lastig navigeren wordt voor screenreadergebruikers, maar dus ook omdat TTS Engines de plank dan vaker misslaan.</p>
<p>Dat neemt niet weg dat het altijd de moeite loont om je website te testen met een <em>echte</em> screenreader. Zo kan je gênante situaties voorkomen.</p>
<p>En, oh ja: maak je niet al te druk over iedere synthetische <em>slip of the tongue</em>, want dat doen jouw gebruikers ook niet.</p>
<h2>Over Roel van Gils</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/roel.jpg" alt="Foto van Roel van Gils" class="floating-portrait" />
Roel noemt zichzelf een Digital Accessibility Nerd. Met zijn bedrijf Eleven Ways (gevestigd in Gent) helpt hij overheden en bedrijven die hun websites en apps voor zoveel mogelijk mensen toegankelijk willen maken. Roel steekt ook wel eens een handje toe bij het organiseren van Fronteers-bijeenkomsten in Vlaanderen. Hij twittert als [@roelvangils](https://twitter.com/roelvangils).
<p>Donatie: Belgisch Centrum voor Geleidehonden
In mijn omgeving heb ik zelf gezien hoe een geleidehond het leven van iemand die slechtziend of blind is helemaal kan veranderen. Ik ken jammer genoeg ook mensen die al jaren uitkijken naar een eigen geleidehond–of een opvolger voor een hond die te oud was geworden. Het opleiden van een hond is enorm tijdsintensief en daardoor is de wachtlijst lang. Ik steun het Belgisch Centrum voor Geleidehonden, een vzw die sinds 1990 alles in het werkt stelt om honden op te leiden en ze daarna kosteloos ter beschikking stelt aan wie ze echt nodig heeft.</p>
</content>
</entry>
<entry>
<title>CSS statistieken om je codebase te verbeteren</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/css-statistieken-om-je-codebase-te-verbeteren"/>
<updated>2018-12-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/css-statistieken-om-je-codebase-te-verbeteren</id>
<content xml:lang="nl" type="html"><p>Front-end is makkelijk, CSS helemaal. Toch valt het veel developers niet mee om complexiteit de baas te blijven bij groeiende CSS codebases. Zeker wanneer met meerdere personen en teams aan een project gewerkt wordt, is het lastig om bij te houden en te controleren of iedereen zich nog wel aan de afspraken houdt. Het klassieke voorbeeld is de monoliet van duizenden regels code die <a href="https://www.projectwallace.com/printdeal/drukzo/colors">meer dan 50 tinten grijs</a> bevat of <a href="https://www.projectwallace.com/teamwallace/smashing-magazine/fontsizes">ruim 100 unieke font-sizes</a>. Gelukkig zijn er tools voorhanden die je inzicht kunnen geven in de CSS die jouw applicatie uitspuugt. Deze tools analyseren je CSS en genereren een rapport met bijvoorbeeld de filesize, het aantal selectors, de unieke kleuren en ga zo maar door. Tijdens <a href="https://codepen.io/bartveneman/pen/OPMevb">een presentatie</a> die ik hierover een aantal jaar geleden gaf, bleek de interesse voor CSS statistiek-tools groot, dus hieronder wat tips om CSS statistieken in te zetten om de kwaliteit van je codebase inzichtelijk te maken en te verbeteren.</p>
<h2>De tools</h2>
<p>Allereerst, de tools. Zelf gebruik ik de volgende tools om statistieken over mijn CSS te laten genereren:</p>
<ul>
<li><a href="https://cssstats.com/">CSS Stats</a> - Webapp en CLI tool om verschillende statistieken over je CSS te visualiseren</li>
<li><a href="https://github.com/katiefenn/parker">Parker</a> - CLI tool/node module voor CSS statistieken</li>
<li><a href="https://github.com/bartveneman/wallace-cli">Project Wallace CSS Analyzer</a> - CLI tool voor CSS statistieken. <a href="https://www.projectwallace.com/">Op de website</a> kan ik bijhouden hoe de statistieken veranderen naarmate de tijd verstrijkt.</li>
</ul>
<p>De ene tool is niet per definitie beter dan de andere. Het is maar wat je er mee wilt bereiken. Voor dit artikel kijken we voornamelijk naar het meten van complexiteit en kwaliteit.</p>
<h2>Complexiteit meten</h2>
<p>‘Echte’ developers hebben het al heel lang, maar wij CSS-nerds zijn nog een beetje verstoken van tooling zoals het meten van bijvoorbeeld <em><a href="https://en.wikipedia.org/wiki/Cyclomatic_complexity">cyclomatic complexity</a></em>. Gelukkig kunnen we met wat statistieken wel vergelijkbare metrics opstellen. Enkele belangrijke metrics die ik zelf toepas om de complexiteit van een codebase te bepalen zijn:</p>
<ul>
<li><em>Gemiddeld aantal identifiers per selector:</em> Lange selectors betekenen dat je CSS nauw verbonden is aan de HTML. Dat betekent dat je styling stuk kan gaan als een kleine wijziging wordt gedaan in je template. Eigenlijk is elke identifier in je selector een if-statement en daarom is deze metric voor mij min of meer gelijk aan het meten van <em>cyclomatic complexity</em>.</li>
</ul>
<pre><code>.my-selector {} /* 1 identifier */
.my #super [complex^=&quot;selector&quot;] &gt; with ~ many :identifiers {} /* 6 identifiers */
</code></pre>
<ul>
<li><em>Average cohesion:</em> Het gemiddeld aantal declarations per ruleset. Een laag gemiddelde is een indicatie van complexe ‘objecten’.</li>
</ul>
<pre><code>/* 1 rule, 1 declaration =&gt; cohesion = 1 */
.text-center {
text-align: center;
}
/* 1 rule, 8 declarations =&gt; cohesion = (1 / 8) = 0.125 */
.button {
background-color: blue;
color: white;
padding: 1em;
border: 1px solid;
display: inline-block;
font-size: normal;
font-weight: bold;
text-decoration: none;
}
</code></pre>
<ul>
<li><em>Filesize:</em> Hoe groter je CSS, hoe complexer…</li>
<li><em>Importants:</em> Hoewel een <code>!important</code> op zijn tijd zeker niet verkeerd is, kan een hoog aantal !importants duiden op een moeilijk onderhoudbaar stuk CSS.</li>
<li><em>Aantal unieke kleuren/font-families/font-sizes:</em> Projecten die honderden unieke kleuren en font-sizes gebruiken zijn lastig. Wanneer weet je of je de juiste <code>font-size</code> of <code>color</code> hebt? En is de grijs van de header nou de goede, of die van de footer? Ach, ik gebruik de color picker van Photoshop wel weer om een kleurtje uit het design te pikken…</li>
<li><em>Aantal unieke @media queries:</em> Zoals met elke metric is het lastig te bepalen wat goed is en wat slecht, maar als ik 150 unieke <code>@media</code> queries zie, dan weet ik dat het lastig gokken wordt om de juiste te gebruiken.</li>
<li><em>Specificity graph:</em> Het gebruik van de <a href="https://csswizardry.com/2014/10/the-specificity-graph/">specificity graph</a> is handig als je wilt kunnen zien waar complexe selectors zich in je codebase bevinden. Daar zijn gelukkig ook <a href="https://isellsoap.github.io/specificity-visualizer/">tools</a> voor!</li>
</ul>
<h2>Kwaliteit meten</h2>
<p>Wat de term kwaliteit inhoudt verschilt per project (evenals complexiteit overigens), maar voor veel projecten gelden de volgende punten zeker:</p>
<ul>
<li><em>Branding - aantal unieke kleuren/font-families/font-sizes:</em> CSS gaat voornamelijk om branding en het mooi maken van webpagina’s. Vormgevers doen hun best op het maken van mockups die wij weer omzetten in code. Daarbij gaat wel eens een detail verloren en kan het gebeuren dat het eindproduct andere kleuren bevat dan de vormgever voor ogen had. Ik heb voor bedrijven gewerkt waar geëist werd dat alle kleuren en fonts voldeden aan de voorgeschreven <em>brand guide</em>. Gelukkig had ik <a href="https://github.com/bartveneman/gromit-cli">tools</a> om aan te tonen dat alles netjes binnen de kaders was.</li>
<li><em>Methodologie - cohesion, gemiddeld aantal identifiers:</em> Een opkomende trend in het CSS-landschap is utility-based CSS. Kort gezegd is dat een stylesheet vol classes die een heel klein dingetje doen. Een kenmerk van zo’n library is dan dus ook dat de cohesion heel dicht bij 1 ligt, evenals het gemiddeld aantal identifiers per selector. Goede metrics om aan te tonen dat je niet afwijkt van je gekozen strategie!</li>
</ul>
<pre><code>/*
Voorbeeld uit Tailwind CSS waar 1 rule
1 selector en 1 declaration heeft:
https://tailwindcss.com/docs/text-color
*/
.text-transparent { color: transparent; }
.text-black { color: #22292f; }
.text-grey-darkest { color: #3d4852; }
</code></pre>
<h2>Bugs opsporen</h2>
<p>Soms kom je onverwachte dingen tegen in je CSS statistieken. Rare selectors of onverwacht complexe declarations. Een greep uit een aantal vondsten die ik de afgelopen tijd in eigen of andermans codebases deed:</p>
<ul>
<li>Fronteers.nl bevat <a href="https://www.projectwallace.com/bartveneman/fronteers/stylesheet">20 lege rulesets</a> 😱</li>
<li>Bol.com heeft een wel <a href="https://www.projectwallace.com/bartveneman/bolcom/selectors">heel rare selector</a>: <code>Bulk beeldmerk 22 mei 2017 .flexbanner--billboard .flexbanner__button.c-btn-tertiary--small.mini_details:before</code></li>
<li>Een project op mijn werk waar een selector als volgt werd getoond als meest complex: <code>input[type=checkbox]:checked+.label input[type=radio]+label:focus:after</code>. Een gevalletje waar we een foutje hadden gemaakt met nesting in de preprocessor (inputs nesten werkt doorgaans niet zo best). Gelukkig zagen we de fout op tijd dankzij <a href="https://www.projectwallace.com/adwise/sportdirect/imports/20181001090916777#selectors.identifiers.top">Project Wallace</a>.</li>
<li>Facebook heeft <a href="https://www.projectwallace.com/teamwallace/facebookcom/colors#duplicate:%23fff">vier verschillende manieren</a> om de kleur wit te beschrijven. Dat is niet noodzakelijk verkeerd, maar het kan een teken zijn van <a href="https://www.projectwallace.com/blog/detecting-color-aliases/">een aantal issues</a> in de codebase, zoals bijvoorbeeld een kapotte CSS minifier.</li>
<li>Catawiki had op enig moment meer dan 4095 selectors (<a href="https://stackoverflow.com/a/9906889">IE selector limit</a>, iemand?) en wetende dat zij IE8+ supporten in verband met een breed internationaal publiek, betekende het dat bezoekers met IE9 niet alle CSS voorgeschoteld kregen wat mogelijk tot bugs geleid heeft. Na een melding hebben zij hun stylesheet in tweeën gesplitst en was het euvel voorlopig verholpen.</li>
</ul>
<h2>Tot slot</h2>
<p>Voor alle metrics die deze tools genereren geldt dat er niet noodzakelijk een goed of fout is. Er zijn developers die zweren bij het nesten van selectors met behulp van preprocessors en er zijn developers die dat haten. Zo zijn er ook mensen die fel gekant zijn tegen het gebruik van <code>!important</code> en mensen die het inzetten om hun utility classes meer kracht bij te zetten. Wat je voorkeur ook is, deze en andere tools kunnen je helpen om de gevolgen van jouw keuzes inzichtelijk te maken voor jezelf, maar hopelijk ook voor anderen. Doe er je voordeel mee.</p>
<p>Wil je meer lezen? Hier enkele leestips:</p>
<ul>
<li><a href="https://csswizardry.com/2016/06/improving-your-css-with-parker/">Improving your CSS with Parker</a></li>
<li><a href="https://www.projectwalace.com/blog">Project Wallace Blog</a></li>
<li><a href="https://webdesign.tutsplus.com/tutorials/understanding-css-stats-how-to-make-the-most-of-the-numbers--cms-22756">Understanding CSS Stats: How to Make the Most of the Numbers</a></li>
</ul>
<h2>Over Bart Veneman</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/bart.jpeg" alt="Foto van bart" class="floating-portrait" />
Bart is frontend developer met een sterke voorliefde voor CSS op elke schaal, maar is ook niet vies van een portie backend op zijn tijd. Al zijn vaardigheden bundelt hij in het bouwen van [ProjectWallace.com](http://projectwallace.com/), een platform voor CSS analytics.
<p>Donatie: KiKa!</p>
</content>
</entry>
<entry>
<title>Word een front-end developer</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/word-een-front-end-developer"/>
<updated>2018-12-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/word-een-front-end-developer</id>
<content xml:lang="nl" type="html"><p>Begin september 2018 heeft <a href="https://medium.freecodecamp.org/my-role-as-a-front-end-web-engineer-explained-948d0f1ceac1">Shaun Michael Stone</a> zijn ervaringen, mening en advies gedeeld over hoe het is om front-end web engineer te zijn.</p>
<p>In dit artikel wil ik mijn ervaringen delen over het begin van een front-end carrière.</p>
<h2>Beginnen met leren</h2>
<p>Veel front-end developers beginnen door te experimenteren. Het is niet zo moeiijk om daarmee te beginnen. Je hebt alleen een browser en een texteditor nodig. Twee hele goede voorbeelden zijn <a href="https://code.visualstudio.com/">Visual Studio Code</a> en <a href="https://atom.io/">Atom</a> en ze zijn gratis! Daarna wil je HTML en CSS leren. Door in een zoekmachine te zoeken naar “HTML tutorial” en “CSS tutorial” zou je al een heel eind moeten komen. Voor je het door hebt, bouw je een website!</p>
<p>Tijdens de experimentele fase zal je vooral het volgende leren:</p>
<ul>
<li>HTML: HyperText Markup Language, de taal om inhoud te organiseren</li>
<li>CSS: Cascading StyleSheets, de taal om de inhoud te stijlen</li>
<li>JavaScript: een programmeertaal waarmee je complexe features kunt bouwen</li>
<li>Basiskennis over browsers en hoe internet werkt</li>
</ul>
<p>Beginnen met HTML en CSS is makkelijk, maar het goed doen is een ander verhaal en vergt best veel kennis. Ik verwacht niet dat junior developers bekend zijn met alle onderwerpen in het lijstje hieronder, maar er van bewust zijn dat het bestaat en wat je kunt leren, kan je wel een voorsprong geven:</p>
<p>HTML</p>
<ul>
<li>Basis: in staat zijn om functionerende HTML te schrijven</li>
<li>Validiteit: in staat zijn om HTML te schrijven met weinig fouten</li>
<li>Browser compatibiliteit: hoe om te gaan met browser incompatibiliteit</li>
<li>Memorisatie: bekend zijn welke HTML tags bestaan</li>
<li>Semantiek: weten welke HTML tag goed is in welke situatie</li>
<li>Toegankelijkheid: markup optimaliseren voor iedereen, ook mensen met beperkingen</li>
</ul>
<p>CSS</p>
<ul>
<li>Basis: in staat zijn om functionerende CSS te schrijven</li>
<li>Validiteit: in staat zijn om CSS te schrijven met weinig fouten</li>
<li>Browser compatibiliteit: hoe om te gaan met browser incompatibiliteit</li>
<li>Responsive ontwerp: weten hoe je een ontwerp optimaliseert voor verschillende apparaten en schermen</li>
<li>Architectuur: weten hoe je dingen moet noemen, verantwoordelijkheden scheidt, bestanden organiseert, en de code onderhoudbaar houdt</li>
<li>Toegankelijkheid: weten wat voor rol stijling bijdraagt aan toegankelijkheid en afweten van beste en slechte praktijken</li>
</ul>
<p>JavaScript</p>
<ul>
<li>Basis: in staat zijn om functionerende JS te schrijven</li>
<li>Probleemoplossend vermogen: weten hoe je een probleem aanpakt om een doel te behalen</li>
<li>Debuggen: hoe je bugs vindt, isoleert en oplost</li>
<li>Web platform: wat kennis van de DOM API (HTML hiërarchie tijdens runtime) en wat Web APIs</li>
<li>Principes: scheiden van verantwoordelijkheden, KISS, etc</li>
<li>Onderhoudbaarheid: hoe je de code onderhoudbaar houdt</li>
<li>Wanneer je het moet gebruiken, en wanneer niet</li>
<li>Verschil tussen ECMAScript en JavaScript</li>
</ul>
<p>Browsers en het internet</p>
<ul>
<li>HTTP Protocol: hoe browsers inhoud laden</li>
<li>Media encoderingen: weten wanneer je gif, jpg, png, svg, webp, mp3, mp4, etc. moet gebruiken</li>
</ul>
<p>Bovenstaande lijst lijkt misschien veel, maar maak je geen zorgen. Focus vooral op HTML, CSS en basis JavaScript. De rest volgt vanzelf.</p>
<p>Beginnende front-end developers ontdekken snel wat JavaScript is en hoe populair het is. De markt heeft veel vraag naar developers die kunnen programmeren met JavaScript. Sterker nog, er is vaak voorkeur naar mensen die vloeiend JavaScript programmeren dan mensen die vloeiend HTML en CSS schrijven, terwijl slechte HTML en CSS vaak problemen veroorzaken wat betreft toegankelijkheid.</p>
<p>Wanneer je de basis leert, leer ook wat JavaScript, maar vergeet niet dat (goede) HTML en CSS essentieel zijn voor websites en webapplicaties.</p>
<h2>Jouw eerste baan</h2>
<p>Je eerste baan is een gigantische mijlpaal! Het is je allereerste stap in je carrière. Maar hoe bereik je die mijlpaal?</p>
<p>Net als met producten is er vraag en aanbod in de banenmarkt die de “prijs” bepaalt. In de banenmarkt is de “prijs” terug te zien in je salaris en extra’s. Momenteel is de markt in ons voordeel: er is veel vraag naar front-end developers, vooral ervaren front-end developers.</p>
<p>Ik verwacht dat het aanbod zal stijgen, maar daarmee moet je meer opvallen ten opzichte van andere mensen die een baan zoeken als front-end developer. Er zijn een paar manieren om dat te doen.</p>
<h2>Haal een diploma</h2>
<p>Ik was heel lui en verveeld op school. Ik denk dat ik met een beetje moeite een bachelor en/of master graad had kunnen behalen, maar dat heb ik niet gedaan. Ondanks dat ik dat niet heb, werk ik met toffe en hele slimme mensen.</p>
<p>Momenteel lijkt het er op dat een diploma niet zo veel helpt. Veel mensen die dit wel hebben, hebben vaak wel een goede theoretische achtergrond en lijken problemen op een meer wetenschappelijke methode te benaderen.</p>
<p>Wanneer de vraag in de banenmarkt groeit, denk ik dat een opleiding in media of informatica belangrijker gaat worden, vooral voor developers die geen of weinig ervaring hebben.</p>
<p>Een studie doen is niet goedkoop en kost veel tijd. Gelukkig zijn er veel bedrijven die de kosten (deels) op hun nemen en soms mag je zelfs tijdens werkuren studeren. Dan kan je studeren en ook je rekeningen betalen! Denk goed na over wat voor opties er zijn en wat het beste bij jou past.</p>
<h2>Zelfstandig leren</h2>
<p>Front-end development is heel goed gedocumenteerd. Online is er heel veel informatie te vinden, wat het mogelijk maakt om een developer te worden door te lezen of online cursussen te volgen. Veel developers die ik ken hebben het vak volledig zelfstandig gestudeerd.</p>
<p>Hier een paar linkjes naar documentatie en cursussen om zelfstandig te studeren:</p>
<ul>
<li><a href="https://developer.mozilla.org/en-US/docs/Web">MDN’s Web Technology for Developers</a></li>
<li><a href="https://www.freecodecamp.org/">freeCodeCamp</a></li>
<li><a href="https://udacity.com/courses/front-end-developer">Front end developer courses on Udacity</a></li>
<li><a href="https://www.udemy.com/topic/web-development/">Web development courses on Udemy</a></li>
<li><a href="https://academy.microsoft.com/en-us/professional-program/tracks/front-end-development/">Microsoft Professional Program for Front-End Web Development</a></li>
<li><a href="https://www.codecademy.com/catalog/language/html-css">HTML &amp; CSS courses on CodeCademy</a></li>
<li><a href="https://www.codecademy.com/catalog/language/javascript">JavaScript courses on CodeCademy</a></li>
<li><a href="https://javascript30.com/">JavaScript30</a></li>
<li><a href="https://es6.io/">ES6 for Everyone</a></li>
</ul>
<p>Je kunt ook lid worden van een gemeenschap zodat je met anderen kan praten over front-end development. Neem bijvoorbeeld de <a href="https://fronteers-slack.herokuapp.com/">Fronteers Slack</a> of <a href="http://fedsonslack.com/">FEDs on Slack</a>.</p>
<h2>Documentatie is belangrijk</h2>
<p>Laten zien wat je gemaakt heb is een goede manier om jezelf te verkopen, dus zorg ervoor dat je een portfolio hebt met wat je gemaakt hebt. Documenteer je projecten (ook van school) en side-projects goed.</p>
<p>Zorg er ook voor dat je niet alleen het resultaat demonstreert, maar ook het proces daar naartoe. Gedurende een project los je uitdagingen op door opties te overwegen. Het verdedigen van die keuzes geeft veel inzicht in hoe goed jij bent en hoe jij keuzes maakt.</p>
<p>Als je schrijven leuk vind, kun je ook artikelen schrijven! Het schrijven van technische artikelen geeft een enorme voorsprong. Sommige bedrijven betalen zelfs om een artikel op hun blog te publiceren, wat mooi meegenomen is.</p>
<h2>Wees zichtbaar</h2>
<p>Laat jezelf zien! Je bent een front-end developer. Het web is jouw domein. Gebruik dat dus!</p>
<ul>
<li>Je kunt <a href="https://www.linkedin.com/">LinkedIn</a> gebruiken als een soort online CV en om je interesses te delen</li>
<li>Publiceer je eigen code (bijvoorbeeld experimenten) op <a href="https://github.com/">GitHub</a></li>
<li><a href="https://codepen.io/">CodePen</a> is een leuke site om kleine demo’s en experimenten te maken en te laten zien</li>
<li>Andere sociale media, zoals Twitter en Facebook, kunnen ook handig zijn om interesses te delen en om te netwerken</li>
<li>Een eigen website met een blog en links naar jouw profielen</li>
<li>Als je een freelancer wilt worden, denk na over een ‘personal brand’ en hoe je jezelf in de markt wilt zetten</li>
</ul>
<p>Misschien valt het op dat veel opties in bovenstaande lijst een offer vergt: tijd. Al is geen van bovenstaande punten vereist om een baan te vinden, je springt er wel door uit, dus durf wat tijd te investeren.</p>
<h2>Overweeg opties</h2>
<p>Wil je generaliseren of specialiseren? In wat voor soort situatie kan je het meest leren? Wat voor soort bedrijf zou jou een kans geven?</p>
<p>Denk goed na over hoe je jouw carrière wilt starten. Wil je een ‘manusje-van-alles’ zijn bij een klein bureau, of wil je specialiseren als een in-house developer met collega’s waar je van kunt leren? Misschien wil je jouw eigen ding doen als een freelancer. Wat je ook kiest, elk heeft voor en nadelen, dus denk daar over na.</p>
<p>Als je andere interesses hebt buiten development, is het leuk om een baan te vinden in die industrie.</p>
<h2>Aan de slag! Wat nu?</h2>
<p>Software verandert constant, dus we moeten up-to-date blijven om relevant te blijven. Denk aan principes, tools, browsers, specificaties, browser compatibiliteit, apparaten en features van apparaten. Dat zijn heel veel onderwerpen om in de gaten te houden en dit verklaart ook waarom het vak front-end development langzaam opsplitst in specifiekere specialisaties.</p>
<p>Als je naar specificaties en documentatie kijkt, kan alleen al de hoeveelheid browser-functies en Web API's schrikbarend veel zijn. Gelukkig heb ik een strategie om niet gek te worden van de hoeveelheid nieuwe informatie.</p>
<p>Een klein deel van al die API’s wordt vaak gebruikt. In plaats van proberen alle API’s te onthouden, lees ik een klein beetje over elke API zodat ik ongeveer weet wat ik kan doen en vergeet ik de details. API’s die ik vaak gebruik, onthou ik vanzelf. Door deze strategie kan ik mij richten op probleemoplossend denken, best practices, patronen, principes en andere dingen die lastig te vertalen zijn in concrete zoektermen.</p>
<p>Om up-to-date te blijven kan ik sociale media aanraden. Ondanks de ruis is het vaak de eerste plek waar nieuws wordt gedeeld. Zoek mensen en bedrijven op die jij interessant vind en volg ze. Hier wat voorbeelden:</p>
<ul>
<li><a href="https://www.reddit.com/r/Frontend/">/r/Frontend</a></li>
<li><a href="https://twitter.com/csswg">@csswg</a></li>
<li><a href="https://twitter.com/htmlwg">@htmlwg</a></li>
<li><a href="https://twitter.com/ecmascript">@ECMAScript</a></li>
<li><a href="https://twitter.com/ChromiumDev">@ChromiumDev</a></li>
<li><a href="https://twitter.com/ChromeDevTools">@ChromeDevTools</a></li>
<li><a href="https://twitter.com/FirefoxDevTools">@FirefoxDevTools</a></li>
</ul>
<p>Lezen en experimenteren met dingen die je leert, zou je tijdens werkuren moeten kunnen doen. Een fatsoenlijk bedrijf zal je die gelegenheid geven en heeft een opleidingsbudget zodat je congressen en workshops kan bezoeken. Maak daar gebruik van! Een paar goede events zijn:</p>
<ul>
<li><a href="http://aneventapart.com/">An Event Apart</a> (Global)</li>
<li><a href="https://beyondtellerrand.com/">Beyond Tellerrand (or btconf)</a> (Germany)</li>
<li><a href="http://cssconf.org/">CSSconf</a> (Global)</li>
<li><a href="https://fronteers.nl/congres">Fronteers Conference</a> (Netherlands)</li>
<li><a href="https://fronteers.nl/workshops">Fronteers Workshops</a> (Netherlands)</li>
<li><a href="https://jsconf.com/">JSConf</a> (Global)</li>
<li><a href="https://smashingconf.com/">SmashingConf</a> (Global)</li>
</ul>
<h2>Werken in je vrije tijd</h2>
<p>Eerder in dit artikel heb ik het werken in je vrije tijd al kort benoemd om een portfolio op te bouwen. Ik moedig dit aan als je een voorsprong wilt hebben op anderen, maar ik wil je ook waarschuwen.</p>
<p>Veel bedrijven erkennen het werk in je vrije tijd niet als extra ervaring. Al zou je, naast een 8-urige werkdag, nog 4 uur investeren in side-projects, heb je na een jaar niet anderhalf jaar ervaring opgebouwd. Maar wat je in die extra tijd hebt geleerd, is natuurlijk wel waardevol.</p>
<p>Ons vakgebied reageert erg positief op werken in je vrije tijd, wat veel mensen motiveert om dat te doen, maar niet zonder consequenties. Het kan bijdragen aan problemen met je geestelijke gezondheid. Veel open-source projecten zijn ten einde gekomen of het beheer is naar iemand anders gegaan omdat de originele auteur last heeft van een burn-out.</p>
<p>Werken (inclusief studeren en experimenteren) in je vrije tijd is niet zonder risico’s. Rust en ontspanning zijn belangrijk, en de balans tussen werk en privé is delicaat. Sommige mensen kunnen heel veel stress hebben. Sommige niet. Een ‘workaholic’ zijn is niet cool.</p>
<p>Ik wil heel duidelijk zijn dat werken in je vrije tijd niet verplicht is en waarschijnlijk ongezond. Jouw werkplek moet de tijd faciliteren om nieuwe dingen te leren. Wat je met je eigen tijd doet, is aan jou.</p>
<h2>Conclusie</h2>
<p>Er zijn veel manieren om front-end web developer te worden. Je kan het jezelf aanleren of met begeleiding door bijvoorbeeld een opleiding te doen. Je kan een generalist of een specialist worden. Je kan zelfstandig beginnen of een bij een bedrijf gaan werken en nieuwe dingen van collega’s leren.</p>
<p>Wat je ook kiest, basiskennis van HTML, CSS en JavaScript is voldoende om aan de slag te gaan. De rest volgt vanzelf.</p>
<h2>Over Tim Severien</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/tim-severien.png" alt="Foto van Tim" class="floating-portrait" />
Tim Severien is een front-end developer uit Nederland. Naast zijn werk blogt hij wel eens op [timseverien.com](https://timseverien.com/) en uit hij zijn creativiteit op [codepen.io/timseverien](https://codepen.io/timseverien).
<p>Donatie: WNF
Ik hou enorm van dieren en de natuur en ik wil dat ze onderdeel blijven van dit kleine brokje in het universum. Daarom doneer ik aan het WNF.</p>
</content>
</entry>
<entry>
<title>Over websites en lekkende kranen</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/over-websites-en-lekkende-kranen"/>
<updated>2018-12-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/over-websites-en-lekkende-kranen</id>
<content xml:lang="nl" type="html"><p>Bij de loodgieter thuis lekt de kraan. Het kind van de dokter is altijd ziek. De schoenmaker loopt op versleten schoenen. Wat heeft het Nederlands <a href="https://twitter.com/onzetaal/status/1012230346912534528">veel spreekwoorden</a> die allemaal ongeveer op hetzelfde neerkomen. Het is dan ook geen wonder waarschijnlijk dat dit voor veel front-enders ook opgaat. Voor anderen de mooiste dingen bouwen, maar de eigen website is vaak een ondergeschoven kindje.</p>
<p>Mijn eigen website is ook zo’n lekkende kraan. In de loop der jaren heb ik er heel wat versleten. Van ‘plain old HTML’ naar Wordpress (en verschillende flirts met andere CMS’en) en uiteindelijk kwam ik toch weer uit bij ‘plain old HTML’. Makkelijk, snel, geen concessies hoeven doen voor een CMS en precies zo te perfectioneren als ik zelf wil. Het enige nadeel: ‘even’ een blogpost maken of andere dingen aan de site updaten, zijn toch wat meer werk dan ik zou willen. Met als gevolg dat mijn website precies aan het rijtje spreekwoorden toegevoegd kan worden. Daar baalde ik eigenlijk een beetje van.</p>
<p>Ik had weleens van het wonder van static site generators gehoord, maar ook dat leek mij niet de heilige graal, tot ik van het bestaan van Netlify leerde. Een commit maken naar Github en de website wordt geüpdatet? Te mooi om waar te zijn, dacht ik. Maar toch de moeite waard om eens naar te kijken. Ik neem je mee in mijn persoonlijke werkwijze. Als je wilt, kun je via <a href="https://github.com/JoseeWouters/Josee-Wouters">mijn Github</a> meekijken.</p>
<h2>Stap 1 - Een static site generator uitkiezen</h2>
<p>Mijn startpunt hiervoor was <a href="https://www.staticgen.com/">https://www.staticgen.com/</a>. Ik had een keer eerder met Nuxt.js gewerkt - het bood toen precies de extra opties die ik met Vue.js wilde gebruiken - maar ik wilde niet direct hiervoor kiezen zonder andere opties te overwegen. Jekyll werkt met Ruby en Liquid, Hugo met Go en Gatsby met React. Nuxt.js is een framework voor Vue.js applicaties. Omdat ik Vue.js geweldig vind, wilde ik daar graag mee werken. Het werd dus toch Nuxt.</p>
<h2>Stap 2 - de eerste opzet met Nuxt</h2>
<p>Je kunt een Nuxt project op twee manieren starten: via npm kun je een een default applicatie opstarten of je kunt ‘from scratch' beginnen door een package.json te maken. Ik koos voor deze laatste optie.</p>
<pre><code>{
&quot;name&quot;: &quot;joseewouters&quot;,
&quot;scripts&quot;: {
&quot;dev&quot;: &quot;nuxt&quot;,
&quot;generate&quot;: &quot;nuxt generate&quot;
}
}
</code></pre>
<p>Het command <code>generate</code> staat niet genoemd in het voorbeeld bij Getting Started op de website van Nuxt.js, maar dit is wel nodig. Anders zul je een error krijgen bij het builden van de website en bij Netlify. Verder kun je wel de stappen volgen die op de website staan.</p>
<p>Behalve het aanmaken van een pages directory heb ik een aantal andere die ik meteen heb toegevoegd. Mijn structuur ziet er als volgt uit:</p>
<pre><code>- assets
- - css
- components
- - app
- - icons
- layouts
- pages
- - blog
- static
- - media
- - - images
</code></pre>
<p>Een aantal dingen van mijn aanpak wil ik uitlichten.</p>
<h2>Icons</h2>
<p>Ik gebruik graag de icons van FontAwesome, maar ik laad liever niet alles in. Daarom sla ik de icons die ik wil gebruiken op in components/icons. Hier heb ik bijvoorbeeld een file iconGithubSquare.vue. Binnen de <code>template</code> tags plaats ik de svg code.</p>
<p>In components/app staan de files voor onder andere de header en footer. Hierin kan ik nu eenvoudig mijn custom icons aanroepen. In AppHeader.vue importeer ik het icon als volgt:</p>
<pre><code>&lt;script&gt;
import iconGithubSquare from '@/components/icons/iconGithubSquare.vue'
export default {
components: {
iconGithubSquare
}
}
&lt;/script&gt;
</code></pre>
<p>Zodat ik vervolgens in mijn HTML het icon kan gebruiken met <code>&lt;icon-github-square/&gt;</code>.</p>
<h2>Blog</h2>
<p>Nuxt.js zorgt er automatisch voor dat de vue-router geconfigueerd wordt, op basis van de files binnen pages. Mijn blogs bevinden zich daarom allemaal in pages/blogs. Daarbinnen maak ik voor elke blog een nieuwe folder. Bevat de desbetreffende blog afbeeldingen, dan zet ik deze hier ook in, zodat ik alles bij elkaar houd. pages/blog/hello-fronteers/index.vue wordt automatisch /blog/hello-fronteers.</p>
<p>Ik schrijf mijn blogs in markdown. Nuxt.js ondersteunt het niet out-of-the-box en het staat ook niet beschreven op de website, maar door het toevoegen van een module kun je het wel beschikbaar maken. Dit doe je door <code>@nuxtjs/markdownit</code> met npm of yarn aan je project toe te voegen en vervolgens deze in <code>nuxt.config.js</code> te plaatsen. Heb je het project net als ik zelf opgezet, dan moet je deze file nog aanmaken in de root.</p>
<pre><code>module.exports = {
modules: [
'@nuxtjs/markdownit'
]
}
</code></pre>
<p>Vervolgens kun je in een .vue file aangeven dat je markdown wilt schrijven met:</p>
<pre><code>&lt;template lang=&quot;md&quot;&gt;
&lt;/template&gt;
</code></pre>
<h2>Layouts</h2>
<p>Voor ik mijn website wil proberen te deployen met Netlify wil ik nog een layout maken. Ik heb zoals gezegd in components/app een aantal files, waaronder de header en footer. Doordat je deze elementen in een layout file importeert, mag een file niet header.vue heten.</p>
<p>In layouts heb ik vervolgens mijn home.vue en blog.vue. Zo heb ik twee templates tot mijn beschikking, een blogpagina en een homepagina.</p>
<p>Mijn home ziet er zo uit:</p>
<pre><code>&lt;template&gt;
&lt;div class=&quot;wrapper&quot;&gt;
&lt;app-header/&gt;
&lt;nuxt/&gt;
&lt;app-footer/&gt;
&lt;/div&gt;
&lt;/template&gt;
&lt;script&gt;
import appHeader from '@/components/app/appHeader.vue'
import appFooter from '@/components/app/appFooter.vue'
export default {
components: {
appHeader,
appFooter
}
}
&lt;/script&gt;
</code></pre>
<p>Het <code>&lt;nuxt/&gt;</code> component wordt alleen in layout files gebruikt om de content te tonen van de pagina, bijvoorbeeld je index.vue.</p>
<p>Om deze layout nu te gebruiken op een pagina, geef je dit eenvoudig aan in het desbetreffende file door middel van:</p>
<pre><code>&lt;script&gt;
export default {
layout: 'home'
}
&lt;/script&gt;
</code></pre>
<h2>Stap 3 - Netlify</h2>
<p>Ik kan nu blogs schrijven in markdown en ik heb een layout waar deze in getoond worden. Klaar voor de volgende stap: het live brengen van de website. Om eerlijk te zijn, had ik hier van tevoren niet zoveel vertrouwen in. Dingen als 'zo gedaan' en 'maar een paar stappen' blijken vaak meer werk dan websites beloven, is mijn ervaring.</p>
<p>Ik volgde de stappen: Registreren bij Netlify met Github, de juiste repository kiezen, een paar build settings en klaar! Nou, niet helemaal. Ik kreeg een foutmelding. Ik had de package.json opgenomen in .gitignore. Niet zo slim, maar snel hersteld. En wonderlijk genoeg, werkte het nu meteen. Zodra ik de commit maakte, ging Netlify bijna direct aan de slag met opnieuw builden en hoogstens een paar minuten later stond mijn website live.</p>
<p>Om een wijziging te maken, heb ik er bijna geen omkijken meer naar: ik maak een nieuwe commit en Netlify doet de rest zelf.</p>
<h2>De lekkende kraan</h2>
<p>Ik geef het niet graag toe, maar mijn website is eigenlijk nog steeds een lekkende kraan. Ik wil nog een keer uitgebreid gaan kijken naar de toegankelijkheid van mijn website, ik wil ervoor zorgen dat nieuwe blogs automatisch in de lijst op de homepage verschijnen en stiekem doet de website het niet zo goed in IE11. Het lijstje met nice-to-have's en need-to-have's is lang. Maar deze werkwijze van Nuxt en Netlify zorgt er voor mij wel voor dat ik makkelijker en sneller even een kleine wijziging kan maken. Ik heb hoop dat het nog wel wat wordt met die kraan.</p>
<h2>Meer weten:</h2>
<ul>
<li><a href="https://nuxtjs.org/">https://nuxtjs.org/</a></li>
<li><a href="https://www.netlify.com/">https://www.netlify.com/</a></li>
<li><a href="https://github.com/JoseeWouters/Josee-Wouters">https://github.com/JoseeWouters/Josee-Wouters</a></li>
<li><a href="https://fronteers.nl/workshops/workshop-netlify-static-site-generators">https://fronteers.nl/workshops/workshop-netlify-static-site-generators</a></li>
</ul>
<h2>Over Josee Wouters</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/josee-square.jpg" alt="Foto van Josee" class="floating-portrait" />
Front-end developer en vrijwilliger bij Fronteers. Werkt naast haar reguliere werk ook freelance en heeft in haar vrije tijd een app genaamd What Dinner? gemaakt. Programmeert ook graag met Arduino.
<p>Donatie: Nationaal Fonds Kinderhulp
Kinderhulp vindt dat in Nederland armoede geen reden mag zijn dat kinderen worden buitengesloten. Kinderhulp wil ervoor zorgen dat alle kinderen er gewoon bij kunnen horen.</p>
</content>
</entry>
<entry>
<title>Hoe test ik de toegankelijkheid van mijn website?</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/hoe-test-ik-de-toegankelijkheid-van-mijn-website"/>
<updated>2018-12-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/hoe-test-ik-de-toegankelijkheid-van-mijn-website</id>
<content xml:lang="nl" type="html"><p>Top! Je wil testen of je website toegankelijk is voor iedereen. Daarmee help je niet alleen de mensen met een beperking, waarvan er steeds meer zijn in onze vergrijzende maatschappij. Een toegankelijke website is voor iedereen fijner in gebruik, en er zijn nog veel meer <a href="https://www.w3.org/WAI/bcase/Overview">goede redenen</a> om met toegankelijkheid aan de slag te gaan.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-testen/keep-clear-accessibility-fail.jpg" alt="Twee drempels met opgangen voor rolstoelen, maar in het midden een bord “”Keep clear for wheelchair users” dat de toegang verspert" /></p>
<h2>Geef mij maar een uitdaging!</h2>
<p>Je zou de <a href="https://www.w3.org/TR/WCAG/">Web Content Accessibility Guidelines</a> (WCAG) door kunnen nemen. Deze richtlijn van het W3C is verankerd in <a href="https://www.w3.org/WAI/policies/">regelgeving</a> en is internationaal de standaard voor toegankelijkheid. Als je dit document tot je wil nemen ben je wel even bezig. WCAG bestaat uit 4 principles met 13 guidelines die onderverdeeld zijn in 78 success criteria. En die gaan dan weer gepaard met een paar honderd &quot;techniques and failures&quot;. Je voelt hem misschien al aankomen: de meest gebruikte richtlijn is niet het meest toegankelijke startpunt.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-testen/wheelchair-sign.jpg" alt="Driehoekig waarschuwingsbord met rolstoel die van helling af glijdt" /></p>
<h2>Vijf simpele tests om de toegankelijkheid van mijn website testen</h2>
<p>Er zijn vijf relatief simpele checks die veel op kunnen leveren. Deze testjes zorgen ervoor dat je met weinig moeite heel wat problemen kunt onderscheppen. Gebruik hierbij de termen &quot;quick wins&quot; en &quot;laaghangend fruit&quot; en iedereen zal je begripvol aankijken.</p>
<h2>Simpele test 1: Kleur en contrast</h2>
<p>De tekst op je pagina moet leesbaar zijn voor iedereen. Een goed contrast helpt niet alleen mensen die slechtziend of kleurenblind zijn, maar bijvoorbeeld ook bezoekers die met hun mobieltje in de zon staan of hun scherm gedimd hebben. Het testen van kleur en contrast is dan ook een waardevolle stap naar toegankelijkheid.</p>
<p>WCAG laat voor grote tekst een lagere contrastwaarde toe dan voor kleine tekst. Grote tekst is in dit geval minimaal 24px, of minimaal 19px en bold. Voor grote tekst moet het contrast minimaal 3.0:1 zijn, en voor normale tekst 4.5:1.</p>
<p>Nu kan ik me voorstellen dat je je bij deze getallen niks kan voorstellen. Gelukkig zijn er tal van tools die je precies kunnen vertellen hoeveel contrast er tussen twee kleuren zit. Je kunt twee kleuren invoeren op de website <a href="https://contrast-ratio.com/">contrast-ratio.com</a>, je <a href="https://developers.google.com/web/updates/2018/01/devtools#contrast">Chrome developer tools</a> gebruiken, of een los programma zoals <a href="https://developer.paciellogroup.com/resources/contrastanalyser/">Contrast Analyser</a> downloaden.</p>
<p>Als je eenmaal een tool gekozen hebt kun je alle teksten op je website nagaan.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-testen/ally.jpg" alt="Rolstoelopgang die begint met 1 traptrede" /></p>
<h2>Simpele test 2: Zoom in en uit</h2>
<p>Heel veel mensen zijn erbij gebaat als er fatsoenlijk in te zoomen is op je website. De site mag dan best overspringen naar een tablet of mobiele versie als die er is. De basis van toegankelijkheid is dat iedereen dezelfde inhoud en functionaliteit kan gebruiken, dus let wel op dat je responsive website een volwaardig alternatief is! Dit kun je gemakkelijk testen met de zoomopties in je browser.</p>
<h2>Simpele test 3: Gebruik je toetsenbord</h2>
<p>Een deel van je bezoekers zal gebruiken maken van zogenaamde assistive technology (AT), ondersteunende technologie. Veel van die technologie communiceert met de browser via de toetsenbord API. Kort gezegd: als je website met een toetsenbord te bedienen is maak je veel mensen blij. Daarbij horen ook bezoekers met een kapotte muis, een gebroken arm en power users.</p>
<p>Test dus even met je toetsenbord of alles werkt. Ga met TAB door je pagina, en weer terug met SHIFT-TAB. Kijk of je al je interactieve elementen (knoppen, links, formulieren, etc) kan bereiken, en of je ze kan bedienen. Let ook goed op of het altijd zichtbaar is welk element de focus van je toetsenbord heeft.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-testen/lb-prague-kunta-hora-14.jpg" alt="Trap met latten die eroverheen liggen" /></p>
<h2>Simpele test 4: Doe een automatische test</h2>
<p>Misschien vraag je je af, waarom testen we niet alles automatisch? Een beetje gezonde luiheid kan geen kwaad. Helaas is alles automatisch testen bij toegankelijkheid geen optie. Een test kan bijvoorbeeld wel zien of een afbeelding een tekstalternatief heeft, maar niet of de tekst ook daadwerkelijk de lading dekt.</p>
<p>Het exacte getal varieert afhankelijk van wie je het vraagt, maar ga er van uit dat zo'n 30% van alle issues automatisch getest kan worden. Gelukkig zitten daar wel een aantal veel voorkomende tussen, dus de winst is alsnog flink.</p>
<p>Er zijn verschillende tools die je kan gebruiken. Zelf ben ik een erg tevreden gebruiker van <a href="https://www.deque.com/axe/">aXe</a>. Deze Javascript library kun je overal in de developer workflow inzetten. Bijvoorbeeld in je <a href="https://webhint.io/docs/user-guide/hints/hint-axe/">linting tool</a>, <a href="https://github.com/dequelabs/axe-core/tree/develop/doc/examples">bij je andere tests</a>, of als <a href="http://bitly.com/aXe-Chrome">browser extension</a>.</p>
<p>De laatste optie is misschien wel de makkelijkste om mee te beginnen. De aXe extensie geeft je developer tools een nieuw tabje met een mooie analyze-knop. Na een druk op de knop krijg je alle issues te zien. Ik zou eerst filteren op &quot;Violations&quot; in plaats van &quot;All issues&quot;, dat maakt het een stuk praktischer. Vervolgens krijg je een overzichtelijke lijst met issues inclusief omschrijving, locatie, oplossing en een hele waardevolle &quot;Learn more&quot;-link waar enorm veel nuttige informatie achter zit.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-testen/1514154-408320525965919-1541568371-n-grande.jpg" alt="Bord weelchair ramp available pleas ask at counter" /></p>
<h2>Simpele test 5: Screen reader</h2>
<p>Bij assistive technology denken men al snel aan screen readers. Een screen reader is software die kan voorlezen wat er op een scherm te zien is, en hier doorheen kan navigeren. Deze software wordt onder andere door blinden en slechtzienden gebruikt. Zo'n screen reader is een flink andere gebruikerservaring dan de meeste mensen hebben. Zeker als je de eerste keer een screen reader start en je computer begint een heel verhaal, dan kan dat even wennen zijn.</p>
<p>Ervaring leert echter dat je helemaal niet veel van een screen reader hoef te snappen om er praktisch mee te testen. Eigenlijk wil je ongeveer hetzelfde doen als eerder met je toetsenbord. Je navigeert door de pagina om te zien (of horen) of je alles kan bereiken, en of je alles kan bedienen. Extra controlepunt is nu of alle onderdelen die je bereikt een logische naam en rol hebben. Een knop moet bijvoorbeeld voorgelezen worden als &quot;button&quot; en niet als &quot;clickable&quot; of &quot;link&quot;. Daarnaast moet de button een naam hebben die past bij de functie. Een menu knop kan bijvoorbeeld voorgelezen worden als &quot;Menu, button&quot;.</p>
<p>Wat je met een screen reader hoort, moet overeenkomen met wat visueel aanwezig is.</p>
<p>Op MacOS heb je <a href="https://www.apple.com/lae/accessibility/mac/vision/">VoiceOver</a> dat het beste resultaat geeft met Safari. Bekijk de <a href="https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts">VoiceOver cheatsheet bij Deque</a>.</p>
<p>Op Windows heb je onder andere <a href="https://www.nvaccess.org/">NVDA</a> dat het beste werkt met Firefox. Bekijk de <a href="https://dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts">NVDA cheatsheet bij Deque</a>.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-testen/m3ed6g0adn001.jpg" alt="zeer steile trap met daarnaast even steile helling met daarop bord voor rolstoepgebruikers" /></p>
<h2>Ok, dan ben ik klaar!</h2>
<p>Nee helaas, zo simpel is het niet. Maar je hebt nu wel een stevige basis. Zorg dat je semantische HTML gebruikt, volg standaarden en denk bij alles wat je maakt na of het mogelijk mensen met een beperking beïnvloedt.</p>
<p>En om af te sluiten nog een aantal praktische bronnen voor als je nog meer wil weten toegankelijkheid.</p>
<h2>Bronnen</h2>
<p><a href="https://www.w3.org/WAI/fundamentals/accessibility-intro/">W3C - WAI - Introduction to Web Accessibility</a></p>
<p><a href="https://www.w3.org/WAI/tutorials/">W3C - WAI - Web Accessibility Tutorials</a></p>
<p><a href="https://www.udacity.com/course/web-accessibility--ud891">Udacity - Web Accessibility</a></p>
<p><a href="https://www.edx.org/course/information-communication-technology-ict-gtx-ict100x">edX - ICT Accessibility</a></p>
<p><a href="https://www.futurelearn.com/courses/digital-accessibility">Future Learn - Digital Accessibility</a></p>
<p><a href="https://accessibility.blog.gov.uk/2016/09/02/dos-and-donts-on-designing-for-accessibility/">GOV.UK - Dos and don'ts on designing for accessibility</a></p>
<p><a href="https://www.w3.org/WAI/WCAG21/quickref/">W3C - WAI - How to Meet WCAG 2 (Quick Reference)</a></p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/toegankelijkheid-testen/title-describes-topic-or-purpose.jpeg" alt="" /></p>
<h2>Over Erik Kroes</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/erik.jpg" alt="Foto van Erik Kroes" class="floating-portrait" />
Erik is onderdeel van het accessibility team van ING. Elke dag probeert hij weer zijn steentje bij te dragen aan de digitale toegankelijkheid van de apps en websites. Daarnaast is hij creatief actief en maakt hij onder andere illustraties voor de Volkskrant.
<p>Donatie: de Hersenstichting</p>
</content>
</entry>
<entry>
<title>Prettier, de eigenzinnige code-opmaker</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/prettier-de-eigenzinnige-code-opmaker"/>
<updated>2018-12-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/prettier-de-eigenzinnige-code-opmaker</id>
<content xml:lang="nl" type="html"><p>Bij HTML, CSS en JavaScript en de meeste andere computertalen is niet voorgeschreven hoe je de code moet opmaken. Alles op één regel of juist niet, veel spaties, tabs of alles dicht op elkaar, voor de computer maakt het echt niet uit.</p>
<p>Dit zorgt er ook voor dat iedereen een eigen stijl ontwikkelt. Dat is op zich niet erg, maar als meerdere ontwikkelaars met elk een eigen stijl aan dezelfde code gaan werken, dan wordt dat lastiger. Met verschillende stijlen wordt de code lastiger leesbaar en als code steeds anders wordt opgemaakt geeft dat vervuiling in het versiebeheersysteem.</p>
<p>Stijl van Gerard:</p>
<pre><code>const hc = h =&gt; h&gt;300?'hoogte-'+hcls:null
</code></pre>
<p>Stijl van Sergey:</p>
<pre><code>function getHeaderClass ( height )
{
headerClass = null;
if ( height &gt; 300 )
{
headerClass = `hoogte-${highHeaderClassname}`;
}
return headerClass;
}
</code></pre>
<p>Vaak gebruiken veel bedrijven daarom coderichtlijnen waarin staat hoe code geschreven moet worden zodat men niet verschillende stijlen door elkaar gebruikt. Vroeger werden die vaak zelf geschreven, maar tegenwoordig kies je er een die al door anderen is geschreven. Een bekende coderichtlijn voor JavaScript is de <a href="https://github.com/airbnb/javascript">coderichtlijn van Airbnb</a>.</p>
<h2>Standaard codestijl</h2>
<p>Zou het niet handig zijn om een tooltje te hebben die je code automatisch naar de juiste stijl herschrijft? Hier komt Prettier om de hoek kijken, want dat is precies wat het doet. Prettier converteert je code naar een standaard codestijl.</p>
<p>Standaard codestijl? Wat is dat? In veel editors met een eigen codeopmaker kan je heel precies aangeven wat jouw favoriete stijl is. Wil je spaties binnen de haakjes van een if? Wil je een spatie voor de accolade van een while?</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/stijlinstellingen.png" alt="Stijlinstellingen" /></p>
<p>Prettier doet het omgekeerde: het gaat uit van één codestijl, waar ze goed over hebben nagedacht en die voor iedereen geldt.</p>
<h2>Hoe gebruik je prettier?</h2>
<p>Je kunt Prettier globaal installeren met:</p>
<pre><code>npm install --global prettier
</code></pre>
<p>Een bestand kan je dan opnieuw opmaken met:</p>
<pre><code>prettier --write filename.js
</code></pre>
<p>Het is echter veel handiger om Prettier op te nemen in je editor. Je kunt dan zorgen dat de tool wordt uitgevoerd met een bepaalde toetscombinatie of zelfs elke keer als je het bestand opslaat.</p>
<p>Dat laatste doe ik en ik merk dat ik al snel productiever werd omdat ik niet steeds handmatig de code hoef op te maken. Ik typ een blurb code zonder spaties en enters… <save> en hoppa, de code ziet er weer netjes uit.</save></p>
<p>Misschien denk je dat een programma nooit de code zo netjes opmaakt als jijzelf. Dat was in ieder geval mijn grootste weerstand om Prettier te gebruiken. Maar de code waar Prettier mee komt, ligt erg in de buurt met hoe ik het ook zou doen. En als je een stukje precies opgemaakte code hebt of bijvoorbeeld een grafiekje in ASCII-art met zijn eigen opmaak, dan kan je <code>// prettier-ignore</code> erboven zetten en de code wordt dan met rust gelaten.</p>
<p>Naast het niet zelf hoeven opmaken, ontdekte ik nog een voordeel. Het zoeken in code wordt beter. Als je bijvoorbeeld zoekt naar <code>varname =</code> dan hoef je niet bang te zijn dat <code>varname=</code> of <code>varname&lt;tab&gt;=</code> worden overgeslagen want al deze code heeft Prettier al veranderd in <code>varname =</code>.</p>
<h2>Toevoegen aan een bestaand project</h2>
<p>Hoe voeg je Prettier toe aan een bestaand project? Als je Prettier begint te gebruiken kan het zijn dat je ergens een bugje oplost, één regel aanpast en dat Prettier ook nog eens het hele bestand opnieuw opmaakt. In je versiebeheersysteem zie je dan niet die ene aangepaste regel, maar heel veel aanpassingen in de opmaak. Je versiebeheersysteem raakt zo erg vervuild.</p>
<p>Beter is om alle bestanden één keer opnieuw op te maken en verder geen andere aanpassingen te maken en die wijzigingen in één commit op te nemen.</p>
<p>Prettier toepassen op alle JavaScriptbestanden gaat op een UNIX-gebaseerd systeem zoals Linux of macOS met dit commando:</p>
<pre><code>find . -name &quot;*.js&quot; | grep -v node_modules | xargs prettier --write
</code></pre>
<h2>Linter</h2>
<p>En wat nu als je ook nog een linter gebruikt? Die kunnen namelijk met Prettier conflicteren. Een optie is om elke keer dat er een conflict is een uitzondering toe te voegen aan het linter configuratiebestand, zo heb ik dat gedaan. Maar op internet kan je ook linter configuratiebestanden vinden die geschikt zijn voor Prettier. Het uitschakelen van de linter is in ieder geval geen goed idee. Een linter kijkt in tegenstelling tot Prettier verder dan alleen de opmaak, het kijkt ook naar veelgemaakte programmeerfouten.</p>
<h2>Uitzonderingen</h2>
<p>Het idee van Prettier is dat er één stijl is die voor iedereen geldt en dat er geen tientallen instellingen zijn. Maar zoals geen enkel programma is ook Prettier niet perfect en al snel kwamen er toch opties om uitzonderingen toe te voegen.</p>
<p>Eén daarvan is <a href="https://prettier.io/docs/en/options.html#jsx-brackets">jsxBracketSameLine</a> dat er zelfs kwam omdat dit een dealbreaker was om Prettier binnen Facebook te gebruiken.</p>
<p>Van de meeste opties kan je gewoon de defaultwaarden kiezen. Twee opties heb ik wel aangepast.</p>
<p>Een daarvan is de achterliggende komma, die sinds ES5 in JavaScript is toegestaan. Als je in JavaScript een lijst met items hebt met elk item op een eigen regel, dan is het handig om achter elke item een komma te zetten. Als je dan een item onderaan toevoegt of weghaalt, dan hoef je geen komma’s aan te passen en in je versiebeheersysteem ziet het er ook netter uit.</p>
<p>De tweede is het altijd gebruiken van ronde haakjes in een fat arrow-functie. Standaard laat Prettier bij een fat arrow-functie met één parameter de haakjes weg. Maar bij geen of meer parameters zijn er wel haakjes. Het is net iets netter om dan altijd haakjes te gebruiken.</p>
<p>Uitzonderingen kan je toevoegen aan het <code>.prettierrc.json</code>-bestand in de root van je project.</p>
<p>Met bovengenoemde twee uitzonderingen ziet deze er dan zo uit:</p>
<pre><code>{
&quot;trailingComma&quot;: &quot;es5&quot;,
&quot;arrowParens&quot;: &quot;always&quot;,
}
</code></pre>
<p>In eerste instantie was Prettier bedoelt voor JavaScript, maar al gauw kwamen daar andere talen bij zoals TypeScript, JSX voor React en CSS.</p>
<p>Op 7 november 2018 is daar met <a href="https://prettier.io/blog/2018/11/07/1.15.0.html">versie 1.15</a> ook HTML-, Vue-, Angular- and MDX-ondersteuning bijgekomen. Er is dus haast geen front-endcode meer die je niet door Prettier kan laten opmaken.</p>
<h2>Over Edwin Martin</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/edwin.jpg" alt="Foto van Edwin Martin" class="floating-portrait" />
Edwin loopt alweer een tijdje mee en kent het internet nog van toen er nog geen World Wide Web was. Toen dit kwam, was hij gelijk verkocht. Edwin is sinds 2000 freelancer en [blogt](https://bitstorm.org/) en [twittert](https://twitter.com/edwinm).
Donatie
Mijn donatie gaat naar Artsen zonder Grenzen. Zij zorgen voor noodzakelijke medische hulp bij natuurrampen en in oorlogsgebieden.
</content>
</entry>
<entry>
<title>Mooi rood is niet lelijk</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/mooi-rood-is-niet-lelijk"/>
<updated>2018-12-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/mooi-rood-is-niet-lelijk</id>
<content xml:lang="nl" type="html"><p>7 tips voor het kiezen van de juiste kleuren voor je website of app</p>
<p>Design is een vak, laat dat duidelijk zijn. Maar soms heb je als websitebouwer even geen budget voor een professionele designer. Of vind je het gewoon leuk om zelf te doen.</p>
<p>Betekent dat dan maar dat je website of app lelijk moet zijn? Zeker niet! Hoewel design veel breder gaat dan alleen het visuele aspect, is het kiezen van de juiste kleuren voor je website behoorlijk bepalend, want hey, het oog wil ook wat. Daarom geef ik je in dit artikel 7 tips voor het bepalen van de juiste kleuren voor je website of app.</p>
<h2>1. Gebruik een color picker tool</h2>
<p>Een handige tool om kleuren te kiezen is de browser addon Colorzilla. Hiermee kun je onder andere bekijken welke kleuren een website gebruikt. Daarnaast kun je met Adobe Color (voorheen Kuler) ook kleurenschema’s samenstellen, of kleurenschema’s gebruiken die door anderen zijn bedacht.</p>
<p>Maar als je eenmaal een kleurenschema hebt gekozen, hoe vertaal je dit naar je website?</p>
<p>Kies allereerst een dominante kleur. Dit is vaak de kleur die voorkomt in het logo. Gebruik deze kleur voor zaken die de aandacht moeten trekken, zoals bijvoorbeeld koppen, buttons, menu’s. Daarnaast kies je één of twee accentkleuren om een kleurenschema te maken. Afhankelijk van de sfeer die je wilt gebruiken, kan dit een complementaire kleur, tint of schaduw zijn. Kies tot slot een rustige achtergrondkleur, maar vaak is wit een goede keuze.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/mooi-rood/kleurenschema-fronteers.jpg" alt="Kleurenschema Fronteers" /></p>
<h2>2. Laat je inspireren door goede bestaande voorbeelden (maar wees geen copycat!)</h2>
<p>Er is niks mis met inspiratie opdoen op websites die je mooi vindt. Kijk daarom naar andere websites en leer. Hoe gebruiken zij accenten? Wat valt je snel op? Komt dat door een kleur? Welke kleuren worden gecombineerd? Het helpt overigens net zo goed om te kijken naar websites die je bloedende ogen bezorgen. Want weten hoe het niet moet, is net zo leerzaam!</p>
<p>Ook belangrijk: zorg dat je niet te veel op een ander lijkt. Je wilt natuurlijk geen copycat zijn.</p>
<p>Zo kwam ik laatst op de website van een zonweringsbedrijf, waarvan ik serieus dacht dat ze een onderdeel van Coolblue waren. Misschien heeft de ontwerper gedacht: wat voor Coolblue werkt, werkt vast ook voor ons. Maar uiteindelijk heeft het een averechts effect op het bouwen van een goed en sterk merk. Je wilt toch niet dat bezoekers aan een ander bedrijf denken als ze jouw website bezoeken?</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/mooi-rood/zonwering-website.jpg" alt="Website zonwering" /></p>
<p>Als we kijken naar de website van Amnesty International, dan is daar duidelijk gekozen om de kleur van het logo als accentkleur te gebruiken. Voor de rest is er een rustig schema gekozen met grijstinten.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/mooi-rood/kleurenschema-amnesty.jpg" alt="Kleurenschema Amnesty" /></p>
<p>De ANWB heeft ook gekozen voor het gebruik van de logokleuren op de website, maar dan voornamelijk het blauw als accentkleur en ook veel (te veel als je het mij vraagt) tinten blauw ter ondersteuning.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/mooi-rood/kleurenschema-anwb.jpg" alt="Kleurenschema ANWB" /></p>
<h2>3. Gebruik Pinterest voor het maken van moodboards</h2>
<p>Het is goed om na te denken over het gevoel dat je op wilt roepen met je website of app. Het kan daarbij helpen om <a href="https://nl.pinterest.com/">een moodboard op Pinterest te maken</a>. Als je uiteindelijk alle foto’s op je moodboard bij elkaar ziet, dan zal je waarschijnlijk een kleurpatroon ontdekken dat de sfeer die je wilt bereiken goed weergeeft.</p>
<p>Met Tineye kun je vervolgens de <a href="https://labs.tineye.com/color/">kleuren uit een of meerdere foto’s halen</a> en deze toepassen in je website.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/mooi-rood/tineye-kleurextractie-van-een-foto.jpg" alt="Kleurextractie van een foto" /></p>
<h2>4. Maak gebruik van kleurassociaties</h2>
<p>Kleuren hebben betekenis. Afhankelijk van je doelgroep, wil je bepaalde kleuren misschien juist wel of juist niet gebruiken. Zo zal een website of app voor een natuurorganisatie zoals Natuurmonumenten gebruikmaken van groentinten. In ons hoofd is dat een logische keuze. Vraag een kind maar eens een boom te tekenen. Negen van de tien keer wordt dat dan een bruine stam met daarboven een groene wolk. Die enkele kunstzinnige expressionist-in-de-dop daar gelaten. Opvallend bij deze website is overigens wel dat de kleur van het logo niet meteen terugkomt in het kleurgebruik op de site.</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/mooi-rood/kleurenschema-natuurmonumenten.jpg" alt="Kleurenschema Natuurmonumenten" /></p>
<h2>5. Bekijk je kleurkeuze in een breder verband</h2>
<p>Een website of app is vaak niet een op zichzelf staand iets, maar onderdeel van een merk. Probeer daarom bij het kiezen van kleuren breder te denken dan alleen de website. Of andersom, als je een logo laat maken, denk dan gelijk aan kleurenschema’s die je op je online uitingen kunt toepassen. Want een logo op zich kan er prachtig uitzien, maar de kleurkeuze kan onwerkbaar zijn in een online omgeving. Wil je een sterk merk opbouwen, dan moet dit consistent worden gebruikt, zowel online als offline. Herkenbare kleuren en beeld zijn hierbij van essentieel belang.</p>
<h2>6. Less is more</h2>
<p>Uiteindelijk geldt ook hier: less is more. Een website of app met veel wit oogt rustig. Gebruik felle kleuren alleen voor kleine elementen en voor elementen die de aandacht moeten trekken, anders wordt het al snel schreeuwerig.</p>
<h2>7. Accepteer dat kleuren er niet bij iedereen hetzelfde eruit zien</h2>
<p>Kleur is belangrijk, heel belangrijk. Maar alsjeblieft: ga niet drie uur lopen nadenken of roze tint 1, 2, 3 of misschien toch 4 beter past in het geheel. Want sorry voor jou: niet iedereen heeft een supersonische, ultragekalibreerde topmonitor waarop de kleuren er net zo lekker uitzien als op jouw scherm. En wat te denken van de avondstand op mobiele apparaten (een fijn geel gloedje over je frisse pastelkleurtjes, joehoe!).</p>
<p>Misschien is een deel van je doelgroep kleurenblind of slechtziend? Bij het kiezen van de juiste kleur is goed contrast dan veel belangrijker dan de laatste trends. <a href="https://www.deque.com/axe/">Met behulp van bijvoorbeeld Axe</a> kun je in je browser kijken of de kleuren van je website voldoende contrast genereren om te voldoen aan de <a href="https://www.w3.org/Translations/WCAG20-nl/">richtlijnen voor toegankelijkheid van webcontent</a>.</p>
<h2>Leer meer over gebruik van kleuren</h2>
<p><a href="https://neilpatel.com/blog/psychology-of-color-and-conversions/">Neil Patel -Psychology of Colour and Conversions</a></p>
<p><a href="https://digitaladblog.com/2013/12/27/the-meaning-of-color-in-company-logos-infographic/">The meaning of colour in company logos</a></p>
<p><a href="https://www.websitebuilderexpert.com/designing-websites/how-to-choose-color-for-your-website/">How to chose colour for your website</a></p>
<p><a href="http://www.meulenhoff.nl/nl/p4c36fcf32b2f4/15227/9789029091732/het-geheime-leven-van-kleuren.html">Boek: Het geheime leven van kleuren</a></p>
<p><a href="https://palermocafe.com/colors-make-hungry/">What colours make you hungry?</a></p>
<h2>Handige tools</h2>
<p><a href="https://labs.tineye.com/color/">https://labs.tineye.com/color/</a> - haal kleuren uit een foto</p>
<p><a href="http://www.colorzilla.com/">http://www.colorzilla.com/</a> - kleurenkiezer add on voor je browser. Laat ook gebruikte kleuren op een website zien.</p>
<p><a href="https://sipapp.io/">Sip colourpicker (voor de Mac)</a> – betaald, maar handige offline tool om kleurenschema’s te bewaren</p>
<p><a href="https://color.adobe.com/">Adobe color cc</a> – online gratis kleurenkiezer van Adobe.</p>
<p><a href="https://www.deque.com/axe/">Axe</a> – kleurcontrast checker voor je browser developer toolbar.</p>
<h2>Over Monique Dubbelman</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/monique-dubbelman.jpg" alt="Foto van Monique" class="floating-portrait" />
Monique Dubbelman is in de vorige eeuw opgeleid als grafica. Omdat dat inmiddels een fossiel beroep is, bouwt en ontwerpt ze sinds de jaren negentig websites, tegenwoordig vooral met WordPress. Eerst als hobby, vanaf 2011 als professional onder de naam BOE!media. In 2016 behaalde ze haar bachelor in Media, Informatie en Communicatie aan de Hogeschool van Amsterdam. Monique maakt zich druk over de inhoud, structuur en gebruiksvriendelijkheid van websites en vindt bovendien dat er een heldere strategie achter mag zitten. Naast UX designer noemt ze zich daarom ook digitaal of contentstrateeg. Op het internet is ze ook nog terug te vinden als wormenfluisteraar.
Donatie
Mijn donatie gaat naar Stichting No Guts No Glory. Deze stichting zamelt geld in voor behandelingen tegen kanker die nog niet vergoed worden door zorgverzekeraars. Niet door zielige verhalen te vertellen, maar door het leven te vieren met als motto: no guts no glory! Ze bieden financiële en morele steun aan kankerpatiënten en gebruiken (social) media om aandacht te vragen voor het probleem. Zij vinden namelijk dat geld geen reden mag zijn om iemand een kans op extra behandelingen te ontnemen (en ik ben het daar mee eens!).
</content>
</entry>
<entry>
<title>In evenwicht</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/in-evenwicht"/>
<updated>2018-12-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/in-evenwicht</id>
<content xml:lang="nl" type="html"><p>Ons front-end vakgebied is ontzettend breed. Elke week zie ik weer iets waar ik me in wil verdiepen omdat het me interessant lijkt. Een nieuw trucje met CSS custom properties, de nieuwe versie van VueJS, het ontcijferen van Heap Snapshots in Chrome…</p>
<p>Daarnaast heb ik dingen die ik specifiek moet weten voor m’n werk. Ik ben bekend met WordPress, Alterian, Hippo, en EpiServer. Mijn nieuwe baan is echter bij een bedrijf dat grotendeels werkt met Drupal. Drupal leren is geen kleinigheidje, er is een hoop te leren en van alleen front-end doen is geen sprake meer: PHP behoort inmiddels ook tot mijn werkzaamheden, net als bekend raken met de quirks van Drupal en de verschillende implementaties voor verschillende klanten.</p>
<p>Verder heb ik eigen projecten waar ik mee bezig ben. Ik ben onder andere bezig met een op JavaScript gebaseerde tekenrobot en mijn domotica-huiskamer.</p>
<h2>Spanningsveld</h2>
<p>Er is zo veel te zien, te leren, en te doen: tijd is schaars. Maar laat dat nou ook precies de situatie zijn die ik veel zie tijdens mijn werk. Klanten willen iets binnen een bepaalde deadline online hebben, tegen een afgesproken prijs. Agile of niet: dit spanningsveld is er altijd. Voor mij en anderen in mijn omgeving resulteert dit in snel werken: als ik een beproefde manier heb om iets te maken dan doe ik dat. De techniek staat alleen niet stil in de tussentijd. Een voorbeeld: Bootstrap als gridsysteem werkt fantastisch maar CSS Grid Layouts zijn inmiddels ook in te zetten voor hetzelfde doel.</p>
<p>Het resultaat van deze snelle of zelfs haastige manier van werken heeft vaak blije klanten tot gevolg, maar heeft ook nadelen. De klant is blij dat het binnen budget is opgeleverd maar met CSS Grid Layouts heb ik nog niets gedaan: er was simpelweg geen tijd voor om eventueel onvoorziene problemen op te lossen. Onvoorziene problemen zijn er genoeg als je een nieuwe techniek inzet. Mijn vakgebied heet dan ook Front-end <em>development</em>. De term 'development' impliceert al dat ik iets <em>ontwikkel</em> en dingen tegen kan komen.</p>
<h2>Het wiel opnieuw uitvinden</h2>
<p>“Waarom bouw je dit filter zelf in vanilla JavaScript, terwijl je ook een jQuery plugin kan gebruiken?” is de meest recente vraag die ik kreeg die te maken had met het spanningsveld. Ik had voor deze user story (wens van de klant) bewust de keuze gemaakt dit handmatig te doen. Iets meer tijd nemen om er iets van te kunnen leren. Ik sprong er natuurlijk niet helemaal blanco in: ik heb eerder zoiets gemaakt, maar had tijdens dat project al een idee hoe het beter kon en dat wilde ik proberen.</p>
<p>Tijdens de bouw kwam ik onvoorziene bugs tegen, waardoor het meer tijd kostte dan ik zelf had ingeschat. Ik kreeg dan ook de vraag of het al bijna klaar was. Ik had voor mezelf de juiste keuze gemaakt: ik zou wat kunnen uitzoeken/leren maar had voor de klant de minder snelle optie gekozen. Mijn idee was eerst om dit thuis uit te zoeken, zodat het geen extra tijd zou kosten voor de klant en ik iets kon leren. Raar eigenlijk, nieuwe dingen leren hoort immers bij ons werk!</p>
<h2>Thuis doorgaan</h2>
<p>Ik spreek online, via meetups, en tijdens conferenties veel mensen die hetzelfde werk doen als ik. Velen herkennen zich in het verhaal dat ze thuis nog dingen uitzoeken na werktijd. Logisch: veel mensen herkennen het spanningsveld dat ik omschrijf en veel zijn erg enthousiast over het werk dat ze doen.</p>
<p>Dit is vaak niet puur en alleen enthousiasme. Vaak heeft het ook te maken heeft met een bepaalde druk die je als front-end developer kunt voelen. Online zie je de meest toffe dingen, op conferenties gaan mensen superhard, je hebt collega’s die een enorme ontwikkeling laten zien, en in vacatures worden <em>‘helden’</em> en <em>‘goeroes’</em> gevraagd.</p>
<p>Ook ik was thuis dingen aan het uitzoeken en proberen. Ik zat me thuis te verdiepen in dingen als routing in React en hoe ik in vredesnaam iets opmeet in Sketch. Dingen die ik nodig heb voor werk, die ik thuis aan het bijleren was.</p>
<h2>We verwennen onze klanten</h2>
<p>Een van de oorzaken van de druk die ik en mensen die ik spreek voelen is dat we onze klanten verwennen. Klanten zien de waarde van ons werk niet, en dat hebben we deels zelf veroorzaakt.</p>
<p>We kiezen in verband met tijdsdruk vaker een snelle route om binnen budget te blijven, we werken langer door om die gedoemde sprint tóch te halen, en we houden onszelf daarnaast thuis up-to-date in ons vakgebied. Begrijp me niet verkeerd; een keer is niet erg, ik heb het hier over dat ik merk dat mensen dit structureel doen.</p>
<p>Ook de klant is deel van de oorzaak. Ons werk als front-end developer is ontzettend complex. Klanten zien vaak niet hoeveel er mis kan gaan bij bijvoorbeeld iets simpels als het toevoegen van een knop.</p>
<blockquote>
<p>We shouldn’t be surprised if anything fails, we should be surprised that anything ever works at all.</p>
</blockquote>
<h2>Een andere kijk</h2>
<p>Op een avond stonden m'n ouders ineens voor de deur, ze waren bij het ziekenhuis geweest. Mijn moeder had daar de diagnose kanker gekregen.</p>
<p>Nieuws als dit leert je relativeren. Naar aanleiding van de diagnose heb ik uiteindelijk ontslag genomen bij m'n toenmalige werkgever, zonder iets nieuws te hebben. Ik trok aan de handrem. 1 januari van dit jaar was ik vrij om te doen en laten wat ik wilde. Werkloos maar heel tevreden; ik had aan de handrem getrokken door ontslag te nemen en was af van de druk om dingen snel op te leveren, maar tegelijkertijd ook bij te blijven.</p>
<p>In deze periode ben ik gaan inzien dat je, hoeveel je ook thuis bij leert, je het nooit gaat redden. En dat er andere dingen zijn in het leven; mijn werk en privé was achteraf gezien uit balans.</p>
<p>Ik heb inmiddels een nieuwe baan waarin ik de balans scherp in de gaten houd. Thuis is nu ook daadwerkelijk thuis, niet meer een verlengstuk van werk. Ik heb nog wel werkmail en Slack op m’n telefoon maar die zijn er <em>on demand</em>, de push notificaties staan uit.</p>
<h2>Inzichten</h2>
<p>De ziekte van mijn moeder heeft me dingen laten inzien die ik anders waarschijnlijk gemist had. Altijd maar haasten bijvoorbeeld, dit werkt als een patch. Je kunt het een paar keer doen maar uiteindelijk stort de boel in omdat je niet de aandacht hebt gegeven die het verdiende. Ditzelfde geldt voor je persoonlijke ontwikkeling: besteed hier tijdens werktijd gericht aandacht aan. Spreek je werkgever erop aan als je voelt dat je niet genoeg kunt leren op de plek waar je zit. De vraag naar front-end developers is enorm, ze zouden gek zijn je te laten gaan omdat je beter wilt worden!</p>
<p>Het meenemen van klanten in hoe complex iets kan zijn - van concept tot oplevering - helpt bij het minder gehaast werken. Er is uiteindelijk meer begrip en daarmee ook meer ruimte om eens te kunnen experimenteren voor je eigen ontwikkeling. Ook het niet halen van een sprint werd daardoor als minder erg gezien door de klanten voor wie ik heb gewerkt. Morgen weer een dag, hoe dramatisch die ook lijkt te gaan worden als iets niet afkomt.</p>
<p>Werk is ook maar werk, durf los te laten! Na werktijd is het tijd voor wat anders. Fanatieke sporters weten: rust is ook onderdeel van de training. Zo is het ook met werk. Wat ik eigenlijk wil zeggen, is dit: let op jezelf!</p>
<p>Nog een laatste inzicht (of eigenlijk meer een verzoek van mij) voor als je bij het kerstdiner aanschuift: Geef je familie en vrienden een extra dikke knuffel dit jaar als je ze ziet, ze zijn het waard!</p>
<h2>Over Tom Hartwig</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/tomhartwig.jpg" alt="Foto van Tom Hartwig" class="floating-portrait" />
Tom werkt als front-end developer bij een digital agency in Haarlem, klimt graag in zijn vrije tijd, en is op Twitter te vinden als [@tmhrtwg](https://twitter.com/tmhrtwg).
Donatie
Bij elke van de adventskalender blogposts deze maand hoort een donatie aan een goed doel. Mijn donatie gaat naar KWF Kankerbestrijding. Ik ben ontzettend blij dat de behandeling van mijn moeder aansloeg en ze deze kerst nog bij ons is!
</content>
</entry>
<entry>
<title>Begin met regular expressions</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/begin-met-regular-expressions"/>
<updated>2018-12-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/begin-met-regular-expressions</id>
<content xml:lang="nl" type="html"><p>Misschien dat je het wel kent: als je in je team begint over regular expressions trekken er vaak direct een aantal lijkbleek weg en beginnen er meteen een aantal anderen te kwispelen van enthousiasme. Allebei hebben ze gelijk, het is een soort superwapen. Een superwapen waarmee je soms met een regel code honderden regels code kunt besparen. In goede handen los je bondig problemen op. In de verkeerde handen leidt het tot code die niemand meer wil aanraken. Dit artikel is bedoeld als een inleiding voor die mensen die lijkbleek wegtrokken, maar nu toch wel nieuwsgierig geworden zijn.</p>
<h2>Wat zijn regular expressions eigenlijk?</h2>
<p>Regular expressions zijn als het ware een eigen programmeertaal met een eigen syntax. Het is een feature waarmee je eenvoudig een reeks tekens of groepen van tekens kunt herkennen. Bijvoorbeeld alle woorden in een tekst die op een ‘s’ eindigen. In haast elke programmeertaal is de basis hetzelfde. Zelfs JavaScript ondersteunt het al sinds EcmaScript 3 (1999).</p>
<p>Een scenario waarin een regular expression van pas komt, is als je dynamische input van een formulier alvast in de front-end wilt valideren. Bijvoorbeeld een postcode. Het officiële format van een postcode is vier cijfers, een spatie en twee hoofdletters. Met regular expressions kun je eenvoudig controleren of een ingevulde postcode correct is en de gebruikers zelfs een handje helpen met het automagisch aanvullen of correct formatteren van de postcode.</p>
<p>In JavaScript zijn regular expressions een soort object waaraan je kunt refereren in een variable.</p>
<pre><code>const mijnEigenRegExps = new RegExp('wow');
</code></pre>
<p>De meest voorkomende vorm waarin je regular expressions in JavaScript tegenkomt, is als <em>literal</em> regular expression welke herkenbaar is door twee forward slashes.</p>
<pre><code>const mijnEigenRegExps = /wow/;
</code></pre>
<p>In veel (string) methods kun je een regular expression ook als argument gebruiken. Onder andere bij de methods <code>replace</code> en <code>split</code> is dit het geval. Dit biedt extra flexibiliteit en functionaliteit.</p>
<pre><code>'Een soort superwapen'.replace('super', 'hyper');
// &quot;Een soort hyperwapen&quot;
'Een soort superwapen'.replace(/super/, 'hyper');
// &quot;Een soort hyperwapen&quot;
'Koe, schaap, kip'.split(/, /);
// [&quot;Koe&quot;, &quot;schaap&quot;, &quot;kip&quot;]
</code></pre>
<h2>Leer basis concept(en)</h2>
<p>Laten we kijken of er een <code>a</code> character in de onderstaande string staat. Met de <code>test</code> method op een regular expression kun je eenvoudig zien of een character voorkomt in een string.</p>
<pre><code>/a/.test(&quot;Content Security Policy (CSP) is an added layer of security.&quot;);
// true
</code></pre>
<p>Stel, je wil alle <code>a</code> characters in een stukje tekst vervangen door een emoji. Daarvoor kun je de <code>replace</code> (string) method gebruiken die zowel een string als een regexp als argument accepteert. Met een normale string loop je snel tegen limitaties op.</p>
<pre><code>const txt = &quot;Content Security Policy (CSP) is an added layer of security.&quot;;
txt.replace('a', '❤️');
// &quot;Content Security Policy (CSP) is ❤️n added layer of security.&quot;
txt.replace(/a/, '❤️');
// &quot;Content Security Policy (CSP) is ❤️n added layer of security.&quot;
</code></pre>
<p>Met regexps heb je meer opties. Zo kun je ervoor kiezen om ‘global’ alle <code>a</code> characters te vervangen, in plaats van slechts de eerste. Dit doe je door de global <code>g</code> flag toe te voegen.</p>
<pre><code>txt.replace(/a/g, '❤️')
// &quot;Content Security Policy (CSP) is ❤️n ❤️dded l❤️yer of security.&quot;
</code></pre>
<p>Laten we nog een paar stappen verder gaan. Alle voorbeelden kun je in de console van je browser uitproberen.</p>
<p>Als je alle <code>a</code>, <code>b</code> en <code>c</code> characters wil vervangen door een smiley, dan kan dat met een character set. Als er op een plek een <code>a</code>, <code>b</code> of <code>c</code> character staat, heb je een match.</p>
<pre><code>txt.replace(/[abc]/g, '❤️')
// &quot;Content Se❤️urity Poli❤️y (CSP) is ❤️n ❤️dded l❤️yer of se❤️urity.&quot;
</code></pre>
<p>Regular expressions zijn standaard hoofdlettergevoelig, dus de eerste C van Content wordt niet gematcht. Er zijn twee manieren om dit wel te doen: het toevoegen van de hoofdlettervarianten aan de character set of het gebruik van de <code>ignore case</code> flag. De ignore case flag kun je gewoon naast de andere flags zetten, zoals in ons voorbeeld naast de global.</p>
<pre><code>txt.replace(/[abcABC]/g, '❤️')
// &quot;❤️ontent Se❤️urity Poli❤️y (CSP) is ❤️n ❤️dded l❤️yer of se❤️urity.&quot;
txt.replace(/[abc]/gi, '❤️')
// &quot;❤️ontent Se❤️urity Poli❤️y (CSP) is ❤️n ❤️dded l❤️yer of se❤️urity.&quot;
</code></pre>
<p>Als je wilt, kun je in dit geval ook een character set range definiëren: alle characters vanaf a tot en met c: <code>[a-c]</code>.</p>
<pre><code>txt.replace(/[a-c]/gi, '❤️')
// &quot;❤️ontent Se❤️urity Poli❤️y (CSP) is ❤️n ❤️dded l❤️yer of se❤️urity.&quot;
</code></pre>
<p>Het matchen op een character set range werkt ook voor getallen: een character set range van 1 tot en met 6 <code>[1-6]</code> in plaats van <code>[123456]</code>.</p>
<pre><code>'06-06-1991'.replace(/[1-6]/gi, '❤️')
// &quot;0❤️-0❤️-❤️99❤️&quot;
</code></pre>
<p>Als je groepen characters wil vervangen, kun je die tussen haakjes zetten en meerdere mogelijkheden per groepje scheiden met een vertical bar character. Bijvoorbeeld alle ‘onnodige’ woorden in deze zin.</p>
<pre><code>const txt2 = 'The referrer of the document in which the violation occurred.';
txt2.replace(/(of|the|in)/gi, '❤️')
// &quot;❤️ referrer ❤️ ❤️ document ❤️ which ❤️ violation occurred.&quot;
</code></pre>
<h2>Use case: valideer en autocorrect postcode</h2>
<p>Nu je de basis van regular expressions in JavaScript onder de knie hebt, kunnen we ook eens opnieuw naar het eerder beschreven postcodeprobleem kijken.</p>
<p>Met onderstaande code kun je controleren of de notatie van de postcode geldig is. Even ter herhaling: check voor vier cijfers, een spatie en twee hoofdletters. Het <code>^</code> character geeft aan dat de tekst ermee moet starten en <code>\d</code> is equivalent aan de character set range <code>[0-9]</code>. Het <code>$</code> character geeft aan dat de match die je maakt aan het einde van de string moet zitten.</p>
<pre><code>const gebruikersInput = '2384 AB';
/^\d\d\d\d [A-Z][A-Z]$/.test(gebruikersInput);
// true
</code></pre>
<p>Dit voorbeeld keurt de input alleen goed als dit het juiste format heeft: 2345 AB. Variaties daarop zoals 2345ab of 2345 Ab zijn incorrect, terwijl deze inhoudelijk wel kloppen.</p>
<p>Om dit op te vangen kun je regular expressions inzetten om de gebruikersinput te formatteren. Denk bijvoorbeeld aan het vergeten van een spatie of het gebruik van kleine letters. Daarvoor zou het onderstaande voorbeeld geschikt zijn. Hierin wordt gekeken of de input uit vier cijfers en twee letters bestaat en het <code>?</code> character voegt een spatie toe tussen beide groepen. De letters in de postcode worden omgezet naar hoofdletters.</p>
<pre><code>const gebruikersInput2 = '2345aB';
gebruikersInput2.replace(/^(\d\d\d\d) ?([a-z][a-z])$/i, '$1 $2').toUpperCase();
// &quot;2345 AB&quot;
</code></pre>
<p>Dit voorbeeld zou je ook op andere, meer efficiënte manieren kunnen oplossen, maar om het eenvoudig te houden heb ik hiervoor gekozen.</p>
<h2>Conclusie</h2>
<p>Met dit artikel heb je de basis van regular expressions: je kunt ze herkennen, lezen en in de basis toepassen. Eenvoudige regular expressions kunnen vele regels code schelen, maar soms kan het een onnodig ingewikkelde oplossing voor een probleem zijn of nieuwe bugs introduceren.</p>
<p>Daarom geldt voor regular expressions hetzelfde als voor elk ander superwapen: use it wisely. Want je kunt het jezelf - en je collega's - heel snel heel moeilijk maken.</p>
<h2>Meer weten?</h2>
<p>Regular expressions zijn een uitgebreid onderwerp. Het kan even duren voordat je je de basisconcepten helemaal eigen hebt gemaakt, daarom zou ik aanraden om eerst een aantal introducties te lezen. Die van MDN en Eloquent JavaScript zijn een uitstekend startpunt.</p>
<p><a href="https://eloquentjavascript.net/09_regexp.html">Eloquent JavaScript</a></p>
<p><a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions">MDN web docs over regular expressions</a></p>
<h2>Over Melle Wynia</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/melle.jpg" alt="Foto van Melle Wynia" class="floating-portrait" />
Melle Wynia werkt als freelance front-end developer/consultant. Voor zijn klanten sluit hij aan bij hun teams om kennis over te dragen, de kwaliteit te waarborgen, beveiliging op peil te brengen en nieuwe features te realiseren. Tot zijn tools behoren onder andere Node, Angular en Vue.js.
<p>Donatie: de Hersenstichting</p>
</content>
</entry>
<entry>
<title>Twaalf geschenken van Fronteers</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/twaalf-geschenken-van-fronteers"/>
<updated>2018-12-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/twaalf-geschenken-van-fronteers</id>
<content xml:lang="nl" type="html"><p>(Vrij naar “<a href="https://nl.wikipedia.org/wiki/The_Twelve_Days_of_Christmas">The Twelve Days of Christmas</a>”)</p>
<p>Op de eerste dag van Kerstmis, schonk Fronteers aan mij:</p>
<h2>Een geweldige conferentie</h2>
<p>Mijn eerste Fronteers conferentie was in 2015. Nou ja, ik kwam de conferentie niet bezoeken, ik kwam mijn vrouw ophalen die de conferentie bezocht. Toen ik binnenkwam legde ik aan Anneke Sinnema bij de Fronteers booth uit dat ik even ergens wilde gaan zitten totdat de boel afgelopen was. Of ik een t-shirt wilde? Maar ik was geen lid. Gaf niet. Wat is je maat? Alsjeblieft.</p>
<p>En zo heb je dan opeens een Fronteers conference t-shirt.</p>
<p>De sfeer op de conferentie zag er zó goed uit. En Chris Heilmann gaf de closing talk, en daar had ik wel eens een artikel van gelezen… en ging ik niet meer op front-end gebied doen bij een nieuwe baan binnenkort? Misschien maar eens lid worden…</p>
<h2>Op de tweede dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een gezellige Slack</h2>
<p>Het komt weinig voor dat ik geen tab open heb waarin de <a href="https://fronteers-slack.herokuapp.com/">Fronteers Slack</a> staat. Al is het maar om de gebruikelijke “Gooooeeeeedemorgen!” van honourary non-lid Robert van der Elst en de filosofische discussies in het #watercooler kanaal, tot handige tips en hulp in #js en #ui-ux. En mocht je extrovert zijn, is er de #meetandgreet. Maar vertel eerst wie je bent in #voorstelrondje!</p>
<h2>Op de derde dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een stem die telt</h2>
<p>Fronteers leden krijgen een stem tijdens de Algemene Leden Vergadering. Bij mijn eerste AVG werd er beslist over het door een extern bedrijf laten mee-organiseren van de jaarlijkse conferentie. Wat vooral indruk op me maakte is hoe fel en serieus de gesprekken waren. Dit was duidelijk geen club van enkel passieve leden.</p>
<h2>Op de vierde dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een leerzame workshop</h2>
<p>Meer dan één, eerlijk gezegd. Visualisations met Nadieh Bremer. Grid en Flexbox met Hidde de Vries. React Native met Roy Derks. Iedere keer leer ik weer nieuwe dingen die ik uiteindelijk weer kan gebruiken. En je leert van elkaar tijdens een workshop. Wie weet, misschien geef ik er zelf nog wel een keer één…</p>
<h2>Op de vijfde dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een interessante meetup</h2>
<p>Conferentie, workshops, en ook nog meetups? Tuurlijk! Er was er een bij Schiphol, met Ischa Gast en Tamara Forza: Schiphol toegankelijk op het web (en meer)! Een meetup bij E-sites, met Bram Smulders en Iain van der Wiel, sprekend over Schaalbaar en beheersbaar CSS! Toegankelijkheid met Karl Groves en Job van- oh wacht, dat is het volgende stukje.</p>
<h2>Op de zesde dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een kans om te spreken</h2>
<p>Tijdens mijn eerste conferentie (nou ja, ik was al naar de Spring Conference geweest) werd ik gevraagd of ik een keer wilde spreken over toegankelijkheid. Maar natuurlijk. Met Karl Groves, van Tenon.io? Helemaal mooi. We werkten al samen en zouden rond die tijd door Duitsland spreken bij verscheidene events, dus dit kwam helemaal goed uit. Uiteindelijk sprak ik over de typen van toegankelijkheidstooling, en waar ik verwachtte dat dingen naartoe zouden gaan in die sector.</p>
<h2>Op de zevende dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een sponsorship</h2>
<p>Ik co-organiseer de <a href="https://www.idea11y.nl/">Inclusive Design en Accessibility meetup</a> en heb meegewerkt aan role=drinks. Fronteers bood aan deze meetups te sponsoren. Wauw! Dit heeft er voor gezorgd dat we interessante buitenlandse sprekers konden invliegen en voor stickers konden zorgen. Ook het huren van ruimtes voor de meetups werd hierdoor beter mogelijk. Nogmaals bedankt!</p>
<h2>Op de achtste dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een lijst met vacatures</h2>
<p>Niet per se iets dat ik zelf gebruik, maar ik kijk wel graag naar de vacatures om te zien wat de trends in front-end banen zijn. Voor mijzelf is het ook wel een soort “stamp of approval” om een baan bij de Fronteers Vacaturebank te zien.</p>
<h2>Op de negende dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een manier om bij te dragen</h2>
<p>Vorig jaar werd ik gevraagd om in het comité van de conferentie dat jaar plaats te nemen. Zeker gezien ik nog maar relatief kort lid was, een hele eer. En voor de 10e conferentie, nota bene. Maar natuurlijk wilde ik graag deelnemen. Het samenstellen van de onderwerplijst, potentiële sprekers, het thema - er was veel te doen. En er is ook veel gedaan. En uiteindelijk was het een pracht van een conferentie.</p>
<h2>Op de tiende dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een stem binnen het W3C</h2>
<p>Als front-end vakvereniging is het een puik idee om binnen een standards body als het W3C een stem te hebben. Browserfabrikanten representeren een groot gedeelte van de stemmen, dus waarom geen ontwikkelaars? Tijdens de Algemene Leden Vergadering werd hier over gesproken en vóór gestemd. Fronteers, en wij als leden, hebben nu invloed binnen het W3C. Een goede ontwikkeling, als je het mij vraagt.</p>
<h2>Op de elfde dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een leuke korting</h2>
<p>Ik werk binnen digitale toegankelijkheid, en bezoek graag het Nationaal Congres Digitale Toegankelijkheid. En wat bleek - Fronteers leden kregen dit jaar korting. Een leuke verrassing. Ook konden leden recentelijk korting krijgen tot An Event Apart boeken. Ik heb de meeste al, anders had ik zeker deelgenomen. Ook kortingen op andere conferenties zoals Performance.now() kwam recent voorbij.</p>
<h2>Op de twaalfde dag van Kerstmis, schonk Fronteers aan mij:</h2>
<h2>Een geweldige community</h2>
<p>Fronteers bestaat door haar leden. Soms vragen leden zich af wat Fronteers <em>is</em>, behalve een vakvereniging die een conferentie organiseert (en workshops, en meetups). Persoonlijk vind ik het überhaupt al goed dat een vereniging als Fronteers bestaat, waar je lid van bent als je je werk als front-end ontwikkelaar serieus neemt, en van elkaar leert. Dat betekent niet dat we niet naar de toekomst kunnen kijken - het lidmaatschap van W3C is daar een goed voorbeeld van.</p>
<p>Ik ben benieuwd wat Fronteers haar leden in 2019 zal schenken, en aan welke dingen ik zelf zal bijdragen.</p>
<p>Fijne feestdagen!</p>
<h2>Over Job van Achterberg</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/job.jpg" alt="Foto van Job van Achterberg" class="floating-portrait" />
Job werkt als toegankelijkheidsspecialist (mooi Scrabblewoord) en ontwikkelaar bij Tenon (https://www.tenon.io). Hij gooit met slangen en water bij de vrijwillige brandweer.
<p>Donatie: Stichting Lezen en Schrijven</p>
</content>
</entry>
<entry>
<title>Pump up the JAM</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/pump-up-the-jam"/>
<updated>2018-12-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/pump-up-the-jam</id>
<content xml:lang="nl" type="html"><p>In de jaren dat ik werk als front-end developer, en ook in mijn tienerjaren als hobby, heb ik vele sites ontwikkeld in een heel scala aan frameworks en CMS’en. De bekendste CMS’en waar ik mee heb gewerkt zijn toch wel WordPress, Drupal en Sitecore. Maar hoe verschillend al deze traditionele CMS’en ook zijn, hoe je er in de basis een website mee ontwikkelt blijft vrijwel hetzelfde:</p>
<p>Zet een installatie op van het CMS, begin de paginatypes en content daarin te definiëren en maak templates waarmee je de content mee presenteert. Voor veel sites werkt deze werkwijze ook gewoon prima, gezien de hoeveelheid websites er sinds jaar en dag op deze manier ontwikkeld zijn.</p>
<h2>Jack of all trades…</h2>
<p>Gevolg van deze werkwijze is dat <em>alles en iedereen</em> met dit CMS moet (leren) werken om er een site mee te ontwikkelen.</p>
<p>Simpel gezegd moeten er onder andere:</p>
<ul>
<li>Content editors leren omgaan met de editor van het CMS;</li>
<li>Back-end developers het CMS uitbreiden om gewenste pagina’s en gegevens te kunnen beheren;</li>
<li>Front-end developers de ‘internals’ van het CMS leren omgaan met diens template-taal (of afwezigheid daarvan);</li>
<li>Hosting en ontwikkelomgevingen moeten opgezet en ingericht worden zodat het CMS kan draaien.</li>
</ul>
<p>Zoals je ziet draaien alle onderdelen van een website om dit ene punt heen: het traditionele CMS. Alles is <em><em>tightly coupled</em></em>.</p>
<p>Dat is gelijk de keerzijde van het tradtionele CMS, ze zijn vaak heel generalistisch. Zodra er iets ontwikkeld moet worden dat niet matcht met wat het systeem standaard biedt, dan kan het zijn dat dit niet zonder slag of stoot mogelijk is en je bent overgeleverd aan bijvoorbeeld een hoop plugins of een flinke tijdsinvestering om het zelf te ontwikkelen.</p>
<p>Dit type CMS kunnen we om deze redenen een <em><em>jack of all trades, master of none</em></em> noemen.</p>
<h2>Hit the road, Jack</h2>
<p>Vrij recentelijk zijn er ook andere soorten CMS’en op de markt gekomen, het zogenaamde headless of decoupled CMS. Dit type CMS is gericht op maar één ding: het gemakkelijk beheren en opslaan van content en data.</p>
<p>Het grote verschil met het traditionele CMS is dat een headless CMS geen pagina’s serveert aan bezoekers, maar de content die erin is opgeslagen alleen beschikbaar maakt via een API. Deze API kan dan door andere systemen aangesproken worden om toegang te krijgen tot deze content om er uiteindelijk pagina’s voor te serveren. Op deze manier zijn het beheer en opslag van content volledig ontkoppeld van de uiteindelijke presentatie ervan.</p>
<p>Dit geeft mogelijkheden tot het ontwikkelen van de front-end, aangezien je op deze manier niet beperkt bent tot alleen de features die het CMS (en diens plugins/modules) aanbiedt. Er is meer vrijheid om precies de onderdelen te ontwikkelen zoals ze nodig zijn voor het project waar je aan werkt. Aan de andere kant kan dit wel arbeidsintensiever zijn dan bouwen op een traditioneel CMS, omdat er over zaken nagedacht moet worden die met een traditioneel CMS al uit handen worden genomen, zoals routing, caching, meertaligheid, URL-opbouw, etc.</p>
<h2>🍓 Pump up the JAM 🍓</h2>
<p>Stel, er is voor het project waar je aan werkt gekozen voor een headless CMS, hoe ga je daar dan mee aan de slag? Hoe zorg je ervoor dat er een website is, een front-end, waar de content die in het CMS zit op gepresenteerd wordt?</p>
<p>Daar komt de <em>‘JAM stack’</em> om de hoek kijken. Maar wat is dan precies de JAM stack?</p>
<blockquote>
<p>A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.</p>
</blockquote>
<p>Websites gebouwd op basis van de JAM stack worden veelal ontwikkeld met een static site generator, zoals bv. Jekyll, Hugo of Gatsby. Nu denk je misschien: “Statische sites? Maar hoe ga ik dan om met dynamische content? En hoe zit het met formulieren? Of webshops?”.</p>
<p>Dat is waar een headless CMS en de JAM stack samenkomen, de ‘reusable APIs’. Static site generators kunnen namelijk de content uitlezen uit de API van het headless CMS! Deze content kan je dan gebruiken om statische pagina’s mee te genereren, zodat je nog steeds dynamische content hebt. Maar in tegenstelling tot traditionele CMS’en zijn beide systemen nu van elkaar gescheiden, oftewel <em><em>decoupled</em></em>.</p>
<p>Dit zorgt ervoor dat elk systeem (CMS, hosting, front-end, etc.) minder sterk afhankelijk is van elkaar en er andere, betere keuzes gemaakt kunnen worden.</p>
<h2>⚡️ De voordelen van statisch ⚡️</h2>
<p>Een statische site heeft ten opzichte van een dynamisch gegenereerde site (direct uit het CMS) een aantal <em>flinke</em> voordelen. Statische sites zijn:</p>
<p><em>Sneller</em> Sites worden opgebouwd tot simpele statische HTML files. Bestanden lezen en serveren is supersnel, er hoeft immers geen hele applicatie te draaien of op te starten om een request af te handelen.</p>
<p><em>Veiliger</em> Omdat er op de server geen back-end code of database aangesproken hoeft te worden om een verzoek af te handelen, is de site ook een stuk minder vatbaar voor aanvallen als XSS en SQL injection.</p>
<p><em>Schaalbaarder</em> Het opzetten van servers en hosting die statische files serveren is flink simpeler op te zetten en op te schalen bij grote hoeveelheden verkeer. In principe is elke vorm van hosting voldoende, omdat er alleen maar files verstuurd hoeven te worden. Er draait geen server-side CMS of framework wanneer er een verzoek binnenkomt op de server.</p>
<p><em>Bevrijdend</em> Er is meer vrijheid om de juiste tools en technieken te kiezen voor de front-end van de website of applicatie. De front-end is veel minder afhankelijk van achterliggende technieken zoals een CMS of framework met een eigen template engine.</p>
<h2>Ooh shiny! Can I touch?</h2>
<p>Klinkt goed toch? Dat dacht ik ook! 😉</p>
<p>Maar hoe gaan we er nu mee aan de slag? Daar zijn verschillende combinaties in mogelijk, zodat je de keuze hebt wat er het beste bij jouw project past. Ik ga niet verder op alle opties in, dat zou materiaal zijn voor nog een serie blogposts! Maar hieronder zal ik een aantal opties noemen:</p>
<p><em>CMS</em> <a href="https://www.contentful.com/">Contentful</a>, <a href="https://prismic.io/">Prismic</a>, <a href="https://graphcms.com/">GraphCMS</a>, <a href="https://www.netlifycms.org/">Netlify CMS</a></p>
<p><em>Static site generator</em> <a href="https://gohugo.io/">Hugo</a>, <a href="https://jekyllrb.com/">Jekyll</a>, <a href="https://www.gatsbyjs.org/">Gatsby</a></p>
<p><em>Formulieren</em> <a href="https://www.wufoo.com/">Wufoo</a>, <a href="https://www.typeform.com/">Typeform</a>, <a href="https://www.netlify.com/features/#forms">Netlify Forms</a></p>
<p><em>Authenticatie</em> <a href="https://auth0.com/">Auth0</a>, <a href="https://oauth.net/">OAuth</a>, <a href="https://www.netlify.com/features/#identity">Netlify Identity</a></p>
<p><em>Webshops</em> <a href="https://www.shopify.com/">Shopify</a>, <a href="http://stripe.com/">Stripe</a></p>
<p><em>Hosting</em> <a href="https://zeit.co/">Zeit</a>, <a href="https://cloud.google.com/">Google Cloud</a>, <a href="https://aws.amazon.com/">Amazon AWS</a>, <a href="https://www.netlify.com/features/">Netlify</a></p>
<p>Zoals je ziet is er ruime keuze in het hele ecosysteem om services en tools te kiezen die precies bij jouw project passen.</p>
<p>Zelf ben ik erg fan van de combinatie Netlify + Gatsby + Contentful (of Netlify CMS). Het zijn systemen die erg makkelijk zijn op te zetten, een goede community en een rijk ecosysteem hebben.</p>
<p>Hopelijk heb ik je hiermee geīnspireerd om er zelf een keer mee aan de slag te gaan. Kom je ergens niet uit? Kom even langs in de <a href="https://fronteers-slack.herokuapp.com/">Fronteers Slack</a> en stel gerust je vraag!</p>
<h2>Over Iain van der Wiel</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/iain.png" alt="Foto van iain" class="floating-portrait" />
Iain van der Wiel is een front-end developer bij Frontmen in Eindhoven. Met passie voor UX, standaarden en toegankelijkheid probeert hij elke dag het web ietsje beter te maken. Tevens is hij Fronteers Slack coryfee. 😄
Donatie
Mijn donatie gaat naar de Hersenstichting. Een kwart van de mensen in Nederland heeft in meer of mindere mate een hersenaandoening. De Hersenstichting steunt onderzoek, voorlichting en ondersteuning voor deze grote groep mensen.)
</content>
</entry>
<entry>
<title>Inclusive Design is Design</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/inclusive-design-is-design"/>
<updated>2018-12-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/inclusive-design-is-design</id>
<content xml:lang="nl" type="html"><p>Als men het over een toegankelijk en inclusive website heeft, gaat dit vaak over dat de website goed te gebruiken is voor mensen die schermlezers gebruiken en mensen die kleurenblind of slechtziend zijn. Het betekent vaak ook dat de website goed te gebruiken is met alleen een toetsenbord zonder een muis.</p>
<p>Vaak gaan talks, blogs en slack channel chats over: wanneer ARIA te gebruiken, hoe te gebruiken, goede HTML-structuur, CSS tips (denk aan: class ‘screenreaders’), kleurcontrasten en lettertypes die goed leesbaar zijn. Er is een boel te leren en te delen met elkaar over deze onderwerpen.</p>
<p>Dit is een grote vooruitgang ten opzichte van niet zo lang geleden toen we daar nog niet echt over nadachten.</p>
<p>Maar inclusive design is veel meer dan structuur, code en kleur alleen. Inclusive design gaat om het geheel van je website - het gaat om de algehele ervaring van de gebruiker als ze een website bezoeken.</p>
<h2>Het noninclusive internet</h2>
<p>In mijn eigen ervaring als iemand die altijd slechthorend was en langzamerhand helemaal doof is geworden, kom ik dagelijks situaties tegen die voor mij niet toegankelijk of inclusief zijn. Ik heb niks aan een goed gecodeerd formulier dat perfect werkt met een schermlezer en tabtoets als het formulier het verplicht maakt om een telefoonnummer in te vullen en tevens geen veld heeft voor een korte toelichting of een keuze hoe ik wil communiceren: e-mail, SMS of WhatsApp.</p>
<p>Als ik online bij de gemeente een afspraak maak om grofvuil op te halen, kan dat makkelijk. Maar dan krijg ik een no-reply bevestigingsmail en is het alleen mogelijk telefonisch contact op te nemen mocht er iets aan de hand zijn.</p>
<p>Jarenlang was online eten bestellen noninclusive. Je had een ruime keuze aan restaurants, betalen met contant, creditcard, iDeal, PayPal en zelf bitcoins. Maar er was geen veld voor een toelichting en alleen telefonisch contact mogelijk als er iets fout is gegaan met de bestelling.</p>
<p>Een veld voor toelichting bij een eten-bestelpagina (en alle contactpagina’s) is niet alleen inclusive voor iemand die wilt aangeven dat ze doof zijn en liever een SMS ontvangen in plaats van een belletje. Maar ook voor iedereen die een voedselallergie heeft en zeker wilt zijn dat ze niet ziek worden van het eten.</p>
<h2>Inclusive design is ook taal en beeld</h2>
<p>Veel online winkels denken niet echt na over wat hun doelgroep is met als gevolg dat hun website een groot deel van de doelgroep niet aanspreekt.</p>
<p>Neem eens een website die hoorapparaten verkoopt. Op de stockfoto’s staan alleen ouderen afgebeeld. Ik was 12 jaar toen ik mijn eerste paar hoorapparaten kreeg. Slechthorendheid is een beperking die in iedere leeftijdsgroep voorkomt. Als ik vandaag nog baat had met hoorapparaten dan zou ik zeker meer aandacht (en geld) besteden aan de website die mij aanspreekt. (Voorbeeld geen rekening houden met wie doelgroep echt is: <a href="https://www.specsavers.nl/horen">https://www.specsavers.nl/horen</a>)</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/specsavers.jpg" alt="Voorbeeld geen rekening houden met wie doelgroep echt is: Specsavers" /></p>
<p>Hoe vaak hebben we zuchtend een blog gelezen over een onderwerp dat nieuw voor ons was. We wilden er meer over weten, maar de schrijver gebruikte veel moeilijke en ingewikkelde zinnen. Er is zoveel te lezen en te doen online dat het teveel energie vergt om online een tekst te gaan lezen die te ingewikkeld is geschreven, terwijl dat niet hoeft. Stel iemand is bezig met een medisch behandeling die stress met zich brengt, hun geheugen aantast en dan komen ze een website tegen met lange zinnen en moeilijke woorden. Zo’n website is noninclusive voor hen.</p>
<h2>Design voor iedereen</h2>
<p>Als je websites bouwt, kijk verder dan je structuur, code en kleuren. Het kan 100% scoren in de Axe test, Lighthouse audit, Tenon.io en dergelijke, maar toch enorm frustrerend zijn voor veel bezoekers. De beste test tools zijn mensen: een diverse groep mensen. Inclusive design is design. Er bestaat geen mens die niet profiteert van inclusive design.</p>
<h2>Over Darice de Cuba</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/darice-de-cuba-2018.jpg" alt="Foto van Daroce" />
Darice is front-end developer en ervaringsdeskundige met een focus op inclusive design. Ze schrijft regelmatig over inclusive design voor doven en slechthorenden op [darice.org](https://darice.org). Als je meer wilt weten over inclusive design kan je contact nemen met @Darice via Twitter.
Donatie
De Nierstichting zet zich in om de levenskwaliteit van nierpatiënten te verbeteren, informatie geven aan mensen om nierschade te voorkomen en onderzoek voor betere behandelingen en genezing. [www.nierstichting.nl](https://www.nierstichting.nl))
</content>
</entry>
<entry>
<title>Code in style!</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/code-in-style"/>
<updated>2018-12-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/code-in-style</id>
<content xml:lang="nl" type="html"><p>In een perfecte wereld schrijven we allemaal code zonder bugs, onduidelijkheden of stijlfouten. Discussies over spaties, tabs, haakje-op-dezelfde-regel-of-juist-op-die-eronder bestaan alleen in de fantasieboeken die we aan onze kinderen voorlezen. In een perfecte wereld bestaat alleen perfecte code.</p>
<p>Maar ja, wij leven in de realiteit. In de realiteit schrijven we onze code niet allemaal op dezelfde manier en is onze code zeker niet foutloos!</p>
<p>Wanneer we in teams werken aan dezelfde codebase, is het hebben van verschillende schrijfstijlen bijna problematisch. In plaats van het werken aan nieuwe functionaliteit, of het reactoren van oude code, verspillen we tijd aan het begrijpen van onlogische code en constructies. Tijd die we veel beter kunnen besteden.</p>
<p>Om deze reden bestaan er coding styleguides. Deze richtlijnen geven aan in welke stijl de code moet worden geschreven in een team. De regels gaan vooral over de leesbaarheid en consistentie van code. Hierdoor hebben we minder tijd nodig om wat we lezen te ontleden in ons hoofd en kunnen we sneller begrijpen wat er bestaat.</p>
<p>In mijn werk was het maken van een coding styleguide tot voor kort iets dat “later altijd nog kan”. Ik werkte als enige front-ender in een team dat bestaat uit onder meer back-enders en een business analist. Recentelijk heeft één van mijn teamleden besloten zich meer op full-stack te richten. Dit bracht de coding styleguide vrijwel meteen van de dit-komt-nog-wel-stapel naar de dit-moeten-we-nu-gaan-hebben-stapel.</p>
<h2>Let’s go!</h2>
<p>Dit brengt mij naar het onderwerp van deze post: hoe zet je een coding styleguide op in je team? De manier die ik hier beschrijf, is niet de enige, maar gebruik het als leidraad als je zelf in deze situatie komt. We zijn er zelf nog steeds hard mee bezig, maar een aantal stappen zijn inmiddels al wel duidelijk. Let wel op: in deze post richt ik me op JavaScript.</p>
<p>Het maken van een coding styleguide bestaat grofweg uit de volgende stappen:</p>
<ul>
<li>Stel de lint regels op.</li>
<li>Configureer deze regels in een lint tool.</li>
<li>Configureer Babel (meestal op basis van je <code>browserslist</code>).</li>
</ul>
<p>We gaan door ieder punt heen lopen. Op het einde volgt er natuurlijk een codevoorbeeld. De code in dit artikel is terug te vinden op <a href="https://github.com/lodybo/code-in-style-examples">GitHub</a>.</p>
<h2>It’s not code, they’re more what you’d call “guidelines”</h2>
<p>De eerste stap is het precies afspreken volgens welke regels de code geschreven wordt. Het is aan te raden om dit zoveel mogelijk met het hele team af te tikken in een meeting (oké... het worden er waarschijnlijk meer dan één).</p>
<p>Een andere tactiek is het pakken van een bestaande styleguide en bij iedere regel bekijken of je het ermee eens bent. Zo niet, wat zou je eraan veranderen? Dit is handig als niet iedereen tijd heeft, of als er maar een paar mensen zijn die het schrijven van een styleguide als taak hebben. Wanneer je een voorstel hebt geschreven op basis van de bestaande styleguide, is het zaak om deze met het hele team door te spreken. Best practices kan je zo makkelijk introduceren, maar het blijft aan het team om te bepalen of ze die willen volgen.</p>
<p>Wij baseren onze styleguide op die van Airbnb. Het handige aan hun styleguide is hoe gedetailleerd hij is. Niet alle regels hebben we overgenomen (sommige zijn niet eens van toepassing bij onze applicaties), maar in het gesprek met het hele team kunnen we wel uitleggen wáárom we die keuzes hebben gemaakt.</p>
<p>Wat essentieel is: zorg dat de verantwoordelijkheid van de styleguide duidelijk is vastgelegd. Styleguides die achterlopen kunnen misschien wel schadelijker zijn voor code quality dan géén styleguide. Degene die deze verantwoordelijkheid draagt moet zich dan ook geroepen voelen dit bij te houden en <em>het team er op te wijzen als dit niet wordt nageleefd</em>.</p>
<h2>Lint All The Code!</h2>
<p>Dus, je hebt nu een document met alle regels voor je JavaScript code? Goed, dan gaan we nu instellen dat de linter de codebase ook daadwerkelijk inspecteert of deze regels worden nageleefd. Wij gebruiken ESLint om de code te inspecteren op schrijf- en stijlfouten. Uiteindelijk is het doel om op deze manier kleine foutjes te voorkomen (zoals het gebruiken van een ongedefinieerde variabele) en om consistente code te gebruiken. Er zijn meerdere manieren om ESLint in te zetten, zo zijn er mensen die iedere keer dat ze opslaan de linter draaien in de command line (guilty as charged...). Anderen stellen hun code editor of IDE in alles te linten en weer te geven tijdens het typen. En weer anderen gebruiken ESLint in combinatie met Prettier om hun code automatisch te formatten bij het opslaan. Maak hier gezamenlijk afspraken over zodat degene die de styleguide beheert, weet met welke voorkeuren hij rekening moet houden.</p>
<h2>Shareable configuration</h2>
<p>ESLint heeft een lijst <a href="https://eslint.org/docs/rules/">met alle regels</a> die ondersteund worden. Deze regels kunnen met nummers geconfigureerd worden om niet af te gaan (“0”), een waarschuwing te geven (“1”) of een fout op te gooien (“2”). Het configureren van ESLint gaat door middel van een configuration file (zoals <code>.eslintrc</code>). Ieder project dat via ESLint gelint wordt maakt dan gebruik van die configuratie.</p>
<p>Maar... dat moeten we dan met de hand bijhouden en kopiëren?</p>
<p>Gelukkig niet! ESLint ondersteunt het gebruik van <a href="https://eslint.org/docs/developer-guide/shareable-configs">“shareable configs”</a>. Het voordeel van shareable configs is dat deze te publishen zijn in een <code>npm</code> registry. Dit is perfect in het onderhouden van een styleguide, omdat de configuratie niet iedere keer gekopieerd wordt en daardoor snel achterloopt. Het enige wat je teamleden hoeven te doen, is de styleguide definiëren als een <code>devDependency</code>.</p>
<p>Later gaan we een voorbeeld hiervan bekijken.</p>
<h2>The Power of Babel</h2>
<p>Babel wordt gebruikt om transformaties op je code uit te voeren. Babel <em>transpilet</em> ES2015+ JavaScript naar bijv. ES5 JavaScript die oudere browsers kunnen begrijpen. Deze browsers komen meestal uit een <code>browserslist</code> en kan je in je project definiëren, maar slimme developers zorgen er natuurlijk voor dat de <code>browserslist</code> onderdeel wordt van de styleguide!</p>
<p>Babel kan je configureren om een aantal presets en/of plugins te gebruiken om je code te <em>transpilen</em>. Een Babel preset is een verzameling van andere presets en plugins, en als dat nou nét zo klinkt als de shareable configs van ESLint dan heb je het goed: je kan je eigen <a href="https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/user-handbook.md#making-your-own-preset">Babel presets maken</a>.</p>
<p>Babel presets hebben dezelfde voordelen als ESLints shareable configs: het zijn <code>npm</code> modules die je kan publishen in de <code>npm</code> registry (zowel de publieke als de lokale variant als je team die gebruikt). Projecten hoeven dan alleen je preset als een <code>devDependency</code> op te geven.</p>
<h2>Practicum</h2>
<p>Na al deze theorie is het tijd om dit in de praktijk te gaan gebruiken. Eerder in dit artikel vertelde ik al dat de sharable config van ESLint en de presets van Babel eigenlijk niks meer zijn dan kleine <code>npm</code> modules. In het practicum maken we een kleine shareable config van één regel voor ESLint, en een Babel preset met één plugin. We gebruiken deze vervolgens in ons testproject.</p>
<p>Om dit practicum te volgen heb je het volgende nodig:</p>
<ul>
<li>Node (ik gebruik versie 8.9.1)</li>
<li>Een code editor of IDE (ik gebruik - heel origineel - VS Code).</li>
</ul>
<h2>Setup</h2>
<p>Om te beginnen maken we drie mappen:</p>
<ul>
<li><code>eslint-config-custom-team-rules/</code>: in dit project definiëren we onze shareable config</li>
<li><code>babel-preset-custom-team-preset/</code>: in dit project schrijven we onze eigen Babel preset.</li>
<li><code>test-project/</code>: in dit project gebruiken we bovenstaande “styleguide” op de source code.</li>
</ul>
<p>Ja, de namen van de mappen zijn niet erg spannend. Deal with it.</p>
<h2>ESLint and the Shareable Configs</h2>
<p>We beginnen met het schrijven van onze shareable config in ESLint. Hierbij gaan we naar de <code>eslint-config-custom-team-rules</code> map en maken we een <code>npm</code> module aan:</p>
<pre><code>$ cd eslint-config-custom-team-rules
$ npm init -y
</code></pre>
<p>Voilà, we hebben een basis <code>npm</code> module. Tenzij je verder bouwt op bestaande ESLint regels of shareable configs hoef je verder niet veel te doen in <code>package.json</code>. Er is wel één ding wat handig is om weer te geven, en dat is de minimale versie van ESLint waar je op bouwt. Voeg daarom het volgende toe aan je <code>package.json</code>:</p>
<pre><code>&quot;peerDependencies&quot;: {
&quot;eslint&quot;: &quot;&gt;= 5&quot;
}
</code></pre>
<p>Hiermee geef je aan dat ESLint (versie 5 en hoger) nodig is als dependency in het project waar jouw shareable config wordt gebruikt.</p>
<p>Als volgende stap maken we een <code>index.js</code> bestand aan waar de regels zich in gaan bevinden:</p>
<pre><code>module.exports = {
rules: {
'no-eval': 2
},
env: {
'es6': true
}
}
</code></pre>
<p>Onze shareable config zegt eigenlijk niks anders dan dit:</p>
<ul>
<li>Onze code wordt uitgevoerd in een omgeving die ES6 code begrijpt.</li>
<li>Onze code mag geen <code>eval()</code> bevatten.</li>
</ul>
<p>Deze <code>npm</code> module is nu klaar om te publishen.</p>
<h2><code>eval()</code> is <code>evil()</code></h2>
<p>Het advies dat vaak gegeven wordt is om <code>eval()</code> <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#Do_not_ever_use_eval!">niet te gebruiken</a>. Deze post gaat daar niet verder op in, maar de reden dat ik deze regel toch toevoegde is erg simpel: ESLint heeft zelf een regelset met aanbevolen regels (<code>&quot;extends&quot;: eslint:recommended</code>). In deze regelset is het niet verboden om <code>eval()</code> te gebruiken. In een team is het niet ongebruikelijk om het gebruik van <code>eval()</code> toch af te laten vangen door de linter. Dit maakte het uitermate geschikt om als voorbeeld configuratie te gebruiken.</p>
<h2>Babel and presets</h2>
<p>De volgende stap is om een custom Babel preset te maken. Ook hierbij beginnen we met het maken van een <code>npm</code> module:</p>
<pre><code>$ cd babel-preset-custom-team-preset
$ npm init -y
</code></pre>
<p>Onze Babel preset heeft, in tegenstelling tot onze ESLint shareable config, een dependency op een bestaande Babel plugin: <code>@babel/plugin-transform-arrow-functions</code>. Deze installeren we eerst in onze preset:</p>
<pre><code>$ npm i -D @babel/plugin-transform-arrow-functions
</code></pre>
<p>Ook in deze module gaan we aangeven dat wij afhankelijk zijn van een <code>peerDependency</code>, namelijk <code>@babel/core</code> versie 7 of hoger:</p>
<pre><code>&quot;peerDependencies&quot;: {
&quot;@babel/core&quot;: &quot;&gt;= 7&quot;
}
</code></pre>
<p>Dan naar de configuratie! We maken eerst een <code>index.js</code> aan die de configuratie van onze plugin bevat:</p>
<pre><code>module.exports = () =&gt; ({
plugins: [
require('@babel/plugin-transform-arrow-functions')
]
});
</code></pre>
<p>Als plugin <code>require</code>’n we onze Babel plugin.</p>
<p>Let wel op: in het uitgebreide <a href="https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/user-handbook.md#toc-making-your-own-preset">Babel Handbook</a> van James Kyle wordt op het moment van schrijven een voorbeeld gegeven waarbij de configuratie bestaat uit het exporteren van een object. Babel geeft echter een fout als presets dit doen:</p>
<pre><code>Error: Plugin/Preset files are not allowed to export objects, only functions.
</code></pre>
<p>Let er dus op dat je Babel preset een functie exporteert dat zelf een config object <code>return</code>’ed.</p>
<p>Deze <code>npm</code> module is nu klaar om te publishen in een registry.</p>
<h2>Bringing it together</h2>
<p>Nu we onze shareable config en Babel preset hebben gedefinieerd is het tijd om ze in ons project samen te brengen. <code>cd</code> naar ons testproject en maak daar een nieuwe <code>npm</code> module:</p>
<pre><code>$ cd test-project/
$ npm init -y
</code></pre>
<p>In dit project geven we aan van welke <code>devDependencies</code> wij afhankelijk zijn:</p>
<pre><code>&quot;devDependencies&quot;: {
&quot;@babel/cli&quot;: &quot;^7.1.5&quot;,
&quot;@babel/core&quot;: &quot;^7.1.6&quot;,
&quot;eslint&quot;: &quot;^5.9.0&quot;,
&quot;eslint-config-custom-team-rules&quot;: &quot;^1.0.0&quot;,
&quot;babel-preset-custom-team-preset&quot;: &quot;^1.0.0&quot;
}
</code></pre>
<p>Vervolgens maken we onze project-specifieke ESLint configuratie in<code>.eslintrc</code>:</p>
<pre><code>{
&quot;extends&quot;: &quot;custom-team-rules&quot;
}
</code></pre>
<p>In deze configuratie geven we aan dat wij verder bouwen op onze shareable config. Je hebt vast gemerkt dat we overal hebben aangegeven dat de volledige naam van onze shareable config <code>eslint-config-custom-team-rules</code> is. Als je je aan deze conventie houdt weet ESLint dat je een shareable config inlaadt en hoef je de prefix <code>eslint-config-</code> niet te gebruiken.</p>
<p>De volgende stap is het maken van een Babel configuratie. Maak een <code>.babelrc</code> bestand aan en voeg daar de volgende regels aan toe:</p>
<pre><code>{
&quot;presets&quot;: [
&quot;custom-team-preset&quot;
]
}
</code></pre>
<p>Net zoals bij ESLint, geven wij Babel nu instructies om onze eigen preset in te laden. De prefix <code>babel-preset</code> hoeven wij niet op te geven omdat wij ons aan de conventies van Babel presets houden.</p>
<p>De volgende stap is het maken van onze source code. Maak een map aan genaamd <code>src/</code> en plaats daarin de volgende code in <code>index.js</code> bestand:</p>
<pre><code>const add = (num1, num2) =&gt; {
return eval('num1 + num2', {
num1: num1,
num2: num2
});
};
</code></pre>
<pre><code>const result = add(1, 2);
</code></pre>
<p>Onze source code bevat 2 punten die we in onze shareable config of preset behandelen:</p>
<ul>
<li>Het gebruik van <code>eval()</code>.</li>
<li>Het gebruik van een arrow functie (wat in oudere browsers niet ondersteunt wordt.</li>
</ul>
<p>Als laatste stap mogen we onze bouwstap configureren. Om het makkelijk te houden doen we dit via <code>npm</code> scripts, maar door het gebruik van standaard configuratie bestanden zou je dit ook makkelijk in Webpack doen.</p>
<p>Voeg de volgende <code>scripts</code> toe aan <code>package.json</code>:</p>
<pre><code>&quot;scripts&quot;: {
&quot;lint&quot;: &quot;eslint src/index.js&quot;,
&quot;build&quot;: &quot;babel -o src/script.min.js src/index.js&quot;
},
</code></pre>
<p>En nu komen we aan het spannendste deel van de avond: het uittesten van onze configuratie!</p>
<p>Zoals eerder gezegd, geeft ESLint geen fout of waarschuwing op het gebruik van <code>eval()</code> in onze code. Het draaien van <code>npx eslint --no-eslintrc src/index.js</code> geeft het volgende resultaat:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/code-in-style/eslint-no-config.png" alt="EsLint zonder config" /></p>
<p>Hier is te zien wat ESLint standaard teruggeeft: <code>eval()</code> is toegestaan, en aangezien ESLint normaal gesproken uitgaat van een ES5 omgeving is <code>const</code> niet toegestaan.</p>
<p>Wanneer we onze eigen shareable config gebruiken krijgen we een heel ander resultaat:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/code-in-style/eslint-shareable-config.png" alt="" /></p>
<p>Hierin kunnen we zien dat ESLint een fout geeft op het gebruik van <code>eval()</code>, maar het gebruik van <code>const</code> toestaat in onze code.</p>
<h2>Op naar Babel!</h2>
<p>We kunnen een zelfde test uitvoeren wanneer we Babel draaien. Wanneer we Babel zonder configuratie draaien moet de output er hetzelfde uitzien als onze source code, want Babel doet van zichzelf niks:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/code-in-style/babel-no-config.png" alt="Babel zonder config" /></p>
<p>Dit geeft ons het volgende resultaat:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/code-in-style/babel-no-config-result-3.png" alt="Resultaat van Babel zonder config" /></p>
<p>Maar als we onze <code>npm</code> script uitvoeren krijgen we een ander resultaat, omdat onze Babel preset dan wél uitgevoerd wordt:</p>
<pre><code>$ npm run build
</code></pre>
<p>Dit geeft:</p>
<p><img src="https://www.fronteers.nl/_img/adventskalender/code-in-style/babel-custom-preset-result-3.png" alt="Resultaat van Babel met custom preset" /></p>
<p>En dat is het. We hebben nu een eigen project gemaakt dat onze eigen ESLint en Babel configuratie (of preset) gebruikt op de source code. Wil je de voorbeeldcode in actie zien? Dan kan je het altijd terugvinden op <a href="https://github.com/lodybo/code-in-style-examples">Github</a>.</p>
<h2>Wrapping up</h2>
<p>Het proces zoals hierboven beschreven is natuurlijk niet de enige manier om een coding styleguide te maken met je team. En zoals voor veel dingen geldt in de wereld van development: your mileage may vary. Het belangrijkste is dat er een set richtlijnen vastligt waardoor het hele team zich kan richten op het schrijven van goede code!</p>
<h2>Over Lody Borgers</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/lody.png" alt="Foto van lody" class="floating-portrait" />
Lody Borgers is front-end developer bij TAF Verzekeringen in Eindhoven. Naast zijn kennis op het gebied van front-end is hij mede geroemd om zijn scherp inzicht, zijn enthousiasme voor JavaScript, en zijn ongelooflijke bescheidenheid. Hij kijkt altijd meer uit naar een meeting dan de mensen die deze meeting met hem hebben. Studeerde naast ICT ook Communicatie, maar zegt zelf nooit teveel. [@lodybo](https://www.twitter.com/lodybo)
<p>Donatie: Nederlandse Hartstichting</p>
</content>
</entry>
<entry>
<title>Schrijf eens iets anders dan code</title>
<link href="https://www.fronteers.nl/nl/blog/2018/12/schrijf-eens-iets-anders-dan-code"/>
<updated>2018-12-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/12/schrijf-eens-iets-anders-dan-code</id>
<content xml:lang="nl" type="html"><p>Langzaam maar zeker kruipen we alweer het nieuwe jaar in. Tijd om terug te blikken op het afgelopen jaar en goede voornemens te maken voor het nieuwe jaar. Normaal gesproken betekent dat voor mij dat ik constateer dat er weinig van mijn goede voornemens terecht is gekomen, en herpak ik mezelf met een &quot;maar volgend jaar wordt mijn jaar.&quot; Dit jaar doe ik het anders!</p>
<p>Één van mijn voornemens voor 2018 was namelijk om meer te gaan schrijven. Niet vanwege het schrijven op zich, maar wel wat er allemaal bij komt kijken: het op een rijtje zetten van je gedachtes en het overbrengen van een verhaal; dáár wil ik beter in worden. En de beste manier om ergens beter in te worden, is dat gewoon vaak te doen.</p>
<h2>Ik zei het toch...</h2>
<p>...of niet? Je herkent het vast wel: een project gaat de verkeerde kant op en je probeert je collega's of baas te overtuigen hoe het anders kan. Dit lukt vervolgens niet, het project mislukt inderdaad en achteraf was jouw idee misschien toch beter geweest. Niet dat er op dat moment geen enkele voldoening zit in een &quot;ik zei het toch&quot;, maar daar is natuurlijk niemand mee geholpen.</p>
<p>Het is niet zo dat ik denk dat ik altijd gelijk heb — 11 jaar samen met mijn vrouw heeft daar wel een einde aan gemaakt — maar als zo'n &quot;ik zei het toch&quot; zich voordeed, lag het ook aan mij. Ik ben meestal prima in staat om over problemen te redeneren en oplossingen te bedenken, maar vervolgens die redenering omzetten in een samenhangende reeks woorden is nou eenmaal een vak apart. Logisch dat er dan niet geluisterd wordt.</p>
<p>In zo'n geval had het minstens geholpen als ik mijn gedachten op papier had verzameld. Ik had er rustig overheen kunnen lezen en zien waar er gaten zaten of mogelijke vragen konden ontstaan. Niet alleen had ik dan zelf een beter beeld gehad van wat ik wilde vertellen, ik had ook steviger in mijn schoenen gestaan op het moment dat ik tegengas kreeg.</p>
<h2>Niet alleen voor communicatie</h2>
<p>Het opschrijven van dingen zit niet in mijn natuur: ik neem zelden aantekeningen en afspraken probeer ik van nature zoveel mogelijk in mijn hoofd te onthouden. Tot en met mijn studentenleven voldeed dat 'systeem' eigenlijk prima, en was er dus ook geen noodzaak om dit te veranderen. Met de leeftijd komen echter meer verantwoordelijkheden, met meer verantwoordelijkheden komen meer zaken om te onthouden en er zit een grens op hoeveel dingen je tegelijk in je hoofd kunt proppen. Mijn systeem houdt het niet meer.</p>
<p>Ik ben eerder begonnen met het noteren van alle 'simpele' zaken die ik moet onthouden — TODO's, boodschappen, en afspraken — en ik merk dat dat me rust in mijn hoofd geeft. Vanaf nu trek ik die lijn door naar dingen die ik geleerd heb en ideëen die ik heb. Congres bezocht? Schrijf een verslag! Heb je een vaag idee over hoe schrijven je leven zou kunnen verbeteren? Schrijf er een blogpost over!</p>
<p>Mocht je mijn woord niet willen geloven, lees dan eens <a href="https://www.helpscout.net/blog/benefits-of-writing/">The Psychological Benefits of Writing</a>; een blogpost over (je raad het al) de voordelen die je kunt ervaren als je regelmatig schrijft, met links naar onderzoeken.</p>
<h2>Cirkeltje rond</h2>
<p>Ik heb even getwijfeld of 'schrijven' een goed onderwerp was voor deze adventskalender. Je leest deze tekst immers op de website van een vakvereniging voor front-end developers en er is helemaal niets technisch aan. Maar aan de andere kant: een groot deel van ons werk <em>is</em> niet technisch. Software-ontwikkeling is communicatie en creativiteit, en er zijn meer dan genoeg middelen die ons daarbij kunnen helpen.</p>
<p>Dus ik blijf schrijven en dit is mijn startpunt. Net op tijd om nog mijn goede voornemen voor dit jaar in te kunnen lossen. Fijne feestdagen!</p>
<h2>Over Koen Kivits</h2>
<img src="https://www.fronteers.nl/_img/adventskalender/koen.jpeg" alt="Foto van koen" class="floating-portrait" />
Koen Kivits is een web developer in Eindhoven. Hij hobbyt op zijn [Github](https://github.com/koenkivits), tweet op zijn [Twitter](https://twitter.com/koenkivits) en blogt (sinds kort!) op zijn [website](https://koen.kivits.com/).
Donatie
Mijn donatie gaat naar [Stichting Vluchtelingenwerk](https://actie.vluchtelingenwerk.nl/geef-voor-vluchtelingen), omdat zij helpen om meer mensen dezelfde kansen te geven als ik heb gehad.
</content>
</entry>
<entry>
<title>Fronteers Adventskalender 2018</title>
<link href="https://www.fronteers.nl/nl/blog/2018/11/fronteers-adventskalender-2018"/>
<updated>2018-11-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/11/fronteers-adventskalender-2018</id>
<content xml:lang="nl" type="html"><p>Morgen begint de Fronteers Adventskalender. Vanaf 1 tot en met 24 december verschijnen er 24 blogs van 24 verschillende auteurs over uiteenlopende onderwerpen.</p>
<h2>Wat kun je verwachten?</h2>
<p>Natuurlijk zullen er blogs verschijnen over zaken waar we als front-enders dagelijks mee werken, zoals lettertypes of verschillende tools om je workflow te verbeteren. Maar er zullen ook een aantal verrassende blogs voorbij komen, denk aan het maken van sketchnotes of een persoonlijke noot over de balans werk-privé.</p>
<h2>Goede doelen</h2>
<p>Elke schrijver van een blog heeft de kans gekregen om een goed doel uit te kiezen. Fronteers zal aan elk van deze goede doelen 75 euro uit de verenigingskas doneren.</p>
<p>Alle artikelen uit deze adventsreeks vind je hieronder.</p>
<ul>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/schrijf-eens-iets-anders-dan-code">Schrijf eens iets anders dan code</a> door Koen Kivits</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/code-in-style">Code in style!</a> door Lody Borgers</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/inclusive-design-is-design">Inclusive Design is Design</a> door Darice de Cuba</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/pump-up-the-jam">Pump up the JAM</a> door Iain van der Wiel</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/twaalf-geschenken-van-fronteers">Twaalf geschenken van Fronteers</a> door Job van Achterberg</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/begin-met-regular-expressions">Begin met regular expressions</a> door Melle Wynia</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/in-evenwicht">In evenwicht</a> door Tom Hartwig</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/mooi-rood-is-niet-lelijk">Mooi rood is niet lelijk</a> door Monique Dubbelman</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/prettier-de-eigenzinnige-code-opmaker">Prettier, de eigenzinnige code-opmaker</a> door Edwin Martin</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/hoe-test-ik-de-toegankelijkheid-van-mijn-website">Hoe test ik de toegankelijkheid van mijn website?</a> door Erik Kroes</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/over-websites-en-lekkende-kranen">Over websites en lekkende kranen</a> door Josee Wouters</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/word-een-front-end-developer">Word een front-end developer</a> door Tim Severien</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/css-statistieken-om-je-codebase-te-verbeteren">CSS Statistieken om je codebase te verbeteren</a> door Bart Veneman</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/hoe-een-blinde-klant-zich-heel-even-miljonair-waande">Hoe een blinde klant zich even miljonair waande</a> door Roel van Gils</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/beginnen-met-webbluetooth">Beginnen met WebBluetooth</a> door Niels Leenheer</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/een-api-schrijven-als-een-front-end-developer">Een API schrijven als een front-end developer</a> door Thomas Machielsen</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/ik-doe-ook-front-end">&quot;Ik doe ook front-end&quot;</a> door Sander Langendoen</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/lettertypes-op-het-web-wat-kan-ik-ermee">Lettertypes op het web, wat kan ik ermee?</a> door Amy Davis</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/webdeveloper-worden-zonder-dure-opleiding">Webdeveloper worden zonder (dure) opleiding</a> door Tim Oerlemans</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/min-of-meer-toegankelijk">Min of meer toegankelijk</a> door Jules Ernst</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/css-en-javascripters">CSS en JavaScripters</a> door Peter-Paul Koch</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/wat-ik-leerde-van-twaalf-uur-tekenen-tijdens-fronteers">Wat ik leerde van twaalf uur tekenen bij Fronteers</a> door Anke Willems</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/fuck-the-system-be-nice">Fuck the system, be nice</a> door Paul van Buuren</li>
<li><a href="https://www.fronteers.nl/nl/blog/2018/12/met-fronteers-het-nieuwe-jaar-in">Met Fronteers het nieuwe jaar in</a> door Anneke Sinnema</li>
</ul>
</content>
</entry>
<entry>
<title>Schrijf mee aan de Fronteers Adventskalender!</title>
<link href="https://www.fronteers.nl/nl/blog/2018/10/schrijf-mee-aan-de-fronteers-adventkalender-2018"/>
<updated>2018-10-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/10/schrijf-mee-aan-de-fronteers-adventkalender-2018</id>
<content xml:lang="nl" type="html"><p>Heb jij altijd al een blog willen schrijven voor Fronteers? Dan is nu je kans! In december keert de Fronteers Adventskalender terug. 24 blogs van 24 schrijvers over alles dat met front-end (en Fronteers) te maken heeft. En de schrijvers mogen een donatie van 75 euro uit de verenigingskas doen aan een goed doel naar keuze.</p>
<p>Tot 1 november kan iedereen zich aanmelden om een blog te schrijven. Je mag schrijven over elk onderwerp dat front-end gerelateerd is. Misschien heb je wel goede voornemens voor 2019 of wil je graag een terugblik op het afgelopen jaar maken. Heb je een belangrijke ontdekking gedaan, wil je iets wat je zelf hebt geleerd met iedereen delen? Je kunt ook een pleidooi maken voor jouw favoriete framework of een lijstje van tools/artikelen die jij op dit moment belangrijk vind. Of misschien wil je graag schrijven over jouw ervaringen als front-end developer en waarom dit het mooiste werk van de wereld is. Denk ook eens aan het schrijven van een review, bijvoorbeeld over een Fronteers congres of workshop.</p>
<p>Wil je graag meeschrijven en namens Fronteers een donatie doen aan een goed doel van jouw keus? Meld je dan voor 1 november aan via onderstaand formulier, voor vragen kun je natuurlijk op het Fronteers Slack-kanaal terecht.</p>
<p>Deze schrijvers doen al mee:</p>
<ul>
<li>Anneke Sinnema</li>
<li>Josee Wouters</li>
<li>Paul van Buuren</li>
<li>Edwin Martin</li>
<li>Niels Leenheer</li>
<li>Tim Severien</li>
<li>Koen Kivits</li>
</ul>
</content>
</entry>
<entry>
<title>Fronteers als W3C-lid</title>
<link href="https://www.fronteers.nl/nl/blog/2018/09/fronteers-als-w3c-lid"/>
<updated>2018-09-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/09/fronteers-als-w3c-lid</id>
<content xml:lang="nl" type="html"><p>Het bestuur stelt voor om Fronteers W3C-lid te maken en Rachel Andrew als onze vertegenwoordiger aan te stellen om ons, en ook front-end ontwikkelaars in het algemeen, een stem te geven in de webstandaarden. Dit zal circa 30.000 euro per jaar kosten. Het bestuur zal op de ALV van 19 oktober hierover een motie indienen.</p>
<h2>Overweging</h2>
<p>Front-end ontwikkelaars hebben op dit moment geen stem in W3C. De individuele ontwikkelaars die niettemin deelnemen aan de discussie over nieuwe webstandaarden, doen dit in hun eigen, onbetaalde tijd, en gaan op eigen kosten naar W3C-meetings.</p>
<p>Aangezien vertegenwoordiging van front-end ontwikkelaars in W3C een goede zaak is die aansluit bij de doelstellingen van Fronteers, en aangezien we het geld in kas hebben, lijkt het het bestuur goed om het lidmaatschap aan te vragen en een ervaren webontwikkelaar te betalen om dit werk op zich te nemen. Hiervoor hebben wij contact gezocht met Rachel Andrew, die de afgelopen jaren ervaring heeft opgedaan als Invited Expert bij het W3C. Zij heeft toegestemd om als onze vertegenwoordiger op te treden - mits de leden akkoord gaan.</p>
<p>Het bestuur hoopt dat het lidmaatschap van het W3C een positieve uitwerking zal hebben op de naamsbekendheid van Fronteers, en mogelijkerwijs zou kunnen leiden tot een ledenaanwas. Met meer leden kan Fronteers zich op termijn beter inzetten voor de belangen van front-end ontwikkelaars.</p>
<p>Op <a href="https://alistapart.com/article/web-developer-representation-in-w3c">A List Apart</a> kan je verder lezen over de overwegingen die tot deze motie hebben geleid. Ook <a href="https://www.smashingmagazine.com/2018/09/representing-web-developers-w3c/">vertelt Rachel</a> op Smashing Magazine over haar werk bij W3C, en de kans die Fronteers haar zou kunnen bieden.</p>
<h2>Motie</h2>
<p>Het bestuur stelt het volgende voor.</p>
<ul>
<li>Fronteers wordt W3C-lid, in eerste instantie voor twee jaar.</li>
<li>Het bestuur zal een vertegenwoordiger aanwijzen.</li>
<li>Het bestuur reserveert hiervoor 30.000 euro per jaar voor 2019 en 2020.</li>
<li>Op de ALV van 2020 zal het W3C-lidmaatschap geëvalueerd worden.</li>
<li>Op lange termijn is het de bedoeling dat er een internationale samenwerking van organisaties van front-end ontwikkelaars ontstaat die uiteindelijk het lidmaatschap en de vertegenwoordigers samen zullen betalen. Het bestuur hoopt dat zo'n structuur in 2020 aanwezig is, en zal stappen zetten om dit voor elkaar te krijgen.</li>
</ul>
<h2>Financiële onderbouwing</h2>
<p>Lidmaatschap W3C: 1.950 euro per jaar.
(Noot: na twee jaar gaat <a href="https://www.w3.org/Consortium/fees?countryCode=NL&amp;quarter=07-01&amp;year=2018#results">dit bedrag</a> omhoog naar 7.800 euro. Dit is de voornaamste reden om in 2020 het lidmaatschap te evalueren.)</p>
<p>Vertegenwoordigersfee: 25.000 euro per jaar. Dit is inclusief eventuele reiskosten naar W3C-meetings. Rachel Andrew is akkoord gegaan met dit bedrag.</p>
<p>Overige kosten: circa 3.000 euro per jaar. Hierbij valt te denken aan het inhuren van een advocaat in het geval dat er een internationale organisatie geschapen zou moeten worden, of incidentele reis- en verblijfkosten die verband houden met het oprichten van andere organisaties die het W3C-lidmaatschap financieel zouden steunen. Het is mogelijk dat dit geld niet gebruikt wordt.</p>
<h2>Vertegenwoordiger</h2>
<p>Het bestuur is van zins Rachel Andrew als onze vertegenwoordiger aan te stellen. Rachel is hiermee akkoord gegaan, en zal zelf op de ALV verschijnen om het een en ander toe te lichten.</p>
<p>Noot: W3C-lidmaatschap geeft recht op vier vertegenwoordigers. Fronteers kan zich niet permitteren vier vertegenwoordigers te betalen, wat een andere reden is dat we hopen een internationale samenwerking op gang te brengen.</p>
</content>
</entry>
<entry>
<title>Alles over mechanische toetsenborden</title>
<link href="https://www.fronteers.nl/nl/blog/2018/09/alles-over-mechanische-toetsenborden"/>
<updated>2018-09-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/09/alles-over-mechanische-toetsenborden</id>
<content xml:lang="nl" type="html"><p>Je zult er vast wel eens van gehoord hebben of misschien heeft een van je collega’s er wel één. Een leek noemt het ‘ouderwets’, de kenner zweert erbij. Ik heb het natuurlijk over mechanische toetsenborden! Wie ben ik? Ik ben Josee en ik heb zelf een Ducky. Sinds ik dit toetsenbord heb, ben ik helemaal om. Ik zou niet meer zonder willen.</p>
<p><em>Maar hoe kies je nu een mechanisch toetsenbord? Over het algemeen is zo'n toetsenbord niet de goedkoopste en je wilt een miskoop vermijden. Maar zodra je even googlet, vliegen de switches je om de oren. Hopelijk zie je met deze guide straks door de toetsen het toetsenbord weer.</em></p>
<p><img src="https://www.fronteers.nl/_img/blog/ducky-shine.jpg" alt="Ducky Shine 3 is herkenbaar door de voor Ducky typerende spatiebalk" /></p>
<p class="note">
Ducky Shine 3 is herkenbaar door de voor Ducky typerende spatiebalk
</p>
<h2>Wat is een mechanisch toetsenbord eigenlijk?</h2>
<p>Als er wordt gesproken over een mechanisch toetsenbord - of op z'n Engels: een mechanical keyboard - dan wordt er een toetsenbord bedoeld dat een switch van bewegende delen onder de toets heeft zitten. Een gewoon toetsenbord daarentegen bestaat doorgaans uit een rubberen switch. Dit is veel goedkoper om te produceren. Naast zo'n rubber dome switch en mechanische switches, zijn er ook andere soorten switches, zo gebruikt Apple de eigen 'butterfly' switches voor zijn toetsenborden. Daar ga ik nu niet verder op in.</p>
<h2>Waarom is een mechanisch toetsenbord beter?</h2>
<p>Allereerst, een goedkoop toetsenbord is meestal niet slecht. Het zal zeker de klus geklaard krijgen. De superioriteit van een mechanisch toetsenbord zit 'm voornamelijk in de beleving. Bij een gemiddeld toetsenbord met rubber dome switches moet je meer kracht zetten, krijg je weinig feedback en kan het toetsenbord door het gebruik van rubber 'mushy' aanvoelen. Ook is de levensduur van zo'n toetsenbord een stuk korter.</p>
<p>Bij een mechanisch toetsenbord heb je deze nadelen niet. Afhankelijk van de switches die je kiest - die het grootste deel van de beleving bepalen - hoef je zoveel kracht te zetten als je wilt en krijg je de feedback die je wilt. Een veel genoemd nadeel van een mechanisch toetsenbord: het maakt veel lawaai. Nu is dit echter ook weer afhankelijk van de switches die je kiest, je manier van typen en je werkomgeving. Een rubber dome toetsenbord is ook niet bepaald stil. En persoonlijk hoor ik liever het gezellige geklik-klak van een mechanisch toetsenbord dan de rammel van een niet-mechanisch toetsenbord.</p>
<p><img src="https://www.fronteers.nl/_img/blog/magic-force.jpg" alt="Deze Magic Force is een budgetkeuze met een opvallend uiterlijk" /></p>
<p class="note">
Deze Magic Force is een budgetkeuze met een opvallend uiterlijk
</p>
<h2>Welke switches zijn er?</h2>
<p>Er zijn verschillende soorten switches. <a href="https://www.cherrymx.de/en">Cherry MX</a>, de meest bekende fabrikant van switches, heeft tien verschillende soorten om uit te kiezen. Deze switches kenmerken zich door een kleur, red, blue of brown bijvoorbeeld. De meeste fabrikanten houden deze kleurcodes aan voor dezelfde soort switches. Andere merken die deze kleuren aanhouden zijn bijvoorbeeld <a href="https://deskthority.net/wiki/Gateron_KS-3_series">Gateron</a>, <a href="http://www.kailh.com/en/Products/Ks/KTS/">Kailh</a>, en <a href="http://www.greetech.com/en/products.asp?enBigClassName=Mechanical%20Keyboard%20Switch">Greetech</a>.</p>
<p><a href="https://www.razer.com/eu-en/gaming-keyboards">Razer</a>, vooral bekend van gaming accessoires, maakt onder andere gebruik van eigen hybride switches; een kruising tussen mechanisch en dome. <a href="https://www.logitechg.com/nl-nl/articles/romer-g">Logitech</a> gebruikt zijn eigen Romer-G switches en andere bekende merken zijn <a href="http://www.topre.co.jp/en/products/elec/keyboards/">Topre</a> en <a href="https://matias.ca/">Matias</a>. Deze laatste twee zijn vooral bekend bij liefhebbers.</p>
<p><img src="https://www.fronteers.nl/_img/blog/brown-switches.jpg" alt="Bij deze Magic Force zie je dat er is gekozen voor brown switches" /></p>
<p class="note">
Bij deze Magic Force zie je dat er is gekozen voor brown switches
</p>
<p>Om het iets makkelijker te maken: er wordt een onderscheid gemaakt tussen tactile switches en linear switches. Een lineaire switch moet je tot de bodem indrukken voor deze een aanslag registreert. Een tactile switch heeft halverwege een voelbare bump, op dit punt wordt de aanslag geregistreerd en kun je verder typen. Je hoeft de toets dus niet verder in te drukken: het kan wel.
Een derde type, die je minder tegenkomt, is de clicky switch. Deze heeft naast een voelbare bump van een tactile switch, ook een hoorbare klik. Deze switches zouden nog wel eens tot geïrriteerde collega's kunnen leiden.</p>
<p>Verder onderscheid in switches wordt gemaakt door de hoeveelheid kracht die je moet gebruiken om een toets in te te drukken. Dit wordt actuation force genoemd. De actuation force wordt gemeten in centiNewtons (cN) maar 1 cN is gelijk aan 1 gram, deze maten worden door elkaar gebruikt. Een gemiddeld rubber dome keyboard heeft een actuation forse van tussen 55g en 60g. Bij mechanische switches heb je doorgaans keus van 45g tot en met 80g.
Een derde punt van onderscheid is het actuation point. Dit is het punt vanaf waar de switch de aanslag registreert. Gemiddeld ligt dit bij 2mm, bij een totale afstand tot bottom out van 4mm. Hoe lager het actuation point, hoe sneller de toets de aanslag registreert en jij naar de volgende toets kunt.</p>
<p>Met deze drie kenmerken, kun je besluiten welke switch voor jou de juiste is.</p>
<h2>Welke switch moet ik kiezen?</h2>
<p>Mijn daily driver is een Ducky Miya Pro Sakura met Cherry MX Brown switches. De Cherry MX Brown is een populaire tactile switch. De actuation force is met 45g licht en de actuation point gemiddeld, met 2mm. Ik viel voor dit toetsenbord voornamelijk dankzij het geweldige uiterlijk: de kleurtjes en de Japanse kersenbloesem op de spatiebalk en escape-toets. De Cherry MX Brown switches kende ik al en vond ik fijn typen. De keus was snel gemaakt.</p>
<p><img src="https://www.fronteers.nl/_img/blog/ducky-sakura.jpg" alt="Dit zuurstokroze toetsenbord is mijn Ducky Miya Pro Sakura." /></p>
<p class="note">
Dit zuurstokroze toetsenbord is mijn Ducky Miya Pro Sakura.
</p>
<p>Er zijn ook speciale switches. Zoals bijvoorbeeld de silent serie van Cherry. Deze zijn er in Red en Black en zijn stille(re) varianten van deze kleuren. Dan is er ook de Cherry MX Speed Silver, ideaal voor games. Deze linear switch een lage actuation force en actuation point. Mijn advies zou zijn om deze speciale switches achterwege te laten bij je keus, dat maakt het in mijn ogen onnodig ingewikkeld.</p>
<p>De beste manier om te besluiten welke switch je wilt, is simpelweg om het uit te proberen. Al is dat in de praktijk wat minder simpel. Niet veel computerwinkels zullen mechanische toetsenborden hebben die je kunt uitproberen. De meeste MediaMarkt winkels hebben wel enkele gaming toetsenborden van onder andere Logitech en Razer, maar ook Corsair en Kingston, die gebruik maken van Cherry MX switches.</p>
<p>Coolblue heeft in de fysieke winkels zogenoemde testers. Dit zijn kleine bordjes met een aantal kleuren switches naast elkaar, zodat je kunt uitproberen hoe het aanvoelt.</p>
<p>Deze switches zijn bij de meeste webwinkels ook te bestellen, bijvoorbeeld bij <a href="https://www.candykeys.com/category:switch-testers">Candykeys</a> en <a href="https://www.keyboardco.com/product/cherry-mx-switch-sampler.asp">Keyboardco</a></p>
<p><img src="https://www.fronteers.nl/_img/blog/wooting-one.jpg" alt="De Wooting One (een Nederlands merk) is een toetsenbord waarbij je zelf kunt wisselen tussen red en blue switches." /></p>
<p class="note">
De Wooting One (een Nederlands merk) is een toetsenbord waarbij je zelf kunt wisselen tussen red en blue switches.
</p>
<p>Of heb je collega's of mensen in je omgeving die een mechanisch toetsenbord hebben? Vraag of je het eens mag uitproberen.</p>
<p>Probeer van te voren te bedenken wat je fijn vindt: vind je het fijn als je de toets lichter of zwaarder moet indrukken voor de aanslag wordt geregistreerd? Wil je feedback voelen of wil je dat de toets pas registreert als je de bodem bereikt? Dit zal je keus al wat makkelijker maken.</p>
<p>Maar wees gewaarschuwd: mechanische toetsenborden zijn verslavend. Als je er eenmaal een hebt, wil je waarschijnlijk niet anders meer, net als ik en Melle Wynia, die zijn toetsenborden voor het schrijven van deze blog ter beschikking stelde.</p>
<p>Ben je lid van Fronteers? Dan krijg je nu korting bij Candykeys en Keyboardco op een mechanisch toetsenbord van jouw keuze. Je kunt contact opnemen met het bestuur voor een kortingscode.</p>
</content>
</entry>
<entry>
<title>Flinke korting op performance.now(), 8-9 november in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2018/09/korting-op-performance-now-2018"/>
<updated>2018-09-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/09/korting-op-performance-now-2018</id>
<content xml:lang="nl" type="html"><p>Op 8 en 9 november vindt in het Compagnietheater in hartje Amsterdam de nieuwe conferentie performance.now() plaats, die geheel gewijd is aan web performance.</p>
<p>Met een zeer mooie rij aan sprekers zoals Steve Souders, Tammy Everts en Scott Jehl en onderwerpen zoals JavaScript, fonts, afbeeldingen en PWA's, is dit een zeer interessante conferentie voor elke webontwikkelaar. En georganiseerd door een ervaren team (Mobilism, CSS Day) dat zorgt dat alles piekfijn is geregeld.</p>
<p>Alle informatie is te vinden op de website van <a href="https://perfnow.nl/">performance.now()</a>.</p>
<p>In plaats van 550 euro, betalen Fronteersleden 450 euro (ex. BTW), een mooie korting dus.</p>
<p>Als je als Fronteerslid gebruik wilt maken van deze korting, stuur dan even <a href="https://www.fronteers.nl/nl/vereniging/contact/">een berichtje naar het bestuur</a>. Je ontvangt dan alle informatie om een kaartje met korting te kopen.</p>
</content>
</entry>
<entry>
<title>Word nu lid van Fronteers en krijg korting op Fronteers Conference 2018 én 2019!</title>
<link href="https://www.fronteers.nl/nl/blog/2018/08/word-nu-lid-van-fronteers-en-krijg-korting-op-fronteers-conference-2018-n-2019"/>
<updated>2018-08-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/08/word-nu-lid-van-fronteers-en-krijg-korting-op-fronteers-conference-2018-n-2019</id>
<content xml:lang="nl" type="html"><p>Heb je nog geen kaartje voor <a href="https://www.fronteers.nl/congres/2018">Fronteers Conference</a>? En je bent ook nog geen lid van <a href="https://www.fronteers.nl/nl/vereniging">Fronteers</a>? Heb jij even geluk! Want als je nu lid wordt van Fronteers, krijg je niet alleen korting voor Fronteers Conference 2018, maar ook voor 2019!</p>
<p>Wat moet je daarvoor doen? <a href="https://www.fronteers.nl/inschrijven">Meld je aan als lid van Fronteers</a> voor 2018 en 2019, dat is alles. Je betaalt € 108,90 en krijgt dan niet alleen korting voor Fronteers Conference, maar ook voor <a href="https://www.fronteers.nl/vereniging/ledenkorting">workshops, vakgerelateerde boeken en online cursussen</a>.</p>
<p>Voor Fronteers Conference betaal je dan nog maar € 305,- in plaats van € 395,-. En de ledenkorting geldt ook alvast voor volgend jaar!</p>
<p>Fronteers Conference is een van de meest toonaangevende conferences in Europa op het gebied van front-end development. Met 16 sprekers verspreid over twee dagen - en twee workshops voorafgaand aan de conferentie - is het hét evenement voor webdevelopend Nederland. Dat wil je toch niet missen?</p>
<p>Dit jaar vindt Fronteers Conference plaats op 4 en 5 oktober 2018 in het DeLaMar Theater in Amsterdam. <a href="https://www.fronteers.nl/_downloads/2018/convince-your-employer-nl.pdf">Overtuig alvast je werkgever</a> terwijl jij <a href="https://www.fronteers.nl/inschrijven">je inschrijft voor Fronteers</a>.</p>
</content>
</entry>
<entry>
<title>Tijdelijke korting op online cursussen van Egghead.io</title>
<link href="https://www.fronteers.nl/nl/blog/2018/08/tijdelijke-korting-op-online-cursussen-van-egghead-io"/>
<updated>2018-08-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/08/tijdelijke-korting-op-online-cursussen-van-egghead-io</id>
<content xml:lang="nl" type="html"><p>Als je je graag nieuwe dingen leert door het kijken van online video-tutorials, dan heeft Fronteers nu voor leden een leuk ledenvoordeel binnengesleept! Als lid krijg je tot 11 oktober 2018 maar liefst 40% korting op een Pro abonnement bij Egghead.io. Je betaalt dan 150 dollar per jaar - 12,50 per maand!</p>
<p>Om van dit aanbod gebruik te maken stuur je een <a href="mailto:bestuur@fronteers.nl">e-mail naar het bestuur</a> en benoem je daarin dat je interesse hebt in de actie met Egghead.io. Nadat is vastgesteld dat je lid bent van de vereniging krijg je dan een kortingslink opgestuurd waarmee je een Pro-account kunt aanmaken (of je account kunt upgraden)!</p>
<p>Als <em>pro member</em> kun je online video-cursussen volgen over CSS, JavaScript, Angular, React, Vue, Node, Docker Git enzovoorts. Je krijgt toegang tot het complete assortiment en <a href="https://egghead.io/instructors">je leert van doorgewinterde developers</a> als Kent C. Dodds, Marcy Sutton, Max Stoiber, Sarah Drasner en meer. Bekijk hier <a href="https://egghead.io/browse/frameworks">het complete aanbod van Egghead cursussen</a>!</p>
</content>
</entry>
<entry>
<title>A Book Apart actie voor Fronteersleden</title>
<link href="https://www.fronteers.nl/nl/blog/2018/07/a-book-apart-korting-voor-fronteersleden"/>
<updated>2018-07-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/07/a-book-apart-korting-voor-fronteersleden</id>
<content xml:lang="nl" type="html"><p>Voor fans van de snel-bijgepraat-worden-over-een-onderwerp boeken van A Book Apart hebben we goed nieuws: Fronteersleden kunnen deze zomer flink besparen op het aanvullen van hun (thuis)bibliotheek! De boeken zijn gemiddeld 130 pagina's, lezen vlot weg en zijn fraai vormgegeven. Omdat ze zo'n sterke focus hebben over een bepaald onderwerp binnen webdevelopment heb je er ook een langere tijd plezier van!</p>
<h2>Hoe maak je gebruik van de korting?</h2>
<p>Bestel vòòr 10 september met een speciale (<a href="mailto:bestuur@fronteers.nl">discountcode op te vragen bij het bestuur</a>) en bespaar 12 dollar verzendkosten per boekje! De bestellingen worden voor Fronteers verzameld en als batch verzonden. De vereniging neemt de verzendkosten op zich en jij kunt je aankopen (met vertoning van je bon op mobiel of uitgeprint) afhalen op het Fronteers congres of de Algemene Ledenvergadering.</p>
<h2>Tips vanuit het Fronteersbestuur</h2>
<p>Wij zijn erg tevreden met &quot;Going Offline&quot; van Jeremy Keith (over service workers, waarmee je websites ook offline kunt blijven aanbieden aan je gebruikers) en &quot;Working the command line&quot; van Remy Sharp. Maar vergeet ook niet &quot;The New CSS Layout&quot; van Rachel Andrew, die je in 131 pagina's helemaal up to date brengt met CSS Grid Layout, of &quot;Accessibility for everyone&quot; van Laura Kalbag, waarin je een goede start maakt als je toegankelijker websites wilt maken. Hier vind je een <a href="https://abookapart.com/products">compleet overzicht van de A Book Apart boeken</a>.</p>
<p>Wil je graag meer tips? <a href="https://fronteers-slack.herokuapp.com/">Meld je aan voor de Fronteers Slack</a> en vraag de aanwezigen naar hun ervaringen!</p>
</content>
</entry>
<entry>
<title>Meld je nu aan voor de ALV 2018</title>
<link href="https://www.fronteers.nl/nl/blog/2018/07/meld-je-nu-aan-voor-de-alv-2018"/>
<updated>2018-07-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/07/meld-je-nu-aan-voor-de-alv-2018</id>
<content xml:lang="nl" type="html"><p>Op vrijdagavond 19 oktober houden we onze jaarlijkse algemene ledenvergadering (ALV). Alle leden zijn hiervoor van harte uitgenodigd. De vergadering vindt plaats in het La Vie Meeting Center in Utrecht, dezelfde locatie als in 2017.</p>
<p>Voor de mensen die van ver komen (of gewoon geen zin hebben om te koken) zullen er vanaf 18:30 broodjes klaar staan. De vergadering zelf zal stipt om 19:00 uur beginnen. We verwachten dat de totale vergadering twee uur zal duren, maar de ervaring leert dat het nog weleens wil uitlopen. De voorzitster doet haar best dat zoveel mogelijk te beperken. Als dit je eerste keer is, <a href="https://www.fronteers.nl/nl/vereniging/alv">vertellen we je graag meer over de ALV</a>.</p>
<p><em>De lokatie is inmiddels bekend: Net als vorig jaar zijn we te gast bij het La Vie Meeting Center, St Jacobsstraat 61, 3511 BP Utrecht. Dit is ongeveer vijf tot tien minuten lopen vanaf Utrecht Centraal Station.</em></p>
<p>Het staat leden tot het begin van de ALV vrij voorstellen voor de agenda in te dienen. De voorlopige agenda voor de ALV wordt op dinsdag 26 september bekendgemaakt. Wat in ieder geval zal worden behandeld zijn de jaarstukken van de vereniging over 2017, de financiën over 2018 en de nieuwe begroting voor 2019. Deze stukken zullen enkele dagen voor de ALV naar alle aangemelde aanwezigen worden opgestuurd. Mocht je niet aanwezig kunnen zijn, maar deze informatie wel willen zien: laat het ons weten!</p>
<h2>Voorlopige agenda</h2>
<ul>
<li>Opening</li>
<li>Jaarrekening 2017</li>
<li>Bevindingen kascommissie</li>
<li>Benoeming nieuwe kascommissie</li>
<li>Financiën 2018</li>
<li>Begroting 2019</li>
<li>Stemming over het mogelijk <a href="https://www.fronteers.nl/nl/blog/2018/09/fronteers-als-w3c-lid">W3C-lidmaatschap</a></li>
<li>Toelichting commissies</li>
<li>Evaluatie congres</li>
<li>Rondvraag</li>
<li>Sluiting</li>
</ul>
<h2>Aanmelden</h2>
<p>Ben je van plan te komen, dan vragen we je vriendelijk je hieronder hiervoor in te schrijven, zodat we enigszins een idee hebben van de verwachte opkomst.</p>
</content>
</entry>
<entry>
<title>Workshop React Native</title>
<link href="https://www.fronteers.nl/nl/blog/2018/05/workshop-react-native"/>
<updated>2018-05-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/05/workshop-react-native</id>
<content xml:lang="nl" type="html"><p>Heb je altijd al willen weten hoe je een native app voor mobiel ontwikkelt? Geef je dan op voor de <a href="https://www.fronteers.nl/workshops/workshop-react-native">Fronteers workshop React Native</a> op vrijdag 29 juni in Utrecht.</p>
<p>React Native is de ultieme manier om als front-end developer kennis te maken met mobile app ontwikkeling. Wat zijn de specifieke wensen die mobile apps aan ons stellen die wij als web developer niet kennen? Roy Derks, een ervaren mobile én React developer, neemt je in één dag mee in de wereld van React en Mobile Development.</p>
<p>In de workshop - waarvoor geen kennis van React noodzakelijk is - leer je eerst de basics van React en React Native, om deze later toe te passen bij het bouwen van een mobile app. Aan het eind van de dag heb je een goed beeld van het zelf bouwen van een mobiele app.</p>
</content>
</entry>
<entry>
<title>Kaartverkoop Fronteers Conference vandaag van start</title>
<link href="https://www.fronteers.nl/nl/blog/2018/05/kaartverkoop-fronteers-conference-vandaag-van-start"/>
<updated>2018-05-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/05/kaartverkoop-fronteers-conference-vandaag-van-start</id>
<content xml:lang="nl" type="html"><p>Vanmiddag om 12 uur starten we met de kaartverkoop voor Fronteers Conference! Via <a href="https://tickets.fronteers.nl/">onze ticketshop</a> kun je kaarten kopen. Is dit de eerste keer dat je een kaart voor het congres koopt? <a href="https://www.fronteers.nl/congres/2018/tickets">We leggen je graag uit hoe het werkt</a>.</p>
<p>Leden van Fronteers hebben afgelopen week een kortingscode in de mailbox gehad waarmee ze een flinke korting krijgen op de ticketprijs. Heb je geen kortingscode gehad, maar was je al wel lid ten tijde van de aankondiging van het congres en heb je ook je lidmaatschap op tijd betaald? Dan kun je het beste een mailtje sturen naar <a href="mailto:conference@fronteers.nl">conference@fronteers.nl</a> met <a href="mailto:penningmeester@fronteers.nl">penningmeester@fronteers.nl</a> in de cc.</p>
<p>Laat je door je werkgever meerdere kaarten kopen voor je team en zijn jij en je collega's lid van Fronteers? Zorg dan dat de persoon die de kaarten bestelt de kortingscodes heeft zodat ze gebruik kunnen maken van de korting!</p>
<h2>Fronteers Conference</h2>
<p>Fronteers Conference vindt dit jaar plaats op 4-5 oktober in het DeLaMar theater in Amsterdam. Het bestuur plaatste in april een <a href="https://www.fronteers.nl/blog/2018/04/fronteers-conference-in-2018-in-het-delamar-theater">nieuwsbericht over de nieuwe lokatie</a>. Meer informatie kun je vinden op de <a href="https://fronteers.nl/congres/2018">Fronteers Conference website</a>.</p>
</content>
</entry>
<entry>
<title>Fronteers Conference in 2018 in het DeLaMar Theater!</title>
<link href="https://www.fronteers.nl/nl/blog/2018/04/fronteers-conference-in-2018-in-het-delamar-theater"/>
<updated>2018-04-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/04/fronteers-conference-in-2018-in-het-delamar-theater</id>
<content xml:lang="nl" type="html"><p>Heugelijk nieuws! Ons jaarlijkse congres, <a href="https://fronteers.nl/congres/2018">Fronteers Conference</a> vindt dit jaar voor het eerst sinds 2010 niet plaats in Pathé Tuschinski, maar verhuist naar een grotere lokatie. Er is hard gezocht naar een plek in Amsterdam die centraal ligt, meer mensen kan huizen dan Tuschinski (waar we aan een maximum van 550 zaten) maar waar we in sfeer niets hoeven in te leveren. Uiteindelijk is de keuze gevallen op het DeLaMar Theater, waar we rond de 900 personen kunnen verwelkomen. De conferentie vindt plaats op 4 en 5 oktober 2018.</p>
<p class="note">
[This article is also available in English](/congres/2018/fronteers-conference-moving-to-the-delamar-theatre)
</p>
<h2>Waarom deze verhuizing van het 'grote' congres?</h2>
<ul>
<li>De kaartverkoop voor het congres gaat ieder jaar razendsnel en dit maakte het voor veel mensen lastig om een kaartje te kopen. Je moest precies online zijn als de online verkoop startte, want in enkele minuten waren we door een batch heen. Dit zat ons als bestuur dwars, omdat we het liefst iedereen die wil komen welkom willen heten.</li>
<li>Tegelijkertijd waren (en zijn) we nog steeds erg aan Tuschinski gehecht, en wisten we dat we met een grotere lokatie potentieel een stuk sfeer en gevoel van gezelligheid kwijt zouden raken. We denken nu dat we een mooi medium hebben gevonden in het DeLaMar theater!</li>
<li>Tuschinski wordt nu de lokatie voor een Spring Conference op 5 april 2019.</li>
</ul>
<h2>Toegankelijkheid van het DeLaMar Theater</h2>
<p>Tegelijkertijd betekent deze nieuwe lokatie ook dat meer mensen de kans kunnen krijgen om er bij te zijn. Fronteers hecht enorm aan diversiteit (in alle vormen) en helaas heeft Tuschinski een aantal letterlijke drempels. Als je in een rolstoel zit of met krukken loopt is dat niet ideaal. Het DeLaMar Theater is geheel rolstoeltoegankelijk en er zijn liften. Daarnaast beschikt het DeLaMar Theater over een ringleiding, en zijn daarvoor koptelefoons en inductielussen (voor gehoorapparaten) beschikbaar. Uiteraard mag je blindengeleidehond ook mee, en zorgen we weer voor een schrijftolk die er alle presentaties bij is. Als je dat fijn vindt, zorgen we voor een vrijwilliger die je tijdens het congres begeleidt.
<a href="https://delamar.nl/mindervaliden/">Bekijk alle faciliteiten van het DeLaMar Theater voor mindervaliden</a></p>
<p>We zijn heel erg blij dat we deze nieuwe lokatie kunnen aankondigen en hopen dat het komende congres weer één groot feest wordt!</p>
</content>
</entry>
<entry>
<title>CSS Day komt er weer aan: een gesprek met Peter-Paul Koch</title>
<link href="https://www.fronteers.nl/nl/blog/2018/04/css-day-komt-er-weer-aan-een-gesprek-met-peter-paul-koch"/>
<updated>2018-04-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/04/css-day-komt-er-weer-aan-een-gesprek-met-peter-paul-koch</id>
<content xml:lang="nl" type="html"><p>Op donderdag 14 en vrijdag 15 juni vindt in het Compagnietheater in Amsterdam het congres <a href="https://cssday.nl/2018">CSS Day</a> plaats. Net als de afgelopen twee jaar bestaat het congres nu uit twee dagen: een UX Special op de donderdag, en een 'gewone' CSS Day op de vrijdag.</p>
<p>Fronteers-leden krijgen <a href="mailto:bestuur@fronteers.nl">met een mailtje naar het bestuur</a> korting op beide: 25 euro op een eendagsticket, of 50 euro op een ticket voor beide dagen. Ook hebben we voor leden <a href="https://www.fronteers.nl/blog/2018/04/korting-op-de-workshops-van-css-day">korting voor de workshops geregeld</a>!</p>
<p><a href="https://webconferences.nl/">Web Conferences Amsterdam</a>, het team achter dit congres, is mede opgericht door Fronteers-oprichter en spreker Peter-Paul Koch. CSS Day gaat nu haar tweede lustrum in, hoog tijd om eens met PPK bij te praten!</p>
<p><em>FRONTEERS: PPK, samen met Krijn Hoetmer en Martijn van Duuren organiseer je dit jaar alweer voor de zesde keer CSS Day. Dit is maar liefst het zeventiende congres dat jullie als Web Conferences Amsterdam organiseren sinds 2011. Wat houdt jullie gemotiveerd om dit te doen?</em></p>
<p><em>PPK:</em> 17e? Wow. Ik had het niet zo door, maar ik heb net geteld en je hebt gelijk. Met performance.now() erbij komt het dus op 18.</p>
<p>Mijn oorspronkelijke idee was simpel:</p>
<ol>
<li>Ik had wat ervaring opgedaan met Fronteers 2008 en 2009, en Krijn daarnaast nog met Fronteers 2010</li>
<li>Het mobiele web stond destijds op uitbarsten, en er was nog geen dedicated congres voor.</li>
<li>Ik zag een mogelijkheid om wat extra inkomen te verdienen met zo'n congres.</li>
</ol>
<p>Dus heb ik Krijn en Stephen Hay uitgenodigd om mee te doen, en zijn we met Mobilism 2011 van start gegaan. Dat was het juiste congres op de juiste tijd, en het was een paar jaar zeer succesvol. Toen kwam er echter de klad in, voornamelijk doordat mobiel mainstream ging, en er geen speciale congressen meer voor nodig waren. Ook ging Stephen van freelance naar een vaste baan, en viel hij uit.</p>
<p>Intussen hadden we echter Adobe PhoneGap als klant gekregen voor hun jaarlijkse EU-congres, en was Krijn op het lumineuze idee van CSS Day gekomen. Dus gingen we vrolijk zonder Mobilism verder.</p>
<p>Qua motivatie: het is eigenlijk niet zo moeilijk. We hebben het grote voordeel dat we, net zoals het Fronteers-congres, een draaiboek hebben dat we voor elk congres kunnen gebruiken. Derhalve is een nieuwe editie van een bestaand congres een kwestie van een paar belletjes en mailtjes, en iedereen staat weer voor ons klaar. Wel moeten we zelf nog sprekers en marketing doen, en dat heeft wat meer voeten in de aarde, maar we kunnen ons hier helemaal op concentreren.</p>
<p>Een nieuw congres opzetten kost meer werk, omdat we een helder concept moeten hebben, alsmede een nieuwe huisstijl, een nieuwe site, een nieuw Twitter-account en wellicht een nieuwe tone-of-voice. Maar opnieuw, locatie, kaartverkoopsysteem, techniek, catering en wifi staan klaar, en daar hoeven we weinig aan te doen.</p>
<p>En het is erg leuk een eigen line-up te verzinnen, zoals iedereen die in de Fronteers congrescommissie heeft gezeten, weet. Tenslotte zijn al onze congressen commercieel, waardoor we sprekers kunnen betalen en er zelf ook wat aan overhouden.</p>
<p>En toen we een beetje uitgekeken begonnen te raken op het CSS Day-concept, besloten we het met een dag uit te breiden waarop een ander onderwerp besproken werd. Ook dat was een succes, en we denken dat we met de combinatie van UX en CSS nu de juiste vorm hebben gevonden.</p>
<p><em>FRONTEERS: Welk proces maken jullie door in de selectie van sprekers?</em></p>
<p><em>PPK:</em> Een paar lijstjes, veel warrige discussies, en dan nemen we ad-hoc beslissingen als het echt moet. Het helpt dat alleen Krijn en ik hierbij betrokken zijn, waarbij Krijn meestal voor de nieuwe, onbekende namen gaat en ik voor de gevestigde namen die voor wat kaartverkoop zorgen. We hebben beide nodig voor een succesvol congres, dus ons proces werkt eigenlijk prima. We zijn het niet altijd eens, maar, zoals een voormalige werkgever van me zei, &quot;zonder wrijving geen glans.&quot;</p>
<p>Alleen bij performance.now() hebben we het gros van de sprekerselectie overgedaan aan Steve Souders en Tim Kadlec, omdat zij de performance-wereld veel beter kennen dan wij. We hebben nog steeds een stem in het kapittel, maar Steve en Tim nemen het voortouw. Dat is best leuk voor de verandering.</p>
<p><em>FRONTEERS: Jullie hebben ook een nieuw congres op stapel staan- <a href="https://perfnow.nl/">performance.now()</a>, kun je daar iets meer over vertellen? Hoe lang zijn jullie daar 'stiekem' mee bezig geweest?</em></p>
<p><em>PPK:</em> Het zaadje werd geplant toen Tim Kadlec in mei 2017 een nacht in Amsterdam moest doorbrengen wegens complexe vliegtuigconnecties, en we gingen eten. Hij vertelde me toen dat O'Reilly flinke wijzigingen had doorgevoerd. De performance-track van Velocity, die ze jarenlang in Europa en Amerika hadden gedraaid en waarvan Steve Souders program chair was, bleek te worden overgeheveld naar Fluent, en de Europese editie van Fluent werd afgeschaft. Ergo: op de Europese markt kwam ruimte vrij voor een performance-congres. Dus als we daar iets mee wilden doen...</p>
<p>We hebben hier een tijdje over nagedacht, en besloten in september het te doen. We hebben toen Steve en Tim gevraagd om ons te helpen, en zei zeiden beide Ja. Toen kwam er een hoop geharrewar over de datum, omdat Tim en Steve ons wisten te vertellen dat er in mei een ander performance-congres in Londen zou plaatsvinden. Mei viel dus af, en juni wegens CSS Day, en oktober wegens Fronteers, en september omdat het Compagnietheater alleen beschikbaar was tijdens de IBC, als hotelprijzen in Amsterdam de pan uit rijzen, als je al iets kunt krijgen (zie ook Fronteers 2008). Dus: november.</p>
<p>Toen hebben we Steve en Tim verzocht lijsten met sprekers te maken, en hebben we er een aantal aangezocht. We hebben Hidde ingehuurd voor het grafisch ontwerp, en een paar dagen geleden besloten we dat het tijd was. Dus performance.now() is on, 8-9 november, Amsterdam.</p>
<p><em>FRONTEERS: Wat is iets waar jullie het meest trots op zijn in de afgelopen jaren dat jullie evenementen organiseren?</em></p>
<p><em>PPK:</em> Eigenlijk het feit dat het concept dat we in 2010 hebben opgesteld, nog steeds heel redelijk werkt. Te weten: zelf de line-up vaststellen aan de hand van de onderwerpen die we besproken willen hebben (en we hebben tot nu toe <a href="https://webconferences.nl/speakers">120 unieke sprekers</a> naar Amsterdam gehaald), opbouw van een vast klantenbestand, geen invloed van sponsoren (of recruiters - brrrr) op de inhoud, en een kaartprijs die onze doelgroep bereid is te betalen en die ons ook in staat stelt het desnoods zonder sponsors te redden.</p>
<p><em>FRONTEERS: Peter-Paul, je hebt aan de wieg gestaan van Fronteers, de vakvereniging, en je hebt je wel eens kritisch uitgelaten over de focus op Javascript-frameworks. Dekt volgens jou de titel 'frontend developer' de lading nog wel?</em></p>
<p><em>PPK:</em> Goeie vraag. Kort antwoord: ik weet het niet.</p>
<p>Lang antwoord: ik denk dat er een splitsing gaande is tussen heavy-duty JavaScripters aan de ene kant, en meer traditionele HTML/CSS/JavaScript web developers aan de andere kant. Wie van de twee groepen mag zich &quot;de echte front-ender&quot; noemen? Ik heb wel een mening, maar anderen zullen een andere mening hebben.</p>
<p>Wat mij betreft is het gevaarlijkste aspect van de huidige framework-rage het feit dat front-end developers het zicht verliezen op de platforms waarop hun software draait: de browsers. Zeker, vele problemen zijn verdwenen dankzij de noeste arbeid van de browsermakers zelf, en sommige andere worden efficiënt opgelost door de frameworks. Maar als je nu als moderne JavaScripter een van de weinige overgebleven browser bugs tegenkomt, heb je geen flauw idee wat je moet doen. Dat kan een probleem zijn.</p>
<p>Tevens lijkt het er op dat de heavy-duty JavaScripters CSS niet meer begrijpen, en wellicht zelfs niet meer <em>willen</em> begrijpen. Hier wil ik iets aan doen, al weet ik nog niet precies wat.</p>
<p>Een splitsing tussen JavaScripters enerzijds en HTML/CSS/JavaScripters anderzijds is eerder voorgekomen. Rond de dot.bust van 2001 gebeurde hetzelfde, toen de CSS-adepten zich afkeerden van de hysterische hoeveelheden JavaScript die toen in de mode waren (en in Netscape 4 moesten werken!) en die geschreven werden door back-enders die ineens ook front-end moesten doen. Uiteindelijk is die ronde glansrijk gewonnen door de HTML/CSS/JavaScripters, al kwam JavaScript een paar jaar in het verdomhoekje terecht - eigenlijk tot aan de release van jQuery in 2006.</p>
<p>Dat wil niet zeggen dat deze keer hetzelfde zal gebeuren. De context is heel anders, en de huidige frameworks zijn niet te vergelijken met de rommelige, Netscape 4-compatibile DHTML-libraries uit 2000. Bovendien zijn er veel minder browserproblemen dan toen - de moderne front-ender heeft het maar makkelijk.</p>
<p>Ik weet niet wat er verder gaat gebeuren, maar ik denk wel dat iedereen die zich met front-end bezighoudt, zichzelf de vraag moet stellen tot welke groep hij of zij eigenlijk behoort of wil behoren.</p>
</content>
</entry>
<entry>
<title>20% korting op de workshops van CSS Day!</title>
<link href="https://www.fronteers.nl/nl/blog/2018/04/korting-op-de-workshops-van-css-day"/>
<updated>2018-04-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/04/korting-op-de-workshops-van-css-day</id>
<content xml:lang="nl" type="html"><p>Half juni vindt CSS Day plaats. Op de dag voor de conferentie, woensdag 13 juni, organiseert CSS Day twee workshops. Leden van Fronteers krijgen 20% korting op de workshops (mits zij hun lidmaatschap voor 2018 betaald hebben). Zo betalen de leden niet 400, maar 320 euro (excl. BTW) voor een workshop!</p>
<p>Vitaly Friedman - bekend van <a href="https://www.smashingmagazine.com/">Smashing Magazine</a> - geeft zijn vernieuwde <em>Responsive Interface Design Bootcamp</em>. Ideaal voor als je je kennis van responsive web design up-to-date wilt brengen. Lees meer over de workshop van Vitaly <a href="https://cssday.nl/2018/workshops">op de website van CSS Day</a>.</p>
<p>Sara Soueidan - bij ons natuurlijk bekend als spreekster en host van het Fronteers congres - is al jaren een gerenommeerd expert op het gebied van CSS en SVG. Zij geeft dan ook de <em>CSS &amp; SVG Power Combo</em>. Vind de details op <a href="https://cssday.nl/2018/workshops">de workshoppagina van CSS Day</a>.</p>
<p>Als je als Fronteerslid gebruik wilt maken van deze 20%-korting stuur dan even <a href="https://www.fronteers.nl/nl/vereniging/contact/">een berichtje naar het bestuur</a>. Je ontvangt dan een speciale link waarmee je je workshopticket met korting kunt bestellen.</p>
<p>Overigens kun je als Fronteerslid ook korting krijgen voor CSS Day zelf. Fronteersleden krijgen via een speciale link €25 of €50 korting op de reguliere toegangsprijs (Je betaalt dus maar €275 voor 1 dag, of €500 euro voor 2 dagen!). Bij interesse mag je <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact opnemen met het bestuur</a>.</p>
</content>
</entry>
<entry>
<title>Vrijwilligers gezocht!</title>
<link href="https://www.fronteers.nl/nl/blog/2018/03/vrijwilligers-gezocht"/>
<updated>2018-03-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/03/vrijwilligers-gezocht</id>
<content xml:lang="nl" type="html"><p>Fronteers is op zoek naar nieuwe vrijwilligers om te helpen bij het behalen van de ambitieuze plannen die we hebben als vereniging. Help je mee?</p>
<p>Op dit moment hebben we helaas niet de capaciteit om (veel) activiteiten in Nederland te organiseren. We zijn dus hard op zoek naar vrijwilligers die het leuk vinden om onder de vlag van Fronteers dit initiatief te ontplooien. Wil je ons helpen? <a href="https://www.fronteers.nl/nl/vereniging/vrijwilligers/activiteiten">Bekijk hier de vacature voor de activiteitencommissie</a>!</p>
<p>Hiernaast heeft de commissie Workshops behoefte aan 1 tot 2 actieve vrijwilligers die kunnen helpen om workshops te organiseren. <a href="https://www.fronteers.nl/nl/vereniging/vrijwilligers/workshops">Bekijk hier de vacature voor de workshopscommissie</a>!</p>
</content>
</entry>
<entry>
<title>Bestuurs Update Maart 2018</title>
<link href="https://www.fronteers.nl/nl/blog/2018/03/bestuurs-update-maart-2018"/>
<updated>2018-03-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2018/03/bestuurs-update-maart-2018</id>
<content xml:lang="nl" type="html"><p>Het nieuwe jaar is goed begonnen en het bestuur is actief geweest op het gebied van ledenadministratie en vrijwilligers. Zo zijn alle commissie-pagina's op de website geüpdate, zijn een aantal commissies tijdelijk opgeheven, hernoemd of samengevoegd en hebben we er een aantal vrijwilligers bij! In deze bestuursupdate vertellen we je er meer over.</p>
<h2>We willen graag vaker afspreken</h2>
<p>Op 12 januari hebben we een gezellige nieuwjaarsbijeenkomst gehad in Utrecht. Tijdens deze borrel kwam het idee naar voren om weer vaker spontane vrijdagmiddagborrels te organiseren. We hopen dit binnenkort eens uit te proberen in Amsterdam!</p>
<h2>Vrijwilligerskorting</h2>
<p>In januari stelden we ons als bestuur als doel om de vrijwilligerslijsten op de website up-to-date te krijgen. Dit had onder andere te maken met de facturatieronde die er aan zat te komen. Vrijwilligers krijgen namelijk vanaf dit jaar korting op hun lidmaatschap op de vereniging en een voucher voor een Fronteers workshop. Leden die ná het moment van factureren vrijwilliger zijn geworden, krijgen geen korting op het lidmaatschap in 2018 maar wel een workshopvoucher (en korting vanaf de volgende facturatieronde).</p>
<h2>Nieuwe commissies &amp; nieuwe vrijwilligers</h2>
<p>Inmiddels hebben we contact gehad met alle vrijwilligers en zijn de <a href="https://www.fronteers.nl/nl/vereniging/commissies">commissiepagina's op de website</a> bijgewerkt. De commissie Online Community is samengevoegd met de commissie Marketing en de commissies Onderwijs en Webtoegankelijkheid zijn (tijdelijk) opgeheven.
Er zijn twee commissies bij gekomen: Toegankelijkheid (met Jules Ernst) en Vacatures (met Bernard Nijenhuis). Bernard viert dit jaar maar liefst zijn vijfjarig jubileum als de vrijwilliger die de vacaturebank voor ons onderhoudt! Bernards' inzet was tot nu toe vrij onzichtbaar, maar heeft nu een net plekje op de site. Heel erg bedankt Bernard.
Daarnaast zijn we heel blij dat er drie nieuwe vrijwilligers bij gekomen als leden van de Congrescommissie: Niels Leenheer, Nienke Dekker en Tamara Forza!
Dan nog een speciale shout-out naar de commissie België: uitgegroeid tot een bruisende commissie die met regelmaat meetups organiseert. Hier worden ook video-opnames van gemaakt; hou onze socials in de gaten, er zullen binnenkort filmpjes worden gelinkt.
<a href="https://www.fronteers.nl/nl/vereniging/vrijwilligers">Voor de commissies Activiteiten en Workshops zoeken we nieuwe vrijwilligers</a>.</p>
<h2>Kortingscodes</h2>
<p>Ook steunen we met Fronteers een aantal toffe events die dit jaar zijn aangekondigd; <a href="https://cssday.nl/">CSS Day</a> (14 en 15 juni) en <a href="https://www.frontendunited.org/">Frontend United</a> (31 mei t/m 2 juni). Voor beide events verloten we binnenkort een kaartje! We hebben ook een kortingscode beschikbaar die Fronteersleden kunnen gebruiken om met korting naar CSS Day te gaan. Fronteers-leden krijgen hiermee €25 (1 dag) of €50 (2 dagen) korting op de reguliere toegangsprijs (€300/€550). <a href="mailto:bestuur@fronteers.nl">Stuur een mailtje naar het bestuur</a> als je hiervan gebruik wilt maken!</p>
</content>
</entry>
<entry>
<title>Bestuurs Update december 2017</title>
<link href="https://www.fronteers.nl/nl/blog/2017/12/bestuurs-update-december-2017"/>
<updated>2017-12-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/12/bestuurs-update-december-2017</id>
<content xml:lang="nl" type="html"><p>Net zoals in het afgelopen jaar kiest het nieuwe bestuur er voor om het leeuwendeel van overleg en vergaderen te doen via een privé Slack-kanaal. Het voordeel voor het bestuur (dat vrij ver uit elkaar woont) zit hem daarin dat overleg snel plaats kan vinden en tussen de bedrijven door.</p>
<p>Het nadeel zoals afgelopen jaar geleerd heeft is dat dit het lastiger maakt om door middel van notulen verslag te doen. Om dit probleem op te lossen heeft het Slack-team (Charis en Peter) voor ons een nieuw privé-kanaal gemaakt waarin we besluiten die we maken snel kunnen 'noteren', om hier de leden vervolgens maandelijks verslag van te doen!</p>
<h2>Afgelopen maand</h2>
<p>In November zijn alle vrijwilligers benaderd voor een bedankje vanuit de vereniging. We hebben dit in gang gezet maar het is een flinke logistieke operatie gebleken. Nog even geduld lieve mensen!</p>
<p>Op 13 december hebben Edwin, Anneke en Sander bij elkaar gezeten in Utrecht voor een team-kick-off. We hebben het gehad over <a href="https://www.fronteers.nl/nl/vereniging/doel">het doel</a> van Fronteers, hoe Sander de financiële en leden-administratie doet, en een stukje rolverdeling. We hebben ook besproken hoe we Fronteers beter op de kaart kunnen zetten.</p>
<p>Op 20 december hebben we met een etentje de congrescommissie van 2017 bedankt voor hun inzet het afgelopen jaar. Thijs Reijgersberg gaat door, en Jaco Koster is ondertussen toegetreden tot de commissie. Jaco zal in 2018 de commissie voorzitten. Het tweetal vormt in de loop van januari een nieuwe commissie!</p>
<h2>Vrijwilligers</h2>
<p>Begin januari van het nieuwe jaar benaderen Edwin en Anneke alle vrijwilligers over hoe zij hun inzet zien in 2018. We gaan spoedig daarna actief op zoek naar nieuwe vrijwilligers voor de commissies die daar behoefte aan hebben. Anneke heeft met een aantal mensen contact gehad over het vormen van een diversiteits-denktank en pakt dit in januari op. Ook is in gesprek binnen het bestuur voorbij gekomen dat we graag meer willen doen om het bereik van Fronteers te vergroten. Hiervoor wil Anneke graag in 2018 in gesprek gaan met Charis, Koen en Michael, die zich daar nu al voornamelijk mee bezig houden op het gebied van social media en de nieuwsbrief!</p>
<p>We hebben met elkaar in overleg bevestigd dat we als bestuur van vrijwilligers verwachten dat ze ook lid zijn van Fronteers; daar staat tegenover dat tijdens de ALV is voorgesteld om bijvoorbeeld vrijwilligers korting te geven op hun lidmaatschap en elke vrijwilliger jaarlijks gratis aan een workshop mag deelnemen. Het precieze voorstel en wie hiervoor in aanmerking komt, wordt begin januari kortgesloten met de commissievoorzitters. Zien we volgens jou iets of iemand over het hoofd? Dan hopen we dat je ons helpt door middel van een <a href="https://www.fronteers.nl/nl/blog/2017/12/bestuur@fronteers.nl">mailtje</a>! <em>Wil je zelf actief worden binnen Fronteers? Laat het ons dan weten.</em></p>
<h2>Nieuwjaarsborrel</h2>
<p>De nieuwjaarsborrel houden we op 12 januari bij stadskasteel Oudaen in Utrecht vanaf 18:00! Zien we je daar? <a href="https://www.fronteers.nl/nl/activiteiten/2018/nieuwjaarsborrel">Meld je aan via de Fronteers website.</a></p>
<h2>Opgezegd</h2>
<ul>
<li>We hebben besloten om te bezuinigen op twee doorlopende abonnementen die volgens ons niet langer nodig zijn. IRCCloud werd gebruikt toen de community nog gebruik maakte van IRC. Ondertussen gebruiken we al een tijdje Slack.</li>
<li>Daarnaast hadden we 2 private repo's op GitHub. deze zijn in 2015 gebruikt voor het opslaan van bestuursnotulen en artikelen. We hebben het er kort over gehad of deze dienst kunnen doen voor de nieuwe Fronteers-website, maar daarvoor hoeven we geen (betaalde) private repo te hebben. De data is nu verhuisd naar een gratis private repository op GitLab!</li>
</ul>
</content>
</entry>
<entry>
<title>Nieuwjaarsborrel 2018</title>
<link href="https://www.fronteers.nl/nl/blog/2017/12/nieuwjaarsborrel-2018"/>
<updated>2017-12-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/12/nieuwjaarsborrel-2018</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 12 januari 2018 verwelkomt Fronteers leden en niet-leden bij stadskasteel Oudaen in Utrecht voor de jaarlijkse nieuwjaarsborrel.</p>
<p>Leden en niet-leden zijn van harte welkom om met ons het glas te komen heffen op het nieuwe jaar. Ben je er bij? <a href="https://www.fronteers.nl/nl/activiteiten/2018/nieuwjaarsborrel">Meld je aan voor de nieuwjaarsborrel!</a></p>
</content>
</entry>
<entry>
<title>Nieuwe rolverdeling verenigingsbestuur</title>
<link href="https://www.fronteers.nl/nl/blog/2017/12/nieuwe-rolverdeling-verenigingsbestuur"/>
<updated>2017-12-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/12/nieuwe-rolverdeling-verenigingsbestuur</id>
<content xml:lang="nl" type="html"><p>Vorige week donderdagavond was de ALV, waar wij afscheid namen van Jaco Koster als voorzitter en secretaris, en van Roy Tomeij als algemeen bestuurslid. Anneke Sinnema en Edwin Martin zijn dezelfde avond nog gekozen als nieuwe bestuursleden naast Sander Vink, die nu zijn tweede jaar in gaat als penningmeester.</p>
<p>Vandaag hebben we overleg gehad over de nieuwe rolverdeling die we onszelf hebben toebedacht. Na enig beraad is daar het volgende uit gekomen:</p>
<p><em>Sander Vink</em> blijft aan als penningmeester. Sander heeft zich het afgelopen jaar ingezet om de financiële administratie verder op orde te brengen en gaat hier het komende jaar mee door. Hij neemt ook de ledenadministratie op zich.</p>
<p><em>Edwin Martin</em> is een oudgediende van Fronteers en is al sinds de oprichtingsbijeenkomst bij de vereniging betrokken. Na drie jaar in de congrescommissie en drie jaar de kascommissie gaat Edwin zich nu inzetten voor Fronteers als secretaris.</p>
<p><em>Anneke Sinnema</em> heeft drie jaar onderdeel gevormd van de congrescommissie en stort zich nu vol enthousiasme op een rol als voorzitter. Het is mij een grote eer!</p>
<p>Volgende week gaan Anneke en Edwin met Sander om tafel en op &quot;Fronteerscursus&quot; voor een stukje overdracht. We hebben er zin in!</p>
</content>
</entry>
<entry>
<title>Kandidaat bestuur Fronteers: Anneke Sinnema</title>
<link href="https://www.fronteers.nl/nl/blog/2017/11/kandidaat-bestuur-fronteers-anneke-sinnema"/>
<updated>2017-11-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/11/kandidaat-bestuur-fronteers-anneke-sinnema</id>
<content xml:lang="nl" type="html"><p>Aanstaande donderdag vindt de jaarlijkse algemene ledenvergadering (ALV) van Fronteers plaats. Een van de onderdelen tijdens de ALV is de bestuursverkiezing. Kandidaat bestuurslid Anneke Sinnema stelt zich voor!</p>
<p>Na vijf jaar als lid van Fronteers en drie jaar als lid van de congrescommissie heb ik besloten om me kandidaat te stellen voor een positie in het bestuur van onze vakvereniging!</p>
<p>Toen ik vijf jaar geleden op mijn allereerste Fronteers-bijeenkomst kwam werkte ik als &quot;content manager&quot; voor een online-marketing bureau. Ná die bijeenkomst liet ik als de wiedeweerga mijn functietitel aanpassen want ik wist: ik ben een programmeur! Dat gevoel gun ik andere mensen ook. Alleen daarom al vind ik het belangrijk dat Fronteers als vakvereniging blijft bestaan.</p>
<h2>Wat kun je van mij verwachten?</h2>
<p>Diversiteit is een belangrijk thema voor mij. Daarom lanceerde ik nog niet zo lang geleden een enquete om meer te weten te komen over de mensen die deel uitmaken van ons vakgebied. Ik wil graag dat iedereen zich thuis voelt in de Nederlandse webindustrie en bij Fronteers en hoop dat de uitkomst van dit onderzoek daar aan bij kan dragen.
Ik wil daarnaast graag onderzoeken wat we nog meer kunnen doen door middel van de oprichting van een speciale denktank-commissie Diversiteit, maar hier ga ik hulp bij nodig hebben! Daarom hoop ik ook meer mensen te bewegen tot het doen van vrijwilligerswerk voor de vereniging.</p>
<h2>Wat zijn verder de bijdrages die ik graag aan Fronteers wil leveren?</h2>
<ul>
<li>Het transparanter maken van het bestuur en het koesteren van onze bestaande vrijwilligers &lt;3</li>
<li>Het organiseren van events blijven ondersteunen, liefst ook buiten de randstad. Wellicht het vinden van partners in de regio voor kwalitatief sterke meetups (zonder recruitmentverhalen) voor iederéén</li>
<li>Toegankelijkheid is geen feature maar een kwaliteitskenmerk. Daarom vind ik dat Fronteers als vakvereniging zich sterk moet blijven maken voor het verhogen van het kennisniveau rond dit onderwerp.</li>
</ul>
<p>Wil je (als lid van Fronteers) op me stemmen, dan kan dat op de ALV op 30 november of door iemand anders die aanwezig is te machtigen.
Wil je me op een andere manier willen ondersteunen dan is alle input welkom via een DM op de Slack!</p>
</content>
</entry>
<entry>
<title>Meld je nu aan voor de ALV 2017</title>
<link href="https://www.fronteers.nl/nl/blog/2017/11/aanmelden-alv-2017"/>
<updated>2017-11-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/11/aanmelden-alv-2017</id>
<content xml:lang="nl" type="html"><p>Donderdag 30 november houden we onze jaarlijkse algemene ledenvergadering (ALV). Alle leden zijn hiervoor van harte uitgenodigd. De locatie van de ALV is La Vie Meeting Center, Sint Jacobsstraat 61, ongeveer vijf minuten lopen vanaf Utrecht CS (let op: dit is niet de locatie waar de ALV de afgelopen jaren plaatsvond).</p>
<p>Voor de mensen die van ver komen (of gewoon geen zin hebben om te koken) zullen er vanaf 18:30 broodjes klaar staan. De vergadering zelf zal stipt om 19:00 uur beginnen. We verwachten dat de totale vergadering twee uur zal duren, maar de ervaring leert dat het nog weleens wil uitlopen. De voorzitter doet zijn best dat zoveel mogelijk te beperken. En mocht je geen flauw idee hebben waar de ALV precies voor dient, dan <a href="https://www.fronteers.nl/nl/vereniging/alv">vertellen we je graag meer over de ALV</a>.</p>
<p>Het staat leden nog steeds vrij voorstellen voor de agenda in te dienen. Vooralsnog is de agenda van de avond de volgende:</p>
<ol>
<li>Welkom en opening door de voorzitter</li>
<li>Toelichting commissies</li>
<li>Rapportage kascommissie 2016</li>
<li>Jaarstukken 2016 / Financiën 2017 / Begroting 2018</li>
<li>Kascommissieverkiezing</li>
<li>Evaluatie uitbesteding organisatie congres</li>
<li>Resultaat haalbaarheidsonderzoek vrijwilligersvergoeding</li>
<li>Aftreden Jaco en Roy, bestuursverkiezing</li>
<li>Rondvraag</li>
<li>Afsluiting</li>
</ol>
<p>De jaarrekening over 2016 is afgerond en gecontroleerd door de kascommissie. Voorlopige cijfers over 2017 en de volledige begroting over 2018 zullen enkele dagen voor de ALV naar alle aangemelde aanwezigen worden opgestuurd. Mocht je niet aanwezig kunnen zijn, maar deze informatie wel willen zien: laat het ons weten.</p>
<p>Aan het eind van zijn bestuurstermijn treedt dit jaar Jaco Koster af, en hij stelt zich niet herkiesbaar. Tevens treedt Roy Tomeij tussentijds af. We hebben op het moment van schrijven nog GEEN nieuwe leden bereid gevonden zich kandidaat te stellen voor een bestuursfunctie. Het bestuur kan niet fungeren met één overgebleven bestuurslid, omdat conform de statuten het bestuur moet bestaan uit minimaal drie personen. We hopen op de ALV alsnog één of meerdere kandidaten aan de leden te mogen voorstellen, zodat we kunnen voorkomen dat bestuursleden die willen aftreden dat niet kunnen. Wil je je hard maken voor de vereniging, dan is dit het moment. <a href="mailto:bestuur@lists.fronteers.nl">Neem gerust contact op met de huidige bestuursleden</a> om te bespreken wat een bestuursfunctie precies inhoudt, of om jezelf meteen kandidaat te stellen.</p>
<h2>Aanmelden</h2>
<p>Ben je van plan te komen, dan vragen we je vriendelijk je hieronder hiervoor in te schrijven, zodat we enigszins een idee hebben van de verwachte opkomst.</p>
</content>
</entry>
<entry>
<title>Fronteers zomerborrel</title>
<link href="https://www.fronteers.nl/nl/blog/2017/08/barbecue-en-borrel-voor-fronteersleden"/>
<updated>2017-08-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/08/barbecue-en-borrel-voor-fronteersleden</id>
<content xml:lang="nl" type="html"><p>Op <em>vrijdag 25 augustus</em> houdt Fronteers voor leden en niet-leden een gezellig diner bij <a href="http://bucksbbqhouse.nl/">Bucks BBQ</a> in Utrecht! De perfecte gelegenheid om bij te praten en vakantieverhalen te delen met mede-frontend ontwikkelaars, onder het genot van lekker eten en drinken.</p>
<p>Voor deze zomerse tegenhanger van de nieuwjaarsborrel neemt Fronteers de drankjes voor haar rekening. Het eten is voor eigen rekening en komt uit op 25,50 euro per persoon, en ook voor mensen die liever vegetarisch eten zal er keuze genoeg zijn.</p>
<p>Laat je weten of je komt? <a href="https://www.fronteers.nl/nl/activiteiten/2017/zomerborrel-2017">Vul het aanmeldingsformulier in voor 18 augustus</a>. Let op: er is beperkt plaats, dus wacht er niet te lang mee! :)</p>
</content>
</entry>
<entry>
<title>Workshops! Wees er snel bij!</title>
<link href="https://www.fronteers.nl/nl/blog/2017/07/workshops-wees-er-snel-bij"/>
<updated>2017-07-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/07/workshops-wees-er-snel-bij</id>
<content xml:lang="nl" type="html"><p>Tijd voor iets nieuws? Meld je aan voor de workshop Progressive Enhancement of Service Workers.</p>
<p>In augustus en september hebben we weer toffe workshops in Utrecht die je niet wilt missen!</p>
<h2>Progressive Enhancement</h2>
<p>Met de vele browsers, apparaten en gebruikers is niks zeker. Hoe garanderen we dat de websites en applicaties die we bouwen in alle situaties werken? Progressive Enhancement is een manier van bouwen om websites zeer robust te maken. Wilfred Nas laat zien waarom Progressive Enhancement belangrijk is en hoe je het toepast.</p>
<p>De workshop is 18 augustus. Lees meer op <a href="https://fronteers.nl/workshops/progressive-enhancement-wilfred-nas">Progressive Enhancement</a> en <a href="https://fronteers.nl/workshops/progressive-enhancement-wilfred-nas/18-augustus-2017">meld je snel aan</a>!</p>
<h2>Service workers, de motor van de Progressive Web App</h2>
<p>Samen met Anne en Jurgen van De Voorhoede neem je een duik in Service Workers. Wil je een website offline beschikbaar maken of de performance verbeteren? Misschien ben je een web applicatie aan het bouwen en wil je push notifications laten zien of op de achtergrond data synchroniseren. Dat en nog veel meer kan je doen met Service Workers!</p>
<p>Let op: enige ES2015/ES6 kennis is vereist.</p>
<p>Lees meer op <a href="https://fronteers.nl/workshops/service-workers">Service Workers</a> en <a href="https://fronteers.nl/workshops/service-workers/15-september-2017">meld je aan</a>. De workshop vindt plaats op 15 september.</p>
</content>
</entry>
<entry>
<title>Meld je nu aan voor de nieuwe workshops</title>
<link href="https://www.fronteers.nl/nl/blog/2017/05/meld-je-nu-aan-voor-de-nieuwe-workshops"/>
<updated>2017-05-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/05/meld-je-nu-aan-voor-de-nieuwe-workshops</id>
<content xml:lang="nl" type="html"><p>De komende maanden staan er weer boeiende workshops op het programma. Meld je gauw aan als je een deep dive wilt nemen in service workers, inclusive design of WebGL!</p>
<h2>Service Workers 101</h2>
<p>Anne en Jurgen van <em>De Voorhoede</em> nemen je mee op een ontdekkingstocht naar Service Workers. Een Service Worker is een script dat op de achtergrond in je browser draait, waarmee je dingen kan doen zonder dat je een webpagina of gebruikersinteractie nodig hebt. Push notifications, background synchronisatie, offline, performance en meer onderwerpen komen om de hoek kijken in deze workshop waarvoor degelijke kennis van ES6 vereist is.</p>
<h2>Inclusive Design &amp; Accessibility</h2>
<p>Hoe zorg je voor optimaal gebruiksgemak voor je blinde bezoekers? Wat is WAI-ARIA en wanneer gebruik je het? Wat is voldoende kleurcontrast? Is semantische HTML gebruiken niet gewoon genoeg? Peter van Grieken neemt je mee in het beantwoorden van deze en nog veel meer vragen in <em>Inclusive Design &amp; Accessibility</em>.</p>
<p>De workshop vindt plaats op vrijdag 30 juni. Vind alle details op <a href="https://fronteers.nl/workshops/inclusive-design-accessibility-peter-van-grieken">Inclusive Design &amp; Accessibility</a>.</p>
<h2>Practical WebGL with three.js</h2>
<p>Mocht je eind juli nog niet op het strand liggen, kom dan naar <em>Practical WebGL with three.js</em>. Martin Splitt laat je van alles zien van de mogelijkheden met 3D en WebGL.</p>
<p>Meer details vind je op <a href="https://www.fronteers.nl/workshops/practical-webgl-with-threejs-martin-splitt">Practical WebGL with three.js</a>.
Traditiegetrouw hebben alle workshops plaats in Utrecht.</p>
</content>
</entry>
<entry>
<title>Met korting naar CSS Day en/of Browser API Special</title>
<link href="https://www.fronteers.nl/nl/blog/2017/04/met-korting-naar-css-day-en-of-browser-api-special"/>
<updated>2017-04-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/04/met-korting-naar-css-day-en-of-browser-api-special</id>
<content xml:lang="nl" type="html"><p>Op 15 en 16 juni organiseert WCA voor de vijfde keer CSS Day, dit jaar voorafgegaan door Browser API Special. Fronteers-leden kunnen hier naar toe met een korting van 25 euro (1 dag) of 50 euro (2 dagen).</p>
<p>Zoals al vijf jaar gebruikelijk is, zullen op<a href="https://cssday.nl/2017"> CSS Day</a> topsprekers de voornaamste nieuwe ontwikkelingen in CSS bespreken. Onder andere zal Rachel Andrew de aanwezigen bijpraten over CSS Grid, dat thans daadwerkelijk wordt ondersteund, CSS-uitvinders Bert Bos en Håkon Wium Lie zullen spreken over wat ze anders zouden doen als ze CSS vandaag opnieuw mochten ontwerpen, Tab Atkins zal Houdini behandelen, en uitleggen waarom een vroeg-20e-eeuwse boeienkoning belangrijk is, en nog veel meer.</p>
<p>Tijdens de Browser API Special gaan de sprekers in op acht browser APIs, zoals WebVR door Ada Rose Edwards, Web Payments door Chris Wilson, en Animations door Rachel Nabors.</p>
<p>Fronteers-leden kunnen met 50 euro korting een kaart voor beide dagen kopen (500 euro ipv. 550), of met 25 euro korting een kaart voor Browser API Special (275 euro ipv. 300). De eendagskaarten voor CSS Day zijn reeds uitverkocht.</p>
<p>Mocht je gebruik willen maken van deze korting, <a href="mailto:bestuur@lists.fronteers.nl">stuur dan een e-mail aan het bestuur</a>. Zoals gebruikelijk geldt deze actie alleen voor leden die op dit moment al lid zijn.</p>
</content>
</entry>
<entry>
<title>15% korting op de Angular conferentie NG-NL, 16 maart 2017 in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2017/03/15-procent-korting-op-angular-conferentie-ng-nl-16-maart-2017-in-amsterdam"/>
<updated>2017-03-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/03/15-procent-korting-op-angular-conferentie-ng-nl-16-maart-2017-in-amsterdam</id>
<content xml:lang="nl" type="html"><p>Op 16 maart organiseert Xebia voor de derde keer haar Angular conferentie NG-NL in ‘t Sieraad te Amsterdam. Leden van Fronteers ontvangen 15% korting op de conference day.</p>
<h2>Thema 2017: Steam up your Angular, learn from world’s best.</h2>
<p>NG-NL is dé conferentie om bij te wonen als je als developer meer wilt weten over Angular 2. NG-NL wordt inmiddels door Google erkend als een van de betere Angular conferenties wereldwijd. NG-NL biedt verschillende tracks, hands-on workshops en interactieve sessies door nationale en internationale Angular experts.</p>
<h2>Enkele sprekers:</h2>
<h3><a href="https://twitter.com/toddmotto">Todd Motto</a></h3>
<p>Angular's Reactive Forms: the hero we need but not the one we deserve.
Todd is een front-end engineer uit England. Hij is wereldwijd een bekende spreker en Angular specialist. In zijn sessie vertelt hij meer over de krachtige API van Angular (2) reactive forms.</p>
<h3><a href="https://twitter.com/petebd">Pete Bacon Darwin</a></h3>
<p>Pete maakt sinds 2012 deel uit van het Angular core team en werd in November 2014 Angular team lead. Hij heeft diverse boeken geschreven over AngularJS en geeft wereldwijd lezingen op het gebied van Angular. Pete is tevens co-organiser van AngularConnect.
Pete vertelt samen met George Kalpakas tijdens zijn sessie meer over de transitie van Angular 1 naar 2 zonder je applicatie volledig te moeten herschrijven.</p>
<h3><a href="https://twitter.com/josepheames">Joe Eames</a></h3>
<p>Joe is een is a front-end specialist en heeft inmiddels met elke grotere Microsoft Language gewerkt. Zijn hart blijft echter uitgaan naar JavaScript. Joe is een welbekende blogger, spreker en organiseert o.a. ng-conf en AngularJS conference. Ook is Joe een vast panellid bij het JavaScript Jabber and Adventures onderdeel van Angular podcasts.</p>
<h2>Thema's die tijdens NG-NL aan het licht komen:</h2>
<ul>
<li>RxJS</li>
<li>Ecosystem</li>
<li>Testing</li>
<li>Mobile</li>
<li>GraphQL</li>
<li>Apollo</li>
<li>NativeScript</li>
<li>en meer... allemaal met een focus op Angular (2)</li>
</ul>
<p>Bekijk het volledige programma op <a href="http://www.ng-nl.org/">ng-nl.org</a></p>
<h2>Ledenkorting</h2>
<p>De 15% korting is geldig op een conferentie ticket.</p>
<h2>Deelnemen?</h2>
<p>Er is een beperkt aantal tickets en kortingscodes beschikbaar.
Bestel je ticket via <a href="https://www.eventbrite.com/e/ng-nl-2017-tickets-29575275445#tickets">ng-nl.org</a> en gebruik de volgende kortingscode.
<em>5982_Fronteers_NGNLconf</em></p>
</content>
</entry>
<entry>
<title>Inventarisatie interesse Fronteers broodfonds</title>
<link href="https://www.fronteers.nl/nl/blog/2017/02/inventarisatie-interesse-fronteers-broodfonds"/>
<updated>2017-02-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/02/inventarisatie-interesse-fronteers-broodfonds</id>
<content xml:lang="nl" type="html"><p>Als zelfstandige met of zonder personeel zijn er een hoop verzekeringen die je wel of niet voor jezelf kunt afsluiten. Eén van de meest bekende waar je als werknemer misschien nooit bij stilgestaan zult hebben is de Arbeidsongeschiktheidsverzekering (AOV).</p>
<p>Als werknemer ben je hier tegen bij wet beschermd. Als je een tijdelijk of vast contract hebt en je voor langere tijd ziek wordt, betaalt je werkgever je loon maximaal 2 jaar lang door. Je ontvangt dan minstens 70% van je laatstverdiende loon.</p>
<p>Als zelfstandige dien je dit uiteraard zelf te regelen. Er zijn een heleboel verzekeringsmaatschappijen die hiervoor verzekeringen aanbieden. Probleem bij een hoop van deze verzekeringen is dat ze vaak duur zijn en het soms een strijd kan zijn alsnog te krijgen waar je denkt recht op te hebben.</p>
<p>Als alternatief hiervoor is een tiental jaar geleden het eerste broodfonds opgericht. In een broodfonds ondersteun je elkaar op vrijwillige en gelijkwaardige basis. Meer informatie over het hoe en waarom vind je op <a href="http://www.broodfonds.nl/">de website van het broodfonds </a>.</p>
<p>Voor nu willen we graag inventariseren hoeveel Fronteersleden geïnteresseerd zouden zijn om aan zo’n broodfonds deel te nemen. Voor een eerste informatieronde zouden we minstens 20 geïnteresseerden moeten hebben. Het broodfonds kan maximaal 50 deelnemers bevatten.</p>
<p>Heb je interesse? Vul dan <a href="https://goo.gl/forms/eJmP7GmLmwabYHsm2">dit Google Form</a> even in. We houden je dan op de hoogte en mocht het tot een eerste informatiebijeenkomst komen dan ontvang je daarvoor een uitnodiging.</p>
</content>
</entry>
<entry>
<title>Workshop Datavisualisatie met Nadieh Bremer en nieuwe commissieleden gezocht</title>
<link href="https://www.fronteers.nl/nl/blog/2017/01/update-commissie-workshops"/>
<updated>2017-01-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/01/update-commissie-workshops</id>
<content xml:lang="nl" type="html"><p>In april presenteert de workshopcommissie met trots een <a href="https://www.fronteers.nl/workshops/creatieve-data-visualisatie-nadieh-bremer">nieuwe workshop over datavisualisatie</a>, met niemand minder dan Nadieh Bremer (die je onder andere kunt kennen van haar talk op Fronteers 2016). Ook zoeken we nieuwe leden voor onze commissie.</p>
<h2>Workshop “Datavisualisatie” met Nadieh Bremer</h2>
<p>Met de enorme hoeveelheid programma's waarmee je tegenwoordig data kan visualiseren, is het erg makkelijk om vast te komen in je grafiekkeuzes. Altijd maar weer gaan voor de staaf of lijn diagram, zonder echt na te denken over effectiviteit. Tijdens deze workshop zal Nadieh je leren hoe je een meer creatieve en praktische benadering kan nemen in het design van data visualisatie.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2016/30196726946-a4d24b6fba-k-full.jpg" alt="Nadieh Bremer voor het enorme projectiescherm van Tuschinski" /></p>
<p><em>Nadieh Bremer tijdens Fronteers 2016</em></p>
<p>Nadieh is opgeleid als sterrenkundige, werkte jaren als data-scientist in het bedrijfsleven en is als freelancer gespecialiseerd in de creatieve kant van datavisualisatie. Ze was afgelopen jaar te gast op het Fronteers-congres en gaf daar de fantastische talk <a href="https://vimeo.com/194817475">Hacking the visual norm</a>.</p>
<p>De workshop zal plaatsvinden op 28 april in Utrecht. We hebben ruimte voor 12 deelnemers. Kosten zijn €250 voor niet-leden of €150 voor leden, inclusief lunch, drankjes en versnaperingen.</p>
<h2>Workshops over CSS voor grote sites en ECMAScript 2015</h2>
<p>Wil je al eerder werken aan het vergroten van je kennis? We hebben in februari en maart workshops over <a href="https://www.fronteers.nl/workshops/that-mess-called-css-door-hans-grimm">CSS voor grote websites</a> (met Hans Grimm) en <a href="https://www.fronteers.nl/workshops/es2015-chiel-kunkels">ES2015</a> (met Chiel Kunkels).</p>
<p>Voor deze workshops, met dezelfde prijs en locatie, zijn op het moment van schrijven nog 6 (CSS) en 2 (ES2015) plaatsen beschikbaar. Wacht dus niet te lang met inschrijven! Vragen over de inhoud van deze workshops? Stel ze op Slack of <a href="https://www.fronteers.nl/nl/vereniging/contact/">neem contact op</a>.</p>
<h2>Nieuwe commissieleden gezocht</h2>
<p>Per 1 april zal onze tijdelijke voorzitter Hidde de Vries de <a href="https://www.fronteers.nl/vereniging/commissies/workshops">commissie</a> verlaten en we zijn daarom op zoek naar nieuw bloed!</p>
<p>Vind je het leuk om workshops zoals deze te helpen organiseren? Wil je meedenken over onderwerpen, met sprekers communiceren en potentiële deelnemers enthousiasmeren voor het bezoeken van een workshop? Dit is een goed moment om bij de workshopcommissie te komen: er is voor dit jaar namelijk begroot op het organiseren van enkele internationale workshop. Het organiseren daarvan zal in de komende maanden plaatsvinden. <a href="https://www.fronteers.nl/nl/vereniging/contact/">Neem contact op met de workshopcommissie</a> voor aanmelding of meer informatie.</p>
</content>
</entry>
<entry>
<title>Front-enders gezocht voor de Dutch Blockchain Hackathon</title>
<link href="https://www.fronteers.nl/nl/blog/2017/01/front-enders-gezocht-voor-de-dutch-blockchain-hackathon"/>
<updated>2017-01-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/01/front-enders-gezocht-voor-de-dutch-blockchain-hackathon</id>
<content xml:lang="nl" type="html"><p>Van 10 t/m 12 februari wordt de <a href="https://blockchainhackathon.eu/">Dutch Blockchain Hackathon</a> in Groningen georganiseerd. Hier zullen 50 teams in 5 verschillende tracks proberen innovatieve oplossingen te bedenken voor diverse uitdagingen die door de organisatie zijn opgesteld.
<a href="https://www.ebpi.nl/">EBPI</a>, dat deelneemt met drie teams, is nog op zoek naar front-end developers om hun teams te versterken.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2017/blockchainhackathon.jpg" alt="" /></p>
<p>Johan Mastenbroek en Ralph Verhelst van EBPI zijn druk bezig met het samenstellen van de teams, bestaande uit mensen met diverse expertises. EBPI zal, zoals gezegd, met drie teams aan de hackathon deelnemen. De <a href="https://blockchainhackathon.eu/tracks">tracks</a> waaraan zij zullen gaan deelnemen zijn:</p>
<ul>
<li>Reinventing Government</li>
<li>International Trade &amp; Entrepreneurship</li>
<li>Future of Pensions</li>
</ul>
<p>De specifieke “cases” binnen deze tracks zijn nog niet helemaal duidelijk, maar zullen waarschijnlijk binnenkort bekend worden.</p>
<p>Bij het samenstellen van de teams kwamen Johan en Ralph erachter dat ze onvoldoende front-end developers kennen om alle teams te voorzien van de benodigde expertise op dit vlak. And that’s where we come in!</p>
<h2>Waarom zou je mee doen?</h2>
<p>Daarover kunnen we Johan en Ralph het beste zelf aan het woord laten.
“De Dutch Blockchain Hackathon is een zeer interessant evenement waar we met circa 50 andere (internationale) teams een begin maken met de oplossingen voor de zeer nabije toekomst!”</p>
<p>“Onze teams verzamelen donderdagavond in Groningen en zullen feestelijk van start gaan. De hackathon zelf begint vrijdag 10 februari en eindigt zondag 12 februari met een mooi feestje. Maandagmorgen zullen we het hotel in Groningen verlaten.”</p>
<p>“Het wordt een fantastische ervaring waar je niet alleen zelf veel van kunt leren, maar waarbij je ook je eigen kennis en ervaring kunt overdragen aan studenten en collega’s van andere organisaties.”</p>
<p>“De reis – we gaan lekker met de trein – en het verblijf worden voor je geregeld! We zouden graag in contact komen met front-enders, die een goede kennis van JavaScript hebben, om onze teams te versterken. Mensen die callback functies en promises snappen. Heb je daarnaast ook nog kennis van één, of meerdere, van de “grotere” JS-frameworks, als AngularJS, ReactJS of MeteorJS dan is dat helemaal mooi meegenomen.”</p>
<h2>Hoe meld je je aan?</h2>
<p>Dus lijkt het je tof om een weekend lang samen te werken aan de cases, lekker te geeken aan de blockchain en je front-end expertise te delen? Mail dan naar <a href="mailto:info@ebpi.nl">info@ebpi.nl</a> ter attentie van Johan en Ralph. Zij nemen dan weer contact met je op om een en ander verder te regelen.</p>
</content>
</entry>
<entry>
<title>Een bijzonder jaar</title>
<link href="https://www.fronteers.nl/nl/blog/2017/01/een-bijzonder-jaar"/>
<updated>2017-01-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/01/een-bijzonder-jaar</id>
<content xml:lang="nl" type="html"><p>In oktober 2007 werd Fronteers opgericht na het oprichtingscongres, en het bestuur is trots op wat er allemaal tot nu toe gerealiseerd is. Sinds de laatste ALV heeft de vereniging niet stil gezeten. Er zijn een aantal mooie activiteiten die plaatsvinden in de komende maand. Het bestuur geeft hieronder enkele updates.</p>
<h2>Tien jaar</h2>
<p>Tijdens het congres in oktober zal Fronteers officieel tien jaar oud worden, en sinds het eerste <a href="https://www.fronteers.nl/nl/activiteiten/2007/oprichtingscongres">mini-congres</a> zijn er <a href="https://fronteers.nl/bijeenkomsten">122 bijeenkomsten</a>, <a href="https://fronteers.nl/workshops">23 verschillende workshops</a> en <a href="https://fronteers.nl/congres">10 congressen</a> georganiseerd. Verder zijn we afgelopen jaar begonnen met het ondersteunen van front-endinitiatieven die georganiseerd worden buiten Fronteers, en hebben we gezien dat het gebruik van Slack als zeer positief wordt ervaren. Voor het komende jaar zijn we wederom van plan om prachtige bijeenkomsten, workshops en een spetterend congres neer te zetten en dat kunnen we niet zonder onze leden. Heb je een tof idee dat Fronteers nog beter gaat laten worden? Heb je interesse om ons te helpen met het organiseren? Neem dan <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact op met het bestuur</a> en dan gaan we er samen een topjaar van maken!</p>
<h2>Congres</h2>
<p>Na <a href="https://www.fronteers.nl/nl/blog/2016/11/wijzigingen-na-alv">de laatste update van het bestuur</a> hebben een aantal mensen aangegeven interesse te hebben om plaats te nemen in de congrescommissie van dit jaar. Naar aanleiding van diverse persoonlijke gesprekken heeft het bestuur recentelijk een overleg gehad met alle geïnteresseerden, waarna officieel de <a href="https://www.fronteers.nl/nl/vereniging/commissies/congres">congres-commissie is vastgesteld</a>. Ook hebben we eerder in december al verkennende gesprekken gehad met Eventstack, en het bestuur ziet de samenwerking met deze partner met vertrouwen tegemoet.</p>
<h2>Atomic design en complexiteit in CSS</h2>
<p>Op dinsdag 24 januari organiseert Fronteers samen met E-sites in Breda een <a href="https://www.fronteers.nl/nl/activiteiten/2017/meetup-januari-e-sites">bijeenkomst met CSS als thema</a>. We hebben twee Nederlandstalige talks, van Iain van der Wiel en Bram Smulders. Uiteraard raden we iedereen van harte aan om naar deze bijeenkomst te gaan!</p>
<h2>Workshops over responsive design, ES2015 en CSS architectuur</h2>
<p>Ken je iemand die meer wil weten over de basis van front-end development? Op vrijdag 27 januari bieden we een beginnersworkshop <a href="https://www.fronteers.nl/workshops/responsive-design-frances-de-waal">Responsive design</a> aan. Doelgroep: back-enders, designers en iedereen die meer over front-end development wil weten. Wil je je <em>eigen</em> kennis opschroeven? In de komende maanden hebben we ook workshops over <a href="https://www.fronteers.nl/workshops/es2015-chiel-kunkels">ES2015</a> en <a href="https://www.fronteers.nl/workshops/that-mess-called-css-door-hans-grimm">CSS architectuur</a>. Deelname kost slechts €150 voor leden (€250 voor niet-leden), inclusief lunch.</p>
<h2>Aftreden bestuurslid</h2>
<p>Naar aanleiding van de –vrij publieke en niet altijd constructieve– discussie die plaatsvond na de laatste ALV heeft <a href="https://www.fronteers.nl/nl/blog/2016/11/wijzigingen-na-alv">Michael Hastrich</a> aangegeven dat hij niet langer op een zinnige wijze een bijdrage kan leveren binnen het bestuur, en daarom een stap terug wil doen. Het bestuur vindt het zeer jammer dat Michael deze beslissing heeft moeten nemen, maar wil hem alsnog hartelijk bedanken voor al het werk dat hij heeft verricht (en blijft verrichten) voor Fronteers. Het bestuur heeft voorlopig besloten dat ze in de huidige bezetting door zal gaan, waarbij de focus volledig zal komen te liggen op het organiseren van activiteiten, workshops, het congres en de communicatie naar de leden. In de loop van het jaar zal het bestuur nogmaals kijken of in de huidige bezetting doorgegaan zal worden, of dat er alsnog een tussentijdse ALV gehouden zal worden.</p>
</content>
</entry>
<entry>
<title>Met korting naar een Front-end Performance Master Class</title>
<link href="https://www.fronteers.nl/nl/blog/2017/01/front-end-performance-master-class"/>
<updated>2017-01-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2017/01/front-end-performance-master-class</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 27 januari organiseert De Voorhoede een Front-end Performance Master Class in Amsterdam. Leden van Fronteers ontvangen 10% korting op deze Master Class.</p>
<p>Tijdens deze hands-on Master Class, die volledig Engelstalig zal zijn, leer je hoe je onderzoekt wat jouw website langzaam maakt en hoe je dat verbetert. In <a href="https://www.voorhoede.nl/en/blog/why-our-website-is-faster-than-yours/">deze blogpost</a> lees je hoe De Voorhoede onlangs haar eigen website compleet vernieuwde. We gaan dieper in op deze technieken en je gaat zelf aan de slag door de performance van een real world voorbeeldsite te optimaliseren.</p>
<h2>Wat je leert</h2>
<ul>
<li>Begrijpen hoe browser rendering werkt</li>
<li>Analyseren van front-end web performance</li>
<li>Vinden van performance bottlenecks</li>
<li>Quick-win performance-optimalisaties</li>
<li>Geavanceerde performance-optimalisaties</li>
</ul>
<p><img src="https://www.fronteers.nl/_img/blog/2016/voorhoede-blog-post-full.jpg" alt="twee ontwikkelaars die naar broncode op een beeldscherm kijken" /></p>
<h2>Dagindeling</h2>
<ul>
<li>Introductie: performance matters, perceived performance</li>
<li>Critical rendering path</li>
<li>Performance meten: met Pagespeed Insights, WebPagetest &amp; Chrome dev tools</li>
<li>Basis performance optimalisatie: caching, gzipping, minification</li>
<li>Image delivery: WebP, <picture>, [srcset], data URI’s</picture></li>
<li>Web fonts: font subsetting, FOIT vs FOUT, async font loading</li>
<li>Lazy load JS: [async], [defer], loadJS</li>
<li>Lazy load CSS: with critical CSS</li>
<li>Moving towards HTTP/2</li>
</ul>
<h2>Praktisch</h2>
<p>De Master Class zal gehouden worden op 27 januari en vindt plaats op het kantoor van <a href="https://www.voorhoede.nl/">de Voorhoede</a> op de Rijnsburgstraat 9 in Amsterdam. Fronteers-leden krijgen 10% korting op de prijs van de Master Class Bij de toegang zijn koffie, lunch, en een drankje na afloop inbegrepen. Meer informatie is te vinden op de <a href="https://www.eventbrite.nl/e/tickets-front-end-performance-master-class-amsterdam-28783247468">website van de Master Class</a>.</p>
<p>Mocht je gebruik willen maken van deze korting, neem dan even contact op met <a href="https://www.eventbrite.nl/e/tickets-front-end-performance-master-class-amsterdam-28783247468">de ledenadministratie</a>. Zoals gebruikelijk geldt deze actie alleen voor leden die op dit moment al lid zijn.</p>
</content>
</entry>
<entry>
<title>Eerste data workshops 2017 bekend</title>
<link href="https://www.fronteers.nl/nl/blog/2016/12/eerste-data-workshops-2017-bekend"/>
<updated>2016-12-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/12/eerste-data-workshops-2017-bekend</id>
<content xml:lang="nl" type="html"><p>Voor 2017 hebben we de ambitie om elke maand een workshop te organiseren. Trots kunnen we mededelen dat de eerste maanden gevuld zijn met hele toffe workshops!</p>
<h2>Workshops 2017</h2>
<p>De volgende workshops ingepland voor begin 2017:</p>
<table>
<thead>
<tr>
<th>Workshop</th>
<th>Docent</th>
<th>Datum</th>
</tr>
</thead>
<tbody>
<tr>
<td>Responsive Webdesign</td>
<td>Frances de Waal</td>
<td>27 januari</td>
</tr>
<tr>
<td>That mess called CSS</td>
<td>Hans Grimm</td>
<td>24 februari</td>
</tr>
<tr>
<td>ES2015</td>
<td>Chiel Kunkels</td>
<td>24 maart</td>
</tr>
</tbody>
</table>
<p>Deze workshops kun je volgen voor €250,-. Ben je Fronteers lid? Dan kost het slechts €150,-. Zet de data in je agenda en meld je aan!</p>
<h2>Onderwerpen voor workshops</h2>
<p>Ook al hebben we voldoende onderwerpen om heel het jaar te vullen, wij zijn altijd benieuwd welke workshops jij graag zou bezoeken! Deel jouw onderwerpen door een reactie te plaatsen op dit bericht, stuur een tweet naar <a href="https://twitter.com/fronteers">@fronteers</a> of benader ons op <a href="https://www.fronteers.nl/blog/2016/02/fronteers-op-slack">Slack</a> of <a href="mailto:workshops@fronteers.nl">email</a>.</p>
</content>
</entry>
<entry>
<title>Wijzigingen na ALV</title>
<link href="https://www.fronteers.nl/nl/blog/2016/11/wijzigingen-na-alv"/>
<updated>2016-11-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/11/wijzigingen-na-alv</id>
<content xml:lang="nl" type="html"><p>Tijdens een bewogen ALV op 29 november jongstleden namen we afscheid van Arjan Eising, Hidde de Vries, Sander van Lambalgen en Thomas van Zuijlen als bestuursleden van Fronteers. Verder werden zowel het voorstel om een leverancier in te schakelen voor de organisatie van het congres alsmede het opstarten van een onderzoek naar het financieel compenseren van vrijwilligers aangenomen.</p>
<h2>Aangenomen voorstel: inschakelen leverancier voor organisatie congres</h2>
<p>Lid Thomas van Zuijlen heeft een <a href="https://www.fronteers.nl/blog/2016/11/alv-2016-motie-andere-aanpak-organisatie-congres">voorstel ingediend bij de ALV</a> om een leverancier in te schakelen voor het organiseren van het Fronteers congres. Concreet wil dat zeggen dat Fronteers het bedrijf Eventstack in gaat huren voor de logistieke organisatie van het jaarlijkse congres. In een eerder gesprek dit jaar heeft het toen zittende bestuur aangegeven een aantal bezwaren te zien bij dit voorstel, hierbij hebben zij aangegeven dat elk lid het recht heeft om een motie in te dienen bij de ALV. Nadat er een aantal vragen van de leden zijn beantwoord en een aantal voor- en tegenstanders aan het woord zijn geweest, heeft er een stemming plaatsgevonden.</p>
<p>Het voorstel is aangenomen met 21 stemmen voor, 18 stemmen tegen en 4 blanco.</p>
<p>Doordat Eventstack onder andere eigendom is van Thomas van Zuijlen, is hij om belangenverstrengeling te voorkomen, direct na de aanname van dit voorstel afgetreden als bestuurslid. Bestuurslid Hidde de Vries is ook afgetreden als bestuurslid. Hidde zal zijn penningmeesterschap tot eind 2016 blijven vervullen en zorgen voor overdracht aan zijn vervanger. Hij blijft voorlopig ook voorzitter van de workshopcommissie.</p>
<p>Naar aanleiding van de aanname van het voorstel zal het bestuur zo snel mogelijk een congres commissie opzetten, waarna de onderhandeling zal plaatsvinden met Eventstack. Zoals altijd blijft Fronteers de eigenaar van het congres, en zal de congrescommissie zorgdragen voor onder andere het inhoudelijke programma. Deze commissie zal ook bepalen welke taken wel en niet worden uitbesteed aan Eventstack. Vanwege de discussie die dit voorstel heeft veroorzaakt, zal het bestuur de leden actief op de hoogte houden op de website.</p>
<h2>Aangenomen voorstel: Onderzoek naar financiële compensatie vrijwilligers</h2>
<p>Leden Arjan Eising en Hidde de Vries hebben tijdens de ALV het volgende voorstel ingediend bij de ALV:</p>
<blockquote>
<p>Verzoekt het bestuur actief uit te zoeken welke voordelen en nadelen kleven aan het betalen van vrijwilligers voor hun inzet binnen de vereniging. Gekeken wordt naar de haalbaarheid, procedures, juridische en fiscale vraagstukken en hoe dit binnen de statuten, of binnen aan te passen statuten, kan werken om de doelstellingen van Fronteers te behalen. De resultaten dienen op een ALV in 2017 te worden gerapporteerd, eventueel bijgestaan door beleidsvoorstellen die er uit volgen.</p>
</blockquote>
<p>Na een korte uitleg hierover, is de ALV direct over gegaan tot een stemming en is dit voorstel met een zeer ruime meerderheid aangenomen.</p>
<p>Naar aanleiding van dit voorstel zal het bestuur een onderzoek instellen naar de mogelijkheden tot het financieel compenseren van leden. Het bestuur is van mening dat dit, gezien de discussie die plaats heeft gevonden op de ALV, zo snel mogelijk zal plaats vinden en ruim voor de ALV gepubliceerd zal worden op de website. Eventuele beleidsvoorstellen zullen op de ALV in 2017 worden ingediend.</p>
<h2>Afgetreden bestuursleden</h2>
<p>Bij deze ALV zijn de volgende bestuursleden afgetreden:</p>
<ul>
<li>Arjan Eising</li>
<li>Sander van Lambalgen</li>
<li>Hidde de Vries</li>
<li>Thomas van Zuijlen</li>
</ul>
<p>Het bestuur bedankt hen voor de inzet in de afgelopen jaren.</p>
<h2>Aangetreden bestuursleden</h2>
<p>Tijdens deze ALV zijn de volgende leden toegetreden tot het bestuur:</p>
<ul>
<li>Michael Hastrich</li>
<li>Roy Tomeij</li>
<li>Sander Vink</li>
</ul>
<p>Bij de eerstvolgende bestuursvergadering zal de rolverdeling voor 2017 worden vastgesteld en aangepast op de website.</p>
<h2>Oproep</h2>
<p><a href="https://www.fronteers.nl/vereniging/alv">De ALV</a> is het hoogste orgaan binnen de vereniging, waar opdrachten aan het bestuur kunnen worden gegeven, en plannen van het bestuur kunnen worden aangepast. Een voorstel wordt zoals <a href="https://www.fronteers.nl/vereniging/geschiedenis/statuten">beschreven in de statuten</a> aangenomen wanneer een meerderheid (50% + 1 stem) voor het voorstel is. Het bestuur hoopt dat alle leden, ook die tegen hebben gestemd, zich neer leggen bij de democratisch genomen beslissing van de ALV, of op een constructieve wijze binnen de kaders van de statuten, actie ondernemen.</p>
<p>Het bestuur roept een ieder op alle zorgen, opmerkingen of vragen naar aanleiding van het bovenstaande te <a href="https://www.fronteers.nl/nl/vereniging/contact/">delen met het bestuur</a>, zodat deze meegenomen kunnen worden in de verdere besluitvorming.</p>
</content>
</entry>
<entry>
<title>Kandidaat bestuur Fronteers: Michael Hastrich</title>
<link href="https://www.fronteers.nl/nl/blog/2016/11/kandidaat-bestuur-fronteers-michael-hastrich"/>
<updated>2016-11-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/11/kandidaat-bestuur-fronteers-michael-hastrich</id>
<content xml:lang="nl" type="html"><p>Aanstaande maandag vindt de <a href="https://www.fronteers.nl/blog/2016/11/aanmelden-alv-2016">jaarlijkse ALV van Fronteers</a> plaats. Een van de onderdelen tijdens de ALV is de bestuursverkiezing. Er zijn op dit moment twee kandidaten voor het bestuur. Hieronder stelt de tweede zich aan jullie voor: Michael Hastrich.</p>
<p>Hallo, ik ben Michael Hastrich, woonachtig in Utrecht en werkzaam als freelance front-end developer. Ik heb geen idee wanneer ik precies lid geworden ben van Fronteers, maar ben vooral de laatste 5 jaar actief geweest binnen de vereniging. Nu wil ik me graag kandidaat stellen voor een bestuursfunctie.</p>
<p>Nadat ik eerst een poosje bij de marketingcommissie wat kleinere klusjes gedaan heb, vroeg Hidde me in 2013 bij de congrescommissie te komen. Iets wat ik een ontzettende eer vond en dus graag met beide handen aanpakte.</p>
<p>Na 5 congressen te hebben georganiseerd, vind ik het tijd dat weer aan anderen te laten. Ik kijk er naar uit om in oktober 2017 plaats te nemen in zo’n luxueuze stoel in Tuschinski en weer een ‘information overload’ over me uitgestort te krijgen.</p>
<p>Maar ik wil wel graag ‘iets’ blijven doen voor de vereniging en dat zou nu dus kunnen in de vorm van plaatsnemen in het bestuur. Dat lijkt me erg interessant, met name door het kruispunt waarop de vereniging zich lijkt te bevinden. De afgelopen tijd zijn er een hoop zaken bespreekbaar gemaakt waarvan ik denk, dat ze aangeven dat de vereniging een aantal belangrijke keuzes moet gaan maken.
Ik zou graag meedenken over die keuzes, ervoor willen zorgen dat leden zich betrokken bij en gehoord voelen in die keuzes. En dat de keuzes die genomen worden zo goed mogelijk worden ondersteund door beleid.</p>
<p>Daarnaast wil ik me er als bestuurslid hard voor gaan maken dat Fronteers zich wat meer naar buiten gaat richten. Dat we meer de aansluiting gaan zoeken met verwante beroepsgroepen en dat we ook duidelijker maken aan front-end developers die nog geen lid van Fronteers zijn, waarom ze dat wel zouden moeten worden.</p>
<p>Ook directere en regelmatigere communicatie met de leden zie ik als een verbeterpunt en ook daarvoor zou ik graag het initiatief willen nemen om te kijken of we daar met gelijkgestemden binnen de vereniging niet eens iets aan kunnen doen.</p>
</content>
</entry>
<entry>
<title>Kandidaat bestuur Fronteers: Sander Vink</title>
<link href="https://www.fronteers.nl/nl/blog/2016/11/kandidaat-bestuur-fronteers-sander-vink"/>
<updated>2016-11-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/11/kandidaat-bestuur-fronteers-sander-vink</id>
<content xml:lang="nl" type="html"><p>Aanstaande maandag vindt de <a href="https://www.fronteers.nl/blog/2016/11/aanmelden-alv-2016">jaarlijkse ALV van Fronteers</a> plaats. Een van de onderdelen tijdens de ALV is de bestuursverkiezing. Er zijn op dit moment twee kandidaten voor het bestuur. Hieronder stelt de eerste zich aan jullie voor: Sander Vink.</p>
<p>Hi allen! Ik ben Sander Vink, 34 jaar, woon samen met mijn (bijna) vrouw en twee kids in Utrecht, en werk bij <a href="https://developer.procurios.com/">Procurios</a>. In mijn vrije tijd sport ik regelmatig (tennis/hardlopen), en wat online gaming kan ik zeker ook waarderen. Verder ga ik graag naar congressen, en ben ik een regelmatig bezoeker van meetups.</p>
<p>Samen met een aantal collega's ging ik al een aantal jaar naar het Fronteers congres, en heb twee jaar geleden besloten om mij aan te melden voor de congres commissie. Dit heb ik dan ook twee jaar met veel plezier gedaan. Het is mij daarbij vooral opgevallen hoe erg je bijdrage aan Fronteers wordt gewaardeerd door iedereen die ik sindsdien gesproken heb. Graag zou ik dit verder voortzetten als bestuurslid van Fronteers.</p>
<p>Fronteers is als vereniging al behoorlijk bekend in de front-end wereld van Nederland, maar volgens mij hebben we hier nog steeds terrein te winnen. Het aantal leden schommelt ook al even rond hetzelfde punt, terwijl het aantal front-end developers niet is afgenomen; hier is dus werk aan de winkel! Het moet voor iedereen duidelijk zijn dat een lidmaatschap van Fronteers toegevoegde waarde heeft, en dit ook blijft houden, ongeacht het niveau wat je al bereikt hebt als front-end developer. Vanuit het bestuur, namens de vereniging en haar leden, draag ik daar graag mijn steentje aan bij.</p>
</content>
</entry>
<entry>
<title>Meld je nu aan voor de ALV 2016</title>
<link href="https://www.fronteers.nl/nl/blog/2016/11/aanmelden-alv-2016"/>
<updated>2016-11-21T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/11/aanmelden-alv-2016</id>
<content xml:lang="nl" type="html"><p>Maandag 28 november houden we onze jaarlijkse algemene ledenvergadering (ALV). Alle leden zijn hiervoor van harte uitgenodigd. De locatie van de ALV is Zalencentrum Se7en (toegang via <a href="http://www.sevenutrecht.nl/contact/route/">Restaurant Se7en</a>), Mariaplaats 7, ongeveer vijf minuten lopen vanaf Utrecht CS.</p>
<p>Voor de mensen die van ver komen zullen er vanaf 18:00 broodjes klaar staan. De vergadering zelf zal stipt om 19:00 uur beginnen, en we gaan ons er voor inzetten om deze kort en doeltreffend te laten verlopen. We waarderen de inspraak van leden echter zeer, en hebben een aantal onderwerpen op het programma waarvan we verwachten dat deze discussie zullen oproepen, dus verwachten dat de totale vergadering eerder drie dan twee uur zal duren.</p>
<p>Het staat leden nog steeds vrij voorstellen voor de agenda in te dienen. Vooralsnog is de agenda van de avond de volgende:</p>
<ol>
<li>Welkom en opening door de voorzitter</li>
<li>Besluiten eerdere ALVs</li>
<li>Toelichting commissies</li>
<li>Rapportage kascommissie 2014</li>
<li>Rapportage kascommissie 2015</li>
<li>Jaarstukken 2015 / Financiën 2016 / Begroting 2017</li>
<li>Kascommissieverkiezing</li>
<li>Ingediend voorstel: inschakelen leverancier voor organisatie congres</li>
<li>Aftreden Sander en Arjan, bestuursverkiezing</li>
<li>Rondvraag</li>
<li>Afsluiting</li>
</ol>
<p>Aan het eind van zijn bestuurstermijn treedt dit jaar Sander van Lambalgen af, en stelt zich - na 8 jaar in het bestuur - niet herkiesbaar. Tevens - na wel 9 jaar in het bestuur (sinds het allereerste begin!) - heeft ook Arjan Eising besloten dat het genoeg is geweest, en treedt tussentijds af. Het bestuur bedankt hen voor al hun inspanningen en bijdragen uit de afgelopen jaren.</p>
<p>We hebben op het moment van schrijven nog <em>geen</em> nieuwe leden bereid gevonden zich kandidaat te stellen voor een bestuursfunctie. Het bestuur kan theoretisch fungeren met de overgebleven drie bestuursleden, maar zou graag versterking zien. We hopen op de ALV alsnog een of meerdere kandidaten aan de leden te mogen voorstellen.</p>
<h2>Toelichting op de begroting</h2>
<p>We zijn er op dit moment nog mee bezig, maar hopen de voorlopige financiële cijfers over 2016 en volledige begroting over 2017 enkele dagen voor de ALV naar alle aangemelde aanwezigen te kunnen opsturen. (Mocht je niet aanwezig kunnen zijn, maar deze informatie wel willen zien, dan is dat natuurlijk ook mogelijk. Laat het ons weten!)</p>
<p>Belangrijkste wijzigingen in de begroting t.o.v. vorige jaren zijn de volgende punten:</p>
<h2>Extra budget activiteitencommissie t.b.v. niet-gesponsorde bijeenkomsten</h2>
<p>We zijn recent met <a href="https://www.fronteers.nl/blog/2016/11/verslag-bijeenkomst-toegankelijkheid">dit type bijeenkomsten</a> gestart, zijn er enthousiast over, en willen dit concept dan ook voortzetten (naast de normale bijeenkomsten). Hier is extra budget voor gereserveerd.</p>
<h2>Nieuwe post communityondersteuning</h2>
<p>Er worden veel voor front-enders nuttige activiteiten georganiseerd door andere organisaties dan Fronteers. Mits deze organisaties en activiteiten &quot;passen&quot; bij Fronteers (dwz gerund door vrijwilligers, professionalisering ten goede komen, etc), willen wij dit ondersteunen, met advies en promotie, maar ook - waar nodig - financieel. We zijn hier al mee begonnen, en willen dit volgend jaar graag verder voortzetten.</p>
<h2>Reservering vernieuwing website</h2>
<p>Naar aanleiding van onze ledenconsultatie in september stelde een lid voor geld uit te geven aan een nieuwe Fronteers-website. Het bestuur is enthousiast over het idee, maar heeft wel enkele bedenkingen. Er is een stelpost opgenomen in de begroting. De penningmeester heeft een blogpost geschreven <a href="https://www.fronteers.nl/blog/2016/11/begroting-2017-een-nieuwe-website">om dit onderwerp nader toe te lichten</a>.</p>
<h2>Voorstel inschakelen leverancier Eventstack voor praktische organisatie Fronteers Conference</h2>
<p>Tenslotte hebben we dit jaar een voorstel van Thomas van Zuijlen om aan de leden voor te leggen. Thomas is bestuurslid, maar doet dit voorstel expliciet als lid, gericht aan de leden. De samenvatting van het voorstel:</p>
<blockquote>
<p>Het management van de praktische organisatie van Fronteers Conference uitbesteden aan een leverancier, Eventstack. De congrescommissie hoeft geen logistieke werkzaamheden meer uit te voeren en blijft inhoudelijk verantwoordelijk voor het congres. Fronteers richt zich op inhoud, terwijl de organisatie van het congres verder professionaliseert.</p>
</blockquote>
<p>Thomas heeft een blogpost geschreven met <a href="https://www.fronteers.nl/blog/2016/11/alv-2016-motie-andere-aanpak-organisatie-congres">verdere overwegingen</a>, en hij zal dit op de ALV verder toelichten.</p>
<p>Eerdere discussie over dit onderwerp valt ook <a href="https://www.fronteers.nl/vereniging/bestuur/notulen/04-08-2016">in de bestuursnotulen</a> terug te lezen.</p>
<h2>Aanmelden</h2>
<p>Ben je van plan te komen, dan vragen we je vriendelijk je hieronder hiervoor in te schrijven, zodat we enigszins een idee hebben van de verwachte opkomst.</p>
</content>
</entry>
<entry>
<title>ALV 2016: Motie: Andere aanpak organisatie congres</title>
<link href="https://www.fronteers.nl/nl/blog/2016/11/alv-2016-motie-andere-aanpak-organisatie-congres"/>
<updated>2016-11-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/11/alv-2016-motie-andere-aanpak-organisatie-congres</id>
<content xml:lang="nl" type="html"><p>Het Fronteerscongres is in negen jaar uitgegroeid tot Fronteers Conference. De organisatie daarvan is inmiddels geen avondwerk meer, maar een dagtaak. De congrescommissie gaat niet verder in zijn huidige vorm: een goed moment om het anders aan te pakken. Aangeboden ter overweging aan de algemene ledenvergadering van Fronteers: Ik stel voor om de commissie op inhoud te laten sturen en om de praktische organisatie uit te besteden.</p>
<h2>Achtergrond</h2>
<p>Het Fronteerscongres bestaat bijna 10 jaar. In dit decennium is het congres uitgegroeid van een mooie bijeenkomst tot een congres van wereldformaat met een begroting in tonnen. De organisatie moet momenteel rekening houden met, en zorgen voor, steeds meer verschillende facetten van het congreswezen. Een zaal en een groep sprekers is niet meer voldoende, het huidige congres is een onderneming met een voorbereiding van een jaar, een groep side events en een logistieke piek van twee weken. Dat brengt allerlei reis-, branding-, contact-, plan-, en ander organisatiewerk met zich mee.</p>
<p>De inspanning die daarvoor nodig is, past niet meer in de avonden en weekenden van enkele vrijwilligers. Bovendien is niet alleen de hoeveelheid, maar ook de aard van de werkzaamheden gegroeid. Inmiddels is front-end-inhoudelijk werk helemáál nog maar een klein onderdeel van het takenpakket.</p>
<p>Jan van Hellemond en ik zijn al jaren bij het congres betrokken; eerst als vrijwilliger en sponsor, en sinds 2014 en 2013 als lid van de congrescommissie. We hebben met onze collega-vrijwilligers veel (mee)gemaakt van deze groei. Wij vinden het inmiddels juist uitermate leuk om allerlei logistieke werkzaamheden uit te voeren - dit jaar hebben we naast ons front-end-bedrijf samen ook een bedrijf opgericht voor de organisatie van bijeenkomsten en evenementen voor developers.</p>
<h2>Voorstel</h2>
<p>Kortweg stel ik daarom het volgende voor: Een nieuwe congrescommissie legt zich toe op de inhoudelijke invulling van het congres, en Fronteers schakelt onze 'tweemanszaak' Eventstack in voor de praktische organisatie van Fronteers Conference.</p>
<p>(Net zoals reisexpert Been Here wordt ingeschakeld voor het regelen en boeken van reizen voor sprekers, Event Engineers om de Wi-Fi te verzorgen tijdens het congres, DJP Media voor de videoregistratie, Van Dam Catering en Select Catering voor het eten, enzovoort.)</p>
<blockquote>
<p>Voorstel: Het management van de praktische organisatie van Fronteers Conference uitbesteden aan leverancier Eventstack. De congrescommissie hoeft geen logistieke werkzaamheden meer uit te voeren en blijft inhoudelijk verantwoordelijk voor het congres. Fronteers richt zich op inhoud, terwijl de organisatie van het congres verder professionaliseert.</p>
</blockquote>
<h2>Vragen</h2>
<h3>Waarom leg je dit voor aan de leden - we worden toch ook niet over de cateraar van het congres geconsulteerd?</h3>
<p>Het bestuur was verdeeld over het initiële voorstel en adviseerde om de leden te raadplegen. De verdeeldheid zat 'm erin dat congresorganisatie traditioneel onderdeel is van de vrijwilligersactiviteiten van de vereniging. Ook was men benieuwd wat dit betekent voor de continuïteit van de congressen. Omdat er geen overeenstemming bereikt werd en er dus niet zonder meer een besluit genomen is, kwam het advies om de kwestie aan de leden voor te leggen.</p>
<h3>Gaan we nu vrijwilligers betalen?</h3>
<p>Nee, dit is een voorstel om een leverancier in te schakelen voor het gedurende het hele jaar tijdens kantooruren runnen van de praktische kant van het congres. Dat is dus onder meer het corresponderen met sprekers, leveranciers, en bezoekers via mail, Twitter en website, maar ook het coördineren van logistiek voor de congresweek, het reserveren van locaties, het zorgen voor promotiemateriaal, het verzorgen van design, regelen van video-opnames enzovoort.</p>
<h3>Waarom ga je niet gewoon door met vrijwilligen?</h3>
<p>Het vasthouden en verder doen groeien van de kwaliteit van het congres kost volgens ons te veel tijd in de oude congrescommissie-opzet. Bovendien gaat veel tijd zitten in het vergaderen en opvolgen van takenlijstjes bij alle vrijwilligers. Die moeite en tijd gaat dan ten koste van regulier werk overdag en van te veel avonden in de week, gedurende het hele jaar. Het terugschroeven van die inzet vertegenwoordigt volgens ons een stap terug in kwaliteit en klasse van het congres. Daarom willen we logistiek leverancier worden: gewoon tijdens werktijd overdag, behoud en groei van evenementkwaliteit gedurende het jaar, en de commissie kan meer op de inhoud zitten.</p>
<h3>Als we de praktische organisatie uitbesteden, doet de vereniging dan zelf nog iets?</h3>
<p>Jazeker - sprekers uitkiezen, side events bedenken, vrijwilligen tijdens de congresweek, initiatieven toevoegen, enzovoort. De congrescommissie kan met veel minder bijeenkomsten toe, en kan het bij vergaderen en bij inhoudelijke actie houden.</p>
<h3>Wie bepaalt of het goed gaat?</h3>
<p>Een nieuwe congrescommissie. Namens het bestuur blijft een bestuurslid een oogje in het zeil houden (zoals gebruikelijk, en zoals bij alle commissies). Dat is een ander bestuurslid dan Thomas. Jan en Thomas zitten ook niet meer in de congrescommissie, maar Eventstack is wel bij vergaderingen aanwezig om snel te kunnen schakelen.</p>
<h3>Wat kost dit?</h3>
<p>Het gaat bij dit voorstel in eerste instantie om <em>het idee</em> van uitbesteding van de praktische werkzaamheden, maar om je een beeld te geven: we schatten € 15-20K per jaar, om een dag per week full-pull aan het congres te werken. Precieze tijdsbesteding fluctueert natuurlijk, want bepaalde perioden van het jaar vergen meer tijd per week. De exploitatie van het congres is nu een kleine € 200.000 per jaar.</p>
<h3>UPDATE: Wacht even, leuk idee, maar je zit toch ook in het bestuur? Is dat niet dubbel?</h3>
<p>Dat is een goed punt. Ik ben het met verschillende vraagstellers eens, dat dat eigenlijk niet goed te combineren is met het gelijktijdig deel zijn van een bedrijf dat ingehuurd wordt. Zeker niet als er een beoordeling gemaakt moet worden of er iets verkeerd gaat: dan moet Fronteers natuurlijk Eventstack (net zo goed als de cateraar, of de mensen van de verlichting, of de boekhouder) zonder meer de wacht aan kunnen zeggen.</p>
<p>Als ik bestuurslid ben, is dat natuurlijk ontzettend drassig gebied. Om de vereniging niet in die positie te brengen (noch mijzelf, noch Eventstack), stel ik daarom voor mijn positie in het bestuur neer te leggen als de ALV dit voorstel aanneemt en erop geacteerd wordt.</p>
</content>
</entry>
<entry>
<title>Begroting 2017: een nieuwe website?</title>
<link href="https://www.fronteers.nl/nl/blog/2016/11/begroting-2017-een-nieuwe-website"/>
<updated>2016-11-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/11/begroting-2017-een-nieuwe-website</id>
<content xml:lang="nl" type="html"><p>Wie de Fronteers-begroting voor 2017 bestudeert, zal het vast opvallen: er is een stelpost geïntroduceerd genaamd ‘Eenmalige kosten nieuwe website’. Graag licht het bestuur toe waar deze reservering voor is bedoeld.</p>
<p>We nodigen leden van harte uit hun mening over deze toelichting te geven op de ALV, 28 november in Utrecht (<a href="https://www.fronteers.nl/blog/2016/11/aanmelden-alv-2016">Aanmelden</a>).</p>
<h2>Ledenconsultatie: waarom geen nieuwe website?</h2>
<p>Naar aanleiding van de <a href="https://www.fronteers.nl/blog/2016/09/ledenraadpleging-wat-te-doen-met-ons-geld">ledenconsultatie in september</a> stelde een Fronteers-lid op Slack de volgende vraag: is het niet tijd om eens een nieuwe website te laten ontwerpen? ‘We doen hele coole dingen, maar dat straalt de website niet echt uit […] daar past een hipper jasje bij’, schreef ze.</p>
<p>In de discussie die erop volgde werd uitgebreid gesproken over allerlei aspecten. Kunnen we dit (deels) zelf binnen een GitHub project organiseren, waar de hele community mag meecommitten? Of is het te moeilijk je eigen website te maken, en moeten we er professionals voor inhuren? Voor dat laatste gingen veel stemmen op, en er werd de suggestie gedaan te kiezen voor het designbureau dat onze originele website (en logo) bijna tien jaar geleden gratis ontwierp.</p>
<p>Ook werd nogmaals duidelijk dat de beheerder van de site zeer open staat voor wijzigingen. In de afgelopen jaren zijn er enkele keren <em>realigns</em> in het ontwerp doorgevoerd en regelmatig nieuwe features en paginasoorten toegevoegd. De voorstellen voor een nieuwe website gaan expliciet om vernieuwing die verder gaat dan dat.</p>
<p>De conclusie uit de discussie op Slack was dat een nieuw ontwerp (en mogelijk daarnaast ook een nieuw CMS) wenselijk was. Het doel? Al onze <em>informatie veel gestructureerder aanbieden</em>, beter <em>laten zien wat we doen</em> (aan leden en niet-leden) en <em>onszelf aantrekkelijker presenteren</em> richting mensen die overwegen lid te worden.</p>
<h2>Uitdagingen</h2>
<p>Bovenstaande is recent ook binnen het bestuur besproken. De conclusie daar was helder: een meerderheid van het bestuur zou erg blij worden van het vernieuwen van de website. Bestuursleden krijgen regelmatig uit het ‘veld’ te horen dat onze website er verouderd uit ziet, en bepaalde informatie-architectuur-zaken zitten promotie van kernactiviteiten als ons congres, workshops en meetups in de weg.</p>
<p>Er werden wel bedenkingen uitgesproken over hoe we faire keuzes kunnen maken, en over de beschikbare tijd bij vrijwilligers.</p>
<p>Ten eerste een bedenking over de inhuurprocedure. Fronteers huurt al jaren derde partijen in om zich te laten ondersteunen, bijvoorbeeld op het gebied van administratie, event catering, audiovisuele techniek en zaalhuur. Kenmerkend voor al deze partijen is dat hun vakgebied buiten dat van ons ligt. Dit zou anders zijn bij het inhuren van een bedrijf dat ons kan helpen een website te produceren. Binnen het bestuur, dat hoofdverantwoordelijk zou zijn bij een dergelijke uitgave, is iedereen werknemer of freelancer bij één of meerdere van dat soort bedrijven. Is het voor het bestuur principieel wel mogelijk een zuivere keuze te maken? Kunnen we dit zo organiseren dat het niet tot gewetenskwesties leidt?</p>
<p>Een tweede bedenking: het idee van een nieuwe website bestaat al jaren. Er hebben zelfs wel eens meetings bij webbureaus plaatsgevonden die ons gratis wilden helpen. Grootschalige wijzigingen zijn in de afgelopen jaren altijd wel een wens geweest, maar lijken vooral te zijn uitgebleven door tijdgebrek van vrijwilligers. Het uitbesteden van het redesignproject zou nog steeds een onbetaalde vrijwilligersfunctie zijn.</p>
<h2>Conclusie</h2>
<p>Het bestuur vindt het een goed om een traject voor een nieuwe website op te starten. We zien wel uitdagingen in belangen binnen het keuzeproces en het aansturen van een ingehuurd team.</p>
<p>Om het <em>mogelijk</em> te maken in 2017 een bedrag aan een nieuwe website te besteden, hebben we in de begroting voor 2017 een stelpost opgenomen. Mocht er een commissie opstaan of een uitgewerkt voorstel vanuit het bestuur of leden komen, dan zou daar geen nieuwe ALV of uitstel tot 2018 voor nodig zijn.</p>
<p>Heb je ideeën over hoe we dit kunnen doen of wil je over bovenstaande toelichting je mening geven? Kom dan naar de <a href="https://www.fronteers.nl/blog/2016/11/aanmelden-alv-2016">ALV</a> op 28 november, waar het onderwerp besproken zal worden.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst over muziek en het web</title>
<link href="https://www.fronteers.nl/nl/blog/2016/11/bijeenkomst-muziek"/>
<updated>2016-11-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/11/bijeenkomst-muziek</id>
<content xml:lang="nl" type="html"><p>Woensdag 7 december zal Desmet Studio's op zijn grondvesten daveren dankzij onze bijeenkomst over muziek en het web, met als eerste act van de avond <a href="http://www.holovaty.com/">Adrian Holovaty</a> gevolgd door <a href="https://blog.sambego.be/">Sam Bellen</a>. Zet 'm dus in je agenda en <a href="https://www.fronteers.nl/bijeenkomsten/2016/muziek-en-het-web">meld je aan</a>!</p>
<p>Na al enkele keren te hebben gesproken op Fronteers meetups in België, hebben we Sam Bellen eindelijk een keer naar Nederland kunnen halen. Eerder dit jaar sprak hij nog over <a href="https://jsconfbp.com/speakers/sam-bellen.html">Changing live audio with the web-audio-api</a> tijdens JSConf Budapest waarbij hij dankzij de kracht van het web het geluid van zijn gitaar kon manipuleren.</p>
<p><img src="https://www.fronteers.nl/_img/bijeenkomsten/meetup-0712.jpg" alt="Foto van Adrian Holovaty en Sam Bellen" /></p>
<p><em>No cats were harmed in the making of this photo</em></p>
<p>Je kan gerust rechtstreeks van je werk naar de meetup komen want wij zorgen voor catering zodat je met een volle maag kan genieten van deze topacts!</p>
<p>De bijeenkomst vindt plaats in Desmet Studio's, nabij Artis in Amsterdam. Je kunt je vanaf nu <a href="https://www.fronteers.nl/bijeenkomsten/2016/muziek-en-het-web">aanmelden</a>. Wees er snel bij, want er is maar een beperkt aantal plaatsen.</p>
</content>
</entry>
<entry>
<title>Fronteers in Desmet Studio's #a11y</title>
<link href="https://www.fronteers.nl/nl/blog/2016/11/verslag-bijeenkomst-toegankelijkheid"/>
<updated>2016-11-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/11/verslag-bijeenkomst-toegankelijkheid</id>
<content xml:lang="nl" type="html"><p>Afgelopen dinsdag organiseerde Fronteers voor het eerst een bijeenkomst die niet bij een bedrijf, maar op een ‘eigen’ locatie plaatsvond. Het was gezellig druk in Desmet Studio's in Amsterdam, met zo'n 60 enthousiaste front-end ontwikkelaars.</p>
<p>De bijeenkomst stond geheel in het tegen van toegankelijkheid. Als sprekers waren Karl Groves (<a href="https://twitter.com/karlgroves">@karlgroves</a>) en Job van Achterberg (<a href="https://twitter.com/detonite">@detonite</a>) te gast, en Thomas van Zuijlen was namens Fronteers de <em>host</em>.</p>
<h2>Wat hebben we geleerd?</h2>
<p><img src="https://www.fronteers.nl/_img/blog/2016/karl-praat.jpg" alt="Karl Groves met publiek" /></p>
<p><em>Karl Groves laat zien hoe je een ‘dialog’ toegankelijker maakt</em></p>
<p>Karl liet een aantal manieren zien om met JavaScript toegankelijkheid te verbeteren. Het idee dat toegankelijkheid betekent dat een pagina zonder JavaScript moet werken, ontkrachtte hij. Een toegankelijke pagina beantwoordt de vraag ‘wat is dit en wat moet het doen?’. Volgens Karl kan JavaScript daar <em>juist</em> goed bij helpen, bijvoorbeeld door roles, tabgedrag en focus vanuit scripts te beïnvloeden. Via de speakers van Desmet luisterden we samen naar hoe screenreader VoiceOver de door hem gebouwde interacties interpreteerde. Karl liet ons vervolgens zien hoe dat eenvoudig een stuk beter kon.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2016/job-praat.jpg" alt="Job van Achterberg" /></p>
<p><em>Job haalt fronteers.nl door de W3C validator. Gelukkig, geen errors!</em></p>
<p>Job ging in zijn talk in op een aantal tools die je pagina kunnen analyseren. Er zijn inmiddels vele browser plug-ins die je eenvoudig kunnen laten zien of je pagina genoeg contrast heeft, hoe deze eruit ziet voor mensen met visuele beperkingen, en wat de roles van elementen in je pagina zijn. Er zijn ook tools die je als onderdeel van je buildproces kunt toevoegen. Tot slot schetste Job voor ons de toekomst van dit soort tools, en gaf hij een idee van het soort vragen waar makers van toegankelijkheidstools, zoals hijzelf, mee worstelen.</p>
<h2>Meer bijeenkomsten op eigen locaties</h2>
<p><img src="https://www.fronteers.nl/_img/blog/2016/desmet-buiten.jpg" alt="" /></p>
<p>De eerste niet-bij-een-bedrijf-bijeenkomst was een groot succes te noemen. Het team activiteiten is van plan om elk kwartaal een bijeenkomst zoals deze te organiseren, op een door Fronteers gehuurde locatie. Het idee is dus: elke maand een bijeenkomst, waarvan elk kwartaal eentje op een eigen locatie. Bijeenkomsten bij bedrijven blijven dus ook terugkomen.</p>
<h2>De volgende: 7 december in Amsterdam</h2>
<p>Heb je deze bijeenkomst gemist? Over een maand vindt er nog eentje plaats, wederom bij Desmet Studio's, en je kunt je daar vanaf nu voor <a href="https://www.fronteers.nl/bijeenkomsten/2016/muziek-en-het-web">inschrijven</a>. Het onderwerp: “muziek en het web”, waarin je onder andere kunt horen over het aansturen van je gitaar via JavaScript.</p>
</content>
</entry>
<entry>
<title>ALV 2016: ma 28 november - bestuursleden gezocht</title>
<link href="https://www.fronteers.nl/nl/blog/2016/10/datum-alv-2016"/>
<updated>2016-10-31T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/10/datum-alv-2016</id>
<content xml:lang="nl" type="html"><p>Op maandagavond 28 november zal het 10e verenigingsjaar van Fronteers van start gaan met onze 10e algemene ledenvergadering. De ALV is <em>het</em> moment om als lid van je te laten horen over wat je waardeert aan de vereniging, en over welke zaken <em>nog</em> beter kunnen. Het bestuur en de commissies zullen toelichting geven op de activiteiten van het afgelopen jaar, en de plannen voor volgend jaar. Tevens zullen twee bestuursleden aftreden, en zijn we dus op zoek naar vervanging.</p>
<p>Draag jij de vereniging een warm hart toe, en wil je meehelpen met zorgen dat we de komende jaren even succesvol blijven als we op dit moment zijn, dan is zo'n bestuurspositie misschien wel het juiste middel om daar invulling aan te geven. We zoeken mensen die zowel zelf het voortouw nemen om verbeteringen door te voeren, als andere vrijwilligers weten te motiveren om dit te doen, en bij dit alles ook kritisch blijven controleren dat de dingen die we doen blijven passen bij onze missie en het geheel aan bestaande Fronteers-activiteiten.</p>
<p>Agenda, locatie en tijdstip van de ALV volgen uiterlijk de week voor de ALV. (Waarschijnlijk wederom Utrecht, 19:00.) Als je vragen, opmerkingen en/of voorstellen voor de ALV hebt, of je je aan wilt melden als potentieel bestuurslid, [neem dan contact met ons op](/contact. (Een kort en bondige toelichting waarom je in het bestuur zou willen plaatsnemen wordt op prijs gesteld. Je zal in de gelegenheid worden gesteld in een blogpost je kandidatuur toe te lichten.)</p>
</content>
</entry>
<entry>
<title>Bijeenkomst over toegankelijkheid met Karl Groves</title>
<link href="https://www.fronteers.nl/nl/blog/2016/10/bijeenkomst-over-toegankelijkheid-met-karl-groves"/>
<updated>2016-10-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/10/bijeenkomst-over-toegankelijkheid-met-karl-groves</id>
<content xml:lang="nl" type="html"><p>We zijn blij te kunnen melden dat we op 8 november een bijeenkomst over toegankelijkheid zullen hosten, met als eerste spreker niemand minder dan ex-congresspreker <a href="http://www.karlgroves.com/">Karl Groves</a>. Zet 'm dus vast in je agenda, of [meld je aan](/bijeenkomsten/2016/toegankelijkheid.</p>
<p>Karl Groves stal eerder dit jaar de show bij Fronteers Spring Conference met zijn talk <a href="https://fronteers.nl/congres/2016-spring/sessions/to-hell-with-performance-by-karl-groves">To hell with performance</a>, over toegankelijkheid en performance. In november zal hij het hebben over hoe je met <em>JavaScript</em> meer toegankelijkheid kunt bereiken.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2016/karl.jpg" alt="Karl Groves" /></p>
<p><em>Karl Groves eerder dit jaar bij Fronteers Spring Conference in Amsterdam</em></p>
<p>De bijeenkomst vindt plaats in Desmet Studio's, nabij Artis in Amsterdam.</p>
</content>
</entry>
<entry>
<title>20% korting op de ReactNL conferentie, 13 oktober 2016 in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2016/10/20-procent-korting-reactnl"/>
<updated>2016-10-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/10/20-procent-korting-reactnl</id>
<content xml:lang="nl" type="html"><p>Op 13 oktober 2016 organiseert Xebia ReactNL in ‘t Sieraad te Amsterdam. Leden van Fronteers ontvangen 20% korting op de conference day.</p>
<h2>Deep-dive in React</h2>
<p>ReactNL is de conferentie om bij te wonen als je als developer technische kennis wilt verdiepen. ReactNL biedt naast talks, ook hands-on workshops door nationale en internationale sprekers van o.a. Zalando, Facebook en Microsoft.
Het volledige programma vind je <a href="http://reactnl.org/#program">op de ReactNL website</a>.</p>
<h2>Enkele onderwerpen die tijdens ReactNL aan het licht komen zijn</h2>
<ul>
<li><a href="https://flowtype.org/">flow type checking</a></li>
<li><a href="http://elm-lang.org/">elm</a></li>
<li><a href="https://facebook.github.io/reason/">Reason</a></li>
</ul>
<p><img src="https://www.fronteers.nl/_img/blog/2016/photo00138.jpg" alt="" /></p>
<h2>React Training - Full Access</h2>
<p>Voor developers die voorafgaand aan de conferentie hun React kennis extra willen ontwikkelen is op 12 oktober een technische hands-on training.</p>
<p>Die dag leer je onder andere:</p>
<ul>
<li>React te gebruiken in een bestaande applicatie</li>
<li>Custom React componenten te creëren</li>
<li>Een React applicatie op de juiste manier vorm te geven</li>
<li>React applicatie te koppelen met een back-end</li>
</ul>
<h2>Ledenkorting</h2>
<p>De korting is geldig op een <a href="https://www.eventbrite.com/e/reactnl-tickets-25828372357#tickets">conferentie ticket</a>.</p>
<h2>Deelnemen?</h2>
<p>Neem dan voor de kortingscode contact op met <a href="mailto:wgreve@xebia.com">Wendy Greve</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst met Val Head en Seb Lee-Delisle</title>
<link href="https://www.fronteers.nl/nl/blog/2016/09/bijeenkomst-met-val-head-en-seb-lee-delisle"/>
<updated>2016-09-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/09/bijeenkomst-met-val-head-en-seb-lee-delisle</id>
<content xml:lang="nl" type="html"><p>Op 19 oktober aanstaande organiseert WestVisions.de hun eerste bijeenkomst, net over de grens in Duisburg.</p>
<p><a href="http://westvisions.de/en/index.php">WestVisions.de</a> is een nieuw evenement voor de digitale community in het Ruhrgebied, zoals ze zelf zeggen. En met deze kick-off meetup leggen ze de lat voor zichzelf gelijk hoog, want ze hebben twee internationaal gerenommeerde sprekers uitgenodigd, Val Head en Seb Lee-Delisle.</p>
<p>Val Head is een ontwerper en (web)animatie consultant. Ze geeft workshops bij bedrijven en conferenties over de hele wereld over 'motion design for the web'. Het is dus ook niet verrassend dat Val's talk als titel 'Designing Meaningful Animation' heeft.</p>
<p>Seb Lee-Delisle's presentatie heeft als titel 'The ART of creative coding'. Seb is een digitale kunstenaar en spreker die code en computers gebruikt om installatie's te maken waar zijn publiek mee kan interacteren en spelen. Wie Seb eerder heeft zien spreken weet dat zijn presentaties altijd verrassend, erg humoristisch en leerzaam zijn.</p>
<p>De bijeenkomt is gratis en er zijn snacks en drinks voor- en achteraf! Wil je meer weten over WestVisions.de en deze bijeenkomst of wil je je aanmelden? Ga dan naar <a href="http://westvisions.de/en/">WestVisions.de</a>.</p>
</content>
</entry>
<entry>
<title>Ledenraadpleging: wat te doen met ons geld?</title>
<link href="https://www.fronteers.nl/nl/blog/2016/09/ledenraadpleging-wat-te-doen-met-ons-geld"/>
<updated>2016-09-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/09/ledenraadpleging-wat-te-doen-met-ons-geld</id>
<content xml:lang="nl" type="html"><p>&quot;Zouden we onze vrijwilligers moeten betalen?&quot;
&quot;Zijn het dan nog wel vrijwilligers?&quot;</p>
<p>&quot;Wat nou als we ze niet direct betalen, maar met verenigingsgeld een donatie aan een goed doel doen dat zij mogen uitkiezen?&quot;
&quot;Maar gaan de niet-vrijwilligende leden wel blij zijn dat hun contributie <em>zo</em> wordt uitgegeven?&quot;</p>
<p>&quot;Misschien moeten we het congres veel goedkoper maken voor leden?&quot;
&quot;Wordt dan niet <em>iedereen</em> lid, alleen voor de congreskorting?&quot;</p>
<p>Je merkt het, wij - het bestuur - weten het niet; of tenminste, we zijn (nog) niet eensgezind. Maar we hebben wel het idee dat we onze inkomsten nuttiger moeten gebruiken dan jaar na jaar onze reserves verder opvullen. We hebben minimaal 1 idee waar we met z'n allen positief over zijn (meer budget beschikbaar stellen voor onze bijeenkomsten, om ze naar een hoger segment te laten doorgroeien, met hopelijk <em>ook</em> minder tijd en regelwerk gemoeid met de organisatie ervan). Maar een aantal van de andere ideeën die we hebben zijn dusdanig radicaal dat we daar eerst toestemming aan de ALV voor zouden moeten vragen. Ter voorbereiding daarvan, en in de hoop dat discussie hier ons gaat helpen tot consensus te komen, willen we graag wat mogelijke concepten met jullie delen, en horen wat <em>jullie</em> er van vinden.</p>
<p>Allereerst dus dat betalen van onze vrijwilligers. <em>Zonder</em> vrijwilligers zou de vereniging nergens zijn. We proberen ze ieder jaar te bedanken met een leuk zeiluitje, en af en toe nog eens iets extras, maar niet iedereen is in de gelegenheid mee te gaan zeilen, en er zitten vrijwilligers tussen die <em>zo</em> veel doen dat je ze als dank iedere maand wel op een luxe cruise wil sturen. De uren die ze erin steken is elk financieel gebaar meer dan waard. Maar het voelt (in ieder geval voor sommige bestuursleden) ook erg krom. Vrijwilligen doe je omdat de vereniging je aan het hart gaat, omdat de contacten met mede-front-enders super leuk en waardevol zijn, etc - niet omdat je er voor betaald wordt.</p>
<p>Aan de andere kant, als je er voor betaald wordt, dan ben je misschien wat sneller geneigd om ook wat meer van de minder leuke klusjes op te pakken, en dan kan je misschien wat meer erop worden aangesproken als je iets niet doet waarvan je beloofd had dat je het zou gaan doen. Maar kom op zeg, je wil toch geen halve werknemer van de vereniging worden?! (En dan hebben we het nog niets eens over &quot;Wie bepaalt wie genoeg doet voor zo'n beloning?&quot; en hoe scheef dit alles kan overkomen op vrijwilligers uit het verleden, zoder wie we onze huidige luxe positie nooit zouden hebben bereikt.)</p>
<p>We kunnen ook op andere manieren onze vrijwilligers bedanken. Laten we ze op cursussen sturen die ze helpen met het uitvoeren van hun taken voor de vereniging. De congrescommissie is zo <a href="https://www.fronteers.nl/blog/2016/05/fronteers-ging-naar-confconf">eerder dit jaar naar ConfConf gegaan</a>. Dat is iig een concept waar we met z'n allen achter staan. Maar meer van dat soort geschikte en nuttige gelegenheden lijken niet direct voor het oprapen te liggen. Moeten we desondanks daar al onze energie in gaan steken, en dat luider en breder bekend maken onder onze vrijwilligers?</p>
<p>Of toch die donaties aan een goed doel?</p>
<p><em>Waarom willen we uberhaupt iets op dit gebied?</em> De vereniging doet het op financieel gebied goed. <em>Te</em> goed! De meeste van onze activiteiten zijn zelfbedruipend, de weinige echte kosten die we hebben worden ruimschoots gedragen door onze lidmaatschapsinkomsten, en daar bovenop stroomt het geld binnen via onze vacaturebank. In 2012 <a href="https://www.fronteers.nl/blog/2012/11/financien-en-reserves-van-fronteers">hebben we besloten</a> onze inkomsten te gebruiken om een aantal reserves op te bouwen om de continuïteit van de vereniging op de langere termijn te kunnen garanderen, maar daar beginnen we zo stilletjes aan ook wel aan te komen. Bovendien lopen we gevaar belasting te moeten gaan betalen door te veel inkomsten en te weinig uitgaven, en we zouden nalatig zijn als we niet proberen dat geld te besteden aan iets dat beter bij de missie van Fronteers past, waarbij het onze vrijwilligers zijn die helpen die missie tot uitvoering te brengen.</p>
<p>Aan de andere kant, dit is dus wel verenigingsgeld, dus we kunnen ook proberen alle leden van de vereniging zo veel mogelijk baat te laten hebben bij ons huidige overschot aan inkomsten, door de kosten van zowel congres als workshops naar beneden bij te stellen.</p>
<p>De reden dat we in het verleden huiverig zijn geweest om dit te doen, is dat de korting die je op congres en workshops krijgt nu al groter is dan de contributie. Het is op dit moment nog niet echt de moeite waard om even snel lid te worden om deel te gaan nemen aan een activiteit, maar als de korting nog groter wordt, dan gaat dat veranderen, en onze vrijwilligers die de communicatie over deze activiteiten afhandelen hebben nu vaak al hun handen vol met after-the-fact pogingen tot dat soort acties (waarbij overal uitgespelde voorwaarden over de spelregels die we daarbij hanteren gewoon niet worden gelezen). En weet je, de tijd van die vrijwilligers, die is ons toch wel erg veel waard...</p>
<p>Misschien dan maar de inkomsten uit de vacaturebank gebruiken om het congres en de workshops te 'sponsoren' en ze voor iedereen - inclusief niet-leden - goedkoper te maken?</p>
<p><em>Moet het lidmaatschapsgeld dan niet gewoon omlaag?</em> Tja, we zullen dat dit jaar wederom voorleggen aan de ALV, zoals we om de paar jaar doen, maar de verwachting is dat de ALV voorstander zal zijn van het handhaven van het huidige niveau, met de redenering dat een minimale drempel van dit niveau zin heeft om een lidmaatschap iets te laten zijn dat alleen wordt overwogen door mensen die serieus bezig zijn met front-end, en specifiek de meerwaarde van het bestaan van Fronteers zien.</p>
</content>
</entry>
<entry>
<title>Win een kaartje voor PFCongres</title>
<link href="https://www.fronteers.nl/nl/blog/2016/09/win-een-kaartje-voor-pfcongres"/>
<updated>2016-09-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/09/win-een-kaartje-voor-pfcongres</id>
<content xml:lang="nl" type="html"><p><a href="http://www.pfcongres.nl/">PFCongres</a> is na drie jaar terug! Op 15 oktober wordt een nieuwe editie van dit web development congres georganiseerd, en jij kunt er bij zijn. Fronteers mag namelijk twee kaarten verloten onder haar leden!</p>
<h2>Over PFCongres 2016</h2>
<p>PFCongres is een congres over web development in brede zin: zowel front-end als back-end gerelateerde onderwerpen komen aan bod. Een greep uit de talks van dit jaar:</p>
<ul>
<li>Fronteers-lid <em>Jayne Verbeek</em> zal het hebben over ECMAScript 6. Alle moderne browsers ondersteunen het, maar wat is er nieuw aan? En hoe verschilt het eigenlijk van JavaScript?</li>
<li><em>Dimitri van Hees</em> gaat vertellen over de ambitieuze plannen van het Kadaster om het geo data platform van de toekomst te bouwen en zal ingaan op de API die hierbij hoort</li>
<li><em>Stefan Koopmanschap</em> zal spreken over het ontwikkelen van jezelf. Hoe kun je bijblijven in een wereld die snel verandert?</li>
<li>ICT-journalist <em>Brenno de Winter</em> sluit de dag af. Hij zal spreken over security</li>
</ul>
<p>Dit jaar vindt het congres plaats in Utrecht, vlakbij het centraal station.</p>
<h2>Winnen?</h2>
<p>Was je voor vandaag lid van Fronteers en wil je hierbij zijn? Meeloten is zo simpel als hieronder een reactie geven. We kiezen op 1 oktober een winnaar.</p>
<p>Mocht de prijs aan je voorbij gaan, je kunt ook nog <a href="http://www.pfcongres.nl/kaartverkoop/">kaarten kopen</a>.</p>
</content>
</entry>
<entry>
<title>Win de laatste ticket voor Fronteers Conference 2016</title>
<link href="https://www.fronteers.nl/nl/blog/2016/09/win-de-laatste-ticket-voor-fronteers-conference-2016"/>
<updated>2016-09-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/09/win-de-laatste-ticket-voor-fronteers-conference-2016</id>
<content xml:lang="nl" type="html"><p>Alle reguliere toegangskaarten voor het Fronteerscongres zijn uitverkocht. Maar je kunt nog een kaartje winnen!</p>
<p>Op donderdag 29 september organiseert Fronteers een meetup bij Schiphol Group - en verloten we de (enorme) Final Ticket to Fronteers Conference. Die ticket biedt je toegang tot beide dagen van het congres, op donderdag 6 en vrijdag 7 oktober. Buitenkansje!</p>
<p>Winnen? <a href="https://www.fronteers.nl/nl/activiteiten/2016/schiphol">Meld je dan nu aan voor de Fronteers-meetup op Schiphol</a>!</p>
<p><img src="https://www.fronteers.nl/_img/congres/2016/schiphol-meetup-final-ticket-promo.jpg" alt="Promotie-illustratie voor Schiphol-meetup van Fronteers" /></p>
</content>
</entry>
<entry>
<title>Eerste onderwerpen en data workshops bekend</title>
<link href="https://www.fronteers.nl/nl/blog/2016/08/eerste-onderwerpen-en-data-workshops-bekend"/>
<updated>2016-08-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/08/eerste-onderwerpen-en-data-workshops-bekend</id>
<content xml:lang="nl" type="html"><p>De afgelopen weken hebben we ons best gedaan om de kalender voor dit najaar te vullen met workshops. Dat is gelukt! Niet alleen hebben we een divers aanbod aan workshops, we gaan met de workshops ook naar een nieuwe locatie in Utrecht (en kijken naar onder andere Den Haag voor 2017).</p>
<h2>Workshops 2016</h2>
<p>De volgende workshops vinden dit najaar plaats:</p>
<table>
<thead>
<tr>
<th>Workshop</th>
<th>Docent</th>
<th>Datum</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="https://www.fronteers.nl/workshops/advanced-sass-roy-tomeij/">Advanced Sass</a></td>
<td>Roy Tomeij</td>
<td>29 september</td>
</tr>
<tr>
<td><a href="https://www.fronteers.nl/workshops/angular-2-rachel-heimbach">Angular 2</a></td>
<td>Rachèl Heimbach</td>
<td>20 oktober</td>
</tr>
<tr>
<td><a href="https://www.fronteers.nl/workshops/html-css-frances-de-waal">HTML/CSS voor beginners</a></td>
<td>Frances de Waal</td>
<td>25 november</td>
</tr>
<tr>
<td><a href="https://www.fronteers.nl/workshops/toegankelijk-bouwen-voor-front-enders-jules-ernst">Toegankelijk bouwen voor webontwikkelaars</a></td>
<td>Jules Ernst</td>
<td>9 december</td>
</tr>
</tbody>
</table>
<p>Bovenstaande data kun je dus vast in je agenda zetten! De kosten voor deze workshops zijn €250,- (Fronteers-leden betalen slechts €150,-).</p>
<p>Je kunt je vanaf nu aanmelden voor alle workshops. De precieze locatie maken we binnenkort bekend, maar ga er vanuit dat die vlakbij station Utrecht Centraal is.</p>
<h2>Nieuwe onderwerpen en leden comissie</h2>
<p>Om dit tempo vast te houden willen we in het najaar de workshops voor 2017 communiceren via de website en social media. Heb jij nog suggesties voor een onderwerp, laat het ons vooral horen door hieronder een reactie achter te laten, een tweet te sturen naar <a href="https://twitter.com/fronteers">@fronteers</a> of benader ons op <a href="https://www.fronteers.nl/nl/blog/2016/02/fronteers-op-slack">Slack</a> of <a href="https://www.fronteers.nl/nl/blog/2016/08/workshops@fronteers.nl">email</a>.</p>
<p>Daarnaast zijn we nog op zoek naar enthousiaste leden die ons workshop-team willen versterken. We zijn op zoek naar front-enders die graag meedenken over de onderwerpen en ons willen ondersteunen met het organiseren van de workshops.</p>
</content>
</entry>
<entry>
<title>Fronteers-(eiland)helpdesk gezocht</title>
<link href="https://www.fronteers.nl/nl/blog/2016/08/fronteers-helpdesk-wecamp-2016"/>
<updated>2016-08-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/08/fronteers-helpdesk-wecamp-2016</id>
<content xml:lang="nl" type="html"><p>Deze zomer combineert Fronteers twee favoriete front-end-activiteiten, namelijk &quot;mooie dingen maken&quot; en &quot;een eiland-uitstapje maken&quot;, in &quot;een eiland-uitstapje maken om mooie dingen te maken&quot;. Fronteersleden die het leuk vinden om een dag of twee deel te nemen aan <em>WeCamp 2016</em>, sturen we namelijk naar het uitverkochte WeCamp-eiland in het Veluwemeer.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2016/wecamp-wider-full.jpg" alt="Luchtfoto van het WeCamp-eiland in het Veluwemeer" /></p>
<p>Van <em>23 tot en met 27 augustus</em> verblijven vijf teams van vijf personen op het eiland om webapplicaties te bedenken, te bouwen en te presenteren, onder begeleiding van coaches. Een snelkookpan voor web-productontwikkeling, maar dan op een eiland. Het evenement is uitverkocht, maar Fronteers mag enkele front-enders inparachuteren* om part-time deel te nemen.</p>
<p>Dat is tof voor front-enders die mee willen doen, meer contacten willen leggen en (eindelijk eens) in de zon willen zitten. Het is ook leuk voor de WeCamp-deelnemers, die vooral uit de back-end/PHP-wereld komen en tijdens hun projecten alles moeten doen inclusief front-end-werk.</p>
<p>Organisator Stefan Koopmanschap legt uit: &quot;We willen meer begrip en front-end-skills triggeren bij de mensen die normaal gesproken daar niet aan gewend zijn. Andersom proberen we de aanwezige front-enders kennis te laten maken met de back-end. Naast techniek zijn <em>soft skills</em> daarom misschien nog wel het belangrijkste waar we aandacht aan besteden. Communicatie met teamleden (die je van te voren misschien nog niet eens kent), planning en presentatie.&quot;</p>
<p>Wil jij een kijkje te nemen op WeCamp en de aanwezige developers, designers en productmanagers van jouw front-end-adviezen voorzien?</p>
<p>Voor <em>donderdag 25 augustus</em> zoeken ze naar 2 front-enders die een hele dag kunnen meedoen, en voor <em>vrijdag 26 augustus</em> zoeken ze 2 mensen die een halve dag raad kunnen geven.</p>
<p>De boot naar WeCamp vertrekt vanuit het haventje bij <em>Landal Waterparc Veluwemeer</em> steeds rond 9:30 's ochtends; je kunt om 13:30 of 16:30 weer terug zijn, maar mee-eten is natuurlijk ook een optie.</p>
<p>Wil je meedoen? Gebruik dan het formulier hieronder om je op te geven, dan neemt Stefan contact met je op. Vermeld de dag(en) waarop je het Veluwemeer op wilt! Alles gratis: de vereniging vergoedt je reiskosten. Er zijn vier plaatsen beschikbaar!</p>
<p>Meer informatie over WeCamp vind je op <a href="http://weca.mp/2016">http://weca.mp/2016</a></p>
<p class="note">
*: We zullen je dus niet letterlijk inparachuteren, je gaat netjes met de boot. Safety first.
</p>
</content>
</entry>
<entry>
<title>Webrichtlijnen en nieuwe internationale regels: wat gaat er gebeuren?</title>
<link href="https://www.fronteers.nl/nl/blog/2016/07/webrichtlijnen-en-nieuwe-internationale-regels-wat-gaat-er-gebeuren"/>
<updated>2016-07-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/07/webrichtlijnen-en-nieuwe-internationale-regels-wat-gaat-er-gebeuren</id>
<content xml:lang="nl" type="html"><p>Dankzij een aantal internationale ontwikkelingen is toegankelijkheid voor mensen met een beperking recentelijk hoger op de agenda komen te staan. Dat is dus goed nieuws!</p>
<p>Zo is er een EU-richtlijn opgesteld voor de toegankelijkheid van digitale dienstverlening door overheidsorganisaties. Het doel hiervan is harmonisatie van de toegankelijkheidseisen binnen de EU en -mede daardoor- een verbetering van de algehele toegankelijkheid van digitale dienstverlening in de EU.</p>
<p>Ook is onlangs het VN-verdrag inzake de rechten van personen met een handicap door Nederland geratificeerd.</p>
<p>Wat betekent dit alles voor web developers in Nederland? Moeten we de <a href="http://versie2.webrichtlijnen.nl/norm/20110701/">Webrichtlijnen</a> blijven volgen of niet? Op dit moment staat Webrichtlijnen versie 2 nog op de 'Pas toe of leg uit’-lijst voor overheidswebsites. Dit betekent dat overheden de Webrichtlijnen moeten toepassen, en anders moeten uitleggen waarom dat niet lukt.
De komende periode moet duidelijk worden wat de nieuwe eisen precies gaan worden.</p>
<p>Een overzicht van de stand van zaken:</p>
<h2>EU-richtlijn voor de toegankelijkheid van overheidswebsites</h2>
<p>Op 3 mei 2016 is er een akkoord bereikt tussen de Raad van de Europese Unie en het Europees Parlement over een richtlijn voor de toegankelijkheid van digitale kanalen van alle overheidsorganisaties. Deze richtlijn geldt voor websites, mobiele apps, intranetten en extranetten. De richtlijn moet de komende jaren worden omgezet in nationale wetgeving in de lidstaten.</p>
<h2>Europese standaard EN 301 549</h2>
<p>De <a href="http://mandate376.standards.eu/standard">EN 301 549</a> betreft een inkoopstandaard die deel uitmaakt van een Europese richtlijn voor aanbesteding van overheidsopdrachten voor ICT producten en diensten. Behalve voor websites geldt deze standaard ook voor non-web documenten, non-web software (zoals mobiele apps) en hardware.</p>
<p>Deze Europese standaard moet worden omgezet in wetgeving voor 2018. Tot die tijd is het plan de Webrichtlijnen zoals die nu op de 'Pas toe of leg uit' - lijst staan, te vervangen door de EN 301 549. Dit wil de Nederlandse overheid doen om alvast aan te sluiten bij Europese ontwikkelingen, zodat internationale of Europese leveranciers met gelijke eisen per land te maken hebben.</p>
<p>Om deze vervanging te kunnen organiseren, zijn echter wat aanpassingen nodig op de huidige 'Pas toe of leg uit' -lijst. Voor het web gedeelte van de Europese standaard gaat WCAG 2.0 AA gelden, net als nu in binnen de Webrichtlijnen. Dit vormt dus geen probleem. Maar de Webrichtlijnen bevatten ook het ‘<a href="http://versie2.webrichtlijnen.nl/norm/20110701/#universal-nl">Principe Universeel</a>’. Dit zijn richtlijnen die gaan over hoe de website is opgebouwd. Denk aan zaken als semantische opmaak en gelaagd bouwen. Omdat dit niet in de Europese standaard zit, zal dit een aparte standaard moeten worden die alleen voor Nederland geldt, los van de Europese toegankelijkheidseisen.</p>
<p>Deze kwestie is onlangs besproken in een consultatie van een groep Nederlandse experts. Binnen deze groep zijn de meningen vooralsnog verdeeld over wat er precies met het Principe Universeel moet gebeuren: geheel weglaten, er een aanbevolen standaard van maken, of -zoals nu- een verplichte standaard? Wel is de groep het er over eens dat het Principe Universeel gemoderniseerd moet worden, omdat deze niet meer goed aansluit bij de praktijk. Een voorbeeld hiervan is het huidige gebruik van JavaScript via bijvoorbeeld AngularJS en React t.o.v. de richtlijn dat content en gedrag gescheiden moeten worden aangeboden. Hiervoor zal dan dus doorontwikkeling en beheer voor opgezet moeten worden. Om in lijn te blijven met de EN 301 549 zal deze standaard dan ook moeten worden uitgebreid met richtlijnen voor non-web software.</p>
<h2>Ratificatie van het VN-verdrag inzake de rechten van personen met een handicap</h2>
<p>Op 14 juni 2016 is dit VN-verdrag in Nederland in werking getreden. Dit verdrag verplicht lidstaten maatregelen te nemen voor het garanderen van toegankelijke ICT. Dit verdrag geldt algemeen, dus niet alleen voor overheden maar ook voor bedrijven. Het nakomen van dit verdrag is mogelijk door het toepassen van EN 301 549.</p>
<h2>Laat je mening horen</h2>
<p>Heb je ideeën over bijvoorbeeld de doorontwikkeling van het Principe Universeel? Deel deze dan met ons, bijvoorbeeld via <a href="https://fronteers-slack.herokuapp.com/">Slack</a>.</p>
<p>Binnenkort volgt er vanuit de Nederlandse overheid een openbare consultatie over de invoering van de nieuwe standaard ter vervanging van de Webrichtlijnen. Iedereen kan hier een reactie op insturen. Houdt de website <a href="https://www.digitoegankelijk.nl/">www.digitoegankelijk.nl</a> in de gaten voor meer informatie.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst over Progressive Web Apps bij Mirabeau in Rotterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2016/07/bijeenkomst-mirabeau"/>
<updated>2016-07-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/07/bijeenkomst-mirabeau</id>
<content xml:lang="nl" type="html"><p>Op 18 augustus organiseert Fronteers een bijeenkomst in Rotterdam over Progressive Web Apps, met Daniel Appelquist en Niels Leenheer.</p>
<p>Service Workers, push notifications, background sync, “Add to homescreen”, fijne UX en toegankelijkheid: allemaal zaken die een web app een stuk beter kunnen maken. Onder de naam “Progressive Web Apps” wordt deze verzameling van open standaarden en best practices nu gepromoot door een aantal grote webbedrijven. Onder andere Google, Microsoft, Opera, Samsung en Mozilla zijn enthousiast over PWAs. Het doel? Zorgen dat web apps minstens zo goed worden als native apps.</p>
<p>We hebben twee sprekers bereid gevonden over dit onderwerp te komen spreken. Daniel Appelquist werkt voor Samsung Internet (de browser op Samsung telefoons en brillen) en is voorzitter van W3C's <a href="https://www.w3.org/2001/tag/">TAG</a>. Niels Leenheer is de maker van <a href="http://html5test.com/">HTML5test.com</a> en runt een heel groot <a href="http://html5test.com/devicelab">open device lab</a>.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2016/dan-niels.jpg" alt="" /></p>
<p><em>Dan Appelquist (links) en Niels Leenheer (rechts)</em></p>
<p>De bijeenkomst is in het Engels en zal plaatsvinden bij Mirabeau in Rotterdam, vlak naast Rotterdam Centraal in het Groothandelsgebouw.</p>
<p><a href="https://www.fronteers.nl/bijeenkomsten/2016/mirabeau">Meld je nu aan</a>, want er is slechts plek voor 60 enthousiaste dames en heren!</p>
</content>
</entry>
<entry>
<title>Nieuwe leden workshopcommissie en onderwerpen workshops gezocht</title>
<link href="https://www.fronteers.nl/nl/blog/2016/07/nieuwe-leden-workshopcommissie-onderwerpen-gezocht"/>
<updated>2016-07-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/07/nieuwe-leden-workshopcommissie-onderwerpen-gezocht</id>
<content xml:lang="nl" type="html"><p>Deze week heeft Fronteers afscheid genomen van haar workshopcommissie. We bedanken Joël, Mirella, Arjan en Michael van harte voor hun werk de afgelopen jaren. Dankzij jullie hebben een hoop front-enders een te gekke workshop kunnen bijwonen!</p>
<p>Er is ook een nieuwe workshopcommissie opgestaan, met daarin voorlopig Sharon Martens en Hidde de Vries. Het nieuwe team is van plan dit najaar te komen met vier workshops, en wil in 2017 regulier (maandelijks of tweemaandelijkse) namens Fronteers workshops gaan organiseren. De planning voor alle vier de workshops kondigen we begin augustus aan via de website en social media van Fronteers.</p>
<h2>Suggesties welkom</h2>
<p>Wil je meer leren over tooling, preprocessors, Angular, toegankelijkheid, webtypografie of ES6? We hebben een voorlopige lijst met onderwerpen in gedachten, maar horen graag over welk onderwerp jullie een workshop willen volgen. Laat dit dus vooral horen door hieronder een reactie achter te laten, een tweet te sturen naar <a href="https://twitter.com/fronteers">@fronteers</a> of benader ons <a href="https://www.fronteers.nl/nl/blog/2016/02/fronteers-op-slack">op Slack</a> of <a href="mailto:workshops@fronteers.nl">email</a>.</p>
</content>
</entry>
<entry>
<title>Verplichting &quot;Principe Universeel&quot; kan komen te vervallen bij vervanging Webrichtlijnen</title>
<link href="https://www.fronteers.nl/nl/blog/2016/06/vervallen-verplichting-principe-universeel"/>
<updated>2016-06-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/06/vervallen-verplichting-principe-universeel</id>
<content xml:lang="nl" type="html"><p>Enige tijd geleden is een Europese standaard voor de toegankelijkheid van ICT-producten en -diensten ontwikkeld. Deze standaard is op veel punten breder dan de webrichtlijnen, maar bevat net als de webrichtlijnen heel WCAG 2. Het Forum Standaardisatie is <a href="https://www.digitoegankelijk.nl/actueel/nieuws/2016/06/09/aanpassingsverzoek-webrichtlijnen-naar-forum-standaardisatie">een procedure gestart</a> om de verplichting (op overheidswebsites) voor het gebruik van de Webrichtlijnen te vervangen met de verplichting voor het gebruik van de nieuwe Europese standaard.</p>
<p>Een punt waar de webrichtlijnen verder gaan dan de nieuwe Europese standaard, is op het gebied van waarborgen van &quot;bouwkwaliteit&quot;, samengevat in het <a href="https://www.accessibility.nl/kennisbank/webrichtlijnen2/principe-universeel/">&quot;Principe Universeel&quot;</a>. In dit principe worden fundamentale best practices op het gebied van website-bouw verenigd:</p>
<ul>
<li>Semantisch: Pas technologieën voor webcontent op betekenisvolle wijze toe</li>
<li>Gescheiden: Scheid content van presentatie en van gedrag</li>
<li>Bouw gelaagd: Borg de beschikbaarheid van basiscontent en -functionaliteit</li>
<li>Foutmeldingen: Zorg voor bruikbare foutmeldingen</li>
<li>Formulieren: Maak formulieren optimaal bruikbaar</li>
<li>Meertaligheid: Maak anderstalige content eenvoudig bereikbaar</li>
<li>Geneste weergavekaders: Sluit niemand uit bij het aanbieden van content middels geneste weergavekaders</li>
<li>Identificatie van tekens en symbolen: Specificeer karaktercodering</li>
<li>Openheid: Veroorzaak geen belemmeringen bij de creatie, publicatie en uitwisseling van content</li>
<li>URI's: URI's dienen duidelijk, uniek en duurzaam te zijn</li>
</ul>
<p>Het Forum Standaardisatie heeft een <a href="https://www.logius.nl/fileadmin/os/Vergaderstukken/FS_160608.3C_Intakeadvies_wijziging_Webrichtlijnen.pdf">intakeadvies (PDF)</a> geschreven, waarin wordt uitgelegd dat dit Principe Universeel niet als &quot;extra laag&quot; bovenop de Europese standaard kan worden gelegd, dus naar een zelfstandige standaard afgesplitst moet worden. Vervolgens wordt aangeraden om deze nieuwe standaard niet de huidige status &quot;verplicht&quot; (&quot;pas toe of leg uit&quot;) te geven, maar om dit te verlichten naar &quot;aanbevolen&quot;, omdat deze criteria &quot;onnodig verzwarend werken&quot;.</p>
<p>Twee relevante quotes vanuit het intakeadvies:</p>
<blockquote>
<p>Het verminderen van de verplicht toe te passen richtlijnen en criteria, komt tegemoet aan de in de praktijk veel geuite klacht dat er ‘zoveel criteria’ moeten worden toegepast. Naar alle waarschijnlijkheid kan dit ook op instemming rekenen van belangenorganisaties. Deze hebben eerder aangegeven dat de extra eisen voor bouwkwaliteit onnodig verzwarend werken op de implementatie van de toegankelijkheidseisen en gepleit om de verplichting te beperken.</p>
</blockquote>
<blockquote>
<p>De praktijk laat zien dat de bouwkosten van een website die aan de Webrichtlijnen versie 2 voldoet niet of niet substantieel hoger zijn. De verwachting is dat hetzelfde geldt voor EN 301 549. De inspanning om hieraan te voldoen is daarmee niet veel groter. Dit is mede afhankelijk van de deskundigheid van de ingehuurde ontwikkelaars en hoe de kwaliteitszorg is ingericht. De exploitatie-kosten van een website die aan de Webrichtlijnen voldoet zijn lager dankzij minder complexiteit, eenvoudiger onderhoud en de mogelijkheid om content te hergebruiken.</p>
</blockquote>
<p>Fronteers is uitgenodigd om op 7 juli aanwezig te zijn bij een expertbijeenkomst over dit onderwerp, waarbij Janita Top ons zal vertegenwoordigen. In een eerste inventarisatie zijn wij van mening dat het een slechte zaak zou zijn om het Principe Universeel zo te laten degraderen. Wij als professionele front-end ontwikkelaars zien deze criteria helemaal niet als verzwarend, maar juist als een beschrijving van minimale kwaliteit. Fronteers-leden die bij overheidsorganisaties betrokken zijn merken dat het <em>juist</em> de regels uit Principe Universeel zijn waarop evident broddelwerk van externe leveranciers kan worden afgekeurd. Ook het punt over de exploitatie-kosten uit het intakeadvies komt naar ons inziens voornamelijk voort uit de punten van het Principe Universeel, niet uit de WCAG 2 regels.</p>
<p>We horen graag van onze leden of jullie het eens zijn met dit standpunt, alsmede mogelijke argumenten om aan Janita mee te geven naar de expertbijeenkomst om het belang van het verplicht houden van deze richtlijn mee te kunnen beargumenteren.</p>
</content>
</entry>
<entry>
<title>Fronteers ging naar ConfConf</title>
<link href="https://www.fronteers.nl/nl/blog/2016/05/fronteers-ging-naar-confconf"/>
<updated>2016-05-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/05/fronteers-ging-naar-confconf</id>
<content xml:lang="nl" type="html"><p>Als je kennis wilt opdoen en beter wilt worden in je vak, kun je als front-ender naar front-end-congressen gaan. Maar waar ga je heen als je front-end-congressen organiseert en dáár beter in wilt worden? Naar een congressencongres natuurlijk.</p>
<p>Cat Hunter en Ben MacGowan organiseerden in Bristol op 20 mei voor de tweede keer zo'n congressencongres, met de toepasselijke naam <a href="http://conf-conf.com/">ConfConf</a>.</p>
<h2>Doel</h2>
<p>Vrijwilligers van Fronteers organiseren dit jaar in oktober intussen voor de negende keer het Fronteerscongres. Daarnaast organiseerden we op 1 april voor het eerst <a href="https://www.fronteers.nl/congres/2016-spring">Fronteers Spring Conference</a>.</p>
<p>Ondanks dat we dit al een behoorlijke poos doen, zijn we natuurlijk nooit te oud om te leren en verbeteren. Op 20 mei gingen we daarom met een kleine delegatie naar Bristol om ons steentje bij te dragen en veel te leren.</p>
<blockquote>
<p>&quot;ConfConf aims to challenge industry perspectives and recurring criticisms that plague tech events, providing a platform for open debate and discussion on matters such as diversity, inclusivity, enabling new talent and the current event landscape.&quot;</p>
</blockquote>
<p>Precies goed, dachten wij, voor de congressen en voor Fronteers. Met het bestuur spraken we af dat Fronteers de kosten voor de reis en tickets op zich zou nemen.</p>
<h2>Het congres</h2>
<p>De congresdag bestond uit vier talks en twee paneldiscussies. De sprekers dit jaar waren Marc Thiele (Beyond Tellerand), John Davey (Reasons To), Rachel Andrew (oud-Fronteers Conference-spreker) en Cat Hunter (Smashing Conference).</p>
<p>We hoorden interessante parallellen met wat wij proberen te doen bij Fronteers Conference: duidelijk communiceren met sprekers, altijd vriendelijk zijn tegen bezoekers en leveranciers, video's na afloop gratis beschikbaar maken en de registratie in de congresmorgen zo eenvoudig en snel mogelijk laten verlopen.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2016/thijsthomas.jpg" alt="Twee mannen met ConfConf badges" /></p>
<p>Er kwamen ook dingen die wij juist niet deden: sommige organisatoren vertelden bijvoorbeeld over hun uitgebreide marketingstrategieën. En er werd veel gesproken over het benaderen van sponsoren. Omdat wij de afgelopen jaren vrij vlot zijn uitverkocht, zijn wij in een ware luxepositie beland. Onze focus kan daardoor veel meer op de inhoud liggen.</p>
<p>De talk van Rachel Andrew was een hele interessante aanvulling op de feedback die we soms in de sprekersauto en op de wandelgangen van sprekers krijgen. Met tientallen congressen per jaar is Rachel met recht een ervaringsdeskundige te noemen.</p>
<p>In de panels, de pauzes tussen de talks en de receptie na afloop was er voldoende ruimte om kennis te maken met de andere congresorganisatoren. We wisselden een hoop ervaringen uit.</p>
<h2>Conclusie</h2>
<p>We hebben veel geleerd van de anderen, en er werd driftig meegeschreven. Ook konden we zelf wat van onze kennis delen. Het was dus al met al een interessante dag voor de Fronteers-delegatie. Die zal het geleerde vast snel in de praktijk brengen voor <a href="https://www.fronteers.nl/congres/2016">Fronteers Conference 2016</a>, waarvoor de verkoop voor de eerste batch kaartjes morgen (!) start.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2016/joelhidde.jpg" alt="Een deel van de Fronteers-delegatie, lopend op straat" /></p>
<p><em>Discussie over BEM, onderweg naar de congreslocatie.
V.l.n.r.: Anneke, Joël, Thomas, Hidde</em></p>
</content>
</entry>
<entry>
<title>Fronteers 2016 launchborrel + livegang kaartverkoop op 27 mei</title>
<link href="https://www.fronteers.nl/nl/blog/2016/05/fronteers-2016-launchborrel-livegang-kaartverkoop-27-mei"/>
<updated>2016-05-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/05/fronteers-2016-launchborrel-livegang-kaartverkoop-27-mei</id>
<content xml:lang="nl" type="html"><p>De kaartverkoop voor het Fronteerscongres 2016 start vrijdag 27 mei om 20:00 uur. Om dit te vieren, organiseert Fronteers die avond vanaf 19:00 uur een speciale launchborrel bij Café De Jaren in Amsterdam - en jij bent van harte uitgenodigd.</p>
<h2>TL;DR</h2>
<ul>
<li>Fronteers Conference 2016 Launchborrel</li>
<li>Vrijdag 27 mei, Café De Jaren, Amsterdam</li>
<li>Borrel 19:00u, livegang ticket sales 20:00u</li>
<li>RSVP via <a href="https://www.fronteers.nl/nl/activiteiten/2016/fronteers-2016-launchborrel">het formulier</a></li>
</ul>
<h2>Livegang</h2>
<p>Net als vorig jaar zal de congrescommissie aanwezig zijn om eventuele vragen te beantwoorden. Maar het gaat natuurlijk om de kaarten voor het congres (en de gezelligheid). Vanaf 20:00 uur gaat de ticketshop weer met enige bombarie open en kunnen tickets voor het congres op 6 en 7 oktober aangeschaft worden. Komt dat zien!</p>
<h2>Locatie</h2>
<p>Café De Jaren in Amsterdam heet ons hiervoor wederom welkom; een bekende locatie voor congresgangers. De Jaren is prima bereikbaar met het openbaar vervoer. Het NS- en busstation van Amsterdam liggen op circa 15 minuten loopafstand.</p>
<p>Café De Jaren
Nieuwe Doelenstraat 20-22
1012 CP Amsterdam</p>
<h2>RSVP</h2>
<p><a href="https://www.fronteers.nl/nl/activiteiten/2016/fronteers-2016-launchborrel">Meld je aan via het formulier</a> (let op: plaatsen zijn beperkt!) en kom met ons het glas heffen op Fronteers Conference 2016!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst over datavisualisatie bij CLEVER°FRANKE in Utrecht</title>
<link href="https://www.fronteers.nl/nl/blog/2016/05/bijeenkomst-clever-franke"/>
<updated>2016-05-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/05/bijeenkomst-clever-franke</id>
<content xml:lang="nl" type="html"><p>Op donderdag 2 juni is Fronteers te gast bij ‘data-driven design agency’ CLEVER°FRANKE voor een avond over het oplossen van complexe problemen met front-end development en datavisualisatie. Zij zorgen voor bier, eten en snacks, en hebben ruimte voor zo'n 40 geïnteresseerden.</p>
<p>Kom langs als je meer wilt weten over datavisualisatie en hoe je dit als front-end ontwikkelaar kunt aanpakken. Dit is het programma van de avond:</p>
<ul>
<li>18:00 Ontvangst met drankjes en hapjes</li>
<li>18:30 Gert Franke - Lessons learned in building a datavisualization agency</li>
<li>19:15 Pauze</li>
<li>19:30 Jan Hoogeveen - Overcoming complexity and what that means for development</li>
<li>20:15 borrel</li>
</ul>
<p>(<a href="https://www.fronteers.nl/nl/activiteiten/2016/clever-franke">Meer over de talks</a>)</p>
<h2>Voor wie?</h2>
<p>Deze bijeenkomst is toegankelijk voor leden en niet-leden. <a href="https://www.fronteers.nl/bijeenkomsten/2016/clever-franke">Meld je wel even aan</a>, want er is slechts plek voor 40 front-endende dames en heren.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 14 april bij Kabisa</title>
<link href="https://www.fronteers.nl/nl/blog/2016/03/bijeenkomst-kabisa"/>
<updated>2016-03-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/03/bijeenkomst-kabisa</id>
<content xml:lang="nl" type="html"><p>Op donderdag 14 april 2016 is Fronteers te gast bij Kabisa in Weert. Er staan twee sprekers op het programma.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 inloop met dinerbuffet en een drankje</li>
<li>19:00 Matthijs Groen - &quot;JavaScript games bouwen tijdens je lunchpauze&quot;</li>
<li>19:45 korte pauze</li>
<li>20:00 Roy Tomeij - &quot;De toekomst van preprocessors&quot;</li>
<li>20:45 borrel</li>
</ul>
<p>Dit evenement vindt plaats bij Kabisa, Marconilaan 8, 6003 DD Weert. <a href="https://www.fronteers.nl/bijeenkomsten/2016/kabisa">Aanmelden kan via de pagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 40 mannen en vrouwen. Meld je daarom aan via het <a href="https://www.fronteers.nl/nl/activiteiten/2016/kabisa">formulier</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 24 maart 2016 bij iDA Mediafoundry</title>
<link href="https://www.fronteers.nl/nl/blog/2016/03/bijeenkomst-ida-mediafoundry"/>
<updated>2016-03-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/03/bijeenkomst-ida-mediafoundry</id>
<content xml:lang="nl" type="html"><p>Op donderdag 24 maart is Fronteers te gast bij <a href="http://www.ida-mediafoundry.be/">iDA Mediafoundry</a> in Mechelen. Er worden twee presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 Ontvangst met een hapje en een drankje</li>
<li>19:00 Mario Van den Eynde (<a href="https://twitter.com/mariovde">@mariovde</a>) - &quot;From null to full in under 30 minutes&quot;, building a React app.</li>
<li>19:45 Korte pauze</li>
<li>20:00 Johan Ronsse (<a href="https://github.com/wolfr">@wolfr</a>) - &quot;Welcome to <a href="http://bedrock.mono.company/">Bedrock</a>&quot;</li>
<li>20:45 Naborrelen</li>
</ul>
<p>Dit evenement vindt plaats bij iDA Mediafoundry te Mechelen. <a href="https://www.fronteers.nl/bijeenkomsten/2016/ida-mediafoundry">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 80 vrouwen en mannen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Met korting naar het Nationaal Congres Digitale Toegankelijkheid</title>
<link href="https://www.fronteers.nl/nl/blog/2016/03/met-korting-naar-het-nationaal-congres-digitale-toegankelijkheid"/>
<updated>2016-03-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/03/met-korting-naar-het-nationaal-congres-digitale-toegankelijkheid</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 31 mei 2016 vindt het Nationaal Congres Digitale Toegankelijkheid plaats. Leden van Fronteers krijgen 30% korting op de toegangsprijs, eventueel in combinatie met de early-bird korting, die geldt tot 16 maart.</p>
<p>Op het programma staan onder andere: gevolgen van de ratificatie van het VN-verdrag, het accessibility-squad van de ING, pair writing, webstatistieken, webcare, en soft skills voor webwerkers.</p>
<p>’s Ochtends zijn er plenaire sessies. Middags zijn er parallelsessies in kleine groepen. Daarin spijker je je kennis bij en ga je ook zelf aan de slag. Tussendoor is er volop ruimte om collega’s te spreken.</p>
<p>De congreslocatie is Antropia, Driebergen.</p>
<p>Meer informatie: <a href="http://www.ncdt.nl/">www.ncdt.nl</a></p>
<p>Mocht je gebruik willen maken van deze korting, neem dan even contact op met het <a href="https://www.fronteers.nl/nl/vereniging/contact/">bestuur</a>. Zoals gebruikelijk geldt deze actie alleen voor leden die op dit moment al lid zijn.</p>
</content>
</entry>
<entry>
<title>Met korting naar From the Front in Bologna</title>
<link href="https://www.fronteers.nl/nl/blog/2016/03/from-the-front-korting"/>
<updated>2016-03-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/03/from-the-front-korting</id>
<content xml:lang="nl" type="html"><p>Op 15 en 16 september 2016 organiseert From the Front, een Fronteers-achtige organisatie in het noorden van Italië, wederom hun <a href="http://2016.fromthefront.it/">From the Front conference</a>. Fronteers-leden krijgen korting: 20% op de early-birdprijs, en zelfs 25% op de reguliere prijs.</p>
<h2>Programma</h2>
<p>Over het programma is op het moment van schrijven nog weinig bekend, maar ter inspiratie is het misschien interessant om te kijken naar wat ze in <a href="http://2012.fromthefront.it/">2012</a>, <a href="http://2013.fromthefront.it/">2013</a>, <a href="http://2014.fromthefront.it/">2014</a> en <a href="http://2015.fromthefront.it/">2015</a> te bieden hadden.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2016/duso.jpg" alt="Theaterzaal" /></p>
<p><em>Teatro Duse in Bologna. Foto: From the Front</em></p>
<h2>Praktisch</h2>
<p>From the Front is een tweedaags congres en zal plaatsvinden op 15 en 16 september 2016 in het Teatro Duse in Bologna, Italië.</p>
<p>Fronteers-leden krijgen een korting van 20% (early bird) of 25% (reguliere prijs).</p>
<p>Mocht je gebruik willen maken van deze korting, neem dan even contact op met de <a href="https://www.fronteers.nl/nl/vereniging/contact">ledenadministratie</a>. Zoals gebruikelijk geldt deze actie alleen voor leden die op dit moment al lid zijn.</p>
</content>
</entry>
<entry>
<title>Fronteers op Slack</title>
<link href="https://www.fronteers.nl/nl/blog/2016/02/fronteers-op-slack"/>
<updated>2016-02-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/02/fronteers-op-slack</id>
<content xml:lang="nl" type="html"><p>In 2008 is Fronteers begonnen met <a href="https://www.fronteers.nl/nl/blog/2008/03/fronteers-op-irc">een chatkanaal op IRC</a> waar nog steeds dagelijks actief over front-end development gediscussieerd wordt. De laatste twee jaar heeft <a href="https://slack.com/is">Slack</a> als chatkanaal ook de nodige populariteit gewonnen. Niet zo vreemd, want het is erg gebruiksvriendelijk en makkelijk uit te breiden met andere webdiensten — misschien wel het belangrijkste is de animated GIF-integratie met Giphy.</p>
<p>We vonden het daarom tijd voor een Slack kanaal voor Nederlandse front-end developers.</p>
<p>/giphy crazy</p>
<p>De eerste week zijn er al veel leuke gesprekken gevoerd over leuke onderwerpen, van ECMAScript 2015 tot <a href="https://open.spotify.com/album/6lAcQFcvUlYnNhuinzCXsb">het nieuwe album van Scooter</a>. Er zijn een aantal kanalen zoals JavaScript, CSS, webfonts en de Fronteers Spring Conference. Ook worden de laatste tweets van <a href="https://twitter.com/fronteers">@Fronteers</a> en <a href="https://twitter.com/fronteersconf">@FronteersConf</a> gepost, net zoals de laatste berichten van het blog en alle bijeenkomsten.</p>
<p><a href="https://www.fronteers.nl/nl/blog/2008/03/fronteers-op-irc">Het IRC-kanaal</a> blijft natuurlijk gewoon open.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2016/fronteersopslack.jpg" alt="" /></p>
<h2>Aanmelden</h2>
<p>Kan je ook niet wachten om mee te front-end Slacken? Meld je dan aan op <a href="https://join.slack.com/t/fronteersnl/shared_invite/zt-1m0mbjbkh-LyrZgCPr1JzWBeASuTcnog">voor onze Slack</a>.</p>
<p>Leden en niet-leden zijn welkom!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 24 maart bij eVision</title>
<link href="https://www.fronteers.nl/nl/blog/2016/02/bijeenkomst-evision"/>
<updated>2016-02-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/02/bijeenkomst-evision</id>
<content xml:lang="nl" type="html"><p>Op donderdag 24 maart 2016 is Fronteers te gast bij eVision in Den Haag. Er staan twee sprekers op het programma en het thema is React.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 - inloop met pizza</li>
<li>19:00 - Kamil Afşar - &quot;Wat is REACT en waarom is het zo cool&quot;</li>
<li>19:45 - korte pauze</li>
<li>20:00 - Maurice de Beijer - React applicaties en Event Sourcing</li>
<li>We sluiten af met een borrel.</li>
</ul>
<p>Dit evenement vindt plaats bij eVision, Lange Vijverberg 3 in Den Haag. <a href="https://www.fronteers.nl/bijeenkomsten/2016/evision">Aanmelden kan via de pagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 40 mannen en vrouwen. Meld je daarom aan via het <a href="https://www.fronteers.nl/nl/activiteiten/2016/evision">formulier</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Nieuw congres: Fronteers Spring Conference op 1 april</title>
<link href="https://www.fronteers.nl/nl/blog/2016/02/nieuw-congres-fronteers-spring-conference-op-1-april"/>
<updated>2016-02-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/02/nieuw-congres-fronteers-spring-conference-op-1-april</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 1 april organiseert Fronteers een nieuw themacongres in EYE in Amsterdam. We gaan ons een dag lang met 10 interessante sprekers verdiepen in Web Performance onder leiding van Phil Hawksworth. Leden van Fronteers kunnen voordelig deelnemen - én krijgen voorrang.</p>
<p>Dit congres heet <a href="https://fronteers.nl/congres/2016-spring">Fronteers Spring Conference</a>; het is speciaal opgezet als een 'leden-first' aanvulling op ons congresaanbod in oktober. Iedereen is welkom, maar leden van Fronteers krijgen fikse korting én voorrang.</p>
<p>Vandaag start meteen de kaartverkoop op <a href="https://tickets.fronteers.nl/">https://tickets.fronteers.nl</a> en alleen Fronteersleden (die op 3 februari al lid waren) kunnen de eerste kaarten kopen, voor <em>€99 plus BTW</em>. Pas over twee weken kan iedereen een ticket bemachtigen; kaartjes voor niet-leden kosten €199 plus BTW.</p>
<h2>Opzet van de dag</h2>
<p>Met een centraal onderwerp, kortere presentaties en meer (panel-)discussie is de opzet iets anders dan je gewend bent van het congres in oktober.</p>
<p>Het dagthema is Web Performance: Dat betekent dat alle sprekers vanuit hun unieke expertise iets gaan zeggen over het thema, en er ook met elkaar (en jou) over in discussie gaan.</p>
<p>De subonderwerpen lopen uiteen van animatie-tweaks tot accessibility-problemen and van technische optimalisatie tot de performance van single-page web apps.</p>
<p>De dag is ingedeeld in drie blokken van drie presentaties die op elkaar aansluiten. Deze praatjes worden direct achter elkaar gehouden en worden per blok opgevolgd door een paneldiscussie met de sprekers, geleid door een MC.</p>
<h2>Sprekers</h2>
<p>Die MC is niemand minder dan Phil Hawksworth, die al twee keer uitstekend op het Fronteerscongres sprak. Hij houdt de voortgang in de gaten en modereert met jullie vragen de discussies met de sprekers.</p>
<p>We hebben een prachtige verzameling van experts bereid gevonden naar Nederland (terug) te komen. We zijn trots op de lijst tot nog toe:</p>
<ul>
<li>Tobias Baldauf</li>
<li>Marcy Sutton</li>
<li>Karl Groves</li>
<li>Tobias Ahlin</li>
<li>Paul Bakaus</li>
<li>Bram Stein</li>
<li>Yan Zhu</li>
<li>Estelle Weyl</li>
</ul>
<p>Meer over de sprekers en hun presentaties vind je op de congrespagina's, <a href="https://fronteers.nl/congres/2016-spring">https://fronteers.nl/congres/2016-spring</a>.</p>
<h2>Locatie: EYE</h2>
<p>Fronteers Spring Conference vindt plaats in en rond de kolossale Cinema 1-zaal van EYE. <a href="https://www.eyefilm.nl/">EYE, het filmmuseum</a>, ligt aan de oever van 't IJ in Amsterdam, pal achter het Centraal Station.</p>
<p>We zorgen voor Fronteerswaardig lekker eten en een goede koffie/thee-balans zodat ook je eigen Performance tijdens het congres in orde zal zijn.</p>
<h2>Live transcriptie</h2>
<p>Tijdens het congres zorgen we voor live transcriptie van de presentatie. Een gespecialiseerde stenografe maakt ter plekke een transcriptie van de talks in het Engels. Deze transcriptie tonen we op een extra scherm vooraan in de zaal. Daarmee hopen we voor iedereen het evenement nog toegankelijker te maken, en het volgen van onze uitstekende sprekers nog comfortabeler.</p>
<h2>Code of Conduct</h2>
<p>Sinds enkele jaren hanteert Fronteers op congressen een Code of Conduct. Als je naar ons evenement komt, verklaar je je akkoord met die Code en word je er ook aan gehouden.</p>
<p>Het gaat vooral om respect voor elkaar, en om het creëren van een veilige, open omgeving. We zijn erg trots op de bijzondere, vreemde, uiteenlopende en intelligente groep Fronteersleden en -bezoekers, en willen dat iedereen zich comfortabel voelt en blijft voelen.</p>
<p>Bekijk daarom even de Code of Conduct op <a href="https://fronteers.nl/congres/2016-spring/code-of-conduct">https://fronteers.nl/congres/2016-spring/code-of-conduct</a>.</p>
<h2>TL;DR</h2>
<p>Vrijdag 1 april in EYE, een Fronteers-themadag over Web Performance met 10 internationale sprekers. Vanaf vandaag kunnen (alleen) Fronteersleden kaartjes kopen op <a href="https://tickets.fronteers.nl/">https://tickets.fronteers.nl</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 25 februari bij Nucleus</title>
<link href="https://www.fronteers.nl/nl/blog/2016/02/bijeenkomst-nucleus"/>
<updated>2016-02-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/02/bijeenkomst-nucleus</id>
<content xml:lang="nl" type="html"><p>Op donderdag 25 februari 2016 is Fronteers te gast bij Nucleus in Antwerpen. Er worden twee presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met een hapje en een drankje</li>
<li>19:00 Mattias Geniar (<a href="https://github.com/mattiasgeniar">@mattiasgeniar</a>) - &quot;HTTP/2: The Next Version of the Internet&quot;</li>
<li>19:45 korte pauze</li>
<li>20:00 Koen Kivits (<a href="https://github.com/koenkivits">@koenkivits</a>) - &quot;Bowser in de browser&quot;</li>
<li>20:45 naborrelen</li>
</ul>
<p>Dit evenement vindt plaats bij Nucleus te Antwerpen. <a href="https://www.fronteers.nl/bijeenkomsten/2016/nucleus">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Met korting naar CSS Day en/of HTML Special</title>
<link href="https://www.fronteers.nl/nl/blog/2016/02/korting-css-day"/>
<updated>2016-02-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/02/korting-css-day</id>
<content xml:lang="nl" type="html"><p>Op 17 juni 2016 organiseert Web Conferences Amsterdam wederom het congres <a href="http://cssday.nl/2016">CSS Day</a>, dat op 16 juni vooraf wordt gegaan door iets nieuws: HTML Special. Fronteers-leden krijgen korting op beide: 25 euro op een eendagsticket, of 50 euro op een ticket voor beide dagen.</p>
<h2>HTML Special</h2>
<p>Op de HTML Special worden een aantal HTML elementen onder de loep genomen: de sprekers is gevraagd een hele talk te spreken over een specifiek HTML element: Jeremy Keith over de <code>&lt;a&gt;</code>, Simon Pieters over <code>&lt;source&gt;</code> en onze eigen Peter van der Zee over <code>&lt;iframe&gt;</code>. Kortom, een hele dag over de taal waar eigenlijk elke front-ender regelmatig mee te maken heeft.</p>
<h2>CSS Day</h2>
<p>Op het programma van CSS Day staan onder andere Léonie Watson van de Paciello Group, die zal praten over accessibility in CSS (wat betekent het bijvoorbeeld voor screenreaders als je met flexbox de <code>order</code> van je elementen verandert?) en Una Kravets van IBM, met een talk over blend modes (kunnen we Instagram-effecten straks gewoon in CSS?). Ook komt CSS-tovenaar Harry Roberts spreken, onderwerp nog onbekend.</p>
<h2>Praktisch</h2>
<p>HTML Special en CSS Day vinden plaats op respectievelijk 16 en 17 juni 2016, in het Compagnietheater in Amsterdam.</p>
<p>Fronteers-leden krijgen €25 (1 dag) of €50 (2 dagen) korting op de reguliere toegangsprijs. Bij de toegang zijn koffie, lunch, en een drankje na afloop inbegrepen.</p>
<p>Mocht je gebruik willen maken van deze korting, neem dan even contact op met de <a href="https://www.fronteers.nl/nl/vereniging/contact">ledenadministratie</a>.. Zoals gebruikelijk geldt deze actie alleen voor leden die op dit moment al lid zijn.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij TamTam op 24 februari 2016</title>
<link href="https://www.fronteers.nl/nl/blog/2016/01/tamtam"/>
<updated>2016-01-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/01/tamtam</id>
<content xml:lang="nl" type="html"><p>Op woensdag 24 februari 2016 is Fronteers te gast bij TamTam in Amsterdam. Er staan twee sprekers op het programma.</p>
<p>Er wordt gepresenteerd over de mogelijkheden van Modular Design voor developers en over integreren van backend-less development in de workflow van webapplicaties.</p>
<p>Dit evenement vindt plaats bij Tam Tam, Helicopterstraat 25, Amsterdam. <a href="https://www.fronteers.nl/bijeenkomsten/2016/tamtam">Aanmelden kan via de pagina van deze bijeenkomst.</a></p>
<h2>Programma</h2>
<ul>
<li>18:00 - inloop met pizza</li>
<li>19:00 - Simon Colijn - Designing a System of Components</li>
<li>19:45 - korte pauze</li>
<li>20:00 - Nick Groenewegen - Optimizing your Application Workflow using Backendless Development</li>
<li>We sluiten af met een borrel.</li>
</ul>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 75 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Congresvideo's 2015 nu beschikbaar met transcripties en captions</title>
<link href="https://www.fronteers.nl/nl/blog/2016/01/transcripties-en-captions-congres-2015"/>
<updated>2016-01-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/01/transcripties-en-captions-congres-2015</id>
<content xml:lang="nl" type="html"><p>Op de pagina <a href="https://fronteers.nl/congres/2015/sessions">Sessions</a> zijn nu alle video's van Fronteers 2015 te vinden, voorzien van transcripts en captions.</p>
<p>In <a href="https://www.fronteers.nl/congres/2011/sessions">2011</a> en <a href="https://www.fronteers.nl/congres/2012/sessions">2012</a> deden we het al eerder: onze congresvideo's breder toegankelijk maken door ze te voorzien van transcripts en, in 2012, captions. Dit kan een tijdsintensief proces zijn. We gebruikten destijds weliswaar een betaalde dienst, maar de transcripties die werden aangeleverd waren niet in één keer goed, ze werden handmatig gecontroleerd door een groep enthousiaste vrijwilligers.</p>
<h2>Wat zijn het?</h2>
<p><em>Captions</em> zijn in feite een soort uitgebreidere variant ondertitels. Ze bevatten alles wat er gezegd wordt, maar ook beschrijvingen van andere geluiden. Applaus, gelach, muziek, en ook wie er spreekt. Captions bevatten ook tijdsinformatie, zodat ze, in ons geval als WebVTT, op het goede moment onder een video kunnen verschijnen.</p>
<p><em>Transcriptions</em> zijn een tekstueel alternatief voor de video. In ons geval zijn het de in feite gewoon de caption-bestanden, maar dan als geheel uitgeschreven. We plaatsen ze onder elke video, zodat er makkelijk in te zoeken is, en de video ook als tekst te lezen is.</p>
<h2>Waarom?</h2>
<p>Er zijn goede redenen om transcripts en captions te gebruiken. Dit is wie we er bijvoorbeeld mee proberen te helpen:</p>
<ul>
<li>mensen die slecht of niet kunnen horen</li>
<li>mensen die de talks in het Engels wat snel vinden gaan en liever meelezen</li>
<li>mensen die graag CTRL+F'en in een talk, om een specifiek stukje makkelijk terug te vinden</li>
<li>zoekmachines, om beter inzicht te krijgen in onze content</li>
</ul>
<h2>Hoe?</h2>
<p>Dit jaar zijn we opnieuw het proces ingegaan. We gebruikten dit keer <a href="https://amara.org/">Amara</a>, dat tegenwoordig ook wordt aangeboden als optie binnen Vimeo, waar we onze congresvideo's hosten. Dit maakt het één en en ander een stuk makkelijker, want in plaats van URLs verzamelen en doorsturen en handmatig aanvragen klaarzetten, konden we het dit keer met een druk op de knop vanuit Vimeo regelen.</p>
<p>De kwaliteit via Amara viel ons erg mee: de meeste captions konden na geen of enkele aanpassingen al snel live. Met als resultaat dat nu allemaal online staan, zowel in de <a href="https://vimeo.com/channels/fronteers15">Vimeo-player</a> als in <a href="https://fronteers.nl/congres/2015/sessions">ons eigen archief</a>.</p>
</content>
</entry>
<entry>
<title>Fronteers Nieuwjaarsborrel 2016</title>
<link href="https://www.fronteers.nl/nl/blog/2015/12/nieuwjaarsborrel-2016"/>
<updated>2015-12-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/12/nieuwjaarsborrel-2016</id>
<content xml:lang="nl" type="html"><p>Tijd voor de Fronteers nieuwjaarsborrel, speciaal voor leden! Meld je nu aan en proost op het nieuwe jaar!</p>
<p>Op vrijdagavond 15 januari 2016 organiseert Fronteers een Nieuwjaarsborrel in de Nieuwe Dikke Dries, in Utrecht.
Meer informatie is te vinden op de <a href="https://www.fronteers.nl/nl/activiteiten/2015/nieuwjaarsborrel-2016">pagina onder Bijeenkomsten</a>. Aanmelden met het formulier is verplicht.</p>
<h2>Meer borrelen?</h2>
<p>Kijk eens <a href="https://newyear.isoc.nl/">naar de uitnodiging van ISOC</a>. Op deze nieuwjaarsreceptie neemt Fronteers als organisatie deel en kom je leden van Fronteers tegen.</p>
</content>
</entry>
<entry>
<title>Wijzigingen na ALV</title>
<link href="https://www.fronteers.nl/nl/blog/2015/12/wijzigingen-na-alv"/>
<updated>2015-12-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/12/wijzigingen-na-alv</id>
<content xml:lang="nl" type="html"><p>Tijdens de ALV op 3 december jongstleden namen we afscheid van Roy Tomeij en Matijs Brinkhuis als bestuursleden van Fronteers. In de bestuursverkiezing verkoos de ALV daarnaast Thomas van Zuijlen tot bestuurslid en herkoos Arjan Eising. Ook werd Krijn Hoetmer benoemd tot erelid.</p>
<p>Om nog even kort stil te staan bij de verdiensten van Matijs en Roy, maakten we een overzicht van hun bijdragen aan het bestuur in de afgelopen jaren.</p>
<blockquote>
<p>Matijs is sinds 2009 bestuurslid van Fronteers. In die zes jaar heeft hij bij vele facetten van de vereniging een steen bijgedragen. Zo stond hij aan de wieg van de workshopactiviteiten van Fronteers, bouwde er een commissie omheen en zat die vanaf 2010 voor (workshops heetten toen nog 'cursussen' trouwens). Dat alles heeft hij keurig gedocumenteerd en netjes overgedragen. Daarnaast werd hij in 2012 ook penningmeester van onze vereniging, wat hij altijd met veel geduld deed. In 2012-2013 droeg hij veel bij als lid van de congrescommissie; zijn oog voor detail bijvoorbeeld, kwam onze sprekersuitnodigingen enorm ten goede. Matijs, veel dank voor al je inzet de afgelopen jaren. We hebben begrepen dat je van IPA houdt, en daarvan is op dit moment een voorraad naar je onderweg!</p>
</blockquote>
<blockquote>
<p>Roy trad in 2012 toe tot het bestuur, vol ambities. Eén daarvan wil ik specifiek noemen, en dat is het verbeteren van processen. Onder Roys leiding is er mooi samengewerkt door hem, Matijs en Krijn om de facturatie van Fronteers via Moneybird te laten verlopen. Daarvoor waren de nodige koppelingen nodig, bijvoorbeeld met de ledenadministratie, maar is alles nu een hoop makkelijker dan het was. Hij regelde ook een hoop juridische zaken voor de vereniging: de registratie van ons beeldmerk, maar ook zaken als aansprakelijkheid rondom het congres. Iets anders waar Roy ook heel betrokken bij was de afgelopen jaren: de marketingcommissie. Die gaf hij al advies voor hij in het bestuur ging, en later werd hij voorzitter van de commissie. En hij was het afgelopen jaar ook nog een uitstekend penningmeester! Kortom, het is teveel om op te noemen. Namens Fronteers, veel dank voor jouw inzet in het bestuur!</p>
</blockquote>
<p>Daarnaast werd Krijn Hoetmer benoemd tot erelid, voor zijn verdiensten als bestuurslid, webmaster, ledenadministrator, congresorganisator, taalpurist en algehele drijvende kracht sinds de oprichting van Fronteers. We lichtten dit, voor wie hem niet kende, nog even toe:</p>
<p><img src="https://www.fronteers.nl/_img/blog/2015/erelid.png" alt="Certificaat erelidmaatschap Krijn Hoetmer. Tekst: Fronteers, de vakvereniging voor front-end developers heeft het genoegen Krijn Hoetmer hierbij uit te roepen tot erelid voor zijn buitengewone verdiensten voor de vereniging waaronder als bestuurslid, webmaster, ledenadministrator, congresorganisator, taalpurist en algehele drijvende kracht sinds de oprichting." /></p>
<blockquote>
<p>Krijn deed vanaf de start in 2007 tot en met november dit jaar de ledenadministratie. Van 2007 tot 2012 was hij daarnaast ook penningmeester. Hij organiseerde maar liefst vijf jaar het congres, en was daar meestal een drijvende kracht. Hij sponsort (nog steeds) met zijn bedrijf Qontent de Fronteers-website, en voorzag die van een solide CMS dat het al vele jaren volhoudt – de actieve vrijwilligers zullen het kennen. Hij schreef bovendien een hoop van de content, zoals een lange serie Webrichtlijnenposts, maar ook bijvoorbeeld kopij voor de congreswebsites. Krijn was daarbij een echte taalpurist! Voor de website zette hij ook de vacaturebank op, nog steeds een inkomstenbron voor de vereniging, en droeg die over aan zijn opvolgers Ron Derksen en later Bernard Nijenhuis! Taalpurisme kwam hem ook ten goede als wat we wel “the voice of Fronteers” mogen noemen, de anonieme kracht achter het FronteersConf Twitter-account. Al deze verschillende dingen deed Krijn met veel enthousiasme, meestal, en met dat enthousiasme haalde je er vaak nieuwe leden en vrijwilligers bij.</p>
</blockquote>
</content>
</entry>
<entry>
<title>Bijeenkomst op 15 december bij Digiti</title>
<link href="https://www.fronteers.nl/nl/blog/2015/12/bijeenkomst-digiti"/>
<updated>2015-12-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/12/bijeenkomst-digiti</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 15 december 2015 is Fronteers te gast bij Digiti in Herentals. Er worden twee presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met een hapje en een drankje</li>
<li>19:00 Bert Timmermans (<a href="https://twitter.com/Berttimmermans">@Berttimmermans</a>) - &quot;Je eigen dashboard met HTML, CSS en JavaScript!&quot;</li>
<li>19:45 korte pauze</li>
<li>20:00 Jules Ernst (<a href="https://twitter.com/julezrulez">@julezrulez</a>) - &quot;A11Y/accessibility, toegankelijkheid op het web&quot;</li>
<li>20:45 naborrelen</li>
</ul>
<p>Dit evenement vindt plaats bij Digiti te Herentals. <a href="https://www.fronteers.nl/bijeenkomsten/2015/digiti-2">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 175 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Prijsverhoging Fronteers workshops</title>
<link href="https://www.fronteers.nl/nl/blog/2015/11/prijsverhoging-fronteers-workshops"/>
<updated>2015-11-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/11/prijsverhoging-fronteers-workshops</id>
<content xml:lang="nl" type="html"><p>De workshopcommissie heeft, in overleg met het bestuur, besloten de prijzen voor de workshops voor zowel leden als niet-leden te verhogen.</p>
<p>De prijs van een workshop gaat voor leden van €100 naar €150 exclusief btw en voor niet-leden van €200 naar €250 exclusief btw. Ook de prijs van een combi (workshop en gelijk lid worden) wordt €250 exclusief btw. De vergoeding voor de trainer gaat van €500 (exclusief btw) naar €1000 per gegeven training.</p>
<p>Voor deze verhoging zijn een tweetal redenen. Ten eerste geven veel trainers van Fronteers deze workshops ook onder hun eigen vlag, vaak tegen een hoger tarief. Daardoor werden ze hun eigen concurrent wanneer ze dezelfde workshop bij Fronteers gaven. Door de prijzen van de Fronteers workshops meer marktconform te maken verwachten we dat dit niet langer een probleem zal zijn.</p>
<p>Ten tweede kunnen we hierdoor de trainers een ruimere vergoeding per training geven, waardoor het voor meer trainers de moeite waard wordt een workshop bij Fronteers te geven. Waardoor we hopelijk een nog breder en veelzijdiger aanbod van workshops krijgen.</p>
<p>De prijsverhoging gaat per 1 januari 2016 in en geldt alleen voor de reguliere workshops. Voor de workshops die gegeven worden voorafgaande aan het congres gelden bovengenoemde prijzen niet.</p>
</content>
</entry>
<entry>
<title>Meld je nu aan voor de ALV 2015</title>
<link href="https://www.fronteers.nl/nl/blog/2015/11/aanmelden-alv-2015"/>
<updated>2015-11-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/11/aanmelden-alv-2015</id>
<content xml:lang="nl" type="html"><p>Op donderdagavond 3 december houden we onze jaarlijkse algemene ledenvergadering (ALV). Alle leden zijn hiervoor van harte uitgenodigd. De locatie van de ALV is Zalencentrum Se7en (toegang via <a href="http://www.sevenutrecht.nl/">Restaurant Se7en</a>), ongeveer vijf minuten lopen vanaf Utrecht CS (Mariaplaats 7).</p>
<p>We beginnen om 19:00 uur en verwachten met een strakke planning ruim binnen de drie uur af te ronden en gezellig te gaan napraten. Voor de mensen die van ver komen regelen we een broodmaaltijd, welke vanaf 18:30 beschikbaar zal zijn. Geef bij je aanmelding even aan als je hier gebruik van wilt maken.</p>
<p>De agenda voor de avond is als volgt:</p>
<ol>
<li>Welkom en opening door de voorzitter</li>
<li>Besluiten eerdere ALV’s</li>
<li>Toelichting commissies</li>
<li>Belangenafweging kaartverkoop congres</li>
<li>Rapportage kascommissie 2014</li>
<li>Jaarstukken 2014 / Financiën 2015 / Begroting 2016</li>
<li>Kascommissieverkiezing</li>
<li>Aftreden Matijs en Roy, bestuursverkiezing</li>
<li>Rondvraag</li>
<li>Afsluiting</li>
</ol>
<p>Dit jaar treden Matijs Brinkhuis en Roy Tomeij af, en stellen zich niet opnieuw herkiesbaar. We bedanken hen voor hun jarenlange inzet, en hopen buiten het bestuur nog veel van ze te zien als actieve vrijwilligers. Arjan Eising treedt ook af, en stelt zich wel herkiesbaar. Tenslotte hebben we één aanmelding ontvangen voor een positie in het bestuur, van Thomas van Zuijlen. Hij presenteert zich hieronder. Thomas zal helaas niet op de ALV zelf aanwezig kunnen zijn, maar zal zijn kandidatuur via video (live danwel van tevoren opgenomen) verder toelichten. Mocht je prangende vragen hebben over zijn kandidatuur, dan kan je deze natuurlijk alvast via het reactieformulier op deze blogpost stellen.</p>
<blockquote>
<p>Dag Fronteers, ik heet Thomas en ik ben sinds 2009 lid van de vereniging. Af en toe doe ik een inleiding bij spreekavonden, en sinds 2013 ben ik actief in de organisatie van het congres. Vandaag stel ik me kandidaat als bestuurslid.</p>
</blockquote>
<p>Ben je van plan te komen, dan vragen we je vriendelijk je hieronder hiervoor in te schrijven, zodat we een idee hebben van de te verwachten opkomst.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij Netvlies op 10 december 2015</title>
<link href="https://www.fronteers.nl/nl/blog/2015/11/bijeenkomst-netvlies"/>
<updated>2015-11-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/11/bijeenkomst-netvlies</id>
<content xml:lang="nl" type="html"><p>Op donderdag 10 december 2015 is Fronteers te gast bij Netvlies in Breda. Er staan drie sprekers op het programma.</p>
<h2>Het programma</h2>
<ul>
<li>18:00 - inloop met versnaperingen</li>
<li>19:00 - Gebruikerstesten door Fréderic Luksemburg</li>
<li>19:45 - korte pauze</li>
<li>20:00 - A test-imonial door Erwin Heitzman</li>
<li>20:45 - korte pauze</li>
<li>21:00 - Modern testing door Maarten Groeneweg</li>
<li>We sluiten af met een borrel</li>
</ul>
<p>Dit evenement vindt plaats bij Netvlies, Prinsenkade 8, 4811 VB Breda. <a href="https://www.fronteers.nl/bijeenkomsten/2015/netvlies">Aanmelden kan via de pagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 60 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst in Maastricht op 27 november 2015 (vervallen)</title>
<link href="https://www.fronteers.nl/nl/blog/2015/11/bijeenkomst-maastricht"/>
<updated>2015-11-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/11/bijeenkomst-maastricht</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 27 november 2015 organiseert Fronteers een bijeenkomst en borrel in Maastricht. Er worden twee presentaties voorzien.</p>
<p><em>Deze bijeenkomst vervalt en de presentaties worden verplaatst!</em></p>
<ul>
<li>Het programma is als volgt:</li>
<li>18:30 ontvangst</li>
<li>19:30 Jules Ernst - A11Y/accessibility, toegankelijkheid op het web</li>
<li>20:00 korte pauze</li>
<li>20:15 Frederik Creemers - Zoom, een hulpmiddel voor mensen met een visuele beperking</li>
<li>20:45 borrel</li>
</ul>
<p>Dit evenement vindt plaats in Stadscafé Lure in Maastricht. <a href="https://www.fronteers.nl/bijeenkomsten/2015/maastricht">Aanmelden kan via de pagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 30 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Techionista zoekt workshopbegeleiders voor Coding Class for Women</title>
<link href="https://www.fronteers.nl/nl/blog/2015/11/workshopbegeleiders-gezocht"/>
<updated>2015-11-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/11/workshopbegeleiders-gezocht</id>
<content xml:lang="nl" type="html"><p>Techionista en T-Mobile hebben Fronteers benaderd, omdat ze op zoek zijn naar begeleiders bij de serie front-end workshops die ze organiseren onder de naam Coding Class for Women. Iets voor jou?</p>
<p>De website Techionista organiseert, in samenwerking met T-Mobile, sinds begin deze maand een serie workshopdagen genaamd “Coding Class for Women”. Het doel? Zorgen dat ‘<a href="http://techionista.com/geef-je-op-voor-techionistas-1e-gratis-coding-class-for-women/">tech in Nederland een vrouwelijker smoel krijgt</a>’. Naar dit doel wordt toegewerkt door de organisatie van workshopdagen die voor de deelnemers gratis zijn bij te wonen.</p>
<p>De eerste editie was gericht op beginners zonder voorkennis, in de toekomst is het de bedoeling dat er workshops voor zowel beginners als meer gevorderde dames worden gegeven. Lees om een idee te krijgen van hoe de workshopdag eruit ziet, het <a href="http://techionista.com/its-a-wrap-techionista-eerste-coding-class-was-een-succes/">verslag van de eerste Coding Class</a>.</p>
<h2>Front-end developers (m/v) gezocht voor begeleiding</h2>
<p>Van T-Mobile kregen wij de vraag of wij misschien front-end developers (m/v) wisten die het leuk vinden om te komen helpen op één van deze workshopdagen. Dus hierbij: zijn er Fronteers-leden die een dag willen komen helpen? Je zult tijdens de praktijkopdrachten langs de deelnemers lopen, en waar nodig helpen.</p>
<p>De organisatie verwelkomt ook ideeën over de opzet. In de eerste editie is bijvoorbeeld gewerkt met Bootstrap om de deelnemers sneller resultaten te laten zien, misschien heb jij andere ideeën?</p>
<h2>Aanmelden</h2>
<p>Voor meer details of om je aan te melden, stuur een mail naar webmaster@t-mobile.nl, met als onderwerp ‘Techionista Coding Class for Women’. Er staat geen vergoeding tegenover, maar hopelijk wel een leuke dag!</p>
<ul>
<li><em>Locatie</em>: Meet Berlage (in de Beurs van Berlage), Amsterdam</li>
<li><em>Datum</em>: 15 november (en er worden meer data gepland)</li>
<li><em>Aanmelden/meer info</em>: mail webmaster@t-mobile.nl</li>
</ul>
</content>
</entry>
<entry>
<title>Bijeenkomst op 19 november bij Kunstmaan</title>
<link href="https://www.fronteers.nl/nl/blog/2015/10/bijeenkomst-kunstmaan"/>
<updated>2015-10-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/10/bijeenkomst-kunstmaan</id>
<content xml:lang="nl" type="html"><p>Op donderdag 19 november 2015 is Fronteers te gast bij Kunstmaan in Leuven. Er worden drie presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<p>18:00 ontvangst met een hapje en een drankje
19:00 <a href="https://twitter.com/sambego">@sambego</a> - &quot;Web-audio-api en de web-midi-api&quot;
19:30 <a href="https://twitter.com/diskwriter">@diskwriter</a> - &quot;Starten met es6&quot;
20:00 korte pauze
20:15 <a href="https://twitter.com/bramus">@bramus</a> - &quot;Hybrid Apps met Ionic Framework&quot;
20:45 naborrelen</p>
<p>Dit evenement vindt plaats bij Kunstmaan te Leuven. <a href="https://www.fronteers.nl/bijeenkomsten/2015/kunstmaan">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 175 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>ALV 2015: 3 december - bestuursleden gezocht</title>
<link href="https://www.fronteers.nl/nl/blog/2015/10/datum-alv-2015"/>
<updated>2015-10-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/10/datum-alv-2015</id>
<content xml:lang="nl" type="html"><p>De datum voor onze jaarlijkse ledenvergadering is bekend: op donderdagavond 3 december 2015 zullen we alweer voor de negende keer bij elkaar komen om het reilen en zeilen van de vereniging te bespreken. Een aantal bestuursleden zal op deze avond aftreden en zich niet opnieuw herkiesbaar stellen. We zijn dus op zoek naar nieuwe bestuursleden.</p>
<p>Fronteers is door de jaren heen uitgegroeid naar een zeer succesvolle vereniging, met een aantal zeer goedlopende activiteiten. Er zijn echter ook activiteiten waarvan we graag allemaal zouden zien dat we ze <em>ook</em> nog zouden oppakken, of die we liever anders zouden zien, maar waar we aanlopen tegen de beperkingen van de beschikbare tijd van onze vrijwilligers. De ALV is bij uitstek de gelegenheid om hierover met elkaar van gedachten te wisselen, en samen de prioriteiten voor het komende jaar te bepalen. We verwelkomen je graag, zowel wanneer je een mening hebt over die prioriteiten, als wanneer je een steentje wilt bijdragen aan het realiseren hiervan.</p>
<p>Wil je ook <em>verantwoordelijkheid nemen</em> voor het uitvoeren en begeleiden van het geheel aan activiteiten van de vereniging? Dan is een bestuurspositie misschien wel iets om te overwegen. De ideale bestuurskandidaat is iemand die zowel zelf het voortouw neemt om verbeteringen door te voeren, als andere vrijwilligers weet te motiveren om dit te doen, en bij dit alles ook kritisch blijft controleren dat het past binnen onze missie en het geheel aan bestaande Fronteers-activiteiten.</p>
<p>We weten uit ervaring dat er vaak erg ambitieus wordt gedacht over het opzetten van nieuwe activiteiten, waarbij het niet halen van die doelen vervolgens demotiverend werkt; een realistische en pragmatische blik wordt aangeraden.</p>
<p>Op dit moment bestaat het bestuur overwegend uit blanke mannen werkzaam als zelfstandige. We zouden het goed voor de vereniging vinden als we meer diversiteit binnen het bestuur zouden mogen verwelkomen, om hiermee een betere afspiegeling van de vereniging en onze beroepsgroep te vormen.</p>
<p>Je kandidaat stellen als bestuurslid kan tot twee weken voor de ALV, 19 november. De eventueel nieuwe kandidaten voor het bestuur zullen hierna de gelegenheid krijgen hun kandidatuur op het blog toe te lichten. Op de ALV kunnen alle aanwezige leden op alle, sommige, of geen van de kandidaten stemmen. Alle kandidaten die meer dan 50% van de uitgebrachte stemmen krijgen, worden in het bestuur verkozen. (Mochten er dusdanig veel kandidaten zijn dat het resulterende bestuur groter zou kunnen worden dan wenselijk, dan zal het bestuur aan de ALV voorstellen die stemprocedure aan te passen.) Het nieuwe bestuur kiest vervolgens uit haar midden een voorzitter, secretaris en penningmeester.</p>
<p>Agenda, locatie en tijdstip van de ALV volgen komende maand. (Waarschijnlijk Utrecht, 19:00.) Als je vragen, opmerkingen en/of voorstellen voor de ALV hebt, of je je aan wilt melden als potentieel bestuurslid, <a href="https://www.fronteers.nl/nl/vereniging/contact/">neem dan contact met ons op</a>. (Een kort en bondige toelichting waarom je in het bestuur zou willen plaatsnemen wordt op prijs gesteld.)</p>
</content>
</entry>
<entry>
<title>Met 25 euro korting naar dsgnday</title>
<link href="https://www.fronteers.nl/nl/blog/2015/10/korting-dsgnday"/>
<updated>2015-10-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/10/korting-dsgnday</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 13 november wordt net als vorig jaar het <a href="http://dsgnday.nl/">dsgnday</a>-congres georganiseerd. Een dag met acht sprekers over grafisch en UX design op het web. De focus ligt net zoals vorig jaar op directe toepasbaarheid in plaats van inspirerende verhalen zonder direct praktisch nut.</p>
<p>Dan Mall, Ida Aalen, Susan Robertson, Trine Falbe, Stephen Hay, Simon Collison, Bram Stein, en Geri Coady delen praktische truuks en tips onder leiding van Ruben Bos. Onderwerpen variëren van hands-on voorbeelden van verschillende projecten tot het (her)definiëren van de rol van de designer en van het ontwerpen van interfaces voor kinderen tot het maken van styleguides en typografische analyse vanuit een wiskundig en computer science perspectief.</p>
<p>Fronteers-leden krijgen net als vorig jaar €25 korting op de reguliere toegangsprijs van €275. Bij je kaartje zijn koffie, lunch, en een drankje na afloop inbegrepen.</p>
<p>Mocht je gebruik willen maken van deze korting, neem dan even contact op met de <a href="https://www.fronteers.nl/nl/vereniging/contact">ledenadministratie</a>.. Zoals gebruikelijk geldt deze actie alleen voor leden die op dit moment al lid zijn.</p>
</content>
</entry>
<entry>
<title>Win een gratis kaartje voor Polymer Summit, 15 september 2015 in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2015/08/polymer-summit"/>
<updated>2015-08-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/08/polymer-summit</id>
<content xml:lang="nl" type="html"><p>Op 15 september 2015 vindt in Amsterdam de <a href="https://www.polymer-project.org/summit">Polymer Summit</a> plaats. Dit congres
wordt georganiseerd door Google, in samenwerking met Fronteers-lid Jayne Verbeek.</p>
<p>Het congres duurt één dag, en vindt plaats in het Muziekgebouw aan 't IJ in Amsterdam. De dag zal volledig in het teken van Google's <a href="https://www.polymer-project.org/1.0/docs/start/what-is-polymer.html">Polymer library</a> staan. Polymer is een library gebaseerd op <a href="https://en.wikipedia.org/wiki/Web_Components">web components</a>, en bevat zowel een eigen set van custom elementen, als de mogelijkheid nieuwe HTML-elementen te definiëren. De talks zullen technisch zijn, maar toegankelijk voor zowel beginnende als gevorderde front-end ontwikkelaars. De sprekers zijn op dit moment nog niet bekend.</p>
<p>De organisatie stelt 15 tickets beschikbaar voor Fronteers-leden. Toegang is inclusief lunch en after-party. Om hiervoor in aanmerking te komen, laat hieronder een reactie achter of mail naar hidde@fronteers.nl. Hierbij geldt: wie het eerst komt, die het eerst maalt.</p>
<p>Zoals altijd geldt deze actie <em>alleen voor Fronteers-leden</em> (lid geworden voor 10 augustus).</p>
</content>
</entry>
<entry>
<title>Fronteers Zomerborrel op 25 augustus. Meld nu aan!</title>
<link href="https://www.fronteers.nl/nl/blog/2015/08/fronteers-zomerborrel"/>
<updated>2015-08-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/08/fronteers-zomerborrel</id>
<content xml:lang="nl" type="html"><p>Tijd voor de Fronteers zomerborrel, kom bijkletsen met mede front-end ontwikkelaars! In Utrecht, op dinsdag 25 augustus. Meld je snel aan, vol=vol!</p>
<p>Meer info is te vinden op <a href="https://www.fronteers.nl/nl/activiteiten/2015/fronteers-zomerborrel-2015">de pagina van deze bijeenkomst</a>.</p>
</content>
</entry>
<entry>
<title>Workshop Counter space in september</title>
<link href="https://www.fronteers.nl/nl/blog/2015/07/workshop-counter-space-in-september"/>
<updated>2015-07-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/07/workshop-counter-space-in-september</id>
<content xml:lang="nl" type="html"><p>25 september 2015 wordt weer de workshop <a href="https://fronteers.nl/workshops/counter-space-jeroen-visser">Counter Space</a> gegeven met Jeroen Visser als trainer. In deze workshop lopen we langs de hoofdlijnen van de typografie, om vervolgens deze grondbeginselen toe te passen op de tekst in je browser.</p>
<p>In de ochtend ligt het accent op de theorie, in de middag breng je typografie in de praktijk op je eigen scherm. Leden van Fronteers betalen 100 euro. Niet-leden betalen 200 euro. Beide bedragen zijn exclusief btw. De workshop duurt de hele dag en is inclusief lunch bij Seats2Meet in Utrecht.</p>
<p>Als je nog geen lid bent, dan is het mogelijk lid te worden en de workshop te bezoeken voor 225 euro exclusief btw.</p>
</content>
</entry>
<entry>
<title>Win een gratis kaartje voor ColdFront, 3 september 2015 in Kopenhagen</title>
<link href="https://www.fronteers.nl/nl/blog/2015/06/korting-coldfront"/>
<updated>2015-06-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/06/korting-coldfront</id>
<content xml:lang="nl" type="html"><p>De organisatie van het <a href="http://coldfrontconf.com/">ColdFront-congres</a> in Copenhagen heeft ons twee (!) kaartjes gegeven om te verloten onder Fronteers-leden. Dit congres houdt dit jaar zijn tweede editie, met sprekers als Jeremy Keith, Lea Verou en Vitaly Friedman.</p>
<p>Kaartjes kosten 2000 DKK + btw, en zijn inclusief licht ontbijt, lunch en wat te drinken op de congresdag. Op de dag voor het congres is er ook een workshop van Vitaly Friedman (Smashing Magazine), waarvoor los kaartjes worden verkocht.</p>
<p>Het enige wat je hoeft te doen om te winnen, is reageren op deze blogpost. We zullen over twee weken (26 juni) willekeurig twee winnaars trekken uit de reacties.</p>
<h2>Niet gewonnen? Profiteer van korting.</h2>
<p>Naast de twee gratis kaartjes hebben we ook korting bedongen: Fronteers-leden krijgen 30% korting op de toegangsprijs van dit congres. Om van je korting gebruik te maken, neem je contact op met de <a href="https://www.fronteers.nl/nl/vereniging/contact/">ledenadministratie</a>.</p>
<p>Zoals altijd geldt deze actie voor wie voor vandaag lid was van Fronteers.</p>
</content>
</entry>
<entry>
<title>Workshop Responsive Design in september</title>
<link href="https://www.fronteers.nl/nl/blog/2015/05/workshop-responsive-design-september"/>
<updated>2015-05-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/05/workshop-responsive-design-september</id>
<content xml:lang="nl" type="html"><p>De workshop <a href="https://fronteers.nl/workshops/workshop-responsive-design">Responsive Design</a> zal in september opnieuw gegeven worden door Frances de Waal. Op 10 september kun je in Utrecht leren hoe je een website ontwikkelt die er goed uitziet op ieder apparaat, mobiel, tablet of desktop.</p>
<p>Deze workshop is bedoeld voor ervaren webdesigners en ontwikkelaars voor wie responsive design nog (betrekkelijk) nieuw is. De gehele dag, inclusief koffie, thee en lunch, kost 200 euro exclusief btw. Voor leden van Fronteers geldt een prijs van 100 euro exclusief btw. Als je nog geen lid bent, dan is het mogelijk lid te worden <em>en</em> de workshop te bezoeken voor 225 euro exclusief btw.</p>
<h2>Workshopcommissie zoekt versterking</h2>
<p>Als je ideeën hebt over de workshops van Fronteers, zoals het helpen bepalen van de onderwerpen of het regelen van trainers, de workshopcommissie zoekt versterking. Via het <a href="https://www.fronteers.nl/workshops">formulier onderaan de workshoppagina</a> kun je contact opnemen.</p>
</content>
</entry>
<entry>
<title>Ontwikkelen met progressive enhancement</title>
<link href="https://www.fronteers.nl/nl/blog/2015/05/ontwikkelen-met-progressive-enhancement"/>
<updated>2015-05-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/05/ontwikkelen-met-progressive-enhancement</id>
<content xml:lang="nl" type="html"><p>Sanne Veroude werkt bij de Voorhoede in Amsterdam, waar ze bij het bouwen van websites gebruik maken van progressive enhancement. In haar artikel vertelt ze over het proces dat zij gebruiken voor progressive enhancement.</p>
<h2>Ontwikkelen met progressive enhancement</h2>
<p>De term ‘progressive enhancement’ werd voor het eerst genoemd door Steven Champeon en Nick Finck in <a href="http://hesketh.com/publications/inclusive_web_design_for_the_future/">2003</a>. In de wereld van front-end development waarin ontwikkelingen zo ontzettend snel gaan, lijkt dit een eeuwigheid geleden. Sinds die tijd is er veel veranderd, maar progressive enhancement is zeker niet minder relevant geworden.</p>
<p>De diversiteit aan apparaten waarmee we toegang hebben tot het web is de laatste jaren enorm gegroeid. Het is verleidelijk om hierbij te denken aan de nieuwste smartphone of iPad. De verscheidenheid aan apparaten waarmee gebruikers websites bezoeken is echter veel groter dan dat. We krijgen daardoor meer en meer te maken met verschillen in browsermogelijkheden.</p>
<p>Als ontwikkelaars willen we graag een rijke en interactieve ervaring leveren aan moderne smartphones en nieuwe desktop browsers. Tegelijkertijd is het belangrijk dat we oudere browsers en minder bekwame devices blijven ondersteunen. Dit kunnen we realiseren door te ontwikkelen vanuit een progressive enhancement (PE) benadering: we starten met een eenvoudige bruikbare ervaring, en verrijken de gebruikerservaring stap voor stap wanneer we er zeker van zijn dat browsers deze verrijking ondersteunen.</p>
<h2>Hoe brengen we progressive enhancement in de praktijk?</h2>
<p>We kunnen progressive enhancement op twee niveaus toepassen:</p>
<h2>1. Website niveau:</h2>
<p>Op website niveau kunnen we een PE techniek gebruiken die bekend staat als ‘cutting the mustard’. Hierbij ontwikkelen we een basiservaring voor alle browsers met HTML, eenvoudige CSS en zonder JavaScript. Door middel van feature detection maken we een onderscheid tussen ‘verouderde’ en ‘moderne’ browsers.</p>
<pre><code>if ('querySelector' in document) {
// enhance the application
}
</code></pre>
<p>Browsers die de ‘cut the mustard’ test niet doorstaan, krijgen de minimale gebruikerservaring. Wanneer een browser de cut the mustard test doorstaat:</p>
<ul>
<li>wordt JavaScript ingeladen.</li>
<li>wordt de class name ‘enhanced’ aan de HTML tag toegevoegd. Binnen deze class wordt de enhanced CSS toegevoegd. JavaScript afhankelijke controls worden binnen deze class gescoped.</li>
</ul>
<p>Doordat JavaScript niet wordt ingeladen voor de oudere browsers, worden deze niet belemmerd door extra requests.</p>
<h2>2. Component niveau:</h2>
<p>Nu onze websites moeten werken op een breed scala aan apparaten, zijn onze werkprocessen veranderd. In plaats van het bouwen van complete webpagina’s ontwikkelen we nu een systeem van <a href="http://daverupert.com/2013/04/responsive-deliverables">componenten</a>.
Ook op dit niveau beginnen we het ontwikkelen van een component met toegankelijke en semantische HTML. Vervolgens voegen we CSS en JavaScript enhancements toe, op basis van features die door de browser worden ondersteund.</p>
<p>Een voorbeeld: we willen een standaard input element met type=”file” laten passen binnen de look &amp; feel van de website. Bovendien willen we het element gebruiksvriendelijker maken voor mobiele devices door het touch target te vergroten. We kunnen <a href="http://www.filamentgroup.com/examples/jquery-custom-file-input/#">dit doen door</a> het input element een opacity van 0 te geven en er een <code>&lt;div&gt;</code> element overheen te plaatsen die we de custom CSS geven.
Omdat deze oplossing gebruik maakt van de opacity property, willen we de enhancement alleen serveren aan browsers die deze property ondersteunen. Dus eerst checken we voor opacity support:</p>
<pre><code>var supportsOpacity = typeof document.body.style.opacity === 'string';
if (supportsOpacity) {
// enhance the component
}
</code></pre>
<p>Als de opacity property wordt ondersteund, dan voegen we de enhancement toe. Zo niet, dan ziet de gebruiker het native input element. En dat is prima, want <a href="http://dowebsitesneedtolookexactlythesameineverybrowser.com/">een site hoeft er niet op alle apparaten hetzelfde uit te zien</a>. Waar het om gaat is dat de gebruiker in beide gevallen in staat is om het input element te gebruiken.</p>
<h2>Bestand tegen onverwachte omstandigheden</h2>
<p>Gebruikers maken niet langer alleen vanachter hun bureau gebruik van het internet, maar steeds vaker onderweg en op openbare plaatsen, waar regelmatig sprake is van een instabiele internetverbinding. Progressive enhancement is daardoor niet langer slechts een kwestie van support. We moeten er ook voor zorgen dat onze websites een bruikbare ervaring bieden in het geval van onverwachte omstandigheden (bijvoorbeeld wanneer de internetverbinding wegvalt, omdat een gebruiker zojuist een tunnel is binnengereden).</p>
<p>Veel websites gebruiken tegenwoordig web fonts om de typografie te laten aansluiten bij de huisstijl van de website. Maar wat gebeurt er als het web font door een falende internetverbinding niet gedownload kan worden?</p>
<p>Browsers gaan hier <a href="https://speakerdeck.com/zachleat/bulletproof-font-icons?slide=68">op verschillende manieren</a> mee om. Sommige browsers (zoals Chrome 36+, Opera 23+ en Firefox) hebben een timeout voor <code>@font-face</code> requests. Als het font na deze timeout nog niet is geladen, wordt het fallback font weergegeven. Andere browsers (Mobile Safari, Safari, Android, Blackberry) hebben geen timeout en verbergen de fallback tekst. De gebruiker wordt daardoor geconfronteerd met een ‘flash of invisible text’ (FOIT): zolang het custom font bezig is met downloaden, is de tekst onzichtbaar.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2015/example-of-foit.png" alt="" /></p>
<p class="note">
Een voorbeeld van FOIT
</p>
<p>Uiteraard willen we dat onze content zo snel mogelijk beschikbaar is: een font request zou geen single point of failure moeten zijn. We moeten websites op zo’n manier bouwen dat ze bij onverwachte omstandigheden, zoals een falende internetverbinding, nog steeds bruikbaar zijn.</p>
<p>We hebben meer controle over de manier waarop browsers met font loading omgaan door gebruik te maken van load events. De native oplossing hiervoor, de <a href="http://dev.w3.org/csswg/css-font-loading/">CSS Font Loading Module</a>, wordt helaas nog niet door alle browsers ondersteund. Voor een betere browserondersteuning kunnen we gebruik maken van <a href="https://github.com/bramstein/fontfaceobserver">Font Face Observer</a>, een polyfill waarmee je een font family en andere eigenschappen (zoals de font weight en style) kan specificeren in de <em>FontFaceObserver constructor</em>.</p>
<pre><code>var observer = new FontFaceObserver(‘Custom Font Family', {
weight: 400
});
</code></pre>
<p>Met de check() methode wordt gesignaleerd wanneer fonts zijn geladen. We voegen de class name enhanced-font toe wanneer dit het geval is:</p>
<pre><code>observer.check().then(function () {
// font is available
w.document.documentElement.className += ‘enhanced-font’;
}, function () {
// font is not available
});
</code></pre>
<p>In de CSS specificeren we een fallback font dat wordt gebruikt zolang het custom font niet beschikbaar is:</p>
<pre><code>body {
font-family: sans-serif;
}
</code></pre>
<p>Binnen de class enhanced-font specificeren we in de CSS het custom font:</p>
<pre><code>.enhanced-font body {
font-family: Open Sans;
}
</code></pre>
<p>Met deze werkwijze wordt het standaard lettertype weergegeven terwijl de custom fonts worden geladen, ook wanneer het laden van de fonts lang duurt of mislukt. In plaats van gebruikers FOIT te presenteren bieden we hen het standaard lettertype aan, waardoor de content altijd beschikbaar is. Zodra het custom font beschikbaar is, wordt het als een enhancement toegevoegd.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2015/kapotte-roltrap.png" alt="" /></p>
<h2>Geen liften maar roltrappen</h2>
<p>Christian Heilmann vergelijkt progressive enhancement met <a href="http://christianheilmann.com/tag/progressive-enhancement/">liften en roltrappen</a>: wanneer een lift buiten werking is, is hij onbruikbaar en heb je er niets aan. Wanneer een roltrap buiten werking is, is hij nog steeds te gebruiken als trap. Het is wellicht minder gemakkelijk, maar gebruikers kunnen nog steeds op de volgende verdieping komen.</p>
<p>Hetzelfde geldt voor de manier waarop we websites bouwen: gebruikers moeten altijd hun doel kunnen bereiken, ook wanneer de techniek faalt. En hier moeten we door grotere verschillen in browsermogelijkheden en instabiele internetverbindingen steeds meer rekening mee moeten houden.</p>
<p>Progressive enhancement biedt ons een aantal praktische methodes waarmee we:</p>
<ul>
<li>door middel van feature detection geavanceerde technieken kunnen aanbieden aan moderne browsers, terwijl de basiservaring altijd beschikbaar is voor minder capabele browsers.</li>
<li>een website bestand maken tegen onverwachte gebeurtenissen, waardoor deze ook bruikbaar is in het geval van een instabiele internetverbinding.</li>
</ul>
<h2>Over Sanne Veroude</h2>
<img src="https://www.fronteers.nl/_img/blog/2015/sanneveroude.png" alt="Foto van Sanne" />
Front-end developer, likes building stuff accessible for everyone and on every device
</content>
</entry>
<entry>
<title>Fronteers 2015 launchborrel + livegang kaartverkoop op 29 mei</title>
<link href="https://www.fronteers.nl/nl/blog/2015/05/launchborrel-cafe-de-jaren"/>
<updated>2015-05-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/05/launchborrel-cafe-de-jaren</id>
<content xml:lang="nl" type="html"><p>De kaartverkoop voor het Fronteerscongres 2015 start vrijdag 29 mei om 20:00 uur. Om dit te vieren, organiseert Fronteers die avond vanaf 19:00 uur een speciale launchborrel bij Café De Jaren in Amsterdam - en jij bent uitgenodigd.</p>
<p><img src="https://www.fronteers.nl/_img/congres/2015/fronteers15-launchborrel-announcement-image-nl-1024.png" alt="Fronteerscongres 2015 Launchborrel bij Café de Jaren. Vrijdag 29 mei 2015 om 19.00 uur" /></p>
<h2>TL;DR</h2>
<ul>
<li>Fronteers 2015 Launchborrel</li>
<li>Vrijdag 29 mei, <a href="http://www.cafedejaren.nl/nl/de-Jaren/Home.html">Café De Jaren, Amsterdam</a></li>
<li>Borrel 19:00u, livegang ticket sales 20:00u</li>
<li>RSVP via het formulier</li>
</ul>
<p>Het wordt een gezellige avond met ontspannen sfeer (behalve voor de congresorganisatie die ter plekke de verkoop live zal zetten) en zoals altijd: de eerste drankjes zijn op onze kosten.</p>
<h2>Livegang</h2>
<p>De congrescommissie vertelt over de plannen voor dit jaar en is aanwezig om jullie vragen te beantwoorden. Hoofdevenement is natuurlijk de <a href="https://www.fronteers.nl/nl/blog/2015/05/kaartverkoop-fronteers15-begint-op-vrijdag-29-mei">livegang van de kaartverkoop om 20:00 uur</a>, waarna je zelf ook ter plekke je tickets kunt kopen - met Fronteerskorting, natuurlijk.</p>
<h2>Locatie</h2>
<p>Café De Jaren in Amsterdam heet ons hiervoor welkom; een bekende locatie voor congresgangers. De Jaren is prima bereikbaar met het openbaar vervoer. Het NS- en busstation van Amsterdam liggen op circa 15 minuten loopafstand.</p>
<p><a href="http://www.cafedejaren.nl/nl/de-Jaren/Home.html">Café De Jaren</a>
Nieuwe Doelenstraat 20-22
1012 CP Amsterdam</p>
<h2>RSVP</h2>
<p><a href="https://www.fronteers.nl/nl/activiteiten/2015/fronteers-2015-launchborrel">Meld je aan via het formulier</a> (let op: plaatsen zijn beperkt!) en kom met ons het glas heffen op #fronteers15!</p>
</content>
</entry>
<entry>
<title>Kaartverkoop #fronteers15 begint op vrijdag 29 mei</title>
<link href="https://www.fronteers.nl/nl/blog/2015/05/kaartverkoop-fronteers15-begint-op-vrijdag-29-mei"/>
<updated>2015-05-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/05/kaartverkoop-fronteers15-begint-op-vrijdag-29-mei</id>
<content xml:lang="nl" type="html"><p>De kaartverkoop voor het Fronteerscongres 2015 begint op 29 mei. Geen early-bird-korting maar goedkopere kaartjes, en natuurlijk krijgen leden fikse korting.</p>
<p><img src="https://www.fronteers.nl/_img/congres/2015/fronteers15-ticket-sales-announcement-image-nl-2.jpg" alt="Kaartverkoop Fronteers 2015 op 29 mei 2015" /></p>
<p>Omcirkel de datum in je agenda, zet een wekker en typ vast tickets.fronteers.nl in een extra tabblad; de kaartverkoop voor het Fronteerscongres 2015 gaat van start op vrijdag 29 mei 2015. We gaan dit jaar een paar dingen veranderen - hier is de situatie.</p>
<h2>TL;DR</h2>
<ul>
<li>Start kaartverkoop: 29 mei 2015</li>
<li>Verkoop in batches</li>
<li>Geen early-bird-korting</li>
<li>Lagere kaartprijzen voor iedereen</li>
<li>Korting voor Fronteersleden</li>
</ul>
<h2>Kaartprijzen</h2>
<p>We doen het dit jaar zonder early-bird-kaartjes en smeren het voordeel uit over alle tickets. Daarmee kosten congreskaartjes dit jaar €345 exclusief BTW voor niet-leden en €270 exclusief BTW voor leden. Net als in voorgaande jaren, moet je wel lid zijn geweest vóór deze aankondiging om in aanmerking te komen voor de ledenkorting van €75.</p>
<h2>Verkoop in batches</h2>
<p>Als je toevallig op vakantie bent of anderszins niet beschikbaar op vrijdag de 29e, geen zorgen: we gaan de tickets in drie keer verkopen. Je kunt dus een tweede of derde poging wagen (voor hetzelfde bedrag). De eerste set van 300 kaartjes gaat in de verkoop op vrijdag 29 mei om 20:00u. Daaropvolgende batches worden op tijd aangekondigd.</p>
<p>Ga vrijdag de 29e naar tickets.fronteers.nl om je kaartje binnen te halen!</p>
<h2>Over #fronteers15</h2>
<p>Het Fronteerscongres is een van de grootste congressen over front-end development in Europa. Het wordt sinds 2008 jaarlijks georganiseerd door de vereniging Fronteers. De editie van dit jaar wordt de achtste, en zal opnieuw plaatsvinden in het prachtige Pathé Tuschinski. De congresdata zijn donderdag en vrijdag 8 en 9 oktober 2015. Op woensdag 7 oktober organiseren we bovendien een extra dag met workshops.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij VI Company op 3 juni 2015</title>
<link href="https://www.fronteers.nl/nl/blog/2015/05/bijeenkomst-vi-company"/>
<updated>2015-05-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/05/bijeenkomst-vi-company</id>
<content xml:lang="nl" type="html"><p>Op woensdag 3 juni 2015 is Fronteers te gast bij VI Company in Rotterdam. Er worden twee presentaties en een demo voorzien rondom het thema Frontend &amp; Mobile.</p>
<h2>Programma</h2>
<ul>
<li>18:00 Inloop</li>
<li>18:40 intro Fronteers en VI Company</li>
<li>18:45 Jan Jongboom over mobiele telefoons, sensoren, een theremin, een schroevendraaier, de gyroscoop, beacons en ... JavaScript.</li>
<li>19:30 demo van een Open Device Lab (ODL) door VI Company</li>
<li>19:45 pauze</li>
<li>20:15 Niels Leenheer, bekend van o.a. html5test.com over vreemde browsers en rare devices</li>
<li>21:00 borrel</li>
</ul>
<p>Deze bijeenkomst vindt plaats bij VI Company in Rotterdam. <a href="https://www.fronteers.nl/bijeenkomsten/2015/vicompany">Meer informatie is beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 75 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Fronteers.nl is vanaf heden een single page app</title>
<link href="https://www.fronteers.nl/nl/blog/2015/04/fronteers-spaof"/>
<updated>2015-04-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/04/fronteers-spaof</id>
<content xml:lang="nl" type="html"><p>Nu grote partijen als KLM, ING en de Gemeente Antwerpen hun nieuwste redesigns hebben gebouwd in moderne JavaScript frameworks als Angular.JS, vinden we dat Fronteers niet achter kan blijven. Daarom lanceren we vandaag de nieuwste versie van fronteers.nl, onder de motorkap aangestuurd door bewezen technologieën als require.js en Ember.</p>
<p>De site is geoptimaliseerd op snelheid, doordat we gebruik maken van lazyload.js voor afbeeldingen, en webfonts inladen met Web Font Loader van Google en Adobe.</p>
<p>Met de nieuwe opzet hebben we eindelijk gezorgd dat er in onze code een strikte scheiding bestaat tussen de data zelf (model), hoe het wordt weergegeven (view) en de techniek waarmee het wordt weergegeven (controller). Dit maakt het één en ander ook gemakkelijker voor de back-end ontwikkelaars van Fronteers.nl, voor wie het toevoegen van nieuwe modules een stuk eenvoudiger is geworden.</p>
<p>Omdat de CSS op onze site door veel verschillende mensen wordt bijgehouden, lang niet allemaal front-end ontwikkelaars, zochten we een manier om onze variabelen te scopen en cascading te voorkomen. CSS zelf biedt alleen globale variabelen, dus hebben we besloten onze CSS voortaan in JavaScript te schrijven. De uiteindelijke style rules injecteren we in een style-attribuut in de DOM.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2015/angularbootstrap.png" alt="Screenshots van Angular.js en Bootstrap homepages" /></p>
<p>We houden ook vast rekening met de toekomst, door bijvoorbeeld gebruik te maken van Bootstrap. Nieuwe ontwikkelaars kunnen zo gemakkelijker bij het team aansluiten, ze hoeven immers alleen Bootstrap te kennen! Ook hebben we jQuery UI toegevoegd, zodat we straks een stuk minder ontwikkeltijd nodig hebben als we bijvoorbeeld een overlay in de site willen implementeren.</p>
<p>Een website is nooit af. Zo hebben we ook bij deze nieuwe site van Fronteers nog wel wat aandachtspunten. Aan toegankelijkheid, bijvoorbeeld, wordt nog gewerkt. We zijn hiervoor bezig met a11y.js, een plug-in die de site automatisch van de nodige WAI-ARIA zal voorzien.</p>
<p>We zijn benieuwd wat jullie van deze nieuwste versie vinden.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst van ISOC en W3C op 2 april in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2015/03/bijeenkomst-van-isoc-en-w3c-op-2-april-in-amsterdam"/>
<updated>2015-03-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/03/bijeenkomst-van-isoc-en-w3c-op-2-april-in-amsterdam</id>
<content xml:lang="nl" type="html"><p>Komende donderdag, 2 april, organiseren ISOC.nl en W3C Benelux i.s.m. het CWI en Waag Society twee evenementen, het middagprogramma gaat over WebRTC (Web Real-Time Communications) en het avondprogramma over HTML5/Webapps. De toegang bedraagt 30 euro.</p>
<p>Op donderdag 2 april organiseren W3C Benelux en ISOC.nl twee bijeenkomsten met de Franse webexpert Dominique Hazaël-Massieux van het World Wide Web Consortium (W3C) uit Frankrijk. Alexander Blom (ISOC.nl) en Annette Kik (W3C Benelux Office) nodigen je van harte uit, deze bijeenkomst bij te wonen.</p>
<h2>Programma</h2>
<p>'s Middags spreekt Dominique Hazaël-Massieux tijdens een WebRTC masterclass op het CWI. WebRTC – Web Real-Time Communications – is een webstandaard waarmee audio- en video-gesprekken, instant messaging en het uitwisselen van bestanden mogelijk wordt via de browser.</p>
<ul>
<li>WebRTC masterclass en inschrijving: <a href="http://isoc.nl/events/webrtc-masterclass/">http://isoc.nl/events/webrtc-masterclass/</a></li>
<li>Datum en tijd: 2 april, 14:00 - 17:00 uur</li>
<li>Locatie: Centrum Wiskunde &amp; Informatica (CWI), Science Park 123, 1098 XG Amsterdam</li>
</ul>
<p>'s Avonds is Dominique Hazaël-Massieux spreker tijdens een HTML5/webapps workshop in de Amsterdamse Waag Society. HTML5 biedt een rijke set van features waar voorheen browser plug-ins benodigd waren. Belangrijker nog is dat je met HTML5 niet meer per OS een aparte app te ontwikkelen.</p>
<ul>
<li>HTML5/webapps workshop en inschrijving: <a href="http://isoc.nl/events/html5webapps-workshop/">http://isoc.nl/events/html5webapps-workshop/</a></li>
<li>Datum en tijd: 2 april, 20:00 - 22:30 uur</li>
<li>Locatie: Waag Society, Nieuwmarkt 4, Amsterdam</li>
</ul>
<h2>Aanmelden via de website van ISOC</h2>
<p>Deelname is gratis voor leden van W3C en ISOC.nl (na registratie) en 30 euro voor andere belangstellenden. Voertaal is Engels.
Deze bijeenkomst wordt niet georganiseerd door Fronteers, maar kan wel interessant zijn voor onze leden en lezers. Aanmelden kan alleen via <a href="http://isoc.nl/events/">http://isoc.nl/events/</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 28 april bij 3SIGN</title>
<link href="https://www.fronteers.nl/nl/blog/2015/03/bijeenkomst-3sign"/>
<updated>2015-03-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/03/bijeenkomst-3sign</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 28 april 2015 is Fronteers te gast bij 3SIGN in Eeklo. Er worden twee presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met verse pizza en een drankje</li>
<li>19:00 “De mythe van het extra werk van de AnySurfer-richtlijnen” door <a href="https://twitter.com/b_de_clercq">Bart De Clercq</a></li>
<li>20:00 “Help! De designer werkt met Illustrator” + “Introductie in Sketch en Zeplin” door <a href="https://twitter.com/macetaria">Dries van Giel</a></li>
<li>21:00 naborrelen</li>
</ul>
<p>Dit evenement vindt plaats bij 3SIGN te Eeklo. <a href="https://www.fronteers.nl/bijeenkomsten/2015/3sign">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 30 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Ceci n’est pas une pipe | or on CSS naming</title>
<link href="https://www.fronteers.nl/nl/blog/2015/03/on-css-naming"/>
<updated>2015-03-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/03/on-css-naming</id>
<content xml:lang="nl" type="html"><p>Wilfred Nas hield tijdens de jam session van het Fronteerscongres een praatje over naamgeving van classes. Dit praatje heeft hij omgezet in een artikel voor onze website.</p>
<h2>Ceci n’est pas une pipe | or: on CSS naming</h2>
<p>Most of us write CSS daily, it is something we do and not the most difficult thing that we do. Or so we tell ourselves, as most of us would rather concentrate on the more difficult stuff, such as writing JavaScript or semantically correct HTML. Most of the time we don't really think about what it is we write, but I think that CSS is a poorly understood part of our work.
And I think we tend to forget the most important part of it:
naming things.</p>
<h2>In the beginning</h2>
<p>There used to be a time when life was simple. You built a website or an app, all by yourself. In those days stuff was simple and you didn't need to really think about the name of that <code>.button</code> or was it <code>.btn</code> or even <code>.defaultButton</code>. You just had a couple of hundred lines of CSS and you could oversee it all easily. That is, when you were working on it. If the client came back in three months there sometimes was that moment that you honestly had no clue what you had done in the past, but most of the times you managed.</p>
<h2>Enter the modern times</h2>
<p>Nowadays there is almost no project I tackle all by myself, most of the time there are two or more people working on the same code that I work on. And I have to communicate with those people, to avoid mistakes or unnecessary rework. So to avoid these things, we start to think about naming conventions. There are some tools and methodologies around to help you, <a href="http://smacss.com/">SMACSS</a>, <a href="http://bem.info/">BEM</a> and <a href="http://oocss.org/">OOCSS</a> to name but a few and I advise you to look at those. But I think that rather than blindly following one of those methods you should settle on your own and build these things with your team. As the most important thing about this is communication and that happens best when you do it together…</p>
<h2>So a proposal</h2>
<p>Something that I like to do is to work really simply, so the first thing I like to do is set up boundaries. So the first part of each class will be the name of the project or the sub-project you are working on.</p>
<p><code>.*g*-form-checkbox</code>: Where G is the Generic part of the project you are working on.
This is a real life example from a project I worked on, this one involved around 30 people working in 7 different teams. So you see, we had quite some coordinating to do. Each team has its own prefix thus preventing them to overwrite other peoples code by accident.</p>
<p>.g-<em>form</em>-checkbox: The second part is what we are working on, the form bit of the application.
Each project has its own sections in the code base, most of the time in its own .less file.</p>
<p>.g-form-<em>checkbox</em>: The third part is for... you can figure that one out.</p>
<p>Ok you say, this all sounds reasonable, but why should we bother? Well maybe to really start thinking about the names you give to stuff, as to avoid stuff like this:</p>
<pre><code>.textAlignRight { text-align:left;}
.width756px { width: 740px; }
</code></pre>
<h2>Real code</h2>
<p>I know you are smarter than that, but the truth is, what I have seen is stuff like naming a button three different ways:</p>
<p><code>.button</code></p>
<p><code>.btn</code></p>
<p><code>.defaultButton</code></p>
<p>So I will just show you some of the CSS naming conventions me and the people that I have worked with have came up with in the past. It is not something you have to do, think of it like tips or guidelines...</p>
<p>We have always tried to make use of smart people and starting from some of the things of patternlab seemed like a good idea. So we started out with Atoms.</p>
<h2>Atoms</h2>
<p>Atom are the smallest part of a page or application, for instance, the input box on a page.</p>
<p>So how do we name those atoms?
For an <code>&lt;input /&gt;</code> we set a class of <code>.g-form-input</code>. If we wanted to be more specific for a <code>&lt;input type=&quot;search&quot; /&gt;</code> we could do <code>.g-form-input-search</code> or we could go <code>.g-form-input[type=“search”]</code>, whatever strikes your fancy.
In the same jest, we could approach states like focus, by either providing an extra class <code>.g-form-input-focus</code> or using attribute selectors <code>.g-form-input:focus</code>.</p>
<p>You could even do without the classes all together and go <code>input[type=search]</code>, that only is a different kind of naming, CSS naming is not about classes, it is about how we address things. So if you want to go another way, please do so consistently.</p>
<h2>Molecules</h2>
<p>Atoms make up molecules. So the input from the atom could be located in a search box and there, it would need some different styles. What we are not going to do is make up a new atom for it, we are going to create a class that contains only the difference and add that to the surrounding element like :</p>
<pre><code>&lt;div class=&quot;g-m-search-input&quot;&gt;
&lt;label for=&quot;search&quot;&gt; &lt;/label&gt;
&lt;input id=&quot;search&quot; type=&quot;search&quot; class=&quot;g-form-input g-form-input-search&quot;&gt;
&lt;button class=&quot;g-form-button g-form-button-primary&quot;&gt; &lt;/button&gt;
&lt;/div&gt;
</code></pre>
<p>Where in the CSS, the <code>*.g-m-search-input*</code> will only contain the declarations that make it different, carefully avoiding overwriting any generic styles if we can avoid it.</p>
<h2>Organisms</h2>
<p>Next up in the chain are organisms, things made up of the molecules. Let's say that we have a header organism <code>.g-o-header</code> that contains a search box. If the search box needs any styles different applied to it, we supply it with some extra css, like this:</p>
<pre><code>.g-o-header .m-search-input .g-form-input-search {
foo:bar;
}
</code></pre>
<p>Needless to say, we only need to specify the difference here, not overwrite stuff that is already there...</p>
<h2>Templates</h2>
<p>Next up in our hierarchy are the templates, here is where we put even more stuff together. The atoms, molecules and organisms all on the same kind of page. A search page for instance could go with a class of <code>*.g-t-search*</code> and the results page could have <code>*.g-t-results*</code>.</p>
<h2>Pages</h2>
<p>Finally we have the actual pages, where our templates are used to create actual web pages. Please note that the bulk of the css you will write will be for the Atoms and will diminish as we get down to the molecules and on to the pages. If you have a lot of code for each page, you need to look closely at your atoms and see what you can change there.
Pages come like this <code>*.g-p-awesomeblogpost*</code> and contain only the stuff needed there, like on the page <code>*.g-p-saintpatricksday*</code> you will set the borders of the <code>*.g-form-input-search*</code> to green, as we all know.</p>
<h2>Wrap up and pointers</h2>
<p>So in a nut shell, here is what I do in big projects:</p>
<ul>
<li>I prefix each name with the name of the project or an abbreviation of that name.</li>
<li></li>
<li>Molecules have a -m after that, organisms an -o, templates a -t and pages a -p. By doing this you should make your names easily understandable to all of your team members and you will get new members up to speed in no time.</li>
</ul>
<p>So now you know what a naming convention could look like, I will give you some random pointers that I have found useful.</p>
<h2>Avoid using ID's</h2>
<p>They are too specific and generally cause you more harm than do you good. In a lot of projects ID's are used by backend or JavaScript programmers, so leave them alone.</p>
<h2>Don't over nest</h2>
<p>Ya, I know it sounds daft, with me just giving you all these layers and all. But try to avoid excessive nesting, my rule of thumb is max 4 layers but you can set that to what you like. It is not for performance reasons, but to make debugging easier.</p>
<h2>Avoid the direct &gt; child selector</h2>
<p>It looks nice, doing stuff with that kind of selector, it will make you look really smart and all. But it will bind you to a specific dom construction and that is not something you have total control over at all times.</p>
<p class="note">
(Same goes for the adjacent sibling combinator (+) and the general sibling combinator (~))
</p>
<h2>Talk about it</h2>
<p>This is the most important advice I can give you on CSS naming conventions. There is no ultimate solution for your problem, you have to decide on that with your whole team. If you talk about your naming convention and get everybody on board, it is more probable that everyone will adhere to these conventions.</p>
<h2>Over Wilfred Nas</h2>
<img src="https://www.fronteers.nl/_img/blog/2015/wilfrednas.jpeg" alt="Foto van Wilfred" />
Freelance front end developer, loves to travel by rocket, father of two sons and founding member of the gang of 5. Nuts about html5 forms and semantics.
He writes more at [wnas.nl](http://wnas.nl) and rants on twitter as [@wnas](https://twitter.com/wnas).
</content>
</entry>
<entry>
<title>Fronteers-korting op CSS Day</title>
<link href="https://www.fronteers.nl/nl/blog/2015/03/korting-css-day"/>
<updated>2015-03-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/03/korting-css-day</id>
<content xml:lang="nl" type="html"><p>Op 12 juni 2015 wordt in Amsterdam voor de derde keer CSS Day georganiseerd, een congres over geavanceerde CSS. Fronteers-leden kunnen er dit jaar wederom met 25 euro korting naartoe.</p>
<p><a href="http://cssday.nl/">CSS Day</a> vindt plaats in het Compagnietheater in Amsterdam. Dit jaar spreken onder andere John Daggett, Roy Tomeij en Zoe Mickley Gillenwater. Een ticket is inclusief koffie, thee, lunch en een borrel achteraf.</p>
<p>Voor onze leden hebben we 15 kortingscodes ontvangen. Fronteers-leden die lid waren voor 11 maart kunnen hiermee 25 euro korting op hun ticket krijgen. Om hier gebruik van te maken, neem je contact op met de <a href="https://www.fronteers.nl/nl/vereniging/contact">ledenadministratie</a>..</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij Kabisa op 8 april 2015</title>
<link href="https://www.fronteers.nl/nl/blog/2015/03/bijeenkomst-kabisa"/>
<updated>2015-03-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/03/bijeenkomst-kabisa</id>
<content xml:lang="nl" type="html"><p>Op woensdag 8 april 2015 is Fronteers te gast bij <a href="http://www.kabisa.nl/">Kabisa</a> in Weert. Er worden twee presentaties gehouden.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 uur Ontvangst met buffet &amp; drankje</li>
<li>19:00 uur Rik Schennink - Conditioner.js</li>
<li>19:45 uur Korte pauze</li>
<li>20:00 uur Koen Kivits - Bowser in de browser</li>
<li>20:45 uur Borrel</li>
</ul>
<p>Geen tijd om na je werk nog ergens een hapje te gaan eten? Geen nood: er staat vanaf 18:00u een lekker buffet voor je klaar. Geef even door of je aanschuift, en of je nog speciale dieetwensen hebt.</p>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Kabisa in Weert. <a href="https://www.fronteers.nl/bijeenkomsten/2015/kabisa">Er is een kaart beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Voor wie?</h2>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2015/kabisa">Meld je daarom aan via het aanmeldformulier.</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Kom flexwerken met Fronteersleden!</title>
<link href="https://www.fronteers.nl/nl/blog/2015/02/kom-flexwerken-met-fronteers-leden"/>
<updated>2015-02-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/02/kom-flexwerken-met-fronteers-leden</id>
<content xml:lang="nl" type="html"><p>Een nieuw soort bijeenkomst voor Fronteersleden: kom samen flexwerken én kennis delen op woensdag 25 maart 2015 in Utrecht. Zaal, koffie én lunch zijn voor onze rekening, doe je mee?</p>
<p>Op woensdagochtend 25 maart organiseert de activiteitencommissie een bijeenkomst bij Seats2meet in Utrecht. De vraag kwam van freelancers en ZZP'ers: kunnen jullie ook eens iets voor ons organiseren? Natuurlijk, neem je laptop en kabels mee en ga samen aan de slag of op ontdekkingstocht. Ook als je geen freelancer bent, ben je welkom. Altijd al iets willen uitzoeken, maar nog geen tijd gevonden? Wil je op weg geholpen worden? Start met schrijven van een artikel voor onze site, maak een presentatie af en bespreek de opzet, of help mee een bijeenkomst te organiseren. Vul maar in!</p>
<p>Na een kort voorstelrondje ga je aan de slag en voor je het weet is het al tijd om aan te schuiven aan het lunchbuffet. Meer info is te vinden op de <a href="https://www.fronteers.nl/bijeenkomsten/2015/flexwerken-maart">pagina van deze bijeenkomst</a>.</p>
<h2>Wie?</h2>
<p>Ieder Fronteerslid, beginner of gevorderd is welkom. Er is echter beperkt plaats, voor circa 15 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 12 maart bij Digiti</title>
<link href="https://www.fronteers.nl/nl/blog/2015/02/bijeenkomst-digiti"/>
<updated>2015-02-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/02/bijeenkomst-digiti</id>
<content xml:lang="nl" type="html"><p>Op donderdag 12 maart 2015 is Fronteers te gast bij Digiti in Zoersel. Er worden twee presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met een hapje en een drankje</li>
<li>19:00 Saskia Videler over <em>Content-strategie</em></li>
<li>20:00 Bert Timmermans over <em>Minecraft in de browser</em></li>
<li>21:00 naborrelen</li>
</ul>
<p>Dit evenement vindt plaats bij Digiti te Zoersel. <a href="https://www.fronteers.nl/bijeenkomsten/2015/digiti">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij inSided op 24 februari 2015</title>
<link href="https://www.fronteers.nl/nl/blog/2015/02/bijeenkomst-insided"/>
<updated>2015-02-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/02/bijeenkomst-insided</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 24 februari 2015 is Fronteers te gast bij <a href="http://www.insided.com/">inSided</a> in Amsterdam. Er worden drie presentaties gehouden.</p>
<h2>Het programma is als volgt:</h2>
<p>18:00 uur Ontvangst met hapje &amp; drankje
19:00 uur Anne Ties van Vliet - How we use modular Sass at inSided
19:30 uur Korte pauze
19:45 uur Mauro Mandracchia - A new custom font rendering tool and workflow
20:15 uur Korte pauze
20:30 uur Flurin Egger - Skynet.js
21:00 uur Borrel</p>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij inSided in Amsterdam. <a href="https://www.fronteers.nl/bijeenkomsten/2015/insided">Er is een kaart beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Voor wie?</h2>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 60 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>CSS Resets</title>
<link href="https://www.fronteers.nl/nl/blog/2015/01/css-resets"/>
<updated>2015-01-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2015/01/css-resets</id>
<content xml:lang="nl" type="html"><p>Wat betekenen ‘reset’ en ‘normalize’ eigenlijk? Hebben deze termen wel met elkaar te maken? En wat moet je er mee als front-ender?</p>
<h2>Wat doet de CSS reset?</h2>
<p>Elke browser gebruikt een <a href="http://css-class.com/test/css/defaults/UA-style-sheet-defaults.htm">standaard styling</a> voor het weergeven van de HTML elementen. Denk hierbij aan de grootte van het lettertype, de kleur en het onderstrepen van linkjes, of de witruimte (paddings of margins) van elementen zoals de <code>&lt;p&gt;</code> of <code>&lt;h1&gt;</code> tag. Niet elke browser gebruikt exact dezelfde standaard layout. Hierdoor kan je design er net iets anders uitzien in de verschillende browsers.
De WHATWG heeft in haar <a href="https://html.spec.whatwg.org/multipage/rendering.html#rendering">HTML standard suggesties</a> aangebracht voor welke CSS de browser bouwers het beste zouden kunnen gebruiken zodat de HTML het beste weergegeven wordt zoals een front-end ontwikkelaar of zoals de WHATWG het noemt een document author het bedoeld zou hebben. Ze borduren hiermee verder op wat de W3C ooit begonnen was voor <a href="http://www.w3.org/TR/CSS1/#appendix-a">CSS1</a>, <a href="http://www.w3.org/TR/CSS2/sample.html">CSS2</a> en <a href="http://www.w3.org/TR/CSS21/sample.html">CSS2.1</a>.</p>
<p>Om de verschillen tussen browsers te ondervangen zijn er CSS resets en CSS normalizers.</p>
<p>Een CSS reset overschrijft de standaard layout van een browser met simpele, neutrale basiswaardes. Alle elementen in een HTML document krijgen zo dezelfde font-size, padding, margin, line-height, etc. De tekst in een <code>&lt;h1&gt;</code> is dus even groot als in een <code>&lt;small&gt;</code>. Het is aan de developer om vanaf dit neutrale, blanco stylesheet zijn eigen styling op te bouwen. Zoals Jeff Starr schrijft: “Het geeft de bouwer een uniforme fundering om verder op te kunnen bouwen”. (<a href="http://perishablepress.com/a-killer-collection-of-global-css-reset-styles/">Jeff Starr: Killer Collection of CSS Resets</a>)</p>
<p>Op <a href="http://cssresetr.com/">cssresetr.com</a> kun je zien wat verschillende resets doen. Hier zie je dat de verschillende resets ook echt verschillende zaken resetten.</p>
<h2>Welke resets zijn er eigenlijk?</h2>
<p>Jeff Starr heeft in zijn artikel <a href="http://perishablepress.com/a-killer-collection-of-global-css-reset-styles/">Killer Collection of CSS Resets</a> verschillende CSS-resets opgenomen. In augustus 2013 is het artikel geüpdatet. Het valt op dat de eerste resets vrij globaal starten met een * en een padding en margin van 0, tot aan specifiek benoemde HTML tags. Deze laatste levert dan ook een behoorlijk verhaal op. Op Sixrevisions is <a href="http://sixrevisions.com/css/the-history-of-css-resets/">de geschiedenis van de css reset</a> beschreven. Hier staan verschillende resets benoemt. Interessant om eens door te nemen.</p>
<h2>Normalize</h2>
<p>Een CSS reset is nogal rigoureus. Kritiek op de eerste generatie resets was bijvoorbeeld dat ze hulpzame features als :focus-styles weghaalden. Hierdoor zag je geen visuele feedback als je een link of form-element focus gaf. Dat zag er mooier uit, maar maakte de site slecht bruikbaar voor mensen die met keyboard navigeren of met hulpmiddelen surfen. Er kwam behoefte aan een opvolger die daar beter mee omging: een “normalizer”, bijvoorbeeld de <a href="http://nicolasgallagher.com/about-normalize-css/">normalize van Nicolas Gallagher</a>.</p>
<blockquote></blockquote>
<blockquote></blockquote>
<p>Niet iedereen gebruikt Normalize. Er zijn ook ontwikkelaars die CSS resets gebruiken. Zoals Flurin Egger, hij gebruikt CSS resets. <a href="https://twitter.com/flurin/status/516963529749172226">Zijn reactie</a> na een vraag op twitter wat ontwikkelaars gebruiken, een reset of normalize: “Resets: een 0-like baseline, ik heb mijn eigen minimale versie. Normalizers = opinionated resets :)”</p>
<h2>Moet je je CSS resetten?</h2>
<p>Het idee achter de reset is dat je gelijk ogende websites bouwt voor elke browser. We zien steeds meer stemmen opgaan dat dit niet hoeft en ook zeker niet meer kan. Hierdoor lijkt de CSS reset aan waarde te verleizen. We hoeven als Front-end ontwikkelaar niet alles meer in de hand te houden. Elke browser mag zijn/haar eigenaardigheden hebben.</p>
<p>Afhankelijk van het project waar je mee bezig bent bepaal je of je de CSS een reset meegeeft. Je hebt niet altijd alle HTML tags nodig die in een standaard reset zitten. Juist dit laatste is heel belangrijk. Kijk goed naar een standaard reset en haal er uit wat je nodig hebt en neem het niet klakkeloos over.</p>
<h2>Wat vinden andere front-enders van resets?</h2>
<blockquote></blockquote>
<blockquote></blockquote>
<h2>TL;DR</h2>
<p>Voor een front-end ontwikkelaar is het belangrijk om ervaring op te doen en te testen wat voor hem/haar handig is om te gebruiken. Elk project heeft andere uitdagingen en je kan klakkeloos een reset overnemen, maar zijn alle zaken in de reset echt nodig voor je project? Vaak niet. Voor front-end ontwikkelaars is belangrijk dat wij weten wat browsers doen, dat we weten wat HTML en CSS doet. We moeten leren hierop in te springen en mee te werken.</p>
<p>In dit artikel heb ik geen CSS resets opgenomen, want ik kan niet overzien welke reset het nuttigst is voor jou. Mijn bedoeling was inzicht te geven in wat een CSS reset precies is.
Leer hoe de browsers werken; hoe gaan ze om met de verschillende HTML-tags en welke verschillen worden veroorzaakt tussen de verschillende browsers? Hoe beïnvloedt dat een design dat je aan het bouwen bent?</p>
<p><a href="http://meyerweb.com/eric/thoughts/2007/04/18/reset-reasoning/">Eric Meyer gaf in 2007 al aan</a>: “Een CSS reset is om je aan het denken te zetten en niet om deze standaard te gebruiken”.</p>
<p>Gebruik jij een reset? Zo ja, welke en waarom? Zo nee, waarom niet?</p>
<h2>Links:</h2>
<ul>
<li><a href="https://html.spec.whatwg.org/multipage/rendering.html">Whatwg: Rendering</a></li>
<li><a href="http://perishablepress.com/a-killer-collection-of-global-css-reset-styles/">Jeff Starr: Killer Collection of CSS Resets (2007 / 2013)</a></li>
<li><a href="http://cssresetr.com/">* { CSS:resetr }</a></li>
<li><a href="http://www.iecss.com/">IE CSS</a></li>
<li><a href="http://sixrevisions.com/css/the-history-of-css-resets/">Michael Tuck: The History of CSS Resets (2010)</a></li>
<li><a href="http://nicolasgallagher.com/about-normalize-css/">Normalize van Nicolas Gallagher</a></li>
<li><a href="http://meyerweb.com/eric/thoughts/2007/04/18/reset-reasoning/">Eric Meyer: Reset Reasoning (2007)</a></li>
</ul>
<h2>Interessante artikelen om te lezen die niet genoemd zijn in de tekst:</h2>
<ul>
<li><a href="http://html5doctor.com/html-5-reset-stylesheet/">Richard Clark: HTML5 Reset Stylesheet (2009)</a></li>
<li><a href="http://csswizardry.com/2011/10/reset-restarted/">Harry Roberts: Reset restarted (2011)</a></li>
<li><a href="http://meiert.com/en/blog/20080419/reset-style-sheets-are-bad/">Jens Oliver Meiert: Why “Reset” Style Sheets Are Bad (2008)</a></li>
</ul>
<h2>Over Kaj Rietberg</h2>
<p>blog/2014/kajrietberg.png
Kaj is Front-end ontwikkelaar bij Zorgweb in Zwolle. Zijn specialisaties zijn webforms, CSS, CSS-architectuur, Sass en hij verdiept zich momenteel in het responsive bouwen van webformulieren met grote tabellen.</p>
</content>
</entry>
<entry>
<title>Hallo frontenders, hier spreekt een ontwerper</title>
<link href="https://www.fronteers.nl/nl/blog/2014/12/hallo-frontenders"/>
<updated>2014-12-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/12/hallo-frontenders</id>
<content xml:lang="nl" type="html"><p>Maaike de Laat deed tijdens de Jam Sessions van het Fronteers-congres namens ontwerpers een oproep aan front-enders. Deze presentatie heeft ze met Marrije Schaake uitgeschreven tot dit artikel. Haar talk, 'A Call To Arms', in het Engels, <a href="https://www.fronteers.nl/nl/blog/2014/12/%5Ccongres/2014/jam-session/call-to-arms">is terug te kijken bij de Jam Session video's</a>.</p>
<h2>Hallo Frontenders</h2>
<p>Ik heb een verzoek aan jullie, namens de grafisch ontwerpers. Nou ja, ik heb het ze niet allemaal gevraagd, maar ik denk dat veel ontwerpers het wel met me eens zullen zijn.</p>
<p>We hebben jullie hulp nodig. Jullie kunnen ons helpen om webontwerp beter te maken, om het naar het volgende niveau te tillen. Ik zal het zo uitleggen, maar kijk eerst eens naar dit plaatje:</p>
<p><img src="https://www.fronteers.nl/_img/blog/2014/benz-patent-motorwagen-nummer-1-02.jpg" alt="Benz Motowagen" /></p>
<p>Dit is de Benz Motorwagen. Hij werd ontworpen door Karl en Bertha Benz in 1886, en hij wordt door veel mensen beschouwd als de allereerste auto. Dat wil zeggen – er waren eerder ook al wel auto-achtige voertuigen, maar dat waren gewoon koetsen waarbij de bouwers het paard weghaalden en er een motor voor terugplaatsten.</p>
<p>Deze auto was de eerste die echt ontworpen is om gebruikt te worden met een motor. Maar toch lijkt hij nog erg veel op een koets! Koetsen waren wat de mensen kenden. Het duurde een tijdje voordat de auto-ontwerpers bedachten welk soort ontwerp het beste werkt voor een automobiel. En voordat handelaars nieuwe toepassingen bedachten voor de auto.</p>
<h2>Horseless Carriage Syndrome</h2>
<p>In de jaren zestig van de twintigste eeuw noemde Marshall McLuhan dit het ‘<em>Horseless Carriage Syndrome</em>’ (het ‘paardloze koets-syndroom’): nieuwe technologieën beginnen altijd met het imiteren van wat er eerder was. Dat hoeft niet per se een probleem te zijn: mensen vinden het makkelijker om iets te begrijpen als het lijkt op iets dat ze kennen. Maar na verloop van tijd wordt het een beperking.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2014/apple-macintosh-desktop.png" alt="Een Apple Macintosh desktop uit begin jaren tachtig" /></p>
<p>Kijk bijvoorbeeld eens naar de eerste GUI's (Graphical User Interfaces) van computers. De metafoor van het bureaublad was nuttig: het hielp mensen te begrijpen wat een PC allemaal kon. Op het bureaublad van de PC bevonden zich mappen met documenten erin, een rekenmachine, een prullenbak... Net zoals bij een echt bureau. Maar inmiddels kunnen computers heel veel dingen die niets te maken hebben met echte bureaus – en dan wordt de metafoor een last.</p>
<p>Laten we nu eens naar webontwerp kijken. Toen ik begon als ontwerper, eind jaren negentig, was het heel hip om achtergronden met een structuurtje te gebruiken in websites. Je kent ze vast nog wel, een mooi gekreukeld papiertje, of een kek houtnerfje. Ik heb zelfs een ontwerp gevonden waar ze allebei inzitten!</p>
<p><img src="https://www.fronteers.nl/_img/blog/2014/david-hasselhoff-screenshot-van-een-prachtige-jaren-negentig-website.jpg" alt="Een screenshot van een prachtige jaren-negentig website" /></p>
<p>Mooi, toch?</p>
<p>En het is niet zo gek dat we dit deden, want in die tijd hadden veel webontwerpers een traditionele grafisch-ontwerpachtergrond. En als je drukwerk ontwerpt is het heel belangrijk om rekening te houden met de eigenschappen van het materiaal dat je gebruikt. Je kunt kiezen uit allerlei soorten papier, variërend van glad en glanzend tot heel grof, en dit heeft letterlijk veel invloed op de <em>look &amp; feel</em> van je ontwerp. Maar computerschermen zijn altijd hetzelfde: koud en hard. Dat was even wennen voor ons ontwerpers! En misschien ook voor ons publiek.</p>
<p>Zoals je vast wel weet, heet deze gewoonte om een website of een interface te laten lijken op een fysiek object ‘skeuomorfisme’. En waarschijnlijk hadden we dit allemaal een beetje nodig, terwijl we langzaam gewend raakten aan digitaal ontwerp. De afgelopen jaren is er natuurlijk veel gedebatteerd over skeuomorfisme, en het lijkt nu wel aan zijn einde te komen. En dan is de vraag: wat komt er nu?</p>
<h2>Ken je materialen</h2>
<p>Ik denk dat goed ontwerp voortkomt uit een gedegen kennis van de materialen waar je mee werkt. Lang is het zo geweest dat dit voor ontwerpers min of meer met de paplepel ingegoten werd. Voor de twintigste eeuw bestond ‘grafisch ontwerper’ niet eens als een apart beroep. De persoon die het werk maakte was tegelijkertijd de ontwerper.</p>
<p><img src="https://www.fronteers.nl/_img/blog/2014/inscription-theatre-leptis-magna-libya.jpg" alt="Een foto van een Romeins theater met inscriptie" /></p>
<p>In het Romeinse rijk, bijvoorbeeld, was degene die de inscripties maakte op een monument ook de ontwerper van de inscriptie. En na de uitvinding van de drukpers waren de mensen die de drukpersen bedienden ook de ontwerpers van de producten die ze drukten.</p>
<p>Vanaf de jaren vijftig van de vorige eeuw, toen de reclame-industrie een grote vlucht nam, werd ontwerp een echt beroep. Maar ook nu weten ontwerpers gewoonlijk nog prima hoe een drukpers werkt en wat je met verschillende soorten inkt, papier en boekbindtechnieken kunt. De drukwerkwereld is nogal langzaam en conservatief, dus dit is altijd goed te doen gebleven.</p>
<p>In de digitale wereld ligt dat echter heel anders. En dat, lieve frontenders, is waarom we jullie nodig hebben.</p>
<p>We zijn allemaal wel op de hoogte van de discussie over of ontwerpers ook moeten programmeren. Over die discussie zal ik het nu niet hebben, want dat lijkt me niet zo nuttig. Het is geweldig als een ontwerper kan programmeren, maar er zijn veel ontwerpers die het niet kunnen, en ze gaan het echt niet leren alleen omdat jij zegt dat het moet.</p>
<p>Maar dan nog moeten ontwerpers hun medium wel goed begrijpen om goed werk te kunnen maken. Ze moeten snappen hoe webpagina's werken, wat je kunt doen met HTML, CSS and JavaScript – en vooral ook wat je <em>niet</em> kunt doen.</p>
<p>Ontwerpers zullen namelijk altijd ontwerpen. En als ze tegemoet zijn gekomen aan de wensen van de klant en de behoeften van de klant, als ze hebben nagedacht over concepten en <em>branding</em> en gebruiksvriendelijkheid, hebben ze ook gewoon zin om nieuwe dingen te proberen. Om te experimenteren. Veel ontwerpers bezoeken websites met voorbeelden van interessant ontwerp, zoals It's Nice That, ontelbaar veel webdesign <em>showcases</em> en zelfs Pinterest. En als ze iets zien dat ze mooi vinden, zullen ze waarschijnlijk iets soortgelijks proberen te maken. Ook als dat betekent dat jij 5 JavaScript libraries, 8 webfonts en 500 mb aan plaatjes nodig hebt om het te bouwen.</p>
<p>En natuurlijk kun je daar over mopperen, maar tegen die tijd is de ontwerper waarschijnlijk al verliefd geworden op zijn of haar eigen ontwerp. En als je echt pech hebt, is de klant dat ook.</p>
<h2>Past het bij het medium?</h2>
<p>Het probleem met deze ontwerpsites is dat ze nooit uitleggen hoe iets gebouwd is, en of een ontwerp technisch wel goed in elkaar zit. Als je zelf geen frontender bent, kan het heel moeilijk zijn om te beoordelen of een bepaald effect of een ontwerpoplossing moeilijk te bouwen of te onderhouden is, of dat het bijvoorbeeld slecht voor de performance is. Met andere woorden: of het een elegante oplossing is die goed bij het medium past. Of, met nog andere woorden: of je hier te maken hebt met een <em>horseless carriage</em>.</p>
<h2>En jij dan?</h2>
<p>Maar laten we het eens over jou hebben. Jij bezoekt waarschijnlijk heel andere websites. Sites als <a href="http://alistapart.com/">A List Apart</a> en <a href="http://www.smashingmagazine.com/">Smashing Magazine</a>, waar je leest over CSS3-dingen die je eindelijk kunt gebruiken, of misschien een nieuwe lichtgewicht JavaScript library waarmee je allerlei coole dingen kunt doen.</p>
<p>Interessant, toch? Zowel jij als de ontwerper willen graag experimenteren. Jullie zijn beiden op zoek naar nieuwe ideeën. Zou het niet veel beter zijn als jullie allebei experimenteren met dezelfde dingen?</p>
<h2>Houd contact met je ontwerpers</h2>
<p>Er zijn een aantal dingen die je zou kunnen proberen. Allereerst: zorg er voor dat je contact houdt met je collega's die ontwerp doen, vooral tussen projecten in, als er geen (tijds)druk is. En steeds als je een interessant nieuw iets leert, zou je ze er over kunnen vertellen. “Hee kijk, ik heb ontdekt hoe ik deze mooie animaties kan maken!” Of “Hee, wist je dat ik nu verloopjes kan maken met CSS, zodat ik er nu niet meer zo ongelukkig van word als je ze gebruikt in je ontwerpen?”</p>
<p>Met een paar collega's heb ik de website <a href="http://achterhetscherm.nl/">Achter het Scherm</a>, een serie interviews over hoe mensen samen aan webprojecten werken. Voor deze website hebben we de afgelopen tijd gesproken met een aantal ontwerpers en ontwikkelaars, en ze gevraagd hoe ze elkaar op de hoogte houden van nieuwe ontwikkelingen. En ze hadden een paar erg goede ideeën, die jij ook zou kunnen gaan toepassen, als je dat nog niet doet.</p>
<p>Sommige bedrijven hebben bijvoorbeeld een e-maillijst voor alle medewerkers. Sommige teams houden regelmatig korte bijeenkomsten waarbij iedereen laat zien waar ze mee bezig zijn en wat ze de laatste tijd geleerd hebben. Sommige organisaties hebben multidisciplinaire weblogs. Sommige gebruiken online communicatiemiddelen zoals <a href="https://slack.com/">Slack</a> (❤). En sommige mensen gaan gewoon naast elkaar zitten en praten over wat ze aan het doen zijn. Probeer het eens!</p>
<p>Denk eens na: je bent hier bij Fronteers om jezelf onder te dompelen in front-end ontwikkeling. Hoe ga je de dingen die je hier leert delen met je collega's op je werk? Als je je inspant om je ontwerpvrienden op de hoogte te houden van jouw vakgebied, zul je hopelijk merken dat ze je suggesties ter harte nemen. Dit maakt jouw werk leuker, en jullie werk zal er beter van worden.</p>
<p>Ik weet ook wel dat wat ik hier zeg niet nieuw is. Maar ik denk wel dat het vaker gezegd moet worden! Wij ontwerpers hebben jullie echt nodig, zelfs als we het onszelf niet altijd realiseren ;-)</p>
<h2>Over Maaike de Laat</h2>
<img src="https://www.fronteers.nl/_img/blog/2014/maaikedelaat.png" alt="Foto van Maaike uit 2014" class="floating-portrait" />
<p>Maaike is ontwerper bij <a href="http://eend.nl/">eend</a>. <a href="https://twitter.com/maaike">Volg haar op twitter</a>.</p>
</content>
</entry>
<entry>
<title>Yes, we starten met artikelen!</title>
<link href="https://www.fronteers.nl/nl/blog/2014/12/artikel-start"/>
<updated>2014-12-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/12/artikel-start</id>
<content xml:lang="nl" type="html"><p>We zijn nu een paar maanden bezig geweest en eindelijk kunnen we het goede nieuws verspreiden: we starten met het plaatsen van artikelen over front-endwetenswaardigheden!</p>
<p>Op onze website kunnen jullie al veel <a href="https://www.fronteers.nl/videos">video's</a> vinden over veel verschillende onderwerpen binnen ons vakgebied. Voor degene die graag video kijken een goede manier om informatie tot zich te nemen, maar voor de lezers onder ons mist er iets. Daarom starten we met het plaatsen van artikelen over front-endwetenswaardigheden op het Fronteers weblog.</p>
<p>Het plan is om maandelijks één artikel te plaatsen. Het eerste artikel dat we plaatsen is van Maaike de Laat. Zij hield een talk tijdens de Jam Session van de Fronteers-congres en vertaalde dit naar een artikel voor ons weblog. Voor volgende maand hebben we het artikel ook klaar staan. Verder zijn verschillende Fronteers leden bezig met een artikel voor ons weblog. Er gaat nog veel moois komen.</p>
<p>Fronteersleden hebben heel veel kennis over heel veel verschillende onderwerpen. We willen hun graag een podium bieden. De artikelen zijn bedoeld voor:</p>
<ul>
<li>beschouwingen</li>
<li>tips, trucs en <em>best practices</em></li>
<li>het uitlokken van discussie</li>
</ul>
<p>Lijkt het je leuk om ook een artikel te schrijven laat het ons weten: <a href="https://www.fronteers.nl/nl/vereniging/contact/">neem contact op</a> met Kaj Rietberg of Paul van Buuren en vertel ons waarover jij wilt schrijven. Wij helpen je met schrijven. Help andere Fronteerleden met jouw kennis; je weet meer dan je denkt!</p>
</content>
</entry>
<entry>
<title>Fronteers Nieuwjaarsborrel 2015</title>
<link href="https://www.fronteers.nl/nl/blog/2014/11/nieuwjaarsborrel-2015"/>
<updated>2014-11-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/11/nieuwjaarsborrel-2015</id>
<content xml:lang="nl" type="html"><p>Een nieuw jaar, tijd voor de Fronteers nieuwjaarsborrel, speciaal voor leden!</p>
<p>Op vrijdag 16 januari 2015 organiseert Fronteers een Nieuwjaarsborrel voor leden. Deze zal plaatsvinden in Grand Cafe Lebowski, in Utrecht, maar dan wel in de grote zaal boven. <a href="https://www.fronteers.nl/blog/2013/12/nieuwjaarsborrel">Vorig jaar</a> bleek <a href="https://www.fronteers.nl/blog/2013/12/nieuwjaarsborrel#reacties">het enthousiasme</a> om te borrelen enorm en daardoor de ruimte bij Lebowski wat krap. Dit jaar is er ruimte voor 80 personen. Rond 17:30 uur zullen de eerste leden aanwezig zijn en de eerste drankjes worden betaald door de vereniging.</p>
<p>Grand Café Lebowski in Utrecht heeft veel lekkere bieren, ook van de tap. En bij een borrel horen (lekker veel en lekker vette) hapjes.</p>
<h2>Locatie</h2>
<p>Domplein 17, naast de Dom in Utrecht, ongeveer 10 minuten lopen van Utrecht Centraal Station. Op de website van Grand Café Lebowski vind je de routebeschrijving.
Parkeren in Utrecht is geen probleem, maar bekijk wel even de tarieven. Kies voor garage Springweg of één van de andere parkeergarages rond Hoog Catharijne.</p>
<h2>Nog meer borrelen?</h2>
<p>Op donderdag 8 januari is er een nieuwjaarsreceptie van ISOC, ook daar kun je leden van Fronteers tegenkomen. <a href="https://www.fronteers.nl/blog/2014/11/nieuwjaarsreceptie-isoc">Lees hier verder.</a></p>
<h2>Aanmelden</h2>
<p>Ben je lid van Fronteers en doe je mee? Meld je dan aan.</p>
</content>
</entry>
<entry>
<title>Meld je nu aan voor de ALV 2014</title>
<link href="https://www.fronteers.nl/nl/blog/2014/11/aanmelden-alv-2014"/>
<updated>2014-11-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/11/aanmelden-alv-2014</id>
<content xml:lang="nl" type="html"><p>Op dinsdagavond 2 december houden we onze jaarlijkse algemene ledenvergadering (ALV). Alle leden zijn hiervoor van harte uitgenodigd. De locatie van de ALV is Zalencentrum Se7en, in zaal 2 (toegang via <a href="http://www.sevenutrecht.nl/">Restaurant Se7en</a>), ongeveer vijf minuten lopen vanaf Utrecht CS (Mariaplaats 7). Dit is, los van een naamswijziging, dezelfde locatie als vorig jaar.</p>
<p>We beginnen om 19:00 uur en hopen deze keer toch <em>écht</em> niet langer dan drie uur nodig te hebben. Voor de mensen die van ver komen regelen we een broodmaaltijd, welke vanaf 18:30 beschikbaar zal zijn. Geef bij je aanmelding even aan dat je hier gebruik van wilt maken.</p>
<p>De agenda voor de avond is als volgt:</p>
<ol>
<li>Welkom en opening door de voorzitter</li>
<li>Besluiten eerdere ALV’s</li>
<li>Toelichting commissies</li>
<li>Rapportage kascommissie 2013</li>
<li>Jaarstukken 2013 / Financiën 2014 / Begroting 2015</li>
<li>Kascommissieverkiezing</li>
<li>Voorstel ledenadministratie buiten bestuur</li>
<li>Aftreden Krijn en Vasilis, bestuursverkiezing</li>
<li>Rondvraag</li>
<li>Afsluiting</li>
</ol>
<p>In de nieuwsbrief die op 19 november is verstuurd staan meer details en een toelichting op de verschillende agenda-onderwerpen.</p>
<p>Dit jaar treden Vasilis van Gemert en Krijn Hoetmer af. Twee nieuwe leden hebben zich aangemeld voor een positie in het bestuur, te weten Hidde de Vries en Jaco Koster. Beide presenteren zich hieronder.</p>
<blockquote>
<p>Hallo! Mijn naam is Hidde de Vries, en ik stel mij dit jaar verkiesbaar als bestuurslid van Fronteers. In die positie hoop ik te kunnen bijdragen aan het behartigen van de belangen van onze leden. Kort over mezelf: ik ben freelance front-end ontwikkelaar, en ik heb veel hart voor de front-end community.</p>
</blockquote>
<blockquote>
<p>Ik ben <a href="http://nl.linkedin.com/in/jacokoster/">Jaco Koster</a>, 30 jaar oud, als <a href="http://frontmen.nl/">Frontmen</a> gedetacheerd bij een oranje bank en woon ik, samen met mijn vriendin en zoon, in het prachtige Montfoort. In mijn vrije tijd ben ik leiding bij de <a href="http://scoutingflevo.com/zee/">scouting</a>, speel ik online een <a href="http://eu.battle.net/sc2/en/">spelletje</a> of loop ik onzin uit te kramen op <a href="https://twitter.com/jacokoster">Twitter</a> of <a href="https://webchat.freenode.net/?channels=fronteers">IRC</a>.</p>
</blockquote>
<p>Ben je van plan te komen, dan vragen we je vriendelijk je hieronder hiervoor in te schrijven, zodat we een idee hebben van de te verwachten opkomst.</p>
<h2>Aanwezigen</h2>
<ul>
<li>Sander van Lambalgen</li>
<li>Matijs Brinkhuis</li>
<li>Krijn Hoetmer</li>
<li>Arjan Eising</li>
<li>Roy Tomeij</li>
<li>Vasilis van Gemert</li>
<li>Wesley Lancel</li>
<li>Jaco Koster</li>
<li>Peter-Paul Koch</li>
<li>Tom Greuter</li>
<li>Meta Kruijs</li>
<li>Thomas van Zuijlen</li>
<li>Sander Aarts</li>
<li>Joël Kuijten</li>
<li>Wim van Iersel</li>
<li>Jarno de Wit</li>
<li>Jules Ernst</li>
<li>Edwin Martin</li>
<li>Tom Hartwig</li>
</ul>
</content>
</entry>
<entry>
<title>Bijeenkomst op 27 november bij De Persgroep</title>
<link href="https://www.fronteers.nl/nl/blog/2014/11/bijeenkomst-persgroep"/>
<updated>2014-11-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/11/bijeenkomst-persgroep</id>
<content xml:lang="nl" type="html"><p>Op donderdag 27 november 2014 is Fronteers te gast bij De Persgroep Publishing in Asse (Kobbegem). Er worden drie presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met broodjes en een drankje</li>
<li>19:00 <a href="https://twitter.com/Bizonder">Harald Bertels</a> over <em>Design collaboration</em></li>
<li>19:30 <a href="https://twitter.com/FirstManOnDaMoo">Pieter Mergan</a> over <em>Schema.org microdata</em></li>
<li>20:15 <a href="https://twitter.com/joggink">Jochen Vandendriessche</a> over <em>Large Scale JavaScript Design Patterns (and how we use them at De Persgroep)</em></li>
<li>21:00 naborrelen</li>
</ul>
<p>Dit evenement vindt plaats bij De Persgroep Publishing te Asse (Kobbegem). <a href="https://www.fronteers.nl/bijeenkomsten/2014/persgroep">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 60 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Nieuwjaarsreceptie ISOC</title>
<link href="https://www.fronteers.nl/nl/blog/2014/11/nieuwjaarsreceptie-isoc"/>
<updated>2014-11-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/11/nieuwjaarsreceptie-isoc</id>
<content xml:lang="nl" type="html"><p>De datum voor nieuwjaarsborrel, georganiseerd door de overkoepelende organisatie voor internetinstanties, Internet Society Nederland, is bekend: donderdag 8 januari 2015 in de Tolhuistuin in Amsterdam. Je kunt je nu aanmelden. You’re Invited to the 2015 Internet New Year's Event In Amsterdam!</p>
<p>Op de nieuwjaarsreceptie van ISOC Nederland ontmoet je meer dan dertig nationale en internationale spelers uit de internetwereld. Van e-infrastructuur tot .nl, van digitale burgerrechten tot en met digitale certificaten, van toegankelijkheid voor blinden tot hosting providers - iedereen doet mee. En natuurlijk is vakvereniging Fronteers één van die spelers.
Er zijn hapjes, drankjes, lightning talks en netwerkmogelijkheden. De startijd, het programma en alle details <a href="http://isoc.nl/activ/2015-newyear.htm">vind je op de website van ISOC</a>.</p>
<h2>Locatie</h2>
<p>De borrel wordt gehouden bij <a href="http://www.tolhuistuin.nl/de-tolhuistuin/bereikbaarheid">De Tolhuistuin, Buiksloterweg 5c, 1031 CC Amsterdam</a>.</p>
<h2>Aanmelden bij ISOC</h2>
<p><a href="http://isoc.nl/activ/2015-newyear.htm">Aanmelden kan gratis op de website van ISOC</a>.
Aanmelden kan niet via de website van Fronteers. Laat Fronteersleden wél weten dat je komt, reageer hieronder en/of tweet met hashtag #fronteers.</p>
<h2>Bijdragen of kennis delen?</h2>
<p>Wil je spreken, dan kun je een voorstel voor een lightning talk van maximaal 10 minuten mailen aan <a href="mailto:ny2015pc@ripe.net">ny2015pc@ripe.net</a>. Doe dat vóór 15 december 2014.
Als je een voorstel voor een lightning talk inschiet, zeg er even bij dat je dat namens Fronteers doet.</p>
<h2>Vragen?</h2>
<p><a href="https://www.fronteers.nl/vereniging/commissies/activiteiten">Neem contact op met de Activiteitencommissie</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij Blendle op 25 november 2014</title>
<link href="https://www.fronteers.nl/nl/blog/2014/10/bijeenkomst-blendle"/>
<updated>2014-10-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/10/bijeenkomst-blendle</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 25 november 2014 is Fronteers te gast bij <a href="http://www.blendle.nl/">Blendle</a> in Utrecht. Er worden twee presentaties gehouden.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>19:00 uur Ontvangst met hapje &amp; drankje <em>(Let op: uurtje later dan normaal.)</em></li>
<li>19:45 uur Jesse Dijkstra - &quot;Front-end bij Blendle&quot;</li>
<li>20:30 uur Korte pauze</li>
<li>20:45 uur Paul van Buuren - &quot;Edge Case Design&quot;</li>
<li>21:30 uur Borrel</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Blendle in Utrecht. <a href="https://www.fronteers.nl/bijeenkomsten/2014/blendle">Er is een kaart beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Voor wie?</h2>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 150 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/blendle">Meld je daarom aan via het aanmeldformulier.</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Algemene Ledenvergadering 2014: 2 december</title>
<link href="https://www.fronteers.nl/nl/blog/2014/10/datum-alv"/>
<updated>2014-10-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/10/datum-alv</id>
<content xml:lang="nl" type="html"><p>De datum voor onze jaarlijkse ledenvergadering is bekend: op dinsdagavond 2 december 2014 zullen we alweer voor de achtste keer bij elkaar komen om het reilen en zeilen van de vereniging te bespreken. Reserveer deze avond dus alvast in je agenda.</p>
<p>De locatie is dezelfde als vorig jaar: <a href="http://www.sevenutrecht.nl/">se7en</a>, Mariaplaats 7, 3511 LH, in Utrecht. We beginnen hier rond 19 uur en proberen de laatste hamer om 22 uur op tafel te laten landen.</p>
<p>Op de exacte agenda komen we later nog terug, maar denk aan de terugkoppeling van <a href="https://www.fronteers.nl/vereniging/commissies">onze verschillende commissies</a>, de <a href="https://www.fronteers.nl/vereniging/bestuur">bestuursverkiezing</a>, en het doornemen van de begroting en nieuwe beleidsvoorstellen.</p>
<p>Ook de bestuursverkiezing zal weer gehouden worden. Krijn Hoetmer is dit jaar aan de beurt voor aftreden en zal zich <strike>opnieuw</strike> <strong>niet</strong> herkiesbaar stellen. Vasilis van Gemert heeft jammer genoeg besloten zijn rol in het bestuur neer te leggen. Aangezien we van mening zijn dat zes bestuursleden de ideale grootte voor het bestuur is, staan we dus open voor een extra bestuurslid. Volgens onze statuten mag elk lid zich verkiesbaar stellen voor het bestuur en het voornaamste doel van deze blogpost is te vragen of er leden zijn die zich daartoe geroepen voelen. Neem in dat geval <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact met ons op</a>. Geef kort en bondig aan waarom je in het bestuur zou willen plaatsnemen. Je kandidaat stellen kan tot twee weken voor de ALV, 18 november. De eventueel nieuwe kandidaten voor het bestuur zullen hierna de gelegenheid krijgen hun kandidatuur op het blog toe te lichten.</p>
<p>De ideale bestuurskandidaat is iemand die kritisch kan blijven kijken naar alle lopende Fronteers-activiteiten en zowel zelf het voortouw neemt om verbeteringen door te voeren, als andere vrijwilligers weet te motiveren om dit te doen, en zich bij dit alles niet laat demotiveren door de belemmeringen die een organisatie geheel bestaande uit vrijwilligers met zich meebrengt.</p>
<p>Op de ALV kunnen alle aanwezige leden op alle, sommige, of geen van de kandidaten stemmen. Alle kandidaten die meer dan 50% van de uitgebrachte stemmen krijgen, worden in het bestuur verkozen. (Mochten er dusdanig veel kandidaten zijn dat het resulterende bestuur groter zou kunnen worden dan wenselijk, dan zal het bestuur aan de ALV voorstellen die stemprocedure aan te passen.) Het nieuwe bestuur kiest vervolgens uit haar midden een voorzitter, secretaris en penningmeester.</p>
<p>Als je vragen, opmerkingen en/of voorstellen hebt, of je je aan wilt melden als potentieel bestuurslid, neem dan <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact met ons op</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij Q42 op 5 november</title>
<link href="https://www.fronteers.nl/nl/blog/2014/10/bijeenkomst-q42"/>
<updated>2014-10-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/10/bijeenkomst-q42</id>
<content xml:lang="nl" type="html"><p>Op woensdag 5 november 2014 is Fronteers te gast bij <a href="http://www.q42.nl/">Q42</a> in Amsterdam. Er worden twee presentaties gehouden.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 uur Ontvangst met hapje &amp; drankje</li>
<li>19:00 uur Roelf-Jan de Vries - &quot;Designing &amp; developing voor de unhappy flow&quot;</li>
<li>19:30 uur Korte pauze</li>
<li>19:45 uur Martin Kool - &quot;Case study: Mobile in Afrika&quot;</li>
<li>20:15 uur Borrel</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Q42 in Amsterdam. <a href="https://www.fronteers.nl/bijeenkomsten/2014/q42">Er is een kaart beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Voor wie?</h2>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/q42">Meld je daarom aan via het aanmeldformulier.</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij internetbureau WHITE op 29 oktober</title>
<link href="https://www.fronteers.nl/nl/blog/2014/10/bijeenkomst-white"/>
<updated>2014-10-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/10/bijeenkomst-white</id>
<content xml:lang="nl" type="html"><p>Op woensdag 29 oktober 2014 is Fronteers te gast bij <a href="http://www.white.nl/">internetbureau WHITE</a> in Valkenswaard. Er worden twee presentaties gehouden.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 uur Ontvangst met hapje &amp; drankje</li>
<li>19:00 uur Simon de Turck - &quot;An introduction to AngularJS&quot;</li>
<li>19:45 uur Korte pauze</li>
<li>20:00 uur Bob Donderwinkel - &quot;De voordelen van BEM (Block, Element, Modifier) CSS&quot;</li>
<li>20:45 uur Borrel</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij internetbureau WHITE in Valkenswaard. <a href="https://www.fronteers.nl/bijeenkomsten/2014/white">Er is een kaart beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Voor wie?</h2>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/white">Meld je daarom aan via het aanmeldformulier.</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Met 25 euro korting naar dsgnday</title>
<link href="https://www.fronteers.nl/nl/blog/2014/09/korting-dsgnday"/>
<updated>2014-09-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/09/korting-dsgnday</id>
<content xml:lang="nl" type="html"><p>Op 11 november wordt in Amsterdam het <a href="http://dsgnday.nl/">dsgnday</a>-congres georganiseerd: een dag met acht sprekers over grafisch en UX design op het web. Bij alle presentaties ligt de focus op directe toepasbaarheid; een inspirerend verhaal is allemaal leuk en aardig, maar als je het niet kan toepassen in je dagelijkse werk, heeft het weinig praktisch nut.</p>
<p>Mark Boulton, Leisa Reichelt, Mike Rohde, Val Head, Stephen Hay, Bonny Colville-Hyde, Peter Boersma en Laura Kalbag zullen hun praktische tips en truuks delen, variërend van het werken met grote opdrachtgevers zoals de overheid, via het praktische nut van animaties naar het zorgen dat je ontwerp ook toegankelijk is - zonder het lelijk te maken.</p>
<p>Geïnteresseerd? Fronteers-leden krijgen €25 korting op de reguliere toegangsprijs van €275. Bij je kaartje zijn koffie, lunch, en een drankje na afloop inbegrepen.</p>
<p>Mocht je hiervan gebruik willen maken, neem dan even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact op</a> met de ledenadministratie. Zoals gebruikelijk geldt deze actie alleen voor leden die op dit moment al lid zijn.</p>
</content>
</entry>
<entry>
<title>10% korting op Node.js training door Mirabeau</title>
<link href="https://www.fronteers.nl/nl/blog/2014/09/korting-node-js-training-mirabeau"/>
<updated>2014-09-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/09/korting-node-js-training-mirabeau</id>
<content xml:lang="nl" type="html"><p>Op woensdag 15 oktober geeft Mirabeau in Utrecht een <a href="https://www.mirabeau.nl/nieuws/persbericht/2014/2014-08-22-programma-training-mirabeau-node-js">Node.js training</a> onder leiding van Bran van der Meer en Niek Bosch. Leden van Fronteers kunnen hier met 10% korting heen.</p>
<p>JavaScript is de lingua franca van het web geworden nu het met Node.js nog meer terrein aan het winnen is. Node.js pakt schaalbaarheid op een revolutionaire manier aan en levert daardoor een erg goede performance. Voorwaarde is wél dat je het voor de juiste zaken inzet.</p>
<p>Steeds meer grote bedrijven zetten Node.js in als REST endpoint, UI layer, en andere micro-services. De open source community is groot en groeit snel, maar het ontwikkelen van server-side JavaScript is iets heel anders dan het ontwikkelen van in-browser JavaScript.</p>
<p>De kosten voor deze dag training zijn € 295,- per persoon. Voor leden wordt dit dus € 265,50. Lees voor meer informatie de <a href="https://www.mirabeau.nl/nieuws/persbericht/2014/2014-08-22-programma-training-mirabeau-node-js">aankondiging op mirabeau.nl</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 23 oktober bij Wijs</title>
<link href="https://www.fronteers.nl/nl/blog/2014/09/bijeenkomst-wijs"/>
<updated>2014-09-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/09/bijeenkomst-wijs</id>
<content xml:lang="nl" type="html"><p>Op donderdag 23 oktober 2014 is Fronteers te gast bij Wijs in Gent. Er worden drie presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met een drankje</li>
<li>19:00 Stephen Verhalleman over <em>werken bij Yelp</em></li>
<li>19:45 Simon Coudeville over <em>design in de browser</em></li>
<li>20:30 Gwen Vanhee over <em>creatieve code-experimenten</em></li>
<li>21:00 naborrelen</li>
</ul>
<p>Dit evenement vindt plaats bij Wijs te Gent. <a href="https://www.fronteers.nl/bijeenkomsten/2014/wijs">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen. Vol is vol!</p>
</content>
</entry>
<entry>
<title>10 extra Fronteers 2014 tickets</title>
<link href="https://www.fronteers.nl/nl/blog/2014/09/10-extra-fronteers-2014-tickets"/>
<updated>2014-09-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/09/10-extra-fronteers-2014-tickets</id>
<content xml:lang="nl" type="html"><p>Volgende week vrijdag zullen 10 extra tickets voor Fronteers 2014 de verkoop in gaan; initieel alleen voor leden, mochten die na 24 uur nog niet allemaal verkocht zijn, ook voor niet-leden. Zie <a href="https://www.fronteers.nl/congres/2014/news/10-more-tickets-available">het nieuwsbericht</a> op het congresgedeelte van de site voor details.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 24 september bij Incentro</title>
<link href="https://www.fronteers.nl/nl/blog/2014/08/bijeenkomst-incentro"/>
<updated>2014-08-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/08/bijeenkomst-incentro</id>
<content xml:lang="nl" type="html"><p>Op woensdag 24 september is Fronteers te gast bij Incentro in Amsterdam. Er worden drie presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 Inloop en eten</li>
<li>18:45 Modulair ontwikkelen met Angularjs - Kasper Reijnders</li>
<li>19:00 Frontend Maturity Model - Steven Chim</li>
<li>19:45 Korte pauze</li>
<li>20:00 Mobile Viewports - Peter-Paul Koch</li>
<li>21:00 Borrel</li>
</ul>
<p>Dit evenement vindt plaats bij Incentro in Amsterdam. Lees meer op de <a href="https://www.fronteers.nl/nl/activiteiten/2014/incentro">pagina van deze bijeenkomst</a>.</p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 30 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/incentro">Meld je daarom aan via het aanmeldformulier.</a>. Vol is vol, er wordt wel een oplossing gezocht als er veel aanmeldingen zijn.</p>
</content>
</entry>
<entry>
<title>30% korting op ColdFront in Kopenhagen</title>
<link href="https://www.fronteers.nl/nl/blog/2014/08/korting-coldfront"/>
<updated>2014-08-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/08/korting-coldfront</id>
<content xml:lang="nl" type="html"><p>We hebben weer een leuke korting voor onze leden! Deze keer voor <a href="http://coldfrontconf.com/">ColdFront</a>, dat op donderdag 4 september (volgende maand al) plaatsvindt in Kopenhagen, Denemarken. De organisatie hierachter komt al een aantal jaar naar ons congres en wilde al een hele tijd ook zoiets organiseren in Denemarken. We hopen dus van harte dat dit ze gaat lukken!</p>
<p>De line-up bestaat uit Kasper Lund, Erik Bryn, Bruce Lawson, Phil Hawksworth, Nat Buckley, Guillermo Rauch, Peter Hedenskog en Christian Heilmann. Op de avond voor het congres vindt ook een soort jam session plaats, waar je zelf een praatje kunt houden. Alle informatie is te vinden op <a href="http://coldfrontconf.com/">coldfrontconf.com</a>.</p>
<p>Een kaartje kost normaal 1.875 Deense Kronen (ongeveer €250), maar met 30% korting wordt dit 1.312,50 Kronen (zo'n €175).</p>
<p>Mocht je hiervan gebruik willen maken, neem dan even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact op met de ledenadministratie</a>. Zoals gebruikelijk geldt deze actie alleen voor leden die op dit moment al lid zijn.</p>
</content>
</entry>
<entry>
<title>Fronteers-BBQ 8 augustus</title>
<link href="https://www.fronteers.nl/nl/blog/2014/07/fronteers-bbq"/>
<updated>2014-07-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/07/fronteers-bbq</id>
<content xml:lang="nl" type="html"><p>Op 8 augustus organiseert de activiteitencommissie een BBQ in Utrecht. Meld je nu aan!</p>
<p>Vanaf 17:30 uur kun je borrelen en BBQ-en met de leden Fronteers! Introducés zijn van harte welkom. Je kunt je <a href="https://www.fronteers.nl/bijeenkomsten/2014/bbq">aanmelden op deze pagina</a>.</p>
</content>
</entry>
<entry>
<title>Korting op boeken voor onze leden</title>
<link href="https://www.fronteers.nl/nl/blog/2014/06/korting-op-boeken-voor-onze-leden"/>
<updated>2014-06-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/06/korting-op-boeken-voor-onze-leden</id>
<content xml:lang="nl" type="html"><p>Er zitten mooie voordelen aan het Fronteers-lidmaatschap. Zo krijg je korting op <a href="https://www.fronteers.nl/congres">het congres</a>, korting op <a href="https://www.fronteers.nl/nl/activiteiten">onze workshops</a> (en op <a href="https://www.fronteers.nl/blog/categorieen/ledenkorting">die van anderen</a>), je kunt met je vragen terecht op <a href="https://forum.fronteers.nl/">ons forum</a>, en je kan actief een bijdrage leveren aan de professionalisering van ons vakgebied. Maar natuurlijk zijn we altijd op zoek naar meer voordelen. Vandaar dat we een aantal uitgeverijen hebben benaderd met de vraag of we korting kunnen krijgen.</p>
<p>Dat kan. Zo hebben we <a href="https://www.fronteers.nl/vereniging/korting-op-boeken">mooie kortingen weten te regelen</a> bij O’Reilly, Peachpit, Smashing Magazine, Rosenfeld Media, Manning en No Starch Press, en zijn we in onderhandeling met nog meer relevante uitgevers. De kortingen lopen uiteen van 20% tot 50%, wat natuurlijk fantastisch is. Nu heb je geen enkele reden meer om je <em>niet</em> te verdiepen.</p>
<h2>Meer</h2>
<p>Natuurlijk willen we korting geven op meer boeken. Een aantal van de uitgeverijen die we hebben benaderd kunnen helaas geen korting geven. Maar we hebben ze vast niet allemaal bereikt. Ken je nog uitgevers die we moeten benaderen? Suggesties zijn meer dan welkom via het reactieformulier.</p>
</content>
</entry>
<entry>
<title>Student, win kaarten voor het congres!</title>
<link href="https://www.fronteers.nl/nl/blog/2014/06/student-win-kaarten-voor-het-congres"/>
<updated>2014-06-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/06/student-win-kaarten-voor-het-congres</id>
<content xml:lang="nl" type="html"><p>Hoewel het Fronteers congres 2014 al lang en breed is uitverkocht kun je als <em>student</em> nog kaarten bemachtigen. Omdat we het belangrijk vinden dat de volgende generatie front-end developers weet wat er allemaal speelt, en contact krijgt met professionals, hebben we <em>maximaal</em> 10 kaarten om weg te geven aan de meest gemotiveerde studenten! Daar moet je natuurlijk wel wat voor doen.</p>
<p>Sinds 2008 wordt er jaarlijks een <a href="https://www.fronteers.nl/congres">Fronteers congres</a> gehouden in Amsterdam. Het is een hoog aangeschreven congres met bezoekers en sprekers van over de hele wereld. Twee dagen lang vertellen internationale spekers waar het heen gaat op het gebied van front-end development. De <em>talks</em> zijn altijd van hoog, technisch niveau, met onderwerpen variërend van <em>real-time JavaScript parsing</em>, via web-typografie tot toegankelijkheid. Om een beeld te krijgen, <a href="https://www.fronteers.nl/videos?type=conference">de video's van vorige jaren zijn allemaal terug te kijken</a>.</p>
<p>Overigens doet Fronteers veel meer dan alleen een congres organiseren. Zo zijn er bijvoorbeeld <a href="https://www.fronteers.nl/bijeenkomsten">regelmatige bijeenkomsten</a> in Nederland en België. Deze zijn altijd gratis te bezoeken, ook voor mensen die geen lid zijn. Erg interessant voor studenten die eens kennis willen maken met meer mensen uit het vakgebied. Onze leden krijgen bovendien interessante kortingen, bijvoorbeeld voor <a href="https://www.fronteers.nl/nl/activiteiten">onze workshops</a>. Studenten <a href="https://www.fronteers.nl/inschrijven">kunnen met korting lid worden</a>.</p>
<h2>Hoe kan je winnen?</h2>
<ul>
<li>Omschrijf in maximaal 10 zinnen hoe de Fronteers conferentie kan bijdragen aan je ontwikkeling als professional. Wees creatief!</li>
<li>Voeg een link toe naar je eigen site, of github, of een ander online portfolio.</li>
<li>Stuur een link naar je bijdrage voor 1 september via <a href="https://www.fronteers.nl/nl/vereniging/contact/">het formulier op onze contactpagina</a> (kies als onderwerp <em>Onderwijs</em>)</li>
<li>Als we je bijdrage willen belonen dan zullen we je vragen om een (bewijs van inschrijving van Hogeschool, Universiteit of Middelbaar Beroepsonderwijs)</li>
</ul>
<p>Op 15 september worden de eventuele winnaars via Twitter kenbaar gemaakt. Als je hebt gewonnen krijg je natuurlijk ook persoonlijk bericht. Beoordeling van de inzendingen gebeurt door een groep docenten en professionals.</p>
<h2>Voorwaarden</h2>
<ul>
<li>De kaart is persoonlijk en je mag hem niet doorverkopen. Neem dus een ID mee naar het congres!</li>
<li>De wedstrijd is alleen toegankelijk voor studenten die onderwijs volgen aan Hogeschool, Universiteit of Middelbaar beroepsonderwijs in Nederland of België.</li>
</ul>
</content>
</entry>
<entry>
<title>Met 20% korting naar Dutch Digital Day</title>
<link href="https://www.fronteers.nl/nl/blog/2014/06/met-20-korting-naar-dutch-digital-day"/>
<updated>2014-06-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/06/met-20-korting-naar-dutch-digital-day</id>
<content xml:lang="nl" type="html"><p>Op 27 juni organiseert PIBN de <a href="http://dutchdigitalday.com/">Dutch Digital Day</a>. Vanaf 13:30 uur kun je je daar onder andere tegoed doen aan internationale sprekers, gadgets en een borrel met barbecue. En dat alles op Undercurrent, een drijvende loods op het IJ in Amsterdam. Leden van Fronteers krijgen 20% korting op de ticketprijs.</p>
<p>Als lid betaal je 80 euro (excl. 6,75 reserveringskosten; voorwaarde is dat je vóór 5 juni al lid was van Fronteers). Wil je graag naar Dutch Digital Day? <a href="https://www.fronteers.nl/nl/vereniging/contact/">Neem dan contact op met de ledenadministratie</a> voor de kortingscode, en <a href="http://dutchdigitalday.com/tickets">koop daarna je ticket</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 19 juni bij Cronos</title>
<link href="https://www.fronteers.nl/nl/blog/2014/06/bijeenkomst-cronos"/>
<updated>2014-06-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/06/bijeenkomst-cronos</id>
<content xml:lang="nl" type="html"><p>Op donderdag 19 juni 2014 is Fronteers te gast bij Cronos in Kontich. Er worden twee presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met een drankje</li>
<li>19:00 Dimitri Mestdagh over <em>JavaScript at your enterprise</em></li>
<li>20:00 Bram(us) Van Damme over <em>terugkeren naar de roots van JavaScript</em></li>
<li>21:00 naborrelen</li>
</ul>
<p>Dit evenement vindt plaats bij Cronos te Kontich. <a href="https://www.fronteers.nl/bijeenkomsten/2014/cronos">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 40 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/cronos">Meld je daarom aan via het aanmeldformulier.</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Spontaanborrel 30 mei</title>
<link href="https://www.fronteers.nl/nl/blog/2014/05/spontaanborrel"/>
<updated>2014-05-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/05/spontaanborrel</id>
<content xml:lang="nl" type="html"><p>Op 30 mei is er weer een spontaanborrel in Utrecht.</p>
<p>De spontaanborrel, wat kan je er nog meer over zeggen. Kom gezellig een biertje pakken, vrijdag (30 mei) vanaf een uur of vijf! Na de workshop lopen we de stad in, vanuit Seats2meet in HoogCatharijne. Wil jij meedoen, zomaar even vrijmibo-en? Alleen borrelen of nog wat eten? Verzamel bij Seats2meet, geef hieronder je reactie of zoek op #fronteers in Twitter en weet ons te vinden.</p>
</content>
</entry>
<entry>
<title>30% korting op het Nationaal Congres Digitale Toegankelijkheid 2014</title>
<link href="https://www.fronteers.nl/nl/blog/2014/05/korting-nationaal-congres-digitale-toegankelijkheid-2014"/>
<updated>2014-05-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/05/korting-nationaal-congres-digitale-toegankelijkheid-2014</id>
<content xml:lang="nl" type="html"><p>Op 29 oktober 2014 vindt het Nationaal Congres Digitale Toegankelijkheid plaats in Utrecht. Leden van Fronteers krijgen 30 procent korting op de toegangsprijs van €299,- en betalen dus €209,30 (exclusief BTW).</p>
<p>Op het programma staat onder andere:</p>
<ul>
<li>Accessible TV for Everyone, Anywhere door Gareth Ford Williams van de BBC</li>
<li>Webtoegankelijkheid en governance door Wiep Hamstra</li>
<li>Web accessibility in 2020 door Eric Velleman</li>
<li>Toegankelijke documenten door Han Sinke</li>
<li>Schrijven voor toptaken door Ger Dreijer</li>
<li>Video toegankelijk maken</li>
<li>Geo-informatie: bruikbaar, vindbaar en toegankelijk door Thijs Brentjens</li>
<li>Gewoon Toegankelijk: een nieuw monitoringsysteem voor overheden</li>
</ul>
<p>Naast de presentaties is er dit jaar een ook een aantal technische sessies:</p>
<ul>
<li>WAI-ARIA door Wilco Fiers</li>
<li>Graphics on the fly door Jules Ernst</li>
<li>Accessible apps door Brian Bors</li>
</ul>
<p>Meer informatie: <a href="http://www.ncdt.nl/">www.ncdt.nl</a></p>
<p>Er zijn tien kortingscodes beschikbaar. Wie het eerst komt, het eerst maalt. Neem <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> op, en we sturen de code zo spoedig mogelijk naar je op. Zoals gebruikelijk, geldt deze korting alleen voor leden dit op dit moment al lid zijn.
Voor early birds (1e 50 inschrijvers) geldt dubbele korting: dan kun je deelnemen voor € 174,30.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij Coolblue op 24 juni</title>
<link href="https://www.fronteers.nl/nl/blog/2014/05/bijeenkomst-coolblue"/>
<updated>2014-05-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/05/bijeenkomst-coolblue</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 24 juni 2014 is Fronteers te gast bij <a href="http://www.coolblue.nl/">Coolblue</a> in Rotterdam. Er worden twee presentaties gehouden.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 uur Ontvangst met hapje &amp; drankje</li>
<li>19:00 uur Welkomstwoord door Fronteers &amp; Coolblue</li>
<li>19:05 uur Frank van Boven &amp; Marijn de Römph - &quot;Keep it Simple Stupid!&quot;</li>
<li>19:50 uur Korte pauze</li>
<li>20:00 uur Reinier Ladan - Research, development en professioneel aanklooien</li>
<li>20:45 uur Borrel</li>
<li>21:30 uur Einde</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Coolblue in Rotterdam. <a href="https://www.fronteers.nl/bijeenkomsten/2014/coolblue">Er is een map beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Voor wie?</h2>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/coolblue">Meld je daarom aan via het aanmeldformulier.</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>15% Ledenkorting op online Advanced Sass workshop</title>
<link href="https://www.fronteers.nl/nl/blog/2014/05/ledenkorting-op-advanced-sass-workshop"/>
<updated>2014-05-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/05/ledenkorting-op-advanced-sass-workshop</id>
<content xml:lang="nl" type="html"><p>Op 12 en 19 juni geeft Roy Tomeij een 5 uur durende <a href="http://sassworkshop.com/">online Advanced Sass workshop</a>. De workshop is geschikt voor ontwikkelaars die al regelmatig met Sass werken, en gaat dieper in op &quot;programmeren met Sass&quot;, right-to-left layouts, media query management en nog veel meer. Daarnaast is er aandacht voor slechte, maar wel leuke experimentele code.</p>
<p>De workshops worden online gegeven. De workshop van 12 juni begint om 18 uur Nederlandse tijd en die van 19 juni om 10 uur. Leden krijgen 15% korting. Voor een kortingscode kun je <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact opnemen met de ledenadministratie</a>, waarna je kunt inschrijven via <a href="http://sassworkshop.com/">SassWorkshop.com</a>.</p>
</content>
</entry>
<entry>
<title>10% korting voor een serie masterclasses voor front-end developers</title>
<link href="https://www.fronteers.nl/nl/blog/2014/05/korting-voor-masterclasses-front-end-developers"/>
<updated>2014-05-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/05/korting-voor-masterclasses-front-end-developers</id>
<content xml:lang="nl" type="html"><p><em>LSG Career Center</em> organiseert samen met Vasilis van Gemert een <a href="http://www.lsgcareercenter.nl/trainingen/masterclass-frontend-development">serie masterclasses</a> met als doel meer front-end developers op weg te helpen naar een senior niveau. Fronteers-leden krijgen een korting van 10%. Deelnemers volgen om de paar weken een masterclass over een specifiek onderwerp, telkens gegeven door een expert op dat gebied. De serie gaat van start in september en wordt telkens gehouden in Utrecht.</p>
<p>Als je kijkt naar de <a href="https://www.fronteers.nl/nl/werk-en-freelance/">vacaturebank</a> hier op de Fronteers-site dan zie je dat er steeds meer vraag is naar senior front-end developers. Er wordt steevast gevraagd om mensen die <em>of</em> alles kunnen, of om mensen die op strategisch niveau mee kunnen denken en mee kunnen werken in een multidisciplinair team. En je ziet ook dat het erg lastig is om de juiste mensen te vinden voor deze functies. De senior developers die er zijn hebben vaak een prima baan en hebben dus geen behoefte aan iets anders. Of ze verdienen bakken met geld als drukke freelancer en hebben helemaal geen behoefte aan een baas. Allemaal tekenen van een tekort. Deze serie masterclasses is bedoeld om meer mensen op weg te helpen naar dat senior niveau.</p>
<h2>Leren</h2>
<p>De tofste manier om te groeien naar dit niveau is door het te leren van vakidioten. Door vier uur lang doorgezaagd te worden over JavaScript door Peter van der Zee. Door tot in detail naar de verschillende viewports te kijken met Peter-Paul Koch. Door samen met Maaike de Laat en Robert Jan Verkade te onderzoeken wat designers nu eigenlijk belangrijk vinden. Door het hoe en waarom van <em>performance</em> echt te doorgronden samen met Mathias Bynens. Door manieren te vinden om om te gaan met de chaotische eigenschappen van het web samen met Vasilis van Gemert. Of door onze huidige en toekomstige tools aan een kritische blik te onderwerpen met Stephen Hay.</p>
<h2>Korting</h2>
<p>Fronteers-leden krijgen een korting van 10%. Wil je gebruik maken van deze korting, <a href="https://www.fronteers.nl/nl/vereniging/contact/">neem dan even contact op</a> met de ledenadministratie. Je kan je <a href="http://www.lsgcareercenter.nl/trainingen/masterclass-frontend-development">inschrijven voor de masterclasses</a> op de site van LSG Career Center.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 22 mei bij Ordina</title>
<link href="https://www.fronteers.nl/nl/blog/2014/05/bijeenkomst-ordina"/>
<updated>2014-05-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/05/bijeenkomst-ordina</id>
<content xml:lang="nl" type="html"><p>Op donderdag 22 mei 2014 is Fronteers te gast bij Ordina in Mechelen. Er worden drie presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met broodjes en een drankje</li>
<li>19:00 Pieter Beulque over <em>Gulp</em></li>
<li>19:45 Frank Baele over <em>Grunt workflows</em></li>
<li>20:30 Gregory Van Looy over <em>Maintainable en scalable CSS</em></li>
<li>21:15 naborrelen</li>
</ul>
<p>Dit evenement vindt plaats bij Ordina te Mechelen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/ordina">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 60 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/ordina">Meld je daarom aan via het aanmeldformulier.</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 8 mei bij Competa</title>
<link href="https://www.fronteers.nl/nl/blog/2014/04/bijeenkomst-competa"/>
<updated>2014-04-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/04/bijeenkomst-competa</id>
<content xml:lang="nl" type="html"><p>Op donderdag 8 mei 2014 is Fronteers te gast bij <a href="http://www.competa.com/">Competa</a> in Rijswijk. Er worden twee of drie presentaties voorzien.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00: Inloop met hapje/drankje aangeboden door Competa</li>
<li>19:00: Pascal Vree over NodeJS</li>
<li>19:45: Elmer Bulthuis over IndexedDB en WebSQL</li>
<li>20:30: Borrelen</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Competa in Rijswijk. <a href="https://www.fronteers.nl/bijeenkomsten/2014/competa">Er is een map beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Voor wie?</h2>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/competa">Meld je daarom aan via het aanmeldformulier.</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Start kaartverkoop Fronteers 2014</title>
<link href="https://www.fronteers.nl/nl/blog/2014/04/start-kaartverkoop-fronteers-2014"/>
<updated>2014-04-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/04/start-kaartverkoop-fronteers-2014</id>
<content xml:lang="nl" type="html"><p>Het is weer zover. De kaarten voor Fronteers 2014 gaan bijna in de verkoop. Het congres wordt dit jaar gehouden op 9 en 10 oktober in Amsterdam. Net als voorgaande jaren wordt het in ieder geval weer een mooie mix van hoge kwaliteit content op het gebied van front-end development en aanverwante zaken. Op dit moment hebben we al toezeggingen van een paar goede sprekers met geweldige content. Welke dat zijn dat verklappen we pas nadat de early bird kaarten verkocht zijn. Onderwerpen die in ieder geval aan bod zullen komen zijn: het customizen van Javascript en de tools er om heen, responsive layout en schaalbare HTML &amp; CSS.</p>
<p>Kaarten voor Fronteers 2014 zijn vanaf 25 april verkrijgbaar rond 12:00 Nederlandse tijd <a href="https://fronteers.paydro.net/">in onze ticketshop</a>. Er zijn in totaal 150 early bird kaarten (100 voor leden, 50 voor niet-leden) en daarvoor geldt op == op. Wees er dus snel bij.</p>
<p>We verwachten dat alle niet-leden early bird kaarten binnen een paar uur zullen uitverkopen, waarna normale niet-leden kaarten beschikbaar zullen worden gemaakt. De hoeveelheid ledenkaarten zou voldoende moeten zijn voor een ruime week aan verkoop, hoewel we dat natuurlijk niet kunnen garanderen.</p>
<p>Wie op het moment van deze aankondiging (vóór 08-04-2014) Fronteerslid is, kan als vanouds zijn of haar kaartje met korting kopen. Direct na de start van de kaartverkoop (25 april, 12:00) zal de Fronteers-nieuwsbrief worden verstuurd, met daarin de spelregels voor ledenkaarten en een specifieke link voor de aankoop daarvan. Heb je aan het eind van die dag nog niets ontvangen? Controleer dan je spam folder. Als je daar ook niets vindt, mail ons dan.</p>
<h2>Aangepaste voorwaarden</h2>
<p>Belangrijk te noemen is dat het vanaf dit jaar niet meer mogelijk is om kaarten op factuur te kopen. Mocht dit problemen opleveren voor mensen die willen komen, dan horen we dat graag. Betaling is dus alleen direct mogelijk, via iDeal of creditcard. Zie voor meer informatie ook <a href="https://www.fronteers.nl/congres/2014/algemene-voorwaarden">onze voorwaarden</a>.</p>
<p>Mocht je de vorige jaren niet geweest zijn of wil je gewoon nog eens nagenieten van de gegeven talks kijk dan eens naar de video's van <a href="https://www.fronteers.nl/congres/2013/sessions">2013</a> en <a href="https://www.fronteers.nl/congres/2012/sessions">2012</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 24 april bij Nucleus</title>
<link href="https://www.fronteers.nl/nl/blog/2014/04/bijeenkomst-nucleus"/>
<updated>2014-04-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/04/bijeenkomst-nucleus</id>
<content xml:lang="nl" type="html"><p>Op donderdag 24 april 2014 is Fronteers te gast bij Nucleus in Antwerpen. Er worden twee presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met broodjes en een drankje</li>
<li>19:00 Jeroen Moors over performance</li>
<li>20:00 Lennart Schoors: <em>Adding SVG to your tool belt</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Nucleus in Antwerpen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/nucleus">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/nucleus">Meld je daarom aan via het aanmeldformulier.</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Design reviews: rechtstreeks in de browser!</title>
<link href="https://www.fronteers.nl/nl/blog/2014/04/design-reviews"/>
<updated>2014-04-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/04/design-reviews</id>
<content xml:lang="nl" type="html"><p>Vandaag presenteren we het redesign van de site. Gewoon, in de browser, omdat dat onze favoriete tool is.</p>
<p>Veel van de pagina's zijn op dit moment alleen nog beschikbaar in Photoshop, maar er er zijn ook al wat pagina's uitgewerkt, zoals <a href="https://www.fronteers.nl/congres">de congres homepage</a>. Ook hebben we natuurlijk gedacht aan ontwerpen voor mobiele apparaten (lees: de iPhone), waarvan de <a href="https://www.fronteers.nl/nl/vereniging/contact/">contactpagina</a> een voorbeeld is.</p>
<p>Als we deze ontwerpen snel af kunnen laten tikken, kunnen we vanaf morgen beginnen met het pixel-perfect implementeren van de hele boel!</p>
<p>De makkelijkste manier om je reviews door te geven, is door een screenshot te maken, deze te plakken in Word en daar je commentaar bij te typen. Vervolgens kun je dit Word document doormailen naar het bestuur.</p>
<p>Alvast bedankt!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 13 maart bij BetaGroup Kortrijk</title>
<link href="https://www.fronteers.nl/nl/blog/2014/02/bijeenkomst-betagroup"/>
<updated>2014-02-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/02/bijeenkomst-betagroup</id>
<content xml:lang="nl" type="html"><p>Op donderdag 13 maart 2014 is Fronteers te gast bij BetaGroup/Parkoffice te Kortrijk. Er worden twee presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00: Ontvangst met belegde broodjes en een drankje</li>
<li>19:00: <em>Doing it without jQuery</em> door <a href="https://twitter.com/joggink">Jochen Vandendriessche</a></li>
<li>20:00: <em>It’s a startup life – from idea to execution</em> door <a href="https://twitter.com/thomastuts">Thomas Tuts</a> en <a href="https://twitter.com/choisissez">Miet Claes</a></li>
<li>21:00: Naborrelen met een drankje</li>
</ul>
<h2>Waar?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 80 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2014/betagroup">Meld je daarom aan via het aanmeldformulier</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij E-sites op 26 maart 2014</title>
<link href="https://www.fronteers.nl/nl/blog/2014/02/bijeenkomst-bij-e-sites-op-26-maart-2014"/>
<updated>2014-02-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/02/bijeenkomst-bij-e-sites-op-26-maart-2014</id>
<content xml:lang="nl" type="html"><p>Op woensdag 26 maart 2014 is Fronteers te gast bij E-sites in Breda. Meld je nu aan voor deze bijeenkomst over tooling, code afspraken, JS errorlogger, cronitor (cronjob logger), deployment, standaardisatie, github én over Surfly, een online tool die je web laat sharen door middel van open web technologieën.</p>
<p>Het front-end team van E-sites (Boye, John en Iain) laat zien wat voor gereedschap zij gebruiken en geeft een demo van de tools en scripts die het ontwikkelproces vergemakkelijken. Peter van der Zee geeft Fronteersleden een primeur: hij laat zien hoe Surfly het web laat sharen door middel van open web technologieën.</p>
<h2>Programma</h2>
<p>Een uitgebreide beschrijving van de twee presentaties is te vinden op de <a href="https://www.fronteers.nl/bijeenkomsten/2014/e-sites">bijeenkomstpagina</a>. Het programma is als volgt:</p>
<ul>
<li>18.30 inloop</li>
<li>19.30 presentatie door Boye Oomens, John van Hulsen en Iain van der Wiel</li>
<li>20.30 korte pauze</li>
<li>20.45 presentatie door Peter van der Zee</li>
<li>21.45 borrelen</li>
</ul>
<h2>Aanmelden</h2>
<p>Deze bijeenkomst vindt plaats bij <a href="http://www.e-sites.nl/">E-sites</a> in Breda. Je kunt je <a href="https://www.fronteers.nl/bijeenkomsten/2014/e-sites">aanmelden op deze pagina</a>.</p>
</content>
</entry>
<entry>
<title>Commissie Webrichtlijnen weer actief</title>
<link href="https://www.fronteers.nl/nl/blog/2014/02/commissie-webrichtlijnen-weer-actief"/>
<updated>2014-02-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/02/commissie-webrichtlijnen-weer-actief</id>
<content xml:lang="nl" type="html"><p>Het is een poosje stil geweest vanuit de Commissie Webrichtlijnen van Fronteers. Hoog tijd dus voor een update.</p>
<p>Zoals jullie misschien vernomen hebben, is de Normcommissie Drempelvrij – waar ik zelf in zat namens Fronteers – afgelopen jaar opgestapt wegens onvrede met de gang van zaken binnen de stichting. Omdat we nog wel onze opgedane kennis en ervaring nuttig willen inzetten, zijn we met een aantal ex-Normcommissieleden – te weten Raph de Rooij, Iacobien Riezebosch, Wilco Fiers, Bram Duvigneau en ik - een nieuwe groep opgestart. Aan de precieze invulling hiervan wordt nu gewerkt.</p>
<p>Wat we in ieder geval van plan zijn, is om naast onze eigen kerntaken via de Commissie Webrichtlijnen op deze site informatie te verschaffen en discussies te voeren over vragen en kwesties rondom webtoegankelijkheid. Net als met de eerder geschreven <a href="https://www.fronteers.nl/blog/categorieen/webrichtlijnen">blogposts op deze site</a> over de webrichtlijnen, willen we hiermee een open en transparant archief opbouwen waar o.a. ontwikkelaars informatie kunnen vinden over deze vraagstukken. Naast artikelen publiceren willen we ook het forum van Fronteers hiervoor gaan inzetten.</p>
<p>Wat kunnen jullie verwachten? Artikelen over:</p>
<ul>
<li>Best practises: hoe ben je omgegaan met een bepaald toegankelijkheidsprobleem?</li>
<li>Uitdagingen: welke ontwikkelaar kan een goede oplossing bedenken voor situatie X?</li>
<li>Vragen over verplichtingen: wat moet wel, wat niet, wat zijn fabels?</li>
<li>Hoe ga je om met het uitleggen van toepassing van de richtlijnen aan collega's met andere rollen in de organisatie?</li>
</ul>
<p>We gaan uit van oplossingsgericht denken en anderen helpen hun sites toegankelijker te maken, wat het startpunt daarvan ook mag zijn.</p>
<p>Suggesties en vragen zijn welkom!</p>
</content>
</entry>
<entry>
<title>30% korting op GeeUp in Leiden</title>
<link href="https://www.fronteers.nl/nl/blog/2014/02/korting-geeup-leiden"/>
<updated>2014-02-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/02/korting-geeup-leiden</id>
<content xml:lang="nl" type="html"><p>Gebruik je het CMS ExpressionEngine of ben je ondernemer? Dan is <a href="http://geeuphq.com/">GeeUp</a> misschien iets voor jou. Op 20 juni kun je in Leiden terecht voor dit congres over ExpressionEngine, met onderwerpen over code, projectmanagement, en veel meer. Fronteers-leden krijgen 30% korting!</p>
<p>ExpressionEngine is een content management systeem dat onze kostbare HTML helemaal met rust laat, en is daarom een populair CMS onder front-enders. Bij GeeUp gaat het niet alleen over het ontwikkelen van sites met dit systeem, maar ook over sales, nazorg en creativiteit in development.</p>
<p>Een kaartje kost normaal gesproken € 125,- ex. btw, maar met de Fronteers-korting kun je er al heen voor € 85,50. De korting geldt niet voor de workshops op 19 juni.</p>
<p>Wil je gebruik maken van deze korting, <a href="https://www.fronteers.nl/nl/vereniging/contact/">neem dan contact op</a> met de ledenadministratie. Zoals gebruikelijk geldt de korting uitsluitend voor diegenen die op dit moment lid zijn.</p>
</content>
</entry>
<entry>
<title>Met 25 euro korting naar CSS Day in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2014/02/korting-css-day"/>
<updated>2014-02-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/02/korting-css-day</id>
<content xml:lang="nl" type="html"><p>Op woensdag 4 juni wordt in Amsterdam voor de tweede keer <a href="http://cssday.nl/">CSS Day</a> georganiseerd; een dag waarop 8 sprekers, waaronder Nicole Sullivan, David Baron en Ethan Marcotte, diep in zullen gaan op CSS.</p>
<p>Fronteers heeft voor deze dag 15 kortingscodes van € 25,- gekregen. Wil je gebruik maken van deze korting? Neem dan <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact op met de ledenadministratie</a>. De korting geldt, zoals gebruikelijk, alleen voor leden die bij aankondiging van deze actie al lid waren en is niet van toepassing op de workshops.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst met Jared Spool over UX Strategy</title>
<link href="https://www.fronteers.nl/nl/blog/2014/01/uxstrategy"/>
<updated>2014-01-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/01/uxstrategy</id>
<content xml:lang="nl" type="html"><p>Kom ook naar de last-minute-special 'UX Strategy Means Business', vrijdag 7 februari spreekt Jared Spool in Amsterdam. Schrijf meteen in!</p>
<p>Jared Spool <a href="https://twitter.com/jmspool/status/428460022646181888">tweette dat hij in Nederland is</a> en de activiteitencommissie van Fronteers wist hem te strikken voor een presentatie. Deze bijeenkomst wordt georganiseerd in samenwerking met <a href="http://www.meetup.com/AmsterdamUX/">Amsterdam UX</a>.</p>
<h2>Programma</h2>
<ul>
<li>19:30 inloop</li>
<li>20:35 introductie door Fronteers, Amsterdam UX en sponsor User Intelligence</li>
<li>20:45 presentatie Jared Spool, UX Strategy Means Business (in English) <a href="https://www.fronteers.nl/bijeenkomsten/2014/uxstrategy">Lees meer op deze pagina</a></li>
<li>21:45 Q &amp; A (je kunt ook via Twitter meedoen)</li>
<li>22:05 borrel</li>
<li>23:00 einde</li>
</ul>
<h2>Bereikbaarheid en aanmelden</h2>
<p>De bijeenkomst vindt plaats bij Felix Meritis, <a href="https://maps.google.nl/maps?q=felixmeritis&amp;hl=nl&amp;sll=51.992171,4.494086&amp;sspn=1.270144,3.348083&amp;t=h&amp;z=16&amp;iwloc=A">Keizersgracht 324, Amsterdam</a>
Meer info over de locatie is te vinden op <a href="https://www.fronteers.nl/bijeenkomsten/2014/uxstrategy">de pagina onder Bijeenkomsten</a>.
Ondanks recente berichten in het nieuws kunnen we melden dat dit niet van invloed is op onze bijeenkomst, zie ook <a href="https://twitter.com/FelixMeritis/status/431065078406725632">hun tweet</a>.</p>
<p>Aanmelden is verplicht!</p>
<p>Leden van Fronteers kunnen op <a href="https://www.fronteers.nl/bijeenkomsten/2014/uxstrategy">deze pagina</a> aanmelden. Ook niet-leden zijn welkom.
Leden van Amsterdam UX melden zich aan via <a href="http://www.meetup.com/AmsterdamUX/">meetup.com/Amsterdam UX</a>.</p>
</content>
</entry>
<entry>
<title>Hackathon op 15 februari 2014</title>
<link href="https://www.fronteers.nl/nl/blog/2014/01/hackathon-februari"/>
<updated>2014-01-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/01/hackathon-februari</id>
<content xml:lang="nl" type="html"><p>De vrijwilligers van de activiteitencommissie en congrescommissie organiseren een hackathon, voor en door leden van Fronteers.</p>
<p>Vind jij ook dat Fronteers 2014 een coole website nodig heeft? En zou jij graag een vinger in de pap willen hebben? Hier is je kans! Op 15 februari organiseren we een hackaton waarbij we daarvoor een basis willen leggen. Ons idee is om een context-afhankelijke homepage te maken.</p>
<p>Wat bedoelen we precies met een context-afhankelijke homepage? Naar ons idee is dat een homepage die verandert. Afhankelijk van de tijd tot aan het congres en misschien nog andere factoren, zoals locatie en weersomstandigheden.
Dus in de maanden van de kaartverkoop geeft de homepage vooral informatie over de sprekers en de onderwerpen. Wanneer de kaarten zijn uitverkocht krijg je vooral informatie over hotels en activiteiten rond de congreslocatie. En tijdens het congres, en wie weet alleen als je op de wifi zit, kun je dingen zien zoals de lengte van de wachtrij voor de toiletten. Zoiets dus... Maar wat precies? Dat is aan jou.</p>
<p>Dit idee kan vanuit een aantal invalshoeken belicht worden, technisch, UX, visual design, etc. Aan het eind van de hackathon hopen we een aantal goed beschreven ideeën, liefst uitgewerkt tot demo/proof of concept, te hebben waarmee we de site kunnen gaan realiseren. Tijdens de hackathon kun je aangeven of je ook bij deze fase betrokken zou willen blijven.</p>
<h2>Locatie en tijd</h2>
<ul>
<li>Datum: 15 februari 2014</li>
<li>10.00 - 17.00 uur</li>
<li>Locatie: In de Ruimte, Oudegracht 230, 3511 NT Utrecht (<a href="http://www.inderuimte.org/contact-inf/">routebeschrijving</a>)</li>
</ul>
<p><a href="https://www.fronteers.nl/bijeenkomsten/2014/hackathon-februari">Meld je hier aan</a></p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 19 februari bij Coosto</title>
<link href="https://www.fronteers.nl/nl/blog/2014/01/bijeenkomst-coosto"/>
<updated>2014-01-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/01/bijeenkomst-coosto</id>
<content xml:lang="nl" type="html"><p>Op woensdag 19 februari 2014 is Fronteers te gast bij <a href="http://www.coosto.coml/nl/">Coosto</a> in Eindhoven. Onderwerpen zijn webfonts, schalen van je webapp en responsive webdesign.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18.00 inloop met buffet en 'n drankje</li>
<li>19.30 presentatie Roel Nieskens, I □ webfonts</li>
<li>20.00 presentatie Koen Kivits, Groeistuipen: het schalen van je web app</li>
<li>20.30 korte pauze</li>
<li>20.45 presentatie Wilfred Nas, ‘What has Responsive Web Design done for us, so far’.</li>
<li>21.30 borrelen</li>
</ul>
<h2>Waar en wie?</h2>
<p>Deze bijeenkomst vindt plaats bij Coosto in Eindhoven. Meer details vind je op <a href="https://www.fronteers.nl/bijeenkomsten/2014/coosto">de pagina van deze bijeenkomst</a>. Iedereen is welkom.
Er is ruimte voor 40 personen. <em>Aanmelden is helaas niet meer mogelijk, het maximaal aantal deelnemers is bereikt.</em></p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 13 februari bij TriFork</title>
<link href="https://www.fronteers.nl/nl/blog/2014/01/bijeenkomst-trifork"/>
<updated>2014-01-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2014/01/bijeenkomst-trifork</id>
<content xml:lang="nl" type="html"><p>Op donderdag 13 februari 2014 is Fronteers te gast bij <a href="http://www.trifork.nl/">TriFork</a> in Amsterdam. Er worden twee presentaties gegeven.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18.00 Binnenkomst met pizza</li>
<li>18.30 Presentatie Roy Tomeij</li>
<li>19.30 Korte pauze</li>
<li>19.45 Presentatie Justin Halsall</li>
<li>20.45 Borrel</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij TriFork te Amsterdam. <a href="https://www.fronteers.nl/bijeenkomsten/2014/trifork">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Voorafgaand aan de bijeenkomst zal er pizza zijn, je hoeft dus van tevoren niet te eten. We willen graag weten hoeveel pizza's we moeten bestellen.</p>
</content>
</entry>
<entry>
<title>Fronteers nieuwjaarsborrel</title>
<link href="https://www.fronteers.nl/nl/blog/2013/12/nieuwjaarsborrel"/>
<updated>2013-12-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/12/nieuwjaarsborrel</id>
<content xml:lang="nl" type="html"><p>Een nieuw jaar, een nieuwe locatie voor de Fronteers nieuwjaarsborrel, speciaal voor leden!</p>
<p>Op vrijdag 17 januari 2014 organiseert Fronteers een Nieuwjaarsborrel voor leden. Deze zal plaatsvinden in Cafe Lebowski, in Utrecht.
Rond 17:00 uur zullen de eerste leden aanwezig zijn en de eerste drankjes worden betaald door de vereniging.</p>
<p>Grand Cafe Lebowski in Utrecht heeft veel lekkere bieren, ook van de tap. De hongerige direct-uit-werk-naar-borrel-ganger kan ook wat te eten bestellen, op eigen kosten.</p>
<h2>Locatie</h2>
<p>Domplein 17, naast de Dom in Utrecht, ongeveer 10 minuten lopen van Utrecht Centraal Station. Op de website van Grand Café Lebowski vind je <a href="http://www.grandcafelebowski.nl/contact-en-route">de routebeschrijving</a>.
Parkeren in Utrecht is geen probleem, maar bekijk wel even de tarieven. Kies voor <a href="http://www.interparking.nl/find-parking/Springweg/">garage Springweg</a> of één van de andere parkeergarages rond Hoog Catharijne.</p>
<h2>Nog meer borrelen?</h2>
<p>Op 9 januari is er een nieuwjaarsreceptie van ISOC, ook daar kun je leden van Fronteers tegenkomen. <a href="https://www.fronteers.nl/blog/2013/12/nieuwjaarsreceptie-isoc">Lees hier verder.</a></p>
<h2>Aanmelden</h2>
<p>Ben je lid van Fronteers en doe je mee? Laat in de comments weten dat je komt, en of je wel of niet wil mee-eten. Dat mag ook naar of aan <a href="mailto:meta@fronteers.nl">meta@fronteers.nl</a>. Dan weten we ook hoeveel ruimte nodig is.</p>
</content>
</entry>
<entry>
<title>Update uit de congrescommissie: de datum!</title>
<link href="https://www.fronteers.nl/nl/blog/2013/12/update-uit-de-congrescommissie-de-datum"/>
<updated>2013-12-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/12/update-uit-de-congrescommissie-de-datum</id>
<content xml:lang="nl" type="html"><p>Sinterklaas is al weer achter de rug en terwijl iedereen z'n adem inhoudt voor de kerst heeft de congrescommissie van Fronteers 2014 al weer een hoop geritseld achter de schermen. Zoals je wellicht hebt gelezen op <a href="http://fronteers.nl/congres/2014">de congrespagina</a> vindt het Fronteers Congres plaats op 9 en 10 oktober 2014.</p>
<p>Net als vorig jaar proberen wij een selectie te maken op basis van onderwerp en zoeken wij daar geschikte sprekers voor. Om de onderwerpen wat structuur te geven hebben we een &quot;lichtroze draad&quot; uitgestippeld die door heel het congres heen loopt. Wat die draad zal zijn, dat houden we nog even geheim. Naast selectie op onderwerp hebben we ook al een aantal &quot;must-have&quot; sprekers geselecteerd en die zullen wij de komende dagen en weken benaderen om op &quot;ons&quot; congres te spreken. Je zult begrijpen dat het een hele kluif is om ons aan de ene kant te beperken (we willen zoveel!) en aan de andere kant de aller-allerbeste mensen te vinden (en hopen dat ze ook kunnen en willen!).</p>
<p>We hopen in ieder geval dat je 9 en 10 oktober 2014 alvast in je agenda hebt gezet en dat je met smart uitkijkt naar een volgende update!</p>
<p>Als je ook tussendoor van kleinere gebeurtenissen op de hoogte wilt blijven, volg ons dan op <a href="https://twitter.com/fronteersconf">Twitter (@FronteersConf)</a> en houd onze <a href="http://lanyrd.com/2014/fronteers/">Lanyrd-pagina</a> in de gaten.</p>
</content>
</entry>
<entry>
<title>Nieuwjaarsreceptie ISOC</title>
<link href="https://www.fronteers.nl/nl/blog/2013/12/nieuwjaarsreceptie-isoc"/>
<updated>2013-12-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/12/nieuwjaarsreceptie-isoc</id>
<content xml:lang="nl" type="html"><p>Het wordt weer tijd voor de nieuwjaarsborrels. De eerste is op donderdag 9 januari 2014, georganiseerd door de overkoepelende organisatie voor internetinstanties, Internet Society Nederland.</p>
<p>Op de nieuwjaarsreceptie van ISOC Nederland ontmoet je bijna twintig nationale en internationale spelers uit de internetwereld. Van e-infrastructuur tot .nl, van digitale burgerrechten tot en met digitale certificaten, van toegankelijkheid voor blinden tot hosting providers - iedereen doet mee.
Er zijn hapjes, drankjes, lightning talks en netwerkmogelijkheden. Fronteers is ook zichtbaar aanwezig. Het programma start om 17:45 uur, <a href="http://isoc.nl/activ/2014-nieuwjaar.htm">meer info vind je op de website van ISOC</a>.</p>
<h2>Locatie</h2>
<p>De bijeenkomst wordt gehouden in Amsterdam in Felix Meritis, Keizersgracht 324. Op hun website vind je de <a href="http://www.felix.meritis.nl/nl/over-felix-meritis/contact-en-route/">routebeschrijving</a>.</p>
<h2>Aanmelden bij ISOC</h2>
<p><a href="https://portal.ripe.net/meeting-pub/registration?meetingId=0587eee7-730d-441b-9982-eb223b459c8e">Aanmelden kan gratis op de website van ISOC.</a>
Aanmelden kan niet via de website van Fronteers. Laat Fronteersleden wél weten dat je komt, reageer hieronder en/of <a href="https://twitter.com/search?q=%23fronteers&amp;src=typd">tweet met hashtag #fronteers</a>.</p>
</content>
</entry>
<entry>
<title>Updates uit de congrescommissie</title>
<link href="https://www.fronteers.nl/nl/blog/2013/11/updates-uit-de-congrescommissie-2014"/>
<updated>2013-11-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/11/updates-uit-de-congrescommissie-2014</id>
<content xml:lang="nl" type="html"><p>Buiten is het guur en koud, binnen zit de congrescommissie van 2014 al weer hard te tikken achter hun lichtgevende schermpjes. Een mooie datum in oktober, veel interessante sprekers en misschien wel een nieuwe website.</p>
<p>Voor <a href="https://www.fronteers.nl/vereniging/commissies/congres">de congrescommissie</a> is na een succesvol congres in oktober <a href="https://twitter.com/search?q=%23fronteers14">hekje fronteers14</a> begonnen. <a href="https://www.fronteers.nl/blog/2013/09/de-congrescommissie-zoekt-actieve-leden">De lange blogpost van Vasilis</a> bleek gelukkig niet iedereen weggejaagd te hebben. We hebben voor 2014 twee geschikte nieuwe kandidaten weten te strikken voor de congrescommissie. Hidde en Matijs hebben de commissie verlaten. We willen hen bedanken voor het vele en goede werk. Hun kernwaarden zullen eeuwig in tact worden gehouden. Oké, nog een week of twee... :)</p>
<p>Samen met Carlo en Flurin, onze nieuwe aanwinsten in de commissie, zijn we al begonnen met het verzamelen van sprekersonderwerpen. Net als vorig jaar selecteren we op onderwerpen, waarbij we later sprekers zoeken. Ook wordt er in de congres- wandelgangen al druk gepraat over enkele sprekers die we niet willen missen voor 2014.</p>
<p>Net als vorig jaar zal Michael het grafische werk voor zijn rekening nemen. De taken die onder Thomas zijn verantwoordelijkheid vallen zijn: financiën, vrijwilligers en catering. Sander gaat de workshops, techniek en de locatie voor zijn rekening nemen. Deelnemers en video vallen onder de verantwoordelijkheid van Carlo. Flurin zal de communicatie verzorgen en zal, samen met Charis, de sprekers voor zijn rekening nemen. Charis is dit jaar de voorzitter, en organiseert als feestneus ook dit jaar weer de afterparty.</p>
<p>Afgelopen jaar is er veel vastgelegd in ons eigen Fronteers congreshandboek, dit jaar gaat zal dat handboek uitgebreid worden. We hopen dit jaar de dikte van het boek van Sinterklaas te overtreffen, alhoewel dat natuurlijk geen doel op zich is.</p>
<p>We hopen dat je nu genoeg weet,
tot de volgende update!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 5 december bij Mobile Vikings</title>
<link href="https://www.fronteers.nl/nl/blog/2013/11/bijeenkomst-mobile-vikings"/>
<updated>2013-11-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/11/bijeenkomst-mobile-vikings</id>
<content xml:lang="nl" type="html"><p>Op donderdag 5 december 2013 is Fronteers te gast bij Mobile Vikings te Hasselt. Er worden twee presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00: Ontvangst met belegde broodjes en een drankje</li>
<li>19:00: Bert Wijnants van Mobile Vikings over <em>The Realtime Web</em></li>
<li>20:00: <a href="http://toon.io/">Toon Ketels</a> over <em>Building better client-side JavaScript applications with Domain Driven Design</em></li>
<li>21:00: Naborrelen met een drankje</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Mobile Vikings in Hasselt. Er is een plannetje beschikbaar op de <a href="https://www.fronteers.nl/bijeenkomsten/2013/mobile-vikings">detailpagina van deze bijeenkomst</a>.</p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 70 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2013/mobile-vikings">Meld je daarom aan via het aanmeldformulier</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Een lunchcollege bij W.I.S.V. Christiaan Huygens</title>
<link href="https://www.fronteers.nl/nl/blog/2013/11/lunchcollege-wisv-christiaan-huygens"/>
<updated>2013-11-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/11/lunchcollege-wisv-christiaan-huygens</id>
<content xml:lang="nl" type="html"><p>Een tijdje geleden nam een bestuurslid van de studentenvereniging Christiaan Huygens van de TU in Delft contact op met Fronteers met de vraag of een van ons een verhaaltje wilde vertellen op een van hun vele lunchbijeenkomsten. Bijna elke week organiseren ze zo'n bijeenkomst voor hun leden, waarbij ze luisteren naar iemand uit de praktijk. Wat een prachtige aanvulling op een sowieso al prachtig instituut! Ik vond het dan ook een grote eer om hiervoor uitgenodigd te zijn. Ik heb vandaag een verhaal verteld over hoe ontzettend tof het is om dingen te maken voor het web.</p>
<h2>Echt?</h2>
<p>Tenminste, als je er van houdt om dingen te maken voor een bizar, onbetrouwbaar medium. Ik heb de bezoekers laten zien dat het heel lastig is om iets wat je op een muur hebt geschilderd kleiner te maken, terwijl het echt supersimpel is om iets op het web kleiner te maken. Ik heb ze verteld wat we kunnen leren van de ballondrukkunst, van <em>tattoo-artists</em>, van modeontwerpers, van muziek-producers, van grafisch ontwerpers, van mobiele apps (ffs) en van onszelf. En ik sloot af met de wens om veel te gaan leren van kunstenaars, zodra die zich eens zouden gaan interesseren in het web. Het was erg tof om dit verhaal eens te vertellen aan een collegezaal vol met jonge, briljante informatici en wiskundigen. Dit is een vergelijkbaar verhaal wat ik al eens eerder heb gehouden, dus als je er niet bij was, niet getreurd, <a href="https://vimeo.com/78652974">er is eerder eens een video van gemaakt</a>.</p>
<h2>Verenigingen</h2>
<p>Het verhaal werd volgens mij goed ontvangen. Er was helaas weinig tijd na afloop om te praten met de studenten. Gelukkig heb ik van tevoren wel even de tijd gehad om te babbelen met wat studenten van de vereniging. We hebben het onder meer gehad over de voordelen van lid zijn van een vereniging. Waarom zou je dat willen? Dat is een vraag die Fronteers zich natuurlijk ook keer op keer blijft stellen. Leden van Christiaan Huygens kunnen gratis gebruik maken van de verenigingsruimte en mogen daar op de banken zitten (en dat mocht ik ook!). Klein voordeeltje wat Fronteers niet kan bieden, hoewel onze vrijwilligers wél <a href="https://www.fronteers.nl/blog/2013/11/irccloud-vrijwilligers">een gratis IRCCloud account krijgen</a>. Misschien toch wel vergelijkbaar. Ze bieden verder korting op studieboeken; volgens mij was er ooit een vergelijkbaar initiatief gestart bij Fronteers, maar dit is nooit van de grond gekomen, meen ik me te herinneren. En verder hebben ze de wekelijkse(!) bijeenkomsten met gratis broodjes voor de eerste 100 bezoekers. Ik weet zeker dat ze meer nuttigs doen voor hun leden, zoals wij dat ook doen (denk aan een congres, een onderwijscommissie, onze workshops, en al dat andere moois wat we doen).</p>
</content>
</entry>
<entry>
<title>Gratis gebruik van IRCCloud voor vrijwilligers</title>
<link href="https://www.fronteers.nl/nl/blog/2013/11/irccloud-vrijwilligers"/>
<updated>2013-11-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/11/irccloud-vrijwilligers</id>
<content xml:lang="nl" type="html"><p>Een groot deel van de communicatie tussen onze vrijwilligers speelt zich online af, voornamelijk via e-mail en <a href="https://www.fronteers.nl/blog/2008/03/fronteers-op-irc">IRC</a>. Ook in het bestuur maken we regelmatig gebruik van IRC om elkaar actief en op de hoogte te houden. Aangezien een hoop leden <a href="http://irccloud.com/">IRCCloud</a> hiervoor gebruiken en IRCCloud sinds kort daadwerkelijk kosten rekent en <a href="https://blog.irccloud.com/lower-prices-and-team-accounts/">team accounts</a> mogelijk maakt, hebben we besloten om actieve vrijwilligers van onze vereniging de mogelijkheid te bieden om op onze kosten gebruik te maken van deze service.</p>
<p>De betaalde variant van IRCCloud maakt het mogelijk om altijd verbonden te blijven en onbeperkt terug te lezen wat er besproken is. IRC is niet voor iedereen het juiste medium (wat we ook in 2008 schreven), maar we denken dat deze features het nog nuttiger maken voor onze commissies (wat ook blijkt doordat meer mensen het nu gebruiken). Continu een chatkanaal in de gaten houden is dus niet nodig (en voor velen te tijdrovend); je kunt gewoon eens in de zoveel tijd inloggen, kijken wat er (aan jou) geschreven is, daar even op reageren en weer uitloggen.</p>
<p>Mocht je actief zijn binnen de vereniging, IRC gebruiken voor Fronteers-gerelateerde communicatie, en behoefte hebben aan een volledig IRCCloud account, neem dan even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> met ons op. Via IRC kan dit vanzelfsprekend ook; zoals je in dat geval al weet zitten we in #fronteers op het freenode netwerk. Als je IRCCloud al (betaald) gebruikt, kun je zonder problemen overstappen met je eigen bestaande account.</p>
<p>Een door ons betaald account geldt in principe voor een jaar, en ieder jaar opnieuw bekijken we of je hier nog steeds gebruik van wilt maken.</p>
<p>Andersom is natuurlijk ook mogelijk: lijkt zo'n account je wel wat, maar ben je nog geen vrijwilliger? Er is genoeg te doen binnen de vereniging, dus we zijn altijd op zoek naar nieuwe mensen. Laat ook in dit geval <a href="https://www.fronteers.nl/nl/vereniging/contact/">wat van je horen</a>!</p>
</content>
</entry>
<entry>
<title>Meld je nu aan voor de Algemene Ledenvergadering 2013</title>
<link href="https://www.fronteers.nl/nl/blog/2013/11/aanmelden-alv-2013"/>
<updated>2013-11-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/11/aanmelden-alv-2013</id>
<content xml:lang="nl" type="html"><p>Maandag 25 november aanstaande houden we onze jaarlijkse algemene ledenvergadering (ALV). Alle leden zijn hiervoor van harte uitgenodigd. De locatie van de ALV is <a href="http://www.poortvankleef.nl/vergaderzaal-bij-hoog-cathrijne-jaarbeurs-utrecht-centraal-station/">Zalencentrum De Poort van Kleef</a> (toegang via restaurant Carré), ongeveer vijf minuten lopen vanaf Utrecht CS (Mariaplaats 7).</p>
<p>We beginnen om 19:00 uur en hopen deze keer toch echt niet langer dan drie uur nodig te hebben. Voor de mensen die van ver komen regelen we iets van broodjes, welke vanaf 18:30 beschikbaar zullen zijn. Geef bij je aanmelding even aan dat je hier gebruik van wilt maken.</p>
<h2>De agenda voor de avond is de volgende:</h2>
<ul>
<li>Welkom en opening door de voorzitter</li>
<li>Toelichting commissies</li>
<li>Discussieonderwerpen
<ul>
<li>Studenten op het congres</li>
<li>Bedrijfsnaam op vacatures</li>
</ul>
</li>
<li>Besluiten eerdere ALV’s</li>
<li>Wisseling kascommissie 2012 + rapportage</li>
<li>Financiën 2013 / Begroting 2014</li>
<li>Kascommissieverkiezing</li>
<li>Aftreden Sander en Tom, Sander herkiesbaar</li>
<li>Rondvraag</li>
<li>Afsluiting</li>
</ul>
<p>(Zie de nieuwsbrief die vanochtend, 7 november, wordt verstuurd voor meer details / toelichting op de verschillende agendaonderwerpen.)</p>
<p>Ben je van plan te komen, dan vragen we je vriendelijk je hieronder hiervoor in te schrijven, zodat we enigszins een idee hebben van de verwachte opkomst.</p>
</content>
</entry>
<entry>
<title>Plannen voor de onderwijscommissie</title>
<link href="https://www.fronteers.nl/nl/blog/2013/11/plannen-voor-de-onderwijscommissie"/>
<updated>2013-11-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/11/plannen-voor-de-onderwijscommissie</id>
<content xml:lang="nl" type="html"><p>Het afgelopen jaar lijkt het weer stil te zijn geweest rondom de onderwijscommissie van Fronteers. Maar achter de schermen is er gelukkig wel het een en ander gebeurd. Er zijn een paar informele bijeenkomsten geweest tussen verschillende Fronteers-leden, docenten en meerdere onderwijsinstellingen. Uit deze bijeenkomsten zijn een aantal punten naar voren gekomen waar onderwijsinstellingen en docenten de hulp van Fronteers goed kunnen gebruiken. Er hebben zich inmiddels aardig wat vrijwilligers aangemeld die zich in willen zetten voor deze commissie. Deze post is bedoeld om iedereen te informeren over de mogelijke werkzaamheden.</p>
<h2>Aanpak</h2>
<p>In het verleden heeft Fronteers geprobeerd om een curriculum op te stellen. Deze actieve houding, waarbij we onze visie opdringen aan anderen, is om meerdere redenen niet geslaagd. Ten eerste is het veel te veel werk, ten tweede zijn we zelf vaak geen docenten, en ten derde weten docenten natuurlijk zelf heel goed wat ze nodig hebben. Er bestaat niet zoiets als één curriculum.</p>
<p>Fronteers moet dus ondersteunend zijn, niet leidend. De vraag moet komen vanuit de opleidingen, Fronteers kan dan experts en vrijwilligers leveren om eventuele problemen aan te pakken. Een verschil in aanpak is dus: docenten moeten zelf hun curriculum maken, wij kunnen ze ondersteunen.</p>
<h2>Een duidelijke lijn.</h2>
<p>Wat er lijkt te ontbreken in veel opleidingen is een duidelijke lijn. Welke basiskennis moet een student hebben aan het eind van de studie? Deze basiskennis zou in elk vak, in elk curriculum moeten terugkeren. Bijvoorbeeld: webdesign studenten moeten een gedegen basiskennis hebben van typografie en grids, en studenten die developer willen worden moeten verstand hebben van OO en functioneel programmeren. Dus meer kennis van de principes achter het programmeren dan kennis van een specifieke taal. Taal-agnostisch, dus. Deze principes moeten telkens terugkeren door de jaren heen.</p>
<p>Het is ook een klacht die ik van veel studenten heb gehoord. Ze hebben van alles wel wat geleerd, maar nergens weten ze echt iets van. Dat is natuurlijk een probleem. Wat heeft het bedrijfsleven aan zo iemand? Wat is het nut van een HBO-papiertje als iemand niks echt weet?</p>
<h2>Wat kan Fronteers hier doen</h2>
<p>Fronteers kan helpen om mee te denken wat er bijvoorbeeld voor basiskennis nodig is op het gebied van Het Web. Wat moet iemand weten die wil werken op het web? Welke basiskennis hoort hierbij? Bijvoorbeeld: de flexibele eigenschappen van het web, het feit dat je geen controle hebt over hoe iets er uit ziet, progressive enhancement, maar ook manieren van programmeren, performance, etc. Hier horen vast nog veel meer dingen bij, maar dit is iets waar Fronteers een bijdrage aan kan leveren. Veel opleidingen zijn nu op zoek naar die basisvaardigheden, hier moeten we bij aanhaken. Er zijn inmiddels twee discussies hierover gestart op het forum; een over <a href="http://forum.fronteers.nl/topic/90/basiskennis-van-een-webdesigner/">de basiskennis van een webdesigner</a>, en een over <a href="http://forum.fronteers.nl/topic/89/basiskennis-van-een-frontend-developer/">de basiskennis van een frontend developer</a>.</p>
<h2>Curricula</h2>
<p>Een groot probleem waar docenten mee worstelen zijn de curricula. Die maken ze vaak zelf, en het is lastig om ze up-to-date te houden. Ik heb voorgesteld dat docenten hun lespakketten op github zetten. Op deze manier kunnen docenten van verschillende opleidingen er samen aan werken. Updaten is dan niet meer een grote klus, het is iets wat geleidelijk aan kan gebeuren, waar meerdere mensen tegelijk aan kunnen werken.</p>
<p>Leden van Fronteers kunnen meekijken naar deze curricula en ook actief een bijdrage leveren in de vorm van pull requests, bug reports etc. We hebben die kennis in huis, dit is een manier van bijdragen die gestructureerd is en relatief weinig tijd kost. Curricula blijven zo up-to-date. Er kunnen zo ook meerdere curricula ontwikkeld worden, docenten krijgen zo meer keus. Fronteers zou een repository met links kunnen bijhouden van de verschillende curricula die er online te vinden zijn. Ook hier is inmiddels een <a href="http://forum.fronteers.nl/topic/88/links-naar-online-curricula/">forumpost aan gewijd</a>, en we nodigen jullie van harte uit om hier aan bij te dragen.</p>
<p>Een alternatief, of een aanvulling op zo'n repository zou ook een <em>leercentrum/kenniscentrum</em> kunnen zijn. Bramus van Damme formuleerde het zo: Collectie van hoofdstukken en/of lijst van relevante artikels (links, reeds geprefiltered door de curatoren) over bepaalde onderwerpen. Bij voorkeur gegroepeerd per hoofdonderwerp (html, css, javascript), alsook aangeboden in een traject/pakket (vb: om CSS te leren is er een traject van presentatie X, presentatie Y, filmpje Z, en link Q te doorlopen).</p>
<h2>Kennis</h2>
<p>Een duidelijk probleem bij docenten is up-to-date blijven. Mensen stappen vaak over vanuit het zakenleven naar het onderwijs en hun kennis begint dus snel weg te zakken. Hier kan Fronteers ook een goede bijdrage aan leveren in de vorm van cursussen, workshops. Dit kunnen de reguliere workshops zijn die Fronteers al organiseert, maar dit kunnen ook op maat gesneden cursussen zijn voor specifieke groepen docenten. We moeten een manier vinden waarop docenten ons kunnen benaderen met een specifieke vraag, waarop wij kunnen gaan zoeken naar een goede specialist voor een workshop/cursus. We hebben een goed Nederlands netwerk, maar we kunnen eventueel ook internationale specialisten laten overkomen voor onderwerpen waar veel animo voor is.</p>
<p>Op dit gebied, van kennisdeling, is natuurlijk nog veel meer mogelijk. Mocht je hier goede ideeën over hebben, <a href="http://forum.fronteers.nl/forum/2/fronteers/">start hier gerust een discussie over op het forum</a>.</p>
<h2>Docentendagen</h2>
<p>We willen een docentendag organiseren waarbij we mensen van het zakenleven en van opleidingen bij elkaar brengen. MBO docenten kunnen zo overleggen met HBO docenten over aansluiting, en docenten kunnen zo horen waar het bedrijfsleven nu eigenlijk op zit te wachten. Zulk soort dagen moeten inhoudelijk en praktisch georganiseerd worden.</p>
<p>Naast dit soort wat grotere evenementen kunnen er ook kleinere bijeenkomsten georganiseerd worden met een wat specifieker karakter. Te denken valt er aan brainstormsessies tussen het bedrijfsleven en het onderwijs om te zien wat er <em>hot</em> is.</p>
<p>Dit soort bijeenkomsten zouden idealiter ook leiden tot betere <em>horizontale samenwerkingsverbanden</em> tussen verschillende instellingen en het bedrijfsleven.</p>
<h2>Contacten met bestuurders/overheden</h2>
<p>Bramus van Damme kwam met het goede idee om contacten met overheden/bestuursleden van onderwijsinstellingen te onderhouden: &quot;ons kenbaar maken bij de overheden om een betere erkenning van de opleiding/het beroep. Voor instructoren bijvoorbeeld kan dit zeer concreet gaan naar het mee in rekening brengen van de snelheid waarmee alles gaat bij het berekenen van een taakbelasting (dom voorbeeld: een lesgever wiskunde kan perfect 10 jaar aan één stuk de zelfde cursus aanbieden, wij mogen al blij zijn dat die meer dan één jaar mee gaat), of het mogelijk maken om instructoren lesvrij te stellen en op stage te sturen na X aantal jaar (hiervoor is er een structurele verandering nodig waar vaak nog het aantal fulltime equivalenten enkel op het aantal studenten berekend wordt).&quot;</p>
<h2>Praktisch</h2>
<p>Jeroen Hulscher en ik hebben inmiddels een paar keer geprobeerd om geïnteresseerden in een lidmaatschap van de onderwijscommissie bij elkaar te krijgen. Dit blijkt wat lastig te zijn. We stellen dan ook voor om de eerste bijeenkomsten digitaal te doen, via verschillende kanalen. Iedereen kan mee komen praten op het informele IRC kanaal <a href="irc://irc.freenode.net/fronteers_onderwijs">#fronteers_onderwijs</a> op <a href="http://webchat.freenode.net/?channels=fronteers_onderwijs">Freenode</a>. Alle Fronteers-leden worden uiteraard uitgenodigd om op <a href="http://forum.fronteers.nl/">het forum</a> mee te discussiëren over de bovenstaande onderwerpen. En mensen die zich actief willen inzetten om een van de genoemde activiteiten te verwezenlijken worden lid van de commissie en worden toegevoegd aan de mailinglijst.</p>
</content>
</entry>
<entry>
<title>Loop vast warm voor de Algemene Ledenvergadering 2013</title>
<link href="https://www.fronteers.nl/nl/blog/2013/10/loop-vast-warm-voor-de-algemene-ledenvergadering-2013"/>
<updated>2013-10-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/10/loop-vast-warm-voor-de-algemene-ledenvergadering-2013</id>
<content xml:lang="nl" type="html"><p>Exacte gegevens volgen binnenkort, maar de datum staat vast, dus die kan vast in je agenda: maandagavond 25 november vindt in Utrecht (nabij C.S.) de Algemene Ledenvergadering van Fronteers plaats.</p>
<p>Op de inhoud komen we nog terug, maar de hoofdmoot van de avond wordt gevormd door een terugkoppeling van de commissies die binnen Fronteers opereren, de bestuursverkiezing, en het bespreken van de begroting en nieuwe beleidsvoorstellen.</p>
<p>Heb je nu al vragen of voorstellen, reageer dan via het blog of <a href="https://www.fronteers.nl/nl/vereniging/contact/">neem contact op met bestuur</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij Digiti in Zoersel (Antwerpen)</title>
<link href="https://www.fronteers.nl/nl/blog/2013/10/bijeenkomst-digiti"/>
<updated>2013-10-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/10/bijeenkomst-digiti</id>
<content xml:lang="nl" type="html"><p>Op 31 oktober e.k. is Fronteers voor de tweede keer te gast bij <a href="http://www.digiti.be/">Digiti Interactive Media</a> in Zoersel bij Antwerpen. Zoals steeds, hebben we twee uitstekende sprekers kunnen strikken.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00: Ontvangst met belegde broodjes en een drankje</li>
<li>19:00: Bert Timmermans van <a href="http://www.digiti.be/">Digiti</a> vertelt over zijn <em>uit de hand gelopen Pokémon-remake-project in HTML5</em></li>
<li>20:00: Kristof Houben van Mobile Vikings deelt graag zijn kijk op <em>design thinking</em> met jullie</li>
<li>21:00: Naborrelen met een drankje</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Digiti in Zoersel (bij Antwerpen). Er is een plannetje beschikbaar op de <a href="https://www.fronteers.nl/bijeenkomsten/2013/bijeenkomst-bij-digiti-op-31-oktober">detailpagina van deze bijeenkomst</a>.</p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 75 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2013/digiti">Meld je daarom aan via het aanmeldformulier</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Discussieer mee over de toekomst van styling op het web met Bert Bos</title>
<link href="https://www.fronteers.nl/nl/blog/2013/09/bijeenkomst-what-should-the-web-look-like"/>
<updated>2013-09-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/09/bijeenkomst-what-should-the-web-look-like</id>
<content xml:lang="nl" type="html"><p>Donderdag 3 oktober organiseren de Internet Society Nederland (ISOC), Waag Society en W3C Benelux een bijeenkomst onder de titel &quot;What should the web look like next&quot;. Het design en de bouw van websites en -applicaties wordt sterk bepaald door de (on)mogelijkheden van de techniek. Zaken die door CSS makkelijk (of mogelijk) worden gemaakt zie je overal terug, en hebben daarmee grote invloed op de uitstraling, portabiliteit en individualiteit van websites en de gebruiksvriendelijkheid van webapplicaties en games. Onder leiding van Bert Bos (een van de grondleggers van CSS) wordt er een avond lang ingegaan op vragen als &quot;Hoe willen we als creatieve industrie dat het web er over tien jaar uitziet?&quot; en &quot;Aan welke features heb jij behoefte?&quot; Dit is je kans om invloed uit te kunnen oefenen op het ontwerpproces van de toekomstige standaarden!</p>
<p>Het programma van de avond ziet er als volgt uit:</p>
<ul>
<li>19.45 uur Deuren open</li>
<li>20.00 uur Intro</li>
<li>20.10 uur Bert Bos aan het woord</li>
<li>20.45 uur Plenaire discussie</li>
<li>21.30 uur (Decentrale) voortzetting van de gesprekken annex borrel</li>
<li>22.30 uur Einde</li>
</ul>
<p>En dit alles vindt plaats bij De Waag, aan de Nieuwmarkt 4 te Amsterdam.</p>
<p><a href="http://waag.org/nl/event/bert-bos">Schrijf je nu gratis in</a></p>
</content>
</entry>
<entry>
<title>Fronteers zeiluitje 2013</title>
<link href="https://www.fronteers.nl/nl/blog/2013/09/fronteers-zeiluitje-2013"/>
<updated>2013-09-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/09/fronteers-zeiluitje-2013</id>
<content xml:lang="nl" type="html"><p>Wat kan je nou weer schrijven over een middagje zeilen met Fronteers-nerds? Feitelijk komt het namelijk hier op neer: <a href="https://mapsengine.google.com/map/viewer?mid=zr5DYH-X-oKg.kMAX99Ddbwp4">na een paar ruime bézier-curves, en een tijdelijke vastloper</a>, kwamen we uiteindelijk weer aan waar we vertrokken waren. In Muiden. Maar deze bézier-curves trokken we niet met een slimme webtool, we moesten ze <em>fysiek</em> creëren door aan touwen te sjorren, aan stuurwielen te draaien, door de fokkel, de gaffel en de snoevel op tijd bij te foksen, door het glooizeil strak te laten doorbokkelen, en door punten aan de einder als referentie te nemen. <em>“Wat inefficiënt en onbetrouwbaar!”</em> hoor ik u denken, en zo was het maar net. Gelukkig zitten wij al weer veilig en wel achter onze computers <em>echte</em> bézier-curves te programmeren.</p>
<p><img src="https://www.fronteers.nl/_img/2013/bezier.png" alt="De gevaren bézier curves" /></p>
<p>Maar deze verandering van omgeving, het verkeren in de buitenlucht, was eigenlijk best prettig. Iemand merkte, terecht, op dat het allemaal best wel op Google Earth leek. Alleen dan een stuk trager natuurlijk: als een stuk zee een beetje saai was, dan kon je helaas niet gewoon even wat harder doorscrollen naar iets spannends. Gelukkig hadden we voor dat soort momenten allemaal onze telefoons bij ons waardoor we het contact met de <em>echte</em> wereld niet kwijtraakten. Ik heb wel eens gehoord over mensen die kikken op snelle hardware en gepolijste software, die waren gelukkig niet aan boord. De conclusie was toch duidelijk dat de Nokia Aisha het mooiste apparaat was, vooral vanwege het feit dat het een puur <em>single-task-driven</em> apparaat is. Je kan óf een foto maken, óf muziek luisteren, niet allebei. Verfrissend. Het bijzonder inaccurate <em>touch-screen</em> van de spiksplinternieuwe ZTE Open met Firefox OS er op werd ook zeer op prijs gesteld. Nu IE6 weg is moeten we onze uitdagingen elders zoeken.</p>
<p>Maar eens <em>face to face</em> met een groepje mensen praten, dat heeft toch eigenlijk ook wel wat. We hebben gesproken over het organiseren van bijeenkomsten, over ontwerpen voor grote én kleine schermen, over toekomstplannen, over de vraag of het al tijd was om wijn te drinken, over synchronisatiesoftware, over progressive enhancement, over de (on)mogelijkheid van responsive design. We hebben de saaie skyline van Amsterdam vergeleken met de indrukwekkende skylines van Tilburg en van Stadskanaal a.k.a. 'Manhattan aan 't K’noal'. Ik heb met mensen — partners van — gesproken over kindvriendelijke wijken, over goede scholen, over de kinderen, en over <em>werk</em>. Ik heb gehoord dat mensen het over JavaScript hadden, over closures enzo. Het nadeel van al deze gesprekken is natuurlijk, dat je ze niet even kunt teruglezen, zoals op IRC. We zullen het dus moeten doen met ons <em>fysieke</em> geheugen. En met <a href="http://www.ipernity.com/doc/337525/album/518837">de foto’s van Edwin</a>.</p>
<p>Voor mij was het voor het eerst dat ik meezeilde. Ik heb genoten. Eindelijk eens écht de tijd om met een paar mensen bij te praten. Eindelijk de tijd om een paar mensen in het echt te ontmoeten en om van gedachten te wisselen. Gewoon eens een uur lang ouwehoeren over de mogelijke weergave van een theater in een responsive booking tool. Gewoon even lekker klagen over designers <em>zonder dat ze zich er mee gaan bemoeien op Twitter!</em> En gewoon lekker een middag lang rode wijn drinken en gebraden vlees eten. <a href="https://twitter.com/paulvanbuuren/status/381494369980653568/photo/1/large">De schat</a> hebben we dit jaar niet gevonden. Des te meer reden om uit te zien naar het trippie van volgend jaar!</p>
</content>
</entry>
<entry>
<title>De congrescommissie zoekt actieve leden</title>
<link href="https://www.fronteers.nl/nl/blog/2013/09/de-congrescommissie-zoekt-actieve-leden"/>
<updated>2013-09-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/09/de-congrescommissie-zoekt-actieve-leden</id>
<content xml:lang="nl" type="html"><p>Het Fronteerscongres is een van de allertofste en meest opvallende dingen die Fronteers doet. Het wordt elk jaar bezocht door enkele honderden internationale bezoekers en het wordt geroemd om de hoge kwaliteit van de sprekers (en de relaxte ambiance!). Het organiseren van dit congres wordt gedaan door een kleine groep zeer gedreven vrijwilligers, die hier enorm veel tijd insteken. Niet iedereen heeft hier elk jaar de tijd voor, en dus ook dit jaar zijn er weer een paar leden die de congrescommissie gaan verlaten. We zijn dus weer op zoek naar nieuwe leden voor deze commissie.</p>
<p>Lid zijn van de congrescommissie is geen luizenbaantje, helaas. De handen moeten uit de mouwen. Er moet een selectie van (internationale) sprekers gemaakt worden, deze mensen moeten stuk voor stuk uitgenodigd (en overtuigd) worden, ze moeten gehuisvest worden, ze moeten hierheen gevlogen worden (met hun moeder, als ze daar om vragen), ze moeten vertroeteld worden en gestimuleerd om een absolute top-presentatie te geven. Er moet een zaal geregeld worden met zachte stoelen, betrouwbare Wifi, met een goede lunch, met een goede technische dienst, met voldoende WC's en meer dan genoeg te drinken. Er moeten badges ontworpen worden, en T-shirts, en goodies, en banners, en een site wellicht! Er moet een sprekersdiner georganiseerd worden, en een pre-party, en een tussen-party, en eventueel een after-party. De kaartverkoop moet geregeld worden, de financiën moeten op orde zijn, er moeten mails en tweets beantwoord worden van bezoekers, sprekers, mensen die geen kaartje hebben, mensen die een kaartje overhebben, sponsoren en blije fans. De website moet gevuld worden met relevante informatie voor zowel lokale als internationale bezoekers. Er moeten vrijwilligers gevonden worden zodat alles tijdens het congres zelf op rolletjes loopt. En alsof dat niet genoeg is, er moeten naast het congres óók nog een paar workshops geregeld worden, wat neerkomt op een herhaling van het bovenstaande. Bovendien zit het Fronteersbestuur continu in je nek te hijgen. Dit is veel werk. En nog niet eens alles wat er gedaan moet worden.</p>
<p>Hopelijk haken sommigen door deze opsomming af, en dat is ook de bedoeling. Het is namelijk écht veel werk, en we willen graag voorkomen dat je je daar op verkijkt. Hoeveel werk het precies is is natuurlijk lastig te zeggen. In december zal het natuurlijk rustiger zijn dan in de weken voor het congres. Hou er rekening mee dat je veel van je vrije tijd gaat besteden aan de mooie taak van het organiseren van een topcongres.</p>
<p>Mocht bovenstaande, incomplete, opsomming van taken je juist aanspreken, en mocht je graag, het liefst meerdere jaren, mee willen werken aan een van dé nerd-happenings van Nederland, meld je dan via onderstaand formulier aan als commisielid. Met een motivatie, met <a href="https://www.fronteers.nl/congres/2013/colophon">de werkzaamheden die je graag zou willen doen</a>. Je gaat dan wellicht deel uitmaken van een bijzonder toffe, goed geoliede, ervaren commissie, en je kunt dan rekenen op de ondersteuning van (oud) leden. Maar onthoud, het is absoluut een eervolle taak, een heel erg leuk om te doen, en een groot feest, maar het is ook écht heel veel werk.</p>
<p>Als je nog vragen hebt hierover, neem dan contact op met een van de <a href="https://www.fronteers.nl/congres/2013/colophon">huidige leden van de commissie</a>. Je kan hun contactgegevens gewoon vinden op het internet! Ze zijn ook vaak te vinden op het <a href="http://webchat.freenode.net/?channels=fronteers">IRC kanaal van Fronteers</a> en ze lopen natuurlijk rond op het congres zelf. Jezelf aanmelden kan tot 21 oktober. Eind oktober, begin november krijg je dan te horen of je je volgend jaar uit de naad mag werken voor de volgende editie van dit prachtige evenement.</p>
</content>
</entry>
<entry>
<title>Zomerborrel in Utrecht op 30 augustus</title>
<link href="https://www.fronteers.nl/nl/blog/2013/08/zomerborrel-utrecht"/>
<updated>2013-08-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/08/zomerborrel-utrecht</id>
<content xml:lang="nl" type="html"><p>Omdat het zomer is, en borrelen leuk is, organiseert Fronteers weer een zomerborrel. De borrel vindt plaats bij <a href="http://www.kingarthur-utrecht.nl/">King Arthur</a> aan de Oudegracht in Utrecht. Iedereen is welkom om een drankje mee te genieten op deze avond vanaf circa 18:00.</p>
<p>Geef hieronder in de reacties door als je aanwezig zult zijn. Er is geen tafel gereserveerd, dus houd een oog open voor Fronteers-gerelateerde goodies die aangeven waar de groep zit. Zoals gebruikelijk is het eerste drankje op kosten van Fronteers! Tot vrijdag!</p>
</content>
</entry>
<entry>
<title>Update van de commissie congres</title>
<link href="https://www.fronteers.nl/nl/blog/2013/08/update-congres"/>
<updated>2013-08-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/08/update-congres</id>
<content xml:lang="nl" type="html"><p>Fronteers 2013 is uitverkocht, kaarten voor de workshop van Harry Roberts zijn nu verkrijgbaar, er komt een speciale praktijksessie en we zullen weer boeken weggeven.</p>
<h2>Congres uitverkocht</h2>
<p>Zoals je misschien al gezien had, is Fronteers 2013 inmiddels uitverkocht. Het is dit jaar nog sneller gegaan dan eerdere jaren, en daar zijn we als commissie natuurlijk best een beetje trots op. Wie nog geen kaartje heeft, maar wel graag wil komen, kan het beste <a href="https://twitter.com/fronteersconf">@FronteersConf</a> op Twitter in de gaten houden. Met dit account retweeten we mensen die hun kaartje willen verkopen. Als we nog kaartjes beschikbaar maken, kondigen we het ook daar aan.</p>
<h2>Workshop: “planning and building a big front-end”</h2>
<p>Harry Roberts, bekend van zijn blog <a href="http://csswizardry.com/">CSS Wizardry</a>, zal dit jaar niet alleen spreken in het reguliere programma, hij gaat ook een eendaagse workshop geven. Harry zal ingaan op front-end development voor grote websites, waarbij de focus zal liggen op HTML en CSS. Denk bijvoorbeeld aan code-organisatie, slimme naamgeving, performance en effectief gebruik van SASS. De workshop vindt plaats op de dag voor het congres in het mooie <a href="http://felixmeritis.nl/">Felix Meritis</a> en wordt gegeven in het Engels.</p>
<p>De kosten: €350, exclusief btw, inclusief lunch. Fronteersleden krijgen €75 korting; gebruik hiervoor de link waarmee je ook ledenkaarten kon kopen. Voor wie nog geen kaartje heeft voor het congres zelf: er zijn ook enkele combinatietickets beschikbaar, zolang de vooraad strekt.</p>
<ul>
<li><a href="http://fronteers.paydro.net/">Tickets voor niet-leden</a></li>
<li>Tickets voor leden: zie nieuwsbrief eind april of mail ons voor de link (congres@fronteers.nl)</li>
</ul>
<h2>Nieuw programma-onderdeel: de praktijksessie</h2>
<p>Dit jaar introduceert Fronteers een nieuw onderdeel in het programma. Tijdens deze ‘praktijksessie’ geven we het woord aan drie makers van websites die het afgelopen jaar opvielen. Ze zullen tien minuten over het project vertellen, waarna er tien minuten ruimte is voor vragen uit de zaal. De projecten: <a href="http://rijksmuseum.nl/">Rijksmuseum</a> (met Elaine Oliver van Q42), <a href="http://gov.uk/">GOV.UK</a> (met Edd Sowden van GDS) en <a href="http://9292.nl/">9292.nl</a> (met Anton Vanhoucke van Fabrique).</p>
<h2>Book raffle</h2>
<p>Wegens succes herhaald: de book raffle. Net zoals vorig jaar zullen we ook dit jaar weer een grote hoeveelheid boeken verloten. We hebben contact gezocht met een aantal van de betere uitgeverijen van boeken over front-end development, en die hebben zich wederom gul getoond. Iedereen met een (betaald) ticket doet automatisch mee: het grote scherm kiest de namen en de winnaars mogen uitzoeken.</p>
</content>
</entry>
<entry>
<title>Update Workshop Commissie</title>
<link href="https://www.fronteers.nl/nl/blog/2013/08/update-workshop-commissie"/>
<updated>2013-08-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/08/update-workshop-commissie</id>
<content xml:lang="nl" type="html"><p>Het is de afgelopen tijd wat rustig geweest op workshopgebied maar op 20 september zal Arjan Eising zijn workshop ‘jQuery Inception’ nogmaals geven, bij Seats2Meet in Utrecht. Daarnaast is de commissie op zoek naar versterking.</p>
<p>Tijdens de workshop jQuery Inception zul je de basis van JavaScript programmeren en het gebruik van jQuery leren. Aan het einde van de dag ben je niet alleen in staat JavaScript code te lezen en begrijpen, maar ook zelf te plannen en uit te programmeren. Meer informatie over de workshop, en het aanmelden ervoor, vind je op de pagina <a href="https://www.fronteers.nl/workshops/jquery-inception-arjan-eising">jQuery Inception</a>.</p>
<p>Verder is de commissie met het oog op een aanstaande wisseling van de wacht, op zoek naar een nieuw lid. Als lid denk je mee over de toekomst van de commissie en handel je praktische zaken af die nodig zijn om een workshop neer te zetten. Denk daarbij aan het mailen met trainers en mensen die zich opgeven voor workshops, het boeken van de locatie, etcetera. Als je interesse hebt stuur dan een e-mail via <a href="https://www.fronteers.nl/workshops">dit formulier</a> (kies &quot;een andere...&quot;).</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 11 juli bij MMLab</title>
<link href="https://www.fronteers.nl/nl/blog/2013/07/bijeenkomst-mmlab"/>
<updated>2013-07-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/07/bijeenkomst-mmlab</id>
<content xml:lang="nl" type="html"><p>Op donderdag 11 juli 2013 is Fronteers te gast bij <a href="http://multimedialab.elis.ugent.be/about">Multimedia Lab (iMinds / Universiteit Gent)</a> in Gent. Er worden twee presentaties voorzien.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met een drankje</li>
<li>19:00 Tom Van Goethem over <em>Security Analysis of the Belgian Web</em></li>
<li>20:00 Ruben Verborgh over <em>The Web — a hypermedia story. Past, present, and future.</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij MMLab te Gent. <a href="https://www.fronteers.nl/bijeenkomsten/2013/mmlab">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 60 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>30% korting op From the Front 2013 in Bologna</title>
<link href="https://www.fronteers.nl/nl/blog/2013/05/korting-from-the-front-bologna"/>
<updated>2013-05-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/05/korting-from-the-front-bologna</id>
<content xml:lang="nl" type="html"><p>Net als <a href="https://www.fronteers.nl/blog/2012/05/korting-treasure-of-frontend-island-bologna">vorig jaar</a> geeft <a href="http://2013.fromthefront.it/">From the Front</a> in Bologna, Italië, op 20 september 2013, ons weer 30% korting op hun congres. Dit jaar is het thema: The Frontend Brothers.</p>
<p>Sprekers zijn dit jaar Seb Lee-Delisle, Aaron Gustafson, Nishant Kothary, Marta Armada, Rachel Nabors, Relly Annett-Baker, Paul Annett, Ben Hammersley en Sebastian Golasch. Vorig jaar maakten 5 van onze leden gebruik van deze korting en de reviews waren erg goed!</p>
<p>Een kaartje kost normaal € 99,- (als je een EU btw-nummer hebt); na de 30% korting slechts € 69,30. De korting geldt niet voor de workshops op 19 september.</p>
<p>Wil je gebruik maken van deze korting, <a href="https://www.fronteers.nl/nl/vereniging/contact/">neem dan even contact op</a> met de ledenadministratie. Zoals gebruikelijk geldt de korting uitsluitend voor diegenen die op dit moment lid zijn.</p>
</content>
</entry>
<entry>
<title>BBQ bij eFocus in Amsterdam op 20 juni</title>
<link href="https://www.fronteers.nl/nl/blog/2013/05/bbq-bij-efocus"/>
<updated>2013-05-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/05/bbq-bij-efocus</id>
<content xml:lang="nl" type="html"><p>Donderdag 20 juni is Fronteers te gast bij <a href="http://www.efocus.nl/">eFocus</a> in Amsterdam. Naast een
presentatie van Jeroen Hulscher trakteert eFocus op een BBQ.</p>
<h2>Programma</h2>
<ul>
<li>18:00 inloop met BBQ</li>
<li>19:30 uitgebreide kennissessie met Jeroen Hulscher</li>
<li>21:30 borrelen</li>
<li>22:30 einde</li>
</ul>
<p>&quot;Toegankelijk bouwen is onzin, ik heb geen blinde bezoekers.&quot; Geen uitspraak zo ondoordacht als deze, want als we het hebben over zoekmachines wil iedereen ineens bovenaan de resultaten verschijnen. En zoekmachines zijn allen doof, blind en motorisch beperkt. Bovendien is ontoegankelijke informatie voor niemand prettig te gebruiken, en hebben we allemaal baat bij begrijpelijke content.</p>
<p>Tijdens deze sessie kijken we onder de motorkap van het internet en zoomen we in op de gelaagdheid van onze producten. Hoe zorgen we ervoor dat onze boodschap bij iedereen overkomt zoals het bedoeld is, ongeacht technologische of menselijke beperkingen? We bespreken uitdagingen, oplossingen en met behulp van een mystery guest ontdekken we hoe mensen met een beperking gebruik maken van het internet.</p>
<h2>Bereikbaarheid en aanmelden</h2>
<p>eFocus is gevestigd aan de Cruquiusweg 109e, 1019 AG Amsterdam. <a href="http://www.efocus.nl/contact/route/amsterdam.aspx">Plan hier je route</a>. Kom bij voorkeur met openbaar vervoer want het aantal parkeerplaatsen is beperkt. Kijk op <a href="http://9292.nl/">9292.nl</a>, pak de fiets of ga eventueel carpoolen.</p>
<p>Zoals gebruikelijk is iedereen welkom, zowel leden, als niet-leden. Er is ruimte voor 50 deelnemers. Wel is gewenst dat je doorgeeft dat je komt, via het <a href="https://www.fronteers.nl/bijeenkomsten/2013/efocus">formulier op de bijeenkomstpagina</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij eBuddy in Amsterdam op 30 mei</title>
<link href="https://www.fronteers.nl/nl/blog/2013/05/bijeenkomst-ebuddy"/>
<updated>2013-05-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/05/bijeenkomst-ebuddy</id>
<content xml:lang="nl" type="html"><p>Donderdag 30 mei is Fronteers te gast bij <a href="http://ebuddy.com/">eBuddy</a> in Amsterdam. Twee presentaties staan op het programma. Jan van Hellemond vertelt over SVG voor het responsive web, en Andrei Rusu spreekt over client-side architectuur van server sent events.</p>
<h2>Programma</h2>
<ul>
<li>18:30 inloop</li>
<li>19:30 Jan van Hellemond – SVG voor het responsive web</li>
<li>20:30 korte pauze</li>
<li>20:45 Andrei Rusu – Real time client-server architecture using Server-Sent Events</li>
<li>21:45 borrel</li>
</ul>
<h2>SVG voor het responsive web</h2>
<p>Responsive Web Design wordt dé zomertrend van 2013. Internetgebruik op kleine schermen groeit enorm. En het aantal pixels per vierkante centimeter neemt razendsnel toe. Het wordt steeds moeilijker om al die pixels op al die formaten te vullen met de traditionele bestandsformaten GIF, JPEG en PNG. Vectoren hebben geen last van pixels. Met mathematische precisie schalen ze moeiteloos op en neer voor een strakke presentatie op elke formaat scherm, retina of niet.</p>
<p>Scalable Vector Graphics (SVG) zijn een eersterangs burger geworden in HTML5. Een totaaloplossing is het vooralsnog zeker niet. Jan ging op zoek naar de heilige graal en deelt graag zijn bevindingen.</p>
<h2>[lang=&quot;en&quot;] Real time client-server architecture using Server-Sent Events</h2>
<p>A talk on accelerating the delivery and processing of real-time events from server to client, along with a real life case example of Server-Sent Events in action.</p>
<h2>Bereikbaarheid en aanmelden</h2>
<p>eBuddy is gevestigd aan Keizersgracht 585, 1017 DR Amsterdam. Zoals gebruikelijk is iedereen welkom, zowel leden, als niet-leden. Wel is gewenst dat je doorgeeft dat je komt, via het <a href="https://www.fronteers.nl/bijeenkomsten/2013/ebuddy">formulier op de bijeenkomstpagina</a>.</p>
</content>
</entry>
<entry>
<title>€60 korting op workshop RWD in de praktijk</title>
<link href="https://www.fronteers.nl/nl/blog/2013/05/60-korting-op-workshop-rwd-in-de-praktijk"/>
<updated>2013-05-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/05/60-korting-op-workshop-rwd-in-de-praktijk</id>
<content xml:lang="nl" type="html"><p>Loop je tegen praktische problemen aan bij het doorvoeren van de principes van responsive webdesign (RWD) in je workflow? Zit je middenin responsive webdesign en wil je er verder mee? Heb je oplossingen maar merk je dat die ten koste gaan van performance?</p>
<p>Frontlab uit Amsterdam heeft een workshop om je verder te helpen met precies dit soort kwesties. In een workshop van één dag wordt aan de hand van echte projectcode gekeken naar best practices voor development en workflow. Deelnemers krijgen bovendien het boek Responsive Design Workflow mee naar huis. Er zijn nog plaatsen vrij voor de <a href="https://web.archive.org/web/20231130204455/http://frontlab.nl/workshop-responsive-web-design">intensieve workshop op woensdag 22 mei 2013</a>.</p>
<p>Fronteersleden krijgen €60 korting op de toegangsprijs van €329. Vink bij het inschrijven aan dat je Fronteerslid bent en je krijgt automatisch korting. Je hoeft hiervoor niet eerst contact op te nemen met Fronteers.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 23 mei bij Thomas More</title>
<link href="https://www.fronteers.nl/nl/blog/2013/04/bijeenkomst-thomas-more"/>
<updated>2013-04-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/04/bijeenkomst-thomas-more</id>
<content xml:lang="nl" type="html"><p>Op donderdag 23 mei 2013 is Fronteers te gast bij de opleiding Interactive Multimedia Design aan <a href="http://www.thomasmore.be/">de Thomas More-hogeschool</a> te Mechelen met als centrale thema <em>data-visualisatie</em>.</p>
<p>Er worden twee presentaties voorzien. Toon Ketels (<a href="https://twitter.com/toonketels">@toonketels</a>) zal een intro geven over <a href="http://d3js.org/">D3.js</a>. Hoe werk je ermee, wat zijn de concepten achter de library en hoe ga je ermee aan de slag?</p>
<p>Andries De Reyghere, zaakvoerder van <a href="http://www.bitsoflove.be/">Bits of Love</a>, zal zijn inzichten delen over het runnen van een bedrijf dat zich specialiseert in data-visualisatie.</p>
<p>Daarnaast geven Bart de Man (<a href="http://www.ticketmatic.com/">Ticketmatic</a>), Johan Ronsse (<a href="http://wolfslittlestore.be/">Wolf’s Little Store</a>) en Piet Jaspers (<a href="http://10to1.be/">10to1</a>) een demo van hun werk met D3.js.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met een drankje — voor de hongerigen: er is een frituur vlakbij</li>
<li>19:15 Toon Ketels: <em>Intro to D3.js</em></li>
<li>20:00 Demo’s (Bart de Man, Piet Jaspers, Johan Ronsse)</li>
<li>20:30 Andries De Reyghere: <em>Insights in data visualisation</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Thomas More Mechelen, meerbepaald op Campus “De Vest” in aula 2. <a href="https://www.fronteers.nl/bijeenkomsten/2013/thomas-more">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa <strike>80</strike> <strong>100</strong> mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Fronteers 2013 kaartverkoop start op 25 april</title>
<link href="https://www.fronteers.nl/nl/blog/2013/04/fronteers-2013-kaartverkoop"/>
<updated>2013-04-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/04/fronteers-2013-kaartverkoop</id>
<content xml:lang="nl" type="html"><p>Op 10 en 11 oktober 2013 gaat het Fronteers-congres weer plaatsvinden, wederom in Pathé Tuschinski in Amsterdam. Op donderdag 25 april om 12:00 uur Nederlandse tijd gaat de kaartverkoop van start.</p>
<p>Net als in voorgaande jaren is er een beperkt aantal early bird kaarten dat verkocht wordt voor de reguliere kaartverkoop van start gaat. De kaartprijzen zijn niet veranderd ten opzichte van vorig jaar. <em>Voor de early bird kaarten geldt dit jaar wel: op=op, wees er dus snel bij.</em></p>
<p>Fronteers 2013 early bird kaartje (exclusief 21% btw)
Fronteersleden €200
Niet-leden €275</p>
<p>Fronteers 2013 regulier kaartje (exclusief 21% btw)
Fronteersleden €275
Niet-leden €350</p>
<h2>Ledenkorting</h2>
<p>Wie op dit moment Fronteerslid is (vóór 22-04-2013) kan zijn of haar kaartje met korting kopen. Je hebt daarvoor <em>de kortingslink nodig uit de Fronteers-nieuwsbrief</em>, die rond de start van de kaartverkoop wordt verstuurd. Heb je donderdag aan het eind van de dag nog niets ontvangen? Controleer dan je spam folder. Als je daar ook niets vindt, <a href="mailto:congres@fronteers.nl">mail ons dan</a>.</p>
<h2>Programma</h2>
<p>Sprekers worden bekend gemaakt zodra de early bird kaarten zijn uitverkocht. Wel kunnen we vast een tipje van de sluier oplichten. We hebben een breed programma, met toffe sprekers over onder andere modulaire CSS, ECMAScript 6, responsive images en front-end performance. We doen ons uiterste best om Fronteers 2013 net zo goed, en misschien nog wel een beetje beter te maken dan voorgaande jaren!</p>
<p>Update:</p>
<p><img src="https://www.fronteers.nl/_img/congres/2012/graphics/buttons/buy.png" alt="Buy tickets (you will be sent to Paydro)" /></p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 25 april bij KaHo St-Lieven</title>
<link href="https://www.fronteers.nl/nl/blog/2013/04/bijeenkomst-kahosl"/>
<updated>2013-04-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/04/bijeenkomst-kahosl</id>
<content xml:lang="nl" type="html"><p>Op donderdag 25 april 2013 is Fronteers te gast bij de opleiding <a href="http://www.ikdoeict.be/">Professionele Bachelor ICT</a> (KaHo St-Lieven) te Gent. Er worden twee presentaties voorzien. Bram(us) Van Damme zal het hebben over hoe kaartprojecties, coördinatensystemen, en geografische data binnen een front-end geïmplementeerd kunnen worden; Bart De Clercq van AnySurfer geeft een presentatie over <em>accessibility</em> voor front-end-ontwikkelaars.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18:00 ontvangst met een drankje</li>
<li>19:00 Bram(us) Van Damme over <em>werken met geografische data binnen een front-end</em></li>
<li>20:00 Bart De Clercq over <em>accessibility voor front-end-ontwikkelaars</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats in het J-blok van de Technologiecampus van KaHo St-Lieven te Gent. <a href="https://www.fronteers.nl/bijeenkomsten/2013/kahosl">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Wie?</h2>
<p>Iedereen is welkom. Er is echter beperkt plaats, voor circa 70 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Updates uit de congrescommissie</title>
<link href="https://www.fronteers.nl/nl/blog/2013/04/updates-uit-de-congrescommissie"/>
<updated>2013-04-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/04/updates-uit-de-congrescommissie</id>
<content xml:lang="nl" type="html"><p>De congrescommissie heeft een nieuwe voorzitter, heeft een handboek gemaakt, probeert het dit jaar zonder sponsors en zal zeer spoedig de kaartverkoop aankondigen.</p>
<h2>Nieuwe voorzitter</h2>
<p>Begin april heeft Peter-Paul Koch de congrescommissie, waarvan hij tot dan voorzitter was, verlaten. De congrescommissie bedankt PPK voor zijn inzet tot zover, en heeft mij gekozen als nieuwe voorzitter. Ik ben Hidde de Vries, betrokken bij het congres sinds 2008. Eerst als vrijwilliger en sinds 2011 ook als lid van de organiserende commissie. Binnen de congrescommissie was ik vorig jaar onder andere verantwoordelijk voor het ontwerp en de sponsors. Dit jaar houd ik mij bezig met de sprekers.</p>
<h2>Handboek</h2>
<p>We werken, net als in 2010, weer met een handboek, samengesteld uit de ervaringen van afgelopen jaren. Het is gecheckt en verbeterd door meerdere betrokkenen, waaronder zij die er vanaf het begin bij waren: Krijn Hoetmer en Peter-Paul Koch (waarvoor dank!). Ons handboek helpt de organisatie van dit jaar, en kan als basis worden gebruikt voor eventuele komende jaren.</p>
<h2>Geen sponsors in 2013</h2>
<p>De afgelopen jaren werd het Fronteers-congres mede mogelijk gemaakt door diverse bedrijven uit binnen- en buitenland. We zijn deze bedrijven zeer erkentelijk. In 2013 willen we het echter een jaar zonder sponsors proberen; de begroting laat dit toe en de commissie kan zich zo op andere zaken richten.</p>
<h2>Kaartverkoop</h2>
<p>De kaartverkoop van Fronteers 2013 laat nog heel even op zich wachten, maar ik kan vast melden dat we daar deze week nog over zullen berichten. Houd dit blog in de gaten voor meer informatie!</p>
</content>
</entry>
<entry>
<title>Met korting naar Dutch Mobile Conference</title>
<link href="https://www.fronteers.nl/nl/blog/2013/04/met-korting-naar-dutch-mobile-conference"/>
<updated>2013-04-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/04/met-korting-naar-dutch-mobile-conference</id>
<content xml:lang="nl" type="html"><p>Vorig jaar kende de Dutch Mobile Conference haar debuut, met verschillende onderwerpen die laten zien hoe moderne web technologieën ingezet kunnen worden op de verschillende mobiele platformen die de wereld rijk is. In 2013 wordt de tweede editie georganiseerd, ditmaal zal het evenement van 6 t/m 8 juni plaatsvinden in de Amsterdam RAI. Speciaal voor Fronteers is er een kortingscode die recht geeft op 10% korting op het ticket na de early bird periode.</p>
<p>De Dutch Mobile Conference 2013 zal vele onderwerpen in de schijnwerpers zetten, dit begint op 6 juni waarop tutorials worden gegeven over onderwerpen als jQuery Mobile, Titanium, IndexedDB, Sencha Touch 2 en CSS3 voor mobile devices. Op 7 en 8 juni worden er reguliere talks gegeven die ieder drie kwartier duren, tijdens deze reguliere talks komen onderwerpen als debugging, AngularJS, responsive design, websockets en vele anderen aan bod. Als je het volledige aanbod wilt bekijken kun je een blik werpen op het schedule via <a href="http://www.mobileconference.nl/schedule">http://www.mobileconference.nl/schedule</a></p>
<p>Naast de conferentie zijn er ook een hoop activiteiten rondom het evenement, zo is er de social in de Escape Lounge, een Hackathon en voor degenen die zelf eens willen proeven hoe het voelt om op het podium te staan is er een ware unconference. Daarnaast geeft het ticket van de Dutch Mobile Conference ook toegang tot de Dutch PHP Conference die tegelijkertijd gehouden wordt.</p>
<p>De early bird loopt tot en met 28 april en geeft 15% korting op de normale ticket prijs. Om na de early bird periode gebruik te maken van de 10% kortingscode vul je bij het aankopen van je tickets de code <code>FRONTEERSDMC13</code> in.</p>
</content>
</entry>
<entry>
<title>Hackathon &quot;Automatiseer je front-end&quot;</title>
<link href="https://www.fronteers.nl/nl/blog/2013/04/hackathon-automatiseer-je-front-end"/>
<updated>2013-04-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/04/hackathon-automatiseer-je-front-end</id>
<content xml:lang="nl" type="html"><p>Op zaterdag 11 mei zal er een hackathon worden georganiseerd voor leden en niet-leden van Fronteers. De dag begint rond half 11 met twee korte presentaties onder het genot van een kopje koffie of thee. Na een verzorgde lunch kan gehackt worden aan een project wat ter plekke gepitcht kan worden. Aan het einde van de dag sluiten we af met een borrel zodat we kunnen zien wat iedereen gemaakt heeft.</p>
<h2>Programma van de dag</h2>
<ul>
<li>10:00 inloop met koffie en thee</li>
<li>10:30 presentatie Tom Greuter over GruntJS</li>
<li>11:00 presentatie Arjan Eising over het Jasmine testframework</li>
<li>11:30 pitchen van ideeën voor hackprojecten</li>
<li>12:00 verzorgde lunch</li>
<li>13:37 hacken!</li>
<li>17:00 borrel met korte demo's</li>
</ul>
<p>GruntJS en Jasmine zijn twee van de nieuwere tools voor front-end programmeurs om applicaties te builden en testen. Het doel van de dag is er eens iets mee te doen op een leuke, informatieve manier. Na de lunch zullen de twee presentatoren beschikbaar zijn voor uitleg als je ergens tegenaan loopt.</p>
<p>De hackathon is gratis voor leden en niet-leden en er is plek voor 30 hackers. Locatie is Nomadz op de 3de verdieping van Bink36 aan de Binckhorstlaan 36 in Den Haag. Aanmelden kan via het <a href="https://www.fronteers.nl/bijeenkomsten/2013/hackathon">formulier op de hackathon-pagina</a>.</p>
</content>
</entry>
<entry>
<title>Met korting Sencha Touch cursus volgen</title>
<link href="https://www.fronteers.nl/nl/blog/2013/03/korting-cursus-sencha-touch"/>
<updated>2013-03-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/03/korting-cursus-sencha-touch</id>
<content xml:lang="nl" type="html"><p>Wil je graag leren hoe je een mobiele app kunt bouwen? Met het <a href="http://www.sencha.com/products/touch/features/">Sencha Touch framework</a> kun je uitgebreide mobiele applicaties bouwen, voor iOS, Android, BlackBerry en meer. Sencha Touch geeft je mobiele web app de native look and feel en volgens de laatste HTML5 en CSS3 web standaarden.</p>
<p>Van 8 t/m 12 april is er een Sencha Touch 2.1 hands-on training aan de Keizersgracht in Amsterdam. Voor meer informatie zie: <a href="http://www.sencha.com/company/events/apr-8-12-fast-track-to-sencha-touch-2-advanced-architect-training-amste/">Fast Track to Sencha Touch + Advanced Architect </a>.</p>
<p>Het bedrijf achter Sencha Touch, Sencha Inc. heeft sinds kort de deuren geopend in Amsterdam. Om dit te vieren, mogen Fronteers leden met 10% korting de Sencha Touch cursus volgen.</p>
<p>Wil je er bij zijn? Om gebruik te maken van de korting, voer bij het registeren de volgende code in: front-touch</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij De Voorhoede op 18 april 2013</title>
<link href="https://www.fronteers.nl/nl/blog/2013/03/bijeenkomst-de-voorhoede"/>
<updated>2013-03-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/03/bijeenkomst-de-voorhoede</id>
<content xml:lang="nl" type="html"><p>Op donderdag 18 april is Fronteers te gast bij De Voorhoede in Amsterdam. De vorige Pecha Kucha was een groot succes en dat willen we dit jaar bij De Voorhoede herhalen.</p>
<p>Pecha Kucha is een presentatiestijl waarbij 20 slides worden getoond die elk 20 seconden in beeld zijn. Hierdoor krijg je snelle en beknopte presentaties. Door de korte tijd van 6 minuut 40 is het ook voor mensen die geen uur willen of kunnen volpraten. Heb je nog nooit een presentatie gegeven en wil je het een keer proberen, dan is dit de uitgeziene mogelijkheid.</p>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij de Voorhoede in Amsterdam. Het adres is Rijnsburgstraat 9 - 11, Amsterdam. <a href="https://maps.google.com/maps?q=Rijnsburgstraat+9-11,+Hoofddorppleinbuurt,+Amsterdam,+Nederland&amp;hl=nl&amp;sll=51.71133,5.295509&amp;sspn=0.148912,0.495415&amp;oq=rijnsburgstraat+9-11+&amp;hnear=Rijnsburgstraat+9,+Oud-Zuid,+Amsterdam,+Noord-Holland,+Nederland&amp;t=m&amp;z=16">Plan route via Google Maps</a>.</p>
<h2>Aanmelden</h2>
<p>Zoals gebruikelijk is deze bijeenkomst gratis bij te wonen door zowel leden als niet-leden. Aanmelden voor de bijeenkomst doe je via <a href="https://www.fronteers.nl/bijeenkomsten/2013/voorhoede">het formulier op de bijeenkomstpagina</a>. Er is ruimte voor 50 personen, inclusief sprekers.</p>
</content>
</entry>
<entry>
<title>Met korting naar Nationaal Congres Digitale Toegankelijkheid 2013</title>
<link href="https://www.fronteers.nl/nl/blog/2013/03/korting-nationaal-congres-digitale-toegankelijkheid-2013"/>
<updated>2013-03-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/03/korting-nationaal-congres-digitale-toegankelijkheid-2013</id>
<content xml:lang="nl" type="html"><p>Op 20 juni 2013 vindt het <a href="http://www.ncdt.nl/">Nationaal Congres Digitale Toegankelijkheid</a> plaats in Utrecht. Leden van Fronteers krijgen 30 procent korting op de toegangsprijs van €349, en betalen dus €244,30.</p>
<p>Er wordt onder andere aandacht besteed aan hoe responsive design en toegankelijkheid samengaan, het aanbieden van toegankelijke video en het schrijven van begrijpelijke teksten op het web. Dagvoorzitter is Francisco van Jole, en <a href="http://www.ncdt.nl/sprekers/">sprekers</a> zijn onder anderen Eric Velleman, Iacobien Riezebosch, Simon Besters, Ger Dreijer, Raph de Rooij en Wiep Hamstra.</p>
<p>Er zijn tien kortingscodes beschikbaar. Wie het eerst komt, het eerst maalt. <a href="https://www.fronteers.nl/nl/vereniging/contact/">Neem contact op</a>, en we sturen de code zo spoedig mogelijk naar je op.</p>
</content>
</entry>
<entry>
<title>Met korting naar Front-Trends 2013</title>
<link href="https://www.fronteers.nl/nl/blog/2013/03/met-korting-naar-front-trends-2013"/>
<updated>2013-03-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/03/met-korting-naar-front-trends-2013</id>
<content xml:lang="nl" type="html"><p>Van 24 tot en met 26 april dit jaar vindt <a href="http://2013.front-trends.com/">Front-Trends 2013</a> plaats. Net als vorig jaar in Warschau en ook dit jaar heeft Fronteers een aantal kortingscodes gekregen.</p>
<p>Na een succesvol tweedaags <a href="http://2012.front-trends.com/">congres in 2012</a> is Front-Trends dit jaar terug met een drie dagen durend programma. Voor leden van Fronteers hebben we tien kortingscodes gekregen. Normale kaarten kosten €349 maar Fronteers leden krijgen maar liefst 30% korting. Om een kortingscode op te vragen moet je even een mailtje met je naam en lidnummer sturen naar <a href="mailto:ledenadministratie@fronteers.nl">ledenadministratie@fronteers.nl</a>.</p>
<p>Wees er snel bij want op is op.</p>
</content>
</entry>
<entry>
<title>Workshops update februari</title>
<link href="https://www.fronteers.nl/nl/blog/2013/02/workshops-update-februari"/>
<updated>2013-02-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/02/workshops-update-februari</id>
<content xml:lang="nl" type="html"><p>Het is al weer enige tijd geleden sinds de laatste workshops update. In de tussentijd hebben we niet stil gezeten. We hebben de eerste workshops van het jaar weer achter de rug, er staan nieuwe gepland, en er gaat wat veranderen.</p>
<p>We zijn het jaar goed begonnen met twee populaire workshops. Op 18 januari <a href="https://www.fronteers.nl/workshops/screw-css-roy-tomeij">Screw CSS!</a> door Roy Tomeij gevolgd door <a href="https://www.fronteers.nl/workshops/future-css-bert-bos">Future CSS</a> door Bert Bos op 28 januari. Voor 13 maart hebben we een workshop over toegankelijkheid op het programma, te weten <a href="https://www.fronteers.nl/workshops/inclusive-design-jeroen-hulscher">Inclusive Design</a> gegeven door Jeroen Hulscher. Hiervoor zijn <strike>nog 3</strike> <strong>inmiddels geen</strong> plekken<strong>meer</strong> beschikbaar. <strike>Schrijf je dus snel in als je mee wilt doen!</strike></p>
<p>Zoals gezegd gaat er ook wat veranderen. De prijzen voor workshops zijn al vrij lang €100 voor leden en €200 voor niet-leden. Het goede nieuws is dat dát vooralsnog niet gaat veranderen. Het misschien wat minder goede nieuws —althans als je nog geen lid bent— is dat het niet langer mogelijk zal zijn om vlak voor inschrijving voor een workshop nog even snel lid te worden, à €60, om op die manier €40 te besparen.</p>
<p>Vanaf de eerstvolgende aan te kondigen workshop moet je namelijk <em>op het moment van aankondigen</em> al lid zijn om met ledenkorting deel te kunnen nemen. Mensen die zich als niet-lid inschrijven voor een workshop krijgen echter wel de mogelijkheid om, op het moment van inschrijven voor de workshop, voor €25 euro extra lid te worden en deel te nemen.</p>
<p>Samengevat:</p>
<ul>
<li>Leden: <em>€100</em></li>
<li>Niet-leden: <em>€200</em></li>
<li>Niet-leden + lidmaatschap Fronteers: <em>€225</em> (in plaats van €260)</li>
</ul>
<p>Nota bene, alle bedragen in deze post zijn exclusief btw.</p>
<p>Tot slot… aarzel vooral niet om hieronder een reactie achter te laten als je een vraag hebt over workshops, je graag een workshop over een bepaald onderwerp zou willen volgen, of zelf een workshop kunt geven.</p>
</content>
</entry>
<entry>
<title>75 euro korting voor Beyond Tellerrand</title>
<link href="https://www.fronteers.nl/nl/blog/2013/02/75-euro-korting-voor-beyond-tellerrand"/>
<updated>2013-02-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/02/75-euro-korting-voor-beyond-tellerrand</id>
<content xml:lang="nl" type="html"><p>Dit jaar vindt <a href="http://2013.beyondtellerrand.com/">Beyond Tellerrand</a> plaats op 27 en 28 mei, net over de grens in Düsseldorf. Als Fronteerslid krijg je € 74,70 korting op de ticketprijs van € 249,-.</p>
<p>Beyond Tellerrand is een kwalitatief hoogstaand congres dat zich focust op design, user interactie en natuurlijk front-end. Het congres vindt plaats op maandag en dinsdag, de woensdag is gereserveerd voor <a href="http://2013.beyondtellerrand.com/workshops">twee workshops</a> van Brad Frost en Aaron Gustafson.</p>
<p>Afgelopen jaar werd Beyond Tellerrand in november georganiseerd, dit jaar is het evenement verplaatst naar eind mei en vindt het wederom plaats in het sfeervolle Capitol Theater. Onder andere Josh Brewer, Elliot Jay Stocks, Mandy Brown en James Victoire hebben hun komst al bevestigd. De komende maanden zal het aantal sprekers tot 16 worden uitgebreid.</p>
<p>Wil je gebruikmaken van de € 74,70 korting en ben je Fronteers-lid, vraag dan een kortingscode aan. Er zijn 20 kortingscodes beschikbaar. Je kunt mailen naar <a href="mailto:ledenadministratie@fronteers.nl">ledenadministratie@fronteers.nl</a>.</p>
</content>
</entry>
<entry>
<title>Fronteers 2013: 10 en 11 oktober in Tuschinski</title>
<link href="https://www.fronteers.nl/nl/blog/2013/02/fronteers-2013-10-en-11-oktober-in-tuschinski"/>
<updated>2013-02-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/02/fronteers-2013-10-en-11-oktober-in-tuschinski</id>
<content xml:lang="nl" type="html"><p>Het zal sommigen misschien ontgaan zijn maar een paar weken terug gaven we een <a href="https://twitter.com/fronteersconf/status/294349733101707264">subtiele hint</a> dat we begonnen waren met de voorbereiding van Fronteers 2013.</p>
<p>We zijn verheugd dat we vandaag Fronteers 2013 officieel kunnen aankondigen. Op 10 en 11 oktober zullen we weer twee dagen te gast zijn in het schitterende <a href="http://nl.wikipedia.org/wiki/Tuschinski_Theater">Theater Tuschinski</a> in hartje Amsterdam.</p>
<p>Op dit moment hebben we verder nog niet zo veel te melden. We zijn hard aan het werk om Fronteers 2013 net zo goed en hopelijk nog een beetje beter te maken dan voorgaande jaren. Houd de website en <a href="https://twitter.com/FronteersConf">@FronteersConf</a> op Twitter in de gaten voor meer informatie de komende weken en maanden. Kaartjes gaan eind maart in de verkoop te beginnen met een beperkt aantal early bird kaarten. Uiteraard zal er korting zijn voor leden. Ledenkorting geldt alleen voor wie lid is op het moment dat de kaartverkoop wordt aangekondigd.</p>
<p>Successen uit het verleden zijn geen garantie voor de toekomst maar als ze een indicatie zijn, dan gaat 2013 weer een fantastisch congres worden! Tot in oktober!</p>
</content>
</entry>
<entry>
<title>100 euro korting voor GOTO Conference Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2013/02/100-euro-korting-voor-goto-conference-amsterdam"/>
<updated>2013-02-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/02/100-euro-korting-voor-goto-conference-amsterdam</id>
<content xml:lang="nl" type="html"><p>Op 18 t/m 20 juni is een algemeen softwarecongres, de <a href="http://www.gotocon.com/amsterdam-2013/">GOTO Conference Amsterdam</a> in de Beurs van Berlage. Leden van Fronteers krijgen 100 euro op deze congres.</p>
<p>GOTO Conference is algemeen softwarecongres waarop de organisatoren vonden dat front-end niet mocht ontbreken. Buiten de Frontend praatjes zijn er ook sessies over agile programming, back-end, big data, search, architecture en meer. Op 20 juni vinden er ook diverse workshops plaats. Voor meer infomatie zie <a href="http://www.gotocon.com/amsterdam-2013/tracks/">Tracks at GOTO Amsterdam2013</a>.</p>
<p>Wil je gebruik maken van de 100 euro korting en ben je Fronteers-lid, dan kun je een kortingscode opvragen middels een mailtje naar <a href="mailto:ledenadministratie@fronteers.nl">ledenadministratie@fronteers.nl</a>. Let op: Om de zoveel tijd neemt de prijs toe, dus de eerder je je inschrijft voor het event, de meer geld je bespaart. Let op de earlybird loopt nu 15 feb af en dan gaat de nieuwe earlybird prijs in.</p>
</content>
</entry>
<entry>
<title>Bijeenstorm in Enschede op 21 februari</title>
<link href="https://www.fronteers.nl/nl/blog/2013/01/bijeenstorm-enschede"/>
<updated>2013-01-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/01/bijeenstorm-enschede</id>
<content xml:lang="nl" type="html"><p><a href="http://trimm.nl/">TriMM</a> host op 21 februari een nieuw soort Fronteersbijeenkomst, een &quot;bijeenstorm&quot;. Doel is om zowel kennis te delen die je zelf hebt over front-end, maar ook iets te leren van andere knappe koppen. Daarnaast leer je die avond op een andere wijze je collega's front-enders kennen.</p>
<p><img src="https://www.fronteers.nl/_img/2013/bijeenstorm-trimm.jpg" alt="Poster bijeenstorm TriMM" /></p>
<p>Verover de front-end wereld met jouw mening over een front-end techniek, deze avond is je kans! A la hackathon kan iedereen in kleine groepen werken aan een korte presentatie. Hiervoor heb je 30 minuten, om daarna met de hele groep circa 5 minuten jullie visie te geven over een actueel front-end onderwerp. Je hoeft natuurlijk niet per se te spreken, maar deelnemen in een groepje is wel de bedoeling.</p>
<p>Onder het genot van een hapje en drankje zal de avond gevuld worden met veel discussie, leermomenten en het ontmoeten van nieuwe mensen. Aan het einde van de avond krijg je een leuke presentje mee.</p>
<p>Zoals gebruikelijk zijn zowel leden als niet-leden welkom en is de toegang gratis. Wel is het prettig als je doorgeeft dat je komt via <a href="https://www.fronteers.nl/bijeenkomsten/2013/trimm">het formulier op de bijeenkomstpagina</a>.</p>
</content>
</entry>
<entry>
<title>Workshop ‘Inclusive Design’ door Jeroen Hulscher</title>
<link href="https://www.fronteers.nl/nl/blog/2013/01/workshop-inclusive-design"/>
<updated>2013-01-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/01/workshop-inclusive-design</id>
<content xml:lang="nl" type="html"><p>Op woensdag 13 maart geeft Jeroen Hulscher zijn workshop ‘Inclusive Design’ voor de tweede keer voor bij Fronteers. Tijdens de workshop zul je de ins en outs leren voor het denken aan alle soorten gebruikers die van een website gebruik kunnen maken.</p>
<p>De workshop kost 100 euro voor leden, en 200 euro voor niet leden. Beide bedragen zijn exclusief 21% btw. Aanmelden kan via het <a href="https://www.fronteers.nl/workshops/inclusive-design-jeroen-hulscher/13-maart-2013#formulier-1">inschrijfformulier</a>. Meer informatie over de workshop vind je op de <a href="https://www.fronteers.nl/workshops/inclusive-design-jeroen-hulscher">workshoppagina</a></p>
</content>
</entry>
<entry>
<title>Bijeenkomsten op 22 januari en 7 februari</title>
<link href="https://www.fronteers.nl/nl/blog/2013/01/bijeenkomsten-januari-februari"/>
<updated>2013-01-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/01/bijeenkomsten-januari-februari</id>
<content xml:lang="nl" type="html"><p>Er zijn weer twee bijeenkomsten ingepland. Te weten bij <a href="http://www.studytube.nl/">StudyTube</a> te Amsterdam op dinsdag 22 januari, en op 7 februari, ook in Amsterdam, bij <a href="http://www.trifork.nl/">Trifork</a>.</p>
<h2>StudyTube – 22 januari 2013</h2>
<p>Matthew Eichler zal vertellen over het automatiseren van accepatatietesten. Jan van Hellemond zal daarna een presentatie geven over Amazon Web Services en hoe je als front-end developer hier gebruik van kunt maken.</p>
<p><a href="https://www.fronteers.nl/bijeenkomsten/2013/studytube">Lees meer over deze bijeenkomst bij StudyTube</a></p>
<h2>Trifork – 7 februari 2013</h2>
<p>Bij Trifork zal Ross Tuck een presentatie houden over hoe je het meeste kan halen uit HTTP. Daarna zal Breandán Knowlton vertellen over project management van een groot project.</p>
<p><a href="https://www.fronteers.nl/bijeenkomsten/2013/trifork">Lees meer over deze bijeenkomst bij Trifork</a></p>
<p>Zoals gebruikelijk zijn beide bijeenkomsten gratis toegankelijk voor zowel leden als niet-leden. Wel is gewenst dat je doorgeeft dat je aanwezig zult zijn via de formulieren op de hierboven gelinkte pagina's.</p>
</content>
</entry>
<entry>
<title>Nieuwjaarsborrel</title>
<link href="https://www.fronteers.nl/nl/blog/2013/01/nieuwjaarsborrel"/>
<updated>2013-01-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2013/01/nieuwjaarsborrel</id>
<content xml:lang="nl" type="html"><p>De beste wensen voor 2013! Om het jaar in te luiden, zijn er volgende week twee borrels waar je naartoe kunt gaan. De eerste is op donderdag 10 januari, georganiseerd door de overkoepelende organisatie voor internetinstanties, <a href="http://isoc.nl/">Internet Society Nederland</a>. Een dag later, vrijdag 11 januari, is onze eigen, semi-spontane borrel in De Bierfabriek in Amsterdam.</p>
<p>Internet Society Nederland organiseert 10 januari haar nieuwjaarsborrel, waarbij bijna twintig nationale en internationale spelers uit de internetwereld elkaar kunnen ontmoeten. Van e-infrastructuur tot .nl, van digitale burgerrechten tot en met digitale certificaten, van toegankelijkheid voor blinden tot hosting providers - iedereen doet mee. <a href="http://isoc.nl/activ/2013-nieuwjaar.htm">Aanmelden kan gratis op de website van ISOC.</a> Locatie is Het Sieraad, Postjesweg 1 in Amsterdam. De receptie begint om 17:30 met drankjes en buffet, en er staan verder lightning talks en een voorzittersdebat op het programma.</p>
<p>Fronteers zelf zal de mogelijkheid bieden met mede-fronteers te borrelen. Dit zal gebeuren op vrijdag 11 januari in <a href="http://www.bierfabriek.com/">De Bierfabriek</a> aan Rokin 75 te Amsterdam. Rond 17:00 zullen de eerste leden aanwezig zijn, en de eerste drankjes worden betaald door de vereniging. Laat in de comments even weten dat je hierbij aanwezig zult zijn.</p>
</content>
</entry>
<entry>
<title>Met 50% korting naar BlackBerry DevCon</title>
<link href="https://www.fronteers.nl/nl/blog/2012/12/met-50-korting-naar-blackberry-devcon"/>
<updated>2012-12-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/12/met-50-korting-naar-blackberry-devcon</id>
<content xml:lang="nl" type="html"><p>Net zoals vorig jaar komt <a href="http://www.blackberryjamconference.com/europe">BlackBerry DevCon</a> op 5 en 6 februari naar Amsterdam, en opnieuw kunnen we Fronteers-leden een korting van 50% aanbieden.</p>
<p>Vorig jaar werd er veel aandacht aan het web besteed, en was het congres over het geheel genomen verrassend goed. Ook kregen alle deelnemers een BlackBerry PlayBook. Dit jaar gaat de aandacht natuurlijk vooral uit naar BlackBerry 10, dat een week voor het congres gelanceerd wordt. Of alle deelnemers een BB10 device krijgen, is onduidelijk, maar er zal weer behoorlijk wat aandacht zijn voor het maken van web apps voor BB10.</p>
<p>Wil je gebruik maken van de 50% korting en ben je Fronteers-lid, dan kun je een kortingscode opvragen middels een mailtje naar <a href="mailto:ledenadministratie@fronteers.nl">ledenadministratie@fronteers.nl</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij Q42 op 8 januari 2013</title>
<link href="https://www.fronteers.nl/nl/blog/2012/12/bijeenkomst-q42"/>
<updated>2012-12-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/12/bijeenkomst-q42</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 8 januari 2013 is Fronteers te gast bij Q42 in Den Haag. Er worden drie presentaties gegeven. Johan Huijkman geeft de presentatie “UX Candy”, Remco Veldkamp bespreekt de uitdagingen die Q42 tegenkwam bij de ontwikkeling van de nieuwe website voor het Amsterdams Rijksmuseum en Elaine Oliver deelt tips en ervaringen over het opzetten van de OOCSS architectuur.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 Inloop met drank en snacks</li>
<li>19:00 Johan Huijkman; UX candy</li>
<li>19:30 Korte pauze</li>
<li>19:45 Remco Veldkamp; Zoomen tot op de kleinste pukkel van Vermeer's Melkmeisje</li>
<li>20:30 Elaine Oliver; There's a class for that</li>
<li>21:00 Borrel</li>
</ul>
<h2>Bereikbaarheid en opgave</h2>
<p>Q42 is gevestigd aan Waldorpstraat 17F, 2521 CA Den Haag.</p>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen voor zowel leden als niet-leden. Wel is gewenst dat je jezelf opgeeft via het formulier op de detailpagina van de <a href="https://www.fronteers.nl/bijeenkomsten/2013/q42">bijeenkomst</a>.</p>
</content>
</entry>
<entry>
<title>Workshop: ‘Future CSS’ door Bert Bos</title>
<link href="https://www.fronteers.nl/nl/blog/2012/12/workshop-future-css-door-bert-bos"/>
<updated>2012-12-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/12/workshop-future-css-door-bert-bos</id>
<content xml:lang="nl" type="html"><p>Op 28 januari geeft Bert Bos voor Fronteers een <a href="https://www.fronteers.nl/workshops/future-css-bert-bos">workshop</a> over wat er komen gaat in CSS. Bos is mede-uitvinder van de <em>cascading stylesheet</em> en is nu vanuit het W3C betrokken bij de verdere ontwikkeling van de opmaaktaal.</p>
<p>Die ontwikkeling is nog volop in gang. Denk daarbij bijvoorbeeld aan recente stabiele nieuwe modules als <em>mediaqueries</em> en kolommen, die al in veel browsers tot op zekere hoogte zijn geïmplementeerd, of aan meer experimentele modules zoals <a href="http://www.w3.org/TR/css3-flexbox/">flexbox</a> en <a href="http://www.w3.org/TR/css3-exclusions/">exclusions</a>. In de workshop zullen waarschijnlijk zo'n 12-14 modules aan bod komen.</p>
<p>Deelname aan deze workshop kost zoals gebruikelijk €100 voor leden en €200 voor niet-leden (beide bedragen exclusief btw).</p>
</content>
</entry>
<entry>
<title>Mobilism 2013: Fronteers-kaarten</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/mobilism-2013-fronteers-kaarten"/>
<updated>2012-11-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/mobilism-2013-fronteers-kaarten</id>
<content xml:lang="nl" type="html"><p>Op 16 en 17 mei zal te Amsterdam het <a href="http://mobilism.nl/2013">Mobilism-congres</a> plaatsvinden, voor iedereen die zich met mobiel bezig houdt. De <a href="http://mobilism.nl/2013/programme">sprekerslijst</a> begint bekend te worden, en de kaartverkoop is net gestart.</p>
<p>Zoals altijd hebben we een speciale aanbieding voor Fronteers-leden: early-bird kaartjes voor €450 in plaats van €500. Als je hiervan gebruik wilt maken, vraag dan een kortingscode op bij <a href="mailto:krijn@fronteers.nl">krijn@fronteers.nl</a>. Deze actie loopt tot en met 25 januari 2013.</p>
<p>Hopelijk mogen we enkele Fronteers-leden op het congres begroeten.</p>
</content>
</entry>
<entry>
<title>Kandidaat bestuur Fronteers: Matijs Brinkhuis</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/kandidaat-bestuur-fronteers-matijs-brinkhuis"/>
<updated>2012-11-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/kandidaat-bestuur-fronteers-matijs-brinkhuis</id>
<content xml:lang="nl" type="html"><p>Aanstaande donderdag vindt de <a href="https://www.fronteers.nl/blog/2012/10/kom-naar-de-algemene-ledenvergadering-2012">jaarlijkse ALV</a> van Fronteers plaats. Een van de onderdelen tijdens de ALV is de bestuursverkiezing. Dit jaar zijn er vier kandidaten voor het nieuwe bestuur, twee zittende bestuursleden en twee nieuwe leden. Na <a href="https://www.fronteers.nl/blog/2012/11/kandidaat-bestuur-roy-tomeij">Roy Tomeij</a>, <a href="https://www.fronteers.nl/blog/2012/11/kandidaat-bestuur-fronteers-vasilis-van-gemert">Vasilis van Gemert</a> en <a href="https://www.fronteers.nl/blog/2012/11/kandidaat-bestuur-fronteers-arjan-eising">Arjan Eising</a> is het vandaag de beurt aan:</p>
<h2>Matijs Brinkhuis</h2>
<p>Hallo, ik ben Matijs, freelance front-end developer, 38 Lentes <strong>kuch</strong> jong en sinds begin augustus van dit jaar woonachtig in het bruisende en altijd zonnige Brighton in Engeland. Na drie jaar actief te zijn geweest als algemeen bestuurslid vind ik het tijd voor een wat actievere rol, maar hiervoor moet ik wel eerst herkozen worden. Vandaar deze (hopelijk korte) introductiepost voor de mensen die me nog niet kennen.</p>
<p>Naast mijn rol in het bestuur van Fronteers ben ik voorzitter van de recentelijk van naam veranderde Commissie Workshops. Aangezien het eindelijk lukt om de taken rond het organiseren van een workshop binnen de commissie te delegeren heb ik aangeboden voor het komend jaar het penningmeesterschap van Fronteers over te nemen van Krijn. Dit gaf nieuwe betekenis aan de uitdrukking “als een kind zo blij” geloof ik…</p>
<p>Begin augustus ben ik zoals gezegd voor onbepaalde tijd verhuisd naar Brighton in Engeland. Met de technologiën die ons vandaag de dag ter beschikking staan, (het internet in het bijzonder, misschien kent u het) denk ik dat het geen probleem zal zijn om het penningmeesterschap vanuit Engeland te bestieren.</p>
<p>Naast het Fronteers penningmeesterschap blijf ik voorzitter van de Commissie Workshops en zal die commissie ook binnen het bestuur blijven vertegenwoordigen.</p>
<p>Verder ben ik het met Roy eens dat sommige dingen binnen Fronteers, zeker nu we over de <a href="https://www.fronteers.nl/blog/2012/11/500-leden">500 leden</a> zitten, efficiënter zouden kunnen. In de rol van penningmeester zou ik me daar sterk voor willen maken.</p>
<p>Tot slot ben ik begin deze week aangehaakt bij de <a href="https://www.fronteers.nl/vereniging/commissies/congres">congres commissie</a> om hier naast mijn commissietaken ook het bestuur te vertegenwoordigen.</p>
</content>
</entry>
<entry>
<title>De financiën en reserves van Fronteers</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/financien-en-reserves-van-fronteers"/>
<updated>2012-11-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/financien-en-reserves-van-fronteers</id>
<content xml:lang="nl" type="html"><p><a href="https://www.fronteers.nl/vereniging/bestuur/notulen/07-12-11">Vorig jaar tijdens de ALV</a> merkte de ALV op dat het bestuur geen duidelijke en eenduidige visie op de financiën van de vereniging had, en dan specifiek op het gebied van de aan te houden reserve. We hebben toen de opdracht gekregen deze visie te ontwikkelen. Ter voorbereiding op de ALV van volgende week willen we in deze blogpost graag meer duidelijkheid verschaffen over de financiële situatie van de vereniging, en hoe het bestuur nu over dit onderwerp denkt.</p>
<p>De vereniging heeft veel inkomsten. De grootste activiteit van de vereniging (het congres) wordt scherp gebudgetteerd (mogelijk gemaakt door een buffer aan overgedragen winst van vorige jaren), maar maakt toch ieder jaar winst (een klein percentage, maar een fors bedrag in absolute getallen). De een-na-grootste activiteit (cursussen) leidt licht verlies doordat voornamelijk leden deelnemen (voor wie de kosten deels gesponsord worden), maar blijft binnen budget. Verder maakt de vereniging kosten waar niet direct inkomsten tegenover staan (website, commissies, administratie, bijeenkomsten, sponsoring). Deze kosten zijn echter een relatief klein percentage van de inkomsten van de vereniging waar niet direct kosten tegenover staan (lidmaatschapsgeld, vacaturebank). Dit betekent dat de vereniging elk jaar winst maakt. (Over 2011: €8.500 euro voor het congres, en €8.900 voor de rest van de vereniging. Over 2012 verwachten we vergelijkbare getallen.)</p>
<p>Aan de kant van de inkomsten heeft de ALV meerdere keren een signaal afgegeven dat de hoogte van het lidmaatschapsgeld niet naar beneden aangepast dient te worden, aangezien het blijk geeft van enige &quot;commitment&quot; van de leden, en een drempel creëert die aangeeft dat een lid professioneel bezig is met front-end ontwikkeling. (We willen graag op de komende ALV controleren of dit nog steeds de houding van de ALV is, maar verwachten van wel.) Dit doel zou theoretisch op andere manieren kunnen worden afgevangen, maar het bestuur is hier op dit moment geen voorstander van, voornamelijk wegens de hieraan gekoppelde administratieve lasten, en de inflexibiliteit van dergelijke regels. Het bestuur is ook geen voorstander van lagere kosten voor de vacaturebank, wederom omdat deze kosten een drempel opwerpen voor bedrijven (alleen serieuze vacatures), waarmee de kwaliteit van de vacatures hoog blijft, en de administratieve lasten beperkt blijven.</p>
<p>Aan de kant van de kosten hebben we nieuwe activiteiten ontplooid (o.a. een hackday, sponsoring van leden om andere congressen bij te wonen, en binnenkort een buitenlandse spreker die voor een cursus wordt ingevlogen), welke een gematigd succes lijken te zijn, maar deze extra kosten blijven nauwelijks de extra inkomsten door aanwas van leden voor. Het bestuur zal expliciet nieuwe initiatieven van leden financieel blijven ondersteunen, en de leden blijven aanmoedigen om met dergelijke nieuwe initiatieven te komen. We hebben als bestuur een nieuwe richting ingeslagen waarbij we zelf minder operationeel bezig zijn, en meer van onze energie stoppen in het ondersteunen van een steeds grotere groep actieve vrijwilligers. We hopen hiermee deze vrijwilligers te kunnen helpen om meer activiteiten te ontplooien. Desondanks verwachten we niet op korte termijn te zien dat onze kosten sterker zullen stijgen dan onze inkomsten. (Wel zien we dat de &quot;winst&quot; per lid, zowel inclusief als exclusief congreswinst, de afgelopen jaren sterk is gedaald, en over 2011 op ~€22 per lid lag. (Excl. congreswinst.))</p>
<p>Op dit moment stoppen we de volledige &quot;winst&quot; die we elk jaar maken in de algemene reserve. Aan het begin van het jaar was deze reserve uitgegroeid tot €75.000, waarvan €20.000-€25.000 buffer is voor het congres. (Dit willen we op de balans in een aparte post gaan opnemen.) Vraag hierbij is hoe groot deze reserve &quot;zou moeten zijn&quot;, voordat deze kan worden beschouwd als onrealistisch groot en de vereniging moet besluiten wat dan te doen met verdere inkomsten.</p>
<p>Om deze vraag te beantwoorden moet gekeken worden naar het doel van de reserve. Dit is in onze optiek tweeledig: 1) Het garanderen van de continuïteit van de vereniging door ons de mogelijkheid te geven onverwachte tegenvallers op te vangen, en 2) De vereniging de mogelijkheid te geven in te springen op onverwachte maar voor de doelstellingen van de vereniging zeer belangrijke gebeurtenissen. Waarschijnlijk verdienen deze twee doelen ieder een eigen reserve, zodat het dienen van het ene doel het andere niet in gevaar brengt.</p>
<p>Ten opzichte van 1) zijn er geen direct te vinden standaarden voor de aan te houden hoogte van de reserve waarmee continuïteit kan worden gegarandeerd. Zoekacties naar jaarrekeningen van verenigingen en andere documentatie hierover laten zien dat verenigingen die een continuïteitsreserve aanhouden, trachten deze een grootte te geven die valt tussen de 3 en 24 maanden aan uitgaven.</p>
<p>In het bestuur heeft enige discussie plaatsgevonden over hoe &quot;arbitrair&quot; deze grootte is, en dat de grootte van deze reserve door het ontplooien van meer activiteiten (dan wel door het afsluiten van lopende activiteiten) aan sterke fluctuaties onderhevig zou kunnen zijn. Desondanks moet worden vastgesteld dat de reserve enige relatie dient te hebben ten opzichte van de grootte van de vereniging en de door haar ontplooide activiteiten. (€10,000 is een grote reserve voor een vereniging met 10 leden, maar klein voor een vereniging met 1000 leden.) Het risico dat de vereniging loopt op onverwachte tegenvallers lijkt ook groter te zijn naarmate het aantal lopende activiteiten toeneemt. Aangezien de onbekendheid van de tegenvallers die we willen kunnen opvangen het onmogelijk maakt deze in te calculeren, lijken we geen ander houvast te hebben om de grootte van de reserve aan vast te knopen dan aan de cashflow.</p>
<p>Waar we - door hier over na te denken - onbekendheden als kleine risico's voorzien (bijvoorbeeld aansprakelijkheid bij een ongeluk tijdens het congres of een bijeenkomst), doen we er goed aan ons hier expliciet tegen in te dekken (d.w.z. laten we uitzoeken of er verzekeringen tegen dergelijke risico's kunnen worden afgesloten), maar er zullen altijd verdere onbekende risico's blijven bestaan.</p>
<p>Ten opzichte van 2) kunnen we ons voorstellen dat de vereniging de komende jaren uitdagingen op hoger niveau kan verwachten. Wederom is deze investeringsreserve bedoeld voor <em>onverwachte</em> gebeurtenissen, maar we denken hier in de trant van inspringen op politieke veranderingen m.b.t. de status van de webrichtlijnen. Of stel dat we internationaal gaan, en de vraag krijgen om de opstart van meerdere Fronteers verenigingen in het buitenland financieel te ondersteunen (net zoals het PIBN ons bij onze oprichting heeft ondersteund). Idealiter zouden we dergelijke gebeurtenissen al hebben zien aankomen en zouden we er in onze begroting al expliciet op zijn voorbereid, maar het is goed om de slagkracht te hebben op dergelijke gebeurtenissen in te kunnen spelen zonder daarmee de vereniging financieel in gevaar te brengen.</p>
<p>Gegeven deze overwegingen willen we op de ALV een drietal moties indienen:</p>
<ol>
<li>De vereniging bouwt een continuïteitsreserve op, waarvan we de grootte vaststellen op 50% van de gemiddelde cashflow over de vorige twee jaar. (D.w.z. dat we onmiddellijk stoppen met mogelijke onverwachte uitgaven als die er ooit voor lijken te zorgen dat de reserve kleiner wordt dan a) dit minimum bedrag, of b) de grootte van de continuïteitsreserve aan het begin van het boekjaar (voor de jaren waarin dit lager ligt dan dit minimum). Onder deze grens geld uitgeven zou alleen mogelijk moeten zijn als het voortbestaan van de vereniging op het spel staat.)</li>
<li>De vereniging bouwt, nadat de continuïteitsreserve de gewenste grootte heeft bereikt, ook een investeringsreserve op, waarvan we de uiteindelijke gewenste grootte vaststellen op 75% van de cashflow over het gemiddelde van de vorige twee jaar. (D.w.z. dat we winst over jaren in de reserve blijven pompen totdat we deze grens hebben bereikt.)</li>
<li>Het bestuur van de vereniging zal geen acties ondernemen ten aanzien van het uitvoeren van activiteiten met als <em>doel</em> de hoogte van de cashflow (en dus van de reserves) te beïnvloeden. (D.w.z. dat we gewoon nieuwe activiteiten blijven ontplooien, en dat activiteiten soms afgesloten zullen worden, maar dat dit op zichzelf staande acties zullen zijn, waarbij geen rekening gehouden zal worden met het effect dat dit zal hebben op de cashflow en de reserves.)</li>
</ol>
<p>We verwachten de continuïteitsreserve aan het eind van 2013 op het gewenste niveau te hebben, en rond 2020 de investeringsreserve op het uiteindelijke gewenste niveau te hebben, hoewel we volledig onderkennen dat de onzekerheid bij een verwachting op een dergelijke termijn erg groot is. We hebben nog geen visie over wat de vereniging zou moeten doen met verdere winsten na het bereiken van dat punt.</p>
<p>We gaan op de ALV graag dieper in op dit onderwerp, maar hopen jullie met deze blogpost al de gelegenheid te geven van te voren een mening over deze voorstellen te vormen.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 22 november bij Mobile Vikings</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/bijeenkomst-mobile-vikings"/>
<updated>2012-11-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/bijeenkomst-mobile-vikings</id>
<content xml:lang="nl" type="html"><p>Op donderdag 22 november 2012 is Fronteers te gast bij Mobile Vikings in Hasselt. Er worden twee presentaties voorzien. Eerst komt Nick Looijmans praten over UX op mobiele apparaten; vervolgens zullen Tom Claus en Kristof Houben wat vertellen over <em>responsive content</em>.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met een drankje</li>
<li>19:00 Nick Looijmans over <em>naadloze user experiences op mobile devices</em></li>
<li>20:00 Tom Claus en Kristof Houben over <em>responsive content</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Mobile Vikings te Hasselt. <a href="https://www.fronteers.nl/bijeenkomsten/2012/mobile-vikings">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 45 mannen en vrouwen. Geef je daarom op via het <a href="https://www.fronteers.nl/bijeenkomsten/2012/mobile-vikings#aanmeldingen">aanmeldformulier</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>25 euro korting voor Startup Weekend Utrecht</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/25-euro-korting-voor-startup-weekend-utrecht"/>
<updated>2012-11-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/25-euro-korting-voor-startup-weekend-utrecht</id>
<content xml:lang="nl" type="html"><p>Op 16 t/m 18 november vindt het <a href="http://www.startupweekendutrecht.nl/">Utrecht Startup Weekend</a> plaats waar ontwerpers, developers en ondernemers samen een nieuw duurzaam product ontwikkelen.</p>
<p>Startup Weekend Utrecht vindt plaats in de Hogeschool van Utrecht. Voor eten, drinken en snacks wordt gezorgd. Daarnaast staat er een team van mentoren voor je klaar en kun je diverse workshops volgen.</p>
<p>Heb je een tof idee, wil je mee helpen ontwikkelen of ontwerpen? Samen vorm je een team en ontwikkel je in 54 uur je eigen startup.</p>
<p>Als Fronteerslid krijg je 25 euro korting op de ticketprijs van 75 euro.
Om gebruik te maken van de korting, kun je <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact opnemen met de ledenadministratie</a>. De korting geldt, zoals gebruikelijk, alleen voor leden die bij aankondiging van deze actie al lid waren.</p>
</content>
</entry>
<entry>
<title>Kandidaat bestuur Fronteers: Arjan Eising</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/kandidaat-bestuur-fronteers-arjan-eising"/>
<updated>2012-11-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/kandidaat-bestuur-fronteers-arjan-eising</id>
<content xml:lang="nl" type="html"><p>Volgende week donderdag vindt de <a href="https://www.fronteers.nl/blog/2012/10/kom-naar-de-algemene-ledenvergadering-2012">jaarlijkse ALV</a> van Fronteers plaats. Een van de onderdelen tijdens de ALV is de bestuursverkiezing. Dit jaar zijn er vier kandidaten voor het nieuwe bestuur, twee zittende bestuursleden en twee nieuwe leden. In de komende dagen stellen zij zich alle vier aan je voor. Vandaag:</p>
<h2>Arjan Eising</h2>
<p>De meeste mensen zullen mij kennen als die rare meneer die de bijeenkomsten inleidt. Mijn naam is Arjan Eising, reeds vijf jaar bestuurslid van Fronteers. Ik treed af, maar ben ook verkiesbaar om opnieuw in het bestuur zetel te nemen.</p>
<p>Enkele punten zijn reeds genoemd om het bestuur (en dus de vereniging) te verbeteren. Denk aan de contacten met het onderwijs en andere vakgebieden verbeteren. Mijn puntjes om daar aan toe te voegen zijn het meer waarde geven aan het lidmaatschap. Denk aan:</p>
<ul>
<li>hoge kwaliteit workshops organiseren, eventueel met internationale workshopleiders;</li>
<li>leuke, nieuwe activiteiten gericht op leden, die je verder laten kijken dan de websites waar je normaal doordeweeks aan werkt;</li>
<li>toffe, bedrukte merchandise en vakgerelateerde boeken die je voor een gereduceerd tarief kunt kopen als je lid bent van Fronteers.</li>
</ul>
<p>… zonder uiteraard de huidige <a href="https://www.fronteers.nl/vereniging/lidmaatschap">voordelen voor het lidmaatschap</a> uit het oog te verliezen.</p>
<p>De doelstelling van de vereniging is &quot;de professionalisering van het beroep front-end web development. Daarbij streven wij naar erkenning, verbetering en ondersteuning van de (positie van) Nederlandstalige front-end webontwikkelaars.&quot; Het huidige bestuur, waaronder ikzelf, heeft op veel vlakken bijgedragen hieraan. Denk aan: het congres, de reeds gegeven workshops en de onderwijscommissie.</p>
<p>Echter, er is nog veel te doen. Ik denk dat Fronteers een actieve rol kan spelen in de communicatie over webrichtlijnen naar niet-front-end developers toe. Daarnaast moet het de banden met verenigingen voor gerelateerde vakgebieden sterk verbeteren. Ook is het voorlichten en inspireren van opdrachtgevers, werkgevers en potentiëel toekomstige front-end developers—over de toenemende leukheid en belangrijkheid van ons beroep—iets wat nu nog ondergesneeuwd is.</p>
<p>Initiatief nemen is daarbij sleutel. De afgelopen jaren heb ik me actief ingezet om nieuwe activiteiten en commissies te ontplooien, denk aan de recentere LustrumCie en de AciviteitenCie. De trend wil ik zeker voortzetten, samen met de rest van het bestuur en de vrijwilligers. De ontplooiing van de Belgische tak van de vereniging is ook iets wat op mijn agenda staat, en waar ik een adviserende rol in kan nemen. Dit onder andere vanwege de opgedane ervaring bij de oprichting van de Nederlandse vereniging. Daarnaast zou ik, als de positie vrijkomt, de rol van secretaris op me willen nemen; een onmisbare rol in een bestuur.</p>
<p>Ik hoop op je stem te mogen rekenen volgende week donderdag, 22 november. Laten we van Fronteers een nog mooiere, interessantere, leuke, inspirerende vereniging maken! Mocht je verhinderd zijn, dan kun je een stem laten uitbrengen door een bevriend Fronteerslid dat wel aanwezig zal zijn.</p>
</content>
</entry>
<entry>
<title>Kandidaat bestuur Fronteers: Vasilis van Gemert</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/kandidaat-bestuur-fronteers-vasilis-van-gemert"/>
<updated>2012-11-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/kandidaat-bestuur-fronteers-vasilis-van-gemert</id>
<content xml:lang="nl" type="html"><p>Over anderhalve week vindt de <a href="https://www.fronteers.nl/blog/2012/10/kom-naar-de-algemene-ledenvergadering-2012">jaarlijkse ALV</a> van Fronteers plaats. Een van de onderdelen tijdens de ALV is de bestuursverkiezing. Dit jaar zijn er vier kandidaten voor het nieuwe bestuur, twee zittende bestuursleden en twee nieuwe leden. In de komende dagen stellen zij zich alle vier aan je voor. Na <a href="https://www.fronteers.nl/blog/2012/11/kandidaat-bestuur-roy-tomeij">Roy Tomeij</a> is het nu de beurt aan:</p>
<h2>Vasilis van Gemert</h2>
<h2>Belangrijk: onderwijs en samenwerking</h2>
<p>Als bestuurslid van Fronteers ga ik me hard maken voor twee dingen: onderwijs en samenwerking. Ik ga me met de hulp van goede docenten inzetten voor een verbetering van het (hoger) beroepsonderwijs in Nederland. Naast goede afgestudeerde frontenders wil ik over een paar jaar afgestudeerde designers met relevante kennis van het web kunnen aannemen.</p>
<p>Naar mijn mening is Fronteers nogal in zichzelf gekeerd. Ik ga er voor zorgen dat we intensiever gaan samenwerken met andere beroepsorganisaties. Aan de ene kant omdat het goed is om te leren van andere professionals, om eens te zien hoe zij dingen doen. Aan de andere kant ben ik er van overtuigd dat veel vakgebieden enorm veel profijt kunnen hebben van de unieke kennis die wij bezitten. Ik heb inmiddels gezien dat een samenwerking tussen briljante techneuten en topdesigners kan zorgen voor prachtige nieuwe inzichten. Ik wil meer van die toffe shit.</p>
<p>Ik ga dit allemaal natuurlijk niet zelf doen. Daar ben ik veel te lui voor. Bovendien moeten bestuursleden meer gaan delegeren. Dus, als je mee wilt denken over het beroepsonderwijs in Nederland, of als je fantastische ideeën hebt over goede manieren van samenwerken, stem dan op 22 november (ook) op mij.</p>
<h2>Trivia</h2>
<p>Naast deze écht belangrijke zaken lijkt het me ook wel goed als er iemand in het bestuur zit die bij een groot bureau werkt. Het bestuur zou een afspiegeling moeten zijn van de beroepsgroep, lijkt me. Volgend jaar dus graag wat vrouwen er bij en mensen die aan één enkel product werken.</p>
<p>Mijn naam is overigens Vasilis van Gemert, en ik ben principal frontend developer bij Mirabeau, waar ik werk voor klanten als ING en KLM (onder veel meer). Sinds de oprichting van Fronteers ben ik betrokken bij de organisatie waar ik me onder andere een paar jaar bemoeid heb met het congres. Ik schrijf met enige regelmaat voor verschillende (web)magazines, ik ben gastdocent aan de HvA en ik geef graag mijn mening.</p>
</content>
</entry>
<entry>
<title>Kandidaat bestuur Fronteers: Roy Tomeij</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/kandidaat-bestuur-roy-tomeij"/>
<updated>2012-11-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/kandidaat-bestuur-roy-tomeij</id>
<content xml:lang="nl" type="html"><p>Over twee weken vindt de <a href="https://www.fronteers.nl/blog/2012/10/kom-naar-de-algemene-ledenvergadering-2012">jaarlijkse ALV</a> van Fronteers plaats. Een van de onderdelen tijdens de ALV is de bestuursverkiezing. Dit jaar zijn er vier kandidaten voor het nieuwe bestuur, twee zittende bestuursleden en twee nieuwe leden. In de komende dagen stellen zij zich alle vier aan je voor. Vandaag:</p>
<h2>Roy Tomeij</h2>
<p>Beste Fronteers-leden, voordat jullie in groten getale gaan stemmen tijdens de ALV op 22 november stel ik me graag aan jullie voor. Het is immers wel zo handig om te weten op wie je nou eigenlijk kunt stemmen.</p>
<p>Alleerst wat steekwoorden: 1980, echtgenoot, 80beans, cola, pragmatisch, <a href="https://twitter.com/roy">twitteraar</a>, front-ender, <a href="http://thesassway.com/roy-tomeij">Sass-groupie</a>, azijnpisser, <a href="http://roytomeij.com/">blogger</a>, <a href="http://modular-frontend.com/">auteur</a>, <a href="https://www.fronteers.nl/workshops/screw-css-roy-tomeij">trainer</a>, chocoladepepernoten, <a href="http://lanyrd.com/profile/roy/">spreker</a>, <a href="http://amsrb.org/">organisator</a>. Details op verzoek.</p>
<p>Op 2 juli 2007 werd ik lid van de Yahoo! Group &quot;Gilde voor Front-enders&quot;, waarna ik sinds begin 2008 meermaals actief ben geweest voor de vereniging en onregelmatig aan het bestuur kritiek heb geuit. Na bijna vijf jaar als beste schipper aan wal te hebben gestaan is de tijd gekomen om zelf een actieve sturende rol op me te nemen.</p>
<h2>Wat wil ik doen dan?</h2>
<p>Ik heb over alles een mening, maar deze kernpunten zou ik graag actief ter tafel brengen in het bestuur:</p>
<ul>
<li>Onderwijzen van best practices aan andere disciplines. Niet enkel preken voor de eigen achterban, maar ook voorzien in de behoeften van designers, back-enders, etc.</li>
<li>Betere aansluiting zoeken bij het beroepsonderwijs en een actieve rol vervullen in de totstandkoming en uitvoering van curricula.</li>
<li>Fronteers is geen bedrijf, maar sommige processen zou ik graag efficiënter inrichten.</li>
<li>Bestuur laten besturen. Het bestuur is te veel uitvoerend bezig en moet meer delegeren naar de commissies.</li>
</ul>
<h2>Waarom ik?</h2>
<p>Het bestuur bestaat nu volledig uit freelancers. Het zou de vereniging ten goede komen om een breder palet aan bestuurders te hebben, waar ik met mijn &quot;klein bureau&quot;-achtergrond voor kan zorgen. Ik ben gewend om te delegeren en processen te optimaliseren. Doordat het besturen van Fronteers deel uit zou maken van mijn werk kan ik structureel tijd inplannen om me hiervoor in te zetten.</p>
<p><em>TL;DR; Stem op mij tijdens de ALV en ik zal voor meer gratis bier en bitterballen voor Fronteers-leden lobbyen!</em></p>
</content>
</entry>
<entry>
<title>Commissie Workshops</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/commissie-workshops"/>
<updated>2012-11-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/commissie-workshops</id>
<content xml:lang="nl" type="html"><p>De Commissie Cursussen heeft haar naam veranderd in Commissie Workshops en kondigt nieuwe <strike>cursussen</strike> <strong>workshops</strong> aan.</p>
<p>De Commissie Cursussen heeft besloten om haar naam te veranderen. Van Dale definieert een cursus als volgt:</p>
<pre><code>cur·sus de;
m -sen 1 reeks van lessen 2 schooljaar
</code></pre>
<p>Aangezien al onze ‘cursussen’ slechts een dag duren en al helemaal geen schooljaar zijn, dekte ‘cursussen’ de lading niet al te best.</p>
<pre><code>work·shop [wu:rksjop] de;
m -s het praktisch, creatief werken in groepjes)
</code></pre>
<p>…daarentegen, dekt de lading een stuk beter. Vandaar dus deze naamswijziging en de nodige url-wijzigingen op de site. Niet in de laatste plaats te danken aan een puik stukje internationaal scrummen.</p>
<h2>Planning</h2>
<p>Voor eind november staat jQuery Inception, een workshop voor beginnende jQuery coders, op het programma. Omdat deze workshop in een mum van tijd vol zat en we van een aantal mensen de vraag hebben gehad of ze niet alsnog mee konden doen, hebben we geprobeerd de <strike>cursus</strike> <strong>workshop</strong> snel nog een keer in te plannen. Dat is gelukt en je kunt je nu <a href="https://www.fronteers.nl/workshops/jquery-inception-arjan-eising/7-december-2012">inschrijven</a> voor <a href="https://www.fronteers.nl/workshops/jquery-inception-arjan-eising">jQuery Inception</a> op 7 december.</p>
<p>Roy Tomeij trapt het nieuwe jaar af op 18 januari met de workshop <a href="https://www.fronteers.nl/workshops/screw-css-roy-tomeij">Screw CSS!</a> Ook deze workshop zat snel vol maar we hebben Roy gevraagd of hij tijd heeft hem later in het jaar nog een keer te geven. Dat wil hij, maar er is nog geen nieuwe datum geprikt.</p>
<p>Tot slot hebben we voor eind januari een internationale trainer bereid gevonden een workshop te verzorgen. Zodra de planning hiervan definitief is, wordt deze workshop aangekondigd.</p>
</content>
</entry>
<entry>
<title>500 leden!</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/500-leden"/>
<updated>2012-11-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/500-leden</id>
<content xml:lang="nl" type="html"><p>Aangezien we <a href="http://twitter.com/fronteers/status/264674691598389248">afgelopen weekend</a> de <a href="https://www.fronteers.nl/leden">500 leden</a> hebben bereikt, wordt het weer tijd voor een <strike>feestje</strike> <strong>spontaanborrel</strong>.</p>
<p>Tot volgende week, maandag 12 november, vanaf een uurtje of 18, bij <a href="http://maps.google.nl/maps?f=q&amp;source=s_q&amp;hl=nl&amp;geocode=&amp;q=winkel+van+sinkel+utrecht&amp;sll=52.469397,5.509644&amp;sspn=3.654648,9.766846&amp;ie=UTF8&amp;hq=Winkel+van+Sinkel&amp;hnear=Winkel+van+Sinkel,+3512+Utrecht&amp;ll=52.095486,5.118599&amp;spn=0.027472,0.076303&amp;z=14&amp;iwloc=A">De Winkel van Sinkel</a> in Utrecht!</p>
<p>Hieronder wat getalletjes, voor de gekte.</p>
<p>Vaakst voorkomende namen van leden
Martijn 12 keer
Peter 10 keer
Jeroen 9 keer
Wouter 8 keer
Sander 6 keer
Paul 6 keer
Johan 6 keer
Tom 6 keer)</p>
<p>Steden met de meeste leden
Amsterdam 67 leden
Utrecht 41 leden
Rotterdam 29 leden
Den Haag 20 leden
Groningen 11 leden
Delft 11 leden
Den Bosch 10 leden)</p>
<p>Bedrijven met de meeste leden
Mirabeau|11 leden
eFocus|6 leden
Stichting Accessibility|5 leden
Ordina|5 leden)</p>
<p>Ledengroei door de jaren heen
2008 147 leden +147 (ja, echt!)
2009 222 leden +75
2010 327 leden +105
2011 431 leden +104
2012 510 leden +79 (and counting!))</p>
<p>Willekeurige getallen
Sinds 2008 onverstoord lid|96 leden
Vaakst voorkomende naam van leden die al sinds 2008 lid zijn|Jeroen
Minimaal één halfjaar lid geweest|734 personen
Studentenleden|11 leden
Plaatsen waar we leden hebben|190 plaatsen
Landen waar we leden hebben|5 landen
Sinds het begin van Fronteers langsgekomen bij de ledenadministratie|810 namen
Geïnteresseerd in dit soort getallen|6 personen)</p>
</content>
</entry>
<entry>
<title>Activiteitencommisie in het leven geroepen</title>
<link href="https://www.fronteers.nl/nl/blog/2012/11/activiteitencommisie"/>
<updated>2012-11-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/11/activiteitencommisie</id>
<content xml:lang="nl" type="html"><p>Tijdens de laatste bestuursvergadering is er een nieuwe commissie in het leven geroepen: een activiteitencommissie. Doel van de commissie is om het organiseren van bijeenkomsten en kleinschalige evenementen zoals een barcamp, jamsessies of hackathons centraal te houden. De commissie is op zoek naar leden.</p>
<p>Voornaamste taken die maandelijks, of zelfs vaker, gedaan moeten worden, zijn:</p>
<ul>
<li>Contactpersoon zijn van sprekers en mensen die bij de gastbedrijven werken zodat een bijeenkomst tot stand kan komen;</li>
<li>Het schrijven van aankondigings-blogposts en bijwerken van detailpagina's van de bijeenkomsten en activiteiten;</li>
<li>Aankondigen van die activiteiten via <a href="https://twitter.com/fronteers">Twitter</a>, <a href="http://www.facebook.com/fronteers">Facebook</a> en <a href="http://lanyrd.com/profile/fronteers/">Lanyrd</a>;</li>
<li>Opnemen van de presentaties met een te kopen camera;</li>
<li>Bewerken van de beelden opgenomen met die camera en ze op de site en het <a href="http://www.vimeo.com/fronteers">Fronteers Vimeo account</a> te plaatsen;</li>
<li>Het kopen van flesjes wijn voor de sprekers en het gastbedrijf;</li>
<li>Op de bijeenkomsten optreden als host.</li>
</ul>
<p>Daarnaast is er genoeg ruimte om op de mailinglijst ideeën voor sprekers, typen bijeenkomsten en activiteiten en andere toffe dingen te bediscussiëren. Dus heb je zin om een van de bovenstaande taken op te pakken, schroom dan niet een (korte) introductie en motivatie te sturen via <a href="https://www.fronteers.nl/nl/vereniging/contact/">het contactformulier</a>.</p>
</content>
</entry>
<entry>
<title>Kom naar de Algemene Ledenvergadering</title>
<link href="https://www.fronteers.nl/nl/blog/2012/10/kom-naar-de-algemene-ledenvergadering-2012"/>
<updated>2012-10-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/10/kom-naar-de-algemene-ledenvergadering-2012</id>
<content xml:lang="nl" type="html"><p>Donderdag 22 november a.s. vindt de jaarlijkse Algemene Ledenvergadering (ALV) van Fronteers plaats. We willen zoveel mogelijk betrokken leden oproepen naar deze ledenvergadering te komen. Dit jaar zal de ALV gehouden worden op Utrecht CS.</p>
<p>Enkele belangrijke punten die we op deze ALV willen bespreken zijn:</p>
<ul>
<li>Toelichting op het reilen en zeilen van de actieve commissies</li>
<li>Opheffen commissie Diplomering</li>
<li>Bespreken van voorstellen over de financiële reserve van Fronteers</li>
<li>Bestuursverkiezing en vertrek Peter-Paul Koch (PPK)</li>
</ul>
<h2>Agenda</h2>
<h2>1. Welkom en opening door de voorzitter</h2>
<h2>2. Toelichting commissies</h2>
<ul>
<li>Onderwijs</li>
<li>Online Community</li>
<li>Congres</li>
<li>Marketing</li>
<li>Cursussen</li>
<li>Webrichtlijnen</li>
<li>Activiteiten</li>
<li>Oprichting commissie België</li>
</ul>
<h2>3. Ingebrachte beleidsvoorstellen</h2>
<ul>
<li>Opheffen commissie Diplomering (zie <a href="https://www.fronteers.nl/blog/2012/10/opheffing-commissie-diplomering">blogpost</a>)</li>
<li>De financiële reserve van Fronteers (hierover verschijnt binnenkort een toelichtende blogpost op fronteers.nl)</li>
</ul>
<h2>4. Besluiten eerdere ALV’s</h2>
<ul>
<li>Toelichting copyright statement publicaties Fronteers</li>
<li>Vastleggen beeldmerk Fronteers</li>
<li>Evaluatie vacaturebank</li>
<li>Evaluatie korting op buitenlandse congressen</li>
<li>Strikter uitschrijven niet-betalende leden</li>
<li>Automatische incasso</li>
<li>Hoogte contributie</li>
</ul>
<h2>5. Begroting 2011</h2>
<h2>6. Begroting 2012</h2>
<h2>7. Kascommissieverkiezing</h2>
<h2>8. Bestuursverkiezing</h2>
<p>Peter-Paul Koch, Arjan Eising en Matijs Brinkhuis treden af. Arjan en Matijs zijn herkiesbaar. Tevens hebben zich twee nieuwe kandidaatbestuursleden aangemeld: Roy Tomeij en Vasilis van Gemert.</p>
<h2>9. Afscheid PPK</h2>
<h2>10. Rondvraag</h2>
<h2>11. Afsluiting</h2>
<p><em>De ALV vindt op donderdag 22 november om 19.00 uur plaats in <a href="http://www.hoogbrabant.nl/Routebeschrijving/">vergadercentrum Hoog Brabant</a> bij Utrecht CS.</em></p>
</content>
</entry>
<entry>
<title>Bijeenkomsten op 27 en 29 november</title>
<link href="https://www.fronteers.nl/nl/blog/2012/10/bijeenkomsten-eind-november"/>
<updated>2012-10-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/10/bijeenkomsten-eind-november</id>
<content xml:lang="nl" type="html"><p>Eind november hebben we twee bijeenkomsten ingepland. Te weten bij <a href="http://incentro.com/">Incentro</a> te Amsterdam op dinsdag de 27ste, en twee dagen later, op de 29ste, bij <a href="http://www.infosupport.com/">Info Support</a> in Veenendaal.</p>
<h2>Incentro – 27 november 2012</h2>
<p>Rob van der Burgt vertelt deze avond hoe je hardware zoals een webcam kunt gebruiken in een webapplicatie. Nikolai Onken duikt in op een door zijn bedrijf ontwikkelde graphics library genaamd BonsaiJS.</p>
<p><a href="https://www.fronteers.nl/bijeenkomsten/2012/incentro">Lees meer over deze bijeenkomst bij Incentro</a></p>
<h2>Info Support – 29 november 2012</h2>
<p>Thamar Kiemel gaat een—bij Fronteers onderbelicht—onderwerp aansnijden: content management en hoe je een contentafdeling goed opzet en begeleidt. Daarna is het woord aan Isaac Andela, die gaat uitleggen hoe je Sass overzichtelijk opzet zodat je makkelijker CSS schrijft.</p>
<p><a href="https://www.fronteers.nl/bijeenkomsten/2012/info-support">Lees meer over deze bijeenkomst bij Info Support</a></p>
<p>Zoals gebruikelijk zijn beide bijeenkomsten gratis toegankelijk voor zowel leden als niet-leden. Wel is gewenst dat je doorgeeft dat je aanwezig zult zijn via de formulieren op de hierboven gelinkte pagina's.</p>
</content>
</entry>
<entry>
<title>Opheffing commissie diplomering</title>
<link href="https://www.fronteers.nl/nl/blog/2012/10/opheffing-commissie-diplomering"/>
<updated>2012-10-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/10/opheffing-commissie-diplomering</id>
<content xml:lang="nl" type="html"><p>Misschien is het droevig maar de commissie Diplomering van Fronteers is niet meer.</p>
<p>Enkele jaren geleden begonnen we met een select groepje enthousiast met het opzetten van diplomering voor front-end developers. In die tijd was het vak als zodanig nog niet zo erkend als tegenwoordig. We hadden het idee om dat met een diplomering te verbeteren.</p>
<h2>Hoe wilden we dat doen?</h2>
<p>Na overleg kwamen we al snel uit op een tweedelig examen. Eerst een theoriegedeelte, met vragen die vanuit de W3C-standaarden getoetst konden worden. Dan zou een praktijkgedeelte volgen, waar men een ontwerp kreeg, wat op een whiteboard uitgewerkt mocht worden. Tijdens deze opdracht zouden de examinatoren vragen stellen over de gemaakte keuzes om achter de motivatie voor een bepaalde richting te komen. Samen zouden deze twee gedeeltes een resultaat van het examen over HTML en CSS opleveren. Dit examen zou iedere twee jaar opnieuw moeten worden afgenomen om te garanderen dat de kennis up-to-date bleef.</p>
<p>Na een voortvarend begin begon de motivatie van de commissie al af te nemen, om na een jaar langzaam geheel te verdwijnen. Uiteindelijk bleef ik alleen over en ook ik had er geen tijd meer voor over.</p>
<h2>Het einde</h2>
<p>Begin dit jaar besloten we om nog een keer te beginnen, met als een van de eerste acties het polsen van de interesse vanuit het veld. Dit gebeurde met een <a href="http://wnas.nl/fronteers-certification">blogpost op wnas.nl</a>. De reacties waren bijna allemaal negatief. Vooral de ervaren front-end ontwikkelaars zagen het niet zitten om getoetst te worden en sommigen waren zelfs bang dat het toetsen zou leiden tot een verkeerd beeld over de kwaliteit van front-end developers. Uit de praktijk van andere talen (Java en .NET bijvoorbeeld) blijkt dat de kwaliteit van de ontwikkelaar niet recht evenredig is aan de hoeveelheid toetsen die gehaald zijn. Integendeel zelfs.</p>
<p>Voor opdrachtgevers heeft het al dan niet hebben van een certificaat van een kandidaat geen meerwaarde. De meest ervaren front-end developers zijn het minst geneigd een certificaat te halen. De meeste opdrachten worden ook verleend aan een bureau, en niet aan een specifieke developer. Met andere woorden, als een gediplomeerde developer het bureau verlaat, dan zal de klant niet om die reden overstappen naar een ander bureau.</p>
<h2>Conclusie</h2>
<p>Doordat er geen behoefte is vanuit de front-end gemeenschap en geen meerwaarde voor opdrachtgevers, stoppen we, en dienen op de komende ALV een motie in om de commissie op te heffen.</p>
<p>Nawoord bestuur: We willen Wilfred en alle leden die zich door de jaren heen voor de commissie hebben ingezet bedanken voor hun inspanningen. Het landschap van front-end ontwikkeling heeft zich de afgelopen 5 jaar sterk verder ontwikkeld, waar het pure bestaan van Fronteers ook aan heeft bijgedragen, en het bestuur onderschrijft de conclusie van de commissie dat diplomering niet langer gewenst is.</p>
</content>
</entry>
<entry>
<title>25% korting op workshop met Stephen Anderson</title>
<link href="https://www.fronteers.nl/nl/blog/2012/10/korting-workshop-stephen-anderson"/>
<updated>2012-10-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/10/korting-workshop-stephen-anderson</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 9 november organiseren Q42 en Fabrique samen met Stephen Anderson <a href="http://qfee.nl/">een workshop over informatie visualisatie</a>.</p>
<p>Het werk van een front-end ontwikkelaar bestaat uit informatie op een scherm visualiseren, dus ook als je voornamelijk de hele dag naar code kijkt is het belangrijk om te begrijpen wat goede technieken voor dergelijke visualisatie zijn en waar je wel en niet naar moet kijken.</p>
<p>Stephen Anderson is een bekende spreker in de design wereld. Hij was twee jaar geleden ook in Nederland, en heeft toen bij Q42 een presentatie gegeven over hoe psychologie web design kan versterken. Uiteindelijk heeft hij daar een boek over geschreven, Seductive Interaction Design.</p>
<p>Nu is hij terug met een nieuwe focus, “<a href="http://qfee.nl/">The Quest for Emotional Engagement</a>”, waarin hij zoekt naar andere manieren om als UI designer mensen voorbij standaardpatronen als lijsten, grids en tables te laten denken.</p>
<p>Q42 en Fabrique sponsoren de workshop, die plaatsvindt in de Westerliefde op het Westergasterrein in Amsterdam. Kom je ook? Leden van Fronteers krijgen 25% korting! Neem even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact op met de ledenadministratie</a> om je kortingscode te ontvangen.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 25 oktober bij Combell</title>
<link href="https://www.fronteers.nl/nl/blog/2012/10/bijeenkomst-combell"/>
<updated>2012-10-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/10/bijeenkomst-combell</id>
<content xml:lang="nl" type="html"><p>Op donderdag 25 oktober 2012 is Fronteers te gast bij <a href="http://www.combell.com/nl">Combell</a> in Gent. Er worden twee presentaties voorzien. Eerst komt <a href="http://twitter.com/qwaxys">Bart Derudder</a> wat vertellen over (het gebrek aan) security op het web; vervolgens zal <a href="http://twitter.com/ThijsFeryn">Thijs Feryn</a> wat vertellen over HTTP.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met een hapje en een drankje</li>
<li>19:00 Bart Derudder: <em>Security – The Weakest Links</em></li>
<li>20:00 Thijs Feryn: <em>There’s this thing called HTTP</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Combell Group NV te Gent. <a href="https://www.fronteers.nl/bijeenkomsten/2012/combell">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 70 mannen en vrouwen. Geef je daarom op via het <a href="https://www.fronteers.nl/bijeenkomsten/2012/combell#aanmeldingen">aanmeldformulier</a>. Vol is vol!</p>
</content>
</entry>
<entry>
<title>Workshops jQuery Inception en Screw CSS! op herhaling</title>
<link href="https://www.fronteers.nl/nl/blog/2012/10/workshops-update-oktober"/>
<updated>2012-10-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/10/workshops-update-oktober</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 30 november wordt een vernieuwde <a href="https://www.fronteers.nl/workshops/jquery-inception-arjan-eising">workshop jQuery Inception</a> gegeven. Enkele weken later, op 18 januari zal Roy Tomeij zijn <a href="https://www.fronteers.nl/workshops/screw-css-roy-tomeij">workshop Screw CSS!</a> opnieuw geven.</p>
<p>Tijdens de beginnerscursus jQuery Inception leer je de basis van programmeren in JavaScript, interacties met de bezoeker van een webpagina, en hoe je HTML en CSS manipuleert met jQuery. Het concept en het niveau van de cursus is iets toegankelijker voor niet-programmeurs dan voorheen.</p>
<p>Screw CSS leert je alles over het installeren en gebruiken van een CSS preprocessor. Je ontdekt alle geheimen van Sass, Compass en LESS om optimaal gebruik te maken van deze tools. Eer je ze aangeleerd hebt, schrijf je veel sneller CSS-code.</p>
<p>Beide cursussen worden gegeven bij Seats2meet, en kosten 200 euro per cursus voor niet-leden. De prijs voor leden is de helft: 100 euro. Beide bedragen zijn exclusief 21% btw. Een cursus duurt de hele dag, en koffie, thee en lunch zijn inbegrepen.</p>
<p>Er zijn momenteel voorbereidingen voor enkele van de andere cursussen. Heb je interesse in een cursus die een vorige keer vol zat, of heb je ideeën voor een nieuwe cursus, laat dan een reactie achter hieronder of via <a href="https://www.fronteers.nl/nl/vereniging/contact/">het formulier</a>.</p>
</content>
</entry>
<entry>
<title>Inschrijven voor bijeenkomst op 1 november bij Netvlies</title>
<link href="https://www.fronteers.nl/nl/blog/2012/10/inschrijven-bijeenkomst-november"/>
<updated>2012-10-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/10/inschrijven-bijeenkomst-november</id>
<content xml:lang="nl" type="html"><p>Op donderdag 1 november is Fronteers te gast bij Netvlies Internetdiensten in Breda. Dit keer is het geen bijeenkomst met 2 presentaties, maar een Pecha Kucha met 10 presentaties. De inschrijvingen hiervoor zijn vanaf vandaag geopend.</p>
<p>Op donderdag 1 november is Fronteers te gast bij Netvlies Internetdiensten in Breda. Dit keer is het geen bijeenkomst met 2 presentaties, maar een Pecha Kucha met 10 presentaties van 6 minuut 40.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 Inloop</li>
<li>19.30 Jayne Verbeek - Intro + All your phones are belong to me</li>
<li>19.40 Krijn Hoetmer - Pedantic Indenting</li>
<li>19.50 Jules Ernst - Webrichtlijnen en het toepassen van afkortingen</li>
<li>20.00 Peter van der Zee - When Worlds Collide</li>
<li>20.10 Jaco Koster - Building Big Sites</li>
<li>20.20 korte pauze</li>
<li>20.40 Arjan Eising - Dr. Strangescope or: How I Learned to Stop Worrying and Love the Closure</li>
<li>20.50 Thomas van Zuijlen - TBA</li>
<li>21.00 Vasilis van Gemert - Nieuwe uitgangspunten voor webdesign</li>
<li>21.10 Christiaan W. Lustig - De rol van contentproductie in responsive web design</li>
<li>21.20 Pascal Vree - How To Destroy Innovation</li>
<li>21.30 borrelen</li>
</ul>
<h2>Pecha Kucha</h2>
<p>Pecha Kucha is een presentatiestijl waarbij 20 slides worden getoond die elk 20 seconden in beeld zijn. Door de korte tijd van 6 minuut 40 krijg je snelle en beknopte presentaties.</p>
<p>Pecha Kuchas zorgen vaak voor het onverwachte - onverwacht talent, onverwachte ideeën. Zorg er dus voor dat je er bij bent!</p>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Netvlies in Breda. Het adres is Prinsenkade 7, Breda. Zoals gebruikelijk is deze bijeenkomst gratis bij te wonen door zowel leden als niet-leden. Geef wel even aan dat je komt <a href="https://www.fronteers.nl/bijeenkomsten/2012/netvlies">het formulier op de bijeenkomstpagina</a>. <em>Er is slechts ruimte voor 30 personen, inclusief sprekers.</em></p>
</content>
</entry>
<entry>
<title>Met 50% korting naar de training 'Apps en Accessibility'</title>
<link href="https://www.fronteers.nl/nl/blog/2012/10/korting-training-apps-accessibility"/>
<updated>2012-10-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/10/korting-training-apps-accessibility</id>
<content xml:lang="nl" type="html"><p>Donderdag 11 oktober organiseert Stichting Accessibility een korte training <a href="http://www.accessibility.nl/trainingen/julian-harty-apps-and-accessibility">'Apps en Accessibility'</a> met als speciale gast <a href="https://twitter.com/julianharty">Julian Harty</a>. Leden van Fronteers krijgen 50% euro korting op deze training.</p>
<p>Julian Harty (UK) is een expert op het gebied van testen en verbeteren van mobiele apps en webapplicaties. Hij spreekt over de hele wereld over het verbeteren van mobiele applicaties en internettoepassingen door slimme inzet van tools. In de lezing 'Apps &amp; Accessibility', zal hij onder meer ingaan op het testen van de toegankelijkheid van mobiele applicaties. Let op: deze lezing is in het Engels.</p>
<p>Om gebruik te maken van de korting, kun je <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact opnemen met de ledenadministratie</a>. De korting geldt, zoals gebruikelijk, alleen voor leden die bij aankondiging van deze actie al lid waren.</p>
</content>
</entry>
<entry>
<title>Bijeenkomsten op 17 en 24 oktober</title>
<link href="https://www.fronteers.nl/nl/blog/2012/09/bijeenkomsten-oktober"/>
<updated>2012-09-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/09/bijeenkomsten-oktober</id>
<content xml:lang="nl" type="html"><p>Naast het congres staan er in oktober ook twee bijeenkomsten ingepland. De eerste is op woensdag 17 oktober bij <a href="http://competa.com/">Competa</a> in Rijswijk. Een week later, op woensdag 24 oktober, doen we Hilversum aan bij <a href="http://lajos.nl/">Lajos</a>.</p>
<h2>Competa - 17 oktober 2012</h2>
<p>Dan Entous gaat een responsive design showcase toelichten, en kijkt welke technieken en aanpakken ze hebben gebruikt in dat traject. Er is nog geen tweede spreker.</p>
<p><a href="https://www.fronteers.nl/bijeenkomsten/2012/competa">Lees meer over deze bijeenkomst bij Competa</a></p>
<h2>Lajos - 24 oktober 2012</h2>
<p>Edwin Martin neemt ons mee de diepte in op het gebied van jQuery's deferred en promise objecten en methoden. Daniël Vermeer vertelt over back-end security en wat daarvoor belangrijk is voor front-end developers.</p>
<p><a href="https://www.fronteers.nl/bijeenkomsten/2012/lajos">Lees meer over deze bijeenkomst bij Lajos</a></p>
<p>Zoals gebruikelijk zijn beide bijeenkomsten gratis toegankelijk voor zowel leden als niet-leden. Wel is gewenst dat je doorgeeft dat je aanwezig zult zijn via de formulieren op de hierboven gelinkte pagina's.</p>
</content>
</entry>
<entry>
<title>Algemene Ledenvergadering 2012 en bestuursverkiezingen</title>
<link href="https://www.fronteers.nl/nl/blog/2012/09/alv-en-bestuursverkiezingen"/>
<updated>2012-09-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/09/alv-en-bestuursverkiezingen</id>
<content xml:lang="nl" type="html"><p>Op donderdag 22 november zal de jaarlijkse Algemene Ledenvergadering (ALV) van Fronteers plaatsvinden. Op de ALV wordt het afgelopen jaar besproken, wordt de koers voor het nieuwe jaar uitgezet en worden bestuursverkiezingen gehouden. De plaats en tijd worden nader bekend gemaakt in een aparte blogpost, maar reserveer de avond van de 22e alvast in je agenda.</p>
<p>Dit jaar zullen de bestuursleden Peter-Paul Koch, Arjan Eising, en Matijs Brinkhuis aftreden. Arjan en Matijs zijn herkiesbaar, Peter-Paul is dat niet. Hij zegt na vijf jaar het Fronteersbestuur vaarwel. Tevens willen wij duidelijk maken dat Matijs Brinkhuis zich in Brighton heeft gevestigd, en dus niet meer in Nederland woont. Het bestuur acht dit geen beletsel voor zijn bestuurstaken, temeer daar hij heeft aangeboden het penningmeesterschap van Krijn Hoetmer over te nemen, dat geheel online uitgeoefend kan worden. Zowel Matijs als Arjan zullen op een later moment hun kandidatuur nog nader toelichten.</p>
<p>Peter-Paul zal wel actief lid van de vereniging blijven. Namens de vereniging bedankt de rest van het bestuur Peter-Paul voor zijn jarenlange inzet als voorzitter, en voor het trekken van de kar sinds voor de oprichting in 2007. De vereniging kan ondertussen prima op haar eigen benen staan, maar is zeker in eerste instantie sterk gevormd door Peter-Paul's leiderschap. Veel van ons huidige succes hebben we te danken aan zijn oorspronkelijke visie.</p>
<p>Conform de statuten mag elk lid zich verkiesbaar stellen voor het bestuur, en het voornaamste doel van deze blogpost is te vragen of er leden zijn die zich daartoe geroepen voelen. Deze leden hebben tot 22 oktober, een maand voor de ALV, de tijd zich kandidaat te stellen. Dit kan je doen door <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> met ons op te nemen: je kandidatuur komt dan vanzelf bij het bestuur terecht. Geef kort en bondig aan waarom je in het bestuur zou willen plaatsnemen. Op 22 oktober zullen eventuele kandidaturen bekend gemaakt worden.</p>
<p>Op de ALV kunnen alle aanwezige leden op alle, sommige, of geen van de kandidaten stemmen. Alle kandidaten die meer dan 50% van de uitgebrachte stemmen krijgen, worden in het bestuur verkozen. Het nieuwe bestuur kiest vervolgens uit zijn midden een voorzitter, secretaris en penningmeester. Gezien Peter-Paul's vertrek zal het voorzitterschap dus vrijkomen.</p>
<p>Het huidige bestuur meent dat het het meest slagvaardig is met vijf of zes bestuurders. Met meer leden kan het bestuur te log worden. Dit is echter het inzicht van het huidige bestuur en vormt geen beletsel voor leden om zich kandidaat te stellen. Uiteindelijk bepaalt de ALV of er meer dan drie nieuwe bestuurders worden gekozen.</p>
<p>Zoals gezegd, de officiële aankondigingen van kandidaturen en de ALV volgen later.</p>
</content>
</entry>
<entry>
<title>Met 100 euro korting naar BubbleConf</title>
<link href="https://www.fronteers.nl/nl/blog/2012/09/korting-bubbleconf"/>
<updated>2012-09-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/09/korting-bubbleconf</id>
<content xml:lang="nl" type="html"><p>Op 12 oktober 2012 vindt in Tuschinski <a href="http://www.bubbleconf.com/">BubbleConf 2012</a> plaats. Op het programma staan sprekers als Facebook’s Philip Su, ontwikkelaar Zed Shaw en ontwerper Juanma Teixido. Leden van Fronteers krijgen 100 euro korting op dit congres.</p>
<p>Sprekers en bezoekers uit de wereld van tech, design, UX en business komen bij elkaar voor een dag vol mogelijkheden om je te laten verrassen, nieuwe mensen te ontmoeten, zinvolle zaken te leren die je helpen succesvol te zijn met je start-up of onderneming en ongewone verhalen te horen van topspelers uit jouw veld.</p>
<p>Om gebruik te maken van de korting, kun je contact opnemen met de <a href="https://www.fronteers.nl/nl/vereniging/contact/">ledenadministratie</a>. De korting geldt, zoals gebruikelijk, alleen voor leden die bij aankondiging van deze actie al lid waren.</p>
</content>
</entry>
<entry>
<title>Jurgen Vansteelant</title>
<link href="https://www.fronteers.nl/nl/blog/2012/09/jurgen-vansteelant"/>
<updated>2012-09-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/09/jurgen-vansteelant</id>
<content xml:lang="nl" type="html"><p>Deze week bereikte ons het treurige nieuws dat Jurgen Vansteelant op zaterdag 8 september is overleden als gevolg van een <a href="http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20120909_00289343">verkeersongeluk</a>.</p>
<p>Jurgen was docent aan de opleiding Devine — Digital Design and Media aan de Hogeschool West-Vlaanderen en vanuit die functie sinds het voorjaar van 2011 ook lid van de onderwijscommissie van Fronteers.</p>
<p>Fronteers wenst de ouders, familie en vrienden van Jurgen heel veel sterkte met dit grote verlies.</p>
</content>
</entry>
<entry>
<title>Fronteers 2012: de laatste sprekers</title>
<link href="https://www.fronteers.nl/nl/blog/2012/09/de-laatste-sprekers"/>
<updated>2012-09-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/09/de-laatste-sprekers</id>
<content xml:lang="nl" type="html"><p>Met nog zo'n drie weken te gaan kunnen we vandaag de laatste sprekers voor Fronteers 2012 aankondigen: Peter-Paul Koch, Stephen Hay, Jeroen Wijering en Alex Russell.</p>
<p><em><a href="http://quirksmode.org/about/">Peter-Paul Koch</a></em> heeft als de man achter Quirksmode.org en oprichter van Fronteers eigenlijk geen introductie meer nodig. Zijn compatibiliteitstabellen hebben al heel wat ontwikkelaars geholpen bij het doorgronden van browser quirks. De afgelopen jaren heeft Peter-Paul zich verdiept in de (on)mogelijkheden van mobiele browsers.</p>
<p><em><a href="http://www.the-haystack.com/about/">Stephen Hay</a></em>, ook wel bekend als “Captain Flexbox”, heeft de afgelopen jaren het congres steeds weer verrast, met onder andere talks over geavanceerde CSS en responsive webdesign. Dit jaar zal dat niet anders zijn.</p>
<p><em><a href="http://www.whoisjw.tv/jeroen-wijering/">Jeroen Wijering</a></em> is de maker van de bekende <a href="http://www.longtailvideo.com/players/">JW Player</a>. Zelfs YouTube heeft nog een tijd deze speler gebruikt. Jeroen heeft niet stilgezeten en is de speler blijven doorontwikkelen tot de uitgebreide speler die het nu is. Jeroen zal spreken over HTML5-video en ondertitels.</p>
<p><em><a href="http://infrequently.org/">Alex Russell</a></em> is een van de Chrome-ontwikkelaars en werkt mee aan de laatste JavaScript-specificatie. Alex spreekt dit jaar op Fronteers onder de titel “What the legacy web is keeping from us (and why it's not any more)”.</p>
<p>Er zijn nog enkele kaartjes over voor de <a href="https://www.fronteers.nl/congres/2012/workshops/visual-design-101-for-web-developers-mark-boulton">workshop Visual Design 101 for Web Developers door Mark Boulton</a>. De workshop richt zich specifiek op ontwikkelaars die meer willen leren over web design. Het is zelfs nog mogelijk om een combikaartje workshop plus Fronteers 2012 te kopen.</p>
<p>Voor wie nog geen kaartje heeft is er nog een allerlaatste kans. Op 22 september om 12:00 CET verkopen we de tien laatste kaartjes. Hou <a href="https://twitter.com/fronteersConf">@fronteersConf</a> goed in de gaten.</p>
<p>De drukpersen draaien, de goodies zijn onderweg en de aanmeldingen van sprekers voor de <a href="https://www.fronteers.nl/congres/2012/jam-session">Jam Sessies</a> stromen binnen. Ofwel: de laatste voorbereidingen voor Fronteers 2012 zijn in volle gang.</p>
<p>Tot over drie weken!</p>
</content>
</entry>
<entry>
<title>Fronteers vrijwilligersuitje: technisch vernuft</title>
<link href="https://www.fronteers.nl/nl/blog/2012/09/fronteers-vrijwilligersuitje-technisch-vernuft"/>
<updated>2012-09-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/09/fronteers-vrijwilligersuitje-technisch-vernuft</id>
<content xml:lang="nl" type="html"><p>Met de zeilen gestreken glijdt de De Hoge Wier door het water. De draaibrug wijkt. Fietsers en voetgangers staan stil en aanschouwen onze éémastklipper terwijl ze de Groote Zeesluis binnenloopt.</p>
<p><img src="https://www.fronteers.nl/_img/blog/img-3526.jpg" alt="Klippers op het IJselmeer." /></p>
<p>De haven van Muiden ligt achter ons. Voor ons lonkt de wijdsheid van het IJmeer. Aan lijnen wordt getrokken, katrollen doen hun werk, de zeilen worden gehesen en staan bol van de wind. We maken vaart. Dan gooit de schipper het roer om en haalt de grootschoot aan, de giek waait over en we zijn overstag gegaan.</p>
<p>Aan boord praten de Fronteers al snel over semantiek, Node JS, Backbone JS, CSS preprocessors et cetera. We zijn hier met louter vakidioten, mensen die hun browser resizen om te kijken of een website wel responsive is; mensen die op F12 drukken, gewoon om te zien hoe iets werkt; ménsen die van het web houden.</p>
<p>Achter me valt een zwaard in het water. Ik schrik op uit het gesprek en volg de lijn terug naar het katrol waar de schipper aan draaide. Hier zie ik letterlijk hoe de boot werkt. Alles is mechanisch. Meer nog dan op het web staan oorzaak en gevolg in direct verband.</p>
<p>Voortgedreven door niets dan wind zijn werelden ontdekt. Daarbij vergeleken vallen de begrenzingen van browsers in het niets. Met technisch vernuft en vakmanschap is alles mogelijk. Laten we een voorbeeld nemen aan de Hollandse scheepsbouwers van weleer en de beperkingen van het web omzetten in elegante technische oplossingen.</p>
<p><img src="https://www.fronteers.nl/_img/blog/7916225236-af246f3c61-o.jpg" alt="Fronteers op het dek van De Hoge Wier." /></p>
<h2>Foto’s van het zeilen</h2>
<ul>
<li><a href="https://plus.google.com/photos/102586242192310743325/albums/5783509127393716561">Fotoalbum Edwin Martin</a></li>
<li><a href="http://www.flickr.com/photos/arjaneising/sets/72157631373234466/">Fotoalbum Arjan Eising</a></li>
</ul>
</content>
</entry>
<entry>
<title>20% korting op ISOC masterclasses in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2012/09/korting-isoc-masterclasses"/>
<updated>2012-09-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/09/korting-isoc-masterclasses</id>
<content xml:lang="nl" type="html"><p>De vereniging Internet Society Nederland (ISOC) heeft in samenwerking met onder andere de UvA, het CWI en het W3C een aantal <a href="http://isoc.nl/activ/masterclasses.htm">masterclasses</a> georganiseerd met sprekers uit het internationale standaardisatieveld. Er komt een aantal voor front-end developers interessante onderwerpen aan bod, waaronder HTML5, CSS3 en mobile app testing.</p>
<p>Op 13 September spreekt Bert Bos over CSS3, een dag later op 14 september gevolgd door Michael Smith die het over HTML5 gaat hebben. Op 27 september zal Fred Baker het hebben over Bufferbloat en Smart Grids, en op 10 oktober spreekt Julian Harty over mobile testing.</p>
<p>Fronteers leden krijgen een korting van 20% op de toch al lage toegangsprijs van de masterclasses. Deze varieert van €100 tot €150. Toegangskaarten koop je net als voor het Fronteers congres bij <a href="https://masterclasses_2012.paydro.net/">Paydro</a>.</p>
<p>Wil je gebruik maken van de ledenkorting? Neem <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact op met de ledenadministratie</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 1 november bij Netvlies</title>
<link href="https://www.fronteers.nl/nl/blog/2012/09/bijeenkomst-november"/>
<updated>2012-09-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/09/bijeenkomst-november</id>
<content xml:lang="nl" type="html"><p>Op donderdag 1 november is Fronteers te gast bij Netvlies Internetdiensten in Breda. Dit keer is het geen bijeenkomst met 2 presentaties, maar een Pecha Kucha met 10 presentaties door je mede-developers of jezelf.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 Inloop</li>
<li>19.30 Pecha Kucha 1 t/m 5</li>
<li>20.30 korte pauze</li>
<li>20.45 Pecha Kucha 6 t/m 10</li>
<li>21.45 borrelen</li>
</ul>
<h2>Pecha Kucha</h2>
<p>Pecha Kucha is een presentatiestijl waarbij 20 slides worden getoond die elk 20 seconden in beeld zijn. Hierdoor krijg je snelle en beknopte presentaties.
Door de korte tijd van 6 minuut 40 is het ook voor mensen die geen uur willen of kunnen volpraten, een stuk aantrekkelijker om een presentatie te geven.</p>
<p>Van degene die een titel voor een presentatie hebben ingediend sturen we rond 1 oktober een e-mail. Er worden er 10 uitgekozen op basis van onderwerp, zodat we niet 5 presentaties krijgen over hetzelfde.
Inschrijven voor een presentatie kan via het <a href="https://www.fronteers.nl/bijeenkomsten/2012/netvlies">formulier op de bijeenkomst-pagina</a>.</p>
<p>Daarom nodigen we je van harte uit om zelf een presentatie in te dienen. Het onderwerp is vrij, maar front-end development-gerelateerd wordt wel aangemoedigd.</p>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij Netvlies in Breda. Het adres is Prinsenkade 7, Breda (routebeschrijving). Zoals gebruikelijk is deze bijeenkomst gratis bij te wonen door zowel leden als niet-leden. Momenteel kan je je nog niet aanmelden voor de bijeenkomst, maar wel om een presentatie te geven. Dit doe je via het <a href="https://www.fronteers.nl/bijeenkomsten/2012/netvlies">formulier op de bijeenkomstpagina</a> Er is slechts ruimte voor 30 personen, inclusief sprekers.</p>
</content>
</entry>
<entry>
<title>Fronteers 2012: nog zes namen</title>
<link href="https://www.fronteers.nl/nl/blog/2012/09/fronteers-2012-nog-zes-namen"/>
<updated>2012-09-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/09/fronteers-2012-nog-zes-namen</id>
<content xml:lang="nl" type="html"><p>Met trots kunnen we vandaag nog een paar namen aankondigen: Mark Boulton, Peter Nederlof en Alex Graul komen een presentatie geven. Naast deze sprekers komt er ook een accessibility-panel met Bram Duvigneau, Bor Verkroost en Antoine Hegeman.</p>
<p>Op de <a href="https://www.fronteers.nl/congres/2012/speakers">lijst met sprekers</a> die tot nu toe zijn aangekondigd had je ze al kunnen zien staan: Addy Osmani, Anne van Kesteren, David DeSandro, Marcin Wichary, Mathias Bynens, Lea Verou, Phil Hawksworth en Rebecca Murphey.</p>
<p>Hier voegen we dus de volgende zes namen aan toe:</p>
<p><em><a href="http://www.markboulton.co.uk/">Mark Boulton</a></em> runt een kleine ontwerpstudio en heeft veel ervaring met veeleisende websites. Hij houdt zich bezig op het snijvlak van front-end en vormgeving. Hoe kun je vormgeving makkelijk toepasbaar maken voor ontwikkelaars? Mark geeft op de woensdag voor het congres ook een <a href="https://www.fronteers.nl/congres/2012/workshops/visual-design-101-for-web-developers-mark-boulton">workshop</a>.</p>
<p><em><a href="http://peterned.home.xs4all.nl/">Peter Nederlof</a></em> is een front-end ontwikkelaar pur sang, die <em>iedereen</em> wel kent van <code>[csshover](http://peterned.home.xs4all.nl/csshover.html)</code>. Hij is altijd in de weer met de laatste technieken, of het nu gaat om een 3D-engine in canvas of een CSS matrix-generator. Eindelijk hebben we hem zover gekregen om ook het podium in Tuschinski te betreden.</p>
<p><em><a href="http://www.sho.ch/">Alex Graul</a></em> is gespecialiseerd in gegevensvisualisatie. Hoe breng je gegevens over zonder dat het saai wordt? Alex is ook mede-ontwikkelaar van <a href="http://misoproject.com/">Miso</a>, een open source toolkit om gemakkelijk interactieve verhalen en gegevensvisualisaties te maken.</p>
<p>Tijdens het accessibility-panel gaan <em><a href="https://twitter.com/bramduvigneau">Bram Duvigneau</a></em>, <em><a href="http://www.eborfoundation.com/">Bor Verkroost</a></em> en <em>Antoine Hegeman</em>, ervaringsdeskundigen op het gebied van de (on)toegankelijkheid van het web, ons aan de hand van praktijkvoorbeelden een beeld schetsen van de valkuilen die zij op het web tegenkomen. Dit jaar dus geen presentatie over hoe het <em>zou moeten</em> in theorie, maar hoe het op dit moment <em>is</em> in de praktijk. De moderator is Chris Heilmann.</p>
<p>De kaartverkoop voor Fronteers 2012 is inmiddels gesloten, maar er zijn nog enkele kaartjes achtergehouden. Op 22 september om 12:00 CET verkopen we de 10 allerlaatste kaartjes. Wees er dus snel bij.</p>
<p>En of je nu naar het congres komt of niet, er zijn in ieder geval nog wel kaarten voor de workshop <em>Visual Design 101 for Web Developers</em> door Mark Boulton. Alle grondbeginselen van een goed ontwerp komen aan bod. <a href="https://www.fronteers.nl/congres/2012/workshops/visual-design-101-for-web-developers-mark-boulton">Meer informatie en kaartverkoop</a>. Via deze weg kun je nu ook nog toegang krijgen tot het congres zelf.</p>
<p>We hebben nog een maand en een hoop voorbereidingen te gaan, maar we hebben er weer zin in!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 20 september bij Future in IT</title>
<link href="https://www.fronteers.nl/nl/blog/2012/08/bijeenkomst-september"/>
<updated>2012-08-21T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/08/bijeenkomst-september</id>
<content xml:lang="nl" type="html"><p>Op donderdag 20 september is Fronteers te gast bij <a href="https://web.archive.org/web/20170518015223/http://futureinit.nl/">Future in IT</a> in Amsterdam. Arjan Eising geeft een presentatie over CoffeeScript, en Bran van der Meer gaat grids in design nader bekijken.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 inloop</li>
<li>19.30 Arjan Eising over CoffeeScript</li>
<li>20.30 korte pauze</li>
<li>20.45 Bran van der Meer over Grids</li>
<li>21.45 borrelen</li>
</ul>
<h2>CoffeeScript door Arjan Eising</h2>
<p>Met de komst van Sass en Less zijn verscheidene front-enders overgestapt op een manier om sneller CSS te schrijven. Met CoffeeScript kan dat ook voor JavaScript. In deze presentatie worden &quot;the good and the bad parts&quot; toegelicht, zodat je na afloop zelf kunt beslissen of je overstapt op code met minder accolades, haakjes en keywords.</p>
<h2>Grids door Bran van der Meer</h2>
<p>Nu webdesign steeds verder volwassen wordt, komt de vraag om een grid ook in de browser te realiseren steeds vaker aan de frontender. Bran gaat de designargumenten voor de verschillende soorten grids toelichten, en vertellen hoe je er als frontender het beste mee kan omgaan, zonder je designer teleur te stellen.</p>
<h2>Waar?</h2>
<p>Future in IT heeft een zaal gehuurd bij <a href="http://www.rokinview.nl/">Rokin View</a>: Rokin 38-E, 1012 KT Amsterdam. Zoals gebruikelijk is deze bijeenkomst gratis bij te wonen door zowel leden als niet-leden. Wel is gewenst dat je via het <a href="https://www.fronteers.nl/bijeenkomsten/2012/future-in-it">formulier op de bijeenkomst-pagina</a> doorgeeft dat je aanwezig kunt zijn. <em>Er is ruimte voor slechts 30 personen.</em></p>
</content>
</entry>
<entry>
<title>Met 25 euro korting naar Inspire Conference in Leiden</title>
<link href="https://www.fronteers.nl/nl/blog/2012/08/met-korting-naar-inspire"/>
<updated>2012-08-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/08/met-korting-naar-inspire</id>
<content xml:lang="nl" type="html"><p>In de tweede week van december wordt in Leiden een nieuw webdesigncongres georganiseerd, met een focus op ontwerp, typografie en code: <a href="http://inspireconf.com/">“Ready to Inspire”</a>. Het heeft als thema 'vakmanschap' en onder meer Jeffrey Zeldman, Simon Collison en Brad Frost komen spreken. Leden van Fronteers krijgen 25 euro korting op de entreeprijs, inclusief toegang tot de New Faces-track, een dag voor het congres.</p>
<p>Wil je gebruik maken van de ledenkorting? Neem <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact op met de ledenadministratie</a>. De korting geldt, zoals gebruikelijk, alleen voor leden die bij aankondiging van deze actie al lid waren en is niet toepasbaar op de nog aan te kondigen workshops.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst bij WHITE op 30 augustus 2012</title>
<link href="https://www.fronteers.nl/nl/blog/2012/07/bijeenkomst-white"/>
<updated>2012-07-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/07/bijeenkomst-white</id>
<content xml:lang="nl" type="html"><p>Op donderdag 30 augustus 2012 is Fronteers te gast bij WHITE in Valkenswaard. Er zijn twee presentaties voorzien.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 inloop</li>
<li>19.30 Stijn Janssen over Front-end style guides</li>
<li>20.30 korte pauze</li>
<li>20.45 Ludo Beumer en Jeroen Smits over Facebook versus corporate website</li>
<li>21.45 borrelen</li>
</ul>
<h2>Stijn Janssen over Front-end style guides</h2>
<p>Zoals ontwerpers gebruik maken van een huiststijl tijdens het ontwerpen en back-end ontwikkelaars gebruik maken coding standards voor hun code kunnen front-end ontwikkelaars gebruik maken van een style guide. De front-end style guide. Maar wat kan je hier in terugvinden? En hoe kan je het gebruiken binnen een bedrijf?</p>
<h2>Ludo Beumer en Jeroen Smits over Facebook versus corporate website</h2>
<p>Coca Cola heeft 44 miljoen fans op Facebook versus 270 duizend bezoekers per maand op hun website… Gaat de corporate website plaats maken voor de Facebook pagina? Feit is dat Facebook niet meer weg te denken is in de communicatie mix van bedrijven. Wat zijn de “do’s and dont’s” op Facebook? Hoe ver kun je gaan? Ludo en Jeroen bespreken enkele geslaagde en minder geslaagde cases.</p>
<h2>Waar?</h2>
<p>Deze bijeenkomst vindt plaats bij WHITE in Valkenswaard. Parallelweg Oost 23. 5555 XA Valkenswaard. Zoals gebruikelijk is de bijeenkomst gratis bij te wonen door zowel leden als niet-leden. Wel is gewenst dat je doorgeeft dat je komt via <a href="https://www.fronteers.nl/bijeenkomsten/2012/white">het formulier op de bijeenkomstpagina</a>.</p>
</content>
</entry>
<entry>
<title>Twee workshops op de woensdag voor het congres</title>
<link href="https://www.fronteers.nl/nl/blog/2012/07/fronteers-2012-twee-workshops-op-woensdag"/>
<updated>2012-07-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/07/fronteers-2012-twee-workshops-op-woensdag</id>
<content xml:lang="nl" type="html"><p>Ook dit jaar organiseert Fronteers weer twee intensieve workshops van hoog niveau, waarmee je een hele dag zoet bent. Dit jaar vinden beide workshops echter op dezelfde dag plaats, namelijk op woensdag 3 oktober.</p>
<h2>Design en JavaScript</h2>
<p>Mark Boulton zal een workshop Visual Design 101 voor Web Developers geven en Addy Osmani gaat het over JavaScript Application Development hebben.
Meer informatie zal spoedig te vinden zijn op de <a href="https://www.fronteers.nl/congres/2012/workshops">workshopspagina</a>.</p>
<p>Beide workshops duren een hele dag, ze worden gegeven in Amsterdam en de voertaal zal Engels zijn. Om er voor te zorgen dat de workshops persoonlijk blijven is er voor gekozen om maximaal 25 mensen toe te laten, <a href="https://fronteers.paydro.net/">wees er dus snel bij</a>! Uiteraard is er een aangename korting voor Fronteersleden die voor 5 april 2012 reeds lid waren (je kortings code heb je dan rond die tijd ontvangen via e-mail).</p>
</content>
</entry>
<entry>
<title>Fronteers Borrel in Groningen op 20 juli</title>
<link href="https://www.fronteers.nl/nl/blog/2012/07/fronteersborrel-groningen"/>
<updated>2012-07-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/07/fronteersborrel-groningen</id>
<content xml:lang="nl" type="html"><p>Om ook de leden in het noorden van het land tegemoet te komen, houden we vrijdag 20 juli een informele borrel in Groningen. Vanaf 17:00 ben je welkom in Cafe Buckshot aan het Gedempte Zuiderdiep 58.</p>
<p>Het eerste rondje is van Fronteers. Laat hieronder even een berichtje achter als je ook komt!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 19 juli bij Wijs</title>
<link href="https://www.fronteers.nl/nl/blog/2012/06/bijeenkomst-wijs"/>
<updated>2012-06-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/06/bijeenkomst-wijs</id>
<content xml:lang="nl" type="html"><p>Op donderdag 19 juli 2012 is Fronteers te gast bij <a href="http://wijs.be/">Wijs</a> in Gent. Er worden twee presentaties voorzien. Eerst komt <a href="http://twitter.com/xavez">Xavier Bertels</a> praten over ritme en ratio’s in layout en typografie voor het web; vervolgens zal <a href="http://twitter.com/ddfreyne">Denis Defreyne</a> wat vertellen over static site generators zoals <a href="http://nanoc.stoneship.org/">nanoc</a>.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:45 ontvangst met een hapje en een drankje</li>
<li>19:00 Xavier Bertels: <em>Ritme en verhouding: think more, do less</em></li>
<li>20:00 Denis Defreyne over <em>static site generators</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij <a href="http://wijs.be/">Wijs</a> te Gent. <a href="https://www.fronteers.nl/bijeenkomsten/2012/wijs">Er is een plannetje beschikbaar op de detailpagina van deze bijeenkomst.</a></p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 40 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Fronteers 2012: de volgende vier sprekers</title>
<link href="https://www.fronteers.nl/nl/blog/2012/06/fronteers-2012-volgende-sprekers"/>
<updated>2012-06-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/06/fronteers-2012-volgende-sprekers</id>
<content xml:lang="nl" type="html"><p>Nooit eerder verkochten we onze kaarten zo snel. En met nog een kleine 4 maanden voor de boeg, hopen we er dit jaar eerder doorheen te zijn dan ooit tevoren. Mocht je nog twijfelen, wacht dan niet te lang, want we willen je niet teleurstellen. Vandaag kunnen we weer vier sprekers onthullen waar we erg trots op zijn.</p>
<p>Hollands trots <em><a href="http://annevankesteren.nl/">Anne van Kesteren</a></em> werkt voor Opera Software en houdt zich bezig met standaardisatie. Daarnaast zet hij zich in voor meer openheid én meer privacy, maar wel in de juiste verhoudingen.</p>
<p>De tweede is front-end developer <em><a href="http://desandro.com/">David DeSandro</a></em>. Hij heeft een passie voor het vinden van nieuwe, creatieve oplossingen. Resultaten hiervan zijn de grafische en technische meesterwerkjes <a href="http://masonry.desandro.com/">Masonry</a> en <a href="http://isotope.metafizzy.co/">Isotope</a>. Na drie jaar nclud begint hij binnenkort voor Twitter. Spannend!</p>
<p>Wat betreft Twitter followers kan David wel een beetje jaloers zijn op <em><a href="http://addyosmani.com/">Addy Osmani</a></em>. Van de 4 sprekers die we vandaag bekendmaken heeft hij er de meeste, ruim 24.000. Hij werkt voor Google als Developer Programs Engineer, is lid van het jQuery team en draagt bij aan Modernizr. Hij typt graag JavaScript, maar heeft ook plezier in schrijven over hoe we het web beter kunnen maken.</p>
<p><em><a href="http://hawksworx.com/">Phil Hawksworth</a></em> werkt als technical director voor R/GA in Londen. Hij focust zich op de technische architectuur, maar waagt zich in de avonduurtjes aan het zelf tikken van code in de vorm van kleine experimentele projectjes. We hopen dat hij in ruil voor een kop koffie van onze barista’s zijn slechte dance moves wil laten zien.</p>
<p>De helft van al onze sprekers van dit jaar zijn <a href="https://www.fronteers.nl/congres/2012/speakers">nu bekend</a>. Zoals gezegd; wacht niet te lang met <a href="https://www.fronteers.nl/congres/2012/tickets">het aanschaffen van je kaartje</a>!</p>
</content>
</entry>
<entry>
<title>Fronteers juniborrel op 29 juni</title>
<link href="https://www.fronteers.nl/nl/blog/2012/06/juniborrel"/>
<updated>2012-06-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/06/juniborrel</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 29 juni, over twee weken, houden we weer een informele borrel. Vanaf 17 uur kun je terecht bij de Bierfabriek in Amsterdam, Rokin 75. Het eerste rondje is van Fronteers.</p>
<p>Kom je ook even langs? Laat het hieronder weten!</p>
</content>
</entry>
<entry>
<title>50% korting op PhoneGap Day EU in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2012/06/korting-phonegap-day-amsterdam"/>
<updated>2012-06-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/06/korting-phonegap-day-amsterdam</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 14 september vindt PhoneGap Day EU plaats in Amsterdam. Kaartjes kosten tijdens de early bird € 100, daarna € 150. Voor 10 leden van Fronteers hebben we een korting geregeld, waardoor je voor € 75 naar binnen kunt.</p>
<p>Er is nog niet veel bekend over het programma, maar het wordt vergelijkbaar met de VS variant. Op donderdag 13 september zullen ook workshops plaatsvinden, voor beginners en ervaren gebruikers.</p>
<p>Wil je gebruik maken van deze korting, neem dan even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> op met de ledenadministratie. Zoals gebruikelijk geldt de korting uitsluitend voor diegenen die op dit moment lid zijn.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 21 juni bij Digiti</title>
<link href="https://www.fronteers.nl/nl/blog/2012/06/bijeenkomst-digiti"/>
<updated>2012-06-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/06/bijeenkomst-digiti</id>
<content xml:lang="nl" type="html"><p>Op donderdag 21 juni 2012 is Fronteers te gast bij <a href="http://digiti.be/">Digiti</a> in Zoersel. Er worden twee presentaties voorzien.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met broodjes en een drankje</li>
<li>19:00 Kristof Houben over <em>pre-processing voor front-end developers</em></li>
<li>20:00 Stelian Firez over <em>website-optimalisatietechnieken</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Waar?</h2>
<p>Dit evenement vindt plaats bij <a href="http://digiti.be/">Digiti</a> te Zoersel. Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2012/digiti">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>30% korting op The Treasure of FrontEnd Island in Bologna</title>
<link href="https://www.fronteers.nl/nl/blog/2012/05/korting-treasure-of-frontend-island-bologna"/>
<updated>2012-05-31T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/05/korting-treasure-of-frontend-island-bologna</id>
<content xml:lang="nl" type="html"><p>We hebben weer een korting voor leden kunnen bedingen. Deze keer voor <a href="http://2012.fromthefront.it/">From the Front 2012: The Treasure of FrontEnd Island</a> in Bologna, Italië, op vrijdag 21 september 2012.</p>
<p>Aral Balkan, Blaine Cook, Denys Mishunov, Denise Jacobs, Linda Sandvik, Jake Archibald, Jonathan Snook, Peter-Paul Koch en Remy Sharp zullen spreken op dit eendaagse congres, wat makkelijk te combineren is met een weekendje zon.</p>
<p>Naar <a href="https://www.fronteers.nl/blog/2012/01/korting-op-front-trends-in-warschau">Front Trends in Warschau</a> gingen een stuk of 10 leden, waarvan een paar tegelijk met de (nacht)trein. Wellicht dat we deze keer ook een groepsreis kunnen opzetten, via <a href="http://forum.fronteers.nl/post/410/">ons forum</a>?</p>
<p>Wil je gebruik maken van deze korting, neem dan even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> op met de ledenadministratie. Zoals gebruikelijk geldt de korting uitsluitend voor diegenen die op dit moment lid zijn.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 21 mei bij KaHo St-Lieven</title>
<link href="https://www.fronteers.nl/nl/blog/2012/05/bijeenkomst-kahosl"/>
<updated>2012-05-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/05/bijeenkomst-kahosl</id>
<content xml:lang="nl" type="html"><p>Op maandag 21 mei 2012 is Fronteers te gast bij de opleiding <a href="http://www.ikdoeict.be/nl/">Professionele Bachelor ICT</a> (KaHo St-Lieven) te Gent. Er worden twee presentaties voorzien. Bram(us) Van Damme zal het hebben over RESTful APIs (met zijdelings Ajax, jQuery, JSON/JSONP, CORS en URL design). De heren van Pixel Lab, die samen met Zeptolab <a href="https://web.archive.org/web/20131127223442/http://www.cuttherope.ie/dev/">de HTML5-versie van Cut The Rope</a> hebben gebouwd, hebben ook vast iets interessants te vertellen — in het Engels, weliswaar.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met een drankje, gesponsord door Fronteers</li>
<li>19:00 Pixel Lab over <em>Recreating “Cut the Rope” in HTML5</em></li>
<li>20:00 Bramus Van Damme over <em>RESTful APIs</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Routebeschrijving</h2>
<p>Dit evenement vindt plaats in het J-blok van de Technologiecampus van KaHo St-Lieven te Gent. De campus heeft als adres Gebroeders De Smetstraat 1, maar het juiste lokaal bevindt zich eerder ter hoogte van de Guldenvliesstraat 14 te Gent. Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2012/kahosl">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 70 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 14 juni met internationale sprekers bij LBi Netherlands</title>
<link href="https://www.fronteers.nl/nl/blog/2012/04/bijeenkomst-internationale-sprekers-lbi"/>
<updated>2012-04-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/04/bijeenkomst-internationale-sprekers-lbi</id>
<content xml:lang="nl" type="html"><p>Fronteers bestaat 5 jaar. Ter ere van dit eerste lustrumjaar, organiseren we een grote bijeenkomst met twee internationale sprekers. Deze bijeenkomst wordt gehouden op 14 juni 2012 vanaf 15:00 uur bij <a href="http://www.lbi.nl/">LBi Netherlands</a> in Amsterdam. De bijeenkomst is voor iedereen, dus ook niet leden, en is gratis!</p>
<p>De middag start met een presentatie door Bruce Lawson. Om 17:00 uur zal er een hapje gegeten worden en 's avonds zal Rachel Andrew een inspirerende presentatie geven. Daarna is er tijd voor een borrel.</p>
<h2>Programma</h2>
<ul>
<li>15:00 Inloop</li>
<li>15:30 Welkomswoordje</li>
<li>15:35 Presentatie Bruce Lawson</li>
<li>17:00 Dinner</li>
<li>18:00 Presentatie Rachel Andrew</li>
<li>19:30 Borrelen</li>
</ul>
<h2>Bruce Lawson</h2>
<p>Bruce Lawson evangelises Open Web Standards for Opera. He’s been active in Web Standards since 2002, working with the Web Standards Project, the W3C Mobile Best Practices Working Group and developer education. He co–authored Introducing HTML5, the first full–length book on the subject. He blogs at brucelawson.co.uk. You can follow him at <a href="https://twitter.com/brucel">@brucel.</a></p>
<h2>Rachel Andrew</h2>
<p>Rachel Andrew is a front and back-end web developer, author and speaker. Her books include the bestselling CSS Anthology for Sitepoint and she is a regular contributor to a number of publications both on and offline. She writes about business and technology on her own site at rachelandrew.co.uk. In addition to offering consultancy services through the company she founded in 2001 – edgeofmyseat.com – Rachel is also one of the developers of the content management system, Perch.</p>
<h2>Locatie</h2>
<p>LBi Netherlands is goed bereikbaar met de auto en het openbaar vervoer. We raden je aan om met het openbaar vervoer te komen. Er zijn geen parkeerplaatsen beschikbaar op het terrein van LBi. Als je met de auto komt, raden we je aan om te parkeren bij <a href="http://www.parkerenindestad.nl/amsterdam/algemeen/parkeren-transferium-amsterdam-arena.html">Transferium Amsterdam Arena</a>, en met de metro naar LBi te reizen. Vanaf Transferium Amsterdam Arena is het ongeveer 5 à 10 minuten met de metro.</p>
<h2>Met het openbaar vervoer:</h2>
<ul>
<li>Neem de trein naar station Duivendrecht, Amsterdam Amstel of Bijlmer Arena.</li>
<li>Neem dan de metro naar Spaklerweg.</li>
<li>Neem de uitgang Wenckebachweg en loop rechtdoor langs het fietspad.</li>
<li>Ga aan het eind van het pad rechts, de Wenckebachweg op.</li>
<li>Na ongeveer 10 minuten lopen zie je LBi recht voor je.</li>
</ul>
<h2>Aanmelden</h2>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen door zowel leden als niet-leden. Wel is gewenst dat je jezelf opgeeft via <a href="https://www.fronteers.nl/bijeenkomsten/2012/lbi">het formulier op de bijeenkomstpagina</a>. Er is plek voor maximaal 150 deelnemers; dus: die het eerst komt, het eerst maalt. De bijeenkomst is gratis en is voor iedereen, dus ook niet leden.</p>
<p>Wanneer je toch niet kunt komen, verzoeken wij je af te melden via e-mail, zodat er weer plek is voor iemand anders.</p>
</content>
</entry>
<entry>
<title>Hackaton op zaterdag 19 mei</title>
<link href="https://www.fronteers.nl/nl/blog/2012/04/hackaton-19-mei"/>
<updated>2012-04-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/04/hackaton-19-mei</id>
<content xml:lang="nl" type="html"><p>Ter ere van het eerste lustrumjaar van Fronteers, organiseren we een hackaton op zaterdag 19 mei 2012. De gehele dag zijn we onder de pannen bij coworkingspace <a href="http://nomadz.nl/">Nomadz</a> in Den Haag.</p>
<p>De dag start met een duopresentatie gegeven door Vasilis van Gemert en Peter Nederlof. Zij zullen een inspirerend praatje houden over wat voor technieken we in de toekomst kunnen gebruiken. Denk aan Flexbox, CSS 3D transformaties et cetera.</p>
<p>In de middag wordt in groepen gewerkt aan toffe projecten, die bijvoorbeeld alleen werken in alpha- of betaversies van browsers zoals Firefox en Chrome. Deze projecten worden aan het einde van de dag gepresenteerd aan mede-Fronteersleden. Als afsluiter is er een borrel.</p>
<p>De dag is alleen toegankelijk voor leden van Fronteers. <a href="https://www.fronteers.nl/bijeenkomsten/2012/hackaton">Opgave is mogelijk tot 10 mei via het formulier op de Hackaton-pagina.</a></p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 3 mei bij VPRO</title>
<link href="https://www.fronteers.nl/nl/blog/2012/04/bijeenkomst-vpro"/>
<updated>2012-04-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/04/bijeenkomst-vpro</id>
<content xml:lang="nl" type="html"><p>Op 3 mei zijn we te gast bij VPRO Digitaal, de digitale afdeling van de omroep. Bekend van populaire websites als 3VOOR12 en Cinema.nl, maar ook de maker van vele websites bij eigen programma's. Hay Kranen en Frank Bosma zullen in hun talks ingaan op respectievelijk het gebruik van RequireJS en het Model View Controller design pattern.</p>
<h2>RequireJS</h2>
<p>Hay Kranen geeft een presentatie over het gebruik van RequireJS bij de VPRO. RequireJS is een JavaScript file en module lader die erg nuttig is voor onder andere de performance van je site en een goede structuur plus hergebruik van je code.</p>
<h2>E=MV*</h2>
<p>Frank Bosma geeft een presentatie over het Model View Controller (MVC) design pattern. De laatste tijd duiken er veel nieuwe JavaScript MVC libraries op. Maar wat is dat, MVC, en kost het energie of levert het ook energie op? Aan de hand van onder andere een aantal VPRO websites en het gebruik van MVC aldaar, probeert Frank een antwoord te geven op die vraag.</p>
<h2>Locatie</h2>
<p>De VPRO is gevestigd op het Mediapark in Hilversum, naast treinstation Hilversum Noord. Het adres is: Sumatralaan 49, 1217 GP, Hilversum (<a href="http://www.vpro.nl/overdevpro/3779664/adres+en+contact">routebeschrijving</a>)</p>
<h2>Aanmelden</h2>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen door zowel leden als niet-leden. Wel is gewenst dat je je aanmeldt via <a href="https://www.fronteers.nl/bijeenkomsten/2012/vpro">het formulier op de bijeenkomstpagina</a>.</p>
</content>
</entry>
<entry>
<title>Korting op Offscreen Magazine voor Fronteers</title>
<link href="https://www.fronteers.nl/nl/blog/2012/04/korting-op-offscreen-magazine"/>
<updated>2012-04-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/04/korting-op-offscreen-magazine</id>
<content xml:lang="nl" type="html"><p>Als front-ender zit je niet snel verlegen om leesmateriaal. Dagelijks worden talloze blogposts gepubliceerd over ons vak: trends en technieken op het gebied van CSS, HTML of JavaScript, hacks en polyfills, lof- en klaagzangen over browsers en standaarden — het is genoeg om je hele werkdag mee vol krijgen. Onlangs is er daar een interessant alternatief bijgekomen: <a href="http://www.offscreenmag.com/">Offscreen</a>, een &quot;ouderwets&quot; inkt-op-papier tijdschrift.</p>
<p>Het fraai vormgegeven blad werpt een blik op de mensen achter de apps en de websites. In interviews, verhalen en korte artikelen vertellen onder anderen <a href="https://twitter.com/simplebits">Dan Cederholm</a> van Dribbble, <a href="https://twitter.com/awilkinson">Andrew Wilkinson</a> van MetaLab, <a href="https://twitter.com/HAN">Hannah Donovan</a> van (voorheen) last.fm en de Belg <a href="https://twitter.com/bdc">Benjamin De Cock</a> over hun werk- en denkwijzen, het verloop van hun carrières, de hobbyprojecten, de geleerde lessen en hun uiteenlopende definities van succes. Het is inspirerend om te lezen over de passie en creativiteit van je vakbroeders en -zusters, en de afwezigheid van technische artikelen is eigenlijk geen gemis.</p>
<p>Kortom, Offscreen biedt inzicht in de persoonlijkheden die ons vakgebied opmaken, en is een mooie toevoeging aan de boekenkast van de front-end developer. Speciaal voor leden van Fronteers heeft uitgever <a href="https://twitter.com/kaibrach">Kai Brach</a> een kortingscode beschikbaar gesteld waarmee de portokosten komen te vervallen. Neem contact op met <a href="mailto:roel@fronteers.nl">Roel</a> voor je eigen kortingscode. Het aanbod is voor één nummer en een week geldig, dus wees er snel bij! Voor wie een abonnement neemt, vervallen de verzendkosten van het eerste nummer.</p>
</content>
</entry>
<entry>
<title>Kaartverkoop Fronteers 2012 van start</title>
<link href="https://www.fronteers.nl/nl/blog/2012/04/kaartverkoop-fronteers-2012-van-start"/>
<updated>2012-04-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/04/kaartverkoop-fronteers-2012-van-start</id>
<content xml:lang="nl" type="html"><p>De kaartverkoop van Fronteers 2012 op 4 en 5 oktober 2012 is begonnen.</p>
<p>Het wachten is voorbij: de kaartverkoop is begonnen. Vanaf vandaag kunnen kaartjes worden gekocht voor <a href="https://www.fronteers.nl/congres/2012">Fronteers 2012</a> op 4 en 5 oktober 2012.</p>
<p>Zoals gewoonlijk krijgen leden een mooie korting en bespaar je nog meer als je gebruik maakt van de Early Bird aanbieding. Als je zeker weet dat je komt, wacht dan niet te lang, want er is slechts een beperkt aantal Early Bird-kaarten beschikbaar. De Early Bird periode eindigt midden mei voor leden en heeft een limiet van 75 kaarten voor niet-leden.</p>
<p>Fronteers 2012 Early Bird prijzen (exclusief 19% BTW)
Fronteersleden: €200
--Niet leden-- <em>Uitverkocht!</em>: €275)</p>
<p>Fronteers 2012 normale prijzen (exclusief 19% BTW)
Fronteersleden: €275
Niet-leden: €350</p>
<p>Fronteersleden krijgen in de komende dagen een mailtje met daarin hun kortingscode. Korting voor leden geldt alleen voor mensen die voor of op 5 april 2012 lid zijn geworden. Studenten kunnen gebruik maken van de studentenkorting door <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> met ons op te nemen. Kaarten zijn te bestellen via <a href="https://fronteers.paydro.net/">Paydro</a>.</p>
<p><img src="https://www.fronteers.nl/_img/congres/2012/graphics/buttons/buy.png" alt="Bestel nu je kaartje voor Fronteers 2012" /></p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 10 april bij Inventis</title>
<link href="https://www.fronteers.nl/nl/blog/2012/04/bijeenkomst-inventis"/>
<updated>2012-04-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/04/bijeenkomst-inventis</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 10 april 2012 is Fronteers te gast bij Inventis in Houthalen (Limburg). Er worden twee presentaties voorzien. Eerst komt Danny Calders praten over typografie en responsive web design; vervolgens zal Jurgen Dedeckere wat vertellen over hoe opleidingen in staat moeten zijn om de fronteers van de toekomst te creëren.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met een drankje</li>
<li>19:00 Danny Calders over <em>typografie en responsive web design</em></li>
<li>20:00 Jurgen Dedeckere over <em>de nieuwe fronteer</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Routebeschrijving</h2>
<p>Inventis is gevestigd aan de Weg naar Zwartberg 85 te 3530 Houthalen-Helchteren (Limburg). Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2012/inventis">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 40 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 19 april in Breda</title>
<link href="https://www.fronteers.nl/nl/blog/2012/03/bijeenkomst-april-breda"/>
<updated>2012-03-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/03/bijeenkomst-april-breda</id>
<content xml:lang="nl" type="html"><p>Op donderdag 19 april is Fronteers wederom te gast bij <a href="http://e-sites.nl/">e-sites</a> in Breda. De presentaties zijn gerelateerd aan JavaScript, en gaan redelijk diep in op de materie. Nikolai Onken en Anne van Kesteren zullen spreken.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 inloop</li>
<li>19.30 Nikolai Onken over een geavanceerd JavaScript onderwerp</li>
<li>20.30 korte pauze</li>
<li>20.45 Anne van Kesteren over standaarden</li>
<li>21.45 borrelen</li>
</ul>
<h2>Tales from a standards engineer, door Anne van Kesteren</h2>
<p>From bytes to code points, same-origin to cross-origin, and mutation events to observers. Disclaimer: Abstract kan afwijken van daadwerlijke inhoud.</p>
<h2>Bereikbaarheid en opgave</h2>
<p>E-sites is gevestigd aan Reduitlaan 33, UNIT 2.09, 4814 DC in Breda. Kom je met de trein, dan is het een klein kwartiertje lopen vanaf station Breda.</p>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen voor zowel leden als niet-leden. Wel is gewenst dat je jezelf opgeeft via <a href="https://www.fronteers.nl/bijeenkomsten/2012/e-sites">het formulier op de detailpagina van de bijeenkomst</a>.</p>
</content>
</entry>
<entry>
<title>Workshop jQuery Inception in Antwerpen op 8 mei 2012</title>
<link href="https://www.fronteers.nl/nl/blog/2012/03/jquery-inception-antwerpen"/>
<updated>2012-03-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/03/jquery-inception-antwerpen</id>
<content xml:lang="nl" type="html"><p>Een korte update van de commissie workshops. De workshop jQuery Inception, een beginners workshop JavaScript en jQuery, zal op dinsdag 8 mei in Antwerpen gegeven worden. De workshop vindt plaats bij ASPACE, en er is plaats voor 12 personen om de gehele dag iets op te steken van jQuery.</p>
<p>Opgave is mogelijk via het <a href="https://www.fronteers.nl/workshops/jquery-inception-arjan-eising">formulier op de detailpagina van deze workshop</a>. De workshop wordt gegeven door Arjan Eising. <a href="http://www.aspace.be/">ASPACE</a> zit in het centrum van Antwerpen, op circa 15 minuten lopen vanaf het centraal station.</p>
<p>Naast deze workshop is het ook nog mogelijk om jezelf op te geven voor de <a href="https://www.fronteers.nl/workshops/html-css-frances-de-waal">beginners workshop HTML/CSS</a> die op woensdag 4 april in Utrecht gegeven wordt. Als je zelf al een HTML &amp; CSS crack bent zal deze workshop wellicht te basic zijn voor je maar misschien ken je mensen (buiten Fronteers) die wel behoefte hebben aan een workshop als deze. Schroom dan niet om hem door te geven, workshops zijn open voor zowel leden als niet-leden en ze zijn een goede reden om lid te worden.</p>
</content>
</entry>
<entry>
<title>€50 korting op de GOTO-conference in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2012/03/korting-goto-conference-amsterdam"/>
<updated>2012-03-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/03/korting-goto-conference-amsterdam</id>
<content xml:lang="nl" type="html"><p>En opnieuw is het prijs: Fronteers heeft een korting van €50 in de wacht weten te slepen voor de <a href="http://gotocon.com/amsterdam-2012/">GOTO Conference Amsterdam</a>, 24 en 25 mei in de Beurs van Berlage.</p>
<p>Dit is nu eens geen pure front-end, maar een algemeen softwarecongres waarop, gezien de stormachtige ontwikkelingen in web en mobiel, de organisatoren vonden dat front-end niet mocht ontbreken. Er zijn echter ook sessies over agile programming, back-end, en <a href="http://gotocon.com/amsterdam-2012/tracks/">meer</a>.</p>
<p>Voor de verandering is dit congres vrij dicht bij huis. Ook is het wat duurder dan de eerder aangekondigde: GOTO gebruikt een progressieve prijsstijging van €3 tot €6 per dag, wat betekent dat hoe eerder je je kaartje koopt, hoe goedkoper je uit bent. En, zoals gezegd, je Fronteers-code haalt nog eens €50 van de prijs af.</p>
<p>Wil je hiervan gebruik maken, neem dan even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact op</a> met de ledenadministratie. Zoals altijd geldt deze korting alleen voor mensen die op dit moment lid van Fronteers zijn.</p>
</content>
</entry>
<entry>
<title>Fronteers 2012: 4 en 5 oktober</title>
<link href="https://www.fronteers.nl/nl/blog/2012/03/fronteers-2012-4-en-5-oktober"/>
<updated>2012-03-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/03/fronteers-2012-4-en-5-oktober</id>
<content xml:lang="nl" type="html"><p>Het zal geen verrassing meer zijn dat we ook dit jaar weer een <a href="https://www.fronteers.nl/congres/2012">Fronteers conferentie</a> organiseren. De vijfde alweer. We zijn al flink bezig met plannen maken en potentiële sprekers uitzoeken. De datum is al geprikt: donderdag 4 en vrijdag 5 oktober. Met Lanyrd kan je deze <a href="https://web.archive.org/web/20171002053735/http://lanyrd.com/2012/fronteers/">datum gemakkelijk in je agenda zetten</a>. Net als de voorgaande twee jaren zullen we weer het prachtige <a href="https://nl.wikipedia.org/wiki/Tuschinski_Theater">Art Deco Pathé Tuschinski Theater</a> in het centrum van Amsterdam gebruiken.</p>
<p>Op de afgelopen conferentie hebben we veel lof ontvangen, waar we natuurlijk heel blij mee zijn. We zullen er alles aan doen om komend jaar nog indrukwekkender te maken. Het niveau van de sprekers, de inhoud en de goede sfeer hopen we zo te houden. Of zelfs dat nog te verbeteren. Het zal in ieder geval weer een inspirerende, gevarieerde en technisch hoogstaande conferentie worden.</p>
<p>Eind maart / begin april gaat de kaartverkoop weer van start, maar het is al mogelijk om een gratis kaartje te winnen. Je moet wel al een Fronteers t-shirt hebben. Maak een foto van je Fronteers t-shirt en tweet erover of stuur hem naar ons op en we plaatsen de foto op <a href="http://isitfronteersconfyet.com/">isitfronteersconfyet.com</a> . We zullen daar dan een willekeurige foto uit pakken voor het vrijkaartje.</p>
<p>Ben je nog niet eerder geweest? Dan kan je een goede indruk van de conferentie krijgen door de <a href="https://www.fronteers.nl/congres">onderwerpen van voorgaande jaren te bekijken</a>. Bekijk ook de <a href="https://www.fronteers.nl/congres/2011/sessions">video's van vorig jaar op deze site, inclusief transcriptie</a> of op <a href="http://vimeo.com/channels/fronteers11">Vimeo</a> of abonneer je op de <a href="http://itunes.apple.com/podcast/fronteers-2011-sessions/id481631840">podcast</a>.</p>
<p>Als je op twitter zit, is het verstandig om <a href="https://twitter.com/FronteersConf">@FronteersConf</a> te volgen, je bent dan altijd op de hoogte van het laatste nieuws.</p>
<p>De conferentiecommissie,
Charis, Edwin, Hidde, Krijn, Peter, Peter-Paul, Sander en Thijs.</p>
</content>
</entry>
<entry>
<title>30% korting op jsDay in Verona</title>
<link href="https://www.fronteers.nl/nl/blog/2012/02/korting-op-jsday-in-verona"/>
<updated>2012-02-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/02/korting-op-jsday-in-verona</id>
<content xml:lang="nl" type="html"><p>En weer een leuk voordeeltje voor Fronteers-leden die JavaScript een mooie taal vinden en graag eens een keer naar Verona willen: we hebben niet minder dan 30% korting in de wacht gesleept voor <a href="http://2012.jsday.it/">jsDay 2012</a>.</p>
<p>Dit tweedaags congres, 16 en 17 mei aanstaande, richt zich exclusief op JavaScript. Het programma voor dit jaar is nog niet bekend, maar <a href="http://www.jsday.it/2011/schedule">dat van vorig jaar</a> ziet er goed uit. En voor de prijs hoef je het niet te laten: €175, en dat is nog exclusief de Fronteers-korting.</p>
<p>Wil je gebruik maken van deze korting, neem dan even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> op met de ledenadministratie. Zoals gebruikelijk geldt de korting uitsluitend voor diegenen die op dit moment lid zijn.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 6 maart in Zaventem</title>
<link href="https://www.fronteers.nl/nl/blog/2012/02/bijeenkomst-microsoft"/>
<updated>2012-02-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/02/bijeenkomst-microsoft</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 6 maart is Fronteers te gast bij Microsoft in Zaventem. Er worden twee presentaties voorzien. Eerst komt Stijn Janssen praten over front-end style guides; vervolgens zal Joris Hens wat vertellen over de lessen die hij leerde uit het runnen van SolidShops.com, een applicatie voor webdesigners die webwinkels bouwen voor hun klanten.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met een drankje</li>
<li>19:00 Stijn Janssen over <em>front-end style guides</em></li>
<li>20:00 Joris Hens over <em>het runnen en bouwen van een geavanceerde web app</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Routebeschrijving</h2>
<p>Microsoft is gevestigd aan de Leonardo Da Vincilaan 3 te 1935 Zaventem. Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2012/microsoft">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Aankomende uitschrijving niet-betalende leden</title>
<link href="https://www.fronteers.nl/nl/blog/2012/02/aankomende-uitschrijving-niet-betalende-leden"/>
<updated>2012-02-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/02/aankomende-uitschrijving-niet-betalende-leden</id>
<content xml:lang="nl" type="html"><p>Fronteers doet het goed. We groeien jaar na jaar, en hebben op dit moment 436 leden. Tenminste, 436 <em>potentiële</em> leden. 436 mensen die we tussen 6 en 10 januari een factuur hebben gestuurd voor het lidmaatschapsgeld over 2012. De meeste van jullie hebben keurig op tijd betaald, of tenminste gelijk na de eerste herinnering, waarvoor onze dank. Maar we lopen, zoals helaas ieder jaar, tegen een groep mensen aan die facturen en herinneringen negeren.</p>
<p>In voorgaande jaren was onze procedure om deze mensen een paar maanden lang persoonlijke emails en herinneringen te blijven sturen, smekend om op z'n minst een ontvangstbevestiging, met vaak na de derde poging een laconiek &quot;oh ja, vergeten, doe dit snel&quot; antwoord, maar maanden later nog steeds geen betaling. Het hele traject kostte onze ledenadministratie veel te veel tijd en energie, en met de groei van de vereniging werd dit alleen maar erger.</p>
<p>We hebben daarom eind vorig jaar in samenspraak met de ALV besloten om dit hele traject dit jaar rigoreus te verkorten. Twee weken geleden is onze eerste en enige herinnering naar niet-betalende leden verstuurd. De betalingstermijn daarvan loopt volgende week af. Mensen die op dat moment nog niet betaald hebben, zullen zonder verdere communicatie uitgeschreven worden als lid. Natuurlijk kunnen deze leden zich later alsnog weer aanmelden als lid, maar de standaard voor veel voordelen van het Fronteers lidmaatschap, zoals kortingen op congressen, is dat deze alleen gelden als je lid bent op het moment dat de korting wordt aangekondigd.</p>
<p>Daarom hierbij nog eens via een compleet ander kanaal een laatste poging om onze wanbetalende leden te bereiken: Ga nog eens bij jezelf na of je onze factuur hebt gezien en betaald. Het kan natuurlijk altijd zijn dat je van emailadres bent gewisseld zonder ons hiervan op de hoogte te stellen, of dat je een slecht afgesteld spamfilter gebruikt en daardoor onze factuur en herinnering hebt gemist, of dat je lidmaatschap door je bedrijf wordt betaald, en de administratie daar erg langzaam is (tip: Het Fronteers lidmaatschap is persoonlijk; als je bedrijf je wil sponsoren, betaal dan zelf, en declareer het naderhand bij je bedrijf). Neem in deze en andere gevallen ajb <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> met ons op, zodat we je nog een nieuwe kopie van de factuur kunnen sturen, en een week extra kunnen geven om te betalen. Als we niets van je horen, dan kunnen we ook niets voor je doen.</p>
</content>
</entry>
<entry>
<title>30% korting op Web Rebels in Oslo</title>
<link href="https://www.fronteers.nl/nl/blog/2012/02/korting-op-web-rebels-in-oslo"/>
<updated>2012-02-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/02/korting-op-web-rebels-in-oslo</id>
<content xml:lang="nl" type="html"><p>Als de trend zich voortzet, wordt het een erg voordelig jaar voor Fronteersleden. Een maand geleden werd bekend dat leden korting krijgen op een ticket voor <a href="https://www.fronteers.nl/blog/2012/01/korting-op-front-trends-in-warschau">Front-Trends</a>, eerder deze week was er een aanbieding voor de <a href="https://www.fronteers.nl/blog/2012/02/creativejs-amsterdam">CreativeJS workshop</a> van Seb Lee-Delisle en nu kunnen we alweer melden dat het ook gelukt is om voor Fronteersleden een korting te bedingen op tickets voor <a href="http://webrebels.org/">Web Rebels</a> op 24 en 25 mei in Oslo.</p>
<p>Web Rebels is een nieuw congres. De organisatie achter Web Rebels komt voort uit Framsia, een groep vrijwilligers die, onder andere geïnspireerd door Fronteers, maandelijks drukbezochte bijeenkomsten organiseert.</p>
<p>Er zijn 10 kaarten met 30% korting beschikbaar voor (huidige) leden van Fronteers. Heb je interesse, neem dan even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> op met de ledenadministratie voor nadere instructies voor het aanschaffen van je ticket. Wacht niet te lang, want de early bird start vanmiddag al om 15:00u en duurt slechts tot 24 februari, terwijl er in totaal maar 20 early bird tickets zijn. Tickets kosten in deze periode met Fronteerskorting € 179,20 inclusief btw. Na 24 februari wordt dit € 268,80.</p>
</content>
</entry>
<entry>
<title>Met 25% korting naar de CreativeJS workshop in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2012/02/creativejs-amsterdam"/>
<updated>2012-02-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/02/creativejs-amsterdam</id>
<content xml:lang="nl" type="html"><p>Op 12 en 13 april geeft <a href="http://seb.ly/">Seb Lee-Delisle</a>, die afgelopen jaar ook op <a href="https://www.fronteers.nl/congres/2011">het congres</a> was, zijn <a href="http://seb.ly/training/">CreativeJS</a> workshop bij Felix Meritis in Amsterdam. Leden van Fronteers (en freelancers) krijgen hiervoor 25% korting. Er zijn in totaal 12 plaatsen beschikbaar, en waarschijnlijk is 'ie snel uitverkocht.</p>
<p>Neem even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> op met de ledenadministratie als je een kortingscode wilt ontvangen.</p>
<p>De korting geldt trouwens alleen voor leden die op dit moment lid zijn van Fronteers.</p>
</content>
</entry>
<entry>
<title>Workshops update januari</title>
<link href="https://www.fronteers.nl/nl/blog/2012/01/cursussen-update-januari"/>
<updated>2012-01-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/01/cursussen-update-januari</id>
<content xml:lang="nl" type="html"><p>Na wat radiostilte tijdens de feestdagen hierbij de eerste workshops update voor 2012 met hopelijk goed nieuws voor iedereen die workshops wil gaan volgen in 2012!</p>
<p>Op basis van de feedback die we in 2011 gekregen hebben kunnen we met een gerust hart stellen dat <a href="https://www.fronteers.nl/nl/activiteiten">workshops</a> in 2011 een succes zijn geweest. In 2012 willen we ons best doen om workshops wat verder van tevoren aan te kondigen, maar verder lekker op deze voet doorgaan. Dit betekent dat we onze workshops blijven verzorgen bij Seats2Meet in Utrecht. Ook onze lage prijzen zullen hetzelfde blijven, €100 voor leden en €200 voor niet-leden. Het aanbod zal ook in grote lijnen hetzelfde blijven. We zijn hierin echter afhankelijk van de beschikbaarheid van trainers. Alle trainers die vorig jaar een workshop hebben gegeven wordt dit jaar, als dat niet al gebeurd is, gevraagd of ze hun training zouden willen herhalen.</p>
<p>Om alvast een tipje van de sluier op te lichten. In februari zal Arjan Eising zijn <a href="https://www.fronteers.nl/workshops/jquery-inception-arjan-eising">beginners workshop jQuery</a> gaan herhalen. In <strike>maart</strike> <strong>april</strong> wordt hij gevolgd door Vasilis van Gemert met zijn workshop <a href="https://www.fronteers.nl/workshops/adaptief-ontwikkelen-vasilis-van-gemert">adaptief ontwikkelen</a> voor de wat gevorderden onder ons. In april zal Frances de Waal<strong>ook</strong> haar <a href="https://www.fronteers.nl/workshops/html-css-frances-de-waal">beginnerscursus HTML en CSS</a> nog een keer gaan geven. Aangezien er gedurende de zomermaanden, juni, juli en augustus beduidend minder animo leek te zijn hebben we besloten dit jaar in deze maanden geen workshops te plannen.</p>
<p>Hopelijk gaat 2012 op zijn minst zo'n succesvol cursusjaar worden als 2011 geweest is.</p>
</content>
</entry>
<entry>
<title>Bijeenkomsten: 8 februari in Leiden en 15 februari in Rotterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2012/01/bijeenkomsten-februari"/>
<updated>2012-01-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/01/bijeenkomsten-februari</id>
<content xml:lang="nl" type="html"><p>De tweede en derde woensdagen van februari staan ingepland voor twee Fronteersbijeenkomsten. Op 8 februari zijn we te gast bij <a href="http://www.transip.nl/">TransIP</a> in Leiden, en een week later opent <a href="http://www.mirabeau.nl/">Mirabeau Rotterdam</a> de deuren voor een bijeenkomst.</p>
<h2>Bijeenkomst bij TransIP in Leiden op 8 februari</h2>
<p>Johan Schuyt geeft een presentatie over de Google Closure Compiler, en Peter Nederlof duikt de diepte in over CSS Transities en Transformaties in combinatie met JavaScript. <a href="https://www.fronteers.nl/bijeenkomsten/2012/transip">Meer informatie en opgave op de bijeenkomstpagina.</a></p>
<h2>Bijeenkomst bij Mirabeau in Rotterdam op 15 februari</h2>
<p>Johan Ronsse, die op zijn verjaardag speciaal voor ons uit Belgie af komt reizen, geeft een presentatie over interface design. Paul Martens, front-end developer bij Mirabeau, vertelt over spriting en workflow. <a href="https://www.fronteers.nl/bijeenkomsten/2012/mirabeau">Meer informatie en opgave op de bijeenkomstpagina.</a></p>
<h2>Opgave</h2>
<p>Zoals gebruikelijk zijn al deze bijeenkomsten gratis bij te wonen door zowel leden als niet-leden. Wel is gewenst dat je jezelf opgeeft via de formulieren op de bijeenkomstpagina's.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 19 januari in Gent</title>
<link href="https://www.fronteers.nl/nl/blog/2012/01/bijeenkomst-pure-sign"/>
<updated>2012-01-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/01/bijeenkomst-pure-sign</id>
<content xml:lang="nl" type="html"><p>Op donderdag 19 januari 2012 is Fronteers te gast bij Pure Sign in Gent. Er worden twee presentaties voorzien. Eerst komt Arjan Eising praten over CSS Selectors Level 4; vervolgens zullen Jelle Desramaults en Jochen Vandendriessche wat vertellen over de design &amp; front-end-workflow die ze hanteren, en hoe ze daarbij Serve, Haml, en Sass/Compass gebruiken.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met een drankje</li>
<li>19:00 Arjan Eising over <em>CSS Selectors Level 4</em></li>
<li>20:00 Jelle Desramaults en Jochen Vandendriessche over <em>de design &amp; front-end-workflow bij Gorilla</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Routebeschrijving</h2>
<p>Pure Sign is gevestigd aan de Liefkensstraat 35 B te 9032 Gent (Wondelgem). Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2012/pure-sign">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen. <a href="https://www.fronteers.nl/bijeenkomsten/2012/pure-sign#formulier-1">Geef je daarom op via het aanmeldformulier.</a> Vol is vol!</p>
</content>
</entry>
<entry>
<title>Korting op Front-Trends in Warschau</title>
<link href="https://www.fronteers.nl/nl/blog/2012/01/korting-op-front-trends-in-warschau"/>
<updated>2012-01-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/01/korting-op-front-trends-in-warschau</id>
<content xml:lang="nl" type="html"><p>Fronteers gaat zich inspannen om voor haar leden leuke kortingen op leuke congressen los te peuteren, en vandaag kunnen we aankondigen dat dit gelukt is voor <a href="http://2012.front-trends.com/">Front-Trends</a>, 26 en 27 april in Warschau.</p>
<p>De sprekerslijst ziet er goed uit, het congres is sowieso al goedkoop, en we ondersteunen natuurlijk graag de pogingen een nationaal Pools front-end congres van de grond te krijgen.</p>
<p>Derhalve kunnen we Fronteers-leden hierbij niet minder dan 30% korting bieden op Front-Trends. Wil je dat, neem dan contact op met <a href="mailto:krijn@fronteers.nl">krijn@fronteers.nl</a> en je krijgt nadere instructies voor het aanschaffen van je kaartje. Let op: er zijn er maar twintig, en op is op.</p>
<p>Het idee om kortingen voor buitenlandse congressen te regelen voor Fronteers-leden werd oorspronkelijk geopperd op de ALV van eind 2010. In de huidige insteek wordt de korting gedeeltelijk gesponsord door de vereniging, en gedeeltelijk aangeboden door het congres. Afhankelijk van het succes van deze actie hopen we vergelijkbare acties voor meer Europese congressen te organiseren, en hiermee onze leden te stimuleren tot meer internationale kennisdeling.</p>
</content>
</entry>
<entry>
<title>Nieuwjaarsborrel</title>
<link href="https://www.fronteers.nl/nl/blog/2012/01/nieuwjaarsborrel"/>
<updated>2012-01-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2012/01/nieuwjaarsborrel</id>
<content xml:lang="nl" type="html"><p>Namens het bestuur hierbij een gelukkig Nieuwjaar aan alle Fronteers-leden en overige bezoekers van de site.</p>
<p>Om het nieuwe jaar vrolijk te laten ingaan, organiseert Fronteers op <em>donderdag 26 januari</em> een Nieuwjaarsborrel voor leden. Deze zal plaatsvinden in <a href="http://www.bierfabriek.com/">De Bierfabriek</a>, Rokin 75, Amsterdam vanaf circa 19:00 uur. Het bestuur stelt enig gratis bier ter beschikking, en tevens is er gelegenheid om hier iets te eten.</p>
<p>Wel moeten we van tevoren weten met hoeveel mensen we zijn. Derhalve verzoeken we je je in te schrijven via onderstaand formulier, als je wilt komen.</p>
<h2>Aanwezigen</h2>
<ul>
<li>Krijn Hoetmer</li>
<li>Anton Kouliavtsev</li>
<li>Edwin Martin</li>
<li>Dorien</li>
<li>Arjan Eising</li>
<li>Hidde de Vries</li>
<li>Kris van der Ven</li>
<li>Peter-Paul Koch</li>
<li>Mike Vierwind</li>
<li>Peter Peerdeman</li>
<li>Peter Nederlof</li>
<li>Thijs Reijgersberg</li>
<li>Tom Greuter</li>
<li>Stefan Fountain</li>
<li>Jeroen Kuijpers</li>
<li>Wilfred Nas</li>
<li>Pascal Haakmat</li>
<li>Charis Rooda</li>
<li>Sander Aarts</li>
<li>Martijn Jongkind</li>
<li>Jan van Hellemond</li>
<li>Thomas van Zuijlen</li>
<li>Frenz</li>
<li>Tom Cool</li>
<li>Sophie van Waesberghe</li>
<li>Matijs Brinkhuis</li>
<li>Rein Groot</li>
<li>Jules Ernst</li>
</ul>
<p>We hopen onze leden op de 26e te mogen begroeten.</p>
</content>
</entry>
<entry>
<title>Lustrumcie zoekt enthousiaste leden!</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/lustrumcie-zoekt-enthousiaste-leden"/>
<updated>2011-12-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/lustrumcie-zoekt-enthousiaste-leden</id>
<content xml:lang="nl" type="html"><p>In 2012 bestaat Fronteers alweer vijf jaar! Aangezien we dit niet ongemerkt voorbij willen laten gaan, is er een lustrumcommissie opgezet tijdens de ALV enkele weken geleden. In de commissie zitten nu Charis Rooda en Arjan Eising, maar er zouden nog wel een of twee leden bij kunnen.</p>
<p>Dus, vind jij het leuk om enkele leuke acties, borrels en dergelijke te organiseren, neem dan contact op met Arjan: <a href="mailto:arjan@fronteers.nl">arjan@fronteers.nl</a>. Vergeet niet kort iets over jezelf te vertellen, en een beknopte onderbouwing te geven waarom <em>jij</em> in de commissie zou moeten zitten. In de loop van januari vindt de eerste vergadering plaats.</p>
</content>
</entry>
<entry>
<title>Dr. Strangescope or: How I Learned to Stop Worrying and Love the Closure</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/dr-strangescope"/>
<updated>2011-12-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/dr-strangescope</id>
<content xml:lang="nl" type="html"><p>Scopes en closures in JavaScript zijn altijd een soort van taboe geweest: het is er altijd, maar je hebt het er liever niet over. In dit artikel probeer ik, voor de beginnende JavaScripter, een introductie in scopes en closures te geven. En aangezien ik een enorme filmfreak ben, heb ik er enkele referenties naar de film <a href="http://www.imdb.com/title/tt0057012/">'Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb'</a> in gestopt.</p>
<h2>Scope</h2>
<p>Scopes in JavaScript (en alle andere programeertalen) zijn een soort ballenbak. Alle variabelen (en stiekem ook functies) zijn de ballen. Je kunt gewoon een bal pakken en de waarde van de variabele opvragen, of je kunt de waarde veranderen.</p>
<p>In JavaScript zijn er twee soorten scopes: <em>globale scope</em> en <em>functie scope</em>. In de globale scope zitten alle variabelen die niet in een functie staan, en in de functie scope zitten variabelen die in een specifieke functie aangemaakt zijn.</p>
<p>De functiescope moet je zien als een soort doos in de ballenbak. Het is mogelijk een variabele in de globale scope aan te passen, maar vanuit de globale scope kun je <em>niet</em> bij variabelen in de functie scope.</p>
<p>Tijd voor een voorbeeld:</p>
<pre><code>var russianAmbassador = 'Alexi de Sadesky';
function warRoom() {
alert(russianAmbassador); // Alexi de Sadesky
var president = 'Merkin Muffley';
alert(president); // Merkin Muffley
}
warRoom();
alert(president); // undefined
function warTable() {
alert(russianAmbassador); // undefined
var russianAmbassador = 'Foo';
alert(russianAmbassador); // Foo
}
warTable();
</code></pre>
<p>In de eerste functie (<code>warRoom</code>) kijken we eerst of binnen de functie de variabele <code>russianAmbassador</code> bestaat. Dit is niet het geval, dus wordt in de globale scope gekeken. Daar wordt de variabele wel gevonden en dus zal de naam van de Russische ambassadeur getoond worden. Omdat de variabele <code>president</code> in de functie scope zit van <code>warRoom</code>, zal die in de alert eronder helaas niet opvraagbaar zijn.</p>
<p>De tweede functie gaat iets anders werken. Omdat de JavaScript parser een variabele initialisatie van <code>russianAmbassador</code> tegenkomt, kan de globale variabele <code>russianAmbassador</code> niet meer benaderd worden. De eerste alert zal dus een <code>undefined</code> teruggeven. Daarna wordt de variabele gezet, en kan die alleen in de functie <code>warTable</code> benaderd worden.</p>
<p>Het weten dat een variabele ergens later in de code gezet gaat worden, lijkt veel op het feit dat een functieaanroep ook prima <em>voor</em> de functiedeclaratie geplaatst kan worden. Probeer het maar eens! In JavaScript worden stiekem alle functiedeclaraties, en ook variabeledeclaraties, helemaal bovenin de code gezet.</p>
<blockquote>
<p>&quot;Sir, you can't let him in here. He'll see everything. He'll see the big board!&quot;</p>
</blockquote>
<h2>Closures</h2>
<p>Closures maken gebruik van het feit dat er een functie scope bestaat. Wat ze doen is een of meerdere functies retourneren bij een bepaalde functieaanroep. Deze buitenste functie houdt dan alle variabelen geheim voor de globale scope.</p>
<pre><code>function telOpEnAlert(a) {
return function(b) {
alert(a + b);
}
}
var vijf = telOpEnAlert(5);
vijf(10); // 15
vijf(100); // 105
</code></pre>
<p>Wat bovenstaande code doet, is eigenlijk een vernuftig trucje. Eerst wordt de variabele <code>vijf</code> geïnitialiseerd door de functie <code>telOpEnAlert</code> aan te roepen. Deze functie neemt één argument aan, namelijk <code>a</code>. Deze variabele (in ons geval gezet op 5) zit in de functie scope van <code>telOpEnAlert</code>. Daarna retourneert het een anonieme functie die ook één argument aanneemt.</p>
<p>Deze anonieme functie wordt aangeroepen bij <code>vijf(10)</code>. Omdat de variabele <code>a</code> in de functie scope zit, is die bekend (namelijk 5). Door daarna het argument van de anonieme functie (in de eerst aanroep 10 en tweede 100) erbij op te tellen, kan hij een getal alerten.</p>
<p>Het grote voordeel van closures is dus dat de globale scope niet wordt vervuild, en dat dus scripts van meerdere makers niet conflicteren. Stel je voor dat iedereen de variabele <code>a</code> gebruikt in zijn of haar script.</p>
<blockquote>
<p>&quot;Well, boys, we got three engines out, we got more holes in us than a horse trader's mule, the radio is gone and we're leaking fuel and if we was flying any lower why we'd need sleigh bells on this thing... but we got one little budge on them Rooskies. At this height why they might harpoon us but they dang sure ain't gonna spot us on no radar screen!&quot;</p>
</blockquote>
<p>Nog een laatste voorbeeld, met een voorbeeld dat je in de praktijk kan gebruiken.</p>
<pre><code>function MijnLightBox(element) {
function roteerLinks() {
// code
geheim(1337);
// code
}
function roteerRechts() {
// code
}
function geheim(argument) {
// voer geheime code uit
alert(argument);
// voer meer geheime code uit
}
function maakHtmlAan() {
// maak enige HTML aan
}
return {
linksom: roteerLinks,
rechtsom: roteerRechts
};
}
var lightbox = MijnLightBox('element');
lightbox.linksom();
</code></pre>
<p>De overkoepelende functie <code>MijnLightbox</code> heeft twee functies die privé zijn: <code>geheim</code> en <code>maakHtmlAan</code>. Ze zitten namelijk in de functie scope van <code>MijnLightbox</code>. Ze kunnen alleen binnen die overkoepelende functie gebruikt worden.</p>
<p>Twee andere functies, <code>roteerLinks</code> en <code>roteerRechts</code>, worden geretourneerd met een object.</p>
<p>Door de functie <code>MijnLightbox</code> aan te roepen, krijg je een object terug met daarin die twee functies. Vervolgens kun je door <code>lightbox.linksom()</code> een van die functies gebruiken.</p>
<p>Overigens kunnen alle vier de functies bij het argument van de ouderfunctie: <code>element</code>. In ons geval doen we daar even niets mee, maar het kan wel.</p>
<blockquote>
<p>&quot;Gentlemen, you can't fight in here! This is the War Room.&quot;</p>
</blockquote>
<p><em>Fijne feestdagen!</em></p>
<h2>Over Arjan Eising</h2>
<p>/2011/12/arjan-eising.jpg
Front-end developer bij <a href="http://www.springest.nl/">Springest</a>. Bestuurslid en bijeenkomstenorganisator bij Fronteers. Kijkt te veel films.</p>
<p>Donatie: Fonds Psychische Gezondheid
<a href="http://www.psychischegezondheid.nl/">Fonds Psychische Gezondheid</a> zorgt voor onderzoek om de zorg voor mensen met psychische klachten te verbeteren, alsmede voorlichting voor patiënten en betrokkenen.</p>
</content>
</entry>
<entry>
<title>Content management door de ogen van een vrolijke front-end fröbelaar</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/door-een-frobelaar"/>
<updated>2011-12-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/door-een-frobelaar</id>
<content xml:lang="nl" type="html"><p>&quot;<a href="https://www.fronteers.nl/blog/2011/12/het-platform-bouwen" title="Het platform bouwen">Dat kan beter.</a>&quot; Zo dacht ik in 2004 ook toen ik het zoveelste op maat gemaakte BeheerDing in elkaar geknutseld had en ontevreden was met het resultaat.</p>
<p>Na het klooien met een Enterprise Content Management System (Magnolia 2.0) tijdens een stage begin 2005 en het klagen over de markup die mijn toenmalige blog (WordPress 1.5) uitkakte, had ik het door: &quot;Dit moet beter.&quot; Niet omdat het Web het nodig had, niet omdat <a href="https://www.fronteers.nl/blog/2011/12/clients-from-heaven" title="Clients from heaven">klanten</a> er om vroegen en niet omdat ik een gat in de markt zag, maar gewoon omdat ik het nodig vond. Ik was klaar met steeds opnieuw het wiel uitvinden en uitvinden dat ik aan het eind van de rit eigenlijk maar een klein rondje gemaakt had. Ik had een missie: het bouwen van een CMS dat ik steeds opnieuw weer in kon zetten en dat toch met me mee kon <a href="https://www.fronteers.nl/blog/2011/12/patronen-voor-de-groei" title="Patronen voor de groei">groeien</a> door de jaren heen. En iets wat perfect ingesprongen HTML uitspuwde natuurlijk, als ik dan toch bezig was. Wat volgt, is een vrij samengeraapt en toch onsamenhangend verhaal over mijn zoektocht naar het ideaal dat ik voor ogen had, en nog steeds heb, gecombineerd met de afsluiting van een in mijn ogen <a href="https://www.fronteers.nl/blog/2011/11/adventskalender" title="Adventskalender 2011">geslaagd idee van Arjan</a>.</p>
<p>Het allereerste probleem bij een CMS is natuurlijk de vraag: wat is content? Volgens Van Dale heeft het iets te maken met tevredenheid, maar als je eens rondvraagt bij een willekeurig aantal inhoudsbestuurders om je heen, merk je dat het eigenlijk niet echt heel leuk werk is, dat content managen. Vreemd, als je bedenkt dat <a href="http://www.amazon.com/Content-Management-Bible-Bob-Boiko/dp/0764573713/" title="http://www.amazon.com/Content-Management-Bible-Bob-Boiko/dp/0764573713/">de bijbel voor content management</a> qua diepgang en dikte <a href="http://www.amazon.com/Lord-Rings-J-R-R-Tolkien/dp/0618260587" title="The Lord of the Rings">de bijbel voor ringheren</a> benadert. Vanzelfsprekend, als je bedenkt dat een groot deel (van dat eerste boek) over <a href="https://www.fronteers.nl/blog/2011/12/waarom-standaarden-essentieel-zijn" title="Waarom standaarden essentieel zijn">XML</a> gaat. En verontrustend, als je bedenkt dat <a href="http://www.amazon.com/XML-Bible-Elliotte-Rusty-Harold/dp/0764549863/" title="XML 1.1 Bible">de bijbel voor validatienazi's</a> eenzelfde hoeveelheid pagina's telt. Ruim drieduizend bladzijden, waarvan slechts 33% <a href="https://www.fronteers.nl/blog/2011/12/dr-strangescope" title="Dr. Strangescope or: How I Learned to Stop Worrying and Love the Closure">filmmateriaal</a> bleek. Nee, al vrij snel wordt duidelijk dat je, met oog op het verlangen naar een vrolijkheidsfactor, de beerput die content heet fijn dicht moet laten.</p>
<p class="note">
Overigens heeft de werkversie van het laatste deel van The Lord of the Rings een tijdje 'Return of the Content 1.0' geheten, maar is in de jaren daarna door een werkgroep voor een andere naam gekozen; 'The Return of the King', afgekort tot LOTR5. Tegenwoordig spreekt men gewoon van 'The Living Hobbit', omdat in de praktijk blijkt dat deze hele ringzoekexercitie maar om één persoon gaat. Afijn, naast op het grote doek zien we deze geschiedenis in ons vege en vage vakgebied vandaag de dag mooi samengevat terug als het welbekende 'Content is King'. Als je je dus afvroeg waar dat vandaan kwam; je las het hier voor het eerst.
</p>
<p>Iedere stinkende hoop kan een hoop lekkerder gemaakt worden door het te prefixen met 'Web'. Developers zijn doorgaans door wereldvreemdheid opvallende mensen, maar zodra je er Web voor zet, zijn ze opeens mondig (kijk naar de rellen rondom <a href="http://24ways.org/">24 ways</a> op Twitter de afgelopen weken). Zet daar nog eens <a href="https://www.fronteers.nl/">Front-end</a> voor en je hebt een heel <a href="https://www.fronteers.nl/blog/2011/12/waarom-een-slicer-een-front-end-developer-is-geworden" title="Waarom een slicer een front-end developer is geworden">nieuw vakgebied</a> gecreëerd (met succes overigens, <em>hulde aan alle vrijwilligers</em> die hier aan hebben meegeholpen!). Ooit gehoord van <a href="http://nl.wikipedia.org/wiki/Cd-video">Cd-video</a>? Maak er <a href="https://www.fronteers.nl/blog/2011/12/html5-video-een-overzicht">Web-video</a> van en je hebt <a href="http://youtube-global.blogspot.com/2011/12/what-were-we-watching-this-year-lets.html" title="In total, there were more than 1,000,000,000,000 playbacks on YouTube this year.">een hit</a>. Met <a href="http://www.mturk.com/" title="Mechanical Turk">sommige workers</a> communiceer je helemaal niet, terwijl je met <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html">Web workers</a> wel <em>moet</em> praten. Zelfs bij het <em>Semantic Web</em> werkt dit fixeren op een pre: Web 3.0 is <em>zoveel</em> sexyer… Hmm, nee, inderdaad, bij deze strontvlieg gaat die vlieger niet op, naar mijn idee. Een mening die niet uit de lucht gegrepen is trouwens; wij HTML'ers snappen gewoon niet wat <em>hidden metadata</em> is, wat je er mee moet, en hoe je het behapbaar moet houden. Google <a href="http://support.google.com/webmasters/bin/answer.py?hl=en&amp;answer=146898" title="In general, Google won't display content that is not visible to the user.">heeft dit voor een groot deel door</a>, anderen [hebben andere dingen door](http://tech.burningbird.net/article/w3c-html-wg-decisions-hidden-longdesc-table-summary-and-myth-hidden-metadata &quot;There is no &quot;hidden&quot; metadata—all the data in the web page is &quot;visible&quot; to some audience.&quot;). Wellicht dat een Web Semantics 5 specificatie dit probleem ooit op gaat lossen. Of misschien lost het zichzelf wel op, zoals een <em>acidic</em> reactie op een post (die hieronder overigens gewoon welkom zijn).</p>
<p>De term content beperken tot het Web lijkt dus een keuze die leidt tot <a href="https://www.fronteers.nl/blog/2011/12/het-is-al-goud-wiens-cursor-blinkt" title="Het is al goud wiens cursor blinkt">goud en bling-bling</a>. Zelfs <a href="http://en.wikipedia.org/wiki/Web_content" title="Web content">Wikipedia</a> heeft hier een pagina over, dus dan is het waar—een <a href="http://nl.wikipedia.org/wiki/Drogreden" title="Drogreden">gedrochtreden</a>, ik weet het. Maar om het nog simpeler te maken: met Web content bedoel <em>ik</em> tastbare 'dingen' op een website, <a href="http://nl.wikipedia.org/wiki/Tautologie_%28stijlfiguur%29" title="Tenenkrommende tautologie is tenenkrommend!">zoals bijvoorbeeld</a> pagina's, nieuwsberichten, reacties, alinea's, tabellen, afbeeldingen, kaarten en video's. En dan heb ik het dus <em>niet</em> over <code>onze-voorpagina-met-achtergrondinformatie.html</code>, <code>Nieuws%20brief%20%28september%202011%29.doc</code>, <code>&lt;li&gt;First! [LOL](http://ragefac.es/23)&lt;/li&gt;</code>, <code>&lt;p&gt;ee&lt;p&gt;ee</code>, <a href="http://www.hotdesign.com/seybold/" title="Herinnert iemand zich deze nog?"><code>&lt;table&gt;&lt;tr&gt;&lt;td&gt;&lt;table&gt;</code>...</a>, <code>&lt;img src=&quot;please-4.gif&quot; alt=&quot;Please forgive!&quot;&gt;</code>, <code>&lt;iframe src=&quot;http://maps.yahoo.com/embed#q=Amsterdam&amp;amp;conf=1&amp;amp;start=1&amp;amp;lat=52.373089&amp;amp;lon=4.8933&amp;amp;zoom=12&amp;amp;mvt=m&amp;amp;trf=0&amp;amp;tt=&quot;&gt;&lt;/iframe&gt;</code> of <code>&lt;embed type=&quot;application/x-shockwave-flash&quot; src=&quot;https://www.youtube.com/v/XSGBVzeBUbk&quot; width=&quot;425&quot; height=&quot;350&quot; pluginspage=&quot;http://www.macromedia.com/go/getflashplayer&quot;&gt;</code>. Dat is het idee dat wij nerds van content hebben, maar waar je verder (<a href="https://www.fronteers.nl/blog/2011/12/acteurs-schilders-en-technici" title="Acteurs, schilders en technici">bijna</a>) <em>niemand</em> mee moet vermoeien. Die <em>implementatiedetails</em> (de tagkoek die voor ons gesneden soep is) zijn niet wat die dingen uniek en bruikbaar maken. Over een jaar wil je misschien de achtergrondinformatie ook op een andere pagina gebruiken, nieuwsberichten of reacties in een feed terug laten komen, tabulaire data als <a href="http://code.google.com/apis/chart/" title="Google Chart Tools">taartdiagram weergeven</a>, <a href="http://www.sitepoint.com/forums/showthread.php?428205-Frequently-Asked-Questions-about-HTML#q30" title="So what is a good text equivalent for a given image? That depends on the context in which the image is used! It's not like there is a single 'perfect' text equivalent for each image.">bepaalde plaatjes voor iets anders gebruiken</a>, overstappen naar Google Maps (omdat die fijn met <a href="https://www.fronteers.nl/blog/2011/12/3d-graphics" title="3D-graphics">3D</a> aan het pielen zijn), of in <a href="https://www.fronteers.nl/blog/2011/12/een-tik-op-de-neus" title="Een tik op de neus">één tik</a> de iPad ondersteunen. Sla de dingen dus zo klein en specifiek mogelijk op; je gaat hier later <a href="https://www.fronteers.nl/blog/2011/12/javascript-pret-met-alle-karakters-in-een-string" title="JavaScript-pret met alle karakters in een string">pret mee hebben</a>. Dit lijkt logisch, maar de eerste grote fout bij de meeste CMS'en is dat ze content en HTML als hetzelfde ding zien.</p>
<p>Het woord 'management' <a href="https://www.fronteers.nl/blog/2011/12/deferred-en-promise-in-jquery" title="Deferred en promise in jQuery">belooft</a> niet veel goeds. Hierbij denk ik, vrijblijvende knutselaar die ik ben, aan <a href="https://www.fronteers.nl/blog/2011/12/geharnast-javascript" title="Geharnast JavaScript">een keurslijf</a>, regeltjes naleven en een pedante stropdas dragen. Hoe erg ik ook gruwel van die ideeën; als ik als HTML-freak graag wil dat mijn open- en sluit-tags inspringen als perfecte pendanten en niet de spuigaten uit spuiten qua <a href="http://krijnhoetmer.nl/zooi/screenshots/out.png" title="Markup die ik ooit terugkreeg van een back-end partij die mijn HTML had geïmplementeerd.">hoeveelheid en nesteldrang</a>, zal er ergens een bepaalde vorm van structuur geforceerd moeten worden. Een web developer is <a href="http://vimeo.com/33650934" title="Chris Heilmann | The prestige of being a web developer | Fronteers 2011">geen magiër</a> en je kunt maar tot op zekere hoogte bijsturen. Volgens mij ligt een groot deel van het beheersbaar maken, voor zowel de developer(s) als degene(n) die met het CMS moet(en) gaan werken, bij de basis.</p>
<p>Je hebt vast wel eens te maken gehad met een gammele WYSIWYG-editor, die een hoop details wegpoetst en een website zogenaamd beheersbaar maakt. Het lijkt aan de oppervlakte een perfect concept en het verkoopt makkelijk. De structuur die wij kennen (HTML) wordt vertaald naar een structuur die de gebruiker kent (een visuele representatie van die HTML), en andersom. Voordat we ook maar een front-end hebben waar we trots op kunnen zijn, is er dus al een vertaalslag geweest. En met een beetje ongeluk zit je je in allerlei bochten te wringen om twee compleet verschillende omgevingen (de publieke website én het CMS) van misschien wel dezelfde CSS te voorzien. Respect voor iedereen die daar overdag mee bezig is!</p>
<p class="note">
Met WYSIWYG-editor hierboven bedoel ik trouwens een HTML-editor. Een editor als [Xopus](http://xopus.com/) is wat mij betreft iets totaal anders, aangezien die tot op het laagste niveau iets van de structuur weet, en dus de echte content beheert. Helaas zijn er maar weinig [goden](http://q42.nl/ "Q42, maar ik bedoel natuurlijk ook de mensen van Silk.") op de wereld, moeten de meeste baksels het gewoon met HTML doen en gaat er nog steeds een hoop fout.
</p>
<p>Tuurlijk, er zijn tegenwoordig perfecte editors die schone HTML teruggeven, maar ik heb ooit voor het meeste simpele model gekozen, waar ik geen spijt van heb. Een WYSIWYG-editor is niet eens mogelijk, aangezien bij de content <em>geen</em> HTML wordt opgeslagen en het CMS niet weet hoe bepaalde <em>dingen</em> verrijkt worden. Het uitleggen van deze kluif aan klanten lijkt misschien een grote, maar in de praktijk blijkt dit één van de makkelijkste punten te zijn. Het belang van een WYSIWYG-editor wordt volgens mij enorm overschat, terwijl het één van de grootste pijnpunten voor vrolijke front-enders is. Ik hoop dat <a href="https://www.fronteers.nl/blog/2011/12/klaar-voor-de-mobiele-tsunami" title="Klaar voor de mobiele tsunami">de mobiele tsunami</a> en misschien de <a href="https://www.fronteers.nl/blog/2011/12/webrichtlijnen-2-de-nieuwe-standaard" title="Webrichtlijnen 2: de nieuwe standaard">nieuwe Webrichtlijnen</a> dit de komende jaren duidelijk gaan maken, maar we moeten <a href="http://vimeo.com/27182344" title="Bryan Rieger | Muddling Through the Mobile Web | Mobilism 2011">loslaten en met betere oplossingen komen</a>. Het beheersbaar maken van <a href="https://www.fronteers.nl/blog/2011/12/responsive-images-een-experiment" title="Responsive images; een experiment">verschillende formaten afbeeldingen</a> op dezelfde pagina is een goed voorbeeld dat het WYSIWYG-probleem meteen al op de proef gaat stellen.</p>
<p>Eén van de grote voordelen van het hebben van aparte stukjes inhoud, is dat je per inhoudstype een specifieke <em>user interface</em> kunt aanbieden. Wat je inlevert aan What You See Is What You Get, krijg je ruimschoots terug bij What You Want Is What You'll Get. Een <a href="http://www.bvalmere.nl/nieuws/2011/12/speelweek-11">lijst met uitslagen</a>? Gewoon een begin- en einddatum vragen. Een <a href="http://www.bvalmere.nl/team-1/2011-2012">speelschema voor een team</a>? Een seizoen, afdeling en team vragen. Een <a href="https://www.fronteers.nl/congres/2011/venue">Google Map</a>? Een adres, zoals je die ook invoert op <a href="http://maps.google.nl/">maps.google.nl</a>. Het beheren van dit soort content kan niet veel makkelijker voor de gebruiker. En het later aankleden van die content ligt helemaal in handen van de front-end developer, die zo door de jaren heen met <a href="https://www.fronteers.nl/blog/2011/12/kijk-mama-zonder-afbeeldingen-grafische-elementen-maken-met-css" title="Kijk mama, zonder afbeeldingen! Grafische elementen maken met CSS">steeds minder markup</a> uit de voeten kan. Voor beide partijen is 'managen' opeens een leuk woord geworden.</p>
<p class="note">
Natuurlijk zijn er ook andere voorbeelden te bedenken, die lastiger zijn. Complexe tabellen onderhouden is nog steeds een ramp, niet alleen in een online editor, maar eigenlijk ook in Excel. Aan de andere kant kun je stellen dat als een tabel te complex is om te onderhouden, deze waarschijnlijk ook te complex is om aan de voorkant te begrijpen. [Dezelfde uitleg](http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-March/014245.html "[whatwg] several messages about tables and related subjects") wordt ook gegeven als de discussie over het via extra markup (`headers=""`, `scope=""`, `summary=""`, etc.) toegankelijk maken van tabellen weer eens oplaait binnen de HTML Working Group. De informatie opsplitsen lijkt dus sowieso geen gek idee, en ik steek mijn tijd liever in het maken van een begrijpelijke front-end, dan in het maken van de perfecte tabel-editor.
</p>
<p>De vertaling naar ons favoriete formaat (HTML, voor de duidelijkheid) is makkelijk; ieder type content krijgt van de server een stukje logica mee wat 'm in een kaal jasje steekt. Alle <em>alinea's</em> krijgen een <code>&lt;p&gt;</code>- en <code>&lt;/p&gt;</code>-paartje. Iedere <em>lijst</em> wordt verpakt in een <code>&lt;ul&gt;</code> en iedere regel van die lijst krijgt een <code>&lt;li&gt;</code>-omhulsel voor z'n kiezen. Een <em>notitie</em> krijgt een <code>&lt;p class=&quot;note&quot;&gt;</code>, een blok code krijgt <code>&lt;pre&gt;&lt;code&gt;…&lt;/code&gt;&lt;/pre&gt;</code>, enz. Grootste voordeel hiervan: dit maakt de belofte <a href="http://www.csszengarden.com/" title="css Zen Garden: The Beauty in CSS Design">die CSS ooit maakte</a> beter mogelijk. Bij een redesign van een site kun je bepaalde inhoud net even wat andere HTML <a href="https://www.fronteers.nl/blog/2011/12/front-end-meta-languages" title="Front-end meta languages">laten genereren</a>. En dat is nodig, want HTML en CSS zijn <em>niet</em> los van elkaar te zien, ondanks dat we onszelf continu voorhouden dat dit wel zo is. &quot;Ja, maar, heiden! Als ik m'n stylesheet weggooi in Firebug, kan ik nog steeds een duidelijke structuur zien. En dat is omdat ik semantische HTML gebruik. You suck.&quot; Nee, dat is omdat je browser dan eindelijk 'ns <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-css-user-agent-style-sheet-and-presentational-hints" title="The CSS user agent style sheet and presentational hints">haar eigen schitterende stylesheet</a> mag laten zien.</p>
<p class="note">
Ja, ik heb wel eens van XSLT gehoord. En nee, ik ken het niet goed genoeg om het een fijne techniek te vinden. Van de extra complexiteit die deze laag introduceert, blijf ik zo ver mogelijk vandaan. Vooral omdat ik met XML en XSLT geen enkel probleem oplos, maar alleen maar voor buzzword compliance zou gaan. In de korte tijd die we hebben op deze aardkloot wil ik de dingen zo simpel mogelijk houden. Daarnaast, stel dat we ooit Hixie op [ons congres](/congres "Fronteers Conference") krijgen, dan wil ik hem zonder schaamte aan kunnen kijken.
</p>
<p>Om al die kleine vertaalblokjes overzichtelijk te houden, heb ik ooit gekozen om mijn CMS op één server te laten draaien, met een gedeelde codebase voor al mijn klanten. Aangezien elk van de ongeveer 100 sites die er nu op draaien het concept 'Alinea' implementeert, is het logisch om de drie regels code die een <code>&lt;p&gt;</code> genereert te delen. En vindt een [bepaalde klant](http://37signals.com/svn/archives/001053.php &quot;&quot;Hire&quot; the right clients&quot;) het nodig om <a href="http://enterprise-html.com/" title="Enterprise HTML - Provides proven high performance, enterprise-level and scalable HTML tips and best practices.">zich groter voor te doen</a> dan 'ie is, dan is het mogelijk om specifiek voor diegene een nieuwe vertaling te maken, die voor <code>&lt;div class=&quot;paragraph&quot;&gt;</code> zorgt ;) Zonder flauwekul: ook deze keuze heeft me veel vrolijkheid opgeleverd, naast het feit dat het lekker <a href="https://www.fronteers.nl/blog/2011/12/scalable-vector-graphics-en-responsive-web" title="Scalable Vector Graphics en responsive web">schaalt</a>. Ja, je kunt waarschijnlijk meer geld verdienen door klanten een SLA aan te smeren en de zoveelste security update tegen betaling door hun strot te duwen. Genoeg Joomla-boeren die hier hun brood mee verdienen. Niets mis mee natuurlijk, maar ik doe er niet aan mee. Niet omdat ik denk dat Vespasianus gelijk had toen 'ie tijdens het zeiken een goed idee kreeg, maar omdat ik niet Caligula achterna wil qua krankzinnigheid; ik wil leuk werk doen. Wat dat betreft zijn wij developers wel magiërs; we <em>kunnen</em> ons eigen werk beïnvloeden.</p>
<p>Los van de kleine blokjes content waar wij tags voor kennen, zijn er ook grotere concepten, zoals pagina's, secties, nieuwsberichten en producten. Deze moeten ook allemaal zonder moeite uitgelegd kunnen worden aan iemand, dus het is het handigst om zo dicht mogelijk bij het tastbare ding te blijven en zoveel mogelijk structuur af te dwingen. Zo hangt een pagina bij mij altijd onder een andere pagina, en komt deze altijd voor of na een andere pagina. Een regel die het makkelijk maakt om menu's te genereren en <a href="http://css-tricks.com/guidelines-for-uri-design/" title="Guidelines for URI Design">URLs netjes leesbaar en gestructureerd</a> te houden. Bij nieuwsberichten is er bijvoorbeeld altijd een auteur en datum, bij producten altijd een naam en prijs. Probeer per concept een stramien te bedenken waarin je net genoeg vrijheid biedt en al het andere dichttimmert. En hou daarbij rekening met het veranderlijke karakter van het web; er gaat <em>sowieso</em> ooit nog wat overhoop gehaald worden. Paginastructuren worden omgegooid, producten krijgen nieuwe eigenschappen, etc. Een CMS dat hier niet <a href="https://www.fronteers.nl/blog/2011/12/learn-you-a-flexbox-for-great-good" title="Learn you a Flexbox for Great Good!">flexibel</a> op kan inspelen, is niet gemaakt voor het Web. Iets wat niet betekent dat een CMS <a href="http://nl.wikipedia.org/wiki/Paretoprincipe" title="Paretoprincipe">alles</a> moet kunnen.</p>
<p class="note">
Een belangrijk deel van veel CMS'en is workflow management en gebruikersrechten. Ik ben zelf van mening dat deze vooral in het leven zijn geroepen om bepaalde mensen zich niet verantwoordelijk te hoeven laten voelen voor het werk dat ze doen, of om een organisatie een gevoel van veiligheid te geven. Ik hoop de komende jaren wat milder te worden, maar voorlopig zit het er niet in. Ook hier geldt voor mij de complexiteit die het oplevert, maar ook het vertrouwen in het goede van de mens. Geef iemand de controle over iets en de kans is vrij groot dat diegene zijn of haar best daar ook voor gaat doen. In de afgelopen maand hebben een paar schrijvers bijvoorbeeld gevraagd of ze toegang mochten krijgen tot het CMS achter deze site, zodat ze zelf nog hun post konden aanpassen, wat perfect werkt.
</p>
<p>Een hoop ontwikkelaars zijn nog steeds <a href="https://www.fronteers.nl/blog/2011/12/welkom-op-het-audiologische-internet" title="Welkom op het Audiologische Internet">gillend</a> op zoek naar het ideale CMS, en een hoop CMS'en proberen alles te doen, tot aan <a href="http://cms.com.au/" title="Coffee Machines Services">koffie</a> zetten toe. <a href="https://www.fronteers.nl/blog/2011/12/closure-tools" title="Closure Tools">Volgens mij</a> bestaat die combinatie niet, en moeten we ons gaan beperken tot plezier hebben in het werk dat we doen. Ik weet dat ik met mijn geknutsel nooit de grote massa ga bereiken (<a href="http://gall.qontent.nl/">een</a> <a href="https://www.fronteers.nl/blog/2011/12/prototype-in-javascript" title="Prototype in JavaScript">prototype</a> daargelaten), maar ik weet ook dat ik het heerlijk vind om te neuzelen in de marge die HTML-indenting heet. De realiteit is toch dat alles wat we online doen over een paar jaar weer compleet vernieuwd wordt.</p>
<p>Het enige nadeel van werken op het Web? Het kan <em>altijd</em> beter. En dat is ook meteen het voordeel.</p>
<p>Aan iedereen die deze maand heeft meegelezen: bedankt voor je overlevend overlezend vermogen. Beleef de komende dagen feestelijk en het nieuwe jaar vooral gelukkig!</p>
<h2>Over Krijn Hoetmer</h2>
<img src="https://www.fronteers.nl/_img/2011/12/krijn-hoetmer.jpg" alt="Foto van krijn hoetmer uit 2011" class="floating-portrait" />
Krijgt door dit soort stukjes _alweer_ zin om [kronkels.net](http://kronkels.net/) nieuw leven in te blazen, maar gaat er waarschijnlijk niet aan toekomen door tijdgebrek. Iets wat in 2012 gaat veranderen.
<p>Donatie: Wikipedia
Omdat deze site het bewijs is dat je nooit uitgeleerd kunt zijn.</p>
</content>
</entry>
<entry>
<title>Closure Tools</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/closure-tools"/>
<updated>2011-12-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/closure-tools</id>
<content xml:lang="nl" type="html"><p>Misschien heb je er van gehoord, misschien ook niet, maar Google zelf is er in ieder geval trots op. Het is de onderliggende (client-side) kracht van Gmail, Google Docs, Google Maps en het meest recente Google Plus! Closure Tools zijn een set tools bedoeld om client-side ontwikkeling wat te vergemakkelijken danwel te professionaliseren.</p>
<p>Voordat we inhoudelijk beginnen, een kleine disclaimer: het gebruik van deze tools is voor kleine tot medium websites overkill. Verwacht niet een drop-in replacement voor je website thuis die in elkaar gezet is met jQuery en/of waarbij al je JavaScript source minified is met de YUI minifier. Aan deze toolset zit een noemenswaardige leercurve en tijd die benodigd is voor het opzetten van deze tools voor een project ligt wat hoger vergeleken met andere tools / libraries. Dat gezegd, je krijgt er ook wel wat voor terug ;)</p>
<h2>De Tools</h2>
<p>Je zult je wellicht al afgevraagd hebben; waar bestaat deze toolset dan uit? Dat zijn de volgende tools:</p>
<ul>
<li><em>Closure Compiler</em>: Een JavaScript to JavaScript compiler (géén minifier!) waar een hoop optimizes in worden gedaan, zoals dead-code elimination, code inlining en chaining, maar waar ook een aantal handige features in zitten, zoals module-splitting en compile-time constants.</li>
<li><em>Closure Library</em>: Geïnspireerd door Dojo, een volledige library met browser-abstraction en een heleboel widgets. Wat deze library eigenlijk nog wel het meest uniek maakt, is het geïmplementeerde event model wat zeker in JavaScript driven web applications zeer nuttig gebruikt kan worden.</li>
<li><em>Closure Templates</em>: Templates die zowel server- als client-side kunnen worden gebruikt. De meest relevante keywords zijn: client-side performance, localisation, language-neutral en secure.</li>
<li><em>Closure Stylesheets</em>: Deze zijn niet door Google zelf gereleased, maar door een ex-Google medewerker gemaakt als aanvulling op de bestaande toolset waarin o.a. CSS constanten en CSS-class renaming worden geïmplementeerd.</li>
</ul>
<p>Elke tool is een op zichzelf staand project en ook zo te gebruiken, maar dat is eigenlijk niet aan te raden. De kracht zit hem juist in hoe deze tools samenwerken. De Library is bijvoorbeeld geweldig, maar gewoon veel te groot om op te nemen in je website als je de Compiler niet gebruikt. Andersom geldt ook, de Compiler is geweldig, maar je behaalt niet de volledige potentie als de code die je compiled niet volledig voor de compiler is gedocumenteerd. Zodoende raad ik je dan ook altijd aan op z’n minst de Library en de Compiler gecombineerd te gebruiken. De introductie tot de Closure Tools zal in deze post beperkt blijven tot de Compiler en de Library.</p>
<h2>Closure Compiler</h2>
<p>Voor de meeste van jullie zal dit eigenlijk het meest interessante onderwerp zijn. Voordat we dieper ingaan op de Compiler, een kleine achtergrond. De Compiler ondersteunt meerdere niveaus van ‘Compiling’. Er is een Simple mode, die wat meer in de buurt komt van een minifier en er is een Advanded mode, die alle features van de Compiler volledig benut. In dit artikel zal ik te allen tijde uitgaan van de Advanced mode.</p>
<p>Wanneer je JavaScript gaat compilen wordt ervan uitgegaan dat je in een closed environment zit. Met andere woorden, alle JavaScript die er bestaat voor jouw project, zit binnen het bereik van de compiler. Als uitzondering is er wel een mogelijkheid om ‘externals’ te definiëren waarmee aangegeven kan worden welke JavaScript-functies en/of variabelen bestaan buiten de compiler. Omdat de compiler letterlijk kennis heeft van alle JavaScript kan deze zeer rigoureus te werk gaan. Een klein voorbeeld:</p>
<pre><code>function a() { return 'Hello'; }
function b() { return 'World'; }
alert(a() + ' ' + b());
</code></pre>
<p>Als je dit leest, zou je je kunnen afvragen, worden de functies ‘a’ en ‘b’ nog ergens anders gebruikt? Zo nee, dan zijn deze functies zelf namelijk behoorlijk overbodig. De compiler denkt hier exact hetzelfde over, juist omdat de compiler kennis heeft van de gehele omgeving maakt de compiler van dit voorbeeldje het volgende:</p>
<pre><code>alert(&quot;Hello World&quot;);
</code></pre>
<p>Probeer dit voorbeeldje zelf maar eens (vergeet niet Advanded mode aan te zetten): <a href="http://closure-compiler.appspot.com/home">http://closure-compiler.appspot.com/home</a></p>
<h2>Annotations voor de Compiler</h2>
<p>Zoals duidelijk mag zijn, kan de compiler best handig zijn. Om te zorgen dat jouw code zo goed mogelijk door de compiler kan worden geparsed dien je je code te voorzien van JSDoc. Met behulp van de juiste documentatie kan je er namelijk voor zorgen dat er bijvoorbeeld een OO-model wordt verplicht in je code. De compiler zal ervoor zorgen dat alle code dat een private member van je class probeert te benaderen een compiler warning zal geven.</p>
<p>Een andere mooie feature is het annotaten van constanten. Door met constanten te werken kan je heel mooi specifieke JavaScript-builds maken voor specifieke scenario’s. Het beste voorbeeld hiervan is eigenlijk hoe de Closure Library constanten gebruikt. In de Library zijn namelijk constanten gedefinieerd voor browser detection. Stel je target alleen maar Chrome en Firefox voor je applicatie, dan kan je een aantal constanten overriden door wat extra opties mee te geven aan de Compiler. Doordat alle code met constanten werkt, kan de compiler met zijn dead-code elimination alle IE related code strippen in jouw build. Dat scheelt aardig wat ruimte.</p>
<p>De laatste grove categorie van annotations is type hinting. JavaScript is geen type-safe language. Dit is aan de ene kant handig, omdat je heel flexibel kan zijn, maar daartegen soms ook wat frustrerend. Er zijn genoeg momenten als programmeur waar je gewoon wilt weten wat je binnen krijgt. De compiler lost dit op door je de mogelijkheid te geven om in je JSDoc het type van je variabelen of parameters te declareren. De compiler zorgt ervoor dat je daadwerkelijk alleen deze types binnenkrijgt. Is dit niet het geval, zal er weer een compiler warning worden gegooid. Een overzichtje van alle annotations kan je terugvinden op: <a href="http://code.google.com/intl/nl-NL/closure/compiler/docs/js-for-compiler.html">http://code.google.com/intl/nl-NL/closure/compiler/docs/js-for-compiler.html</a></p>
<h2>Closure Library</h2>
<p>De Closure Library is wellicht het meest wennen voor verfijnd jQuery-gebruikers, danwel alle andere ontwikkelaars die gebruik maken van JavaScript libraries waar alles voor je wordt geregeld op de achtergrond. De syntax van deze library is een stuk meer verbose dan de meesten van jullie gewend zullen zijn. Persoonlijk vind ik dit een groot voordeel. De meeste code die je zult schrijven is een stuk begrijpbaarder dan code die jQuery gebruikt waarbij 20 calls aan elkaar zijn gechained. Bovendien wordt overhead veroorzaakt door bestandsgrootte tenietgedaan door het gebruik van de compiler.</p>
<p>Wat belangrijker is, is hoe uitgebreid deze library is. Het is voorzien van vele UI widgets, het kent de standaard CSS selectors, er zit een abstractie in voor client-side data storage (HTML5 session storage en IE userdata), er zit functionaliteit in voor encryptie, animaties, internationalisatie, formatting, client-side databases, Ajax calls, etc, etc.</p>
<p>De meest interessante feature binnen deze library is eigenlijk de event handling. Zoals de meeste libraries zit er een abstractie in om browser events op een abstracte wijze af te vangen. Wat echter interessanter is, is dat deze abstractie meteen geldt voor JavaScript-objecten. De Closure Library heeft een interface blootgesteld die je kan extenden, waarmee je volledige events kan gooien vanuit je JavaScript-objecten. Om wat beter te illustreren hoe dit in elkaar zit eerst een korte introductie over hoe je naar browser events luistert met behulp van de Closure Library.</p>
<h2>Browser events</h2>
<p>Het luisteren naar browser events gebeurt met <code>goog.events.listen</code>. De specificatie van deze functie is als volgt:</p>
<pre><code>/**
* @param {EventTarget|goog.events.EventTarget} src
* @param {string|Array.} type
* @param {Function|Object} listener
* @param {boolean=} opt_capt
* @param {Object=} opt_handler
*/
goog.events.listen = function(src, type, listener, opt_capt, opt_handler);
</code></pre>
<p>De namen van de argumenten spreken grotendeels voor zich. Een punt dat misschien opvalt, is dat de bron van het event (<code>src</code>) niet alleen een standaard DOM EventTarget hoeft te zijn, maar ook een <code>goog.events.EventTarget</code> mag zijn. Dit zorgt voor de eerder genoemde flexibiliteit en het gebruiken van dit event-systeem voor veel meer dan alleen events vanuit de DOM. Dit wordt verderop toegelicht.</p>
<p>De <code>listener</code> hoeft niet een functie te zijn, maar mag ook een willekeurig object zijn, als het maar de methode <code>handleEvent</code> bevat, die het event afhandelt.</p>
<p>De <code>opt_capt</code> geeft (optioneel) aan of er capturing of bubbling moet worden toegepast. Closure zorgt ervoor dat capturing ook in oudere IE browsers toegepast kan worden.</p>
<p>De <code>opt_handler</code> methode (ook optioneel) is een mooie uitbreiding van het W3C-model, dat het mogelijk maakt om aan te geven waar het keyword <code>this</code> naar verwijst in de functie die het event afhandelt.</p>
<h2>Eigen EventTargets</h2>
<p>Zoals eerder aangegeven, kan er dus geluisterd worden naar zowel browser-events als eigen JavaScript-events. Door simpelweg de interface <code>goog.events.EventTarget</code> te extenden in een van je eigen classes, krijgt je JavaScript class events. Net zoals bij DOM events kan je hier nu listeners aan koppelen of verwijderen. Hoe dit nou volledig in elkaar zit, is meer een geval van 'een voorbeeld zegt meer dan een duizend woorden'. Hierbij een klein voorbeeldje van een Twitter class die een event dispatched iedere keer als er nieuwe berichten zijn.</p>
<pre><code>goog.provide('example.Twitter');
goog.provide('example.Twitter.EventType');
goog.require('goog.events');
goog.require('goog.events.EventTarget');
/**
* @constructor
* @extends {goog.events.EventTarget}
*/
example.Twitter = function() {
goog.events.EventTarget.call(this);
};
goog.inherits(example.Twitter, goog.events.EventTarget);
/**
* Haalt nieuwe tweets op. Als die er zijn wordt een event gedispatched van het
* type example.Twitter.EventType.NEW_TWEETS.
*/
example.Twitter.prototype.poll = function() {
var messages = this.getNewMessages();
if (messages.length) {
this.dispatchEvent(example.Twitter.EventType.NEW_TWEETS);
}
};
/** @enum {string} */
example.Twitter.EventType = {
NEW_TWEETS: goog.events.getUniqueId('new_tweets')
};
</code></pre>
<p>En uiteraard, een bijhorende listener:</p>
<pre><code>// twitter is van het type example.Twitter.
twitter.addEventListener(
example.Twitter.EventType.NEW_TWEETS,
function() {
var twitter = /** @type {!example.Twitter} */ (e.target);
var count = twitter.getUnreadCount();
goog.dom.setTextContent(goog.dom.getElement('unread-count'), count);
}
);
</code></pre>
<h2>Krachtige combinatie</h2>
<p>Het blijft lastig om zo’n uitgebreide toolset in een keer te introduceren, maar zoals je wellicht al hebt gemerkt, zijn de mogelijkheden eindeloos. Mocht je in de nabije toekomst een project hebben waarbij flink wat JavaScript nodig is, duik dan snel wat dieper in deze toolset. Het is een hele opluchting om er mee te mogen werken. Iedereen die hiermee aan de slag wil, kan ik dan ook van harte het boek ‘Closure: The Definitive Guide’ aanraden.</p>
<h2>Over Johan Schuyt</h2>
<img src="https://www.fronteers.nl/_img/2011/12/johan-schuyt.jpg" alt="Foto van johan schuyt uit 2011" class="floating-portrait" />
Johan is werkzaam bij [TransIP](https://www.transip.nl/) waar hij zich voornamelijk bezighoudt met alle client-side ontwikkelingen. Ook zijn er veel blog posts van hem te vinden op op [blog.transip.nl](http://blog.transip.nl/). Van tijd tot tijd zal hij wat ventileren op zijn Twitter account [@johansglock](https://twitter.com/johansglock).
<p>Donatie: <a href="http://www.redeenkind.nl/">Red een kind</a>
Kinderen zijn de toekomst, en verdienen een zorgeloos te kunnen opgroeien. Niks is meer belangrijk, vandaar dat ik graag Red een kind ondersteun.</p>
</content>
</entry>
<entry>
<title>Scalable Vector Graphics en responsive web</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/scalable-vector-graphics-en-responsive-web"/>
<updated>2011-12-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/scalable-vector-graphics-en-responsive-web</id>
<content xml:lang="nl" type="html"><p>Het blijft grappig om te zien hoe print en web verder van elkaar verwijderd zijn dan ooit tevoren. De evolutie van het web is op zijn minst spectaculair te noemen. Van fluid designs met animated gifs en flashy backgrounds langsheen de fixed dimension websites die langzamerhand aan het uitsterven zijn. Printdesign heeft altijd genoten van de vaste afmetingen die het gedrukte eindwerk met zich meebrengt en het gebrek aan interactieve elementen, terwijl webdesigners meegroeiden met de meest courante schermresolutie. Jarenlang was 960 pixels de vaste waarde, maar 1 apparaat zette deze wereld op zijn kop. De revolutie die de iPhone teweeg bracht in het mobiele weblandschap was nooit gezien en de kloof tussen web en print design werd voor de zoveelste keer groter. Toch hebben deze één gemeenschappelijk überformaat: <em>SVG</em>.</p>
<p>Toen SVG het levenslicht zag en uiteindelijk een W3 recommendation werd in september 2001 bleef het in de schaduw staan van de gigant Macromedia Flash. Doorheen de tijd groeide Flash verder uit, niet echt verwonderlijk aangezien het naast vector graphics ook kon worden gebruikt voor video, audio, animaties, et cetera. Flash bleef jaren koning éénoog in het land der blinden, want terwijl de browsers bleven strijden over universele formaten, HTML- en CSS-implementaties en codecs kon hun SWF-formaat aan de hand van een plugin op ieder platform doen waarvoor het bedoeld was. Opnieuw was het de iPhone die een einde maakte aan de opmars van Flash. Prompt werden de schijnwerpers gericht op de open webstandaarden die video en audio mogelijk maakten, animaties met behulp van JavaScript of zelfs via CSS3!</p>
<p>Een nieuw tijdperk brak aan en de vaste waarden vervaagden, aangezien iedereen altijd en overal via eender welke mobiele telefoon, tablet, computer, televisie en spelconsole het wereldwijde web kon verkennen. Responsive web werd een buzzword, maar in tegenstelling tot Web 2.0 wel eentje met betekenis. Er werden boeken geschreven en presentaties gegeven over hoe we websites konden bouwen die zich aanpasten aan de screen estate en de mogelijk tragere verbinding van de bezoeker.</p>
<p>Helaas wordt SVG vandaag de dag soms wel vernoemd, maar toch wordt er nog te weinig gebruik gemaakt van dit formaat. De mogelijkheden zijn gigantisch en kunnen in de hedendaagse responsive approach een aantal voordelen bieden aan ontwikkelaars.</p>
<h2>Het is scalable</h2>
<p>Laat dat nou net de aanpak van responsive zijn. Websites die meeschalen volgens de beschikbare resolutie. Meeste logo's en iconen zijn PNG of GIF images die dan meestal meermaals worden opgeslagen omdat ze in verschillende formaten nodig zijn. Waarom dan geen vectorformaat gebruiken die van nature uit haarscherp meeschaalt?</p>
<h2>Het heeft een kleine bestandsgrootte</h2>
<p>Aangezien SVG een tekstbestand is, blijft de bestandsgrootte redelijk beperkt in tegenstelling tot GIF- of PNG-varianten. Als we dan nog eens aparte images gebruiken voor mobile, tablet, desktop, etc. hebben we hier tegenover maar één SVG file nodig.</p>
<h2>Het is makkelijk te bewerken en te stijlen</h2>
<p>Een kleur, border of tekst aanpassen is zo gepiept! Het SVG bestand openen in je favoriete text editor is genoeg, je hebt met geen grafisch programma van doen!</p>
<h2>Het is animeerbaar</h2>
<p>Omdat het een DOM heeft, kan je deze aanspreken met JavaScript om bepaalde zaken aan te passen. Infaden en resizen zijn bijvoorbeeld een fluitje van een cent.</p>
<h2>Overtuigd?</h2>
<p>Het klinkt allemaal veelbelovend en te mooi om waar te zijn, en jammer genoeg is het dat ook een klein beetje. De meeste moderne browsers ondersteunen SVG native, maar voor sommige zal er toch een fallback voorzien moeten worden. Godzijdank zijn er hier diverse libraries voor, maar ééntje in het bijzonder springt hier toch wel uit: <a href="http://raphaeljs.com/">RaphaelJS</a>.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/browsersupport-svg.png" alt="" /></p>
<p>Een overzicht van de browsersupport (bron: <a href="http://www.codedread.com/svg-support.php">http://www.codedread.com/svg-support.php</a>).</p>
<p>Op de website van RaphaelJS kan je tal van voorbeelden vinden en een uitgebreide documentatie. Er is zelfs een aparte <a href="http://g.raphaeljs.com/">gRaphaelJS</a> library speciaal voor grafieken. Bar-, line- en piecharts zullen nog nooit zo mooi meeschalen volgens het medium! Aangezien dit niet echt een hands-on artikel is wil ik wel nog meegeven dat het de moeite waard is om eens wat demo's te bekijken en misschien zelf eens te spelen met de mogelijkheden.</p>
<p>Hopelijk heb ik jullie een beetje kunnen overtuigen om in toekomstige projecten SVG te overwegen. Er zijn reeds enkele leuke sites die hier gebruik van maken zoals <a href="http://sleepstreet.be/">sleepstreet.be</a>, <a href="http://www.assekloppendhart.be/wanneer/">Asse Kloppend hart</a> en <a href="http://emacsformacosx.com/">Emacs for Mac OS X</a>, maar echte mannen gebruiken VI ;-)</p>
<h2>Over Jochen Vandendriessche</h2>
<img src="https://www.fronteers.nl/_img/2011/12/jochen-vandendriessche.jpg" alt="Foto van Jochen" />
Freelance front-end developer onder de naam builtbyrobot. Viel als kind in een vat Red Bull en bijgevolg gigantisch energiek. Overtuigde Apple fanboy, houdt van open webstandaarden en een goede portie JavaScript. Twittert als [@joggink](https://twitter.com/joggink). Blogt ook van tijd tot tijd eens op [joggink.com](http://joggink.com/) en dan voornamelijk over front-end gerelateerde zaken en slechte internet providers. Is momenteel bezig aan een web based SVG editor, genaamd [Willistrator](http://willistrator.com) die naast SVG RaphaelJS kan genereren.
Favoriete slogan: 'Develop for the best, optimize for the rest!'
<p>Donatie: <a href="http://www.think-pink.be/">Think pink</a>
Vier jaar geleden, op 10 december 2007, verloor mijn moeder een vijf jaar durende strijd tegen borstkanker. Vijf moeilijke jaren met af en toe een sprankeltje hoop, die helaas de kop werd ingedrukt door uitzaaiingen van deze agressieve tumor. Hopelijk kan deze donatie iets uitmaken aan de levensverwachting van andere vrouwen, moeders, dochters.</p>
</content>
</entry>
<entry>
<title>Prototype in JavaScript</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/prototype-in-javascript"/>
<updated>2011-12-21T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/prototype-in-javascript</id>
<content xml:lang="nl" type="html"><p>Op zich is het heel makkelijk om met JavaScript te beginnen. Maar als je dan wat verder gaat kijken wordt het al snel moeilijk. De meeste mensen lijken te struikelen over closures, context en prototype. Ik wil in deze post graag prototype behandelen en eens zien of ik het een beetje kan verhelderen. Ik zal daarbij de termen lekker in het Engels houden, want met vertalen introduceer je alleen maar (nog meer) verwarring.</p>
<p>Class inheritance in JavaScript, waarbij een object de eigenschappen erft van een ouder, wordt geregeld via de &quot;prototypal chain&quot;. Dat betekent dat er een keten van geheime links is van het kind naar de ouder(s). Maar die link gaat niet direct naar de ouder, maar eigenlijk naar de &quot;prototype property&quot; van de ouder, ook wel &quot;het prototype object&quot; genoemd. Aan de bovenkant van (bijna) iedere keten staat de globale variabele met de naam &quot;<code>Object</code>&quot;. Dat is soms een beetje verwarrend, omdat je ook praat over objecten.</p>
<p>Oké, dus hoe werkt het nou? Iedere functie die je zelf aanmaakt, heeft automatisch een property die &quot;<code>prototype</code>&quot; heet. Dat bevat een normaal object, exact zoals je hem krijgt met <code>{}</code>. Tot dusver geen magie (<em>ok, stiekem wel, misschien dat je aan het einde van dit artikel kunt bedenken waarom!</em>). Je kan properties toevoegen aan dit <code>prototype</code> object of de property gewoon vervangen…</p>
<pre><code>function Foo(){}
typeof Foo.prototype; // &quot;object&quot;
Foo.prototype.x = 5;
Foo.prototype.meh = function(){ alert(&quot;foo&quot;); };
Foo.prototype = {
x: 6,
y: 7
};
</code></pre>
<p>De magie begint als we een zogenaamde nieuwe instance maken met onze functie (oftewel object <code>Foo</code>). Dat doen we met het <code>new</code> keyword.</p>
<pre><code>var foo = new Foo();
</code></pre>
<p>We hebben nu een nieuw object <code>foo</code> dat erft van zijn ouder, <code>Foo</code>. Dit kan je controleren:</p>
<pre><code>foo instanceof Foo; // true
</code></pre>
<p>De magie zit hem in een verborgen property van het kind, <code>foo</code>. Deze bevat namelijk een directe link naar de huidige waarde van <code>Foo.prototype</code>. Dat wil zeggen, de waarde van <code>Foo.prototype</code> op het moment van het instantiëren van het kind. Als de waarde van <code>Foo.prototype</code> wijzigt dan heeft dat ook onmiddellijk het effect dat het kind niet meer wijst naar <code>Foo.prototype</code> (maar naar de referentie van het vorige object, want deze gaat niet onmiddellijk verloren). Let op:</p>
<pre><code>function Foo(){}
var foo = new Foo(); // nieuw kind
foo instanceof Foo; // true
// nu vervangen we Foo.prototype
Foo.prototype = {};
// en dat betekent dat...
foo instanceof Foo; // false
</code></pre>
<p>Dat betekent dus niet dat de verborgen link nu verbroken is! Nee, de <code>instanceof</code> &quot;operator&quot; kijkt alleen of het object waar de geheime link van de linkerkant naar wijst ook inderdaad de waarde is van de prototype property van de rechterkant. Zodra dat niet meer het geval is, zoals in de laatste drie regels van het vorige voorbeeld, zegt <code>instanceof</code> dat het niet meer een kind is. En daar zit wat in, want alle nieuwe properties die aan <code>Foo.prototype</code> worden toegekend worden niet langer doorgegeven aan het (bestaande) kind <code>foo</code>. Wel aan nieuwe kinderen, die dus gemaakt zijn na de toekenning. Maar als oudere kinderen al dingen hadden geërfd worden deze niet gedeeld met de nieuwe kinderen. Hmm.</p>
<pre><code>var oud = new Foo;
Foo.prototype = {};
var nieuw = new Foo;
oud instanceof Foo; // false
nieuw instanceof Foo; // true
</code></pre>
<p>Ok, dat is allemaal wel leuk en aardig, maar wat erf je nou eigenlijk? Hah, goede vraag! We erven en delen de waardes van de properties van het prototype object. Laat die maar eens bezinken, want dat is de kern van het verhaal. Let op:</p>
<pre><code>Foo.prototype.x = 5;
var foo = new Foo();
foo.x; // 5, erft van Foo.prototype
Foo.prototype.x = 6;
foo.x; // 6, wijst nog steeds naar Foo.prototoype
foo.x = 10;
foo.x; // 10, hebben we net toegekend...
Foo.prototype.x; // 6, deze hebben we niet gewijzigd
Foo.prototype.x = 12;
foo.x; // ... 10!
</code></pre>
<p>Wat is er gebeurd? In het begin werd de waarde naar <code>5</code> gezet. We maken een nieuw kind aan en kijken wat de waarde is van de property <code>x</code>. Omdat dit kind een vers object is met als enig extra de verborgen link naar een prototype, heeft het zelf nog geen properties. Toch is de waarde van <code>foo.x</code> gelijk aan <code>5</code>, gelijk aan <code>Foo.prototype.x</code> dus. Dat komt omdat JavaScript bij het uitlezen van een property eerst gaat kijken of dat object (<code>foo</code>) zelf een property heeft met die naam. In dat geval wordt de waarde van die property meteen teruggegeven. Zo niet, dan gaat JavaScript die verborgen link volgen en kijken of dat prototype object een property heeft met die naam. Zo ja, wordt de waarde daarvan teruggegeven. Zo nee, dan gaat JavaScript verder met de verborgen link van dat prototype object. Dit blijft het doen tot de verborgen link niet meer naar een object wijst. In dat geval geeft het op en zal het de waarde <code>undefined</code> teruggeven.</p>
<p>Dat was lezen dus. Hoe zit het dan met schrijven? Nou, een stuk makkelijker! Als je naar een property schrijft, zal JavaScript dat altijd opslaan als een eigen property van datzelfde object. Daarbij maakt het niet uit of dat object al bestaat of niet. Als het al bestond, wordt het overschreven. Als het niet bestond, wordt het aangemaakt. JavaScript zal bij het wijzigen van een property dus nooit naar de verborgen link met prototype kijken. Het doet er simpelweg niet toe.</p>
<p>In JavaScript werkt alles op deze manier van erven. Zo staat <code>Object</code> aan het hoofd (is dus de ouder) van alle andere objecten die JavaScript automatisch aanmaakt. Dit kunnen we eenvoudig aantonen door de waarde van <code>Array instanceof Object</code> te bekijken. Of door <code>Object.prototype.x = 5</code> te doen en daarna te kijken wat de waarde van <code>arr.x</code> is bij een willekeurig array. Bij het uitlezen van <code>arr.x</code> zal JavaScript eerst kijken of <code>arr</code> zelf een property heeft met de naam <code>x</code>. Waarschijnlijk niet, dus gaat het kijken bij de ouder; <code>Array.prototype</code>. Deze zal waarschijnlijk ook geen property <code>x</code> hebben, dus gaat het naar diens ouder, welk <code>Object</code> is. <code>Object.prototype.x</code> heb je net zelf aangemaakt dus wordt <code>5</code> teruggegeven.</p>
<p>Als we nou gaan kijken naar subclassing wordt het al meteen een heel stuk moeilijker. Helaas werkt dat niet zo soepeltjes in JavaScript, maar toch is het best mogelijk. Let op, we nemen de volgende objecten:</p>
<pre><code>function Beest(){}
function Hond(){}
function Kat(){}
</code></pre>
<p>We willen nu dat <code>Hond</code> en <code>Kat</code> allebei een zogenaamde subclass (of sub object) worden van <code>Beest</code>, want het zijn allebei beesten. We gaan een paar fictieve methodes toevoegen om dingen duidelijker te maken. Dit doen we eerst op het prototype van <code>Beest</code>; daar maken we de generieke versie die misschien dingen doet wat alle beesten toch wel moeten doen...</p>
<pre><code>Beest.prototype = {
spreek: function(){
this.openMond();
this.maakGeluid();
},
openMond: function(){
// hier worden spieren aangesproken enz...
// dit moeten (bijna) alle beesten doen die willen &quot;spreken&quot;
},
maakGeluid: function(){
// tril stembanden
// dit moeten alle dieren wel doen, maar ieder dier weer op zijn eigen manier
}
};
</code></pre>
<p>Nu dan, ieder beest maakt natuurlijk andere geluiden. Dus nu willen we eigenlijk dat als we <code>kat.spreek()</code> doen dat we dan mauwen, terwijl <code>hond.spreek()</code> moet blaffen. Oei... Welnu, dit kan :) Eerst maken we <code>Hond</code> en <code>Kat</code> een subclass van <code>Beest</code>:</p>
<pre><code>Hond.prototype = new Beest();
Kat.prototype = new Beest();
</code></pre>
<p>Dat was het! Ja, echt. Dit zorgt er nu al voor dat nieuwe kinderen van zowel <code>Hond</code> als <code>Kat</code> functies zullen teruggeven als je hun <code>spreek</code>, <code>openMond</code> en <code>maakGeluid</code> properties uitleest. Sterker nog, <code>hond.spreek === kat.spreek</code>. Deze functies of objecten worden gedeeld. Wat we zojuist hebben gedaan is het prototype object van <code>Hond</code> en <code>Kat</code> vervangen door een nieuw kind van <code>Beest</code>. Dat zorgt ervoor dat we een prototypal link vormen van een kind van <code>Hond</code>/<code>Kat</code> naar de ouder naar <code>Beest</code> naar <code>Object</code>. De reden is dat bij deze link alleen de verborgen link naar de ouder wordt beschouwd. Dus gewoon <code>Hond.prototype = Beest</code> toekennen zou niet werken, want het object <code>Beest</code> heeft alleen een verborgen link naar zijn eigen ouder; <code>Object</code>.</p>
<p>We hebben nu dus twee subclasses van <code>Beest</code>; <code>Hond</code> en <code>Kat</code>. Alle properties die we aan <code>Beest.prototype</code> toevoegen, zullen we terug kunnen vinden in de kinderen van <code>Hond</code> en <code>Kat</code>, tenzij deze zelf een property hebben met die naam. Of het prototype object van hun ouder. Ter illustratie:</p>
<pre><code>var kat = new Kat();
kat.spreek; // is een functie
kat.spreek === Beest.prototype.spreek; // kat erft van Beest dus het is gelijk, kat -&gt; Kat -&gt; Beest
// voor honden geldt op dit moment hetzelfde
var hond = new Hond();
hond.spreek; // een functie
hond.spreek === Beest.prototype.spreek; // true
// sterker nog...
hond.spreek === kat.spreek; // true
// en ze zijn dus (klein-)kinderen van Beest
kat instanceof Kat; // true
kat instanceof Beest; // true
hond instanceof Beest; // true
kat instanceof Hond; // false, dit werkt dus niet, dat is de bedoeling
// nu gaan we een property &quot;shadowen&quot;...
kat.maakGeluid === Beest.prototype.maakGeluid; // true
Kat.prototype.maakGeluid = function(){ alert(&quot;Miauw&quot;); };
kat.maakGeluid === Beest.prototype.maakGeluid; // false, de prototypal lookup stopt nu bij Kat
kat.maakGeluid === hond.maakGeluid; // false, want hond.maakGeluid is nog steeds die van Beest
// als we nu kat.spreek(); doen zal er een alert komen met &quot;miauw&quot;.
// we kunnen kat.maakGeluid ook eenvoudig weer die van Beest laten zijn
delete Kat.prototype.maakGeluid;
kat.maakGeluid === Beest.prototype.maakGeluid; // true, hij stopt niet meer bij Kat.prototype
</code></pre>
<p>Een nadeel van deze manier van subclassing is dat de &quot;constructor&quot; van de ouder wordt uitgevoerd bij initialisatie. Dus bij <code>Kat.prototype = new Beest()</code>, want je doet daar wel &quot;gewoon&quot; <code>new Beest()</code>. Dat dit voor initialisatie, is maakt voor JavaScript geen verschil. Dat betekent dat eventuele bijwerkingen van de constructor ook zichtbaar zijn. Dat is vaak niet wenselijk, doch soms wel.</p>
<pre><code>function Foo(){ alert(&quot;ohnoes!&quot;); };
new Foo(); // alert
function Bar(){}
Bar.prototype = new Foo(); // deze regel zorgt voor een extra alert
new Bar(); // geen alert
</code></pre>
<p>Dus hoe krijgen we dat subclassing voor elkaar zonder de alert? Nou, dat is een beetje lastig :) Er zijn een aantal oplossingen voor, al komen ze vaak op hetzelfde neer. Je maakt een copy van de referentie van het prototype object en zet die in een nieuwe functie. Aangezien <code>instanceof</code> er alleen maar naar kijkt of het object van de verborgen link van het kind wijst naar hetzelfde object als de prototype property van de rechterkant van <code>instanceof</code>, verandert er niets. Sterker nog, je kunt het heel eenvoudig voor elkaar krijgen dat een object erft van twee of meerdere andere objecten, zelfs als deze nooit met <code>new</code> zijn gebruikt. Ter illustratie:</p>
<pre><code>function Foo(){}
function Bar(){}
Bar.prototype = Foo.prototype; // dus Foo en Bar hebben nu exact hetzelfde prototype object
var foo = new Foo();
foo instanceof Foo; // true, zoals verwacht
foo instanceof Bar; // true, ja deze ook want foo.[verborgen link] wijst naar het object dat gelijk is aan Bar.prototype.
</code></pre>
<p>Nu dan, dit kunnen we dus gebruiken... We gaan even terug naar ons <code>Beest</code> voorbeeld van boven. We willen dat <code>Kat</code> en <code>Hond</code> een subclass worden van <code>Beest</code>. Hiervoor moet <code>Kat.prototype</code> een kind worden van <code>Beest</code>, omdat we die verborgen link naar <code>Beest.prototype</code> nodig hebben. Hoe die link tot stand kwam is niet zo belangrijk, het gaat immers maar om een referentie naar hetzelfde object. Met de kennis die we zojuist opgedaan hebben wordt het dan als volgt:</p>
<pre><code>function Beest(){ alert(&quot;foo&quot;); }
function tijdelijk(){}
tijdelijk.prototype = Beest.prototype; // tijdelijke functie verwijst nu naar hetzelfde prototype object
var tmp = new tijdelijk(); // GEEN alert...
tmp instanceof Beest; // true, de verborgen link bestaat
Kat.prototype = tmp;
// let op dat Kat.prototype niet hetzelfde object moet zijn aan Hond.prototype!
Hond.prototype = new tijdelijk(); // ook geen alert
</code></pre>
<p>Nu zal je zien dat alle voorbeelden van erfelijkheid die we hierboven beschouwden hier ook weer zullen bestaan. Dus nieuwe katten en honden erven in eerste instantie de <code>spreek</code>, <code>openMond</code> en <code>maakGeluid</code> methoden van <code>Beest</code>. Deze kunnen dan specifieker worden door een nieuwe functie aan <code>Kat.prototype.maakGeluid</code> toe te wijzen, zoals we eerder al lieten zien. Daar verandert niets in.</p>
<p>Het enige dat ons nog rust is de zogenaamde &quot;<code>super</code>&quot; call. JavaScript kent geen subclassing en dus ook niet het concept van <code>super</code>... Gelukkig is in JavaScript de code van de constructor gelijk aan de code van een normale aanroep van de functie. Daar ga ik nu niet op in, maar ga er maar vanuit dat voor <code>Beest()</code> en <code>new Beest()</code>, dezelfde code aangeroepen wordt. Het enige verschil is &quot;de context&quot;. Deze context kunnen we wijzigen door twee methodes die JavaScript beschikbaar stelt via <code>Functie.prototype</code>; <code>call</code> en <code>apply</code>. Ook hier ga ik niet dieper op in, behalve dan te zeggen dat ze me in staat stellen om te doen alsof een constructor wordt aangeroepen alsof dat met het <code>new</code> keyword gebeurde.</p>
<pre><code>function Foo(){ this.x = 5; alert(&quot;executed&quot;); }
Foo(); // er wordt een globale variabele x aangemaakt, oeps, en er was een alert
var foo = new Foo(); // foo.x is 5 en er was een alert
var nep = {};
Foo.call(nep); // nep.x zal 5 worden! en er was een alert
</code></pre>
<p>Bij het testen van deze code zal je zien dat je drie alerts krijgt. Dezelfde code wordt dus uitgevoerd. Het enige verschil is dat het keyword <code>this</code> naar een ander object verwijst; respectievelijk het globale object (in de browser is dat altijd <code>window</code>), een nieuwe instance van <code>Foo</code> en een nieuw anoniem object. Uitvoer van de functie is altijd hetzelfde. Enige aparte was dat er bij de tweede keer, dus bij <code>new Foo()</code>, ook een nieuw object werd aangemaakt met die verborgen link naar <code>Foo.prototype</code>. Verder is de uitvoer hetzelfde. Dat kunnen we dus ook gebruiken voor onze <code>super</code>. Stel dat <code>Beest</code> nog iets aparts doet in zijn constructor. Dan willen we dat wel laten doen voor ieder beest. Dus…</p>
<pre><code>function Beest(){ alert(&quot;speciaals, alleen voor nieuwe beesten, maar wel alle beesten&quot;); }
// subclassing zonder super
function Kat(){ alert(&quot;miauw&quot;); }
function tmp(){}
tmp.prototype = Beest.prototype;
Kat.prototype = new tmp();
new Kat(); // 1 alert: miauw
// subclassing met super
function Kat(){ Beest.apply(this, arguments); alert(&quot;miauw&quot;); }
function tmp(){}
tmp.prototype = Beest.prototype;
Kat.prototype = new tmp();
new Kat(); // twee alerts! die van Beest en miauw
</code></pre>
<p>Bij het laatste voorbeeld zijn kinderen van <code>Kat</code> dus ook kleinkinderen van <code>Beest</code>. Ze erven eerst van <code>Kat</code> en daarna van <code>Beest</code>. De constructor van <code>Beest</code> wordt alleen maar uitgevoerd bij het aanmaken van nieuwe kinderen van <code>Beest</code> of <code>Kat</code>, niet bij het initialiseren van de subclass <code>Kat</code> zelf. Achievement achieved!</p>
<p>Ik heb geen idee hoe moeilijk of makkelijk dit is, maar ik hoop dat de voorbeelden een beetje voor zich spreken. Ga er mee spelen. Het is misschien een beetje lastig, maar als je het eenmaal door hebt is het oh-zo logisch :)</p>
<p>Oh, en prettige feestdagen! ;)</p>
<h2>Over Peter van der Zee</h2>
<img src="https://www.fronteers.nl/_img/2011/12/peter-van-der-zee.jpg" alt="Foto van Peter" />
[Peter](http://qfox.nl/) is gespecialiseerd in in JavaScript/ECMAScript en werkt voor [Uxebu](http://uxebu.com/), voornamelijk aan JavaScript gerelateerde projecten.
<p>Donatie: <a href="https://www.bof.nl/">Bits of Freedom</a>
Peter heeft Fronteers de vrijheid gegeven om een goed doel (of geen) te kiezen en we hebben als tegenhanger voor het EFF voor Bits of Freedom gekozen.</p>
</content>
</entry>
<entry>
<title>Deferred en promise in jQuery</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/deferred-en-promise-in-jquery"/>
<updated>2011-12-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/deferred-en-promise-in-jquery</id>
<content xml:lang="nl" type="html"><p>Deferred en promise? Gaan we het hebben over uitstellingen en beloftes in jQuery? Nee, gelukkig niet. Deferred en promise zitten sinds versie 1.5 in jQuery en daarmee kan je asynchrone functies zoals Ajax beter afhandelen.</p>
<p>Even een stapje terug in de tijd, toen we nog met guldens en franken betaalden. Als je een muisklik wilde afvangen, deed je dat met <code>element.onclick = someFunction;</code> Dat werd een probleem als een ander stukje code ook naar de klik wilde luisteren. Dat kon niet, want aan <code>onclick</code> kan je maar één functie toekennen. Dit is destijds opgelost met de DOM-functie <code>addEventListener</code>. Daarmee kan je zoveel functies die luisteren toevoegen als je wilt. En sindsdien weten we niet beter.</p>
<p>Nu hebben we een vergelijkbaar probleem met Ajax-aanroepen. Nu niet met events, maar met het gegeven dat Ajax maar één callback-functie accepteert. Niet alleen bij de jQuery <code>$.ajax()</code>-aanroep, maar ook bij het onderliggende XMLHttpRequest-object.</p>
<h2>Promise</h2>
<p>Tot jQuery 1.5 zag een typische <code>$.ajax()</code>-aanroep er als volgt uit:</p>
<pre><code>$.ajax({
url: &quot;/myServerScript&quot;,
success: mySuccessFunction,
error: myErrorFunction
});
</code></pre>
<p>De <code>$.ajax()</code>-functie retourneert een jQuery XMLHttpRequest-object.</p>
<p>Tot zover niets nieuws. Vanaf versie 1.5 implementeert het teruggegeven object ook de <a href="http://wiki.commonjs.org/wiki/Promises/A">CommonJS Promises/A-interface</a>. Dat is een hele mond vol. CommonJS is een initiatief om gemeenschappelijke en onafhankelijke interfaces (API's) vast te leggen. Promises/A is zo'n interface. Het voordeel is dat deze niet jQuery-specifiek is. Als je bijvoorbeeld met Node.js werkt, dan is de kans groot dat je met dezelfde interface te maken krijgt. Handig.</p>
<p>De manier van callbacks toewijzen is met Promises heel anders:</p>
<pre><code>var promise = $.ajax({
url: &quot;/myServerScript&quot;
});
promise.done(mySuccessFunction);
promise.fail(myErrorFunction);
</code></pre>
<p>&quot;Oke, de interface is nu veranderd, maar wat heb ik daaraan?&quot;, zul je je vast afvragen.</p>
<p>De voordelen van promises zijn:</p>
<ol>
<li>Je kunt de <code>done()</code>- en <code>fail()</code>-functies meerdere keren aanroepen, met verschillende callbacks. Misschien heb je wel een callbackfunctie die een animatie stopt, een die een nieuwe Ajax-aanroep doet en een andere functie die de ontvangen gegevens aan de bezoeker toont.</li>
</ol>
<pre><code>var promise = $.ajax({
url: &quot;/myServerScript&quot;
});
promise.done(myStopAnimationFunction);
promise.done(myOtherAjaxFunction);
promise.done(myShowInfoFunction);
promise.fail(myErrorFunction);
</code></pre>
<ol start="2">
<li>
<p>Ook als de Ajax-aanroep al geweest is, kan je nog steeds de <code>done()</code>- en <code>fail()</code>-functies aanroepen en de callbacks worden dan gelijk uitgevoerd. Dus geen gedoe meer met variabelen die de verschillende staten moeten onthouden. Als een Ajax-aanroep afgelopen is, dan komt deze of in de succes-staat of in de fout-staat en deze zal niet meer veranderen.</p>
</li>
<li>
<p>Je kunt promises combineren. Soms is het nodig om gelijktijdig twee Ajax-aanroepen te doen en wil je een functie pas aanroepen als beide succesvol zijn verlopen. Hiervoor gebruik je de nieuwe <code>$.when()</code>-functie:</p>
</li>
</ol>
<pre><code>var promise1 = $.ajax(&quot;/myServerScript1&quot;);
var promise2 = $.ajax(&quot;/myServerScript2&quot;);
$.when(promise1, promise2).done(function(response1, response2){
// Handle both responses
});
</code></pre>
<h2>Deferred</h2>
<p>Wat is dan een deferred en wat is het verschil met een promise? Zoals je hierboven hebt gezien is een promise een object dat je terugkrijgt van een asynchrone functie. Een deferred heb je nodig als je zelf zo'n functie schrijft.</p>
<p>Een deferred object kan hetzelfde als een promise object, maar heeft twee extra functies om de <code>.done()</code>- en <code>.fail()</code>-functies te laten afgaan.</p>
<p>Een deferred-object heeft een <code>.resolve()</code>-functie om een succesvolle uitkomst aan te geven en de met <code>.done()</code> geregistreerde functies uit te voeren. De <code>.reject()</code>-functie geeft een gefaalde uitkomst aan en voert de met <code>.fail()</code> geregistreerde functies uit.</p>
<p>Aan de <code>.resolve()</code>- en <code>.reject()</code>-functies kunnen parameters worden meegegeven die de met <code>.done()</code> en <code>.fail()</code> geregistreerde functies als argument meekrijgen.</p>
<p>Het promise-object heeft geen <code>.resolve()</code>- en <code>.reject()</code>-functie. Het promise object geef je immers weg aan andere scripts waarvan je niet wilt dat zij de promise kunnen laten resolven of rejecten.</p>
<p>Hieronder een eenvoudig script dat de werking illustreert. De html bestaat uit een leeg divje met als id &quot;result&quot;.</p>
<pre><code>$('#result').html('waiting...');
var promise = wait();
promise.done(result);
function result() {
$('#result').html('done');
}
function wait() {
var deferred = $.Deferred();
setTimeout(function() {
deferred.resolve();
}, 2000);
return deferred.promise();
}
</code></pre>
<p>Het script is ook te vinden op <a href="http://jsfiddle.net/TT3G5/">jsFiddle</a>, zodat je er zelf mee kunt experimenteren.</p>
<p>De <code>wait()</code>-functie is de functie die een promise teruggeeft. Deze wordt resolved via een <code>setTimeout</code> van twee seconden. In plaats van de <code>setTimeout</code> kan alles gebruikt worden wat asynchroon is, zoals Ajax, animaties, Web workers, enzovoorts. Duidelijk is dat binnen de <code>wait()</code>-functie een deferred-object wordt gebruikt, maar dat we het beperkte promise-object teruggeven.</p>
<h2>jQuery-ondersteuning</h2>
<p>Op het <a href="http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/">jQuery-blog</a> is te lezen dat jQuery helemaal voor promises gaat en dat de oude API, met de <code>.error()</code>-, <code>.success()</code>- en <code>.complete()</code>-functies, uiteindelijk zal verdwijnen. Als je deze functies gebruikt, dan kan je alvast beginnen je code te herschrijven en over te stappen op de promise-interface.</p>
<h2>Meer mogelijk</h2>
<p>Dit artikel is slechts een introductie in de werking van het deferred-object. jQuery ondersteunt nog veel meer functies. Bekijk de <a href="http://api.jquery.com/category/deferred-object/">jQuery deferred documentatie</a> voor alle mogelijkheden. Zo is het bijvoorbeeld ook mogelijk om met promises de voortgang van een proces bij te houden.</p>
<h2>Over Edwin Martin</h2>
<img src="https://www.fronteers.nl/_img/2011/12/edwin-martin.jpg" alt="Foto van edwin martin uit 2011" class="floating-portrait" />
Edwin Martin is freelance front-end webontwikkelaar en woont met vrouw en twee dochtertjes in Hilversum. Binnen Fronteers helpt hij mee met het organiseren van de Fronteers conferentie. Hij houdt een blog bij over front-end op [bitstorm.org](http://www.bitstorm.org/) en is te vinden op twitter als [@edwinm](https://twitter.com/edwinm).
<p>Donatie: <a href="https://www.eff.org/">Electronic Frontier Foundation</a>
Mijn echte goede doel is natuurlijk Fronteers, maar dat past niet zo bij de kerstgedachte. Daarom kies ik voor de EFF, die opkomt voor onze rechten in de digitale wereld. Zo helpen ze bijvoorbeeld softwareontwikkelaars die plots een (onterechte) rechtszaak van een groot bedrijf aan de broek krijgen.</p>
</content>
</entry>
<entry>
<title>Welkom op het Audiologische Internet</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/welkom-op-het-audiologische-internet"/>
<updated>2011-12-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/welkom-op-het-audiologische-internet</id>
<content xml:lang="nl" type="html"><p>Het internet. Een praktisch oneindige bron aan tekstuele en grafische informatie. Tegenwoordig kunnen wij, als webontwikkelaars, gebruik maken van net iets meer dan twintig jaar aan evolutie betreft mogelijkheden op het internet. Wat begon als statische tekstdocumenten groeide al snel door tot interactieve pagina’s, en tegenwoordig zelfs tot webapplicaties met miljoenen regels aan JavaScript code en multiplayer spellen. De afname in het gebruik van Adobe Flash, samen met de nieuwe driedimensionale grafische mogelijkheden die WebGL geïntroduceerd heeft, heeft nadruk gelegd op een zintuig dat het internet nog niet volledig kan verzorgen: het gehoor.</p>
<h2>Achtergrondgeluidjes, Adobe Flash en <code>&lt;audio&gt;</code></h2>
<p>Terug naar het jaar 1995, waarin Microsoft Internet Explorer 2 vrijgeeft. Dit is de eerste browser die ondersteuning voor het invoegen van verschillende soorten media toevoegt, namelijk het <code>&lt;bgsound&gt;</code> element en de mogelijkheid om geluid en video te embedden. Niet veel later volgden ook andere browsers en plugins; in 2005 is de door Opera geïntroduceerde <a href="http://www.whatwg.org/specs/web-apps/2005-09-01/#sound">Audio JavaScript interface</a> in de Web Application specificatie toegevoegd, een mogelijkheid die we nu kennen als het HTML5 <code>&lt;audio&gt;</code> element.</p>
<h2>Gebrekkige mogelijkheden</h2>
<p>Ondanks dat het <code>&lt;audio&gt;</code> element het afspelen van geluid toestaat, en zelfs de mogelijkheden biedt om geluid te pauzeren en de afspeelsnelheid te veranderen, zijn er belangrijke tekortkomingen. Een goed voorbeeld hiervan is de afwezigheid van positiebepaling van geluid. Vergelijk dit met een spel waarin iemand een wapen op je afvuurt: je wilt kunnen horen waar in de omgeving deze tegenstander staat. WebGL geeft ons de mogelijkheid om prachtige omgevingen in drie dimensies te creëren, enkel met de beperking dat het huidige geluidsspectrum op het internet enkel links en rechts kent.</p>
<p>Een ander probleem dat je tegen kunt komen is een vertraging bij het afspelen van korte geluidsfragmenten. Net zoals bij het kijken naar nagesynchroniseerde televisie de stemmen duidelijk nep zijn, wordt het als frustrerend ervaren als het ratelen van een geweer een kwart seconde na het afvuren van het wapen volgt. En dan is er natuurlijk ook nog het codec probleem, want geen enkel bestandsformaat werkt in elke browser.</p>
<p>Voor het oplossen van deze problemen is een <a href="http://www.w3.org/2005/Incubator/audio/charter">klein groepje mensen</a> van Mozilla, Google, de BBC en de MIDI Manufacturers Association in 2005 al begonnen met een werkgroup binnen het W3C om de mogelijkheden te onderzoeken. Dit is uitgegroeid tot de <a href="http://www.w3.org/2011/audio/">W3C Audio Working Group</a>, met als doel het ontwikkelen van een geavanceerde Audio API om spellen en applicaties toch de mogelijkheid te geven geluid te analyseren, bewerken en te creëren.</p>
<h2>De Mozilla Audio Data API, en de Web Audio API</h2>
<p>De eerste publieke geavanceerde Audio API is in oktober 2010 geïntroduceerd door Mozilla's David Humphrey, namelijk de <a href="https://wiki.mozilla.org/Audio_Data_API">Audio Data API</a>. Deze API stelt de ontwikkelaar in staat om geluiden te analyseren, te bewerken of zelfs volledig zelf te creëren door de eigenlijke audio data beschikbaar te stellen aan JavaScript, waarna de ontwikkelaar hier berekeningen op kan uitvoeren. Naast het uitrollen van deze functionaliteiten in Mozilla Firefox 4, heeft het bedrijf besloten om een deel van de focus te verleggen naar de <a href="http://www.w3.org/2011/audio/drafts/1WD/MediaStream/">MediaStream Processing API</a>. Deze biedt, naast het analyseren en bewerken van geluid via de Audio Data API, betere integratie met andere functies zoals camera toegang.</p>
<p>Een tegenhanger hiervan is de <a href="http://www.w3.org/2011/audio/drafts/1WD/WebAudio/">Web Audio API</a>, een project van Google en Apple dat in 2009 gestart is door Google's Chris Rogers. De API volgt een totaal andere methodiek, en biedt standaardfunctionaliteiten aan in de vorm van Nodes. Functionaliteiten als positionering van geluid, omgevingseffecten, fade-ins, het mixen van geluid en simpele analyse kunnen hierdoor met slechts een paar regels JavaScript worden toegevoegd.</p>
<p>Om een vergelijking te schetsen tussen de twee voorstellen:</p>
<table>
<thead>
<tr>
<th>Audio Data API</th>
<th>Web Audio API</th>
</tr>
</thead>
<tbody>
<tr>
<td>Mozilla Firefox</td>
<td>Google Chrome, Apple Safari, binnenkort mogelijk iOS.</td>
</tr>
<tr>
<td>Imperatief</td>
<td>Declaratief (met mogelijkheid tot imperatief)</td>
</tr>
<tr>
<td>Low-level, zelf de berekeningen doen</td>
<td>High-level met Nodes voor de meeste operaties, maar opnieuw met de mogelijkheid tot low-level.</td>
</tr>
<tr>
<td>1 input, 1 bewerking, 1 output</td>
<td>1 of meer inputs, 1 of meer bewerkingen, 1 output</td>
</tr>
</tbody>
</table>
<p>De Web Audio API is in principe een superset van de Audio Data API: het biedt dezelfde functionaliteiten, maar geeft de ontwikkelaar ook de optie om gebruik te maken van geoptimaliseerde procedures die veelal tot hetzelfde effect zullen leiden. Er zijn al verschillende JavaScript libraries voor Mozilla’s Audio Data API geschreven om tot datzelfde punt te komen, zoals <a href="https://github.com/corbanbrook/dsp.js/">DSP.js</a>.</p>
<p>Het volgende voorbeeld zal een ingelezen geluidsbestand, bijvoorbeeld via <a href="http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html">XMLHttpRequest</a>, afspelen nadat er een lowpass filter toegepast is (Web Audio API).</p>
<pre><code>var audioContext = new AudioContext();
function playAndAnalyzeAudio(inputBuffer /* ArrayBuffer */) {
audioContext.decodeAudioData(inputBuffer, function(decodedData) {
var inputNode = audioContext.createBufferSource(),
filterNode = audioContext.createBiquadFilter();
filterNode.type = 0; // BiquadFilterNode.LOWPASS;
filterNode.connect(audioContext.destination);
inputNode.buffer = decodedData;
inputNode.loop = true;
inputNode.connect(filterNode);
inputNode.noteOn(0); // speel het geluid af.
});
}
</code></pre>
<p>Persoonlijk geloof ik meer in een API die het gros van de berekeningen op een geoptimaliseerde manier kan uitvoeren, gezien de formules die in geluidsbewerking gebruikt worden veelal standaard zijn, maar tevens de mogelijkheid biedt om verder—imperatief—te gaan als je dat zelf wilt. Een voorbeeld hiervan zijn bijvoorbeeld CSS Animaties: animaties op de pagina gebruiken is al jaren mogelijk via JavaScript, maar juist omdat ze declaratief in CSS worden gedefinieerd kan een browser anticiperen op het resultaat en hardware gebruiken om het effect te tonen, wat tot een beter resultaat leidt. Een moderne Blu-Ray film met 7.1 geluidskanalen op 192 kHz zal over de anderhalf miljoen signalen per seconde verwerken, en hardware speelt hier een essentiële rol in.</p>
<p>Toch is er nog veel discussie aan de gang, en beide APIs zijn nog niet volledig in staat om met alle andere specificaties te integreren: de <code>&lt;video&gt;</code> en <code>&lt;audio&gt;</code> elementen, microfoon input via de <code>getUserMedia()</code>-methode en het synchroniseren van meerdere geluidsstromen via de nieuwe HTML5 <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#synchronising-multiple-media-elements">MediaController interface</a>. Dit zijn allemaal vraagstukken waarop we in 2012 een antwoord gaan krijgen, want op het gebied van multimedia gaat het een heel interessant jaar worden!</p>
<h2>Over Peter Beverloo</h2>
<p>/2011/12/peter-beverloo.jpg
<a href="http://peter.sh/">Peter Beverloo</a> is een Software Engineer bij Google en onderdeel van de Chromium en WebKit teams. Hiernaast is hij actief op <a href="https://twitter.com/beverloo">Twitter</a>, deelnemer van projecten als <a href="http://html5boilerplate.com/">HTML5 Boilerplate</a> en <a href="http://w3fools.com/">W3Fools</a> en vrijwilliger bij de Fronteers en Mobilism conferenties.</p>
<p>Donatie: <a href="https://www.eff.org/">Electronic Frontier Foundation</a>
Electronic Frontier Foundation zal ook namens mij een donatie ontvangen. Hun bezigheden zijn essentieel voor het voortbestaan van het vrije internet zoals we dat vandaag kennen.</p>
</content>
</entry>
<entry>
<title>Geharnast JavaScript</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/geharnast-javascript"/>
<updated>2011-12-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/geharnast-javascript</id>
<content xml:lang="nl" type="html"><p>Het belang van JavaScript op het web is de laatste jaren enorm toegenomen. Ten eerste heeft JavaScript deels de animatierol van Flash overgenomen, ten tweede is het web applicatiever geworden, waardoor JavaScript (bijvoorbeeld in Ajax-communicatie) een grote vlucht genomen heeft. De rol JavaScript wordt groter en tegelijkertijd neemt de professionalisering toe. Het is opvallend te zien dat veel best practices uit de back-end-wereld gemeengoed aan het worden zijn bij JavaScript-development. Testen is zo'n belangrijk onderdeel.</p>
<h2>Testen</h2>
<p>Het testen van JavaScript kan op meerdere niveaus gedaan worden:</p>
<ol>
<li>Lint testen. Het testen op correcte syntax door tools als <a href="http://www.jshint.com/">JsHint</a>, <a href="http://www.jslint.com/">JsLint</a> of <a href="http://code.google.com/intl/nl/closure/utilities/">Closure Linter</a>. Dit kan deels door je editor gedaan worden.</li>
<li>Functioneel testen. Het testen van bijvoorbeeld klikscenario's in je website of app met een tool als <a href="http://seleniumhq.org/">Selenium</a>.</li>
<li>Unittesten. Daar gaan we in dit artikel dieper op in.</li>
<li>Last but not least: handmatig testen. Idealiter stel je hiervoor schriftelijke testscripts op, zodat je gestructureerd dezelfde scenario's kunt testen bij opeenvolgende software releases.</li>
</ol>
<p>De eerste drie soorten testtools kunnen geautomatiseerd worden, zodat je continu op de hoogte gebracht kunt worden van de staat van je applicatie.</p>
<h2>Unittesten</h2>
<p>Wikipedia zegt over <a href="http://nl.wikipedia.org/wiki/Unittesten">unittesten</a>: &quot;Unittesten is een methode om softwaremodulen of stukjes broncode (<em>units</em>) afzonderlijk te testen. Bij unittesten zal voor iedere unit een of meerdere tests ontwikkeld worden. Hierbij worden dan verschillende testcases doorlopen. In het ideale geval zijn alle testcases onafhankelijk van andere tests.&quot; Verschillende units samen worden getest in een integratietest. Voor JavaScript zijn er diverse unittest frameworks beschikbaar. Enkele bekende zijn:</p>
<ul>
<li><a href="http://docs.jquery.com/QUnit">QUnit</a></li>
<li><a href="http://developer.yahoo.com/yui/yuitest/">YUI Test</a></li>
<li><a href="http://code.google.com/p/js-test-driver/">Js Test Driver</a></li>
<li><a href="http://pivotal.github.com/jasmine/">Jasmine</a> (voortgekomen uit JsUnit)</li>
</ul>
<p>In dit artikel kijken we verder naar unittesten met Jasmine. Jasmine kan onafhankelijk van een JavaScript-library gebruikt worden en heeft ook geen DOM nodig om zijn testen uit te voeren. Verder is Jasmine goed te automatiseren. In syntax en mogelijkheden verschilt Jasmine niet veel van andere unittesting tools.</p>
<h2>TDD - Assume your code will fail</h2>
<p>Eén stap verder nog dan systematisch testen is het testen als uitgangspunt te nemen in je software-ontwikkelproces: &quot;Test-Driven Development&quot; (TDD). Test-Driven Development is een ontwikkelmethode voor software waarbij eerst tests worden geschreven en daarna pas de code. De testcases worden beschreven vanuit het oogpunt van de gebruiker. Hoewel TDD (een methodiek) en Jasmine (een tool) niet per definitie een combinatie vormen, werpen we hier een korte, inleidende blik op TDD met Jasmine.</p>
<h2>Jasmine installeren</h2>
<ol>
<li>De voorbeeldcode bij dit artikel is te downloaden vanaf <a href="https://github.com/ludder/Fronteers-Jasmine-Example">github</a>.</li>
<li>Op het hoogste niveau zie je de directory's &quot;lib&quot;, &quot;spec&quot; en &quot;src&quot;. &quot;lib&quot; bevat de core-bestanden van Jasmine, in &quot;src&quot; komen de JavaScriptbestanden van je project en in &quot;spec&quot; zitten de bestanden die de sourcecode gaan testen.</li>
<li>Open SpecRunner.html in je favoriete browser. Er worden nog geen testen uitgevoerd: &quot;0 specs, 0 failures ...&quot;.</li>
</ol>
<h2>Een eerste Jasmine unit test maken</h2>
<p>Jasmine is opgebouwd uit suites, specs en expectations. Eén JavaScript-project bestaat normaal gesproken uit meerdere Jasmine <em>testsuites</em>. Eén testsuite, die vaak een component of een class omvat, kan op zijn beurt een geneste suite of meerdere <em>specs</em> bevatten. Een spec test gerelateerde functionaliteit. In een spec kunnen één of meerdere test cases (<em>expectations</em>) gedefinieerd zijn. Met de standaard <a href="https://github.com/pivotal/jasmine/wiki/Matchers"><em>matchers</em></a> van Jasmine (functies zoals <code>toEqual()</code>, <code>toBe()</code>, <code>toMatch()</code>, <code>toBeUndefined()</code> etc.) kun je verschillende scenario's testen.</p>
<p>Hoe schrijf je een spec? Belangrijke leidraden voor TDD zijn:</p>
<ol>
<li>Schrijf eerst je test (dus niet eerst je functionele code)</li>
<li>Zie de test falen</li>
<li>Schrijf nu de code om de test te laten slagen, op de snelst mogelijke manier, dus niet rekening houdend met eventuele aanpassingen in de code</li>
<li>Refactor (verbeter de code zonder de functionaliteit te wijzigen)</li>
<li>Herhaal deze stappen</li>
</ol>
<h2>Voorbeeld</h2>
<p>Stel dat je de Fronteers webshop beheert. Een product kan een variabele prijs hebben: De gewone bezoeker betaalt de volle mik, vaste klanten krijgen 20% korting, en Fronteersleden toucheren maar liefst 50%. Als je hier een functie voor wilt schrijven zou je dat volgens TDD met Jasmine als volgt kunnen aanpakken:</p>
<p>Maak een suite aan (<code>/spec/FronteersShopSpec.js</code>) die het component FronteersShop en de nog te schrijven functie calcDiscount() gaat testen:</p>
<pre><code>describe(&quot;FronteersShop&quot;, function() {
var fs;
var CLIENTTYPE_MEMBER = 'member',
CLIENTTYPE_FRONTEERS = 'fronteers',
CLIENTTYPE_NONMEMBER = 'other';
// Is executed before each spec:
beforeEach(function() {
fs = new FronteersShop();
});
});
</code></pre>
<p>De bijbehorende JavaScriptcode (<code>/src/FronteersShop.js</code>) ziet er dan nog als volgt uit:</p>
<pre><code>function FronteersShop() {
// a lot TODO
}
</code></pre>
<p>Unittesten worden doorgaans opgeschreven in begrijpelijke taal, zie achtereenvolgens de beschrijving van een suite, een spec en een expectation:</p>
<ul>
<li>describe &quot;when the discount price is calculated&quot;</li>
<li>it &quot;should correctly validate function input&quot;</li>
<li>expect(fs.calcDiscount(null)).toBeUndefined();</li>
</ul>
<p>Dit maakt enerzijds de Jasmine-code self-documenting en geeft anderszijds duidelijk aan waar in de testen fouten optreden.</p>
<p>De functie <code>calcDiscount()</code> willen we twee input-parameters geven:</p>
<ul>
<li>price {Number} - de prijs van het product</li>
<li>customerType {String} - het soort klant: 'member', 'fronteers' of 'other'.</li>
</ul>
<p>In de eerste stap van onze functie <code>calcDiscount()</code> kijken we (in een geneste suite) of de twee input-parameters van het verwachte datatype zijn:</p>
<pre><code>describe(&quot;FronteersShop&quot;, function() {
var fs;
var CLIENTTYPE_MEMBER = 'member',
CLIENTTYPE_FRONTEERS = 'fronteers',
CLIENTTYPE_NONMEMBER = 'other';
beforeEach(function() {
fs = new FronteersShop();
});
describe(&quot;when the discount price is calculated&quot;, function() {
it(&quot;should correctly validate function input&quot;, function() {
// Wrong number of expected arguments
expect(fs.calcDiscount(1)).toBeUndefined();
// First argument of wrong data type
expect(fs.calcDiscount(null, CLIENTTYPE_FRONTEERS)).toBeUndefined();
// Second argument of wrong data type
expect(fs.calcDiscount(100, null)).toBeUndefined();
// Input should be accepted
// expect(fs.calcDiscount(100, CLIENTTYPE_FRONTEERS)).toBeDefined();
});
});
});
</code></pre>
<p>De testen zullen falen, want de bijbehorende code ontbreekt. Hier volgt een eerste implementatie van <code>calcDiscount()</code>:</p>
<pre><code>FronteersShop.prototype.calcDiscount = function(price, customerType) {
// Check if parameter &quot;price&quot; is correct, must be floating point number
if (isNaN(parseFloat(price)) || (!isFinite(price)) ) {
return;
}
// Check if parameter &quot;customerType&quot; is a String
if (typeof customerType !== 'string') {
return;
}
}
</code></pre>
<p>(Normaal gesproken wil je waarschijnlijk geen kale return doen, maar handel je de fout af. Dat valt buiten de scope van dit artikel.) Met deze code zal de eerste spec slagen en groen worden. Vervolgens moet <code>calcDiscount()</code> doen waarvoor het in het leven geroepen is, de juiste prijs teruggeven, al dan niet met korting. Eerst schrijven we de spec:</p>
<pre><code>describe(&quot;FronteersShop&quot;, function() {
// ...
describe(&quot;when the discount price is calculated&quot;, function() {
// ....
it(&quot;should correctly calculate discount&quot;, function() {
// Expect 50% of 100 =&gt; 50
expect(fs.calcDiscount(100, CLIENTTYPE_FRONTEERS)).toEqual(50);
// Expect 80% of 100 =&gt; 80
expect(fs.calcDiscount(100, CLIENTTYPE_MEMBER)).toEqual(80);
// Expect 100% of 100 =&gt; 100
expect(fs.calcDiscount(100, CLIENTTYPE_NONMEMBER)).toEqual(100);
// Check decimals, expect 50% of 17.1 =&gt; 8.55
expect(fs.calcDiscount(17.1, CLIENTTYPE_FRONTEERS)).toEqual(8.55);
});
});
});
</code></pre>
<p>De testen zullen weer falen. Met vallen en opstaan kunnen we dan de bijbehorende JavaScript afleveren:</p>
<pre><code>FronteersShop.prototype.calcDiscount = function(price, customerType) {
// ...
if (customerType === 'member') {
return price * 0.8;
} else if (customerType === 'fronteers') {
return price * 0.5;
} else {
return price;
}
};
</code></pre>
<p>Hoera, de testpagina kleurt weer groen!</p>
<p>Dit is natuurlijk een simpel voorbeeld. Hoe complexer je code, hoe meer de waarde van unittesten toeneemt.</p>
<h2>Wat verder?</h2>
<p>Om verder up-speed te komen met Jasmine kan het <a href="http://net.tutsplus.com/tutorials/javascript-ajax/testing-your-javascript-with-jasmine/">inleidende artikel op Nettuts</a> erg nuttig zijn. De <a href="https://github.com/pivotal/jasmine/wiki/Asynchronous-specs">Jasmine-wiki</a> biedt alle noodzakelijke informatie. Er zijn veel plugins voor Jasmine beschikbaar, bijvoorbeeld om Jasmine in je IDE te integreren (<a href="https://github.com/ibolmo/jasmine-jstd-adapter">JsTestDriver</a>) of om met zogeheten fixtures de interactie met de DOM te testen (zie de <a href="https://github.com/velesin/jasmine-jquery">Jasmine jQuery-plugin</a>). Het is ook mogelijk om Jasminetesten automatisch uit te voeren in <a href="http://maven.apache.org/">Maven</a> en hen zo een onderdeel te maken van de <a href="http://en.wikipedia.org/wiki/Continuous_integration">Continuous Integration</a>. Mocht je offline zijn dan heb je wellicht iets aan het verhelderende boek van Christian Johansen <a href="http://tddjs.com/">Test-Driven JavaScript Development</a>.</p>
<h2>Tot slot</h2>
<p>Wanneer moet je nu alles uit de kast halen met unittesten? Als je een JavaScript-library, plugins of herbruikbare componenten schrijft, zijn unittesten een must. Maar ook in langlopende projecten met een snelle release cycle zijn unittesten onmisbaar om mogelijke regressiebugs af te vangen. Zelfs als je korte toevoeging schrijft voor een kleine website kunnen unittesten erg nuttig blijken. Ze laten je anders tegen je code aankijken, waardoor je code robuuster, leesbaarder en makkelijker overdraagbaar wordt. Ook voor front-enders belangrijke waarden.</p>
<h2>Over Tom Greuter</h2>
<img src="https://www.fronteers.nl/_img/2011/12/tom-greuter.jpg" alt="Foto van tom greuter uit 2011" class="floating-portrait" />
Tom Greuter is lead front-end developer bij [Info.nl](http://info.nl/) en bestuurslid van Fronteers. Naast het web is hij geboeid door voetbalclub [ФК Томь](http://fctomtomsk.ru/) uit Tomsk. Verder is hij binnen de WHATWG co-author van de draft van het nieuwe HTML6-element '<idle do-not-disturb="true">'.
<p>Donatie: Varkens in nood
In Nederland leven ieder jaar ruim 20 miljoen intelligente en sociale varkens een verschrikkelijk bestaan in kleine hokken. Stichting <a href="http://www.varkensinnood.nl/">Varkens in Nood</a> komt op voor de varkens. Met beschaafde, actuele en spraakmakende campagnes probeert Varkens in Nood consumenten en supermarkten ervan te overtuigen dat onze varkens een beter leven verdienen. Om de intensieve veehouderij een halt toe te roepen, moet de publieke opinie ten gunste van de dieren veranderen.</p>
</idle></content>
</entry>
<entry>
<title>Klaar voor de mobiele tsunami</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/klaar-voor-de-mobiele-tsunami"/>
<updated>2011-12-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/klaar-voor-de-mobiele-tsunami</id>
<content xml:lang="nl" type="html"><p>Als ze het niet nu al doen, wordt 2012 het jaar waarin je klanten je gaan vragen om een mobiele website. Hier zijn wat snelle wenken voor diegenen onder ons die mobiel nog niet echt goed bestudeerd hebben.</p>
<h2>Eerste testen</h2>
<p>Je hebt waarschijnlijk al een smartphone voor prive-gebruik. Kijk er eens op naar je recente projecten. Waarschijnlijk zie je al direct enige zaken die voor verbetering vatbaar zijn. Maak een lijstje, en spreek met jezelf af dat je hier in je volgende project iets aan gaat doen.</p>
<p>Let op: ik zeg hier <em>smartphone</em>, en niet tablet! Voor je eerste tests is een tablet minder geschikt, omdat het scherm niet voldoende afwijkt van dat van desktopcomputers. Een extreem verschil in schermgrootte zet je sneller op het goede spoor dan schermen die slechts iets kleiner dan het gemiddelde desktopscherm zijn.</p>
<p>Maak je nog niet teveel zorgen over representativiteit van je smartphone: zelfs als je uitsluitend een iPhone of Android bezit, kan een snelle test je toch al iets nuttigs vertellen over mobiele websites. De belangrijkste wijziging ten opzichte van een ouderwetse desktop-site is het kleine scherm. Bedenk wat je er qua design en interactie aan wilt doen; later in dit artikel vind je de technische tip die je hiervoor nodig hebt.</p>
<h2>Eén site of meerdere sites?</h2>
<p>Idealiter vraagt je klant je om een geheel nieuwe website die zowel op desktop als op tablet en mobiel werkt. Op deze manier kan je direct aan de slag met nieuwe methodes en technieken—en wordt 't nog betaald ook.</p>
<p>Helaas zullen sommige klanten, vooral de kleinere, je vragen om hun site snel geschikt te maken voor mobiel. Lage kosten zijn hierbij belangrijk, dus je kunt je nog niet betaald wekenlang gaan uitleven.</p>
<p>Er zijn twee basiskeuzes: of met behulp van media queries (die we zodadelijk zullen bespreken) enkele extra CSS-regels voor kleine schermen toevoegen, of een geheel aparte mobiele website opzetten, en mobiele browsers middels een server-side browser detect daar naartoe doorsturen.</p>
<h2>Geen van beide oplossingen is ideaal:</h2>
<ul>
<li>Als je met media queries wat extra CSS invoegt, zorgt dat er wel voor dat de site er acceptabel uitziet, maar kan de site te zwaar blijven voor mobiele connecties. Immers, je kunt een groot plaatje of een video die niet geschikt is voor mobiel wel een snelle <code>display: none;</code> meegeven, maar daarmee voorkom je niet dat de browser het bestand downloadt.</li>
<li>Als je een aparte mobiele website maakt, zondig je tegen het One Web-principe. Het is zelden echt nodig om een aparte site voor mobiel te maken, en het bijhouden van twee sites in plaats van een zorgt ook voor de nodige administratieve traagheid. Een goed CMS kan hier uitkomst bieden, maar ... naja, we weten allemaal hoe het met CMS'en gesteld is.</li>
<li>Bovendien is er voor deze oplossing ook nog een goede browser detect nodig. En die zijn dun gezaaid.</li>
</ul>
<p>Niettemin zullen deze twee tussenoplossingen waarschijnlijk je enige alternatieven zijn tijdens je eerste mobiele opdrachten. Klanten hebben nou eenmaal niet altijd het budget dat eigenlijk nodig is.</p>
<h2>De grote truc</h2>
<p>Het maken van een mobiele site kent vele technische trucs en eigenaardigheden, maar één daarvan steekt met kop en schouders boven de rest uit: de combinatie van 'meta viewport' en <code>width</code> media queries.</p>
<p>Dit werkt als volgt. Allereerst voeg je in de <code>&lt;head&gt;</code> van het document de volgende tag toe:</p>
<pre><code>&lt;meta name=&quot;viewport&quot; content=&quot;width=device-width&quot;&gt;
</code></pre>
<p>Dit beveelt de browser de website zo te tonen dat hij precies op het scherm past en de gebruiker niet hoeft in te zoomen om de inhoud te lezen. De exacte breedte van de site hangt af van het apparaat: een iPhone maakt de site 320 pixels breed, terwijl de verschillende Androids kunnen varieren van 240 tot 480. Tablets nemen meestal een breedte tussen de 600 en 1000 pixels.</p>
<p>De truc hier is dat deze breedte gekozen is door de fabrikant van het apparaat (of de browser), en dat alle fabrikanten tegenwoordig de moeite nemen om deze breedte goed af te stellen. De meta viewport wordt immers al op behoorlijk veel sites gebruikt, en nieuwe apparaten en browsers moeten zorgen dat ze deze sites goed tonen.</p>
<p>Nu krijgt je site dus de ideale breedte op (bijna) alle apparaten. Hierna wordt het tijd voor de tweede grote truc: <code>width</code> media queries. Dat gaat als volgt:</p>
<pre><code>@media all and (min-width: 600px) {
#sidebar {
float: left;
width: 20%;
}
}
</code></pre>
<p>Nu krijgt het element <code>#sidebar</code> een <code>float: left;</code> en een breedte van 20%, maar alleen als de schermgrootte tenminste 600 pixels is. Is dat niet het geval, dan wordt de CSS rule nooit uitgevoerd.</p>
<p>Je zou ook het omgekeerde kunnen doen:</p>
<pre><code>#sidebar {
float: left;
width: 20%;
}
@media all and (max-width: 600px) {
#sidebar {
float: none;
width: auto;
}
}
</code></pre>
<p>Nu wordt in eerste instantie de eerste rule uitgevoerd, maar als de breedte van de site <code>600px</code> of minder is, wordt bij nader inzien <code>float</code> uitgezet en komt de <code>width</code> weer op <code>auto</code> te staan.</p>
<p>Technisch gezien is er geen verschil tussen de twee methodes, maar uit oogpunt van beheersbaarheid verdient de eerste de voorkeur.</p>
<p>De grens van <code>600px</code> is hier slechts een voorbeeld: het zou goed kunnen dat jouw design om net een andere grens vraagt. Ook kan je meerdere grenzen gebruiken; bijvoorbeeld 600 en 900 pixels.</p>
<p>Het is het beste om deze grenzen proefondervindelijk vast te stellen: maak een (ruw) ontwerp, verklein je browservenster, en kijk wanneer het ontwerp echt te lelijk of te onoverzichtelijk wordt. Als dat gebeurt, wordt het tijd een nieuwe grens te definiëren en extra instructies in een media query te zetten.</p>
<p>Als je de meta viewport combineert met de <code>width</code> media query, heb je de voornaamste CSS-stap op weg naar een universele site gezet.</p>
<h2>Browsers</h2>
<p>Zodra je mobile webontwikkelen serieus gaat aanpakken, kom je op de vraag in welke browsers je moet testen. De leidraad is uiteraard de browserverdeling die het statistiekenpakket van je klant laat zien, maar als dat pakket niet zo goed is, geen aparte mobiele statistieken bijhoudt, of helemaal afwezig is, moet je een gok nemen.</p>
<p>Deze gok dien je uiteraard te baseren op algemene Nederlandse mobiele browserstatistieken, en de enige bron hiervoor is <a href="http://gs.statcounter.com/#mobile_browser-NL-yearly-2011-2011-bar">StatCounter</a>. Hieruit blijkt dat iPhone en Android overweldigend dominant zijn: samen hebben ze ruim 80% van de markt in handen. Op grote afstand volgen Nokia, BlackBerry en Opera.</p>
<p>Dus je eerste prioriteit is Safari voor iOS en Android WebKit—waarvan de laatste helaas niet zo'n geweldige browser is. Beide zijn gebaseerd op WebKit en beide ondersteunen CSS en JavaScript goed, maar je zult snel merken dat Android WebKit wat houteriger omgaat met dingen als touch events en animaties.</p>
<p>Wat goed nieuws: Internet Explorer doet er niet toe op mobiel. Het zou kunnen dat de nieuwe Nokia Windows Phones een succes worden, en dan zal je gedwongen worden weer IE tests te doen, maar dat is dan in elk geval op IE9.</p>
<p>Ik raad je ten sterkste aan aan je iPhone/Android basispakket ook <a href="http://www.opera.com/mobile/">Opera Mini</a> toe te voegen: hoewel deze browser niet zo vreselijk populair is in Nederland, leert het webontwikkelen voor Opera Mini je heel veel over het mobiele web.</p>
<p>Opera Mini is een zogenaame proxy browser, wat betekent dat een HTTP request niet direct naar de opgevraagde site gaat, maar naar een Opera Mini-server. Deze server vraagt alle noodzakelijke bestanden op, bouwt de pagina op en stuurt daarna in essentie een plaatje door naar de Opera Mini-client op de telefoon. Het grote voordeel is dat de browser op de telefoon bijna niets hoeft te kunnen, wat betekent dat hij ook kan draaien op een oude (en dus technisch inferieure) telefoon. Bovendien is de data die naar de telefoon gezonden wordt, zeer sterk gecomprimeerd, wat de gebruiker behoorlijk in datakosten kan schelen. Vooral voor mensen die op roaming zijn aangewezen, is Opera Mini een uitkomst. (Ikzelf gebruik hem altijd in het buitenland, en tegenwoordig meestal ook terwijl ik in Nederland ben. Zelfs op mijn iPhone.)</p>
<p>Opera Mini ondersteunt wel JavaScript, maar elke JavaScript function call vereist een nieuw request aan de Opera Mini-server, die berekent hoe de nieuwe pagina er uit komt te zien en het resultaat weer doorstuurt. Er is dus geen client-side interactiviteit mogelijk.</p>
<p>Dit alles zorgt er voor dat je van het ontwikkelen voor Opera Mini meer leert dan van ontwikkelen voor iPhone en Android, en daarom raad ik iedereen aan deze browser in hun lijstje op te nemen.</p>
<p>BlackBerry heeft vanaf OS6 een nieuwe, uitstekende browser die op WebKit gebaseerd is. Hij is, na Safari, de beste mobiele browser die er is, dus hier hoef je geen problemen te verwachten. Helaas geldt dit niet voor de oude BlackBerry browser op OS5 en lager: vooral JavaScript is hier vrijwel niet mogelijk wegens volstrekte afwezigheid van performance. Mocht je een complex script schrijven, gebruik dan een harde browser detect om het script voor BlackBerry 5 en lager geheel uit te schakelen.</p>
<p>De Nokia-browser, tenslotte, is ook op WebKit gebaseerd, en is redelijk, maar niet overweldigend goed. Als deze browser voor je van belang is, zorg er dan voor dat je zowel oude als nieuwe Nokia-toestellen tot je beschikking hebt.</p>
<h2>Toestellen kopen</h2>
<p>Dat brengt ons op het laatste onderwerp: welke toestellen moet je hebben?</p>
<p>Je moet daadwerkelijke mobiele telefoons hebben. Hoewel emulators je kunnen helpen, zijn ze <em>niet goed genoeg</em> voor serieuze mobiele webontwikkelaars. Je moet een telefoon in je handen hebben en er mee werken zoals een gebruiker dat doet, anders kan je je site niet afdoende testen.</p>
<p>Je dient dus budget in te plannen voor de aanschaf van mobiele telefoons. Dit is gewoon een zakelijke uitgave die je uiteindelijk weer aan je mobiele klanten terugverdient.</p>
<p>Als eerste raad ik je aan je te concentreren op iPhone en Android. Waarschijnlijk heb je er daar al een van als je eigen mobiele telefoon.</p>
<p>Het beste is om meteen twee Androids te nemen, aangezien er wat subtiele verschillen zijn tussen de Androids van de verschillende merken. Je kunt bijvoorbeeld een Samsung en een HTC nemen. Zorg er ook voor dat ze verschillende schermgroottes hebben, en dat ze beide verschillen van de iPhone.</p>
<p>Installeer Opera Mini op deze toestellen: de browser is beschikbaar voor iPhone, Android, en nog een boel andere platforms.</p>
<p>Heb je daarna nog geld over, dan is het verstandig aan een Nokia te gaan denken. Kies een redelijk populair Symbian model: veel mensen hebben zo'n telefoon nog op zak, hoewel ze er lang niet allemaal mee surfen. Of je kan gelijk in het diepe springen en een gloednieuwe Windows Phone kopen.</p>
<p>Tenslotte zou je aan een BlackBerry kunnen denken. Koop dan een nieuwe (OS6 of hoger), en je hebt direct de op een na beste mobiele browser tot je beschikking.</p>
<p>Koop ook eens een toestel dat niet alleen maar een touchscreen heeft, maar ook (of alleen maar) een toetsenbord of four-way navigation. Niet alle mobiele gebruikers navigeren per touchscreen, en je zal ook andere input modes moeten leren kennen. Oudere Nokia's en BlackBerry's zijn hier prima geschikt voor.</p>
<p>Ook een tablet zou geen gekke investering zijn. Uiteraard ligt een iPad het meest voor de hand, maar je hebt hier uit testoogpunt niet zo heel veel aan. De browser is exact dezelfde als op de iPhone, dus het enige verschil is de schermgrootte, en dat is iets wat elke tablet je geeft. Denk ook eens aan een Android-tablet (hoewel die niet heel erg fantastisch in het gebruik zijn) of aan een BlackBerry PlayBook (uitstekende browser, en verder helemaal niet slecht, al zou de batterijduur wel wat beter mogen).</p>
<p>Probeer er voor te zorgen dat je tenminste elk half jaar of zo een nieuw apparaat kunt kopen. Niet alleen breid je zo gestaag je collectie uit, maar je kunt ook inspelen op veranderingen in de mobiele markt. Wat als webOS ineens door een grote partij wordt gelanceerd? Of als het mysterieuze Tizen-project toch iets blijkt voor te stellen? In dat geval moet je je kunnen veroorloven een nieuw testapparaat te kopen.</p>
<h2>Tot slot</h2>
<p>Ik hoop dat deze collectie tips je helpt je eerste schreden naar webontwikkeling voor alle apparaten te zetten.</p>
<p>En zeg nou zelf, een dynamisch nieuw ecosysteem met tien operating systems en vijftien browsers is toch veel interessanter dan altijd maar diezelfde vijf saaie desktop-browsers waarvan we ondertussen elk bugje en hikje kennen?</p>
<p>Over Peter-Paul Koch
<img src="https://www.fronteers.nl/_img/2011/12/peter-paul-koch.jpg" alt="Foto van peter paul koch" />
Peter-Paul Koch is oprichter en voorzitter van Fronteers, en houdt de stand van zaken in de chaotische mobiele browsermarkt bij op <a href="http://quirksmode.org/">QuirksMode.org</a>. Hij spreekt in binnen- en buitenland, doet wat consultancy, en werkt gestaag aan zijn mobiele telefooncollectie, die op dit moment uit tweeëntwintig prachtexemplaren bestaat. Zijn volgende leerproces wordt het op het gehoor leren herkennen van mobiele telefoons aan de hand van het geluid dat ze maken als ze op de grond vallen.</p>
<p>Donatie: <a href="https://www.bof.nl/">Bits of Freedom</a>
Waarom Bits of Freedom? Omdat digitale burgerrechten steeds belangrijker worden.</p>
</content>
</entry>
<entry>
<title>Learn you a Flexbox for Great Good!</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/learn-you-a-flexbox-for-great-good"/>
<updated>2011-12-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/learn-you-a-flexbox-for-great-good</id>
<content xml:lang="nl" type="html"><p>Dus...je wilt iets weten over Flexbox; misschien heb je er wel eens van gehoord, of misschien heb je één van de vele <a href="http://www.the-haystack.com/2010/01/23/css3-flexbox-part-1">tutorials</a> erover gelezen. Het kan zelfs zijn dat je er al mee gewerkt hebt.</p>
<p>Vergeet alles wat je over Flexbox weet: we beginnen opnieuw! De spec is namelijk veranderd; de nieuwste versie verscheen op 29 november 2011!</p>
<h2>Wat heb je nodig?</h2>
<p>Chrome Canary heeft een deel van de spec geïmplementeerd. Als je mee wilt doen heb je niets anders nodig dan Chrome Canary en je favoriete text editor.</p>
<ul>
<li>Chrome Canary: <a href="http://tools.google.com/dlpage/chromesxs">http://tools.google.com/dlpage/chromesxs</a>;</li>
<li>Je favoriete text editor: <a href="http://www.vim.org/">http://www.vim.org/</a> (Relax, <em>relax</em>)</li>
</ul>
<p>Laten we beginnen!</p>
<h2>Wat is Flexbox?</h2>
<p>Flexbox is de roepnaam van CSS Flexible Box Layout Module. Het is één van de CSS Working Drafts dat zich bezighoudt met layout. Flexbox biedt een aangepast <em>box model</em> aan, die voor gebruikersinterfaces is geoptimaliseerd. In het kort: de kinderen van een “box” kunnen horizontaal of verticaal binnen de box worden geplaatst, en de overblijvende ruimte kan worden verdeeld over één of meer van de kinderen. Het nesten van dit soort boxes is ook mogelijk, waardoor complexe layouts mogelijk zijn.</p>
<h2>Pas op!</h2>
<p>Er zijn andere CSS layout modules in ontwikkeling die wellicht veel beter zullen zijn voor algehele pagina-layout! Flexbox is mooi en eenvoudig, maar wordt bij het nesten van veel boxes vrij snel complex. Het is zeker <a href="http://www.xanthir.com/blog/b4580" title="Why Flexboxes Aren't Good for Page Layout">geen oplossing voor alle soorten layout</a>. Maar voor UI-componenten zoals forms, toolbars of kolommen en rijen met inhoudsblokken die anders gefloat zouden zijn, is Flexbox zeker een uitkomst. Flexbox is ook bedoeld om lief te spelen met alle andere aspecten van CSS, dus hebben de flexbox-regels enkel invloed op de kinderen van een flexbox.</p>
<h2>Three Little Boxes</h2>
<p>Als je een beetje lui bent, kun je de <a href="https://www.fronteers.nl/_downloads/2011/flexbox/demo.html">demopagina</a> downloaden en bewerken. Anders...</p>
<p>Open je editor, maak een eenvoudig HTML-document aan met één box (een <code>div</code> in dit geval):</p>
<pre><code>&lt;!DOCTYPE html&gt;
&lt;html lang=&quot;en&quot;&gt;
&lt;head&gt;
&lt;meta charset=&quot;utf-8&quot;&gt;
&lt;title&gt;Flexbox&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;div&gt;
&lt;/div&gt;
&lt;/body&gt;
&lt;/html&gt;
</code></pre>
<p>Prachtig. Maar we willen natuurlijk iets zien, dus moeten we wat stijl toevoegen:</p>
<pre><code>&lt;style&gt;
body &gt; div {
height: 500px;
padding: 1em;
background-color: gray;
}
&lt;/style&gt;
</code></pre>
<p>Nu voegen we drie boxes toe aan onze eerste box. Dit zijn (uiteraard) de kinderen:</p>
<pre><code>&lt;div&gt;
&lt;div&gt;A&lt;/div&gt;
&lt;div&gt;B&lt;/div&gt;
&lt;div&gt;C&lt;/div&gt;
&lt;/div&gt;
</code></pre>
<p>En deze dienen ook wat stijl te krijgen:</p>
<pre><code>div &gt; div {
width: 100px;
height: 100px;
background-color: pink;
}
</code></pre>
<p>Bekijk de pagina in Canary. We zien niets vreemds: de drie block-level elementen zitten netjes onder elkaar, zoals block-level elementen dat doen. Maar daar brengen we verandering in! We hebben een kleine Flexbox-speeltuin gemaakt; nu gaan we er in spelen.</p>
<h2>Het Flexbox Box Model toekennen aan een box</h2>
<p>Wij willen de kracht van Flexbox toepassen op de drie kinderen van onze parent <code>div</code>. Dit wordt gedaan met de <code>display</code> property, jou vast niet onbekend. Door <code>display: flexbox;</code> te geven aan onze parent <code>div</code>, kunnen we de kracht van Flexbox beginnen te gebruiken. Maar stel dat onze parent geen block-level element moet zijn, maar inline? We hebben toch onze <code>display</code> property al in gebruik? Geen paniek, in dat geval gebruiken we <code>display: inline-flexbox</code>. Pfieuw!</p>
<pre><code>body &gt; div {
display: -webkit-flexbox; /* Prefix nog nodig, helaas */
height: 500px;
padding: 1em;
background-color: gray;
}
</code></pre>
<p>Nu wordt het Flexbox Box Model toegepast op onze drie kinder-<code>div</code>s, die wij voortaan <em>flexbox items</em> gaan noemen. Er zijn regels die aangeven wat een flexbox item is; als wij bijvoorbeeld <code>position: absolute;</code> zouden geven aan één kind, dat is dat kind niet meer een flexbox item! Logisch, maar toch. Lees in de spec <a href="http://www.w3.org/TR/css3-flexbox/#flex-items">meer over flexbox items</a>.</p>
<p>Terug naar onze oefening. Kijk even in de browser: omdat de Flexbox default is om de kinderen horizontaal te plaatsen, ziet het er uit alsof wij <code>inline</code>, <code>inline-block</code> of <code>float</code> op deze elementen heb toegepast. Op zich niets bijzonders, behalve het feit dat wij geen stijlen aan de kinderen hebben moeten toevoegen om dit effect te krijgen.</p>
<h2>Source-order onafhankelijkheid</h2>
<p>De naam “Flexible Box Module” komt van de mogelijkheid om flexibel om te gaan met resterende ruimte binnen een box. Dit is werkelijk fantastisch, maar Flexbox biedt iets dat minstens zo belangrijk is: source-order onafhankelijkheid. Laten we spelen met nog een paar Flexbox properties om de volgorde van onze flexbox items te manipuleren.</p>
<pre><code>body &gt; div {
display: -webkit-flexbox;
-webkit-flex-flow: row-reverse;
height: 500px;
padding: 1em;
background-color: gray;
}
</code></pre>
<p>OMG. Onze flexbox items zijn rechts uitgelijnd, en de volgorde is omgedraaid! Dit doen we met de <code>flex-flow</code> property, die een default van <code>row</code> kent. <code>row-reverse</code> draait alles precies andersom. Naast <code>row</code> en <code>row-reverse</code> zijn er ook <code>column</code> en <code>column-reverse</code>. Probeer <code>column</code> even uit (<code>column-reverse</code> is nog niet geïmplementeerd), en zet daarna de waarde weer op <code>row</code> voor onze volgende stap.</p>
<p>Overigens, <code>flex-flow</code> accepteert ook een waarde voor het “wrappen” van flexbox items naar nieuwe “rows” (of columns, afhankelijk van de waarde die je gebruikt); <code>wrap</code> of <code>wrap-reverse</code> zijn echter nog niet in Canary geïmplementeerd. Ik zal dat wel eens vaker moeten zeggen. In elk geval, stel dat we <code>wrap</code> nu konden gebruiken, dan zouden we zoiets kunnen gebruiken:</p>
<pre><code>body &gt; div {
display: -webkit-flexbox;
-webkit-flex-flow: row wrap; /* `wrap` zorgt voor een multi-line flexbox. */
height: 500px;
padding: 1em;
background-color: gray;
}
</code></pre>
<h2>Spiegel, spiegel...</h2>
<p>Alle properties die te maken hebben met de volgorde, richting of uitlijnen van flexbox items worden beïnvloed door de huidige <em>writing mode</em>. De writing mode is de oorspronkelijke layoutrichting van de tekst. De meesten van ons in Nederland zijn boven-naar-onderen, links-naar-rechts gewend. Maar zodra wij dat spiegelen, gaan onze properties dat ook doen. In je voorbeeldbestand heb je al kunnen zien wat <code>row-reverse</code> doet. Maar stel dat je writing mode niet de default (top-bottom, left-right) is maar juist (top-bottom, right-left)? Dan zijn je flexbox items <em>in eerste instantie</em> al omgekeerd geplaatst. <code>row-reverse</code> draait dit om, en plaatst ze juist van links naar rechts.</p>
<p>Probeer het uit:</p>
<pre><code>body &gt; div {
display: -webkit-flexbox;
direction: rtl; /* De `writing-mode` property heeft momenteel geen visueel effect in Canary. Dit werkt voor ons voorbeeld. */
-webkit-flex-flow: row;
height: 500px;
padding: 1em;
background-color: gray;
}
</code></pre>
<p>Verander <code>row</code> nu in <code>row-reverse</code>. Zie je wat er gebeurt?</p>
<p>Verwarrend? Een beetje, maar over het algemeen zullen de meeste developers kunnen uitgaan van de default writing mode.</p>
<p>Om te begrijpen welk effect een aantal Flexbox properties hebben op flexbox items is het belangrijk om te begrijpen wat de <em>main axis</em> en <em>cross axis</em> zijn. De <em>main axis</em> is de as waarop de flexbox items worden geplaatst. Met andere woorden, als de flexbox items horizontaal (<code>row</code>, dus) worden geplaatst, dan is de horizontale as de <em>main axis</em>. Verticaal is dan de <em>cross axis</em>. Bij verticaal geplaatste flexbox items is dat precies andersom: de <em>main axis</em> is verticaal en de <em>cross axis</em> is horizontaal.</p>
<p>Mja. Dat is lastig uitleggen. Laten we een plaatje tekenen:</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/axis.png" alt="Bij horizontaal geplaatste items is de main axis horizontaal." /></p>
<p>Onthou main axis en cross axis; we komen er straks op terug.</p>
<h2>Order! Order in the court!</h2>
<p>Laten we kijken naar een andere property die belooft dat <em>source order</em> ooit onbelangrijk wordt: <code>flex-order</code>.</p>
<p>In je voorbeeld code, zorg ervoor dat je <code>flex-flow</code> op <code>row</code> hebt gezet, en <code>direction: rtl;</code> hebt verwijderd. Als het goed is, heb je drie flexbox items, A, B en C, linksboven in <code>body &gt; div</code>. Stel je voor dat we die volgorde niet goed vinden; we willen juist A-C-B. Hiervoor gebruiken we <code>flex-order</code>:</p>
<pre><code>div &gt; div:nth-child(2) { /* Ja, je zou een class of ID ook kunnen gebruiken, maar goed. */
-webkit-flex-order: 1;
}
</code></pre>
<p>Kijk maar even in je browser; de volgorde van de flexbox items zou nu A-C-B moeten zijn.</p>
<p><code>flex-order</code> plaatst flexbox items in <em>geordende groepen</em>. Boxes zonder expliciete <code>flex-order</code> zitten in groep 0, en blijven in volgorde van broncode. In dit geval wordt de tweede <code>div</code>, B, in groep 1 geplaatst. A en C blijven in groep 0, in broncode volgorde (A-C dus). Als we B-A-C wilden, dan hadden we B in groep 0 kunnen laten, en A en C in groep 1 kunnen plaatsen:</p>
<pre><code>div &gt; div:first-child,
div &gt; div:last-child {
-webkit-flex-order: 1;
}
</code></pre>
<h2>Flexibiliteit</h2>
<p>Eén van de mooiste aspecten van Flexbox is waar de naam vandaan komt: flexibiliteit. Wij kunnen bepalen wat er met overblijvende ruimte in onze <code>body &gt; div</code> (in dit geval) gebeurt. We kunnen het verdelen tussen de flexbox items, of we kunnen één of meer van de flexbox items <em>flexible maken</em> om die ruimte te gebruiken. Laten we eerst naar flexibiliteit kijken, dan komen we zo terug op het verdelen van de ruimte.</p>
<p>Stel dat onze drie flexbox items knoppen zijn in een web app, die ook voor mobiel zal worden gebruikt. Soms hebben we er drie, en soms hebben we er twee. Wij willen eigenlijk zeggen: “Het maakt niet uit hoeveel van jullie er zijn, ik wil dat jullie allemaal even groot worden, en alle beschikbare ruimte gebruiken.” Zoiets zonder Flexbox wordt bijna uitsluitend met JavaScript gedaan. Maar kijk wat er gebeurt als wij onze flexbox items flexibel maken met de <code>flex()</code> functie:</p>
<pre><code>div &gt; div {
/* width: 100px; */
width: -webkit-flex(1 0 100px);
height: 100px;
background-color: pink;
}
</code></pre>
<p>De <code>flex()</code> functie kan als waarde voor <code>width</code> en <code>height</code> worden toegepast. <code>flex()</code> accepteert drie waarden: positieve flex, negatieve flex en <em>preferred size</em>. De laatste twee waarden hoefde ik niet te geven; 0 is de default voor negatieve flex en 0px is de default voor <em>preferred size</em>. In elk geval werkt <code>flex()</code> als volgt:</p>
<ol>
<li>De flexbox items krijgen de <em>preferred width</em>;</li>
<li>Als er dan nog ruimte over is in de parent, wordt die ruimte verdeeld aan de hand van de positieve flex waarde;</li>
<li>Als de flexbox items op preferred width overflow veroorzaken (ze zijn gezamenlijk breder dan de parent), dan wordt de negatieve flex waarde gebruikt. Let wel, de negatieve flex waarde is een positief cijfer (bijv. 2 en niet -2).</li>
</ol>
<p>Een positieve waarde van 1 betekent min of meer “een gelijk deel van de beschikbare ruimte”. Een waarde van 2 zou betekenen “twee keer zoveel als de ruimte die items met <code>flex(1)</code> hebben”. Niet helemaal ”twee delen whisky, één deel cola” dus. Laten we het proberen. Typ de volgende code in <em>onder</em> je regels voor <code>div &gt; div</code>:</p>
<pre><code>div &gt; div:first-child,
div &gt; div:last-child {
width: -webkit-flex(2);
background-color: magenta; /* Hierdoor kunnen we het verschil iets beter zien. Plus, het doet zeer aan je ogen. */
}
</code></pre>
<p>Als je nu in je browser kijkt, zie je dat de eerste en de laatste flexbox items niet twee delen van de beschikbare ruimte hebben, maar <em>twee keer zoveel</em> als de middelste, die <code>flex(1)</code> heeft. Ben jij niet blij dat je dit niet in een browser hoeft te implementeren?</p>
<p>Let wel, dit betekent ook niet dat de twee buitenste flexbox items <em>twee keer zo breed</em> zijn als de middelste. Het gaat alleen om hoe de beschikbare ruimte in de parent wordt toegevoegd aan de breedte van de flexbox items.</p>
<p>Verwijder die regels weer. Haal nu één van de <code>div</code>s weg en kijk wat er dan gebeurt. Zet haar daarna terug, want we hebben haar nog nodig.</p>
<p>Er zijn veel meer details over <code>flex()</code>, en ook over de andere properties. Deze vind je allemaal in de spec. Heerlijk leesvoer na een avondje stappen.</p>
<h2>Het uitlijnen van flexbox items</h2>
<p>Heb je alles onthouden over main axis en cross axis? Mooi. <code>flex-pack</code> bepaalt namelijk het uitlijnen van elementen langs de main axis. In ons voorbeeldbestandje is dat horizontaal. Om dit effect goed te bekijken, halen we <code>flex()</code> weg en zetten we de <code>width</code> weer op <code>100px</code>:</p>
<pre><code>div &gt; div {
width: 100px;
height: 100px;
background-color: pink;
}
</code></pre>
<p><code>flex-pack</code> accepteert vier waarden: <code>start</code>, <code>end</code>, <code>justify</code> en <code>center</code>. Heel helder. Laten we ze centreren. Dit doen we op de parent:</p>
<pre><code>body &gt; div {
display: -webkit-flexbox;
-webkit-flex-flow: row;
-webkit-flex-pack: center; /* &lt;-- */
height: 500px;
padding: 1em;
background-color: gray;
}
</code></pre>
<p>Speel met de andere waarden totdat je het leuk vindt.</p>
<p>Uiteraard is er een property die het uitlijnen regelt op de <em>cross axis</em>: <code>flex-align</code>. De mogelijke waarden verschillen een beetje, maar het grootste verschil is dat <code>flex-align</code> op de <em>flexbox items</em> wordt toegepast en niet op de flexbox zelf (m.a.w. niet op de parent).</p>
<pre><code>div &gt; div {
width: 100px;
height: 100px;
background-color: pink;
-webkit-flex-align: center; /* Ook: start | end | baseline | stretch &lt;-- Probeer deze waarden ook! */
}
</code></pre>
<p>Niet alle waarden werken nog in Canary, maar je kunt ervan uit gaan dat naarmate de spec definitief wordt, de implementatie vrij snel zal komen. Er is heel veel belangstelling voor Flexbox onder de browsermakers!</p>
<h2>Genoeg! Tijd om te spelen</h2>
<p>Er zijn nog een paar properties die te maken hebben met multi-line flexboxes, maar omdat we de meeste dingen daarvan niet kunnen uitproberen, laten we het hierbij. Hopelijk hebben we hier voldoende behandeld dat je met Flexbox kunt spelen. Probeer na te denken over mogelijke toepassingen. Hoe zou je Flexbox in kunnen zetten bij een “responsive design”? Welke mogelijkheden biedt dit voor het stijlen van formulier layout? Navigatie?</p>
<p>Dit soort specs zijn geweldig om mee te experimenteren. En ondersteuning komt sneller dan je misschien denkt.</p>
<p>Veel plezier ermee (en fijne feestdagen) :)</p>
<h2>Over Stephen Hay</h2>
<img src="https://www.fronteers.nl/_img/2011/12/stephen-hay.jpg" alt="Foto van stephen hay uit 2011" class="floating-portrait" />
[Stephen](https://twitter.com/stephenhay) is een designer/developer met een sterke interesse in CSS en multi-platform design. Hij spreekt en schrijft ook graag over deze onderwerpen.
<p>Donatie: ICCF Holland
Overal (en veel in ons vakgebied) kun je zien dat de inspanningen van enkelingen en kleine groepen mensen een groot verschil kunnen maken. <a href="http://iccf-holland.org/">ICCF Holland</a> is ook zo'n groep: vrijwilligers die kinderen helpen in Kibaale, Uganda. Als je de Vim text editor gebruikt, dan heb je er vast van gehoord: Vim is “charityware”; gebruikers worden gevraagd om een donatie te doen aan ICCF Holland.
Het project is kleinschalig, en dat spreekt mij erg aan. 99% van al het gedoneerde geld gaat naar het project. Mocht je meer willen weten over dit project: op de website kun je foto's van het project zien en bezoekverslagen lezen.</p>
</content>
</entry>
<entry>
<title>Het platform bouwen</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/het-platform-bouwen"/>
<updated>2011-12-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/het-platform-bouwen</id>
<content xml:lang="nl" type="html"><p>&quot;Dat kan beter.&quot; Zo dacht ik zeven jaar geleden over de standaarden voor het web. En eerlijk gezegd, dat is niet echt veranderd. De omvang wel. Toen hadden we qua standaarden HTML, CSS, JavaScript, beetje HTTP, en XML leek belangrijk, maar niemand gebruikte het. Nu is HTML een parser, syntax, taal, omvat het video, audio, en offline applicaties. CSS bestaat uit over dertig min of meer onafhankelijk ontwikkelde componenten, van verticale text layout tot arbitraire matrixtransformaties, van animaties tot kleuren met alpha-kanaal. En het aantal JavaScript API's is enorm gegroeid, met als doel de traditionele computerplatformen te vervangen. Dat JavaScript zo'n honderd keer sneller is geworden helpt daar natuurlijk in mee.</p>
<p>De complexiteit van standaarden is enorm toegenomen. Zo las een standaard eerst als een redelijk technische introductie tot een onderwerp, nu bevat een standaard algoritmes en gedetailleerde eisen om te zorgen dat software op dezelfde manier werkt. Navigatie, garbage collection (het verwijderen van ongebruikte objecten uit het geheugen van de computer), laden van pagina's met een onbekend MIME type, de volgorde van events relatief tot netwerkactiviteit; alles wordt keurig uitgewerkt. De huidige HTML specificatie vertelt hoe een byte stream, die over het netwerk binnenkomt, wordt omgezet in een set Unicode karakters. Deze worden vervolgens omgezet in tokens en daarvan wordt de DOM opgebouwd. Zo weet iedereen dat <code>&lt;image&gt;</code> een <code>&lt;img&gt;</code> element wordt.</p>
<p>De benodigde precisie vloeit voort uit te de talloze problemen die onnauwkeurige specificaties uit het verleden veroorzaakt hebben. Elke browser implementeerde de ambiguïteiten in specificaties op een andere manier, wat er toe leidde dat pagina's en code niet op dezelfde manier werkten. Een ander probleem was dat developers vaak fouten maakten in hun code en deze code alleen testten in de dominante browser. <code>width: 20</code> werkte prima daarin en dus veranderden ze er verder niets aan. Er was nergens beschreven wat <code>width: 20</code> moest doen en als gevolg werkte het net als <code>width: 20px</code> in sommige browsers en in andere deed het niets.</p>
<p>Binnen het W3C begon de CSS groep hiermee. Grote delen van CSS 2.0 werden herschreven in een revisie, CSS 2.1 genaamd. Deze revisie beschreef de features van CSS in groter detail en hield rekening met het feit dat features incorrect gebruikt konden worden. Dat gaf ook gelijk een extensie-pad voor CSS, want nieuwe features zijn niets meer dan incorrect gebruikte oude features (<code>color: rgba(7, 6, 42, 0.5)</code> was bijvoorbeeld ooit incorrect gebruik van de <code>color</code> property).</p>
<p>Opschonen van HTML en de DOM begon buiten het W3C, in de WHATWG, en is inmiddels een coöperatieve onderneming. En door het beter definiëren (en daardoor ook vollediger begrijpen) van de fundamentele aspecten van het platform, zoals het <code>Window</code> object, de same origin policy, en parsen van HTML, wordt het een stuk gemakkelijker om nieuwe features toe te voegen. Zo kun je nu ook SVG en MathML direct in HTML gebruiken, zonder al te veel gedoe.</p>
<pre><code>&lt;!DOCTYPE html&gt;
&lt;title&gt;SVG in HTML!&lt;/title&gt;
&lt;p&gt;A circle:&lt;/p&gt;
&lt;svg viewBox=&quot;0 0 1 1&quot; width=&quot;100px&quot;&gt;
&lt;circle cx=&quot;.5&quot; cy=&quot;.5&quot; r=&quot;.5&quot; /&gt;
&lt;/svg&gt;
</code></pre>
<p>Features toevoegen aan het platform gebeurt redelijk informeel. En belangrijker, het is nu gemakkelijker dan ooit tevoren om er aan deel te nemen. De groepen die bij het W3C en de WHATWG werken aan API's, CSS, en HTML, hebben allemaal publieke mailing lists waar iedereen aan kan deelnemen. Wanneer je een voorstel wilt doen, is het belangrijk om hier op te letten:</p>
<ul>
<li>Vraag niet om een feature, maar leg je probleem uit. Bij het ontwikkelen van features kijken we altijd naar de achterliggende scenario's (&quot;use cases&quot;) en werken we vanaf daar naar een oplossing. Wel &quot;ik wil Japanse karaoke kunnen weergeven&quot;; niet &quot;ik wil vertical text rendering&quot;.</li>
<li>Kun je om je probleem heen werken en doen mensen dat in de praktijk? Timeout ondersteuning voor XMLHttpRequest werd al volop gedaan in het wild, maar vereiste een hoop extra code. Om het makkelijker te maken voor iedereen hebben we XMLHttpRequest uitgebreid met timeout ondersteuning. Andere problemen, zoals het ondersteunen van de camera van de gebruiker, zijn compleet nieuwe functionaliteit en waren eerder onmogelijk, tenzij gebruik werd gemaakt van plugins.</li>
<li>Breng je probleem ter discussie. Leg het voor aan collega's, fora, IRC, en verfijn het gebaseerd op de reacties die je krijgt.</li>
</ul>
<p>Hierdoor, en uiteindelijke iteratie over mogelijke features die het probleem oplossen, middels specificatie, implementatie, discussie, en uitproberen door web developers, wordt het platform steeds een stukje beter. En kun je morgen iets meer problemen oplossen dan vandaag. Succes ermee! ;-)</p>
<h2>Over Anne van Kesteren</h2>
<img src="https://www.fronteers.nl/_img/2011/12/anne-van-kesteren.jpg" alt="Foto van anne van kesteren" />
[Anne van Kesteren](http://annevankesteren.nl/) chillt 'm in Utrecht wanneer hij niet ergens anders is en bouwt aan het platform. Momenteel druk met [XMLHttpRequest](http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html), [Cross-Origin Resource Sharing](http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html), en de nieuwe [DOM](http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html) standaard. Hij werkt voor [Opera Software](http://www.opera.com/), een browsermakertje uit Noorwegen.
<p>Donatie: <a href="https://www.eff.org/">Electronic Frontier Foundation</a>
Mijn goede doel keuze is de Electronic Frontier Foundation omdat het beschermen van onze vrijheden en privacy op het internet enorm belangrijk is. Ik match dan ook de donatie van Fronteers.</p>
</content>
</entry>
<entry>
<title>Clients from heaven</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/clients-from-heaven"/>
<updated>2011-12-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/clients-from-heaven</id>
<content xml:lang="nl" type="html"><p>Deze adventskalender is eigenlijk één grote aanloop naar goede voornemens voor het nieuwe jaar. Want naast meer sporten en minder drinken beloven we onszelf ook dat we eindelijk eens een <a href="https://www.fronteers.nl/blog/2011/12/een-tik-op-de-neus">goede responsive site</a> gaan bouwen, <a href="https://www.fronteers.nl/blog/2011/12/javascript-pret-met-alle-karakters-in-een-string">Javascript pro</a> gaan worden en alleen nog maar <a href="https://www.fronteers.nl/blog/2011/12/html5-video-een-overzicht">HTML5 video players</a> zullen inbouwen.</p>
<p>Voor veel Fronteers is er echter één persoon die ons die kans geeft. En die komt toch wat minder in de lijst met goede voornemens voor. Nee, niet de Kerstman … de klant.</p>
<p>En terecht. Want die klant is te dom voor woorden. Begrijpt niets van ons ontwerp. <a href="http://clientsfromhell.net/" title="Clients from hell">Stelt onredelijke eisen</a>. Levert maar geen content aan. Is nooit blij met het eindresultaat. En blijft je achtervolgen.</p>
<p>Tenminste, als je de berichtgeving uit onze industrie soms mag geloven. Klantwerk lijkt te worden ervaren als een vervelend bijverschijnsel om websites en apps te mogen bouwen.</p>
<h2>Zonde!</h2>
<p>Het werken met klanten ervaar ik juist als één van de leukste onderdelen van mijn werk. Eigenlijk heeft die klant, als je eenmaal luistert, af en toe best wel goede ideeën ... Beter gezegd, die invloeden van 'buitenaf' zorgen juist voor veel inspiratie en nieuwe inzichten. Maar voordat je daar wat mee kan, zal je het eerst goed moeten inrichten. De afgelopen jaren zijn we daar op mijn werkplek uitgebreid mee bezig geweest. Er is genoeg ruimte voor verbetering, maar ik geloof wel dat we de goede, klantvriendelijke weg zijn ingeslagen.</p>
<p class="note">
Note: ik spreek uit het perspectief van werken bij een bureau. Voor freelancers/zzp'ers of bureaus met weinig personeel in dienst zal niet alles even toepasbaar zijn.
</p>
<h2>Geen fffffuuuuuuuuuunctioneel ontwerp</h2>
<p>Net als veel andere bureaus zijn we in de afgelopen jaren overgestapt naar een 'agile' manier van werken, met SCRUM als bekendste vorm. Op de verschillende agiletechnieken wil ik in dit artikel niet ingaan, alhoewel het <a href="http://agilemanifesto.org/">agile manifesto</a> zeker een A4-printje + punaise waard is.</p>
<p>De kern is dat er niet meer vooraf tot in detail wordt vastgelegd wat er gebouwd gaat worden. Met de klant worden in plaats daarvan de belangrijkste 'user stories' verzameld en geprioriteerd. De exacte invulling van deze user stories vindt plaats tijdens het ontwikkeltraject, met een vast team, waardoor volop gebruik gemaakt kan worden van de verschillende expertises.</p>
<p>Door deze opzet blijft het mogelijk om de invulling aan te passen aan nieuwe inzichten en prioriteiten.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/product-backlog.jpg" alt="User Story, User Story aan de wand, wat heeft de hoogste prio van het land?" /></p>
<p class="note">
Post-its maken niet alleen voor het team, maar ook de klant, duidelijk wat er nog moet gebeuren.
</p>
<h2>Voortraject</h2>
<p>Maar voordat er überhaupt iets in een team belandt, dient de klant overtuigd te worden van bovenstaande werkwijze.</p>
<p>De klant verliest immers zijn gevoel voor veiligheid ten opzichte van een in beton gegoten en ondertekend functioneel ontwerp. Er staat niet meer vast wat er gebouwd gaat worden. Daartegenover staat ruimte voor nieuwe inzichten én niet geheel onbelangrijk: de kosten en doorlooptijd staan wél vast.</p>
<p>Dit lijkt lastig te verkopen, maar het gros van de klanten wordt hier enthousiast van. De meeste klanten hebben al de nodige traumatische IT-ervaringen achter de rug, compleet met beloftes die niet zijn waargemaakt, grote investeringen in logge CMS'en, contractgesteggel en uit de hand gelopen doorlooptijden. Zo veilig bleken de functioneel ontwerpen niet te zijn.</p>
<p>Het voortraject is dan ook cruciaal voor een succesvol vervolg. Als hier valse beloftes worden gedaan, die haaks staan op de werkwijze, zal dat het project blijven achtervolgen.</p>
<h2>Ontwikkeling</h2>
<p>De periode waarin 'gebouwd wordt', was traditioneel het lastigste deel voor de opdrachtgever. Het designgedeelte vond de klant nog wel leuk, maar daarna verdween het project voor lange duur in een grote black box. Een duistere wereld vol onbekende talen en codeschrijvende bebaarde mannen die een voorliefde hebben voor unicorns, double rainbows en <a href="http://www.nl.reddit.com/r/fffffffuuuuuuuuuuuu/" title="fffffffuuuuuuuuuuuu">rage faces</a>.</p>
<p>Het klantcontact bestond vooral uit af en toe even meegluren en het alvast in ontvangst nemen van excelsheets met puntenlijstjes …</p>
<p>Die tijden zijn gelukkig voorbij.</p>
<p>We hebben geen afdelingen meer, er wordt gewerkt in vaste teams van 4 à 5 man met meerdere disciplines (visual design, front-end, back-end, drakendoders en teamleiding). Het team werkt in vaste ontwikkelrondes (meestal twee weken) gezamenlijk voor één klant. Elke dag start met een korte statusupdate van alle teamleden.</p>
<p>Het team maakt een inschatting van de user stories waardoor de klant op de eerste dag van de ontwikkelronde (sprint) weet wat hij twee weken later als demo te zien krijgt. Elke sprint levert een werkend product op.</p>
<p>Hier hebben we uiteraard allerlei sektarische rituelen en gebruiken voor, maar over agile/scrum zijn al genoeg boeken geschreven. Het belangrijkste: we verwachten van de klant dat hij enkele dagen met het team meewerkt. Bij de inrichting van ons pand hebben we er zelfs rekening mee gehouden dat klanten altijd kunnen aanschuiven bij het team. De klant wordt (tijdelijk) collega.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/mangrove-werkplek.jpg" alt="Werkplek van Team Brutal bij Mangrove" /></p>
<p class="note">
Werkplek van Team Brutal bij Mangrove. [Foto's door WOVOX workplace](http://wovox.com/workplace/mangrove-internetbureau/rotterdam/mangrove#mangrove-internetbureau-45 "Mangrove op WOVOX").
</p>
<p>Hoe beter de klant het team kan ondersteunen en input kan geven, hoe beter het eindresultaat. Klanten helpen bijvoorbeeld met vullen van content of openstaande vragen te beantwoorden. De grootste reden is echter dat de klant mede-eigenaar wordt van beslissingen. Tijdens zijn aanwezigheid heeft hij een actieve bijdrage bij het oplossen van design, code en interactievraagstukken.</p>
<p>Bij oplevering is dát het grote verschil. Het project komt niet out-of-the-blue op de klant zijn bordje liggen, met voor hem onverklaarbare keuzes en oplossingen.</p>
<h2>Overtuig de klant</h2>
<p>Het zal niet altijd goed gaan. Sommige mensen komen afspraken niet goed na, zitten vast in een organisatie of passen als klant echt niet bij je. Maar vaak ligt de oorzaak bij onszelf. We zijn er dan te veel van uit gegaan dat de klant precies wist wat van hem verwacht werd. Zorg dat je je eigen proces in orde hebt en je verwachtingen aan de klant kan overbrengen. Vervolgens is het belangrijkste om flink de tijd te nemen om klanten te overtuigen van je keuzes als hij ergens niet achter staat of een andere oplossing 'eist'.</p>
<p>De meeste problemen ontstaan doordat je de klant niet hebt weten te overtuigen. En overtuigen doe je door goede concept- en eindpresentaties, hem te betrekken bij keuzes en vooral door te laten zien dat je met gepassioneerde vakidioten keihard werkt.</p>
<p>En als je het écht goed doet, snappen ze zelfs die wondere wereld van unicorns, double rainbows en lolcatz.</p>
<h2>Over Ruben Bos</h2>
<p>2011/12/ruben-bos.png
Overdag Creative Director bij <a href="http://mangrove.nl/">Mangrove</a>. 's Avonds de wijsneus met zijn alter ego <a href="http://bossingaround.com/">Bossing Around</a>. Half-Iers. Verslaafd aan roze koeken. Schreef ooit een <a href="http://webdesignrules.nl/">boek over webdesign</a> voor opdrachtgevers van websitebouwers. Volg op Twitter: <a href="https://twitter.com/rubenbos">@rubenbos</a></p>
<p>Donatie: Oxfam Novib
Mijn donatie gaat naar de <a href="http://www.oxfamnovibpaktuit.nl/pages/detail/s1/21030000000027-2-21010000000083.aspx">aankoop van 150 mangrovebomen</a>. Want mangroves zijn niet alleen vis- en dierrijke ecosystemen, maar bieden ook levensreddende bescherming tegen erosie en overstromingen.</p>
</content>
</entry>
<entry>
<title>Met 50% korting naar BlackBerry DevCon</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/met-50-korting-naar-blackberry-devcon"/>
<updated>2011-12-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/met-50-korting-naar-blackberry-devcon</id>
<content xml:lang="nl" type="html"><p>Op 7 en 8 februari wordt in de RAI te Amsterdam <a href="http://www.blackberrydevcon.com/europe">BlackBerry DevCon Europe</a> gehouden, dat zich op het BlackBerry platform richt. Voor een congres van een mobiele speler wordt er ongebruikelijk veel aandacht aan het web besteed, en bovendien krijgt elke bezoeker een gratis BlackBerry PlayBook.</p>
<p>Fronteers biedt hierbij aan zijn leden 50% korting op de toegangsprijs aan. De early bird loopt op 23 december af. Registreer je je voor die tijd, dan betaal je niet 250 maar slechts 125 euro.</p>
<p>Er wordt voor interessante websessies gezorgd, al zijn de details bij het ter blogge gaan van dit bericht nog niet helemaal duidelijk. Ikzelf zal in elk geval iets doen.</p>
<p>Even een plug: de BlackBerry browser is, na Safari, de beste mobiele browser die er bestaat, en wat mij betreft zou elke webontwikkelaar er op moeten testen. Bezit van een PlayBook helpt hier natuurlijk behoorlijk bij. Er zijn niet buitengewoon veel apps, maar verder is het een prima tablet dat makkelijk dienst kan doen als test- en surfstation.</p>
<p>Wil je gebruik maken van deze aanbieding en ben je Fronteers-lid, dan kun je een kortingscode opvragen middels een mailtje naar <a href="mailto:krijn@fronteers.nl">krijn@fronteers.nl</a>.</p>
</content>
</entry>
<entry>
<title>Kijk mama, zonder afbeeldingen! Grafische elementen maken met CSS</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/kijk-mama-zonder-afbeeldingen-grafische-elementen-maken-met-css"/>
<updated>2011-12-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/kijk-mama-zonder-afbeeldingen-grafische-elementen-maken-met-css</id>
<content xml:lang="nl" type="html"><p>Zoals Stijn Janssen het al aangaf, <a href="https://www.fronteers.nl/blog/2011/12/waarom-een-slicer-een-front-end-developer-is-geworden">we zijn geen slicers meer</a>. Het idee van een website als een verknipt Photoshop document staat op uitsterven, en wij als front-end developers gebruiken steeds minder gif’s, jpg’s en png’s om onze designs visueel aan te kleden.</p>
<p>Wat is er mis met klassieke afbeeldingen? Wel, het zijn vaak grote bestanden en ze jagen het aantal HTTP requests de hoogte in—of je moet beginnen knoeien met sprites. Elke keer je een pixel wil veranderen moet je weer dat logge programma openen en sterft je CPU een klein beetje. Of probeer die piepkleine site maar eens te zoomen in je fullscreen browser op je 27” monitor, dan krijg je van die wazige pixelsoep. Voor responsive web design moet je soms zelfs verschillende versies van je graphics maken, en halfslachtige technieken gaan aanleren.</p>
<p>Nee, foto’s zullen wel altijd afbeeldingen blijven, maar voor de grafische omkadering zijn er aantal boeiende technologieën opgedoken die vaak veel geschikter zijn. <em>SVG</em> lijkt razend interessant, maar voorlopig nog een beetje een zwarte doos, met <em>canvas</em> worden heel wat grafieken tot leven gewekt, <em>web fonts</em> zijn al helemaal geïntegreerd—we gebruiken ze zelfs voor <a href="http://css-tricks.com/examples/IconFont/">icoontjes</a>—en natuurlijk is er ook <em>CSS</em>.</p>
<h2>Bijsluiter</h2>
<p>Misschien eerst even een woordje over browser support. Een aantal van de volgende technieken werken prima op die gouwe ouwe Internet Explorer 6, andere ga je dan weer enkel kunnen zien in de laatste versie van Chrome bijvoorbeeld. Zoals altijd geldt ook hier het principe van progressive enhancement: begin met een eenvoudige basis die overal werkt en voeg dan laag per laag visuele verfijningen toe, tot je een prachtige ervaring op de modernste platformen hebt! Informatie over ondersteuning van specifieke features vind je natuurlijk op <a href="http://www.caniuse.com/">When Can I Use</a>.</p>
<p>Nu moet je wel goed opletten hoe ver je gaat met het maken van grafische elementen met CSS. In 2010 werden <a href="http://desandro.com/articles/opera-logo-css">enkele</a> <a href="http://graphicpeel.com/cssiosicons">halsbrekende</a> <a href="http://lensco.be/2010/04/04/css-world-clocks">experimenten</a> op poten gezet—een leuke gimmick, maar allesbehalve geschikt voor productie. Nee, we gaan het vandaag hebben over veel kleinere maar daarom niet minder interessante toepassingen.</p>
<h2>Let's go!</h2>
<p>Beginnen doen we bij eenvoudige geometrische vormen. Die kan je rechtstreeks toepassen op eender welk HTML element, maar vaak wordt er gebruik gemaakt van generated content via de <code>:before</code> &amp; <code>:after</code> pseudo-elementen—zo vermijd je onnodig extra elementen toe te voegen aan je HTML. <em>Rechthoeken</em> maak je als web designer elke dag, <em>cirkels</em> zijn goed ingeburgerd via <code>border-radius</code>, en ook <em>driehoeken</em> zijn perfect mogelijk met transparante <code>border</code>s. Die vormen kan je dan weer gaan combineren tot complexere figuren—Chris Coyier heeft er een <a href="http://css-tricks.com/examples/ShapesOfCSS">prachtig overzicht</a> van gemaakt. Zo kan je vrij gemakkelijk deze tooltips maken zonder afbeeldingen of JavaScript:</p>
<p>JSFiddle: <a href="http://jsfiddle.net/lensco/8MbvP/">http://jsfiddle.net/lensco/8MbvP/</a></p>
<p>Die geometrische vormen kan je vervolgends gaan manipuleren en er allerlei effecten op toepassen. Met <em>CSS transforms</em> kan je ze verplaatsen (<code>translate</code>), schalen (<code>scale</code>), draaien (<code>rotate</code>) en scheef zetten (<code>skew</code>). Bijvoorbeeld:</p>
<p>JSFiddle: <a href="http://jsfiddle.net/lensco/NXan9/2/">http://jsfiddle.net/lensco/NXan9/2/</a></p>
<p>Dankzij CSS3 kan je die vormen zelfs inkleuren met <em>gradients</em>, een <em>schaduw</em> of <em>glow</em> geven met <code>box-shadow</code>, <em>animeren</em> met transitions en animations, … de mogelijkheden zijn eindeloos. Waarom nog afbeeldingen gebruiken, als je deze knappe blokjes met geanimeerde drop-shadows gewoon in CSS kan maken?</p>
<p>JSFiddle: <a href="http://jsfiddle.net/lensco/yYQdf/">http://jsfiddle.net/lensco/yYQdf/</a></p>
<p>Het kan natuurlijk nog veel gekker, maar dan begeven we ons wel op experimenteel terrein. Zo kan je bijvoorbeeld met bovenstaande technieken het Shadow DOM gaan stijlen—het verborgen Document Object Model dat je browser genereert voor interface elementen. Beetje bij beetje zijn browserontwikkelaars dat Shadow DOM aan het openstellen, en kan je via pseudo-elementen als <code>::outer-spin-button</code>, <code>::scrollbar-track-piece:vertical</code> en <code>::slider-thumb</code> het uitzicht van een scrollbar of van de nieuwe HTML5 <code>input</code> types gaan personaliseren. Neus eens rond in de broncode van <a href="http://lab.simurai.com/css/umbrui/">Simurai's prachtige umbrUI</a> om een idee te krijgen.</p>
<h2>De toekomst?</h2>
<p>Die laatste demonstratie licht alvast een tipje van de sluier wat de toekomst betreft. De meest boeiende ontwikkelingen zijn momenteel te vinden in de specificaties van CSS <a href="https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/Filters.src.html">Filters</a> en <a href="https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html">Shaders</a>. Samen met enkele browserontwikkelaars zijn bedrijven als Adobe technologieën aan het bedenken die ons hopelijk binnenkort in staat stellen om via CSS effecten toe te passen die we nu eerder met programma's als Photoshop associëren. Denk bijvoorbeeld aan vervagen (blur), grijstinten, ruis toevoegen, enzovoort. Shaders zijn strikt gezien niet eens CSS, maar neem toch eens een kijkje naar de <a href="http://www.adobe.com/devnet/html5/articles/css-shaders.html">indrukwekkende voorbeelden van Adobe</a>.</p>
<p>Heel spannend allemaal, maar ook vandaag al kan je allerlei CSS technieken gebruiken om grafische elementen op te maken, zodat je niet langer je site moet gaan overladen met afbeeldingen. Doen!</p>
<h2>Over Lennart Schoors</h2>
<img src="https://www.fronteers.nl/_img/2011/12/lennart-schoors.jpg" alt="Foto van lennart schoors uit 2011" class="floating-portrait" />
[Lennart Schoors](http://lensco.be/) uit Gent, België werkte meer dan vijf jaar aan sociaal netwerk Netlog, maar is sinds kort freelance interface designer en front-end developer. Schrijft af en toe korte postjes over HTML/CSS op [Bricss](http://bricss.net/).
<p>Donatie: Wikipedia
Wat is de gemakkelijkste manier om dat hoofd van Jimmy Wales uit de header van Wikipedia te kegelen? Hint: niet door erover te klagen op Twitter. Gratis kennis voor de hele wereld, hoera!</p>
</content>
</entry>
<entry>
<title>Het is al goud wiens cursor blinkt</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/het-is-al-goud-wiens-cursor-blinkt"/>
<updated>2011-12-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/het-is-al-goud-wiens-cursor-blinkt</id>
<content xml:lang="nl" type="html"><p>Een pijnlijk vergezochte titel voor een alledaags onderwerp: de opdrachtregel of terminal. Die tekstinterface voor je computer mag dan wel al meegaan van toen de mainframes nog op stoom werkten, tegenwoordig is hij hipper dan ooit. (Een zwart scherm is het nieuwe, euh, zwart.)</p>
<p>Wie al wat langer in dit wereldje meedraait (hier, neem nog een Werthers Echte), heeft de verandering van &quot;slicer&quot; naar &quot;front-end developer&quot; meegemaakt. Vroeger zat er vaak niemand tussen de designer en de ontwikkelaar van een website. Alles was mooi afgelijnd: de designer leverde een hoop geslicete afbeeldingen op en de ontwikkelaar trok er z'n plan mee. Nu komt daar steeds vaker nog een front-ender bij kijken, en die moet van alle markten thuis zijn. In de praktijk betekent dat bijvoorbeeld overweg kunnen met bronbeheersoftware als Subversion en Git, of met allerlei minifiers voor JS en CSS met tal van opties—allemaal uit te voeren op de opdrachtregel.</p>
<p>Om maar te zeggen: het is belangrijk dat je comfortabel je werk kan doen, zonder writer's block. Daarom enkele tips die je het leven in de terminal gemakkelijker maken. Mac- en Linux-gebruikers zitten goed; Windows-gebruikers installeren best eerst <a href="http://www.cygwin.com/">Cygwin</a>.</p>
<h2>1. Word een TiEnErTyPeR</h2>
<p>De Tab-toets is een van de toetsen die je het meest op prijs zal stellen bij het werken op de opdrachtregel. Autocomplete voor map- en bestandsnamen is onmisbaar om snel te werken. Alleen: standaard is die hoofdlettergevoelig, terwijl je Mac- of Windows-schijf daar niet flauw over doet, en je mappen en bestanden ook namen met Hoofdletters hebben. Dus als je <code>cd dow</code> typt, en dat vervolgens met <code>&lt;Tab&gt;</code> automatisch wil aanvullen tot <code>cd Downloads</code>, kom je bedrogen uit.</p>
<p>Bash, de standaardshell, gebruikt de Readline-bibliotheek om je invoer in te lezen. Wat dat precies inhoudt, is niet zo belangrijk. Je moet alleen weten dat je die bibliotheek kan configureren via een <code>.inputrc</code>-bestandje in je gebruikersmap. (De zogenaamde &quot;dot files&quot; zijn configuratiebestanden uit de UNIX-wereld. Je ziet ze standaard niet via de GUI of met een gewone <code>ls</code>, maar met bijvoorbeeld <code>ls -alF</code> wel.)</p>
<p>Zet de volgende regel in je <code>.inputrc</code> zodat <code>cd dOwN&lt;Tab&gt;</code> netjes wordt aangevuld tot <code>cd Downloads</code>:</p>
<pre><code>set completion-ignore-case On
</code></pre>
<p>Daarbij aansluitend zet je dit in je <code>.bashrc</code>, zodat <code>ls -alF *.jpg</code> zowel <code>IMG_1234.JPG</code> als <code>Screenshot 2011-12-01.jpg</code> toont:</p>
<pre><code>shopt -s nocaseglob
</code></pre>
<p>Als die bestandjes nog niet bestaan, kan je ze gewoon aanmaken. De volgende keer dat je je shell (of je terminal) start, worden ze ingelezen.</p>
<h2>2. Word een geschiedenisprof</h2>
<p>Hoe meer tijd je in de terminal doorbrengt, hoe vaker je bepaalde commando's zal herhalen. Gelukkig houdt Bash standaard een aardige geschiedenis bij. Je kan door die geschiedenis bewegen met de pijltjestoetsen: pijltje omhoog toont het vorige commando; pijltje omlaag het volgende. Je kan vorige commando's ook opzoeken door eerst <code>Ctrl+R</code> te drukken en dan een woord in te voeren. Als je bijvoorbeeld <code>Ctrl+R</code> drukt en dan <code>git com</code> typt, zie je je vorige <code>git commit</code>-commando verschijnen. Je kan dan nogmaals op <code>Ctrl+R</code> drukken voor het commando daarvoor, en zo blijven teruggaan in het verleden.</p>
<p>Ikzelf vind het wel gemakkelijk als de pijltjes omhoog en omlaag zich wat intelligenter gedragen. Als je onderstaande code toevoegt aan je <code>inputrc</code>, houdt Readline rekening met wat je al getypt hebt:</p>
<pre><code>## Use more intelligent Up/Down behaviour: use the text that has already been
## typed as the prefix for searching through commands, like in Vim.
&quot;\e[B&quot;: history-search-forward
&quot;\e[A&quot;: history-search-backward)
</code></pre>
<p>Concreet: als je nu <code>git com</code> typt, en dan pijltje omhoog, heb je meteen je vorige <code>git commit</code> te pakken. Of <code>curl what</code> en je krijgt <code>curl whatismyip.org</code>—ervan uitgaande dat je dat al ooit getypt had. (Handige tip, overigens: zo zie je meteen je externe IP-adres.)</p>
<p>Ook in <code>.bashrc</code> voor geschiedenis zijn er enkele handige instellingen. Ik hou wel van deze:</p>
<pre><code>## Als je twee keer `foo` typt, hoeft dat niet twee keer in de geschiedenis.
## Zo vervuil je minder en kan je sneller door de geschiedenis navigeren.
export HISTCONTROL=ignoredups;
## Als je ooit een uitroepteken gebruikt en een onbegrijpelijke foutmelding
## terugkrijgt, is dit commando een redder. Hiermee verschijnt je &quot;foute&quot;
## opdracht netjes opnieuw, zodat je hem gemakkelijk kan bewerken.
shopt -s histreedit;
## Standaard houdt Bash de laatste 500 opdrachten bij. Dat mag meer zijn.
export HISTSIZE=4096;)
</code></pre>
<h2>3. Word een controlefreak</h2>
<p>De shell biedt een heel krachtige manier om je computer te bedienen. Dat is erg prettig, maar missen is menselijk. Daarom, voor je eigen veiligheid, voeg je best een extra controle toe voor je bestanden onherroepelijk verneukt. Immers, als je een bestand kopieert naar een map waar al een bestand met dezelfde naam staat, zal een GUI je wel vragen of je zeker bent, maar de terminal niet. Je moet dat expliciet instellen. Voor <code>cp</code> (&quot;copy&quot;), <code>mv</code> (&quot;move&quot; en hernoem) en natuurlijk <code>rm</code> (&quot;remove&quot;) doe je dat als volgt in <code>.bashrc</code>:</p>
<pre><code>alias cp='cp -i';
alias mv='mv -i';
alias rm='rm -i';)
</code></pre>
<p>Als je nu een keer <code>rm final.css</code> doet, zal je deze vraag krijgen:</p>
<pre><code>remove final.css?
</code></pre>
<p>Deze controle vereist dat je <code>y</code> ingeeft (of <code>yes</code>, of <code>you betcha!</code>, of eender wat met een <code>y</code> vanvoor), of het bestand wordt niet verwijderd.</p>
<h2>4. Word vrolijk</h2>
<p>De standaardprompt (het tekstje dat verschijnt voor jij kan beginnen typen) is niet bepaald geïnspireerd: <code>&lt;computernaam&gt;:&lt;huidige map&gt; &lt;gebruikersnaam&gt;</code>. Dat is op zijn zachtst gezegd beknopt. Het is ook niet handig om te zien waar de uitvoer van je commando's begint en eindigt. Daarom gebruik ik wat kleur. In je <code>.bashrc</code> ziet dat er zo uit:</p>
<pre><code>export PS1=&quot;\[$(tput setaf 4; tput bold)\](\t) \u@\h \W\n\$ $(tput sgr0)&quot;
</code></pre>
<p>Dat is een hele boterham, en in tegenstelling tot wat je moeder altijd zei tijdens het mosselen eten, is het wél nuttig om je voedsel te ontleden:</p>
<ul>
<li><code>PS1</code> is de omgevingsvariabele die je prompt instelt.</li>
<li><code>tput setaf 4</code> zorgt ervoor dat de verdere tekst blauw wordt.</li>
<li><code>tput bold</code> maakt de tekst vet, wat meestal neerkomt op helder gekleurd.</li>
<li><code>\t</code> toont de huidige tijd, zodat je die niet uit het oog verliest.</li>
<li><code>\u@\h</code> is de gebruikersnaam en de computernaam.</li>
<li><code>\W</code> is de huidige map.</li>
<li><code>\n</code> is een nieuwe regel: zo heb je meer plaats voor jouw commando.</li>
<li><code>\$</code> toont de <code>$</code> voor jou en <code>#</code> voor de &quot;root&quot;-gebruiker.</li>
<li><code>tput sgr0</code> zorgt ervoor dat je niet in het blauw zit te smurf—euh, typen.</li>
</ul>
<p>Je kan veel verder dan dit gaan. En dat brengt me naadloos bij de laatste tip.</p>
<h2>5. Word een profiteur</h2>
<p>Deze en vele andere instellingen die je leven in de terminal verbeteren, zijn overal beschikbaar. Gebruik daarom het werk van mensen die je zijn voorgegaan. Enkele bekende voorbeelden van &quot;dot files&quot; beschikbaar op GitHub, zijn die van <a href="https://github.com/gf3/dotfiles">Gianni Chiappetta</a>, <a href="https://github.com/garybernhardt/dotfiles">Gary Bernhardt</a>, en <a href="https://github.com/mathiasbynens/dotfiles">Mathias Bynens</a>. Ondergetekende heeft ook zijn eigen, totaal onbekende verzameling, met de tips uit dit artikel, en veel meer: <a href="https://github.com/janmoesen/tilde">Tilde</a>.</p>
<p>&quot;Good artists copy; great artists pull.&quot;</p>
<h2>Over Jan Moesen</h2>
<img src="https://www.fronteers.nl/_img/2011/12/jan-moesen.jpg" alt="Foto van jan moesen uit 2011" class="floating-portrait" />
[Jan](https://twitter.com/janmoesen) is een webnerd die zich zowel in de browser als op de terminal thuis voelt, en mensen wil doen inzien dat die terminal echt efficiënt is. Dat doet hij op zijn dagtaak als webontwikkelaar, en vanaf begin 2012 ook [op bestelling bij jou](http://tervelo.com/).
<p>Donatie: <a href="http://www.apopo.org/">APOPO</a>
Vroeger vond ik ratten vieze ziekteverspreiders. APOPO heeft dat echter veranderd: zij leiden heroRATs op. Zo'n Rat 2.0 rédt mensenlevens. Ze worden opgeleid om tuberculose—tering!—vast te stellen of om landmijnen op te sporen. Ontmijnen zit er nog niet in, maar mits genoeg fondsen komt er misschien wel een RatGyver?</p>
</content>
</entry>
<entry>
<title>Een tik op de neus</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/een-tik-op-de-neus"/>
<updated>2011-12-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/een-tik-op-de-neus</id>
<content xml:lang="nl" type="html"><p>Een website bouwen op een <em>responsive-design</em>-manier is te vergelijken met aangevallen worden door een haai. Je weet dat je de haai <em>gewoon</em> een tik op zijn neus moet geven maar hoe doe je dat precies? Zo'n haai is ook best imponerend. Dit artikel legt uit hoe je een responsieve site bouwt, hoe je hem opzet. En in onze voorbeeldsite gaan we dieper in op het geven van een tik op de neus van een haai.</p>
<h2>De basis</h2>
<p>De basis van elke responsieve website (van elke website eigenlijk) is natuurlijk de content. <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-11/">Onze site</a> is een eenvoudig HTML document met wat headertjes, wat navigatie, wat paragrafen en wat plaatjes. Deze content gaan we stylen. De beste manier om dit te doen is via de zogenaamde <em>mobile first</em> methode.</p>
<h2>Mobile first</h2>
<p>Als je een bestaande desktop-site gaat optimaliseren voor kleinere resoluties dan is de <em>mobile first</em> aanpak natuurlijk wat lastig, misschien zelfs onmogelijk. In dat geval zou ik een praktische <em>desktop down</em> aanpak hanteren; bezoekers zijn er bij gebaat. Maar als je een nieuwe site bouwt dan heeft het vooral voordelen. Onze site over haaien zullen we dus ook op deze manier opbouwen.</p>
<h2>De viewport</h2>
<p>De <em>viewport</em> is een complex ding. Hoe het precies werkt, ga ik hier niet uitleggen, dat heeft <em>Peter-Paul Koch</em> al gedaan (<a href="http://www.quirksmode.org/mobile/viewports.html">deel 1</a> en <a href="http://www.quirksmode.org/mobile/viewports2.html">deel 2</a>, lees ze vooral als je niet weet hoe de <em>viewport</em> werkt). De <em>viewport</em> is nodig om aan te geven dat een apparaat zijn <em>&quot;fysieke&quot;</em> pixels moet gebruiken en dus niet de desktop-pagina in uitgezoomde toestand moet weergeven. En <em>viewport</em> definieer je in een meta-tag en ziet er als volgt uit:</p>
<pre><code>&lt;meta name=&quot;viewport&quot; content=&quot;width=device-width,initial-scale=1&quot;&gt;
</code></pre>
<p>Er bestaan andere waardes voor het content attribuut; je kan er bijvoorbeeld voor zorgen dat de gebruiker niet kan zoomen, een erg vervelende beperking. Doe dus maar nooit <em>(deze feature wordt wel eens gebruikt om een bug in iOS op te lossen waarbij de pagina vervelend inzoomt als je je apparaat van portret naar landschapsmodus draait. Onthoud goed dat alleen testers en designers hun apparaat wel eens draaien, normale mensen doen dit bijna nooit. Een echte bug is het dus nauwelijks. Overigens treedt deze bug niet op als je geen gebruik maakt van initial-scale)</em>.</p>
<h2>De CSS</h2>
<p><em>Mobile first</em> betekent wat mij betreft gewoon <em>content first</em>. We structureren de content goed en stylen deze zodat hij er prettig uitziet. Zie <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-1/">deze versie van onze haaiensite</a>. Dit zijn stijlen die zowel op kleine als op grote schermen werken, dus zaken als achtergrondkleuren van de body, de verhoudingen van de font-groottes (ja, dat zijn verhoudingen, geen individuele <em>random</em> pixelwaardes), wat marges, het kleurenpallet en eventueel ook wat meer illustratieve zaken, zoals borders en zo. Op welke resolutie je deze versie ook bekijkt, de content is prima toegankelijk. Op brede schermen leest het wat onprettig, maar met een <code>body { max-width: 40em; }</code> <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-2/">is dit opgelost</a> (<a href="https://www.fronteers.nl/_img/2011/12/stap-2.jpg">screenshot</a>). De site is, als je lui bent, af.</p>
<h2>Grotere schermen</h2>
<p>Veel bezoekers hebben een breder scherm waar de content wellicht iets beter tot zijn recht zou komen als we de layout zouden aanpassen. Te denken valt over een layout van meerdere kolommen of bijvoorbeeld een navigatie die bovenaan de pagina staat. De navigatie komen we op terug; we kijken eerst naar de layout. Om bredere schermen te bedienen linken we naar een extra CSS bestand met een <em>media query</em>:</p>
<pre><code>&lt;link rel=&quot;stylesheet&quot; href=&quot;css/layout.css&quot; media=&quot;only screen and (min-width: 50em)&quot;&gt;
</code></pre>
<p>De content bestaat uit een <code>article</code> die begint bij <code>&lt;h1&gt;Aangevallen worden door een haai&lt;/h1&gt;</code>en een <code>aside</code> die begint bij <code>&lt;h1&gt;Wist u dat…&lt;/h1&gt;</code>. In de huidige situatie staan ze gewoon onder elkaar. Door ze als <code>display: inline-block;</code> te stijlen en ze een procentuele breedte te geven, staan ze vanaf een bepaalde breedte ineens naast elkaar. <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-3/">Kijk maar</a> (<a href="https://www.fronteers.nl/_img/2011/12/stap-3.jpg">screenshot</a>). Makkelijk he? <em>Ik gebruik <code>inline-block</code> omdat dat veel prettiger werkt dan floats. Het nadeel is dat pixelperfectie niet echt goed mogelijk is met <code>inline-block</code>. Pixelperfectie doet mij niet zo veel.</em></p>
<h2>Navigatie</h2>
<p>Helemaal rechts bovenaan <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-2/">de pagina</a> staat een letter 'i' in een kadertje. Dit is een klassieke skiplink die je naar de navigatie onderaan de pagina brengt. Op kleine schermen vind ik dit een prima methode. Je zou er eventueel voor kunnen kiezen om de navigatie omhoog te halen als je op de skiplink klikt, dat kan redelijk eenvoudig, <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-4/">kijk maar</a> (<a href="https://www.fronteers.nl/_img/2011/12/stap-4.jpg">screenshot</a>). Voor allebei de oplossingen is wel wat te zeggen. In de tweede versie kan je er van uit gaan dat de gebruiker de footer nooit te zien gaat krijgen, wellicht is dat niet erg.</p>
<h2>Meer pixels</h2>
<p>Als de gebruiker meer pixels tot haar beschikking heeft dan zou je de navigatie natuurlijk gewoon altijd bovenaan kunnen tonen. De standaardpatronen daarvoor zijn een horizontale navigatie bovenaan of een blokje met linkjes links. Ik heb voor een <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-5/">horizontale balk</a> (<a href="https://www.fronteers.nl/_img/2011/12/stap-5.jpg">screenshot</a>) gekozen, je kan vast wel zelf verzinnen hoe je hem elders neerzet, zo moeilijk is het niet. <em>Ik maak hier gebruik van <code>position: absolute;</code> omdat dat zo lekker makkelijk is en omdat ik de hoogte van de header ken. Er bestaan <a href="http://adactio.com/journal/4780/">hacks</a> waarmee het ook lukt als je die hoogte niet kent.</em></p>
<h2>Plaatjes</h2>
<p>Plaatjes zijn makkelijk flexibel te maken: <code>max-width: 100%;</code> en je bent klaar. Het nadeel aan deze techniek is dat mensen met een scherm van 320 pixels breed een plaatje downloaden van 1024 pixels breed en 212KB zwaar. Hetzelfde plaatje is 23KB zwaar als het 320 pixels breed is. Dat scheelt nogal wat, vooral in landen waar bandbreedte duur is. Hier <em>moet</em> dus een oplossing voor verzonnen worden. Helaas bestaan hier geen mooie, eenvoudige oplossingen voor, alle oplossingen die er zijn zijn complex, lelijk en/of onbetrouwbaar.</p>
<p>Omdat ik geen toegang heb tot <em>server-side</em>-technologie bij het artikel over haaien moet ik kiezen voor een <em>client-side-only</em> oplossing. Daar zijn er twee van. De ene is slecht, de andere is lelijk.</p>
<h2>De slechte methode</h2>
<p>We serveren <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-6/">om te beginnen</a> het kleine plaatje. Zo weten we zeker dat gebruikers met een klein scherm geen onnodige KB's ophalen. Voor gebruikers met een groter scherm veranderen we met behulp van <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-6/js/script.js">JavaScript</a> de source van het plaatje in de source van het grote plaatje. Makkelijk en zeer eenvoudig te implementeren. Maar slecht om een paar redenen: browsers met een groot scherm doen <em>twee</em> requests om één plaatje te tonen. Bovendien wordt in dit script gekeken naar de breedte van de <em>viewport</em> om te bepalen of een plaatje vervangen moet worden, het is natuurlijk logischer om te kijken naar de de <em>context</em> van het plaatje. Met <em>context</em> bedoel ik gewoon de omgeving waar het plaatje staat; zijn container.</p>
<h2>De lelijke, onzinnige methode</h2>
<p>Dingen in een <code>noscript</code> tag worden genegeerd door browsers die JavaScript ondersteunen. Als we het kleine plaatje dus in zo'n tag zetten dan krijgen mensen zonder JavaScript het kleine plaatje te zien, mensen mét JavaScript krijgen niks te zien. Met behulp van JavaScript kijken we naar de breedte van de plek waar het plaatje moet komen te staan, we lezen het juiste <code>data</code>-attribuut uit en plaatsen het plaatje op de juiste plek. <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-7/">Tadaa, klaar</a>!</p>
<pre><code>&lt;figure data-src-groot=&quot;img/haai-groot.jpg&quot; data-src-medium=&quot;img/haai-med.jpg&quot; data-src-klein=&quot;img/haai-klein.jpg&quot; data-alt=&quot;Een haai die uit het water springt&quot;&gt;
&lt;noscript&gt;
&lt;img src=&quot;img/haai-klein.jpg&quot; alt=&quot;Een haai die uit het water springt&quot;&gt;
&lt;/noscript&gt;
&lt;/figure&gt;
</code></pre>
<p>De <code>noscript</code> tag is lelijk, het haalt de semantische waarde van het plaatje weg, maar erger nog: het creëert een afhankelijkheid van JavaScript om belangrijke content te tonen. Ik kan er op mijn site wel van uit gaan dat het script wordt uitgevoerd. Ik kan er ook van uit gaan dat het script <em>niet</em> wordt uitgevoerd als iemand het artikel leest in een RSS-reader of een <em>read-it-later-tool</em>. Gebruik deze oplossing dus alleen als je echt niet anders kan.</p>
<h2>De juiste oplossing</h2>
<p>Wat de juiste oplossing is, is geheel afhankelijk van de situatie, geheel afhankelijk van de tool die je aan het bouwen bent. In <a href="http://www.cloudfour.com/responsive-imgs-part-2/">dit artikel van Jason Grigsby</a> worden alle manieren behandeld en alle voor- en nadelen besproken. De conclusie is eigenlijk dat er geen definitieve oplossing voor bestaat. Lees vooral <a href="https://www.fronteers.nl/blog/2011/12/responsive-images-een-experiment">het artikel van Roel Van Gils op het Fronteers blog</a> en alle andere artikelen van Jason Grigsby over dit onderwerp: <a href="http://www.cloudfour.com/responsive-imgs/">deel 1</a>, <a href="http://www.cloudfour.com/responsive-imgs-part-3-future-of-the-img-tag/">deel 3</a>, <a href="http://www.cloudfour.com/what-responsive-img-technique-should-we-teach-in-our-book/">deel 4</a>, <a href="http://www.cloudfour.com/responsive-imgs-choosing-between-semantic-markup-and-working-code/">deel 5</a>, <a href="http://www.cloudfour.com/device-detection-as-the-future-friendly-img-option/">deel 6</a>, <a href="http://www.cloudfour.com/clarification-on-device-detection-for-images/">deel 7</a> en <a href="http://www.cloudfour.com/preferred-solutions-for-responsive-images/">deel 8</a>.</p>
<h2>De finishing touch</h2>
<p>In dit artikel heb ik tot nu toe alleen gekeken naar optimalisatie voor verschillende schermgroottes, maar er is natuurlijk meer waar je voor zou kunnen optimaliseren. Voor <em>touch</em> bijvoorbeeld. Hele grote aanpassingen zijn meestal niet nodig maar een iets hogere <code>line-height</code> is prettig voor mensen met dikke vingers. <em><code>:hover</code> states</em> uitzetten is ook een erg fijne en simpele aanpassing (en <em><code>:focus</code> states</em> toevoegen, nu ik toch bezig ben). Met wat slimme <em>feature detection</em> zijn <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-8/">aparte stijlen voor <em>touch devices</em></a> zo gemaakt. Ik gebruik daar <a href="http://www.modernizr.com/">Modernizr</a> voor, lekker makkelijk en goed getest. Het voegt classes toe aan de <code>html</code>-tag.</p>
<pre><code>&lt;html class=&quot;js no-touch generatedcontent&quot; lang=&quot;nl&quot;&gt;
</code></pre>
<p>Schermen met een hele hoge resolutie zijn misschien wel gebaat bij een andere layout. Je kan denken aan nóg meer kolommen, maar je kan natuurlijk ook gewoon denken aan <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-9/">een groter font</a>.</p>
<p>Als laatste nog een lekker nutteloze tip die het testen van responsieve sites niet makkelijker, maar toch wel <em>leuker</em> maakt: CSS <code>transitions</code> werken niet alleen bij dingen als <code>:hover</code> maar ook bij de overgang van de ene naar de andere <em>media query</em>. Geen normaal mens zal het ooit te zien krijgen maar het testen wordt er wel <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-10/">geiniger/irritanter</a> door.</p>
<h2>De werkwijze</h2>
<p>In dit artikel heb ik alleen maar gekeken naar de verschillende technische aspecten van een responsieve website, de werkwijze heb ik niet echt behandeld. De manier waarop zo'n ontwerp tot stand komt, is anders dan wat we gewend zijn. De ervaring leert me dat het maken van een responsief ontwerp veel meer een iteratief proces is dan het maken van een klassiek pixelplaatje. Visual designers, interaction designers, front-end developers en back-end developers werken tegelijkertijd aan onderdelen van het ontwerp. Oplossingen voor complexe componenten worden verzonnen, uitgewerkt, getest en verbeterd. Hier zou ik een heel artikel over kunnen schrijven, maar waarom zou ik? <a href="http://trentwalton.com/2011/07/14/content-choreography/">Dat heeft Trent Walton al gedaan</a>.</p>
<h2>Oude browsers</h2>
<p>Sommige oude browsers snappen niks van <em>media queries</em>. Er zijn meerdere manieren om hier mee om te gaan. Je kan er natuurlijk voor kiezen om alleen de <em>mobiele</em> layout te tonen aan deze gebruikers, maar je kan ook een <a href="https://github.com/scottjehl/Respond">polyfill</a> gebruiken. Daarnaast kan je mensen mededelen dat ze een verouderde browser hebben en ze informeren over de consequenties die dat heeft en de mogelijkheden die er zijn om te upgraden naar iets moderns. Zo'n scriptje heb ik aan het voorbeeld toegevoegd, gebruikers van IE6, IE7, IE8 en IE9 <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-11/">krijgen het te zien</a> (<a href="https://www.fronteers.nl/_img/2011/12/stap-11.jpg">screenshot</a>). Het grote voordeel van deze laatste optie is dat je niet zo veel tijd hoeft te verspillen aan deze browsers. Het andere voordeel is dat mensen er achter komen dat hun browser verouderd is: mensen weten dit niet omdat wij altijd maar oplossingen voor ze blijven hacken <em>(ja, het is onze schuld dat oude browsers nog gebruikt worden)</em>.</p>
<h2>Complexe content</h2>
<p>Natuurlijk bestaan niet alle sites uit alleen maar navigatie, tekstjes en fotootjes, er zijn ook veel complexere stukken content. Er zijn inmiddels al wel wat oplossingen verzonnen voor <a href="http://css-tricks.com/9096-responsive-data-tables/">data-tabellen</a>, <a href="http://webdesignerwall.com/tutorials/css-elastic-videos">video's</a> (<a href="http://fitvidsjs.com/">alternatieve methode</a>) en <a href="http://artequalswork.com/posts/responsive-ads.php">advertenties</a>. Wellicht is nog niet overal de ideale oplossing voor te vinden. Het enige wat helpt, is creativiteit, het delen van ideeën en gewoon vragen of iemand misschien een oplossing heeft.</p>
<h2>Tot slot</h2>
<p>Een haai een tik op zijn neus geven lijkt eenvoudig, is toch redelijk complex maar is ook goed te overzien, zeker als je het een paar keer hebt gedaan. Ik hoop dat dit artikel je op weg heeft geholpen, niet in het geven van tikken maar wel in het maken van fantastische responsieve designs. Bouw vanuit de content, vanuit de basis, en pas de boel aan aan de mogelijkheden van het apparaat waarmee men toevallig kijkt. <a href="https://www.fronteers.nl/_downloads/2011/haaien/stap-11/">Het voorbeeld wat ik heb gemaakt</a> is natuurlijk erg eenvoudig, dat kan je zelf vast veel beter.</p>
<h2>Over Vasilis van Gemert</h2>
<img src="https://www.fronteers.nl/_img/2011/12/vasilis-van-gemert.jpg" alt="Foto van vasilis van gemert" class="floating-portrait" />
Vasilis van Gemert wil graag dat iedereen een betere front-end developer is dan hijzelf (hetgeen niet zo heel moeilijk is). Zolang dat nog niet zo is, zal hij zijn best doen om er voor te zorgen dat dat wel gebeurt. Dat doet hij onder andere door zich in te zetten voor Fronteers, door (ongeveer) dagelijks de [Daily Nerd](http://dailynerd.nl/) te schrijven en door principal front-end developer te zijn bij [Mirabeau](http://mirabeau.nl). In die functie probeert hij er ook voor te zorgen dat (grote) bedrijven (_én_ concurrenten) betere websites gaan maken. Want ook dat vindt hij belangrijk.
<p>Donatie: <a href="https://www.eff.org/">Electronic Frontier Foundation</a>
Het internet is tof en nuttig. Dat moet zo blijven. Helaas zijn er nogal wat schimmige overheden (zoals voornamelijk die van de VS) en grote bedrijven (voornamelijk bedrijven die in schimmige zaken als <em>rechten</em> handelen) die het internet minder tof—onvriendelijk zelfs—willen hebben. Vandaar dat ik het EFF ondersteun.</p>
</content>
</entry>
<entry>
<title>Waarom standaarden essentieel zijn</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/waarom-standaarden-essentieel-zijn"/>
<updated>2011-12-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/waarom-standaarden-essentieel-zijn</id>
<content xml:lang="nl" type="html"><p>Je hebt vast en zeker al ooit een vaatwasmachine of een oven gekocht. Heb je toen, om er zeker van te zijn dat het in je keuken paste, opgemeten hoe groot het nieuwe toestel was? Normaal gezien was dat niet nodig, omdat de afmetingen van inbouwkeukentoestellen gestandaardiseerd zijn. Op een paar uitzonderingen na zullen toestellen van eender welke leverancier zonder probleem in je keuken passen.</p>
<h2>Standaarden bevorderen innovatie</h2>
<p>Standaarden zijn een onzichtbaar, maar onmisbaar deel van de meeste producten die we in ons dagelijks leven gebruiken. Ze maken niet enkel ons leven gemakkelijker, ze wakkeren innovatie aan en dat wordt vaak vergeten. Standaarden verschuiven de concurrentie van een markt met andere markten naar competitie binnen een markt.</p>
<blockquote>
<p>Standards change competition for a market to competition within a market</p>
</blockquote>
<p>De globalisatie die we de afgelopen jaren meegemaakt hebben is grotendeels te danken aan de opmars van de informatietechnologie en standaarden. Een goed voorbeeld hiervan is <a href="http://nl.wikipedia.org/wiki/SOAP">SOAP</a>. De introductie van SOAP heeft ervoor gezorgd dat grote bedrijven activiteiten eenvoudiger kunnen outsourcen. Laten we accounting als voorbeeld nemen. Doordat een op SOAP gebaseerde interface de standaard is geworden in deze sector kunnen bedrijven nu relatief eenvoudig van accounting firma veranderen. Hierdoor ontstaat er sterkere concurrentie tussen de verschillende bedrijven die de accountingtaken uiteindelijk uitvoeren. Concurrentie gaat meestal gepaard met een prijzenslag of differentiatie op vlak van kwaliteit. In beide gevallen heeft het bedrijf dat de activiteiten outsourcet gewonnen en waarschijnlijk de kosten van de implementatie dubbel en dik terugverdiend.</p>
<h2>Standaarden beschermen gebruikers</h2>
<p>Veel onafhankelijke Belgische reisbureaus en touroperators werken met een bepaald, niet nader te vernoemen, informaticasysteem. Het is ontwikkeld door een klein Belgisch softwarebedrijf en wordt al gebruikt sinds de jaren '90. Een tijdje geleden vroeg een touroperator ons een onderzoek te doen of het mogelijk was om naar een ander, moderner systeem over te stappen. Dit omdat het systeem geen online functionaliteit aanbiedt en het soms meer dan een jaar duurt voordat een feature request geïmplementeerd wordt.</p>
<p>Het resultaat van onze audit verbaasde hen sterk. Het was niet mogelijk om de gegevens uit het bestaande systeem te halen en over te zetten naar een nieuw systeem, omdat hun leverancier weigerde toegang te geven tot de server waarop de gegevens staan. Tot op vandaag werken ze nog altijd met hun verouderde systeem en moeten ze boekingen op de website manueel verwerken. Moest hiervoor een systeem gebruikt zijn dat standaarden respecteert, was dit uiteraard reeds lang gemoderniseerd.</p>
<p>Dergelijke situaties komen we regelmatig tegen tijdens onze consulting opdrachten en we staan er steeds van versteld hoe weinig bedrijven beseffen wat de consequenties kunnen zijn van een dergelijke situatie. Bij het geringste geschil zou hun leverancier bijvoorbeeld kunnen beslissen om hen (tijdelijk) van het platform af te sluiten. De gevolgen hiervan zouden niet te overzien zijn.</p>
<p>Moest er in deze markt een standaard bestaan voor het uitwisselen van informatie dan hadden deze problemen niet bestaan. De bedrijven die denken dat ze groeien door hun technologie af te schermen van concurrenten zijn uiteindelijk de bedrijven die verliezen.</p>
<h2>Standaarden verlagen kosten</h2>
<p>In een ander bedrijf dat we doorgelicht hebben wordt elke week de voorraad informatie van meer dan 200 leveranciers verwerkt. Deze gegevens zijn essentieel voor hun bedrijfsvoering en moeten zo recent mogelijk zijn. Toen we te horen kregen <a href="http://images.cheezburger.com/completestore/2010/1/29/129092786498235257.jpg">hoe dit gebeurde</a> waanden we ons weer even in 1980. Twee mensen zijn er full-time bezig met het copy pasten van de informatie uit allerhande documenten en websites, een deel van de gegevens komen zelfs per fax of telefoon binnen.</p>
<p>De lijsten die dagelijks verwerkt moesten worden zijn op dit moment al volledig geautomatiseerd en er wordt gewerkt aan een automatisatie van 80% van de imports die gebeurden. Door de leveranciers te verplichten de gegevens in een bepaald formaat door te sturen hopen we in de toekomst alles automatisch te kunnen doen. De dames die het werk deden zullen een aangenamere job binnen het bedrijf krijgen.</p>
<p>Door deze standardisatie bespaart de eigenaar niet enkel op zijn personeelskosten, maar vermindert hij ook de kans op fouten in de gevevens, en dus in hun bedrijfsvoering.</p>
<h2>Standaarden en het internet</h2>
<p>Ook op het internet spelen standaarden een zeer grote rol. De steeds snellere verspreiding van de gebruikte standaarden, zowel in front-end als back-end development, liggen aan de basis van de sterke groei van het internet de laatste jaren. Zonder standaarden hadden wij <a href="https://twitter.com/roy/status/139980797233987584">deze geweldige job</a> niet gehad.</p>
<p>Als internetindustrie hebben we een voorbeeldrol op het vlak van standaarden. Zonder standaarden zouden we nu meerdere internetten hebben, zou een bedrijf meerdere websites moeten laten ontwikkelen en zouden de gebruikers meerdere internetaansluitingen moeten hebben.</p>
<p>Toch is er nog heel veel werk. We moeten het internet herbedenken, en niet enkel op het vlak van copyrights zoals de multinationals nu doen. Zo kan je hopelijk over een paar jaar je video's met één klik van YouTube naar Vimeo overzetten.</p>
<p>Nu Flash eindelijk ten dode opgeschreven is en IE6 zijn laatste adem uitblaast kunnen we door standaarden te gebruiken het internet nog dichter bij de echte wereld brengen.</p>
<h2>Over Andreas Creten</h2>
<img src="https://www.fronteers.nl/_img/2011/12/andreas-creten.jpg" alt="Foto van andreas creten uit 2011" class="floating-portrait" />
[Andreas](https://twitter.com/andreascreten) is de zaakvoerder van [madewithlove](http://madewithlove.be). Met een klein team ontwikkelen ze webapplicaties en verlenen ze technisch advies aan bedrijven en startups. Andreas heeft een bachelor in informatica en studeert een master in management. In zijn vrije tijd reist hij, al dan niet op skies, en geniet hij van [elektronische muziek](http://muff.be).
<p>Donatie: PROTOS
Ik heb voor <a href="http://protos.be/">PROTOS</a> gekozen, omdat een groot oom van me er voorzitter van was. Twee jaar geleden heb ik op kerstdag een wandeling met deze bijna blinde man gemaakt en het raakte me hoe gedreven hij over zijn ervaringen kon vertellen. Ik ben er dus van overtuigd dat het geld goed en correct besteed zal worden.
Samen met haar partners en de lokale bevolking slaagt PROTOS erin om jaarlijks zowat honderdduizend mensen aan betere hygiënische voorzieningen, drinkbaar water en/of irrigatiewater voor de voedselvoorziening te helpen. De gemiddelde kostprijs van onze werking per begunstigde inwoner van het Zuiden is 50€.
Maar het werk is nog niet af. Er zijn nog steeds 1.1 miljard mensen zonder toegang tot veilig drinkwater, en liefst één derde van de wereldbevolking heeft nog geen voldoende sanitaire voorzieningen.
Is het werk van PROTOS dan een druppel op een hete plaat? Nee! Voor de mensen die net in die druppel wonen maakt het wél een enorm verschil! In plaats van elke dag 4 uur te moeten besteden aan water halen, kunnen kinderen nu naar school en kunnen de vrouwen hun tijd besteden aan landbouw en/of aan activiteiten die inkomsten verzekeren!</p>
</content>
</entry>
<entry>
<title>JavaScript-pret met alle karakters in een string</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/javascript-pret-met-alle-karakters-in-een-string"/>
<updated>2011-12-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/javascript-pret-met-alle-karakters-in-een-string</id>
<content xml:lang="nl" type="html"><p>Stel: je hebt een functie <code>encode()</code> geschreven, die <a href="http://www.flickr.com/photos/24374884@N08/6346609079/">een string bestaande uit één enkel karakter</a> als argument neemt, en een gecodeerde versie van dat ene karakter teruggeeft. Een praktisch voorbeeld hiervan is <a href="http://en.wikipedia.org/wiki/ROT13">ROT-13-encodering</a>.</p>
<p>Als je nu een willekeurige string bestaande uit meerdere karakters wil gaan coderen volgens <code>encode()</code>, hoe zou jij dat dan doen?</p>
<p>Er zijn natuurlijk verscheidene mogelijkheden, maar de ene is al leesbaarder/compacter/sneller/handiger/robuuster dan de andere.</p>
<p>Laat ons om te beginnen uitgaan van volgende invoer:</p>
<pre><code>var input = 'foo bar baz';
</code></pre>
<h2>ECMAScript 5</h2>
<p>Ik had onlangs iets dergelijks nodig, en mijn eerste idee was om <code>String#split</code> te gebruiken om een array te maken van alle karakters in de invoerstring:</p>
<pre><code>input.split(''); // ['f', 'o', 'o', ' ', 'b', 'a', 'r', ' ', 'b', 'a', 'z']
</code></pre>
<p>Vervolgens kunnen we met ES5 <code>Array#map</code> elk karakter omvormen naar zijn gecodeerde versie, om dan met <code>Array#join</code> de array van gecodeerde karakters samen te voegen tot een string:</p>
<pre><code>var output = input.split('').map(function(character) {
return encode(character);
}).join('');
output; // de gecodeerde string
</code></pre>
<p>(Zowel in dit als in de volgende voorbeelden zouden we de anonieme functie ook gewoon kunnen weglaten door <code>encode</code> mee te geven als argument aan de <code>map</code>-functie, maar dat leek me iets minder duidelijk.)</p>
<p>Dit is wellicht de meest eenvoudige en leesbare oplossing. Helaas werkt deze enkel in omgevingen waar ES5 <code>Array#map</code> beschikbaar is. Het is trouwens mogelijk om de <code>split()</code>-stap over te slaan:</p>
<pre><code>var output = [].map.call(input, function(character) {
return encode(character);
}).join('');
output; // de gecodeerde string
</code></pre>
<p>ES5 biedt echter nog een andere mogelijkheid: je kan door middel van een index een bepaald karakter uit een string opvragen. <code>input[0]</code> geeft dan het eerste karakter terug, <code>input[1]</code> het tweede, enzovoort.</p>
<pre><code>var length = input.length,
counter = 0,
output = '';
for (; counter &lt; length; counter++) {
output += encode(input[counter]);
}
output; // de gecodeerde string
</code></pre>
<p>Helaas ondersteunt IE &lt; 8 dit niet. (IE 8 zelf ondersteunt het enkel voor string literals, maar niet voor string objects.)</p>
<h2>Array generics</h2>
<p>Door gebruik te maken van <a href="https://developer.mozilla.org/en/JavaScript/New_in_JavaScript/1.6#Array_and_String_generics">array generics</a> kan <code>String#split</code> vermeden worden:</p>
<pre><code>var output = Array.map(input, function(character) {
return encode(character);
}).join('');
output; // de gecodeerde string
</code></pre>
<p>Helaas heeft <code>Array.map</code> nog minder ondersteuning dan <code>Array#map</code>, aangezien het geen deel uitmaakt van de ECMAScript-standaard.</p>
<p>Voor ES3-compatibiliteit is een andere aanpak nodig.</p>
<h2>Compatibiliteit met ES3</h2>
<p>Door <code>String#replace</code> te gebruiken in plaats van <code>String#split</code> kunnen we de array-tussenstap weglaten:</p>
<pre><code>var output = input.replace(/[\s\S]/g, function(character) {
return encode(character);
});
output; // de gecodeerde string
</code></pre>
<p>Ik vond deze reguliere expressie best interessant: <code>\s</code> matcht alle witruimte-karakters, en <code>\S</code> matcht alle andere karakters; <code>[\s\S]</code> zal dus om het even welk karakter matchen.</p>
<p>Merk op dat je niet gewoon <code>/./</code> kan gebruiken, aangezien dat geen line feeds (<code>\n</code>), carriage returns (<code>\r</code>), line separators (<code>\u2028</code>) of paragraph separators (<code>\u2029</code>) matcht.</p>
<p>Deze oplossing is volledig conform met ES3.</p>
<p>Een alternatief is om <code>[^]</code> te gebruiken in plaats van <code>[\s\S]</code>: zoek elk karakter dat niet… niets is. Helaas werkt deze reguliere expressie niet in IE &lt; 9. In browsers waar ze wel werkt, is ze <a href="http://jsperf.com/match-any-char-regex" title="jsPerf: Match any character using regex">sneller dan <code>[\s\S]</code></a>.</p>
<h2>Ondersteuning voor Safari 2-achtige WebKits</h2>
<p>Jammer genoeg ondersteunen oeroude WebKit-browsers zoals Safari 2 geen functies als tweede argument voor <code>String#replace</code>.</p>
<p>We kunnen echter wel <code>String#split</code> gebruiken, vervolgens met een loopje door de resulterende array wandelen, en elk gecodeerd karakter stuk voor stuk aan een aparte string-variabele toevoegen.</p>
<pre><code>var characters = input.split(''),
length = characters.length,
counter = 0,
output = '';
for (; counter &lt; length; counter++) {
output += encode(characters[counter]);
}
output; // de gecodeerde string
</code></pre>
<p>Deze oplossing is net als de vorige volledig ES3-compatibel, en werkt bovendien ook in browsers die gebaseerd zijn op een verouderde WebKit-versie.</p>
<h2>Disclaimer</h2>
<p><a href="https://mathiasbynens.be/notes/javascript-encoding">JavaScript maakt intern gebruik van de UCS-2-encodering</a> (de voorloper van UTF-16). Alle ingebouwde string-eigenschappen en functies (zoals <code>String#length</code>, <code>String#split</code> en <code>String#slice</code>) werken op basis van 16-bit code-eenheden in plaats van Unicode-karakters. Dit geeft soms op het eerste zicht <a href="https://mathiasbynens.be/notes/javascript-unicode">onverwachte resultaten</a>. Als je <code>encode</code>-functie Unicode code-points in plaats van UCS-2/UTF-16 code-eenheden verwacht, zal je dus nog een conversie-functie nodig hebben.</p>
<h2>Over Mathias Bynens</h2>
<img src="https://www.fronteers.nl/_img/2011/12/mathias-bynens.jpg" alt="Foto van mathias bynens uit 2011" class="floating-portrait" />
[Mathias](https://mathiasbynens.be/) is een freelance webontwikkelaar uit Grembergen, België. In zijn vrije tijd organiseert hij samen met enkele andere vrijwilligers [Fronteers-meetups in België](https://twitter.com/fronteersbe).
<p>Donatie: ErKriDo
Wat het goede doel betreft: m’n keuze was snel gemaakt :) <a href="http://erkrido.blogspot.com/">ErKriDo</a> is de Buggenhoutse aftakking van <a href="http://www.tegenkanker.be/kom_op_tegen_kanker">Kom Op Tegen Kanker</a>. Zij organiseren jaarlijks o.a. een benefietconcert waarvan de opbrengst integraal naar de Vlaamse Liga Tegen Kanker gaat, en dus goed besteed wordt.</p>
</content>
</entry>
<entry>
<title>Front-end meta languages</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/front-end-meta-languages"/>
<updated>2011-12-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/front-end-meta-languages</id>
<content xml:lang="nl" type="html"><p>Front-end meta languages. Een hippe, zelfverzonnen naam voor talen die compileren naar HTML, CSS en JavaScript, maar dat zelf niet zijn. Het gebruik scheelt op z'n minst veel typewerk en zorgt voor overzichtelijkere code. Dankzij extensies als Compass is er nog meer tijdsbesparing en gemak te realiseren, bijvoorbeeld voor het beheer van je sprites.</p>
<h2>Waar hebben we het over?</h2>
<p>Voor HTML en JavaScript zijn er een paar bekende spelers, zoals <a href="http://haml-lang.com/">Haml</a> en <a href="http://jashkenas.github.com/coffee-script/">CoffeeScript</a>. Voor CSS hebben we talen als <a href="http://sass-lang.com/">Sass</a> en <a href="http://lesscss.org/">Less</a>. Haml, Sass en Less zullen de revue passeren, met een uitstapje naar <a href="http://compass-style.org/">Compass</a>. In dit artikel komen syntaxis en voorbeelden aan bod, zodat je meteen aan de slag kunt met experimenteren. CoffeeScript blijft buiten beschouwing, omdat de leercurve daarvan hoger is en het gebruik ervan voor de meeste front-enders niet direct winst op zal leveren.</p>
<p>NB: Als je <a href="http://nodejs.org/">Node.js</a> gebruikt, zou je eens kunnen kijken naar <a href="http://jade-lang.com/">Jade</a> en <a href="http://learnboost.github.com/stylus/">Stylus</a>. In dit artikel komen ze verder niet terug.</p>
<h2>Compilers schrijven geen slechte code</h2>
<p>Om dit fabeltje maar meteen de wereld uit te helpen: compilers schrijven geen slechte code. Uiteindelijk is wat er uit Haml, Sass, Less en CoffeeScript komt afhankelijk van de kwaliteit van de ontwikkelaar die deze tools gebruikt. Kenmerkend voor al deze talen is dat ze weinig dicteren: als je je CSS 20 niveaus diep wilt nesten of tabellen voor lay-out wilt gebruiken, dan houden ze je niet tegen. Zoals je text editor dat ook niet doet. Wél vangen ze syntactische fouten af; een compiler gooit een error als je een dubbele punt vergeet. Speel een tijdje met je code, zie wat uit de compiler komt en je leert snel hoe je code er uit zal zien na compilatie.</p>
<h2>Compileren: van meta language naar HTML, CSS en JavaScript</h2>
<p>Dit artikel is gebaseerd op het lokaal compileren (&quot;vertalen naar de uiteindelijke taal&quot;) van alle code. Zodra je deze talen in een dynamisch project wilt gebruiken zijn er allerlei setups mogelijk. Voor nu doen we alles zonder enige dynamiek en richten we ons puur op de compilatie. Dat kan voor een deel van deze talen client side met JavaScript (Less heeft hier een officiële oplossing voor, terwijl Sass enkele officieuze implementaties kent). Omdat ik meen dat er geen enkele reden is om dit te willen, compileren we alles voordat we het naar de browser sturen.</p>
<p>Als je OSX gebruikt dan heb je de beschikking over verschillende tools, zoals het kersverse <a href="http://incident57.com/codekit/">CodeKit</a>. Dit programma is nog in beta en daarom voorlopig gratis. CodeKit houdt de bestanden in een folder in de gaten en compileert zodra er iets gewijzigd is. Het is een one-stop-shop voor alle talen in dit artikel, op het moment van schrijven met uitzondering van Compass. Er kan echter ieder moment een update uitkomen met ondersteuning voor Compass; de kans is groot dat het zover is wanneer je dit leest. Kijk na het installeren ook eens naar de opties. Je kunt er onder andere instellen of en hoe code geminified moet worden, of er enkele of dubbele quotes gebruikt worden, enzovoort. Voor alternatieven voor OSX, zie hieronder.</p>
<p>Als je op Windows werkt, is het een klein beetje meer werk. Voor zover ik weet is er voor dat platform geen alles-in-één oplossing. Je kunt gebruik maken van <a href="http://mhs.github.com/scout-app/">Scout</a> of <a href="http://compass.handlino.com/">Compass.app</a> voor Sass en Compass (deze apps werken ook op OSX). Voor Less kun je <a href="http://wearekiss.com/simpless">SimpLESS</a> of <a href="http://winless.org/">WinLess</a> gebruiken. Voor CoffeeScript is er de <a href="https://github.com/alisey/CoffeeScript-Compiler-for-Windows">CoffeeScript Compiler</a>. Een GUI voor Haml is er niet, maar als je niet bang bent voor de command-line kun je daarmee een eind komen.</p>
<p>Als Linux-goeroe ben je vast handig genoeg om de stack zelf te installeren, maar je kunt ook de Linux-versie van bovenstaande Compass.app gebruiken als je een GUI wilt voor Sass en Compass.</p>
<p>Met <a href="http://rendera.heroku.com/">Rendera</a> kun je online het één en ander proberen in Haml, Sass en CoffeeScript. Handig als je alleen een beetje met de syntaxis wilt stoeien.</p>
<h2>HTML: <a href="http://haml-lang.com/">Haml</a></h2>
<p>Het schrijven van HTML is zo erg niet: je editor sluit iedere tag met één toetscombinatie zelf wel af, &quot;angle brackets&quot; zijn helemaal niet overbodig en een sloot aan afsluitende tags onderaan hoort er nu eenmaal bij. Zo dachten de meesten erover die met Haml begonnen en—toegegeven: na enige gewenning—nooit meer iets anders willen.</p>
<p>Haml is alweer vijf jaar oud en daarmee in de developmentwereld zeker volwassen te noemen. De code erachter draait op Ruby, maar dat wil niet zeggen dat je het alleen in op Ruby-gebaseerde projecten in kunt zetten. Als je lokaal ontwikkelt zonder dynamische data (je schrijft puur statische HTML), dan kun je met Haml prima uit de voeten. Wil je het gebruiken in bijvoorbeeld een PHP-project, kijk dan eens naar <a href="http://code.google.com/p/phamlp/" title="PHamlP">deze port</a> (er zijn ook ports voor .NET, Java en zelfs Perl). Gebruik je Wordpress, dan is <a href="https://github.com/welaika/wordless">Wordless</a> een goede optie.</p>
<p>Van alle in dit artikel besproken talen is Haml het eenvoudigst qua hoeveelheid opties en syntaxis. Een prima optie om mee te beginnen dus. Er zitten geen wereldschokkende features in Haml; de voornaamste voordelen zijn de overzichtelijke hiërarchie en het niet hoeven sluiten van je tags. Haml gebruikt &quot;significant whitespace&quot;: het aantal spaties aan het begin van de regel geeft het niveau en daarmee de hiërarchie aan. Alle editors kunnen gebruik maken van &quot;soft tabs&quot;, waarbij het gebruik van de tab-toets ervoor zorgt dat onder water twee spaties gebruikt worden.</p>
<p>De syntaxis van Haml is overzichtelijk. Hieronder eerst wat Haml, met daarna het gecompileerde resultaat.</p>
<h2>Haml:</h2>
<pre><code>!!!
%section#about
%h1 About us
%p.introduction
%a{:href =&gt; 'http://fronteers.nl/'} Fronteers website
#carousel.projects
:javascript
alert('initialize');
%form{:method =&gt; 'post'}
%fieldset
%legend Some form…
</code></pre>
<h2>HTML:</h2>
<pre><code>&lt;!DOCTYPE html&gt;
&lt;section id=&quot;about&quot;&gt;
&lt;h1&gt;About us&lt;/h1&gt;
&lt;p class=&quot;introduction&quot;&gt;
&lt;a href=&quot;http://fronteers.nl/&quot;&gt;Fronteers website&lt;/a&gt;
&lt;/p&gt;
&lt;div id=&quot;carousel&quot; class=&quot;projects&quot;&gt;
&lt;script&gt;
&lt;![CDATA[
alert('initialize');
]]&gt;
&lt;/script&gt;
&lt;/div&gt;
&lt;form method=&quot;post&quot;&gt;
&lt;fieldset&gt;
&lt;legend&gt;Some form…&lt;/legend&gt;
&lt;/fieldset&gt;
&lt;/form&gt;
&lt;/section&gt;
</code></pre>
<p>Zoals je ziet worden HTML-elementen aangegeven met een %-teken. Alles wat je aansluitend tussen curly brackets zet worden attributen (de dubbele punt voor het attribuut komt uit Ruby, eventueel kun je ook gewoon <code>href</code> gebruiken, met quotes).</p>
<p>Door een <code>#</code>-teken te gebruiken geef je aan dat dit een ID is, terwijl een punt een classname aangeeft. Een duidelijke relatie tussen je HTML en CSS dus, wat de leesbaarheid ten goede komt. Door het element weg te laten, zoals bij <code>#carousel.projects</code>, zal Haml een <code>&lt;div&gt;</code> gebruiken.</p>
<p><code>:javascript</code> is een filter, meer hierover in de <a href="http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#filters">Haml-documentatie</a>. Je hebt er nog veel meer, bijvoorbeeld om whitespace te preserveren of een <code>&lt;style&gt;</code>-element toe te voegen.</p>
<p>De voordelen van Haml op een rijtje: inzichtelijke hiërarchie tussen HTML-elementen onderling, duidelijke relatie tussen markup en CSS selectors, geen onnodige haakjes en geen onoverzichtelijke sloot aan afsluitende tags onderaan je pagina. Als bonus kun je aangeven of je enkele of dubbele quotes wilt gebruiken en hoe je je markup wilt compileren (ingesprongen, niet ingesprongen of alles op één regel).</p>
<h2>CSS: <a href="http://sass-lang.com/">Sass</a> &amp; <a href="http://lesscss.org/">Less</a></h2>
<p>Of je Sass of Less wilt gebruiken hangt sterk af van je voorkeur en ontwikkelomgeving. In Ruby on Rails wordt Sass veel vaker gebruikt dan Less, terwijl ik zelfstandige front-enders juist vaker over Less hoor. Belangrijkste is dat je een tool gebruikt waarvan de syntax bij je past en die eenvoudig in te zetten is in de projecten waar je aan werkt. Voor dit artikel maakt het weinig uit: met de hierboven beschreven software kun je ze allebei lokaal compileren. De functionaliteit is vrijwel hetzelfde, met als uitzondering dat Compass (zie verderop in dit artikel) of een vergelijkbare extensie niet beschikbaar is voor Less.</p>
<p>Sass en Less voegen de functionaliteit toe die je al jaren mist in CSS. Wat dacht je van variabelen, herbruikbare functies en calculaties met verschillende eenheden? En dan kun je je bestaande CSS-bestand nog gewoon hernoemen ook, waarna je in je eigen tempo de wijzigingen door kunt voeren die voor jou nuttig zijn. Hieronder staan enkele voorbeelden.</p>
<p>NB: Sass kent twee verschillende syntaxissen: Scss (&quot;Sassy CSS&quot;) en &quot;original Sass&quot;. Original Sass gebruikt geen curly brackets en puntkomma's, maar significant whitespace. Velen, waaronder ondergetekende, vinden dit een overzichtelijkere manier van schrijven. Door het ontbreken van deze &quot;onnodige&quot; karakters is er minder visuele afleiding. Voor dit artikel is gekozen voor Scss, omdat dit voor beginnende gebruikers bekender oogt.</p>
<h2>Nested selectors</h2>
<p>Wat velen een doorn in het oog is aan CSS is het niet DRY karakter ervan (Don't Repeat Yourself), wat bijvoorbeeld opvalt wanneer je gebruik maakt van geneste selectors. Zowel Sass als Less lossen dit op door nesting toe te staan, waarna er valide CSS van gemaakt wordt. Let echter op dat je hier geen nestingfeest van maakt: meer dan een paar niveaus diep is niet bevorderlijk voor de verwerkingssnelheid van de browser en de hoofdpijn die je gaat krijgen door een te hoge <a href="http://coding.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/">specificity</a>. Hetzelfde als wanneer je je selectors met de hand zou schrijven dus.</p>
<h2>Scss / Less:</h2>
<pre><code>#header {
color: #f0f;
h1 {
color: #000;
}
p {
color: #333;
a {
color: #999;
}
}
}
</code></pre>
<h2>CSS:</h2>
<pre><code>#header {
color: #f0f;
}
#header h1 {
color: #000;
}
#header p {
color: #333;
}
#header p a {
color: #999;
}
</code></pre>
<h2>Mixins</h2>
<p>Mixins zijn herbruikbare blokken met stijldeclaraties die je eventueel kunt combineren met zelf te kiezen parameters. De syntax van Scss is iets meer verbose en daarmee wat mij betreft duidelijker, omdat er geen verwarring kan ontstaan tussen een class selector en een mixin.</p>
<p>In de dagelijkse praktijk zul je zien dat mixins veel tijd kunnen schelen, bijvoorbeeld doordat je in een herbruikbare mixin alle vendor specifieke prefixen kunt definiëren. Een voorbeeld hiervan vind je in het onderdeel over Compass een stukje naar verderop.</p>
<h2>Scss:</h2>
<pre><code>@mixin left($distance: 20px) {
float: left;
margin-left: $distance;
}
.foo {
@include left;
}
.bar {
@include left(10px);
}
</code></pre>
<h2>Less:</h2>
<pre><code>.left(@distance: 20px) {
float: left;
margin-left: @distance;
}
.foo {
.left;
}
.bar {
.left(10px);
}
</code></pre>
<h2>CSS:</h2>
<pre><code>.foo {
float: left;
margin-left: 20px;
}
.bar {
float: left;
margin-left: 10px;
}
</code></pre>
<h2>En nog veel meer</h2>
<p>Bovenstaande is slechts het topje van de ijsberg. Zowel Sass als Less bieden de mogelijkheid om variabelen te gebruiken, zodat je kleuren, marges, regelafstanden of wat dan ook maar één keer hoeft te definiëren, waardoor zoeken en vervangen voor het maken van een aanpassing niet meer nodig is. Daarnaast is iets als <code>$link-hover-color</code> een stuk duidelijker voor jezelf of een toekomstige ontwikkelaar dan een willekeurige #hexadecimale kleurcode.</p>
<p>Een grote collectie aan ingebouwde functies zorgen ervoor dat bijvoorbeeld het gebruiken van afgeleide kleuren eenvoudig is. Zo gebruik je <code>lighten(kleur, 10%)</code> om een kleur 10% lichter te maken, waarna Sass of Less de nieuwe #hex-waarde berekenen. Sass heeft meer functies in zich dan Less, maar je moet je afvragen hoe vaak je de meer exotische functies gebruikt.</p>
<p>Mathematische operaties worden door beide talen ondersteund. Van optellen en vermenigvuldigen (handig bij het berekenen van afmetingen in em's) tot het &quot;optellen&quot; van kleuren (wat alleen goed werkt in simpele gevallen, zoals bij grijswaarden).</p>
<p>Daarnaast heeft Sass onderstaande manier om stijlen in een media query overzichtelijk te koppelen aan een selector. Op deze manier hoef je niet totaal ergens anders te gaan zoeken naar een media query-specifieke stijl. Sass combineert media queries waar mogelijk: gebruik je twee keer dezelfde <code>@media</code>-regel, dan komen de bijbehorende stijlen gecombineerd binnen een enkele <code>@media</code>-regel te staan.</p>
<h2>Scss:</h2>
<pre><code>#header {
width: 300px;
@media screen and (orientation: landscape) {
width: 500px;
}
}
</code></pre>
<h2>CSS:</h2>
<pre><code>#header {
width: 300px;
}
@media screen and (orientation: landscape) {
#header {
width: 500px;
}
}
</code></pre>
<h2><a href="http://compass-style.org/">Compass</a></h2>
<p>Compass is een extensie voor Sass waarmee je nóg meer snelheidswinst kunt boeken. Het maakt het onder andere makkelijk om afbeeldingen en fonts in je CSS te embedden (door middel van Data URI's), afmetingen van een afbeelding te achterhalen en te gebruiken in je CSS, met één regel een CSS reset toe te voegen of een collectie helpers aan te roepen om eenvoudiger gebruik te maken van diverse grid systems. De <a href="http://compass-style.org/help/">documentatie van Compass</a> is uitstekend, dus ik verwijs je graag daar naartoe voor alle informatie hierover. Maar eerst overtuig ik je met twee voorbeelden die de winst die uit Compass te halen is meteen duidelijk maken.</p>
<h2>Vendor specifieke prefixen</h2>
<p>Het is vermoeiend om steeds weer een sloot aan vendor specifieke prefixen te moeten gebruiken. Ze zorgen voor extra regels code (en dus meer scrollen) en &quot;visual clutter&quot;. Compass heeft mixins voor veel CSS3-property's die dit voorkomen. Bijvoorbeeld voor <code>border-radius</code>:</p>
<h2>Compass:</h2>
<pre><code>a {
@include border-radius(10px);
}
</code></pre>
<h2>CSS:</h2>
<pre><code>a {
-moz-border-radius: 10px;
-webkit-border-radius: 10px;
-o-border-radius: 10px;
-ms-border-radius: 10px;
-khtml-border-radius: 10px;
border-radius: 10px;
}
</code></pre>
<h2>Sprites beheren: onbegonnen werk</h2>
<p>Het maken en beheren van sprites is veel werk. Afbeeldingen samenvoegen tot een groter geheel, de <code>background-position</code> van ieder element opzoeken en de hele boel weer aanpassen wanneer je één van de afbeeldingen een paar pixels groter maakt. Natuurlijk zijn er tools die het leven wat makkelijker maken, maar er zijn er weinig die zo verweven zijn met je ontwikkelproces als Compass.</p>
<p>Stel je voor dat je een <code>images/flags</code> folder hebt met daarin de vlaggen van verschillende landen: <code>nl.png</code>, <code>be.png</code>, enzovoort. Je wilt deze in een sprite gebruiken, zonder na te hoeven denken over de sprite zelf. Eventueel wil je later grotere afbeeldingen gebruiken, maar ook daar wil je in dat geval geen omkijken naar hebben. Tijd voor wat Compass-magie.</p>
<h2>Scss</h2>
<pre><code>@import &quot;images/flags/*.png&quot;;
a.nl {
@include flags-sprite(nl);
}
a.be {
@include flags-sprite(be);
}
</code></pre>
<h2>CSS:</h2>
<pre><code>a.nl,
a.be {
background: url('/images/flags-s34fe0604ab.png') no-repeat;
}
a.nl {
background-position: 0 0;
}
a.be {
background-position: 0 -16px;
}
</code></pre>
<p>Dit is een simpel voorbeeld, waarbij Compass op basis van de eerste <code>@import</code> alle PNG's in de folder <code>images/flags</code> samenvoegt tot één afbeelding en de coördinaten van de verschillende afbeeldingen berekent. De bestandsnaam is gebaseerd op de inhoud van de afbeeldingen, dus wanneer je er eentje aanpast, krijgt de sprite een nieuwe bestandsnaam. Handig als je far future expiry headers gebruikt.</p>
<p>Hierna komt de functie <code>flags-sprite()</code> beschikbaar, waarbij de naam een afgeleide is van het pad. Als je het over kerstbomen in <code>images/trees</code> zou hebben, dan gebruik je <code>trees-sprite()</code>. De functie accepteert de naam van het bestand als parameter, zonder <code>.png</code>. Er zijn optionele parameters om offsets aan te geven, bijvoorbeeld om de achtergrondafbeelding een x-aantal pixels naar rechts of naar beneden te positioneren.</p>
<p>Sass kan gebruik maken van each-loops, waarmee je door alle landen heen kunt lopen. Dat scheelt nog meer typewerk. Compass heeft zelf ook methoden om op basis van de bestandsnamen van de afbeeldingen een lijst met classnames op te bouwen. Meer hierover in de zeer complete <a href="http://compass-style.org/help/tutorials/spriting/">Compass spriting tutorial</a>, net als informatie over de verschillende opties (verticale of horizontale sprites, tussenruimte, enzovoort).</p>
<h2>Waar wacht je op?</h2>
<p>Front-end meta languages zijn niet altijd eenvoudig om in bestaande processen te implementeren. Je moet iedereen mee krijgen, omdat jij niet steeds andermans CSS kunt overschrijven met code die wordt gecompileerd op basis van jouw Sass of Less. Als je echter iedereen zo ver kunt krijgen, dan zorgt het gebruik van deze talen voor een grote tijdswinst en betere onderhoudbaarheid van je front-end code.</p>
<p>Als je een zelfstandige front-ender bent die HTML of CSS oplevert, dan staat niets je in de weg om vandaag nog te beginnen met het gebruik van front-end meta languages. Wat eruit komt is immers &quot;gewoon&quot; HTML en CSS.</p>
<p>Maar het allerbelangrijkste: gebruik van front-end meta languages is leuker en maakt je leven makkelijker. Happy holidays!</p>
<h3>Over Roy Tomeij</h3>
<img src="https://www.fronteers.nl/_img/2011/12/roy-tomeij.jpg" alt="Foto van roy tomeij uit 2011" class="floating-portrait" />
Roy Tomeij is co-founder van 80beans en [SliceCraft](http://www.slicecraft.nl/) in Amsterdam, front-end developer en spreker. Hij houdt van front-end meta languages zoals Haml, Sass en CoffeeScript. Als je meer wilt weten, neem dan contact op met [@roy](https://twitter.com/roy) via Twitter.
<p>Donatie: Doe Een Wens Stichting Nederland
De vergoeding voor dit artikel gaat naar <a href="http://www.doeeenwens.nl/">Doe Een Wens Stichting Nederland</a>, zodat de liefste wens van kinderen met een levensbedreigende ziekte vervult kan worden.</p>
</content>
</entry>
<entry>
<title>Responsive images; een experiment</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/responsive-images-een-experiment"/>
<updated>2011-12-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/responsive-images-een-experiment</id>
<content xml:lang="nl" type="html"><p>Goed anderhalf jaar geleden weerklonken de eerste oh's en ah's in de Twittersphere. Toen was responsive webdesign niet meer dan een—weliswaar beloftevolle—gimmick. Sindsdien is het hard gegaan: klanten hebben de mond vol over <em>mobile first</em> en vandaag zijn zelfs onze moeders verslingerd aan hun iPad's. Er is uitstekend <a href="http://www.amazon.com/Responsive-Web-Design-Ethan-Marcotte/dp/B005SYWGXW/ref=sr_1_1?ie=UTF8&amp;qid=1322663650&amp;sr=8-1">leesvoer</a> voorhanden, webdesigners overal te lande zijn druk aan het experimenteren en de <a href="http://bostonglobe.com/">eerste responsieve websites</a> voor het brede publiek staan te <a href="http://www.handelsbeurs.be/">blinken</a> op het internet. Over een jaar is responsive webdesign niet langer bijzaak, maar <em>noodzaak</em>.</p>
<h2>De toekomst is responsive</h2>
<p>Wie nog niet helemaal overtuigd is van het belang van responsive webdesign voor een betere gebruikservaring, moet zeker de inspirerende <a href="http://www.slideshare.net/bytte/responsive-web-design-10389263">presentatie van Thomas Byttebier</a> bekijken of het <a href="http://www.abookapart.com/products/responsive-web-design">boek van Ethan Marcotte</a> lezen.</p>
<p>Ik ga er voor het gemak vanuit dat je al vertrouwd bent met hoe je de media queries uit CSS3 gebruikt—de basisbestanddelen van iedere responsieve website. En anders kan je na deze <a href="http://teamtreehouse.com/library/design-foundations/css3/media-queries/introduction/play">5 minuten durende video-introductie</a> al meepraten. Want zo eenvoudig is het basisconcept.</p>
<h2>Geen rozengeur</h2>
<p>Het is niet al maneschijn wat de klok slaat. Een lastige kwestie voor ontwerpers van responsieve websites is hoe om te gaan met afbeeldingen. Als je je ontwerp optimaliseert voor een desktopbrowser, een tablet en een smartphone (of alles daar tussenin), dan spreekt het voor zich dat je ook je afbeeldingen wilt schalen—of lichte variaties van je afbeeldingen wilt weergeven op die verschillende apparaten.</p>
<p>Terzelvertijd wil je te allen prijze voorkomen dat browsers meer afbeeldingen downloaden dan strikt noodzakelijk. Bandbreedte is immers kostbaar en de snelheid van mobiel dataverkeer is gemiddeld genomen—althans in België—niet iets om over naar huis te schrijven. En dan hebben wij het in het Westen nog niet eens zo slecht.</p>
<p>Voor de achtergrondafbeeldingen in je CSS stelt dit probleem zich niet, maar de <code>&lt;img&gt;</code> tags in je HTML gooien helaas roet in het eten. Moderne browsers starten zo snel mogelijk met het inladen van afbeeldingen—nog voor het DOM goed en wel is ingeladen (en liefst met zoveel mogelijk tegelijkertijd). Dat maakt het lastig om én een alternatief aan te bieden voor wie JavaScript niet heeft aanstaan en tegelijk te voorkomen dat een browser mét JavaScript geen overbodige afbeeldingen inlaadt; afbeeldingen die nooit weergegeven zullen worden op jouw apparaat.</p>
<h2>Oplossingen</h2>
<p>Jason Grigsby heeft over dit onderwerp een <a href="http://www.cloudfour.com/responsive-imgs/">leerrijk en uitvoerig artikel</a> geschreven. In het vervolg op dit artikel bespreekt hij de <a href="http://www.cloudfour.com/responsive-imgs-part-2/">voor- en nadelen van de reeds beschikbare technieken</a> om de meest geschikte afbeelding te sturen naar apparaten met uiteenlopende scherm- en browserbreedtes.</p>
<p>Het gros van de technieken maakt gebruik van JavaScript en sommige bieden een fallback voor wanneer JavaScript niet beschikbaar is. De meeste technieken gebruiken bovendien Apache's <code>mod_rewrite</code> module voor het herschrijven van URI's en/of van PHP of Ruby om afbeeldingen aan de serverkant te manipuleren. De ene techniek is al ingenieuzer dan de andere en het vergt veel tijd om ze <em>allemaal</em> uit te proberen. Dat heb ik dan ook niet gedaan, moet ik toegeven.</p>
<p>Om het probleem beter te begrijpen, heb ik vorige zomer de mouwen opgestroopt en zelf een script in elkaar geknutseld. Natuurlijk is het maar <em>een</em> oplosing—en <em>zeker</em> geen ideale—maar het heeft me wel een beter inzicht gegeven in de problemen waar je mee te maken krijgt als je een responsieve website bouwt. In dit artikel leg ik uit hoe het script werkt en welke gebreken het heeft. Misschien brengt het andere, getalenteerdere developers op nieuwe ideeën. En zo maken we het web samen beter. Als dat geen mooie kerstgedachte is!</p>
<h2>Meet Mingy</h2>
<p>Ieder kind—of in ieder geval iedere jQuery plugin—moet een naam hebben. Ook al klinkt die naam erg sullig. Mingy betekent krenterig (een zeer on-Vlaamse eigenschap overigens) en dat is precies wat je moet zijn als je afbeeldingen naar een mobiel apparaat stuurt. Mingy stuurt net zoveel image-data naar de browser als strikt noodzakelijk. Dat is het uitgangspunt.</p>
<p>Net als jij, ben ik fan van nette HTML, of <a href="http://en.wikipedia.org/wiki/Plain_Old_Semantic_HTML#Plain_Old_Semantic_HTML_.28POSH.29">POSH</a> als je wil. Voor mij dus liever geen <code>&lt;noscript&gt;</code> wrappers rondom de afbeeldingen en geen <code>rare_urls_met?kleine&amp;groteversies</code> als <code>src</code> van de <code>&lt;img&gt;</code> tag. En JavaScript hoort in een afzonderlijk bestand; niet inline. <em>Unobtrusive JavaScript</em> heet dat met een sjiek woord.</p>
<p>Bekijk misschien eerst even deze <a href="http://www.catchup.be/experiments/mingy_demo/">demo</a>. Maak je browservenster breder of smaller en bekijk met Firebug of de Webkit Inpsector wat de impact is op het totale gewicht van de pagina.</p>
<h2>Hoe werkt het?</h2>
<p>Het script gaat uit van het idee dat je met <em>master images</em> werkt. Een master image is de grootste variant (of groter) van de afbeelding die je wilt gebruiken. We gaan er ook vanuit dat iedere media query dezelfde master image inlaadt, maar met uiteenlopende afmetingen. De verhoudingen hoeven niet per se dezelfde te zijn. Het kan dus best dat je rechthoekige afbeeldingen gebruikt in de brede desktop-versie en vierkante afbeeldingen op het scherm van een smartphone. Een <a href="https://github.com/roelvangils/mingy/blob/master/mingy/resize.php">PHP-script</a> aan de serverkant zorgt ervoor dat de afbeeldingen netjes worden bijgeknipt en gecachet. De situatie waarbij je een hele andere afbeelding wilt inladen voor een andere schermbreedte is (nog) niet gedekt door Mingy.</p>
<p>Meteen nadat de browser het pagina-DOM heeft ingelezen, schiet Mingy in actie (<a href="https://github.com/roelvangils/mingy/blob/master/mingy/jquery.mingy.js">bekijk het script</a>). In afwachting van het ophalen van een op maat geschaalde afbeelding, geeft de browser een transparante PNG-afbeelding van 68 bytes weer. Dat is de <a href="http://garethrees.org/2007/11/14/pngcrush/">kleinst mogelijke transparante PNG</a> die je kan maken. Het is de enige betrouwbare manier om te verhinderen dat je browser eerst een veel te grote afbeelding inlaadt en die vervolgens vervangt door een kleinere afbeelding—want dan zouden alle inspanningen voor niks geweest zijn.</p>
<p>Je zal terecht opmerken dat we het aantal HTTP-requests op deze manier wel opvoeren. Een praktijktest illustreert echter dat dat eigenlijk helemaal niet opweegt tegen het verminderde gewicht en de verminderde laadtijd van een pagina met veel afbeeldingen. Het <a href="http://9to5mac.com/2011/08/10/new-in-os-x-lion-network-link-conditioner-utility-lets-you-simulate-internet-and-bandwidth-conditions/">Network Link Conditioner preference pane</a> in Xcode 4 voor Mac OS X Lion helpt je om te simuleren hoe webpagina's ingeladen worden op apparaten met een trage verbinding:</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/nlc.png" alt="Schermafbeelding van het voorkeurenpaneel 'Netwerk Link Conditioner' in Mac OS X" /></p>
<h2>Hoe gebruik je het?</h2>
<p>Opgelet: ik raad af om Mingy te gebruiken op een productiesite. Beschouw het in de eerste plaats als een proof of concept. Ik heb het bijvoorbeeld nog niet aangedurfd om Mingy uigebreid te testen in oudere versies van Internet Explorer, hoewel er in principe weinig kan mislopen.</p>
<p>Net voor het sluiten van je <code>&lt;/body&gt;</code>, laad je het plugin-script:</p>
<pre><code>&lt;script src=&quot;mingy/jquery.mingy.js&quot;&gt;&lt;/script&gt;
</code></pre>
<p>Vergeet ook niet om ook jQuery zelf in te laden, bijvoorbeeld via de CDN van Google:</p>
<pre><code>&lt;script src=&quot;http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js&quot;&gt;&lt;/script&gt;
</code></pre>
<p>In zijn meest eenvoudige vorm, gebruk je de plugin zo:</p>
<pre><code>$(function() {
$('img').mingy();
});
</code></pre>
<p>Maar je kan ook een object met parameters meegeven:</p>
<pre><code>$(function() {
$('img').mingy({
quality: 75,
retina: false,
noscriptFallback: true,
reloadOnResize: true
});
});
</code></pre>
<p>Zoals gezegd, hoef je aan je <code>&lt;img&gt;</code> tags helemaal niets te veranderen:</p>
<pre><code>&lt;img src=&quot;foto.jpg&quot; width=&quot;250&quot; height=&quot;250&quot; alt=&quot;…&quot; /&gt;
</code></pre>
<p>Voorlopig werkt Mingy enkel met JPG-afbeeldingen. Als je de kwaliteit van een individuele JPG wilt wijzigen, kan je optioneel een <code>data</code>-attribuut meegeven:</p>
<pre><code>&lt;img src=&quot;foto.jpg&quot; width=&quot;250&quot; height=&quot;250&quot; alt=&quot;…&quot; data-quality=&quot;50&quot; /&gt;
</code></pre>
<p>In je stylesheet kan je de breedte en hoogte van je afbeeldingen als volgt bijsturen:</p>
<pre><code>@media only screen and (max-width: 1000px) {
img { width: 500px; height: 500px; }
}
@media only screen and (max-width: 500px) {
img { width: 250px; height: 250px; }
}
</code></pre>
<p>Mingy zal alle afbeeldingen binnen de selector scope (<code>$('img')</code> in dit geval) automagisch fysiek herschalen als de breedte van je browservenster voldoet aan de <code>min-width</code> en <code>max-width</code> die je hebt opgegeven.</p>
<h2>Achter de schermen</h2>
<p>Mingy gebruikt Apache's <a href="http://httpd.apache.org/docs/current/mod/mod_rewrite.html">mod_rewrite module</a> en een <code>.htaccess</code> bestand dat je in een map met afbeeldingen plaatst. Ik realiseer me dat dat sommige mensen afschrikt, maar feit is dat het op de meeste webservers gewoon wérkt. Hieronder volgt de inhoud van het <code>.htaccess</code>-bestand. Wie dat wil, kan het herschrijven van de URL trouwens vast ook op een 'anders geaarde' webserver aan de praat krijgen.</p>
<pre><code>&lt;IfModule mod_rewrite.c&gt;
RewriteEngine on
RewriteRule (.*\.jpg)\((.*)\) mingy/resize.php?file=$1&amp;options=$2 [L,QSA]
RewriteRule (.*\.jpg) mingy/resize.php?file=$1&amp;loading=true&amp;noscriptfallback=true [L,QSA]
&lt;/IfModule&gt;
</code></pre>
<p>JavaScript zorgt ervoor dat <code>&lt;img src=&quot;foto.jpg&quot; height=&quot;200&quot; alt=&quot;…&quot; /&gt;</code> omgevormd wordt naar iets als <code>&lt;img src=&quot;foto.jpg(141,141,false,false,70) width=&quot;300&quot; height=&quot;200&quot; alt=&quot;…&quot; /&gt;</code>. Deze URI lijkt op een function call en dat is het eigenlijk ook. Ach, het kon vast net zo goed met vraagtekens en ampersands, maar ik vond dit mooier staan. Bovendien zorgt het voor een betere client-side caching en voorkomt het mogelijk zelfs caching issues met sommige proxy-servers. Dat laatste is slechts een aanname.</p>
<p>De twee belangrijkste parameters zijn de eerste en de tweede: hiermee geven we de gewenste breedte en hoogte door aan het PHP-script. Over de andere drie parameters heb ik het straks nog even (zie 'Handigheidjes').</p>
<p>Het script <a href="https://github.com/roelvangils/mingy/blob/master/mingy/resize.php">resize.php</a> wordt twee keer uitgevoerd als JavaScript aanstaat:</p>
<ul>
<li>De <em>tweede</em> reguliere expressies matcht de originele URL en zorgt ervoor dat de transparante PNG wordt ingeladen.</li>
<li>Onmiddellijk daarna, wanneer het jQuery-script alle <code>src</code>-attributen heeft gemanipuleerd, wordt de <em>eerste</em> regex gematcht en stuurt <code>resize.php</code> een afbeelding met de juiste afmetingen naar de browser. Die wordt op de server gecachet.</li>
</ul>
<p>Bezoekers zonder JavaScript laten we niet in de kou staan (je weet wat er gebeurd is met dat meisje met de zwavelstokjes dat op kerstavond in de kou bleef staan, toch?). Met JavaScript schrijven we een cookie weg (<code>js=true</code>) die we vervolgens met het PHP-script dat de afbeelding genereeert, weer inlezen. Als de cookie niet bestaat, sturen we geen transparante PNG naar de browser, maar gewoon de master image. Dat heeft als nadeel dat bezoekers die cookies uitgezet hebben en JavaScript aan hebben staan, extra image-data te verwerken krijgen.</p>
<h2>Handigheidjes</h2>
<h2>Ook zonder CSS</h2>
<p>Situatie: klant uploadt een 5-megapixel-foto via een upload-knop in een WYSIWYG-editor als CKeditor of TinyMCE en maakt ‘m kleiner door zelf de breedte en hoogte in te tikken in een hiervoor bestemd dialoogvenster. De fysieke bestandsgrootte blijft ongewijzigd, maar enkel de waarde van het <code>width</code>- en <code>height</code>-attribuut worden gewijzigd. Het gevolg is dat je niet alleen je eigen bandbreedte verspilt, maar ook die van je bezoekers. Da's duidelijk een <em>#fail</em>, maar toch zie je het nog vaak gebeuren.</p>
<pre><code>&lt;img src=&quot;bigass_2592x1944.jpg&quot; width=&quot;300&quot; height=&quot;200&quot; alt=&quot;Verspilde bandbreedte /&gt;
</code></pre>
<p>Je kan het de klant natuurlijk niet kwalijk nemen en als je een <a href="http://qontent.nl/">slim CMS</a> gebruikt, is het al helemaal geen issue. In andere gevallen kan Mingy hier mogelijk een uitkomst bieden; het script baseert zich immers (ook) op de waarden van het <code>width</code>- en <code>height</code>-attribuut voor het herschalen van afbeeldingen.</p>
<h2>JPEG-compressie ('quality')</h2>
<p>Omdat de afbeeldingen toch op de server bijgeknipt worden (en gecachet), lag het voor de hand om een optie toe te voegen waarmee je de kwaliteit kan kiezen. Net zoals in het Save for Web-venster van Photoshop, kan je waarden van 1 tot 100 invullen. Als je de tab 'Net' in Firebug of 'Network' in de Webkit Inspector opent, kan je zo in een oogopslag zien welk effect het kiezen van een sterkere compressie heeft op het totale gewicht en de totale laadtijd van je pagina.</p>
<p>Onderstaand screenshot illustreert trouwens ook duidelijk wat ik eerder beschreef: initieel worden de placeholder PNG's van 68 bytes geladen en hierna pas de werkelijke afbeeldingen.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/firebug.png" alt="Schermafbeelding van het Tabblad 'Net → Images' in Firebug voor Firefox" /></p>
<h2>Retina</h2>
<p>Wie een iPhone 4 of iPhone 4S (en arendsogen) heeft, zal de scherpere beeldkwaliteit van foto's in zogeheten retina-kwaliteit mogelijk waarderen. Persoonlijk vind ik het de extra kilobytes niet waard, maar misschien ligt dat aan mijn slechte ogen. Je zou de retina-versie ook kunnen gebruiken voor foto's die zo belangrijk zijn dat je verwacht dat bezoekers erop zullen inzoomen; in dat geval is het meegenomen dat het beeld extra scherp is.</p>
<p>Met JavaScript detecteren we of het apparaat een dubbele resolutie ondersteunt. 'Feature detection' heet dat, met een mooi woord. Probeer het zelf met:</p>
<pre><code>console.log(window.devicePixelRatio &gt; 1); // `true` of `false`
</code></pre>
<ul>
<li><code>retina: true</code> zorgt ervoor dat de resolutie van <em>alle</em> afbeeldingen verdubbeld wordt. Dat is niet zinvol, maar je kan het gebruiken om te debuggen (of om te checken hoe zwaar je pagina wordt voor iPhone 4(s)-gebruikers).</li>
<li><code>retina: auto</code> zorgt ervoor dat de resolutie enkel verdubbeld wordt als het apparaat het beeld ook echt met een dubbele resolutie kan weergeven (hier gebruiken we feature detection).</li>
<li>Met <code>retina: false</code> zet je het helemaal uit. Dit is de standaardwaarde.</li>
</ul>
<p>De retina-parameter geef je mee in de vorm van een <code>data</code>-attribuut (voor een individuele afbeelding) of als onderdeel van het object met opties bij het aanroepen van de plugin (zie eerder).</p>
<h2>reloadOnResize</h2>
<p>Bezoekers waarderen het dat websites netjes de breedte van hun appaaraat of de viewport van hun browser vullen en ze niet horizontaal hoeven te scrollen. Maar ze lopen heus niet als een gek hun browser te resizen of hun tablet in alle mogelijke richtingen te draaien om te kijken wat er dan gebeurt. Nee, dat is beroepsmisvorming; enkel <em>wij</em> kicken erop om te kijken hoe leuk alles meeschaalt en wanneer de media queries hun uitwerking hebben.</p>
<p>Maar omdat het helemaal niet zo ingewikkeld bleek om de afbeeldingen ook bij het resizen van het venster opnieuw in te laden, heb ik er toch maar een optie in gestopt die dat toelaat. En stiekem vind ik het zelf ook wel cool.</p>
<h2>Ten slotte</h2>
<p>Ik heb dit artikel (en het script) in de eerste plaats geschreven om m'n eigen gedachten op een rijtje te zetten. Ik pretendeer niet dat deze aanpak beter is dan eender welke andere aanpak, maar ik vond het vooral leuk om te doen. Als ik de tijd vind, lijkt het me leuk om Mingy te finetunen. En als jij het een leuk idee vindt, nodig ik je uit om het script te forken op <a href="https://github.com/roelvangils/mingy">Github</a>.</p>
<p>Ten slotte wil ik graag JavaScript-whizzkid <a href="https://mathiasbynens.be/">Mathias Bynens</a> bedanken omdat hij zo vriendelijk was om het JavaScript-gedeelte van Mingy met een kritisch oog te bekijken en te optimaliseren. Want eigenlijk ben ik maar een wannabe-developer.</p>
<h2>Over Roel Van Gils</h2>
<img src="https://www.fronteers.nl/_img/2011/12/roel-van-gils.jpg" alt="Foto van roel van gils" class="floating-portrait" />
Roel Van Gils noemt zichzelf webarchitect. Als zelfstandig consultant geeft hij advies en helpt bedrijven en overheden met het bouwen van efficiënte, toegankelijke en gebruiksvriendelijke websites en applicaties. Hij werkt voor het web sinds 2000 en is mede-initiatiefnemer van [AnySurfer](http://www.anysurfer.be/), een Belgische organisatie die ijvert voor een toegankelijker internet voor mensen met een handicap. Roel steekt ook graag een handje toe bij het organiseren van [Fronteers-bijeenkomsten](/bijeenkomsten) in Vlaanderen. Hij twittert als [@roelvangils](https://twitter.com/roelvangils).
<p>Donatie: Belgisch Centrum voor Geleidehonden
In mijn omgeving heb ik zelf gezien hoe een geleidehond het leven van iemand die slechtziend of blind is helemaal kan veranderen. Ik ken jammer genoeg ook mensen die al jaren uitkijken naar een eigen geleidehond–of een opvolger voor een hond die te oud was geworden. Het opleiden van een hond is enorm tijdsintensief en daardoor is de wachtlijst lang. Ik steun het <a href="http://www.geleidehond.be/">Belgisch Centrum voor Geleidehonden</a>, een vzw die sinds 1990 alles in het werkt stelt om honden op te leiden en ze daarna kosteloos ter beschikking stelt aan wie ze echt nodig heeft.</p>
</content>
</entry>
<entry>
<title>3D-graphics</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/3d-graphics"/>
<updated>2011-12-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/3d-graphics</id>
<content xml:lang="nl" type="html"><p>De volgende theorie heeft betrekking op de wijze waarop 3D-graphics berekend worden. Welke processen spelen zich buiten het zicht van de gebruiker af in de computer?</p>
<p>Voor het genereren van computer graphics zijn veel en vaak complexe berekeningen nodig. Een gemiddeld boek over computer graphics staat stijf van de moeilijke formules, die voor de gemiddelde mens niet of nauwelijks te lezen zijn en niet echt uitnodigen om er mee aan de slag te gaan. In deze beknopte handleiding wordt de basis uitgelegd; hoe weet je computer welke kleur een bepaalde pixel heeft, welke delen van een voorwerp zichtbaar zijn, welke niet, et cetera. Met een minimum aan wiskunde.</p>
<p>Houd er rekening mee dat alle complexe theorieën en berekeningen niet voor niets bestaan. Als algemene regel geldt dat hoe hoger de kwaliteit van je 3D-graphics is, hoe complexer de berekeningen worden. Rendertijd kan dramatisch gereduceerd worden met complexe berekeningen. De basis is echter vrij eenvoudig en zijn tientallen jaren geleden al bedacht.</p>
<p>De besproken theorie is een zeer beperkte keuze uit het brede aanbod aan mogelijkheden en geeft een inzicht in hoe je zelf 3D-graphics kunt berekenen of hoe ze berekend worden door je 3D-programma.</p>
<h2>Basis</h2>
<p>Om een 3D-graphic te genereren heb je twee zaken nodig: één of meer virtuele voorwerpen, en een zogenaamd belichtingsmodel. Virtuele voorwerpen bestaan in het algemeen uit polygonen, of vlakken. Het belichtingsmodel beschrijft de manier waarop de virtuele voorwerpen reageren op virtueel licht. Wanneer het eindresultaat fotorealistisch moet zijn, wordt een belichtingsmodel gebruikt dat de fysieke wereld om ons heen zo dicht mogelijk benadert.</p>
<h2>Polygonen</h2>
<p>Virtuele voorwerpen worden in veel gevallen beschreven met behulp van polygonen. Eén enkele polygoon is op zich niet zo interessant. Meerdere polygonen kunnen een virtueel voorwerp representeren, bijvoorbeeld het logo van Fronteers.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/polygoon-object.png" alt="" /></p>
<p>Polygonen zijn oppervlakken die begrensd worden door drie posities of hoekpunten in de ruimte met een x-, y- en z-positie. Polygonen die begrensd worden door drie hoekpunten hebben als voordeel dat ze altijd vlak zijn; je kunt de hoekpunten nooit zo in de virtuele ruimte plaatsen dat de polygoon niet vlak is. Naast polygonen met drie hoekpunten kun je ook polygonen met meer hoekpunten gebruiken, zolang het oppervlak vlak is.</p>
<p>Het is belangrijk dat een polygoon vlak is, omdat de geometrie van de polygoon gebruikt wordt in een aantal processen die gebaseerd zijn op vlakke polygonen. Veel software en hardware is geoptimaliseerd voor het verwerken van polygonen met drie hoekpunten.</p>
<p>De drie hoekpunten van een polygoon worden gebruikt om de ruimte die deze drie posities omsluiten als oppervlak te tonen. Elke positie binnen het oppervlak bestaat uit een x-, y- en z-positie die afgeleid kunnen worden van de drie hoekpunten. De posities zijn belangrijk, omdat deze gebruikt worden om te kijken of het wel of niet zichtbaar is. Wanneer er meerdere polygonen gebruikt worden kan een polygoon de andere overlappen. De positie wordt ook gebruikt om te berekenen welke kleur gebruikt moet worden en of de positie eventueel schaduw heeft.</p>
<p>In veel gevallen wordt een afbeelding gegenereerd. De afbeelding kan een enkele afbeelding zijn of een afbeelding uit een reeks die samen een animatie vormt. In het geval van een spelletje worden de afbeeldingen realtime op je scherm getoond, die net als een afbeelding ook uit pixels bestaat.</p>
<p>Er zijn twee typen afbeeldingen: raster graphics en vector graphics. Vector graphics beschrijven het beeld met behulp van wiskundige curves. Raster graphics of bitmap afbeeldingen bestaan uit puntjes of pixels. Elke pixel heeft een bepaalde kleur, die tezamen het beeld vormen.</p>
<p>Een bitmap afbeelding heeft een bepaald formaat in pixels, bijvoorbeeld 300 pixels horizontaal en 200 pixels verticaal; de afbeelding bestaat uit 60.000 pixels.</p>
<h2>Hoe vertaal je een polygoon naar een afbeelding?</h2>
<p>De posities van de hoekpunten van de polygoon zijn bekend, waardoor de minimum y-positie en maximale y-positie berekend kunnen worden. Eén van de hoekpunten van de polygoon is de minimum y-positie, een andere hoekpunt is de maximum y-positie van de polygoon. Het hoekpunt dat niet het verticale maximum of minimum is, bevindt zich tussen de minimum- en maximum y-positie.</p>
<p>Door de polygoon verticaal van boven naar beneden in horizontale lijnen te scannen kan de polygoon vertaald worden naar een afbeelding.</p>
<p>Het vertalen van een polygoon naar pixels wordt scanconversie of rasterization genoemd.</p>
<p>De horizontale start- en eindposities worden naar een pixelpositie vertaald. Deze horizontale startpositie heeft een x-, y- en z-positie, net als de eindpositie. Deze waarden zijn afgeleid van de drie hoekpuntposities van de polygoon.</p>
<p>Vervolgens worden alle posities die zich tussen de horizontale start- en eindpositie bevinden berekend.</p>
<p>Hoe meer polygonen gebruikt worden, hoe preciezer een virtueel voorwerp beschreven kan worden. Meer polygonen betekent ook dat er meer berekeningen nodig zijn.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/polygoon-scanconversion.png" alt="" /></p>
<p>Net als bij het gebruik van afbeeldingen op een website geldt; hoe hoger de kwaliteit, in veel gevallen hoe realistischer het eindresultaat moet worden, hoe langer het duurt voor de afbeelding geladen is, en in het geval van 3D-graphics hoe langer de rendertijd is.</p>
<p>Wanneer er meerdere polygonen gebruikt worden, is het van belang te weten welke (delen van) polygonen zichtbaar zijn voor de virtuele camera. Het volstaat niet om de polygonen een voor een te renderen.</p>
<p>Wanneer de virtuele camera om een virtueel voorwerp gedraaid wordt, is de ene keer de voorkant zichtbaar en de achterkant niet, deze bevindt zich achter de zichtbare voorkant. Wordt de camera verplaatst dan kan de achterzijde zichtbaar zijn en bevindt de voorkant zich achter de zichtbare achterzijde. Individuele polygonen zijn wel of niet of gedeeltelijk zichtbaar afhankelijk van de positie van de virtuele camera.</p>
<p>Voor het renderen van een virtuele omgeving is het dus noodzakelijk te kijken welke polygonen zichtbaar zijn en welke niet. De polygonen die zich het dichtst bij de camera bevinden zijn zichtbaar en overlappen mogelijk polygonen die verder van de camera verwijderd zijn. De afstand tot de camera wordt gebruikt om te bepalen welke (delen van de) polygonen wel of niet zichtbaar zijn. De afstand tot de camera wordt uitgedrukt als een z-waarde.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/scanconversion.png" alt="" /></p>
<p>Per pixel moet uitgerekend worden welke positie van een polygoon zichtbaar is. Voor elke pixel wordt een stuk geheugen gereserveerd die de z-positie per pixel bijhoudt. Wanneer de z-positie van een polygon lager is dan de waarde in het geheugen (de z-buffer genoemd) wordt deze nieuwe waarde als minimum opgeslagen, met een verwijzing naar de polygoon waar de z-positie aan gerelateerd is.</p>
<p>Je kunt de z-buffer als afbeelding wegschrijven; dit levert een zogenaamde depth image op. Pixels met een hoge intensiteit hebben een lage z-waarde, pixels met een lage intensiteit hebben een hoge z-waarde.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/depth-image.png" alt="" /></p>
<p>Polygonen die zich achter de camera bevinden, hebben een negatieve waarde en worden niet gebruikt, omdat je geen beeld kan zien dat zich achter de camera bevindt.</p>
<h2>Belichtingsmodel</h2>
<p>Om een voorwerp te kunnen zien is het noodzakelijk dat er een vorm van licht is. Licht wordt gereflecteerd door een voorwerp en de weerkaatsing van het licht valt op je netvlies waardoor je het voorwerp ziet.</p>
<p>Per pixel is na scanconversie duidelijk welke x-, y- en z-positie deze heeft. Naast de z-positie wordt bijgehouden bij welke polygoon de z-positie hoort. Met behulp van deze gegevens kan de kleur bepaald worden.</p>
<p>Voor het zichbaar maken van virtuele voorwerpen zijn een of meer virtuele lichten nodig.</p>
<p>Om de kleur van een pixel te bepalen kan virtueel licht opgedeeld worden in een aantal componenten: ambient, diffuus licht en specular, ook wel hooglicht genoemd. Door de intensiteit van deze drie componenten te combineren kan plastic, staal, et cetera nagebootst worden.</p>
<p>Ambient is licht gereflecteerd door alle voorwerpen in een omgeving. Diffuus licht wordt gereflecteerd door het oppervlak van een voorwerp. Afhankelijk van het materiaal waaruit het voorwerp bestaat, wordt licht in meer of mindere mate verstrooid gereflecteerd. Specular of hooglicht ontstaat wanneer een gereflecteerde lichtstraal het oog van de toeschouwer treft. Afhankelijk van de eigenschappen van een voorwerp zal hooglicht wel of niet zichtbaar zijn. Vilt reflecteert licht in vele richtingen, waardoor het licht verstrooid wordt en er niet of nauwelijks hooglicht zichtbaar is. Metaal heeft een vrij dicht en egaal oppervlak, waardoor licht minder verstrooid wordt en hooglicht zichbaar is als de gereflecteerde lichtstralen het oog treffen.</p>
<p>De intensiteit van diffuus licht wordt bepaald door de hoek tussen de lichtbron en de normaal van een polygoon te berekenen. De normaal van een polygoon staat loodrecht op het oppervlak van de polygoon en kan eenvoudig berekend worden met behulp van de drie hoekpunten van de polygoon.</p>
<p>De intensiteit van specular wordt bepaald door de hoek tussen de op het oppervlak gereflecteerde lichtstraal en het oog van de toeschouwer te berekenen. De gereflecteerde lichtstraal wordt berekend met behulp van de positie van de lichtbron en de normaal op het oppervlak van de polygoon. De hoek van inval is gelijk aan die van uitval.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/belichtingsmodel.png" alt="" /></p>
<p>Het belichtingsmodel beschrijft de manier waarop de virtuele voorwerpen reageren op virtueel licht en bepaalt hoe de virtuele voorwerpen eruit komen te zien. Er bestaan vele belichtingsmodellen. De meest basale belichtingsmodellen zijn flat shading, Gouraud shading en Phong shading.</p>
<p>Flat shading is het meest eenvoudige belichtingsmodel. Voor elke polygoon wordt één enkele intensiteit berekend. Alleen de intensiteit van ambient en diffuus licht wordt gebruikt.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/shading-types.png" alt="" /></p>
<p>Gouraud shading is iets complexer. Voor elk hoekpunt van de polygoon wordt de intensiteit van ambient en diffuus licht gebruikt. De polygoon wordt vervolgens ingevuld met deze intensiteit. De drie berekende intensiteiten van de hoekpunten vloeien binnen het oppervlak van de polygoon in elkaar over.</p>
<p>Phong shading is complexer en rekenintensiever dan de voorgangers. Per positie wordt een intensiteit berekend. De intensiteiten van ambient, diffuus en specular worden gecombineerd. De normalen van de hoekpunten van de polygoon worden bij Phong shading gemiddeld met de normalen van aangrenzende polygonen die hetzelfde hoekpunt delen.</p>
<p>De berekende intensiteit wordt gecombineerd met de kleur-waarde van een polygoon en resulteert in de kleur van een pixel.</p>
<h2>Kwaliteit</h2>
<p>Nu bekend is hoe je een virtueel voorwerp zichtbaar kunt maken in de vorm van een afbeelding is de kwaliteit een aandachtspunt. Afhankelijk van de kwaliteit van de gebruikte virtuele voorwerpen kunnen lelijke trapjes, die ook wel jagged edges genoemd worden, ontstaan.</p>
<p>Je kunt dit probleem oplossen door de afbeelding op het dubbele formaat van het gewenste formaat te renderen en vervolgens de afbeelding in Photoshop, of een ander beeldverwerkingsprogramma, te schalen naar het gewenste formaat.</p>
<p>Het menselijke oog is gevoelig voor contrast. Wanneer het contrast vrij laag is, vloeien de kleuren van de pixels probleemloos in elkaar over. Daar waar veel contrast is, zullen de jagged edges storend zichtbaar zijn.</p>
<p>Door een filter—edge detection—op de afbeelding los te laten, kan de afbeelding omgezet worden naar een afbeelding waarbij de pixels met hoog contrast zichtbaar worden.</p>
<p>De intensiteit van pixels met een hoog contrast wordt herberekend. Door niet één positie per pixel te berekenen, maar vier of meer en vervolgens de kleurwaarden te middelen, kunnen de trapjes vermeden worden.</p>
<p>De techniek om jagged edges te vermijden wordt anti-aliasing genoemd.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/anti-aliasing.png" alt="" /></p>
<h2>Conclusie</h2>
<p>3D-graphics zijn overal aanwezig: in films, in spelletjes, in reclame, enz. De basale kennis die je zojuist hebt opgedaan, geeft je een beter inzicht in de manier waarop de beelden tot stand komen. Het zelf maken van 3D-graphics is minder ingewikkeld dan je in eerste instantie misschien zou verwachten. Naarmate kwaliteit, realisme en snelheid belangrijker worden, neemt de complexiteit snel toe.</p>
<p>Zelfs als websitebouwer kun je wat aan 3D-graphicskennis hebben. Probeer je website na te bouwen in een 3D-programma. Als blijkt dat je website niet reproduceerbaar is—je kunt de schaduwen bijvoorbeeld niet namaken—dan is er iets mis met je ontwerp.</p>
<h2>Links</h2>
<ul>
<li><a href="http://ict.debevec.org/~debevec/">Paul Debevec</a></li>
<li><a href="http://paulbourke.net/">Paul Bourke</a></li>
</ul>
<h2>Boeken</h2>
<p>Advanced Animation and Rendering Techniques
Alan Watt, M. Watt, ADDISON-WESLEY, ISBN 0-201-54412-1</p>
<p>Computer Graphics: Principles and Practice in C
James D. Foley, Andries van Dam, Steven K. Feiner, John F. Hughes, ADDISON-WESLEY, ISBN 0-201-84840-6</p>
<p>Fundamentals of three-dimensional computer graphics
Alan Watt, ADDISON-WESLEY, ISBN 0-201-15442-0</p>
<h2>Over Arjan Westerdiep</h2>
<img src="https://www.fronteers.nl/_img/2011/12/arjan-westerdiep.jpg" alt="Foto van arjan westerdiep uit 2011" class="floating-portrait" />
Arjan Westerdiep is gediplomeerd kunstenaar, woordblind en probeert met wisselend succes zowel zijn linker als rechter hersenhelft te gebruiken en te combineren, was weer welkom op de lagere school zodra hij het telefoonnummer van zijn ouderlijk huis wist te onthouden, vindt iets mooi of lelijk en is de maker van [drububu.com](http://www.drububu.com).
<p>Donatie: Leger des Heils
Het Leger des Heils bekommert zich om degenen die niet de middelen, mogelijkheden en luxe hebben zich met zaken als anti-aliasing en z-buffers bezig te houden, omdat het ze ontbeert aan de meest basale middelen om een menswaardig leven te leiden en doen dat zonder enige vorm van discriminatie.</p>
</content>
</entry>
<entry>
<title>Acteurs, schilders en technici</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/acteurs-schilders-en-technici"/>
<updated>2011-12-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/acteurs-schilders-en-technici</id>
<content xml:lang="nl" type="html"><p>Wat doet de moderne front-ender van nu tegenwoordig anno 2011? <a href="http://aneventapart.com/alasurvey2010/#gen" title="Een man ja. In 80% van de gevallen. Sorry.">Hij</a> is een acteur-schilder-technicus.</p>
<p>Als ze me vragen wat ik doe, zeg ik: “Ik maak websites.” Dat snapt m’n oma van 90 en dat snapt m’n dochter van 9. Want iedereen weet tegenwoordig wat een website is en wat je er ongeveer van kunt verwachten. De magie van een eigen website hebben is helemaal voorbij.</p>
<p>Je hebt drie rollen als front-ender: acteur, schilder en technicus.</p>
<h2>De acteur</h2>
<p><img src="https://www.fronteers.nl/_img/2011/12/minifig-acteur.jpg" alt="" /></p>
<p>Je hebt het inlevingsvermogen nodig van een acteur. Wie zich niet in kan leven in zijn klant en zijn doelgroep is geen goede front-ender. Dit inleven vereist begrijpen wat je klant verwacht, meedenken met je klant <em>en</em> het vereist inleven in de uiteindelijke gebruikers van je website. Voor wie dacht dat het niet de moeite waard is om over toegankelijke websites na te denken:</p>
<p>Nederland heeft zo'n 16.7 miljoen inwoners. In deze samenleving leven 238.000 slechtzienden. 78.000 blinden, 700.000 kleurenblinden, 1.300.000 slechthorenden en doven en 1.500.000 lichamelijk gehandicapten. En ten slotte zijn er 825.000 dyslectici en 1.500.000 laaggeletterenden. Dat zijn bij elkaar ruim 4.000.000 Nederlanders met 'een' beperking! (<a href="http://www.frankwatching.com/archive/2011/11/10/toegankelijkheid-van-websites-mythe-of-noodzaak/" title="Lees dat artikel en laat het iedereen op je werk lezen. Toegankelijke websites maak je niet alleen voor blinden en slechtzienden.">bron: toegankelijkheid van websites: mythe of noodzaak</a>)</p>
<p>Veel mensen denken bij accessibility aan blinden en slechtzienden of <a href="http://en.wikipedia.org/wiki/File:Handicapped_Accessible_sign.svg" title="Het -jawel- logo voor toegankelijkheid. #zucht">aan gehandicapten</a>. Onzin dus. Accessibility gaat bijvoorbeeld ook om begrijpelijke teksten op je website. Vermijd jargon; gebruik bijvoorbeeld niet 'authenticatiecode', maar 'inlogcode'. Dat is veel begrijpelijker. Realiseer je dat je je niet kunt inleven in <em>elke</em> mogelijke gebruiker van je website, maar probeer wel telkens te blijven kijken naar je werk met de ogen van <a href="http://www.google.nl/search?q=mien&amp;um=1&amp;ie=UTF-8&amp;hl=nl&amp;tbm=isch&amp;source=og&amp;sa=N&amp;tab=wi">Mien</a>, <a href="http://www.google.nl/search?q=frederik&amp;um=1&amp;ie=UTF-8&amp;hl=nl&amp;tbm=isch&amp;source=og&amp;sa=N&amp;tab=wi">Frederik</a> of <a href="http://www.google.nl/search?q=latif&amp;um=1&amp;ie=UTF-8&amp;hl=nl&amp;tbm=isch&amp;source=og&amp;sa=N&amp;tab=wi">Latif</a>. Want waarschijnlijk komen zij ook op je site. Je maakt het voor de bühne, voor het applaus.</p>
<h2>De schilder</h2>
<p><img src="https://www.fronteers.nl/_img/2011/12/minifig-schilder.jpg" alt="" /></p>
<p>Ik wil graag mooie dingen maken. Webdesign was vroeger het favoriete tijdverdrijf van designers. Dat pikken we nu langzaam maar zeker van ze <a href="http://ghehehe.nl/" title="Ghehehehe. Lache.">af</a>. Wie de komende jaren nog ambities heeft om mooie websites te maken heeft niet meer voldoende aan kennis van Photoshop; het liefst moet hij <a href="http://24ways.org/2009/make-your-mockup-in-markup">ontwerpen in de browser</a>. Ik merk dat ik ontwerpers steeds meer moet laten nadenken over de eindeloze mogelijkheden van het web. Je ontwerper komt niet meer weg met alleen een ontwerp voor een pagina van 960px breed. Of met platte plaatjes zonder dat hij nagedacht heeft over interactie. Je moet de taal en de verschillende verschijningsvormen van het web begrijpen. Je hebt te maken met schermgroottes, verschillende <em>devices</em>, verschillende browsers. De front-ender van nu moet meedenken over de mogelijkheden die CSS, responsive webdesign en complexe interacties bieden.</p>
<p>Eerder heb ik al eens geschreven over hoe ik het <a href="http://www.paulvanbuuren.nl/content/2011/10/31/van-wireframe-naar-realisatie/" title="Achtung: zelfspam.">ideale ontwerpproces</a> zie. Stap voor stap: via schetsen naar mockups en verder naar al dan niet klikbare prototypes. Je rol daarin is niet die van stille uitvoerder.</p>
<p><a href="https://www.fronteers.nl/blog/2011/12/waarom-een-slicer-een-front-end-developer-is-geworden" title="Het artikel van Stijn Janssen op 1 december in deze serie.">Stijn Janssen</a> had het al over ‘slicers’. Dat zijn we niet meer. We plamuren geen websites meer dicht met plaatjes en 'spacer.gif'. We kunnen en moeten meedenken over design. We hebben een mening over de leesbaarheid van websites (zei je '<a href="https://www.youtube.com/watch?v=5AxwaszFbDw" title="Youtube filmpje">make the logo bigger?</a>' Ik zeg: '<a href="http://www.smashingmagazine.com/2011/10/07/16-pixels-body-copy-anything-less-costly-mistake/" title="16px is best wel lekker leesbaar.">groot is leesbaar</a>'). Je photoshopper heeft een mooie foto uitgekozen als background-image. Leuk, maar wat zijn daarvan de consequenties op bepaalde schermen? Wat zijn de mogelijkheden voor afwijkende lettertypen?</p>
<p>Je bent creatief en je kent het medium. Denk mee, schets mee, schrijf mee.</p>
<h2>De technicus</h2>
<p><img src="https://www.fronteers.nl/_img/2011/12/minifig-techneut.jpg" alt="" /></p>
<p>Tegelijkertijd blijven we codekloppers die kunnen <a href="https://www.fronteers.nl/congres/2011/sessions/html5-semantics-bruce-lawson" title="Bruce Lawson op het Fronteers congres in oktober 2011">mierenneuken</a> <a href="http://coding.smashingmagazine.com/2011/09/09/an-introduction-to-less-and-comparison-to-sass/" title="SASS versus Less.">over de ideale editor</a>. Je moet de techniek van CSS, HTML en sommige scripttalen snappen. Je moet uit kunnen leggen wat het verschil is tussen <code>&lt;div&gt;</code>, <code>&lt;span&gt;</code> en <code>&lt;section&gt;</code> is. Dat is techniek, je gereedschap. Dat zijn de <a href="http://www.miniland.nl/lego%20lied/liedje_1.htm" title="Van **** kun je alles maken...">blokken</a> waarmee je bouwt. Je moet een betweter zijn, een priechelaar, een speurneus. Je weet wanneer je welke technieken <a href="http://caniuse.com/" title="Can I use?">wel of niet</a> kunt gebruiken.</p>
<p>Dus.</p>
<p>Nog even en ik kan zeggen dat ik een acteur-schilder-technicus ben. En dat iemand dan zegt: &quot;Ah, dus je maakt dus websites?&quot;</p>
<p class="note">
Overigens ben ik van mening dat er meer vrouwen aan de front-end moeten komen! En dat InDesign alleen gebruikt mag worden voor het layouten van foldertjes.
</p>
<h2>Over Paul van Buuren</h2>
<img src="https://www.fronteers.nl/_img/2011/12/paul-van-buuren.jpg" alt="Foto van paul van buuren" />
Houdt van mooie dingen maken. Werkt bij [Matchminds](http://www.matchminds.nl/). Verzamelt [rare woorden](http://www.paulvanbuuren.nl/content/category/bon-mot-du-jour/). En mag sinds de geboorte van z'n kinderen weer met Lego spelen.
[Twitter](https://twitter.com/paulvanbuuren), [Website](http://paulvanbuuren.nl/about/), [LinkedIn](http://nl.linkedin.com/in/paulvanbuuren)
<p>Donatie: <a href="http://www.zwerfjongeren.nl/">Stichting Zwerfjongeren</a>
Het is raar en onbegrijpelijk dat we hier in Nederland zwerfjongeren hebben. Toch zijn ze er, bijna 10.000 en vooral in de grote steden. Geef ze weer toekomstperspectief. Vind ik.</p>
</content>
</entry>
<entry>
<title>Webrichtlijnen 2: de nieuwe standaard</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/webrichtlijnen-2-de-nieuwe-standaard"/>
<updated>2011-12-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/webrichtlijnen-2-de-nieuwe-standaard</id>
<content xml:lang="nl" type="html"><p>Sinds juni van dit jaar is de nieuwe versie van de Webrichtlijnen, versie 2, de officiële overheidsstandaard. Dit betekent dat overheden bij het bouwen van nieuwe websites moeten kiezen voor deze versie, via het 'pas toe of leg uit'-principe.</p>
<p>Wat houdt die verplichting precies in? Momenteel moeten websites van de rijksoverheid voldoen aan het hoogste niveau, dus alle richtlijnen onder versie 1. Mede-overheden zoals gemeenten en waterschappen moeten eind 2012 voldoen aan prioriteit 1, en per 1 januari 2015 aan de maximale vereisten.</p>
<p>Onder Webrichtlijnen 2 moeten websites voldoen aan het tweede niveau, AA. Dit is dus een verlichting ten opzichte van versie 1.</p>
<p>Minister Donner heeft toegezegd dat er een <em>algemene maatregel van bestuur</em> (AMvB) komt als de resultaten achterblijven.</p>
<p>Bestaande websites die voldoen aan versie 1 van de Webrichtlijnen hoeven niet direct aangepast te worden. Er is een <em>overgangsregeling</em> tot 1 januari 2015, dan vervalt de standaard voor Webrichtlijnen 1. De inspectie conform Webrichtlijnen 2 is nog niet van start gegaan, omdat er nog gewerkt wordt aan de toetsingsdocumentatie. De formele datum van de start van deze inspecties zal worden aangekondigd op <a href="http://www.drempelvrij.nl/">www.drempelvrij.nl</a>.</p>
<p>Overigens zijn het niet alleen overheden die bouwen volgens richtlijnen: er zijn (gelukkig) ook bedrijven die er de voordelen van inzien voor hun bezoekers en voor henzelf en die een waarmerk hebben gekregen. Voorbeelden zijn de SNS-bank (prioriteit 1 voor toegankelijkheid) en Microsoft (Webrichtlijnen).</p>
<p>Nu weten we wat de status is van de nieuwe richtlijnen, maar wat verandert er inhoudelijk nu eigenlijk?</p>
<h2>Verschil in uitgangspunten, eenduidigheid en gelaagdheid</h2>
<p>De nieuwe richtlijnen zijn flexibeler als het gaat om het uitgangspunt voor de te gebruiken technologie. Onder versie 1 moest je bijvoorbeeld HTML 4.01 of XHTML 1.0 Strict gebruiken. De nieuwe richtlijnen zijn <em>technologie-onafhankelijk</em>. Wel moet het <em>door toegankelijkheid zijn ondersteund</em>. Je kunt dus prima HTML5 gebruiken, mits het op zo'n manier gebouwd is dat hulptechnologieën zoals screenreaders er mee om kunnen gaan. Deze benadering is meer toekomstgericht dan die onder Webrichtlijnen 1; het maakt niet uit welke technologieën erbij komen, omdat dit principe altijd toepasbaar zal zijn.</p>
<p>Ten tweede is er nu <em>meer eenduidigheid</em> in internationale context. Onder versie 1 was de relatie met de WCAG1.0 (Web Content Accessibility Guidelines van W3C) ijkpunten niet altijd even duidelijk. In versie 2 is WCAG2.0 één op één opgenomen. Dit past binnen de doelstellingen om internationaal meer op één gemeenschappelijke standaard uit te komen als het gaat om regels en toetsingen voor toegankelijkheid. Dit is bijvoorbeeld interessant voor websites die meerdere landen bedienen.</p>
<p>Voor de duidelijkheid: de <em>kwaliteitsrichtlijnen</em> die binnen de webrichtlijnen aan de WCAG2.0 toegankelijkheidsrichtlijnen zijn toegevoegd, gelden dus alleen in Nederland. Dit is geen 'verbetering' van de WCAG richtlijnen, maar deze zijn er om de algehele toegankelijkheid te vergroten; niet alleen voor mensen met een functiebeperking, maar voor iedereen. Zo zijn unieke en duurzame URI's voor iedereen handig.</p>
<p>Tenslotte is er <em>gelaagdheid</em> toegevoegd aan de webrichtlijnen. Voorheen kon je alleen aan alle 125 richtlijnen voldoen of niet, en veel mensen hadden hier problemen mee. Want als je voldeed aan 120 richtlijnen, dan leek het nog of je nergens aan voldeed, omdat het niet aan te tonen was met een webrichtlijnen waarmerk (wel met een Drempelvrij prioriteit 1 of 2 waarmerk voor toegankelijkheid). In versie 2 zijn er nu ook 3 niveaus in de webrichtlijnen waar je aan kunt voldoen. De niveaus heten nu A, AA en AAA, net als in WCAG2.0. En het zijn er geen 125 meer, maar 22!</p>
<h2>Nieuwe indeling</h2>
<p>De webrichtlijnen hebben nu ook een andere structuur. In plaats van één lange lijst met 125 ijkpunten heb je nu 5 <em>principes</em> met daaronder 12 richtlijnen voor toegankelijkheid en 10 voor bouwkwaliteit. Per richtlijn zijn er verschillende <em>succescriteria</em>. Pas op een dieper niveau staan de technische aspecten. Hier staat gedetailleerde uitleg en er staan voorbeelden van technieken die je kunt gebruiken—<em>afdoende technieken</em>—en veelvoorkomende fouten. Dit deel is dus wel technologie-specifiek, maar deze beschreven technieken zijn niet uitputtend en kunnen in de loop der tijd worden bijgesteld. Nog steeds future-proof dus, en handig als referentie bij het ontwikkelen.</p>
<h2>JavaScript mag. Inline frames ook.</h2>
<p>Een aantal concrete veranderingen tussen versie 1 en versie 2:</p>
<ul>
<li>Een JavaScriptloos alternatief is niet altijd vereist. De manier waarop het gebruikt wordt, moet natuurlijk wel toegankelijk zijn (zoals geen toetsenbordval).</li>
<li>Afkortingen beschrijven is niet langer een basiseis (<code>&lt;abbr&gt;</code>).</li>
<li>Inline frames zijn toegestaan, onder voorwaarde dat de content ook op een andere manier benaderd kan worden.</li>
<li>Well-formedness van opmaaktalen is een basiseis, in plaats van validatie. Het gaat erom dat het op de juiste manier geparsed kan worden.</li>
<li>Unieke en duurzame URI's is geen basiseis (AAA-niveau).</li>
<li>Markeren van dubbele content is nieuw (maar wel AAA-niveau). (En ook erg goed voor SEO.)</li>
<li>PDF's worden onder WCAG2.0 gezien als webpagina's, en moeten daarom ook toegankelijk zijn of er moet een toegankelijk alternatief worden geboden.</li>
</ul>
<h2>Meer eisen op het eerste niveau</h2>
<p>Tenslotte zijn er veranderingen in richtlijnen wat betreft het WCAG niveau waar ze onder vallen. Er is nu een aantal eisen onder prioriteit 1—A niveau—bij gekomen. Voorbeelden hiervan zijn geen toetsenbordval en duidelijke foutmeldingen. Op de website van het W3C staat de <a href="http://www.w3.org/WAI/WCAG20/from10/comparison-priorities/">volledige lijst met vergelijkingen</a>.</p>
<p>De nieuwe richtlijnen zijn te vinden op <a href="http://versie2.webrichtlijnen.nl/norm">versie2.webrichtlijnen.nl/norm</a>.</p>
<p>Voor wie de verschillen wil zien tussen WCAG1.0 en WCAG2.0 staat hier het <a href="http://www.w3.org/WAI/WCAG20/from10/comparison-priorities/">mapping-document van W3C</a>.</p>
<h2>Conclusie</h2>
<p>Al met al een hoop veranderingen voor een meer flexibele en toekomstgerichte set Webrichtlijnen, waar de huidige gebruikte technieken beter in passen. En met de mogelijkheid van een AMvB is er eindelijk ook een stok achter de deur voor (mede-)overheden om er echt aan te gaan voldoen.</p>
<h2>Over Janita Top</h2>
<img src="https://www.fronteers.nl/_img/2011/12/janita-top.jpg" alt="Foto van janita top uit 2011" class="floating-portrait" />
Janita is freelance front-end developer en zit namens Fronteers in de Normcommissie Drempelvrij.nl. Haar kernwoorden, zowel in werk als privé, zijn kwaliteit en duurzaamheid. Ze is gek op (trein)reizen, fietsen en gaat geregeld naar (pop)concerten.
Ze is te vinden op [Twitter](https://twitter.com/sigvi) en op haar eigen website [janitatop.nl](http://www.janitatop.nl/).
<p>Donatie: Sea Shepherd
<a href="http://www.seashepherd.nl/">Sea Shepherd</a> voert directe actie op zee om de afslachting van o.a. walvissen en dolfijnen tegen te gaan en de vernietiging van de leefomgeving te stoppen. Dit is hard nodig om ecosystemen en soorten te beschermen en te behouden. De organisatie krijgt geen subsidies en is daardoor volledig afhankelijk van donaties.</p>
</content>
</entry>
<entry>
<title>Patronen voor de groei</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/patronen-voor-de-groei"/>
<updated>2011-12-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/patronen-voor-de-groei</id>
<content xml:lang="nl" type="html"><p>Zelf, met de hand, een website maken is tegenwoordig zo lastig nog niet. Echter, een grote maatwerk website is heel andere koek. In het begin lijkt het wel simpel maar iedere beslissing heeft invloed op je volgende beslissing en één verkeerde beslissing kan heel snel tot frustratie leiden. Mocht je toevallig het (on)geluk hebben om meerdere grote websites te maken en te onderhouden, dan ben je, als je niet uitkijkt, al heel snel de sigaar.</p>
<p><img src="https://www.fronteers.nl/_img/2011/12/patterns-box.png" alt="" /></p>
<p>Waarom? Niets blijft hetzelfde en het maken van een website is een oefening in constante verandering.</p>
<p>HTML wil je zo hebben dat je het achteraf niet hoeft aan te passen voor CSS of JavaScript. Dergelijke aanpassingen zijn duur, omdat je met nog meer onderhoud wordt opgezadeld, wat uiteindelijk ook de duurzaamheid van je product aantast. Erger nog, het is meestal onnodig en makkelijker te voorkomen dan je denkt.</p>
<p>De truc is om binnen de drie front-end gebieden (HTML, CSS en JavaScript) generiek te zijn waar deze gebieden elkaar raken en specifiek te zijn binnen een enkel gebied.</p>
<h2>Structuurpatroon</h2>
<p><em>Generiek</em>: HTML &amp; JavaScript:</p>
<pre><code>&lt;script src=&quot;init.js&quot;&gt;&lt;/script&gt;
</code></pre>
<p><em>Specifiek</em>: JavaScript:</p>
<pre><code>require(['jquery','jquery-ui','validation'],function(){ … });
</code></pre>
<p><em>Generiek</em>: HTML &amp; CSS:</p>
<pre><code>&lt;link href=&quot;main.css&quot; /&gt;
</code></pre>
<p><em>Specifiek</em>: CSS:</p>
<pre><code>@import url(../normalize.css);
@import url(../forms.css);
</code></pre>
<p><em>Preprocessors zijn uitermate geschikt voor dit soort concatinatie</em></p>
<p>Op deze manier is de kans vele malen groter dat de HTML bij aanpassingen aan de website buiten schot blijft.</p>
<p><a href="http://oocss.org/" title="Object Orientated CSS">OO CSS</a> en de recentere <a href="http://smacss.com/book/" title="Scalable and Modular Architecture for CSS">SMACSS</a> zijn ontstaan, omdat grote schaalbare websites een robuuste front-end structuur nodig hebben. Er is simpelweg geen ruimte om even wat te proberen en weer bij te sturen.</p>
<p>Doordat front-end kennis over de jaren iets beter is geworden hebben we de wat starre OO CSS minder hard nodig. De komst van HTML5, CSS3, preprocessors en dependency loaders maken het namelijk eenvoudiger om een duurzaam semantische website op te leveren. SMACSS, bijvoorbeeld, is door de huidige ontwikkelingen eenvoudiger aan te leren, wat de duurzaamheid weer ten goede komt.</p>
<h2>Nulpatroon</h2>
<p>Resets lijken best handig. Websites in meerdere browservarianten (cross-browser) gelijkend te krijgen is precies wat we allemaal nodig hebben, zou je denken. Om resets echt handig te maken moet ze je van patronen voorzien om ze niet achteraf weer recht te trekken. Aan elementen die op nul zijn gezet heb je niets. Een paragraaf heeft normaliter een witregel aan de onderkant. Een tabelkop is meestal vet 'gedrukt'. Laat ik het zo zeggen: een site moet met een 'reset' vergelijkbaar weergeven en vooral cross-browser gelijkend weergeven alsof men geen CSS had toegepast.</p>
<p>Basistoevoegingen die projectspecifiek zijn, zijn uiteraard welkom. Mogelijk met een specifieke <code>font-family</code> en/of <code>font-size</code> voor de headings, <code>&lt;h1&gt;</code>, <code>&lt;h2&gt;</code>, enz.</p>
<p>Browsers die het <em>heel</em> anders doen bestaan niet meer (zwaait naar IE6), wat de nul-reset onzinnig gemaakt heeft, maar CSS zoals <a href="https://github.com/necolas/normalize.css/">normalise.css</a>* zal als een startpunt waarschijnlijk wel nuttig blijven.</p>
<p><em>* normalize.css bevat nog wel browserspecifieke hacks en hierdoor kan ik het niet zonder reserveringen aanbevelen. Wel kan ik het aanraden om door te nemen; er valt veel van te leren en te lenen.</em></p>
<h2>Content patronen</h2>
<p>ID-attributen zijn lastig, omdat ze vaak de basis vormen voor koppeling met de back-end. Je bespaart jezelf een hoop ellende door ze uit je CSS te houden. Beperk ze desnoods tot een handjevol, want ze kunnen ook handig zijn voor performance. Class-attributen zijn ook lastig, maar daar hoeven we ons minder zorgen over te maken. Een deel van de semantische attributen zijn door HTML5-tags opgevangen. Dat scheelt een heleboel onnodige attributen!</p>
<ul>
<li>Niet altijd mogelijk, maar probeer het gebruik van ID’s voor CSS te vermijden</li>
<li>Overdadig gebruik van het class-attribuut is net zo slecht als overal <code>&lt;div&gt;</code>'s plaatsen</li>
<li>Schrijf functionele ID's en classnames zoals; 'progress', 'sign-in' of 'contact'</li>
<li>Niet functioneel? Maak deze attributen generiek; 'module','warning' of 'information'</li>
<li>Schrijf attributen in de taal van de opmaakcode. HTML is Amerikaans Engels (en-US)</li>
<li>Uitzondering is uiteraard een ID voor een 'hash tag' (<code>&lt;a href=”#informatie”&gt;Lees meer&lt;/a&gt;</code>, <code>&lt;section id=&quot;informatie&quot;&gt;Lorem ipsum…&lt;/section&gt;</code>)</li>
</ul>
<p>Contentspecifieke namen zoals 'dataGridProgress' zijn eigelijk uit den boze en geven meestal dezelfde problemen als attributen die de presentatie spiegelen, zoals:</p>
<pre><code>.blue { color: blue; }
</code></pre>
<p>Webformulieren kunnen eenvoudig generiek worden opgemaakt om vervolgens met een productpatroon te worden aangevuld. Een eenvoudig formulier voor een aanmeldmodule:</p>
<pre><code>&lt;form id=&quot;sendToBackEnd&quot; class=&quot;module log-in&quot;&gt;
&lt;fieldset&gt;
&lt;div&gt;
&lt;label for=&quot;&quot;&gt;E-mail&lt;/label&gt;
&lt;input type=&quot;email&quot; value=&quot;&quot; placeholder=&quot;Enter you e-mail address&quot; /&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;label for=&quot;&quot;&gt;Password&lt;/label&gt;
&lt;input type=&quot;password&quot; placeholder=&quot;password&quot; /&gt;
&lt;/div&gt;
&lt;/fieldset&gt;
&lt;div class=&quot;buttons&quot;&gt;
&lt;button type=&quot;submit&quot;&gt;log in&lt;/button&gt;
&lt;/div&gt;
&lt;/form&gt;
</code></pre>
<p>Maar waarom die extra <code>&lt;div&gt;</code>'s? Semantisch gezien zijn labels met invoervelden nu gescheiden maar belangrijker is dat we dit HTML-patroon op verschillende manieren kunnen vormgeven dankzij de extra <code>&lt;div&gt;</code> om de <code>&lt;label&gt;</code> en <code>&lt;input&gt;</code>. Met grote websites is het altijd moeilijker om de HTML aan te passen dan de CSS. HTML dat continue groeit zorgt er vaak ook voor dat de CSS meegroeit. Idealiter beperk je de impact van dergelijke groei, maar de realiteit denkt daar vaak anders over. Zelfs de grootste controlfreak kan daar weinig aan doen. Jens Meiert mag het nog een keer uitleggen: <a href="http://meiert.com/en/blog/20080926/get-the-html-right/">Get the HTML right</a>.</p>
<p>Zoals je het wellicht is opgevallen ga ik hier niet in op de discussie over <a href="http://www.w3.org/2001/sw/">semantiek</a>; daar is door de jaren heen alles over gezegd en er sindsdien weinig veranderd.</p>
<h2>DRY</h2>
<p>Patronen worden pas nuttig als deze zijn vastgelegd. Productiecode van een website is op zichzelf geen documentatie en is als zodanig ongeschikt. Achteraf discussies voeren over de semantiek in die code heeft op zichzelf weinig waarde. Bepaal vooraf de basispatronen die je voor een website nodig hebt zodat je niet iedere keer het wiel moet uitvinden. Discussies steeds opnieuw moeten voeren is zonde van je tijd. <em>Tip</em>: <a href="https://github.com/adactio/Pattern-Primer">Pattern Primer</a> van Jeremy Keith.</p>
<h2>Maatwerkpatroon</h2>
<p>Met de basis- en standaardpatronen onder je arm kun je nu los met maatwerk CSS. Dit is meestal waar het meteen al scheef gaat. Omdat 'nieuw' vaak gelijk is aan 'we proberen wel wat' en we vervuilen hiermee de HTML en CSS door het te laten staan. Wat niet werkt meteen verwijderen! Dit is waar SMACSS je als gids kan helpen. Beperk je HTML, beperk je classnamen en ID-attributen en beperk je selectorlengte in CSS! <a href="http://www.stuffandnonsense.co.uk/archives/css_specificity_wars.html">Specificity kills</a>! Om dit te realiseren zul je regelmatig moeten beoordelen of je een refactorronde moet inlassen.</p>
<ul>
<li>Een basis die geschikt is om te bootstrappen; <a href="https://github.com/dutchcelt/FE-Patterns">FE-Patterns</a>, <a href="http://html5boilerplate.com/">HTML5 Boilerplate</a> of (ik ben er geen fan van: 960 grid)</li>
<li>Gebruik een modulaire aanpak; SMACSS of OO CSS.</li>
<li>Overweeg een pre-parser; <a href="http://lesscss.org/">LESS</a>, <a href="http://sass-lang.com/">Sass</a> of <a href="http://learnboost.github.com/stylus/try.html">Stylus</a> (met mixins en variabelen mag je weer wat specifieker zijn omdat die binnen de CSS zuil blijven)</li>
</ul>
<p>Dit is uiteraard maar een begin en patronen zijn een goed begin voor ieder project. Daar worden ze namelijk groot en sterk van.</p>
<p>Dus, waar wacht je nog op!? Start je volgende project met een van de bovenstaande patronen of bouw ze zelf!</p>
<h2>Over Egor Kloos</h2>
<img src="https://www.fronteers.nl/_img/2011/12/egor-kloos.jpg" alt="Foto van egor kloos uit 2011" class="floating-portrait" />
Geboren in Dublin en woont al decennia in Rotterdam. [Dutchcelt](http://dutchcelt.nl/ "Weblog van Egor Kloos") creëert sinds 1997 met bloed zweet en tranen moderne websites. Vanaf het begin is 'Web Standards' een passie geweest. De kracht van CSS werd hem heel snel duidelijk en resulteerde in zijn 2003 [CSS Zen Garden inzending](http://www.csszengarden.com/062 "Egor's dubbelzinnige 'gemination'"). Twee site designs (eentje voor IE6) via en enkele CSS en javascript.
Hiermee legde hij de basis voor het maken (en herbouwen) van grote websites in de Enterprise wereld. Daar begeleidt hij zijn klant in alles wat web design en moderne front-end te maken heeft. Nu hij voor [Lunatech Research](http://www.lunatech-research.com/) werkt, heeft hij een deel van zijn [kennis in front-end online](http://www1.lunatech.com/~egor/fep/) kunnen zetten.
<p>Donatie: Electronic Frontier Foundation
Het internet verandert de wereld en als individu is het helaas opboksen tegen te de belangen van overheden en grote bedrijven. Wat we denken, wat we doen en wie dat mag weten, wordt niet altijd in het belang van het individu bepaald. Muziek op je muziekspeler, video op tablet computer en bloggen vanaf je laptop is al gebonden aan regels. Waar gaat dat heen?
De <a href="https://www.eff.org/">Electronic Frontier Foundation</a> vecht voor onze privacy, vecht voor innovatie en dat we onszelf kunnen uiten. Als front-enders werken we op en met het internet en de EFF staat in onze hoek.</p>
</content>
</entry>
<entry>
<title>HTML5 Video | Een overzicht</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/html5-video-een-overzicht"/>
<updated>2011-12-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/html5-video-een-overzicht</id>
<content xml:lang="nl" type="html"><p>HTML5 introduceert verschillende nieuwe tools voor het bouwen van dynamische websites en applicaties. Eén hiervan is het <code>&lt;video&gt;</code> element. In theorie maakt dit het invoegen van video's in websites net zo simpel als het invoegen van afbeeldingen met het <code>&lt;img&gt;</code> element.</p>
<p>In de praktijk is HTML5 video <a href="http://www.longtailvideo.com/support/blog/11887/html5-video-not-quite-there-yet">nog volop in ontwikkeling</a>. Belangrijke opties ontbreken nog, niet alle browsers herkennen <code>&lt;video&gt;</code> en de browsers die dat wel doen ondersteunen verschillende formaten. HTML5 video werkt echter uitstekend op smartphones en tablets (iOS en Android). Al met al kan het, met enig denkwerk, vandaag al gebruikt worden in productie.</p>
<h2>Waarom HTML5 video?</h2>
<p>Het invoegen van video gebeurt nu meestal met de Adobe Flash plugin. Dit werkt uitstekend, dus waarom moet het nu opeens in HTML? Er zijn twee praktische redenen:</p>
<ol>
<li><a href="http://www.apple.com/hotnews/thoughts-on-flash/">Flash wordt niet ondersteund op iOS</a>, het populaire mobiele platform van Apple. HTML5 is de enige manier om webvideo af te spelen op de iPad/iPhone.</li>
<li><a href="http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v5/22644/using-the-html5-video-tag">Het invoegen van een HTML5 video is makkelijk</a>. De video tag is kort en bondig, en ontwikkelaars kunnen hun bestaande CSS en JavaScript vaardigheden gebruiken.</li>
</ol>
<p>Er is ook een belangrijkere, maar minder concrete reden. Om online video echt succesvol te laten zijn, moet het een <a href="https://dev.opera.com/articles/view/a-call-for-video-on-the-web-opera-vid/">First Class Web Citizen</a> worden. Dit maakt het:</p>
<ul>
<li>Toegankelijker, zowel voor (gehandicapte) personen als (exotische) apparaten.</li>
<li>Vindbaarder, bijvoorbeeld vinden via zoekmachines of archieven.</li>
<li>Stabieler en veiliger, omdat de plugin &quot;laag&quot; verdwijnt.</li>
<li>Beter presterend, zowel aan de browser (CPU/GPU) als aan de netwerk (TCP/HTTP) kant.</li>
</ul>
<h2>Browser ondersteuning</h2>
<p>Wie ondersteunt HTML5 video vandaag? Hier is <a href="http://gs.statcounter.com/">een overzichtje</a> (oktober 2011), met daarin de desktop-browsers en mobiele apparaten gemixt:</p>
<table>
<thead>
<tr>
<th>Browser</th>
<th>Marktaandeel</th>
<th>HTML5 ondersteuning</th>
<th>Flash ondersteuning</th>
</tr>
</thead>
<tbody>
<tr>
<td>Internet Explorer 6/7/8</td>
<td>30%</td>
<td>Nee</td>
<td>Ja</td>
</tr>
<tr>
<td>Firefox</td>
<td>25%</td>
<td>Ja (WebM)</td>
<td>Ja</td>
</tr>
<tr>
<td>Chrome</td>
<td>20%</td>
<td>Ja (MP4 + WebM)¹</td>
<td>Ja</td>
</tr>
<tr>
<td>Internet Explorer 9</td>
<td>10%</td>
<td>Ja (MP4)</td>
<td>Ja</td>
</tr>
<tr>
<td>Safari</td>
<td>4%</td>
<td>Ja (MP4)</td>
<td>Ja</td>
</tr>
<tr>
<td>iOS</td>
<td>3%</td>
<td>Ja (MP4)</td>
<td>Nee</td>
</tr>
<tr>
<td>Opera</td>
<td>2%</td>
<td>Ja (WebM)</td>
<td>Ja</td>
</tr>
<tr>
<td>Android</td>
<td>1%</td>
<td>Ja (MP4)</td>
<td>Ja²</td>
</tr>
<tr>
<td>Windows Phone</td>
<td>0%</td>
<td>Ja (MP4)</td>
<td>Nee</td>
</tr>
<tr>
<td>Overig (&quot;dumbphones&quot;)</td>
<td>5%</td>
<td>Nee</td>
<td>Nee</td>
</tr>
</tbody>
</table>
<ol>
<li>Chrome heeft afgelopen januari aangekondigd MP4 <a href="http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html">&quot;binnenkort&quot; te verwijderen</a>. Tot dusver werkt het nog.</li>
<li>Adobe is <a href="http://blogs.adobe.com/conversations/2011/11/flash-focus.html">gestopt met het ontwikkelen</a> van Flash voor mobiel. Android 4.0 is de laatste versie met Flash ondersteuning.</li>
</ol>
<p>Tweederde van de markt kan dus HTML5 video afspelen. Uiteraard kunnen oude versies van IE (6/7/8) dit niet, maar zij draaien wel Flash (als fallback optie). Het aandeel van mobiele browsers (iOS en Android) is nog klein (5%), maar snel groeiend.</p>
<p>In de HTML5 kolom worden de ondersteunde video formaten vermeld. Sommige browsers ondersteunen <em>MP4</em>, anderen weer <em>WebM</em>. Alleen Chrome ondersteunt beide. Dit gebrek aan een standaard video formaat is het grootste probleem voor HTML5 video.</p>
<h2>Het codec probleem</h2>
<p>Eerst een korte uitleg van video formaten. Ze bestaan grofweg uit drie bouwstenen:</p>
<ol>
<li>De <a href="http://en.wikipedia.org/wiki/Container_format">container</a> bevat alle metadata inclusief de audio/video codec info, maar niet de frames/samples zelf.</li>
<li>De <a href="http://en.wikipedia.org/wiki/Video_codec">video codec</a> bevat de eigenlijke, gecodeerde video frames.</li>
<li>De <a href="http://en.wikipedia.org/wiki/Audio_codec">audio codec</a> bevat de eigenlijke, gecodeerde audio samples.</li>
</ol>
<p>Hoe beter de video en audio codecs zijn, hoe beter (kleinere bestanden, eenvoudiger te coderen) het video formaat is. Op dit moment worden er twee (uitstekende) formaten gebruikt in HTML5:</p>
<ul>
<li>Het <a href="http://en.wikipedia.org/wiki/MP4">MP4-formaat</a>, met daarin de <a href="http://en.wikipedia.org/wiki/H264">H.264 video codec</a> en de <a href="http://en.wikipedia.org/wiki/Aac">AAC audio codec</a>.</li>
<li>Het <a href="http://en.wikipedia.org/wiki/Webm">WebM formaat</a>, met daarin de <a href="http://en.wikipedia.org/wiki/VP8">VP8 video codec</a> en de <a href="http://en.wikipedia.org/wiki/Vorbis">Vorbis audio codec</a>.</li>
</ul>
<p>Qua kwaliteit doen de twee formaten <a href="http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/WebM-vs.-H.264-A-Closer-Look-68594.aspx">niet veel onder voor elkaar</a>. Het grote verschil zit hem in hun IP:</p>
<ul>
<li>MP4 (H264/AAC) wordt breed ondersteund in de video-industrie, maar is volledig dicht gepatenteerd. <a href="http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65403">Zowel voor encoderen, publiceren als decoderen</a> zijn licenties nodig.</li>
<li>WebM (VP8/Vorbis) is daarentegen <a href="http://www.webmproject.org/">patent-vrij en open source</a> (net als alle andere W3C technologieën). Het formaat is vrij nieuw, met een klein ecosysteem van encoders en decoders.</li>
</ul>
<p>In deze afweging tussen pragmatisme en patenten hebben sommige browsers gekozen voor het eerste (MP4) en anderen voor het laatste (WebM). Het resultaat is dat je nu je video twee keer moet encoderen om alle HTML5 browsers te ondersteunen. Als WebM op termijn meer tractie krijgt, zal dat veranderen, maar dit is een langzaam proces.</p>
<p class="note">
Er is trouwens nog een derde HTML5 formaat: [Ogg](http://en.wikipedia.org/wiki/Ogg). Het is kwalitatief stukken minder dan MP4/WebM, maar werd ondersteund door Firefox en Opera voordat [Google WebM vrijgaf](http://www.longtailvideo.com/support/blog/12120/googles-vp8webm-and-what-it-means-for-you). De enige browser die nog Ogg vereist, is [het snel verdwijnende](http://gs.statcounter.com/#browser_version-ww-monthly-201101-201112) Firefox 3.6.
</p>
<h2>Video en sources</h2>
<p>Nu door naar de video tag zelf. Kort en bondig, als beloofd:</p>
<pre><code>&lt;video
controls
height=&quot;360&quot;
poster=&quot;/files/bunny.jpg&quot;
src=&quot;/files/bunny.mp4&quot;
width=&quot;640&quot;&gt;
&lt;/video&gt;
</code></pre>
<p>De <code>controls</code> optie rendert een ingebouwde navigatiebalk, de <code>height</code> en <code>width</code> bepalen de dimensies van de video, de <code>poster</code> linkt naar een screenshot van de video en de <code>src</code> linkt naar de video zelf. Daarnaast zijn er nog de <code>autoplay</code>, <code>preload</code> en <code>loop</code> opties om het <a href="http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v5/22644/using-the-html5-video-tag">afspelen te controleren</a>.</p>
<p>Om het twee-codec-probleem te faciliteren bevat HTML5 een tweede element: <code>&lt;source&gt;</code>. Meerdere source elementen kunnen worden genest in één video. HTML5 browsers inspecteren de source elementen en spelen de eerste die ze ondersteunen:</p>
<pre><code>&lt;video controls height=&quot;360&quot; poster=&quot;/files/bunny.jpg&quot; width=&quot;640&quot;&gt;
&lt;source src=&quot;/files/bunny.mp4&quot; type=&quot;video/mp4&quot; /&gt;
&lt;source src=&quot;/files/bunny.webm&quot; type=&quot;video/webm&quot; /&gt;
&lt;/video&gt;
</code></pre>
<p class="note">
De [HTML5 specificatie](http://www.w3.org/TR/html5/video.html) beschrijft ook het toevoegen van de audio/video codecs aan de type optie. In de praktijk is dit niet nodig, omdat alle browsers deze waardes negeren en codecs detecteren tijdens het downloaden van de video.
</p>
<p>Bovenstaand stukje HTML resulteert in theorie in een consistente video weergave in alle HTML5 browsers. In de praktijk zijn er echter nog allerlei <a href="http://camendesign.com/code/video_for_everybody#notes">bugs en gaten in implementatie</a>. Het handmatig omzeilen van deze issues is een rotklus. Een HTML5 Video Player kan daarbij helpen.</p>
<h2>HTML5 video players</h2>
<p>Een HTML5 Video Player is een aparte JavaScript bibliotheek die zowel de video's op een pagina als de browser ondersteuning detecteert. De bibliotheek werkt vervolgens om de tekortkomingen van de browser heen. De term Video Player is dus enigszins misleidend, want het is nog steeds de browser die de video afspeelt.</p>
<p>Er zijn <a href="http://praegnanz.de/html5video/">behoorlijk wat</a> van deze bibliotheken in ontwikkeling. Ze bieden meestal:</p>
<ul>
<li>Het corrigeren voor browser bugs. Vooral Android en iOS hebben kritieke bugs in hun parsing en rendering van video elementen.</li>
<li>Het terugvallen op de Flash-plugin. Dit is nodig voor oude browsers (IE 6/7/8), en voor Firefox/Opera als je <a href="http://www.longtailvideo.com/support/blog/17843/browser-video-codec-support-does-it-matter">alleen MP4 gebruikt</a>.</li>
<li>Het renderen van een consistente navigatie. De ingebouwde navigatie van iedere HTML5 browser ziet er namelijk anders uit, en kan niet gestyled worden.</li>
<li>Het aanbieden van een pseudo-fullscreen-optie, door de video naar het volledig browservenster te vergroten. In tegenstelling tot Flash is er nog geen daadwerkelijk fullscreen in HTML5, <a href="https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI">maar daar wordt aan gewerkt</a>.</li>
</ul>
<p>Naast deze functies ondersteunen sommige Video Players zaken als afspeellijsten, ondertiteling of in-video adverteren. Eén belangrijke video functie kunnen ze niet via scripting ondersteunen: <em>streaming</em>. Dit zal ingebouwd moeten worden door de browsers zelf.</p>
<h2>Video streaming</h2>
<p>Het grootste obstakel voor snelle adoptie van HTML5 is het ontbreken van één enkel formaat. Dit heeft als direct gevolg dat HTML5 video's 2x geëncodeerd en 2x opgeslagen moeten worden. Dit heeft echter ook als gevolg dat er <a href="http://www.longtailvideo.com/support/blog/18059/w3c-webtv-adaptive-streaming-content-protection">geen standaard streaming mechanisme is</a>:</p>
<ul>
<li>Video wordt dus altijd geleverd als een &quot;download&quot;, waarbij veel data wordt gedownload maar niet bekeken.</li>
<li>Het aanpassen van de kwaliteit midden in een video is niet mogelijk, net nu dat zo belangrijk is voor mobiel.</li>
<li>Het live streaming van evenementen en kanalen is niet mogelijk, omdat dit geen te downloaden files zijn.</li>
<li>Beveiliging door middel van encryptie (meestal deel van het streaming protocol) bestaat niet in HTML5.</li>
</ul>
<p>Hierdoor is <a href="http://www.longtailvideo.com/support/blog/11887/html5-video-not-quite-there-yet">HTML5 video geen optie</a> voor media bedrijven. Zij hebben Flash (of Silverlight) nodig tot een HTML5 video streaming protocol is gestandaardiseerd.</p>
<p>Op iOS is er echter wél een streaming protocol, volledig door Apple bedacht en geïmplementeerd bovenop HTML5. Het heet <a href="http://developer.apple.com/resources/http-streaming/">HTTP Live Streaming</a> (HLS) en wordt ondersteund door alle iPads en iPhones. Een HLS stream kan worden geladen in een video-tag, net als een MP4-of WebM video:</p>
<pre><code>&lt;video controls height=&quot;360&quot; poster=&quot;/files/bunny.jpg&quot; width=&quot;640&quot;&gt;
&lt;source src=&quot;/files/bunny.m3u8&quot; type=&quot;application/vnd.apple.mpegurl&quot; /&gt;
&lt;source src=&quot;/files/bunny.mp4&quot; type=&quot;video/mp4&quot; /&gt;
&lt;source src=&quot;/files/bunny.webm&quot; type=&quot;video/webm&quot; /&gt;
&lt;/video&gt;
</code></pre>
<p>Door de populariteit van iOS (en de afwezigheid van alternatieven) is het HLS protocol flink gegroeid:</p>
<ul>
<li>Alle <em>pro</em> video op de iPad gebruikt HLS (voor in-app video <a href="http://developer.apple.com/news/index.php?id=02162010a">is HLS zelfs vereist</a>).</li>
<li>Alle streaming servers (Adobe, Microsoft, Real, Wowza) ondersteunen tegenwoordig HLS.</li>
<li>Alle IPTV set-top boxes (XBox, PS3, Apple TV, Roku, Boxee) ondersteunen tegenwoordig ook HLS.</li>
<li>Zelfs Android doet HLS, <a href="http://developer.android.com/sdk/android-3.0-highlights.html">vanaf versie 3.0</a> (Honeycomb).</li>
</ul>
<p>Ondanks dit succes is HLS (nog) niet deel van een web-standaard. Bredere ondersteuning, bijvoorbeeld door Internet Explorer, zou nuttig zijn, maar is onzeker. Betekent dit dan dat HTML5 video vooral leuk is voor korte clipjes en iPads? Absoluut niet. Hoewel streaming nog niet is gefixt, is er een andere ontwikkeling die HTML5 een groot voordeel geeft ten opzichte van Flash.</p>
<h2>Track en WebVTT</h2>
<p>Naast <code>&lt;video&gt;</code> en <code>&lt;source&gt;</code> definieert de <a href="http://www.w3.org/TR/html5/video.html">HTML5 video specificatie</a> een derde nieuwe element: <code>&lt;track&gt;</code>. Met dit element is het mogelijk om verschillende soorten data te synchroniseren met de video:</p>
<ul>
<li><em>Ondertiteling</em> van dialogen in andere talen.</li>
<li><em>Ondertitels</em> van de audio, zowel spraak als anders. Dit voor slechthorenden, of situaties zonder geluid.</li>
<li><em>Audio descripties</em> van de visuele elementen. Bedoeld voor audio synthese voor slechtzienden, of situaties zonder beeld.</li>
<li><em>Hoofdstuk markeringen</em>, voor het snel navigeren door langere videos.</li>
<li><em>Metadata</em>, zelf in te vullen data voor gebruik in scripts.</li>
</ul>
<p>De data van deze tracks wordt opgeslagen in het <a href="http://blog.gingertech.net/2011/06/27/recent-developments-around-webvtt/">nieuwe WebVTT bestandsformaat</a>, een eenvoudige tekst formaat vergelijkbaar met <a href="http://en.wikipedia.org/wiki/SubRip">SRT</a>. Hier is een fragment, met twee ondertitels:</p>
<pre><code>1
00:13:45.250 -&gt; 00:13:48.000
Hello world!
2
00:13:49.910 -&gt; 00:13:56.500
Well, hello to you too!
- Thanks. Any coffee left?
</code></pre>
<p>Deze WebVTT bestanden worden ingeladen in de <code>&lt;track&gt;</code> elementen net als videos in <code>&lt;source&gt;</code> elementen:</p>
<pre><code>&lt;video controls height=&quot;360&quot; poster=&quot;/files/bunny.jpg&quot; width=&quot;640&quot;&gt;
&lt;source src=&quot;/files/bunny.mp4&quot; type=&quot;video/mp4&quot; /&gt;
&lt;source src=&quot;/files/bunny.webm&quot; type=&quot;video/webm&quot; /&gt;
&lt;track label=&quot;Closed Captions&quot; kind=&quot;captions&quot; src=&quot;/files/bunny-cc.vtt&quot; /&gt;
&lt;track label=&quot;Auf Deutsch&quot; kind=&quot;subtitles&quot; src=&quot;/files/bunny-de.vtt&quot; /&gt;
&lt;/video&gt;
</code></pre>
<p>Met tracks en WebVTT kan HTML5 video eenvoudig toegankelijk gemaakt worden, voor zowel buitenlandse sprekers als mensen met een beperking. In Flash was dit <a href="http://www.longtailvideo.com/support/jw-player/22/making-video-accessible">altijd erg lastig</a>, doordat een standaard methode ontbrak. Daarnaast zullen andere toepassingen profiteren van de metadata in WebVTT bestanden. Denk aan video SEO en in-video search, het targeten van advertenties op bepaalde scènes, of de interactie tussen de <a href="http://popcornjs.org/">webpagina en video tijdlijn</a>.</p>
<p>Er is nog één probleempje: zowel <code>&lt;track&gt;</code> als WebVTT <em>bestaan nog niet in browsers</em>. De specificatie is wel <a href="http://www.w3.org/community/texttracks/">zo goed als af</a> en browser-implementaties komen eraan. Waarschijnlijk zullen alle browsers dit eind 2012 ondersteunen.</p>
<h2>Wanneer HTML5?</h2>
<p>Op de lange termijn vervangt HTML5 Flash voor het afspelen van video. Momenteel biedt Flash echter nog een betere gebruikservaring op de desktop. Dus op welk punt heeft het zin om <em>HTML5 first</em> te gaan? Dat hangt af van de manier waarop je video gebruikt:</p>
<ul>
<li>Als video een core business is en je afhankelijk bent van streamen en beveiliging, wordt het wachten totdat er een streaming mechanisme komt. Dat kan nog jaren duren.</li>
<li>Als video gebruikt wordt voor marketing/educatie en bereik, gebruiksgemak en toegankelijkheid belangrijk zijn, wordt het wachten op een hogere dekking (90%) en de beschikbaarheid van <code>&lt;track&gt;</code>. Beiden zitten er aan te komen in 2012.</li>
<li>Als video geen core business is, maar webdesign wel, kun je vandaag al aan de slag met HTML5. Je moet wel je video's dubbel encoderen en je HTML regelmatig bijwerken voor nieuwe features en bugs. Je kunt echter ook meteen met CSS en JavaScript aan de slag om eigen video players te maken.</li>
</ul>
<p>Voor mobiele apparaten is het sowieso nu het best om HTML5 te gebruiken (hetzij integraal, hetzij als fallback). Android en iOS ondersteunen beide HTML5, terwijl Flash op Android aan het verdwijnen is. Bovendien ondersteunen ze, in tegenstelling tot desktop browsers, beiden één formaat (MP4).</p>
<h2>Over Jeroen Wijering</h2>
<img src="https://www.fronteers.nl/_img/2011/12/jeroen-wijering.jpg" alt="Foto van jeroen wijering uit 2011" class="floating-portrait" />
Jeroen Wijering is de ontwikkelaar [achter de succesvolle JW Player](http://www.whoisjw.tv/), die wordt gebruikt op miljoenen websites wereldwijd. Zijn bedrijf [LongTail Video](http://www.longtailvideo.com/) beheert ook een gratis online platform waarbinnen bedrijven hun video's kunnen encoderen en publiceren.
Jeroen is te vinden [op twitter](https://twitter.com/jeroenw) en schrijft af en toe een artikel op [www.longtailvideo.com/blog](http://www.longtailvideo.com/blog).
<p>Donatie: Stichting Aap
<a href="http://www.aap.nl/">Stichting Aap</a> is een sympathiek en kleinschalig opvangcentrum voor uitheemse dieren. De dieren die er terecht komen zijn afkomstig van proefdierlaboratoria, circussen, louche dierentuinen of particulieren. Belangrijker is dat ze ook campagnes voeren voor preventie en gewaarwording, zowel in de politiek als bij het publiek.</p>
</content>
</entry>
<entry>
<title>Waarom een slicer een front-end developer is geworden</title>
<link href="https://www.fronteers.nl/nl/blog/2011/12/waarom-een-slicer-een-front-end-developer-is-geworden"/>
<updated>2011-12-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/12/waarom-een-slicer-een-front-end-developer-is-geworden</id>
<content xml:lang="nl" type="html"><p>Het internet gebruikte je vroeger enkel voor het weergeven van simpele, gestructureerde gegevens. Met de stijgende populariteit van het internet wilde iedereen zijn eigen website onderscheiden van de andere. Naast de interessante content die je op je website toonde, wilde je ook een visueel onderscheid maken ten opzichte van de rest van de wereld. Je wilde je eigen stempel drukken op het groeiende internet. Ik ben op zoek gegaan naar het verhaal achter het woord 'slicer' en hoe dit geëvolueerd is naar een volwaardig beroep als front-end developer.</p>
<h2>De slicer</h2>
<p>Het gebruik van het woord slicer dateert uit de periode dat je in Adobe Photoshop de slice-tool gebruikte om een ontwerp 'op te snijden'. Het gebruik van Adobe Photoshop en Adobe ImageReady maakte het voor iedereen gemakkelijk om een eigen ontwerp om te vormen tot een volwaardige website. Je ontwierp alles in Photoshop, daarna zou je dat bestand exporteren naar Adobe ImageReady om daar elk stukje (slice) te benoemen of er een link van te maken. Daarnaast kon je ook kiezen welk bestandsformaat voor de afbeelding werd gebruikt of zelfs animated GIF's maken. Dit kon je exporteren naar een HTML-versie die dan uiteindelijk je website werd.</p>
<p>In die tijd was het geen eer om jezelf een slicer te noemen. Het omzetten van je ontwerpen naar HTML was toen niet meer dan een last waar je snel van af wilde zijn. Het enige dat telde was dat je ontwerp voor iedereen op het internet zichtbaar was. De code die Adobe ImageReady genereerde bestond volledig uit tabellen en afbeeldingen. Het was een hel om zo'n bestand later te bewerken maar het was toen de enige manier om je content visueel goed weer te kunnen geven.</p>
<h2>Meer dan tabellen</h2>
<p>HTML is een markup language die dient voor het opmaken van de structuur van je document en niet voor stijlen van je pagina. Zo gebruik je tabellen om gestructureerde data weer te geven, niet om je pagina vorm te geven. Websites werden ook groter en dynamischer. Je kon nog onmogelijk elke pagina gaan slicen met behulp van Adobe ImageReady. Met de introductie van CSS ging er een heel nieuwe wereld open. Aan de hand van stylesheets kon je het visuele aspect van je website onderhouden en verbeteren.</p>
<p>Op langere termijn werden verschillende nieuwe aspecten toegevoegd aan het ontwikkelen van websites en werd het takenpakket van de slicer enorm uitgebreid. Naast het gebruik van CSS kon je ook gebruik maken van JavaScript om je website van animaties te voorzien. Als je verder wilde gaan dan enkele simpele animaties deed je dat met Adobe Flash. Met een verder stijgende populariteit van het internet moest je je websites ook toegankelijk maken. Iedereen is immers welkom op jouw website. Niet te vergeten werd je website ook geïndexeerd door zoekmachines, die je ook tevreden diende te houden. De slicer evolueerde dus naar een persoon die meer deed dan de slice-tool van Adobe ImageReady te gebruiken. Als goede slicer had je dan ook de nodige kennis van HTML, CSS, JavaScript, Flash, toegankelijkheid, SEO...</p>
<p>Elk van deze taken werd belangrijker in een website en ging vernieuwen. De moderne slicer maakt de dag van vandaag gebruik van HTML5 en CSS3. De mogelijkheden zijn enkel nog gelimiteerd door je eigen verbeelding. Bij wijze van spreken toch. Want een slicer moet niet enkel weten wat de mogelijkheden zijn maar ook het kennen van de compatibiliteit van deze specificaties in de verschillende browsers is enorm belangrijk.</p>
<h2>De front-end developer</h2>
<p>Je hoort al een tijdje spreken over een front-end developer, de moderne slicer. De front-end developer kreeg de laatste jaren een heel belangrijke rol in het hele proces. Hij (of zij) is een multifunctioneel persoon die de harmonie bewaart tussen het ontwerp en de back-end. Een ontwerper heeft meer te vertellen dan enkel een afbeelding. Het is aan de front-end developer om dit te begrijpen en verder te bouwen aan dit verhaal. Langs de andere kant moet hij ook zorgen dat alle functies van de back-end volledig benut worden om de bezoeker een optimale ervaring te bezorgen.</p>
<p>Technologie staat niet stil, dat weten we al langer. Als front-end developer ga je niet enkel je kennis vergroten door ervaring, je gaat ook op zoek naar nieuwe best practices en nieuwe technieken. Je maakt graag gebruik van de laatste technologieën, maakt je websites responsive en nog meer toegankelijk (mobiel is ook een vorm van toegankelijkheid). Je gebruikt nu al zoveel mogelijk van de CSS3 specificaties en kijkt maar al te graag uit naar de dag dat je de meeste HTML5 API's dagelijks kan gebruiken. Met je uitgebreide kennis van JavaScript en zijn frameworks kan je je al perfect meten met desktopvarianten.</p>
<h2>De uitdagingen van een front-end developer</h2>
<p>Met de verdere groei van de sector wordt de rol van front-end developers nog belangrijker. Het is hun taak om de ontwerpen van de designers nog verder te vertalen naar een complete ervaring voor de bezoeker. Zeker naar de mobiele (en dus de responsive) markt is de impact enorm. Daarnaast gaan we ook andere soorten ontwikkelaars zien overstappen naar front-end development. Zo zien we nu al af en toe een Flash developer die meer gebruik gaat maken van HTML5 en CSS3 en zullen we ook game developers zien overschakelen naar HTML5 en WebGL. Ook Java developers zien gelijkenissen met client-side databases en Web Storage.</p>
<h2>Nooit meer een slicer</h2>
<p>Het is tijd dat we de woorden slicer, slice en slicing vergeten en schrappen uit ons woordenboek. Laten we een front-end developer nooit meer een slicer noemen. De titel 'front-end developer' is ondertussen eentje waar je trots op mag zijn. Organisaties zoals Fronteers benadrukken dan ook dat deze titel niet zomaar voor iedereen is weggelegd. Iets wat mede door de komende 23 artikelen duidelijk zal worden.</p>
<h2>Over Stijn Janssen</h2>
<img src="https://www.fronteers.nl/_img/2011/12/stijn-janssen.jpg" alt="Foto van stijn janssen uit 2011" class="floating-portrait" />
Door de dag vermomd als webdeveloper bij [Inventis](http://www.inventis.be/), 's avonds als freelance front-end developer bij [Recode](http://www.recode.be/). [Stijn](http://www.stijnjanssen.be/) is dag en nacht bezig met front-end development.
<p>Donatie: Project OSJOSMA
<a href="http://www.osjosma.be/">VZW Osjosma</a> is een kleine organisatie die een weeshuis heeft gebouwd in Haïti. Ik ken het verhaal van de organisatie al een tijdje en het is een organisatie met duidelijke doelen en een mooie toekomstvisie. De hoofdzetel van de organisatie is amper 2 straten verder dan mijn woonst. Ik ben blij dat ik via deze weg de kinderen in het weeshuis mee kan steunen.</p>
</content>
</entry>
<entry>
<title>Adventskalender 2011</title>
<link href="https://www.fronteers.nl/nl/blog/2011/11/adventskalender"/>
<updated>2011-11-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/11/adventskalender</id>
<content xml:lang="nl" type="html"><p>Vanaf morgen verschijnt op ons weblog elke dag, tot aan kerst, een artikel gerelateerd aan front-end webtechnologieën. Bijna alle bijdragen voor <a href="https://www.fronteers.nl/blog/categorieen/adventskalender">deze adventskalender</a> zijn geschreven door Fronteersleden.</p>
<p>Middels de artikelen willen we de kennis binnen Fronteers verspreiden onder andere leden, en natuurlijk naar niet-leden. De artikelen hebben zeer diverse onderwerpen, zodat iedereen—zowel beginner als gevorderde—iets op kan steken van deze reeks.</p>
<p>Elke schrijver heeft de mogelijkheid om 75 euro uit de verenigingskas te doneren aan een goed doel, waarvan de schrijver denkt dat die een hart onder de riem kan gebruiken deze kerst.</p>
<p>Alle vierentwintig schrijvers, de editors en andere vrijwilligers kijken uit naar het eerste artikel dat morgen geplaatst zal worden.</p>
<h2>Update, hieronder alle artikelen in deze reeks:</h2>
<ol>
<li><a href="https://www.fronteers.nl/blog/2011/12/waarom-een-slicer-een-front-end-developer-is-geworden">Waarom een slicer een front-end developer is geworden</a> door Stijn Janssen</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/html5-video-een-overzicht">HTML5 Video | Een overzicht</a> door Jeroen Wijering</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/patronen-voor-de-groei">Patronen voor de groei</a> door Egor Kloos</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/webrichtlijnen-2-de-nieuwe-standaard">Webrichtlijnen 2: de nieuwe standaard</a> door Janita Top</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/acteurs-schilders-en-technici">Acteurs, schilders en technici</a> door Paul van Buuren</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/3d-graphics">3D-graphics</a> door Arjan Westerdiep</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/responsive-images-een-experiment">Responsive images; een experiment</a> door Roel Van Gils</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/front-end-meta-languages">Front-end meta languages</a> door Roy Tomeij</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/javascript-pret-met-alle-karakters-in-een-string">JavaScript-pret met alle karakters in een string</a> door Mathias Bynens</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/waarom-standaarden-essentieel-zijn">Waarom standaarden essentieel zijn</a> door Andreas Creten</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/een-tik-op-de-neus">Een tik op de neus</a> door Vasilis van Gemert</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/het-is-al-goud-wiens-cursor-blinkt">Het is al goud wiens cursor blinkt</a> door Jan Moesen</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/kijk-mama-zonder-afbeeldingen-grafische-elementen-maken-met-css">Kijk mama, zonder afbeeldingen! Grafische elementen maken met CSS</a> door Lennart Schoors</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/clients-from-heaven">Clients from heaven</a> door Ruben Bos</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/het-platform-bouwen">Het platform bouwen</a> door Anne van Kesteren</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/learn-you-a-flexbox-for-great-good">Learn you a Flexbox for Great Good!</a> door Stephen Hay</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/klaar-voor-de-mobiele-tsunami">Klaar voor de mobiele tsunami</a> door Peter-Paul Koch</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/geharnast-javascript">Geharnast JavaScript</a> door Tom Greuter</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/welkom-op-het-audiologische-internet">Welkom op het Audiologische Internet</a> door Peter Beverloo</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/deferred-en-promise-in-jquery">Deferred en promise in jQuery</a> door Edwin Martin</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/prototype-in-javascript">Prototype in JavaScript</a> door Peter van der Zee</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/scalable-vector-graphics-en-responsive-web">Scalable Vector Graphics en responsive web</a> door Jochen Vandendriessche</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/closure-tools">Closure Tools</a> door Johan Schuyt</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/dr-strangescope">Dr. Strangescope or: How I Learned to Stop Worrying and Love the Closure</a> door Arjan Eising</li>
<li><a href="https://www.fronteers.nl/blog/2011/12/door-een-frobelaar">Content management door de ogen van een vrolijke front-end fröbelaar</a> door Krijn Hoetmer</li>
</ol>
</content>
</entry>
<entry>
<title>Meld je aan voor de Algemene Ledenvergadering 2011</title>
<link href="https://www.fronteers.nl/nl/blog/2011/11/meld-je-aan-voor-de-algemene-ledenvergadering-2011"/>
<updated>2011-11-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/11/meld-je-aan-voor-de-algemene-ledenvergadering-2011</id>
<content xml:lang="nl" type="html"><p>Woensdag 7 december a.s. houden we onze jaarlijkse algemene ledenvergadering (ALV). De ALV vindt plaats in de op de 10e verdieping van de Regardztoren op Amsterdam C.S. (dit is het gebouw waar ook het Ibishotel in zit en waar de Fronteersmeeting bij Albumprinter plaatsvond). Het adres is Stationsplein 51-53 1012 AB Amsterdam. De zogeheten &quot;Zilveren Toren&quot; van Regardz zit pal naast Amsterdam Centraal Station. We beginnen om 19.00 uur en denken maximaal twee uur nodig te hebben.</p>
<p>De agenda is als volgt:</p>
<ol>
<li>Welkom en opening door de voorzitter</li>
<li>Toelichting commissies</li>
<li>Terugblik 2011</li>
<li>Ingebrachte beleidsvoorstellen</li>
<li>Begroting</li>
<li>Kascommissieverkiezing</li>
<li>Bestuursverkiezing</li>
<li>Rondvraag</li>
<li>Sluiting</li>
</ol>
<p>De commissievoorzitters (of hun vervangers) geven een korte toelichting op het gedane werk in het afgelopen jaar en ontvouwen hun toekomstplannen voor 2012. Natuurlijk staan zij ook open voor vragen. Verder treden (in lijn met de statuten) drie bestuursleden af: Peter-Paul Koch, Krijn Hoetmer en Sander van Lambalgen. Zij zijn allen herkiesbaar.</p>
<p>Het bestuur nodigt alle leden nadrukkelijk uit om vragen, ideeën of voorstellen in te dienen. De vereniging is van iedereen, en de koers bepalen we met zijn allen. Alles wat je kwijt wilt kun je melden via het <a href="https://www.fronteers.nl/nl/vereniging/contact/">contactformulier</a>. Duik eens in de <a href="https://www.fronteers.nl/vereniging/bestuur/notulen">notulen</a> voor inspiratie.</p>
<p><a href="https://www.fronteers.nl/vereniging/bestuur">Meld je zo gauw mogelijk aan voor de ALV</a>, zodat wij ons enigzins een beeld kunnen vormen van de verwachte toeloop. Je komst is niet voor niks. Ten eerste bepaal je mede de koers van Fronteers in 2012, ten tweede scoor je die exclusieve Fronteersgadget die niemand anders heeft (onder voorbehoud). Samen reizen met iemand? Neem even contact op met de ledenadministratie en we koppelen jullie aan elkaar.</p>
<p>Na afloop van de vergadering kunnen we op de 11e verdieping (met een indrukwekkend uitzicht over Amsterdam) tot 22.30 uur een biertje (en meer!) drinken.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 8 december, in Groningen</title>
<link href="https://www.fronteers.nl/nl/blog/2011/11/bijeenkomst-december-groningen"/>
<updated>2011-11-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/11/bijeenkomst-december-groningen</id>
<content xml:lang="nl" type="html"><p>Op donderdag 8 december is Fronteers te gast bij <a href="http://mediact.nl/">mediaCT</a> te Groningen. Vasilis van Gemert geeft een presentatie over Adaptive development, en Bas Rozema over Git.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 inloop</li>
<li>19.30 Vasilis van Gemert over Adaptive development</li>
<li>20.30 korte pauze</li>
<li>20.45 Bas Rozema over Git</li>
<li>21.45 borrelen</li>
</ul>
<h2>Adaptive development</h2>
<p>In deze presentatie behandelt <a href="http://vasilis.nl/">Vasilis van Gemert</a> van <a href="http://mirabeau.nl/">Mirabeau</a> aan de hand van praktijkvoorbeelden verschillende technieken die in te zetten zijn bij het bouwen van adaptive layouts. Denk hierbij aan termen als em-based layouts, media-queries, re-alignment best practices en client-side adaptive image-replacement. Met andere woorden: echt flexibele websites die zich aanpassen aan het apparaat waarmee gekeken wordt.</p>
<h2>Git</h2>
<p>Versiebeheer, bah. Iedereen moet er wat mee, en niemand heeft er zin in. Toch moet je als zelfrespecterende webbouwer zorgen dat je versiehistorie benaderbaar is, dat je weet wie, wat, waar, wanneer iets heeft gewijzigd en waarom. Als je in een team werkt, zijn de voordelen wel duidelijk, je kunt niet onder versiebeheer uit. Gelukkig is er Git: een high-performance, gedistribueerd, easy-to-use versiebeheersysteem. Hoera! Iedereen aan de Git! Maar ben je er dan? Hoe ga je bijvoorbeeld om met doorontwikkeling van een bestaand project? Hoe ga je om met releases. Hoe doe je bugfixes op een manier waarop je tegelijkertijd maximaal flexibel bent en alles overzichtelijk houdt? Hoe support je een oudere versie van dezelfde software? De hamvraag is dus eigenlijk: hoe richt je je versiebeheerproces in en hoe houd je dat nou beheersbaar?</p>
<h2>Bereikbaarheid en opgave</h2>
<p>MediaCT is gevestigd aan Zuiderpark 22, 9724 AH Groningen, circa vijf minuten lopen vanaf station Groningen. Er is ruimte om te parkeren in de buurt. Zoals gebruikelijk is deze bijeenkomst gratis bij te wonen door zowel leden als niet-leden van Fronteers.</p>
</content>
</entry>
<entry>
<title>Workshop HTML/CSS op 16 november</title>
<link href="https://www.fronteers.nl/nl/blog/2011/11/basiscursus-html-css"/>
<updated>2011-11-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/11/basiscursus-html-css</id>
<content xml:lang="nl" type="html"><p>Naast geavanceerde workshops over front-endtechnieken wil Fronteers ook workshops aanbieden aan mensen die minder ervaring hebben met front-end ontwikkeling of er slechts zijdelings mee te maken hebben, zoals content managers. 16 november aanstaande geeft de ervaren docent Frances de Waal een basis workshop over HTML en CSS.</p>
<p>Deze workshop is bedoeld voor mensen die al werken met HTML en CSS en basiskennis missen, maar ook voor mensen die er nog weinig van af weten en wel goed willen beginnen. Doel van de workshop is dat je in een text editor eenvoudige webpagina's kunt maken en vormgeven. Lees meer over deze cursus of meld je aan op de <a href="https://www.fronteers.nl/workshops/html-css-frances-de-waal">workshoppagina</a>.</p>
<p>Ben jij een ervaren front-end developer, maar ken jij mensen in je omgeving voor wie deze basiscursus raadzaam zou zijn? Schroom niet hem of haar op deze nieuwe Fronteerscursus te attenderen.</p>
<p>Voor de fans van statistieken: dit jaar hebben we in totaal <a href="https://www.fronteers.nl/nl/activiteiten">11 workshops</a> verzorgd, met 10 verschillende docenten. Hopelijk gaan we een paar van deze weer terug laten komen, maar als commissie zijn wel al ruim tevreden met het resultaat van dit jaar; we hadden zelf het idee om 4 tot 6 workshops te verzorgen.</p>
<p>In december zullen we even geen workshops aanbieden, maar vanaf januari gaan we weer aan de bak.</p>
</content>
</entry>
<entry>
<title>Vooraankondiging ALV</title>
<link href="https://www.fronteers.nl/nl/blog/2011/11/vooraankondiging-alv"/>
<updated>2011-11-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/11/vooraankondiging-alv</id>
<content xml:lang="nl" type="html"><p>Blok deze datum in je agenda! Woensdag 7 december vindt de jaarlijkse Algemene Ledenvergadering van Fronteers plaats, om 19 uur nabij station Amsterdam CS.</p>
<p>Leden bepalen mede de koers van Fronteers. Als lid van de vereniging heb je er recht op om te weten wat we het afgelopen jaar hebben gedaan en wat onze plannen zijn voor de toekomst. Kom daarom naar de Algemene Ledenvergadering (ALV) van Fronteers.</p>
<p>We zullen stilstaan bij de activiteiten van de commissies, de begroting en de gebruikelijke stoelendans van het bestuur. Het volledige programma volgt nog.</p>
<p>Om vast warm te draaien kun je je verdiepen in <a href="https://www.fronteers.nl/vereniging/bestuur/notulen/24-11-10">de notulen van vorig jaar</a>. Als je zaken aan de orde wilt stellen, voorstellen in wilt dienen of andere goede ideeën hebt, neem dan contact op met het bestuur, graag zelfs!</p>
<p>We willen rond 19.00 uur beginnen en verwachten maximaal twee uur nodig te hebben. Daarna is er natuurlijk tijd voor een webstandaardenbiertje!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 15 november, in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2011/10/bijeenkomst-booking-com"/>
<updated>2011-10-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/10/bijeenkomst-booking-com</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 15 november is Fronteers te gast bij <a href="http://booking.com/">Booking.com</a> in Amsterdam. Roy Tomeij zal spreken over Git voor front-enders, en Fabio Venni over webtypografie. Beide presentaties zullen in het Engels worden gegeven.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 inloop</li>
<li>19.25 introductie Booking.com</li>
<li>19.30 Roy Tomeij over Git</li>
<li>20.30 korte pauze</li>
<li>20.45 Fabio Venni over webtypografie</li>
<li>21.45 borrelen</li>
</ul>
<h2>Git voor front-enders, door Roy Tomeij</h2>
<p>Het is 2011 en je gebruikt geen versiebeheer? Dan is het hoog tijd om ermee te beginnen! Tijdens deze bijeenkomst legt Roy Tomeij uit waarom, hoe Git je leven een stuk makkelijker maakt en waarom GitHub zo goed werkt voor teams vanaf twee personen.</p>
<h2>On typography, by Fabio Venni</h2>
<p>A crash course on typography: the history, the theory, some techniques. A quick panorama of the factors that characterize a font and how they affect its aesthetics, style and readability. Understanding typographic color. Constrains that web typography have to consider. Sizing a font in CSS: creating a typographic scale. Web fonts and typography in the HTML5 era.</p>
<h2>Bereikbaarheid en opgave</h2>
<p>Booking.com is gevestigd aan Nieuwe Weteringstraat 36-38, 1017 SG te Amsterdam. De bijeenkomst is gratis bij te wonen voor zowel leden als niet-leden. Wel is gewenst dat je jezelf opgeeft via het <a href="https://www.fronteers.nl/bijeenkomsten/2011/booking-com">formulier op de bijeenkomstpagina</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 24 november in Mechelen</title>
<link href="https://www.fronteers.nl/nl/blog/2011/10/bijeenkomst-lessius"/>
<updated>2011-10-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/10/bijeenkomst-lessius</id>
<content xml:lang="nl" type="html"><p>Op donderdag 24 november 2011 is Fronteers te gast binnen de opleiding <a href="http://mechelen.lessius.eu/studeren-aan-de-khmechelen/bacheloropleidingen/informaticamanagement-en-multimedia/opleidingsparcours">Interactive Multimedia Design</a> bij Lessius Mechelen. Er worden twee presentaties voorzien. Eerst komt Thomas Byttebier praten over responsive webdesign; vervolgens zal <a href="http://wolfslittlestore.be/">Johan Ronsse</a> wat vertellen over design vanuit het oogpunt van een developer.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst — voor de hongerigen: er is een frituur vlakbij</li>
<li>19:00 Thomas Byttebier over <em>responsive webdesign</em></li>
<li>20:00 Johan Ronsse over <em>design voor web developers</em></li>
<li>21:00 naborrelen (drank wordt voorzien)</li>
</ul>
<h2>Routebeschrijving</h2>
<p>Lessius Mechelen is gevestigd aan Zandpoortvest 60, 2800 Mechelen. Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2011/lessius">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Mobilism 2012: Fronteers kaarten</title>
<link href="https://www.fronteers.nl/nl/blog/2011/10/mobilism-2012-fronteers-kaarten"/>
<updated>2011-10-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/10/mobilism-2012-fronteers-kaarten</id>
<content xml:lang="nl" type="html"><p>Op 10 en 11 mei 2012 zal te Amsterdam <a href="http://mobilism.nl/2012">Mobilism 2012</a> plaatsvinden, dat geheel gewijd zal zijn aan mobiele webontwikkeling. Een mooie en zich nog altijd ontwikkelende <a href="http://mobilism.nl/2012/programme">sprekerslijst</a> staat garant voor een topcongres.</p>
<p>Aangezien twee van de drie organisatoren Fronteers-bestuursleden zijn, hebben we voor Fronteers-leden die op dit moment lid zijn 15 kaarten gereserveerd voor 400 euro ex. BTW. Op dit moment zijn er nog <a href="https://mobilism.paydro.net/">kaartjes</a> voor diezelfde prijs beschikbaar, maar dat zal snel afgelopen zijn. Vanaf dat moment is dit het beste aanbod dat je zult vinden.</p>
<p>Als je een kaartje wilt bestellen en Fronteers lid bent, kun je een kortingscode opvragen middels een mailtje naar <a href="mailto:krijn@fronteers.nl">krijn@fronteers.nl</a>.</p>
<p>We hopen minstens 15 Fronteers leden te kunnen begroeten op 10 en 11 mei.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 26 oktober, in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2011/10/bijeenkomst-oktober"/>
<updated>2011-10-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/10/bijeenkomst-oktober</id>
<content xml:lang="nl" type="html"><p>Op woensdag 26 oktober is Fronteers te gast bij <a href="http://albumprinter.org/">Albumprinter</a>, gevestigd dichtbij Amsterdam Centraal Station. Er zijn twee sprekers: Bram Duvigneau geeft een presentatie over webtoegankelijkheid, en Arjan Eising vertelt over de huidige en toekomstige staat van CSS Selectors.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 inloop</li>
<li>19.20 korte introductie van Albumprinter</li>
<li>19.30 Bram Duvigneau over webtoegankelijkheid</li>
<li>20.30 korte pauze</li>
<li>20.45 Arjan Eising over CSS Selectors</li>
<li>21.45 borrelen</li>
</ul>
<h2>CSS Selectors, door Arjan Eising</h2>
<p>CSS Selectors, de stille kracht achter elke stylesheet. Met de komst van CSS Selectors level 3, en de browsers die het tegenwoordig allemaal ondersteunen, zijn we met enkele slimme selectors in staat 'krachtige' stijlen toe te passen. Daar komt nu een nieuwe set bij: CSS Selectors level 4, waarin vele handige selectors worden toegevoegd. <a href="http://arjaneising.nl/">Arjan Eising</a> licht alles hierover toe in deze presentatie.</p>
<h2>Routebeschrijving</h2>
<p>Albumprinter is gevestigd aan Stationsplein 53 - 57, 1012 AB Amsterdam.</p>
<p>Zoals gebruikelijk is deze bijeenkomst gratis toegankelijk voor zowel ledfen als niet-leden van Fronteers. Wel is gewenst dat je jezelf opgeeft via het <a href="https://www.fronteers.nl/bijeenkomsten/2011/albumprinter">formulier op de bijeenkomstpagina</a>.</p>
</content>
</entry>
<entry>
<title>Fronteers 2011: Awesome!</title>
<link href="https://www.fronteers.nl/nl/blog/2011/10/fronteers-2011-awesome"/>
<updated>2011-10-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/10/fronteers-2011-awesome</id>
<content xml:lang="nl" type="html"><p>Er is al een <a href="http://twitter.com/search/%23fronteers11%20OR%20FronteersConf">hoop over geschreven op Twitter</a>, maar <a href="https://www.fronteers.nl/congres/2011">Fronteers 2011</a> was weer een succes. In totaal hebben <a href="https://www.fronteers.nl/congres/2011/attendees">500 bezoekers</a> genoten van <a href="https://www.fronteers.nl/congres/2011/sessions">14 presentaties</a> van <a href="https://www.fronteers.nl/congres/2011/speakers">14 gepassioneerde sprekers</a>. Wat een sfeer dit jaar, wow! Onze dank gaat uit naar alle vrijwilligers en sprekers die hier aan hebben meegeholpen. Hieronder een overzichtje met links naar (bijna) alle presentaties. In de komende dagen/weken zullen ook alle video's online komen.</p>
<ul>
<li>Aral Balkan, The Future is Native</li>
<li>Derek Featherstone, Accessibility for the Modern Web</li>
<li>Lea Verou, <a href="http://leaverou.me/css3-secrets/#intro">CSS3 Secrets: 10 things you might not know about CSS3</a>, <a href="http://www.slideshare.net/LeaVerou/css3-secrets-10-things-you-might-not-know-about-css3">Slideshare</a>, <a href="http://speakerdeck.com/u/leaverou/p/css3-secrets-10-things-you-might-not-know-about-css3">Speaker Deck</a></li>
<li>Bruce Lawson, <a href="http://www.slideshare.net/brucelawson/you-too-can-be-a-bedwetting-antfucker-bruce-lawson-opera-fronteers-2011">HTML5 Semantics: you too can be a bedwetting antfucker</a></li>
<li>Stephen Hay, <a href="http://www.slideshare.net/stephenhay/go-with-the-flow-9595283">Go with the flow
</a></li>
<li>Tab Atkins, <a href="http://www.xanthir.com/talks/2011-10-06/">The Future of CSS - Current Experiments and Near-Future Reality
</a></li>
<li>Leslie Jensen-Inman, <a href="http://speakerdeck.com/u/jenseninman/p/passion-purpose-promise-pursuit">Passion. Purpose. Promise. Pursuit.</a></li>
<li>Alex Russell, <a href="http://infrequently.org/11/fronteers/fronteers.html">Data, Semantics, &amp; The Process of Progress slides</a>, <a href="http://infrequently.org/11/fowa/demos/shadow-dom-demo/">code examples</a></li>
<li>Divya Manian, <a href="http://nimbu.in/fronteers/#intro">The New Developer Workflow
</a>,
<a href="https://github.com/nimbupani/compass-demos">Compass demo</a>, <a href="https://github.com/robbyrussell/oh-my-zsh">
Terminal skin</a></li>
<li>Robert Nyman, <a href="http://www.slideshare.net/robnyman/html5-forms-kiss-time-fronteers">HTML5 Forms - KISS time
</a>, <a href="http://speakerdeck.com/u/robnyman/p/html5-forms-kiss-time-fronteers">Speaker Deck</a></li>
<li>Seb Lee-Delisle, CreativeJS - beauty in the browser, <a href="https://github.com/sebleedelisle/JavaScript-PixelPounding-demos">code examples</a></li>
<li>John Resig, jQuery and the Open Source Process</li>
<li>Jake Archibald, <a href="http://speakerdeck.com/u/jaffathecake/p/in-your-font-face">In your <code>@font-face
</code></a></li>
<li>Christian Heilmann, <a href="http://www.slideshare.net/cheilmann/the-prestige-of-being-a-web-developer">The prestige of being a web developer</a>, <a href="http://www.slideshare.net/cheilmann/the-prestige-of-being-a-web-developer-no-notes">zonder notes</a></li>
</ul>
<p>(Dank aan Darius Kruythoff voor het maken van deze lijst)</p>
<p>Een <a href="http://vimeo.com/30617937">compilatievideo van het congres</a> is te vinden op Vimeo. Binnenkort volgen ook alle sessies online!</p>
<p>Wat vond jij bijzonder goed of bedroevend slecht gaan? Laat het ons weten via Twitter (#fronteers11), onderstaande reacties of <a href="http://forum.fronteers.nl/topic/23/fronteers11/">het forum</a>.</p>
<p>Tot volgend jaar!</p>
</content>
</entry>
<entry>
<title>WCAG 2.0 : Betekenisvolle volgorde</title>
<link href="https://www.fronteers.nl/nl/blog/2011/09/wcag-2-0-betekenisvolle-volgorde"/>
<updated>2011-09-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/09/wcag-2-0-betekenisvolle-volgorde</id>
<content xml:lang="nl" type="html"><p>Van volgorde van belangrijkheid naar betekenisvolle volgorde.</p>
<p>In Webrichtlijnen 1 is er de omstreden richtlijn <em>Zet de inhoud van de pagina in de HTML broncode op volgorde van belangrijkheid</em> (R-pd.6.2). Hier is veel over gediscussieerd, o.a. <a href="https://www.fronteers.nl/blog/2008/05/webrichtlijnen-volgorde-van-belangrijkheid">hier op site</a>.</p>
<p>In Webrichtlijnen 2/WCAG2.0 is er <a href="http://versie2.webrichtlijnen.nl/documentatie/1.3.2/">Successcriterium 1.3.2</a>: <em>Betekenisvolle volgorde: Als de volgorde waarin content wordt gepresenteerd van invloed is op zijn betekenis, kan een betekenisvolle leesvolgorde door software bepaald worden.</em></p>
<p>Dit is flexibeler, omdat er niet meer voorgeschreven wordt wat (als er overeenstemming is over wat het belangrijkst is) boven of verder naar beneden in de html-structuur moet staan. Er is alleen de voorwaarde dat de onderdelen die door een user agent door elkaar gegooid kunnen worden, de betekenis niet veranderen. Duidelijk, toch?</p>
<p>[Update 09-10-2011:]
Dus als je met css een visuele volgorde creëert, en die verandert wanneer je de site leest met een screenreader (zonder css), of je ziet alleen bepaalde content van die pagina terug in bijvoorbeeld een news-feed, dan moet het nog steeds begrijpelijk zijn.</p>
<p>Op het Fronteers congres afgelopen week was er in de presentatie van <a href="http://www.brucelawson.co.uk/">Bruce Lawson</a> een mooi voorbeeld van waar dit mis kan gaan <em>binnen een tekst</em>, namelijk als een deel van de tekst een andere richting heeft en dit niet in de mark-up wordt aangegeven. In HTML5 is daar nu het <bdi> element voor. Zie <a href="http://rishida.net/blog/?p=564,%20follow%20@r12a">deze use case</a>. WCAG2.0 adviseert hiervoor het gebruik van Unicode right-to-left marks, maar dit schijnt nog wel eens problemen te geven in zoekopdrachten.</bdi></p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 15 september, in Rotterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2011/09/bijeenkomst-september-lunatech"/>
<updated>2011-09-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/09/bijeenkomst-september-lunatech</id>
<content xml:lang="nl" type="html"><p>Op donderdag 15 september is Fronteers te gast bij <a href="http://www.lunatech-research.com/">Lunatech Research</a> in Rotterdam. Egor Kloos vertelt over enterprise front-end code, en Jeroen Wijering gaat ons een update geven van de huidige stand van zaken op het gebied van web video.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.00 inloop</li>
<li>19.00 Egor Kloos over enterprise front-end code</li>
<li>20.00 korte pauze</li>
<li>20.15 Jeroen Wijering over de huidige stand van zaken m.b.t. web video</li>
<li>21.15 borrelen</li>
</ul>
<p><a href="http://dutchcelt.nl/">Egor Kloos</a> is een ontwerper bij <a href="http://www.lunatech-research.nl/">Lunatech Research</a> en helpt met het maken van web applicaties voor zowel consumenten als voor de zakelijke markt (Enterprise). User Experience en een multi platform Web zijn hierbij belangrijke uitgangspunten. In deze Rotterdamse editie van Fronteers gaat hij het o.a. hebben over Enterprise &amp; Front-end. De perceptie is dat de ‘Enterprise’ over het integreren van services gaat en daarom niets te maken heeft met de front-end. &quot;Dat regelt de framework (JSF, ASP.NET etc.) toch?&quot;. De opkomst van UX wordt door deze IT bedrijven als vervelend gezien omdat zij nu wel iets met de front-end moeten. Het blijkt een kwestie van een aantal zaken er bij leren en vooral een aantal zaken afleren.</p>
<p>Jeroen Wijering is de ontwikkelaar achter de succesvolle JW Player, die wordt gebruikt op miljoenen websites wereldwijd (zie <a href="http://whoisjw.tv/">whoisjw.tv</a>). In deze presentatie behandelt hij de opkomst van HTML5 voor online video, de huidige stand van zaken en de voor- en nadelen ten opzichte van Flash. Ook het uitserveren van video naar mobiel (Android, iPad, iPhone) komt aan bod: wat werkt wel en niet op welk apparaat en waar moet de ontwikkelaar in het algemeen rekening mee houden.</p>
<h2>Routebeschrijving</h2>
<p>Lunatech Research is gevestigd aan Heemraadssingel 70, 3021 DD Rotterdam. Er is een <a href="http://www.lunatech-research.nl/contact">plattegrond beschikbaar op hun website</a>.</p>
<p>Zoals gebruikelijk is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden van Fronteers. Wel is het gewenst dat je jezelf opgeeft via het <a href="https://www.fronteers.nl/bijeenkomsten/2011/lunatech-research">formulier op de bijeenkomstpagina</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 22 september in Brussel</title>
<link href="https://www.fronteers.nl/nl/blog/2011/08/bijeenkomst-namahn"/>
<updated>2011-08-31T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/08/bijeenkomst-namahn</id>
<content xml:lang="nl" type="html"><p>Op 22 september organiseren we voor de vijfde keer een Fronteers-bijeenkomst in België. Na een <a href="https://www.fronteers.nl/bijeenkomsten/2011/aspace">succesvolle editie in Antwerpen</a>, is ons oog nu gevallen op de prachtige ‘Open Space’ van Namahn in Brussel. Hier kunnen we maar liefst 45 deelnemers verwelkomen.</p>
<p>Deze editie staat helemaal in het teken van CSS. <a href="http://lensco.be/">Lennart Schoors</a> is onze eerste spreker. Hij <strike>is</strike> <strong>was tot voor kort</strong> Lead Web Designer bij <a href="http://www.netlog.com/">Netlog</a> en is nu freelancer. Zijn presentatie is getiteld ‘Look ma! No images!’. Daarna komt <a href="http://bdc.vc/">Benjamin De Cock</a> spreken over CSS Animations. Benjamin is een interface-designer met een oog voor detail waar velen jaloers op zijn.</p>
<p>Opgelet: zowel Benjamin — die Franstalig is — als Lennart zullen in het Engels presenteren.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00: Ontvangst met drank en broodjes</li>
<li>19:00: Lennart Schoors: ‘Look ma, no images!’</li>
<li>19:45: Pauze</li>
<li>20:15: Benjamin De Cock: ‘CSS Animations’</li>
<li>21:00: Naborrelen met een drankje, gesponsord door <a href="http://www.bloovi.be/">Bloovi</a> (Vacaturewebsite van en voor internetspecialisten)</li>
</ul>
<h2>Routebeschrijving</h2>
<p>Namahn is gevestigd aan de Grensstraat 21 te 1210 Brussel. Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2011/namahn">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 45 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Workshops update augustus</title>
<link href="https://www.fronteers.nl/nl/blog/2011/08/cursussen-update-augustus"/>
<updated>2011-08-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/08/cursussen-update-augustus</id>
<content xml:lang="nl" type="html"><p>Na bijna twee maanden zonder workshops is het weer tijd voor een update en er is genoeg te melden. Als ik zeg zonder workshops dan bedoel ik eigenlijk zonder workshops in Nederland, want op 19 augustus heeft Jan Moesen in België de eerste Vlaamse Fronteers workshop gegeven. Het onderwerp was misschien op het eerste gezicht voor front-end ontwikkelaars wat minder toegankelijk, maar de workshop was desondanks een succes. Tussen de droge Vlaamse humor door hebben de aanwezigen waaronder ondergetekende een boel opgestoken.</p>
<p>Vandaag, 30 augustus, geeft Jeroen Visser zijn workshop <a href="https://www.fronteers.nl/workshops/counter-space-jeroen-visser">Counter Space</a> over web typografie. Mocht je hier aan deel hebben willen nemen maar is het je ontgaan dat hij gegeven werd, laat ons dan alsjeblieft weten hoe we je hadden kunnen bereiken. Workshops worden over het algemeen als eerste via het Twitter account van Fronteers <a href="https://twitter.com/fronteers">@fronteers</a> aangekondigd. Daarnaast kun je <a href="https://www.fronteers.nl/nl/activiteiten">fronteers.nl/workshops</a> in de gaten houden, je abonneren op de workshops newsfeed (onderaan die pagina) en het blog bijhouden.</p>
<p>Over alweer twee weken, op 13 september, zal Arjan Eising een workshop <a href="https://www.fronteers.nl/workshops/jquery-inception-arjan-eising">jQuery Inception</a> geven. Hardcore JavaScripters zullen hier waarschijnlijk niet veel bij kunnen leren maar als je wilt beginnen met JavaScript of jQuery beter onder de knie wilt krijgen dan is deze workshop een aanrader. Inschrijven kan <a href="https://www.fronteers.nl/workshops/jquery-inception-arjan-eising">onderaan de pagina</a>.</p>
<p>Een weekje later, op 20 september zal Stephen Hay een workshop geven over prototyping genaamd Rabid Prototyping. Trek je van de naam niet zo heel veel aan, inentingen tegen hondsdolheid zullen niet nodig zijn. De focus van deze workshop ligt met name op snel prototypen met JavaScript en template layout. Bekijk <a href="https://www.fronteers.nl/workshops/rabid-prototyping-stephen-hay">de workshop pagina</a> voor meer informatie.</p>
<p>Tot slot hebben we geconstateerd dat de aanmeldingen voor cursussen wat terug lijken te lopen. In eerste instantie wijten we dit met name aan de rustige vakantieperiode. Het is echter ook goed mogelijk dat er een andere reden voor is. Misschien dat de doelgroep wat verzadigd begint te raken of is er behoefte aan andere onderwerpen. Mocht je hier ideeën, op- en/of aanmerkingen over hebben, aarzel dan alsjeblieft niet hieronder een reactie achter te laten.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst 25 augustus op andere locatie</title>
<link href="https://www.fronteers.nl/nl/blog/2011/08/bijeenkomst-andere-locatie"/>
<updated>2011-08-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/08/bijeenkomst-andere-locatie</id>
<content xml:lang="nl" type="html"><p>De Fronteers bijeenkomst die morgen, 25 augustus, bij <a href="http://travelgroep.nl/">Travelgroep</a> gehouden zou gaan worden, vindt plaats bij het kantoor van <a href="http://springest.nl/">Springest</a> aan het Rokin in Amsterdam. Dit wegens het niet beschikbaar zijn van de locatie van Travelgroep. De sprekers blijven ongewijzigd: Reinier Linthorst Homan praat over zoekmachineoptimalisatie, en Ruslan Matveev zal een Engelstalig praatje houden over het door hem gebouwde jPath.</p>
<p>Meer informatie is beschikbaar op de <a href="https://www.fronteers.nl/bijeenkomsten/2011/travelgroep">detailpagina</a>, waar je jezelf ook op kunt geven. Springest is gevestigd aan Rokin 75, 1012 KL Amsterdam. De bijeenkomst wordt gehouden op de zesde verdieping. Tot morgen!</p>
</content>
</entry>
<entry>
<title>Nu online: de Fronteers webshop</title>
<link href="https://www.fronteers.nl/nl/blog/2011/08/fronteers-webshop"/>
<updated>2011-08-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/08/fronteers-webshop</id>
<content xml:lang="nl" type="html"><p>De <a href="http://fronteers.spreadshirt.nl/">webshop</a> van Fronteers is vorige week online gegaan, met onder andere Fronteers-branded t-shirts, laptophoezen en—must-have voor de echte webstandaardenliefhebbers—een <a href="http://www.zeldman.com/2010/11/28/dont-forget-blue-beanie-day/">Blue Beanie</a>.</p>
<p>De shop wordt gehost en gerund door Spreadshirt: zij drukken en distribueren de producten. Voor vragen over producten en levering kun je dus terecht bij hun klantenservice.</p>
<p>Niet genoeg keuze? Ideeën voor nieuwe ontwerpen of teksten zijn altijd welkom, en kunnen worden gestuurd naar marketing@fronteers.nl. Ook verzoekjes voor andere producten zijn welkom op dit adres en zullen door de marketingcommissie serieus worden overwogen. Het is de bedoeling dat we in de toekomst nieuwe Fronteers-producten aan de shop blijven toevoegen.</p>
<p>Voor alle producten willen we regelmatig nieuwe ontwerpen blijven toevoegen, en daarmee zullen de oude ontwerpen weer verdwijnen. Wacht dus niet te lang en bestel snel.</p>
<p><em>Update:</em> <a href="https://twitter.com/eising/status/105219979581997056">Enkele</a> <a href="https://twitter.com/hedwygNL/status/104527705491513344">leden</a> <a href="https://twitter.com/rowdyrabouw/status/104212896501858304">hebben</a> hun shirts binnen.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 25 augustus, in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2011/08/bijeenkomst-augustus"/>
<updated>2011-08-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/08/bijeenkomst-augustus</id>
<content xml:lang="nl" type="html"><p>Op donderdag 25 augustus is Fronteers welkom bij <a href="http://travelgroep.nl/">Travelgroep</a> in Amsterdam. Reinier Linthorst Homan vertelt over zoekmachineoptimalisatie, en Ruslan Matveev zal een Engelstalig praatje houden over het door hem gebouwde jPath.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 inloop</li>
<li>19.30 Reinier over zoekmachine optimalisatie</li>
<li>20.30 korte pauze</li>
<li>20.45 Ruslan over jPath</li>
<li>21.45 borrelen</li>
</ul>
<h2>Zoekmachineoptimalisatie</h2>
<p>Google is een machtige speler op het internet. Met diverse technieken probeert het boven Facebook en Bing te blijven. Toch zijn resultaten die de zoekmachine teruggeeft gedateerd. Reinier, oprichter van Travelgroep, vertelt hoe Google de komende tijd de baas blijft.</p>
<h2>Building native cross - platform applications with JavaScript and jPath.</h2>
<p>[Talk in English] jPath is a platform for developing cross - platform native applications using JavaScript and HTML that is based on WebKit and jQuery and allows you to develop native applications that runs under Windows, MacOSX and Linux using HTML, JavaScript and CSS.</p>
<h2>Bereikbaarheid en opgave</h2>
<p>--Het is nog enigszins onduidelijk waar de bijeenkomst plaats gaat vinden, omdat Travelgroep gaat verhuizen. Momenteel is het gevestigd aan de Keizersgracht 630, 1017 ER Amsterdam. Mocht de lokatie gewijzigd zijn, dan zal dat op deze pagina aangekondigd worden.-- Update: de bijeenkomst vindt plaats bij Springest, gevestigd aan Rokin 75, 1012 KL Amsterdam op de zesde verdieping.</p>
<p>Zoals gebruikelijk is de bijeenkomst gratis toegankelijk voor zowel leden als niet-leden.</p>
</content>
</entry>
<entry>
<title>WCAG 2.0: Blokken omzeilen met of zonder skip links</title>
<link href="https://www.fronteers.nl/nl/blog/2011/07/wcag-2-0-blokken-omzeilen"/>
<updated>2011-07-31T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/07/wcag-2-0-blokken-omzeilen</id>
<content xml:lang="nl" type="html"><p>Ze staan er nog steeds in, de skip links, bovenaan bij de afdoende technieken voor het WCAG2.0 succescriterium 2.4.1. Blokken omzeilen: Er is een mechanisme beschikbaar om blokken content die op meerdere webpagina's worden herhaald te omzeilen. (Niveau A). Is het echt nog nodig met al onze semantische markup en html5 om hiervoor nog extra markup toe te voegen?</p>
<p><a href="http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skip">Hoe te voldoen aan succescriterium 2.4.1</a></p>
<p>Ik had de hoop dat met het gebruik van html5-elementen zoals <code>nav</code> en <code>section</code> of <code>article</code> en aria roles zoals <code>navigation</code> en <code>main</code> die skip links wel een keer overbodig zouden worden. Helaas ondersteunen screen readers – in combinatie met browsers – deze elementen en roles nog slecht, zoals in <a href="http://www.accessibleculture.org/research/html5-aria-2011/">dit artikel</a> wordt beschreven.</p>
<p>Gelukkig kun je het ook oplossen met headings. En een goede headingstructuur maak je sowieso, dus dan ben je meteen klaar, toch? Screenreader gebruikers kunnen dan een lijst met links gemakkelijk overslaan. Maar bezoekers die visueel navigeren via de tab toets moeten dan nog wel alle links bij langs. Toch weer skip links dus...?</p>
<p>En hoe zit dat eigenlijk met het <a href="http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/H50">map element</a> voor het groeperen voor links? Gebruikt iemand dat wel eens?</p>
</content>
</entry>
<entry>
<title>Workshop Terminally Chill op 19 augustus</title>
<link href="https://www.fronteers.nl/nl/blog/2011/07/cursus-terminally-chill"/>
<updated>2011-07-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/07/cursus-terminally-chill</id>
<content xml:lang="nl" type="html"><p>Twee jaar geleden organiseerde Fronteers voor het eerst een cursus voor front-end developers in Nederland. De workshops duren meestal een hele dag en zijn van een hoog niveau. Nu Fronteers — mede dankzij de gesmaakte <a href="http://fronteers.nl/bijeenkomsten">bijeenkomsten</a> van de voorbije maanden — ook in Vlaanderen voet aan de grond krijgt, vonden we het tijd voor een eerste cursus op Vlaams grondgebied.</p>
<p><a href="http://jan.moesen.nu/">Jan Moesen</a> — hij gaf eerder al een gesmaakte <a href="https://www.fronteers.nl/bijeenkomsten/2011/phl">presentatie</a> over dit onderwerp — bijt de spits af: op 19 augustus leert hij je in Gent alles wat je moet weten over de terminal. Je zal versteld staan van de voordelen, de tijdswinst en de vele handigheidjes die de terminal voor front-end developers te bieden heeft.</p>
<p>Ben je het beu om altijd weer dezelfde stappen te moeten uitvoeren om je website live te zetten, met het risico om fouten te maken? Doe je elke morgen afstompende computertaken waarbij je wel voelt dat het beter kan, maar niet weet hoe? Of ben je simpelweg op zoek naar wat geekkrediet door je superdeluxe HD-scherm als een veredelde teletekst te gebruiken? <a href="https://www.fronteers.nl/blog/2011/07/cursus-terminally-chill#reageer">Laat dan weten waar je mee worstelt</a>, en we pakken het samen aan tijdens de workshop.</p>
<h2>Praktisch</h2>
<h2>Prijs</h2>
<p>We hebben de inschrijvingsprijs, bij wijze van kennismaking, zeer democratisch weten te houden: Fronteers-leden betalen voor deze eerste cursus in Vlaanderen slechts <em>50 euro</em>. Niet-leden betalen <em>100 euro</em>. De prijzen zijn exclusief 19% btw.</p>
<h2>Deelnemers</h2>
<p>Om de cursus zo interactief mogelijk te kunnen maken, hebben we beslist om het aantal plaatsen tot 12 te beperken. De cursus gaat ook enkel door als we al deze plaatsen hebben kunnen invullen.</p>
<h2>Locatie en lunch</h2>
<p>De cursus vindt plaats in de Campus Schoonmeersen van de Hogeschool Gent in lokaal D1.02. Het adres is Schoonmeersstraat 52, 9000 Gent. ’s Middags voorzien we een broodjeslunch en die is uiteraard in de prijs begrepen.</p>
<h2>Breng je computer mee</h2>
<p>Ten slotte vragen we dat alle deelnemers een eigen computer meebrengen. Toegang tot een Unix-shell (dit is standaard het geval op Mac OS X of Linux) is uiteraard een must.</p>
<h2>Interesse?</h2>
<p>Laat deze kans niet liggen en <a href="https://www.fronteers.nl/workshops/terminally-chill-jan-moesen">schrijf je snel in voor deze workshop</a>.</p>
</content>
</entry>
<entry>
<title>Workshops update juli</title>
<link href="https://www.fronteers.nl/nl/blog/2011/07/cursussen-update-juli"/>
<updated>2011-07-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/07/cursussen-update-juli</id>
<content xml:lang="nl" type="html"><p>Ook voor juli even een korte cursussen update. De laatste cursus die gegeven is, is <a href="https://www.fronteers.nl/workshops/inclusive-design-jeroen-hulscher">'Inclusive Design'</a> door Jeroen Hulscher. We vermoeden dat de zomervakantie ons wat parten heeft gespeeld en dat de opkomst daardoor wat magertjes leek, maar dankzij wat last minute marketing hebben we hem toch door kunnen laten gaan. Uit de evaluatie is gebleken dat ook deze cursus een succes was!</p>
<p>Zoals in <a href="https://www.fronteers.nl/blog/2011/06/cursussen-update-juni">de vorige</a> workshops update al aangekondigd werd, zat er een workshop over 'iets met typografie' in de pijplijn. Gisteren is hij dan aangekondigd. Jeroen Visser gaat zijn workshop over (web)typografie, genaamd <a href="https://www.fronteers.nl/workshops/counter-space-jeroen-visser">'Counter Space'</a>, geven op 30 augustus.</p>
<p>Zonder al te veel van de cursus te verklappen willen we toch graag een tipje van de sluier oplichten.</p>
<p>In de ochtend zal de focus met name liggen op de theorie. Denk hierbij aan de geschiedenis, basisbegrippen en verschillen tussen web en print maar ook aan design gerelateerde zaken als layout en tekstopmaak.</p>
<p>Tijdens het middagprogramma zullen met name webtechnieken aan bod komen. Denk hierbij aan de css toolkit, typische webelementen, berperkingen van browsers, renderverschillen en natuurlijk webfonts.</p>
<p>Inschrijven kan door het <a href="https://www.fronteers.nl/workshops/counter-space-jeroen-visser">formulier</a> in te vullen. Wees er snel bij want we verwachten dat ook deze workshop snel vol zal zitten. Leden betalen nog steeds €100 en niet-leden €200 (beide bedragen exclusief btw).</p>
</content>
</entry>
<entry>
<title>Congresnieuws: Workshops en einde early bird</title>
<link href="https://www.fronteers.nl/nl/blog/2011/06/congres-workshops-einde-early-bird"/>
<updated>2011-06-29T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/06/congres-workshops-einde-early-bird</id>
<content xml:lang="nl" type="html"><p>Ook dit jaar organiseert Fronteers weer <a href="http://fronteers.nl/congres/2011/workshops">workshops</a> in aanloop naar het Fronteers Congres en ook dit jaar gaat het weer om intensieve workshops van een hele dag van hoog internationaal niveau. <a href="http://fronteers.nl/blog/2011/06/congres-workshops-einde-early-bird#real-world-accessibility">Derek Featherstone</a> komt een workshop over toegankelijkheid geven en <a href="http://fronteers.nl/blog/2011/06/congres-workshops-einde-early-bird#css3-for-web-developers">Lea Verou</a> een over CSS3. En een last call voor Fronteers leden: <a href="http://fronteers.nl/blog/2011/06/congres-workshops-einde-early-bird#einde-early-bird">de early bird periode voor het congres loopt af</a>!</p>
<h2>Real World Accessibility for HTML5, CSS and ARIA</h2>
<p>Op <a href="https://www.fronteers.nl/congres/2011/workshops/real-world-accessibility-derek-featherstone">dinsdag 4 oktober</a> komt Derek Featherstone, keizer van toegankelijkheid, ons uitleggen hoe je er voor kunt zorgen dat hedendaagse complexe webpagina's toegankelijk blijven voor iedereen, ongeacht het apparaat wat hij of zij gebruikt. Belangrijke kennis die elke webdeveloper vandaag de dag in zijn portfolio moet hebben:</p>
<blockquote>
<p>You need to know what HTML5, CSS3 and ARIA can do for you, how to use them accessibly AND how reliable they are… You need to know the nitty-gritty, get your hands dirty, practical side of accessibility for all of these technologies… You’ll be better prepared to deliver accessible solutions now and in the future.</p>
</blockquote>
<h2>CSS3 for Web Developers</h2>
<p>Voor mensen die alles over hedendaagse CSS willen weten: Lea Verou, de godin van stylesheets, komt ons op <a href="https://www.fronteers.nl/congres/2011/workshops/css3-for-web-developers-lea-verou">woensdag 5 oktober</a> inweiden in de hogere kunst van CSS3. In haar workshop &quot;CSS for developers&quot; gaat ze niet alleen in op de bling bling van CSS3, ze zal zich voornamelijk richten op de toepassing ervan in complexe webapplicaties. Een absolute must visit voor elke serieuze webdeveloper! In haar eigen woorden:</p>
<blockquote>
<p>CSS3, in essence, is about creating web applications that download faster and are easier to develop, maintain and edit. Less HTTP requests, less Kilobytes to download, less presentational JavaScript. And all those are mostly developer goals, rather than designer goals. And that's why developers should care about CSS3, perhaps even more than designers do.</p>
</blockquote>
<p>Beide workshops duren een hele dag, ze worden gegeven in het centrum van Amsterdam en de voertaal zal Engels zijn. Om er voor te zorgen dat de workshops persoonlijk blijven is er voor gekozen om maximaal 30 mensen toe te laten, wees er dus snel bij! Uiteraard is er een aangename korting voor Fronteersleden (die voor 29 juni 2011 lid waren of zijn geworden).</p>
<h2>Einde early bird voor het congres</h2>
<p>De early bird periode voor niet-leden was inmiddels voorbij, morgen is het ook voor Fronteers leden de laatste kans om <a href="https://www.fronteers.nl/congres/2011/tickets">een kaartje</a> met extraveel korting te kopen, vanaf 1 juli stijgt de prijs van een kaartje voor Fronteers leden met 100 Euro naar € 300,00.</p>
</content>
</entry>
<entry>
<title>WCAG 2.0 : Datatabellen</title>
<link href="https://www.fronteers.nl/nl/blog/2011/06/wcag2-0-datatabellen"/>
<updated>2011-06-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/06/wcag2-0-datatabellen</id>
<content xml:lang="nl" type="html"><p>Volgens de Accessibility Monitor 2011 heeft 69% van de gemeenten toegankelijkheidsproblemen met datatabellen. Wat is er toch zo moeilijk aan het toegankelijk maken daarvan?</p>
<p>Zie ook <a href="http://www.accessibilitymonitor.nl/monitor/2011/per-ijkpunt">Accessibility Monitor 2011</a></p>
<p>Een summary en een caption zijn zo toegevoegd en rij en kolom headers (th) ook.<br />
Pas bij complexere tabellen wordt het meer werk omdat je dan volgens <a href="http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/H63">WCAG2.0, richtlijn 1.3.1</a> scope attributen en/of headers attributen en id's toe moet voegen. Om precies te zijn: bij twee of meer logische niveaus van rij- of kolomheaders.</p>
<p>Wat is jullie ervaring hiermee?</p>
<p>En zou het eigenlijk niet ook aan te raden zijn voor niet-complexe tabellen (minder dan twee rij- of kolomheaders) om ook de verbanden tussen de cellen duidelijk aan te geven met scope en/of headers?</p>
</content>
</entry>
<entry>
<title>Uxebu geeft een workshop over HTML5, CSS3, JavaScript en Web Apps</title>
<link href="https://www.fronteers.nl/nl/blog/2011/06/html5-css3-javascript-web-apps"/>
<updated>2011-06-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/06/html5-css3-javascript-web-apps</id>
<content xml:lang="nl" type="html"><p>Uxebu wil graag haar kennis met jou delen! Wil je graag (mobiele) apps bouwen? HTML5, Chrome Web Store, WebOS, etc? Dan is nu je kans! Op 11-12 juli geeft Uxebu een workshop in Amsterdam om je kennis op te schroeven. Uxebu zal een workshop van hoog niveau neerzetten en je de fijne kneepjes van het vak bijbrengen. Ze zullen je alles leren over JavaScript en het schrijven van mobiele apps en je laten zien wat de browser tegenwoordig allemaal kan.</p>
<p>Deze workshop wordt gegeven door het bedrijf met hackers die aan open source projecten hebben bijgedragen als Gordon, TouchScroll, EmbedJS, StorageJS en vele andere.</p>
<h2>Inhoud</h2>
<p>De workshop zal twee dagen duren. In de ochtenden wordt er intensief gewerkt aan de JavaScript kennis. In de middagen brengen ze deze kennis in de praktijk door de verschillende onderdelen van HTML5 te gebruiken en daadwerkelijk apps te bouwen.</p>
<p>De kennissessies in de ochtenden zullen proberen alle onderdelen van JavaScript aan bod te laten komen. Van simpele dingen als hoe variabele werken tot complexe dingen als closures, prototype en contexten. Tijdens de sessie worden er onderdelen van de taal uitgelegd, gevolgd door opdrachten die kijken of de kennis opgenomen is.</p>
<p>'s Middags worden er een of meerdere apps gebouwd met behulp van de verschillende onderdelen van HTML5. We bekijken de API's en gaan zien wat we tegenwoordig allemaal kunnen op de browser en op mobiele apparaten.</p>
<p>Let op dat deze workshop je niet gaat leren hoe je jQuery moet gebruiken of hoe je moet werken zonder jQuery. Uxebu richt zich vooral op het overbrengen van hun kennis over JavaScript, mobile en HTML5.</p>
<p>Meer info op: <a href="http://uxebu.com/html5-workshop">http://uxebu.com/html5-workshop</a></p>
</content>
</entry>
<entry>
<title>Fronteers zomerborrel op vrijdag 15 juli</title>
<link href="https://www.fronteers.nl/nl/blog/2011/06/zomerborrel"/>
<updated>2011-06-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/06/zomerborrel</id>
<content xml:lang="nl" type="html"><p>Zo makkelijk als <a href="https://www.fronteers.nl/blog/2011/06/lenteborrel">de huidige lenteborrel</a> gepland werd, zo makkelijk plannen we de volgende. In deze tijd van komkommers is dat zo gek nog niet. Op 15 juli vindt daarom de eerste zomerborrel van dit jaar plaats in Utrecht.</p>
<p>Dus, <a href="https://www.fronteers.nl/leden">lid</a> of <a href="https://www.fronteers.nl/inschrijven">niet-lid</a>: kom rond 18 uur naar <a href="http://www.kroegpagina.nl/belgie/">Kafé België</a> aan de Oudegracht, en drink een biertje mee, terwijl je device APIs verdedigt, DOMweg wat willekeurigs over Java Script of Jason [sic] te vertellen hebt, of animaties in CSS van tafel schuift.</p>
<p>Tot dan!</p>
</content>
</entry>
<entry>
<title>Fronteers lenteborrel op maandag 20 juni</title>
<link href="https://www.fronteers.nl/nl/blog/2011/06/lenteborrel"/>
<updated>2011-06-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/06/lenteborrel</id>
<content xml:lang="nl" type="html"><p>Op de een-na-laatste dag van de lente—maandag 20 juni—gaat Fronteers weer gezellig borrelen in de <a href="http://www.nedlook.nl/restauranteersteklas/eersteklas/pub.html">1e klas pub op Amsterdam Centraal</a>. Je kunt gezellig praten over de HTML5 boilerplate, je frustraties over HTML e-mail templates uiten en natuurlijk gezellig een biertje drinken.</p>
<p>De borrel begint rond 18.00 uur, en rond 20.00 uur verschuiven we waarschijnlijk naar het naastgelegen 1e klas restaurant. De borrel is toegankelijk voor zowel leden als niet-leden, en het eerste drankje wordt betaald door Fronteers.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 5 juli, in Amsterdam, met gratis barbecue</title>
<link href="https://www.fronteers.nl/nl/blog/2011/06/bijeenkomst-juli-amsterdam"/>
<updated>2011-06-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/06/bijeenkomst-juli-amsterdam</id>
<content xml:lang="nl" type="html"><p>Op dinsdagavond 5 juli is Fronteers te gast bij <a href="http://efocus.nl/">eFocus</a> te Amsterdam. Voorafgaand is er een gratis barbecue. Aanmelden is wel noodzakelijk, aangezien de ruimte voor slechts 40 personen geschikt is. Er geldt: vol is vol, en wie het eerst komt, die het eerst maalt.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>17.30 binnenkomst met barbecue (indien het slecht weer is zullen er pizza's zijn)</li>
<li>19.30 presentatie Paul Kinlan over Google WebChrome (jawel, een spreker uit Groot Brittannië)</li>
<li>20.30 korte pauze</li>
<li>20.45 presentatie James Pearce via videoverbinding over ontwikkelen voor mobile/tablets met Sencha</li>
<li>21.45 borrelen</li>
</ul>
<p>eFocus is gevestigd aan Cruquiusweg 109e, 1019 AG Amsterdam.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 23 juni in Antwerpen</title>
<link href="https://www.fronteers.nl/nl/blog/2011/06/bijeenkomst-aspace"/>
<updated>2011-06-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/06/bijeenkomst-aspace</id>
<content xml:lang="nl" type="html"><p>Op donderdag 23 juni 2011 is Fronteers te gast bij ASPACE in Antwerpen. We voorzien twee presentaties. Eerst doet <a href="http://catchup.be/">Roel Van Gils</a> een boekje open over keyboard accessibility. Vervolgens zal <a href="http://mathiasbynens.be/">Mathias Bynens</a> je een stuk wijzer maken over JavaScript performance.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met broodjes en een drankje</li>
<li>19:00 Roel Van Gils: <em>“Keyboard accessibility. You’ve been doing it wrong.”</em></li>
<li>20:00 Mathias Bynens: <em>“How to waste an hour saving 8 milliseconds”</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Routebeschrijving</h2>
<p>ASPACE is gevestigd aan de Helmstraat 139 te 2140 Antwerpen. Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2011/aspace">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa <strike>25</strike> <strong>35</strong> mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Workshops update juni</title>
<link href="https://www.fronteers.nl/nl/blog/2011/06/cursussen-update-juni"/>
<updated>2011-06-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/06/cursussen-update-juni</id>
<content xml:lang="nl" type="html"><p>Inmiddels hebben we alweer vijf cursussen achter de rug. Naast <a href="https://www.fronteers.nl/workshops/css-positionering-peter-paul-koch">ppk</a> die het jaar aftrapte met CSS Positionering, zijn er cursussen gegeven door <a href="https://www.fronteers.nl/workshops/adaptief-ontwikkelen-vasilis-van-gemert">Vasilis van Gemert</a> (twee keer al zelfs), <a href="https://www.fronteers.nl/workshops/javascript-achtbaan-peter-van-der-zee">Peter van der Zee</a> en <a href="https://www.fronteers.nl/workshops/praktisch-html5-peter-beverloo">Peter Beverloo</a>. Tijd voor een update.</p>
<p>De eerstvolgende workshop is <a href="https://www.fronteers.nl/workshops/inclusive-design-jeroen-hulscher">Inclusive Design</a> die gegeven gaat worden door Jeroen Hulscher. Vanaf vandaag is het mogelijk om je hiervoor [in te schrijven](/workshops/inclusive-design-jeroen-hulscher. Zoals altijd geldt ook voor deze workshop dat je er snel bij moet zijn. Ervaring heeft ons inmiddels geleerd dat de meeste workshops supersnel vol zitten.</p>
<p>In de pijplijn hebben we verder nog ‘iets met web typografie’ waarover binnenkort meer, en een cursus door Stephen Hay getiteld ‘rabid prototyping’ waarvan we niet precies weten wat hij ermee bedoelt maar waar we natuurlijk wel enorm benieuwd naar zijn!</p>
<p>Tot slot nog het volgende. Zoals <a href="https://www.fronteers.nl/blog/2011/04/cursussen-update-april">eerder aangegeven</a> hebben we, om uit de kosten te komen, de kosten voor zowel leden als niet-leden verhoogd. De laatste workshop was de eerste waarbij we de nieuwe tarieven gehanteerd hebben en ook de eerste waarbij we in de evaluatie als feedback kregen dat de prijs nu precies goed is. In voorgaande evaluaties kregen we steevast te horen dat we te goedkoop waren!</p>
</content>
</entry>
<entry>
<title>Goed nieuws (voor vroege vogels)</title>
<link href="https://www.fronteers.nl/nl/blog/2011/05/goed-nieuws-voor-vroege-vogels"/>
<updated>2011-05-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/05/goed-nieuws-voor-vroege-vogels</id>
<content xml:lang="nl" type="html"><p>De 100 early bird kaartjes voor niet-leden zijn verkocht. Omdat dat veel sneller ging dan gedacht hebben we besloten om er nog 50 vrij te geven. We nemen aan dat deze kaartjes in een mum van tijd uitverkocht zullen zijn, <a href="http://fronteers.nl/congres/2011/tickets">wees er dus snel bij</a>, de prijzen gaan hierna direct omhoog! Fronteers-leden krijgen overigens tot 30 juni korting. Word je hier al blij van? Of nog niet helemaal? Er is meer.</p>
<p>Onze lijst met sprekers – <a href="https://www.fronteers.nl/blog/2011/03/kaartverkoop-fronteers-2011-begonnen">die we al indrukwekkend vonden</a> – is uitgebreid met de volgende topsprekers: de koningin van de de nieuwe revolutie Divya Manian, de koning van fool proof JavaScript Jake Archibald, de Graaf van Nordic Walking Robert Nyman, de koning van toekomstige CSS Stephen Hay en als kers op de cake ook nog eens de koning van jQuery en aanstaande keizer van web educatie John Resig!</p>
</content>
</entry>
<entry>
<title>WCAG 2.0: Voorspelbaar gedrag en overlays</title>
<link href="https://www.fronteers.nl/nl/blog/2011/05/wcag-2-0-overlays"/>
<updated>2011-05-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/05/wcag-2-0-overlays</id>
<content xml:lang="nl" type="html"><p>Richtlijn 3.2 Voorspelbaar: Maak het uiterlijk en de bediening van webpagina's voorspelbaar.</p>
<p><a href="http://www.w3.org/Translations/WCAG20-nl/#consistent-behavior">3.2. Bij focus: Als een component de focus krijgt, dan veroorzaakt dat geen contextwijziging. (Niveau A)</a></p>
<p>Het gebruik van page overlays zoals Lightbox is erg populair: niet alleen voor een uitvergrote foto of een korte melding, maar ook voor ingewikkelde formulieren en andere content zoals video's.</p>
<p>Belangrijk voor de toegankelijkheid is dat deze pop-ups niet op focus worden geopend maar na het activeren van een link, waarbij een waarschuwing is gegeven dat de content in een overlay wordt geopend. Ook is het zaak dat de content in de overlay toetsenbordtoegankelijk is.</p>
<p>Maar ben je er dan? Zijn er nog meer problemen met overlays en zo ja, hoe pak je die aan?</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 5 mei in Gent</title>
<link href="https://www.fronteers.nl/nl/blog/2011/04/bijeenkomst-gent"/>
<updated>2011-04-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/04/bijeenkomst-gent</id>
<content xml:lang="nl" type="html"><p>Op donderdag 5 mei 2011 is Fronteers te gast bij Netlash in Gent. Er worden twee presentaties voorzien. Eerst komt <a href="http://www.yonidebeule.be/">Yoni De Beule</a> praten over OOCSS; vervolgens zal <a href="http://vasilis.nl/">Vasilis van Gemert</a> wat vertellen over adaptieve layouts.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met broodjes en een drankje</li>
<li>19:00 Yoni De Beule over <em>OOCSS</em></li>
<li>20:00 Vasilis van Gemert over <em>adaptieve layouts</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Routebeschrijving</h2>
<p>Netlash is gevestigd aan de Voorhavenlaan 31, 9000 Gent. Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2011/netlash">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 30 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Front-end vraagstukken: HTML e-mail</title>
<link href="https://www.fronteers.nl/nl/blog/2011/04/fe-vraag-html-email"/>
<updated>2011-04-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/04/fe-vraag-html-email</id>
<content xml:lang="nl" type="html"><p>Het is alweer een tijdje geleden dat een Fronteers lid voor het laatst een <a href="https://www.fronteers.nl/blog/categorieen/front-end-vraagstukken">front-end vraagstuk</a> op het blog aan iedereen wilde voorleggen, maar Monique Martens heeft nu een vraag over HTML e-mail:</p>
<p>Het (b)lijkt dat HTML mails niet goed worden weergegeven in sommige versies van Outlook (danwel in andere e-mail clients). Bouw je een schitterende mailing volgens de webrichtlijnen met div id-tjes en class-jes, ziet die er in Outlook niet uit!</p>
<p>Wat vinden de andere leden hier van?
Gewoon stug vasthouden aan de huidige techniek?
Of back to basic (?) en mail(ings) weer met tabellen, font tags e.d. opmaken?</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 6 mei, in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2011/04/bijeenkomst-mei"/>
<updated>2011-04-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/04/bijeenkomst-mei</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 6 mei is Fronteers te gast bij <a href="http://eduhub.nl/">Eduhub</a> te Amsterdam. Er zullen vier mensen een praatje houden van 15 minuten waarna er 15 minuten gediscussieerd kan worden.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 inloop</li>
<li>19.30 Frontend testing met Selenium</li>
<li>20.00 Headless browser testing met Ruby</li>
<li>20.30 korte pauze</li>
<li>20.45 Conversie optimalisatie met Visual Website Optimizer / Optimizely</li>
<li>21.15 Pattern library management (over beheer(s)baar maken van frontend code voor backend developers etc.)</li>
<li>21.45 borrelen</li>
</ul>
<p>Eduhub is gevestigd aan Rokin 75, 1012 KL Amsterdam. De bijeenkomst is gratis bij te wonen voor zowel leden als niet-leden van Fronteers. Wel is noodzakelijk dat <a href="https://www.fronteers.nl/bijeenkomsten/2011/eduhub#formulier-1">je jezelf aanmeldt via het formulier</a> zodat we weten hoeveel mensen aanwezig zullen zijn.</p>
</content>
</entry>
<entry>
<title>WCAG 2.0: Toegankelijke formulieren</title>
<link href="https://www.fronteers.nl/nl/blog/2011/04/wcag-2-0-toegankelijke-formulieren"/>
<updated>2011-04-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/04/wcag-2-0-toegankelijke-formulieren</id>
<content xml:lang="nl" type="html"><p>Richtlijn 2.1 Toetsenbordtoegankelijk: Maak alle functionaliteit beschikbaar vanaf een toetsenbord.</p>
<p>Meer specifiek: <em><a href="http://www.w3.org/Translations/WCAG20-nl/#keyboard-operation">2.1.1 Toetsenbord</a>: Alle functionaliteit van de content is bedienbaar via een toetsenbordinterface zonder dat afzonderlijke toetsaanslagen aan tijd gebonden zijn, behalve als de onderliggende functie een invoer vereist die afhangt van het pad dat de gebruiker aflegt en niet alleen van de eindpunten. (Niveau A)</em></p>
<p>Na deze technisch neutrale richtlijn staan vervolgens bij de <a href="http://www.w3.org/WAI/WCAG20/quickref/#qr-keyboard-operation-keyboard-operable">Afdoende technieken</a> voorbeelden van HTML, scripting en Flash technieken waarmee je aan deze regel kunt voldoen.</p>
<p>In WCAG 2.0 wordt soepeler omgegaan met het gebruik van Javascript dan in WCAG 1.0. Dit is niet raar als je de uitkomsten ziet van de laatste <a href="http://webaim.org/projects/screenreadersurvey3/#javascript">screenreader-enquête</a>. Hierin komt naar voren dat ruim 98% van de screenreader gebruikers javascript enabled heeft. Daarnaast is er ook qua usability wat voor te zeggen als je bijvoorbeeld in uitgebreide formulieren dynamisch de vragen en keuzemogelijkheden kan aanpassen, zodat ook iemand met een screenreader minder opties hoeft te doorlopen. Voor deze gebruikers is dit zelfs nog handiger, omdat het veel tijd kan schelen.
Hetzelfde geldt voor client-side validation. Via javascript kun je bij een verkeerd ingevuld veld een foutmelding invoegen via de DOM, met daarin een link naar het veld waar het gecorrigeerd moet worden. Zodoende hoef je niet het hele formulier te doorzoeken wanneer je niet in een oogopslag kunt zien waar de fout zit.</p>
<p>Eventueel kan het formulier dan nog uitgebreid worden met <a href="http://www.w3.org/TR/wai-aria-practices/">WAI-ARIA</a> roles en states zoals 'role=alert' en 'aria-invalid' of 'aria-live'. En/of met <a href="http://diveintohtml5.org/forms.html">HTML5 formuliervalidatie</a>, eventueel met javascript-fallback.</p>
<p>Hoe maken jullie formulieren toegankelijk?</p>
</content>
</entry>
<entry>
<title>Workshops update april</title>
<link href="https://www.fronteers.nl/nl/blog/2011/04/cursussen-update-april"/>
<updated>2011-04-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/04/cursussen-update-april</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 3 mei zal Vasilis van Gemert, die we natuurlijk allemaal kennen van onder andere de <a href="http://dailynerd.nl/">Daily Nerd</a> nogmaals zijn cursus <a href="https://www.fronteers.nl/workshops/adaptief-ontwikkelen-vasilis-van-gemert">Adaptief Ontwikkelen</a> gaan geven. [Update] inmiddels zit ook deze cursus vol.</p>
<p>De vorige keer dat deze workshop gegeven werd zat de cursus binnen een dag vol.</p>
<p>Cursussen lopen sowieso lekker. Op 20 april zal <a href="http://qfox.nl/">Peter van der Zee</a> zijn cursus JavaScript Achtbaan voor het eerst geven. Ook deze cursus zat binnen een dag vol, maar hopelijk kunnen we hem net als Vasilis overhalen de cursus later dit jaar nog een keer te geven.</p>
<p>Verder staan cursussen van <a href="http://peter.sh/">Peter Beverloo</a>, <a href="http://jeroenhulscher.nl/">Jeroen Hulscher</a> en <a href="http://the-haystack.com/">Stephen Hay</a> op het progamma voor later dit jaar. Dit brengt ons bij het volgende punt; cursussen zijn enorm populair en dit vooral onder de eigen leden. Die betalen voor een cursus het werkelijk luttele bedrag van €50 wat helaas betekent dat cursussen op dit moment verliesgevend zijn. Gelukkig hebben we budget voor cursussen maar omdat cursussen zich op dit moment nog niet zelf kunnen bedruipen is dat is een keer op. Omdat we wel graag meer (en misschien ook vaker) cursussen willen blijven geven, betekent dit helaas dat de prijs van cursussen later dit jaar omhoog zal gaan.</p>
<p>Tot slot willen we, in het verlengde hiervan, aanstaande cursisten wijzen op een kleine wijziging in <a href="https://www.fronteers.nl/workshops/voor-cursisten">de kleine lettertjes</a>. Vanaf de cursus Adaptief Ontwikkelen op 3 mei is het niet langer mogelijk je binnen 48 uur voor een cursus nog af te melden en je geld terug te krijgen.</p>
</content>
</entry>
<entry>
<title>Fronteers adviseert af te stappen van HTML</title>
<link href="https://www.fronteers.nl/nl/blog/2011/04/stap-nu-over"/>
<updated>2011-04-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/04/stap-nu-over</id>
<content xml:lang="nl" type="html"><p>Als vakvereniging voor front-end ontwikkelend Nederland proberen we de trends in onze branche goed in de gaten te houden. HTML5, het mobiele web, responsive design, 3D geneuzel in je browser; het zit er allemaal aan te komen. Maar wat betekent dit voor onze toekomst? Moeten we echt iedere dag bij blijven leren en tijd verspillen aan artikelen en demo's die slechts 10% van onze bezoekers kunnen zien? Waarom kunnen we niet gewoon tevreden zijn met wat we al hebben?</p>
<p>HTML5 zorgt alleen maar voor meer veiligheidsproblemen. Privacy op het web behoort nu al tot het verleden. Testcases voor CSS worden afgeraffeld door browser bouwers. JavaScript wordt steeds sneller, maar tegelijkertijd worden libraries alleen maar groter. Google probeert hard het web sneller te krijgen, maar trends tonen aan dat pagina's alleen maar zwaarder worden. De mobiele web maffia probeert ons te doen geloven dat we eerst aan hun moeten denken, voordat we zooi toevoegen. En aan de andere kant zijn er figuren die blindstaren op het &quot;One Web&quot; mantra.</p>
<p>Wij vinden dat het anders kan, en moet. Vanaf vandaag adviseren wij iedereen die websites ontwerpt, bouwt en onderhoudt gewoon met tekst te werken. Gewoon toegankelijk voor iedereen, snel en herkenbaar. En het grootste voordeel: het werkt in Internet Explorer 6, dus klanten zullen hier van smullen. Na wat onderzoek bij <a href="https://www.fronteers.nl/leden">onze leden</a> blijkt dit, nog steeds, een van de grootste pijnpunten te zijn.</p>
<p>Stap vandaag over. Wij zeggen Doen!</p>
</content>
</entry>
<entry>
<title>Kaartverkoop Fronteers 2011 van start</title>
<link href="https://www.fronteers.nl/nl/blog/2011/03/kaartverkoop-fronteers-2011-begonnen"/>
<updated>2011-03-30T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/03/kaartverkoop-fronteers-2011-begonnen</id>
<content xml:lang="nl" type="html"><p>De kaartverkoop voor het <a href="http://fronteers.nl/congres/2011">Fronteers Congres</a> op 6 en 7 oktober 2011 in Tuschinski in Amsterdam is begonnen, het belooft weer een topcongres te worden. De eerste 6 sprekers zijn inmiddels bekend: Alex Russell, Bruce Lawson, Chris Heilmann, Derek Featherstone, Lea Verou en Tab Atkins Jr. Dat is op zich al een <a href="http://fronteers.nl/congres/2011/speakers">indrukwekkende line up</a> maar de komende maanden zullen we meer namen van sprekers bekendmaken.</p>
<p>Zoals altijd staat de prijs van het Fronteers congres niet echt in verhouding tot de kwaliteit en voor Fronteersleden is het een waar vriendenprijsje:</p>
<table>
<thead>
<tr>
<th>Early-bird</th>
<th>Prijs</th>
</tr>
</thead>
<tbody>
<tr>
<td>Fronteersleden</td>
<td>€ 200,-</td>
</tr>
<tr>
<td>Niet leden</td>
<td>€ 275,-</td>
</tr>
</tbody>
</table>
<table>
<thead>
<tr>
<th>Normaal ticket</th>
<th>Prijs</th>
</tr>
</thead>
<tbody>
<tr>
<td>Fronteersleden</td>
<td>€ 300,-</td>
</tr>
<tr>
<td>Niet-leden</td>
<td>€ 375,-</td>
</tr>
</tbody>
</table>
<p>De early-bird periode is nu gestart en loopt tot eind juni. Fronteersleden kunnen <a href="https://www.fronteers.nl/congres/2011/contact">een kortingscode aanvragen</a>. Korting voor leden geldt alleen voor mensen die inmiddels lid zijn, mensen die na 30 maart lid zijn geworden krijgen geen korting. Kaarten zijn te bestellen <a href="http://fronteers.paydro.net/">via Paydro</a>.</p>
</content>
</entry>
<entry>
<title>WCAG 2.0: regels voor tekstschaalbaarheid achterhaald?</title>
<link href="https://www.fronteers.nl/nl/blog/2011/03/wcag-2-0-regels-voor-tekstschaalbaarheid-achterhaald"/>
<updated>2011-03-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/03/wcag-2-0-regels-voor-tekstschaalbaarheid-achterhaald</id>
<content xml:lang="nl" type="html"><p>Richtlijn 1.4 Onderscheidbaar: Maak het voor gebruikers gemakkelijker om content te horen en te zien, waaronder scheiding van voorgrond en achtergrond.</p>
<p><em><a href="http://www.w3.org/Translations/WCAG20-nl/#visual-audio-contrast">1.4.4 Herschalen van tekst</a>: Behalve voor ondertitels voor doven en slechthorenden en afbeeldingen van tekst, kan tekst zonder hulptechnologie tot 200 procent schalen zonder verlies van content of functionaliteit. (Niveau AA)</em></p>
<p>Is het -nu browserzoom breed ondersteund wordt- nog wel nodig om daarvoor je layout in ems of procenten op te maken? (Zie <a href="http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-scale">Sufficient Techniques for 1.4.4 - Resize text</a>.) IE6 is toch stervende?</p>
<p>En wat te denken van de tekstgrootte opties (Aa) die je nog op veel websites ziet, bijvoorbeeld op <a href="http://www.ns.nl/">www.ns.nl</a> ? Toch nog wel handig voor mensen die de browserzoom niet kennen, of beter schrappen en de bezoeker uitleggen hoe hij/zij zelf de tekst kan vergroten?</p>
</content>
</entry>
<entry>
<title>Fronteers borrel op 1 april in Amsterdam (echt waar)</title>
<link href="https://www.fronteers.nl/nl/blog/2011/03/borrel-april"/>
<updated>2011-03-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/03/borrel-april</id>
<content xml:lang="nl" type="html"><p>Elke week weer diezelfde borrelpraat over koetjes en kalfjes, nooit eens een echt interessant gesprek. Kom op 1 april (echt waar) naar de enige echte Fronteers borrel waar je met vakgenoten gewoon kan praten over css-counters, closures, het nut van het <code>hgroup</code> element, waar je normale conversaties over YSlow en Page Speed kunt houden, waar mensen je gewoon begrijpen als je je frustratie uit over het feit dat Opera decimalen in procentuele breedtes compleet negeert.</p>
<p>De borrel wordt gehouden op 1 april in de <a href="http://www.nedlook.nl/restauranteersteklas/eersteklas/pub.html">1e Klas Pub</a> op spoor 2b in Amsterdam Centraal Station (echt waar) vanaf een uur of 18:00. Het eerste biertje is op rekening van Fronteers. Mensen met een <a href="http://dailynerd.nl/">Daily Nerd</a> t-shirt krijgen een gratis biertje van @vasilis.</p>
<p>De borrel is uiteraard toegankelijk voor zowel leden als niet-leden. Laat het even weten of je komt via een reactie hieronder.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 31 maart in Hasselt</title>
<link href="https://www.fronteers.nl/nl/blog/2011/03/bijeenkomst-hasselt"/>
<updated>2011-03-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/03/bijeenkomst-hasselt</id>
<content xml:lang="nl" type="html"><p>Op donderdag 31 maart 2011 is Fronteers te gast bij de Provinciale Hogeschool Limburg in Hasselt (jawel, in België!). Er worden twee presentaties voorzien. Eerst komt <a href="https://builtbyrobot.com/">Jochen Vandendriessche</a> praten over het gebruik van Git in z’n workflow als front-end-ontwikkelaar; vervolgens zal <a href="http://jan.moesen.nu/">Jan “Bietekwiet” Moesen</a> wat vertellen over automatisering van de browser met user scripts en bookmarklets en automatisering van ontwikkeling via de terminal.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met broodjes en een drankje</li>
<li>19:00 Jochen Vandendriessche over <em>Git voor fronteers</em></li>
<li>20:00 Jan Moesen over <em>het gebrek aan automatisering</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Routebeschrijving</h2>
<p>De Provinciale Hogeschool Limburg is gevestigd aan de Elfde Liniestraat 23a, 3500 Hasselt. Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2011/phl">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 55 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Verslag Docentendag</title>
<link href="https://www.fronteers.nl/nl/blog/2011/03/verslag-docentendag"/>
<updated>2011-03-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/03/verslag-docentendag</id>
<content xml:lang="nl" type="html"><p>De <a href="https://www.fronteers.nl/docentendag">docentendag 2011</a> zit er weer op. Vijftien docenten zijn in Amsterdam samengekomen om samen met de commissie-Onderwijs, Nikolai Onken en Hedwyg van Groenendaal nader kennis te maken met het vakgebied en met elkaar.</p>
<p><img src="https://www.fronteers.nl/_img/2011/03/prezi.png" alt="" /></p>
<p>Nikolai Onken heeft zijn slides over HTML5 apps beschikbaar gesteld via SlideShare: <a href="http://www.slideshare.net/nonken/html5-apps">http://www.slideshare.net/nonken/html5-apps</a>.</p>
<p>Tijdens het middagprogramma is er in groepjes gediscussieerd over een aantal stellingen. Tijdens deze discussie zijn er per groepje aantekeningen gemaakt in Prezi. Deze is terug te vinden op <a href="http://prezi.com/ogrztohwvnve">http://prezi.com/ogrztohwvnve</a>.</p>
<p>De commissie-Onderwijs wil nogmaals Nikolai en Hedwyg danken voor hun bijdrage aan de docentendag. Dank is er ook voor info.nl, voor het goede ontvangst en de geslaagde borrel.</p>
</content>
</entry>
<entry>
<title>WCAG 2.0: Richtlijn 1.3 Aanpasbare presentatie zonder verlies van informatie of structuur</title>
<link href="https://www.fronteers.nl/nl/blog/2011/02/richtlijn-1-3-aanpasbare-presentatie-zonder-verlies-van-informatie-of-structuur"/>
<updated>2011-02-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/02/richtlijn-1-3-aanpasbare-presentatie-zonder-verlies-van-informatie-of-structuur</id>
<content xml:lang="nl" type="html"><p>Richtlijn 1.3 Aanpasbaar: Creëer content die op verschillende manieren gepresenteerd kan worden (bijvoorbeeld eenvoudiger lay-out) zonder verlies van informatie of structuur.</p>
<p>Volgens succescriterium <a href="http://www.w3.org/Translations/WCAG20-nl/#content-structure-separation">1.3.1 Info en relaties</a> moet informatie, structuur, en relaties overgebracht door presentatie door software bepaald kunnen worden of beschikbaar zijn in tekst.</p>
<p>Op 26 februari kwam Stichting Drempelvrij met een <a href="http://www.drempelvrij.nl/actueel/#provinciale-verkiezingswebsites">persbericht over de (on)toegankelijkheid van provinciale verkiezingswebsites</a>. Het Interprovinciaal overleg (IPO) heeft met het oog op de Provinciale Staten-verkiezingen een <a href="http://www.provincies.nl/magazine/">website</a> gemaakt waarin wordt uitgelegd wat de provincies precies doen. Deze website is geheel in Flash en ontoegankelijk bevonden door Drempelvrij.
Flash was lange tijd <em>not done</em> als het aankwam op het bouwen van toegankelijke websites, maar nu zijn er in WCAG 2.0 speciaal <a href="http://www.w3.org/WAI/GL/WCAG20-TECHS/flash.html">richtlijnen</a> voor opgenomen.</p>
<p>Betekent dit dat we nu weer rustig grote, belangrijke onderdelen in Flash in onze sites kunnen opnemen? Lukt het bijvoorbeeld om in de huidige Flash versie zo'n site als bovengenoemde van IPO toegankelijk te maken, in ieder geval op niveau A?</p>
<p>Of kun je toch nog beter een alternatieve versie aanbieden in bijv. HTML of PDF? (Ervan uitgaande dat je geen initiële keus had voor wel/geen Flash.)
Wat is het meest efficiënt voor bouwers en het meest effectief/prettig voor bezoekers met een beperking?</p>
</content>
</entry>
<entry>
<title>Fronteers 2011: 6 en 7 oktober</title>
<link href="https://www.fronteers.nl/nl/blog/2011/02/fronteers-2011"/>
<updated>2011-02-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/02/fronteers-2011</id>
<content xml:lang="nl" type="html"><p>Na de successen van de afgelopen jaren organiseert Fronteers dit jaar uiteraard weer een congres. <a href="https://www.fronteers.nl/congres/2011">Fronteers 2011</a> zal gehouden worden op <em>donderdag 6 en vrijdag 7 oktober 2011 in Pathé Tuschinski</em> te Amsterdam. Deze data kan je alvast in je agenda noteren. Iedereen die vorig jaar is geweest, snapt waarom we dit jaar weer voor Tuschinski hebben gekozen: een prachtig gebouw met een centrale ligging en niet te vergeten fantastische stoelen.</p>
<p><img src="https://www.fronteers.nl/_img/congres/2010/venue/fronteers-2010-andreasdantz.jpg" alt="" /></p>
<p>De kaartverkoop zal in <em>maart</em> starten. Precieze kaartprijzen zijn nog niet bekend. Ze zullen in ieder geval, omdat we geen winstoogmerk hebben, ook dit jaar weer zeer betaalbaar zijn.
<em>Let op</em>: de regels met betrekking tot de ledenkorting zijn veranderd. Dit jaar geldt de ledenkorting <em>alleen</em> indien je al lid bent op het moment dat de kaartverkoop start. Wil je naar het congres en denk je erover om lid te worden en gebruik te maken van de ledenkorting? Neem dan snel je beslissing.</p>
<p>Het is de bedoeling om, net als vorig jaar, voorafgaand aan het congres specialistische workshops/masterclasses te laten geven door internationale experts. De exacte invulling hiervan is nog niet bekend, we laten het weten zodra er meer bekend is.</p>
<p><img src="https://www.fronteers.nl/_img/congres/2010/fr4-lejoe.jpg" alt="" /></p>
<p>Dat laatste geldt natuurlijk ook voor de sprekers: op dit moment zijn er nog geen namen die we bekend kunnen maken. We gaan weer een aantal grote namen naar Amsterdam halen, daarnaast houden we ook een handvol sessies gereserveerd voor nieuw talent: we zorgen er weer voor dat Fronteers 2011 technisch hoogstaand, gevarieerd en spraakmakend wordt.</p>
<p>Het is mogelijk het Fronteers congres te sponsoren. Sponsors krijgen aandacht op het drukwerk, de website en naar eigen wens alle ruimte in de goodie bag. Andere invullingen zijn in overleg ook mogelijk. We doen net als vorig jaar niet aan gesponsorde talks. Geïnteresseerden kunnen contact opnemen met Thijs Reijgersberg, <a href="mailto:thijs@fronteers.nl">thijs@fronteers.nl</a>.</p>
<p><img src="https://www.fronteers.nl/_img/congres/2010/fr5-lejoe.jpg" alt="" /></p>
<p>De congres commissie is hard bezig om Fronteers 2011 minstens zo indrukwekkend te maken als voorgaande edities. De Twitteraars die het congresnieuws graag heet van de naald willen, doen er goed aan ons op <a href="https://twitter.com/FronteersConf">Twitter (@FronteersConf)</a> en <a href="http://lanyrd.com/2011/fronteers/">Lanyrd</a> te volgen.</p>
<p>Edwin, Hidde, Krijn, Peter, Peter-Paul, Thijs en Vasilis.</p>
</content>
</entry>
<entry>
<title>Fronteers Docentendag: nog maar twee weken!</title>
<link href="https://www.fronteers.nl/nl/blog/2011/02/docentendag"/>
<updated>2011-02-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/02/docentendag</id>
<content xml:lang="nl" type="html"><p>Op 24 februari vindt de Fronteers Docentendag 2011 plaats! De docentendag is een studiedag voor docenten in het front-end onderwijs. Het doel is docenten met elkaar en met de beroepspraktijk in contact brengen. De dag vindt plaats in Amsterdam en wordt gehost door <a href="http://info.nl/">info.nl</a> en restaurant/café In De Waag.</p>
<p>Nikolai Onken vertelt over HTML 5 applicaties; Hedwyg van Groenendaal leidt de discussie in over de combinatie van front-end en onderwijs. De dag sluit af met een rondleiding en een borrel bij info.nl.</p>
<p>Er zijn nog maar enkele plaatsen beschikbaar: meld u snel aan op <a href="https://www.fronteers.nl/docentendag">fronteers.nl/docentendag</a>!</p>
</content>
</entry>
<entry>
<title>Fronteers Workshops, een update</title>
<link href="https://www.fronteers.nl/nl/blog/2011/02/workshops-update"/>
<updated>2011-02-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/02/workshops-update</id>
<content xml:lang="nl" type="html"><p>Zoals eenieder bijna niet kan zijn ontgaan is de commissie cursussen voortvarend van start gegaan in het nieuwe jaar. De eerste cursus, <a href="https://www.fronteers.nl/workshops/css-positionering-peter-paul-koch">CSS Positionering</a> is inmiddels achter de rug en uit de korte evaluatie is gebleken dat de cursisten er unaniem zeer tevreden over waren.</p>
<p>De cursus sloot goed aan bij de verwachtingen die de cursisten erbij hadden. De lunch werd zeer goed ontvangen en ook Seats2Meet in Utrecht als locatie blijkt in goede aarde te vallen. De superlatieven waren niet van de lucht, met andere woorden voldoende motivatie om verder te gaan en ook de cursussen die dit jaar nog gegeven gaan worden tot een groot succes te maken.</p>
<p>Voor 8 maart staat de workshop <a href="https://www.fronteers.nl/workshops/adaptief-ontwikkelen-vasilis-van-gemert">Adaptief Ontwikkelen</a> gepland. Deze workshop zal gegeven worden door Vasilis van Gemert. De interesse voor deze workshop was dusdanig groot dat hij binnen een dag vol zat. We hebben echter goed nieuws voor degenen die hem graag hadden willen volgen maar achter het net gevist hebben; Vasilis wil deze workshop in mei graag nog een keer gaan geven. Een exacte datum voor deze workshop, evenals de JavaScript workshop die Peter van der Zee gaat geven, hebben we nog niet. Dus houdt de website en de Twitters daarom goed in de gaten.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 3 maart, in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2011/02/bijeenkomst-maart"/>
<updated>2011-02-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/02/bijeenkomst-maart</id>
<content xml:lang="nl" type="html"><p>Op donderdag 3 maart is Fronteers te gast bij 80beans in Amsterdam. Roy Tomeij zal spreken over front-end meta languages. Vasilis van Gemert gaat dieper in op adaptive development.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 inloop</li>
<li>19.30 Roy Tomeij over front-end meta languages</li>
<li>20.30 pauze</li>
<li>20.45 Vasilis van Gemert over adaptive development</li>
<li>21.45 borrelen, netwerken</li>
</ul>
<h2>Front-end meta languages</h2>
<p>Er zijn verschillende meta-languages die het schrijven van front-end code prettiger, sneller en minder foutgevoelig kunnen maken. Ook hierbij geldt dat het uiteindelijk een kwestie van persoonlijke voorkeur is, maar <a href="https://twitter.com/roy">Roy Tomeij</a> zal uitleggen waarom jij én de back-enders die de code gaan implementeren vrolijker worden van onder andere Haml, Sass en CoffeeScript.</p>
<h2>Adaptive development</h2>
<p>In deze presentatie behandelt <a href="http://vasilis.nl/">Vasilis van Gemert</a> van <a href="http://mirabeau.nl/">Mirabeau</a> aan de hand van praktijkvoorbeelden verschillende technieken die in te zetten zijn bij het bouwen van adaptive layouts. Denk hierbij aan termen als em-based layouts, media-queries, re-alignment best practices en client-side adaptive image-replacement. Met andere woorden: echt flexibele websites die zich aanpassen aan het apparaat waarmee gekeken wordt.</p>
<p>80beans is gevestigd aan de Vijzelstraat 72, ruimte 3.56, 1017 HL , Amsterdam. Zoals gebruikelijk is de bijeenkomst gratis bij te wonen door zowel leden als niet-leden. Wel is het gewenst dat je jezelf opgeeft. Er zal gezorgd worden voor webstandaardenbier.</p>
</content>
</entry>
<entry>
<title>Fronteers 2011: welke spreker wil jij zien?</title>
<link href="https://www.fronteers.nl/nl/blog/2011/02/fronteers-2011-welke-spreker"/>
<updated>2011-02-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/02/fronteers-2011-welke-spreker</id>
<content xml:lang="nl" type="html"><p>De voorbereidingen voor het Fronteers congres van 2011 zijn begonnen. Om het congres nog beter te maken dan voorgaande jaren willen we graag van jullie weten welke sprekers je graag zou zien. Wie heb je al die jaren gemist als spreker? Welke guru moeten we per se uitnodigen?</p>
<p>Misschien ken je wel iemand die nog niet zo bekend is, maar die echt iets nieuws te vertellen heeft. Of vind je dat we absoluut een van de sprekers van afgelopen jaren weer moeten uitnodigen.</p>
<p>Laat het ons weten via <a href="https://twitter.com/FronteersConf">Twitter</a>, <a href="http://webchat.freenode.net/?channels=fronteers">IRC</a>, per <a href="mailto:congres@fronteers.nl">mail</a> of hier in de comments en wij zullen ons best doen om jullie favoriete sprekers te boeken.</p>
<p>Om jullie er nog even aan te herinneren hoe het er afgelopen jaar aan toe ging, hieronder een sfeerimpressie van <a href="http://vimeo.com/16670431">Fronteers 2010</a> (gemaakt door <a href="http://vimeo.com/fzijlstra">Frank Zijlstra</a>):
<video controls="" width="480" height="270">
<source src="https://www.fronteers.nl/archief/_downloads/2010/fronteers-2010-compilatie.webm" type="video/webm" />
Download de <a href="https://www.fronteers.nl/nl/blog/2011/02/archief/_downloads/2010/fronteers-2010-compilatie.webm">webm</a> video.
</video>
Wij hebben er zin in; jullie hopelijk ook!</p>
</content>
</entry>
<entry>
<title>WCAG 2.0: Richtlijn 1.2 Op tijd gebaseerde media</title>
<link href="https://www.fronteers.nl/nl/blog/2011/02/richtlijn-1-2-op-tijd-gebaseerde-media"/>
<updated>2011-02-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/02/richtlijn-1-2-op-tijd-gebaseerde-media</id>
<content xml:lang="nl" type="html"><p>Richtlijn 1.2 Op tijd gebaseerde media: Lever alternatieven voor op tijd gebaseerde media.</p>
<p>Als het aankomt op multimedia lijkt het al snel ingewikkeld te worden om aan <a href="http://www.w3.org/Translations/WCAG20-nl/#media-equiv">Richtlijn 1.2</a> te voldoen: tekstbeschrijvingen, ondertitels, audio beschrijvingen... Het komt erop neer dat alles wat er te zien is, ook te horen moet zijn via aangeboden audio of in tekstvorm (zodat hulptechnologie ermee overweg kan), en dat alles wat er te horen is, ook te zien moet zijn, zoals bijvoorbeeld de beschrijvingen tussen de gesproken tekst door in de ondertiteling als 'er klinkt een harde schreeuw'.</p>
<p>Deze regels gelden voor vooraf opgenomen content op niveau A, vanaf niveau AA zijn er ook eisen wat betreft live content en gebarentaal.</p>
<p>Mijns inziens gaan de regels soms wel wat ver. Twee concrete voorbeelden:</p>
<p>Kun je van een (kleine) gemeente met weinig budget voor de website verwachten dat ze ondertitels gaan verzorgen bij een live uitzending van de raadsvergadering? Anders voldoen ze niet (meer) aan de webrichtlijnen niveau AA...</p>
<p>Als er op de homepage een geanimeerde Flash banner staat die een paar onderwerpen uitlicht die ook elders op de site in de html staan, moet de inhoud van de Flash banner dan ook nog in een alternatief worden aangeboden? Het lijkt mij dat als je er niks belangrijks door mist, dat dat dan niet nodig is.</p>
<p>Wat denken jullie? Zijn deze eisen gerechtvaardigd en uitvoerbaar?</p>
</content>
</entry>
<entry>
<title>Commissie Onderwijs: docentendag, commissieleden gezocht en bronnen bijgewerkt</title>
<link href="https://www.fronteers.nl/nl/blog/2011/02/onderwijs-commissie"/>
<updated>2011-02-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/02/onderwijs-commissie</id>
<content xml:lang="nl" type="html"><p>De commissie Onderwijs organiseert op 25 februari 2011 een docentendag in Amsterdam. Ook zoekt zij nieuwe commissieleden. Daarnaast zijn de bronnen op de website bijgewerkt.</p>
<h2>Docentendag</h2>
<p>Op donderdag 24 februari 2011 organiseert Fronteers samen met <a href="http://info.nl/">info.nl</a> een docentendag in Amsterdam. Ontmoet collega docenten en woon twee presentaties van mensen uit het vakgebied bij. De docentendag is gratis voor docenten (front-end) webdevelopment aan ROC's, hogescholen en universiteiten. Aanmelden kan via het formulier op de pagina <a href="https://www.fronteers.nl/docentendag">/docentendag</a>.</p>
<h2>Commissieleden gezocht</h2>
<p>De commissie is de laatste maanden in omvang afgenomen. We zijn op zoek naar docenten die mee willen discussiëren over de toekomst van het front-end webdevelopment onderwijs in Nederland. Voornaamste taken zijn het bespreken van curricula en het organiseren van de docentendag 2012. We zoeken zowel leden als een nieuwe voorzitter. Een e-mail met motivatie kan naar <a href="mailto:onderwijs@fronteers.nl">onderwijs@fronteers.nl</a>.</p>
<h2>Bronnen bijgewerkt</h2>
<p>Onlangs heeft Claudia Angenent de bronnen op <a href="https://www.fronteers.nl/vereniging/commissies/onderwijs/bronnen">/vereniging/commissies/onderwijs/bronnen</a> bijgewerkt. De bronnen zijn handige links naar materiaal voor beginnende webdevelopers. Mocht je iemand kennen die wil starten met front-end webdevelopment, dan kun je hem of haar hiernaartoe verwijzen. Suggesties zijn overigens welkom, je kunt ze achterlaten in de comments.</p>
</content>
</entry>
<entry>
<title>WCAG 2.0: Richtlijn 1.1 Tekstalternatieven</title>
<link href="https://www.fronteers.nl/nl/blog/2011/01/wcag-20-richtlijn-1-1-tekstalternatieven"/>
<updated>2011-01-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/01/wcag-20-richtlijn-1-1-tekstalternatieven</id>
<content xml:lang="nl" type="html"><p>In navolging van de serie <a href="https://www.fronteers.nl/blog/categorieen/webrichtlijnen">blogposts over webrichtlijnen</a> vanaf nu een reeks artikelen over <a href="http://www.w3.org/Translations/WCAG20-nl/">WCAG 2.0</a>, die ook een integraal onderdeel gaan vormen van de Webrichtlijnen versie 2.</p>
<p><em>Richtlijn 1.1 Tekstalternatieven: Lever tekstalternatieven voor alle niet-tekstuele content, zodat die veranderd kan worden in andere vormen die mensen nodig hebben, zoals grote letters, braille, spraak, symbolen of eenvoudiger taal.</em></p>
<p>Onder deze richtlijn vallen niet alleen situaties waarin belangrijke content toegankelijk moet worden gemaakt via tekstalternatieven (hierover later meer), maar ook situaties waarin gebruikers of hulptechnologieën moeten weten dat ze bepaalde onderdelen juist moeten negeren of 'anders behandelen' :</p>
<ul>
<li>Zintuiglijk: Als niet-tekstuele content primair is bedoeld om een specifieke zintuiglijke ervaring te creëren, dan leveren tekstalternatieven ten minste een beschrijving van de niet-tekstuele content.</li>
<li>Decoratie, opmaak, onzichtbaar: Als niet-tekstuele content puur decoratief is, slechts voor visuele opmaak wordt gebruikt, of niet aan gebruikers wordt gerepresenteerd, dan wordt ze op zo'n manier geïmplementeerd dat ze genegeerd kan worden door hulptechnologie.</li>
</ul>
<p>Hebben jullie hier ervaring mee? Gebruiken jullie bijvoorbeeld wel eens opzettelijk lege <code>alt</code> attributen?</p>
<p>Welke andere situaties zijn hier nog te bedenken?</p>
<p>Zijn er bijvoorbeeld irritaties over elementen die voor veel ruis zorgen voor screenreader gebruikers, en die daarom dus beter aangegeven of verborgen zouden kunnen worden?</p>
</content>
</entry>
<entry>
<title>Mobilism 2011: Fronteers kaarten</title>
<link href="https://www.fronteers.nl/nl/blog/2011/01/mobilism"/>
<updated>2011-01-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/01/mobilism</id>
<content xml:lang="nl" type="html"><p>Op 12 en 13 mei as. zal te Amsterdam <a href="http://mobilism.nl/">Mobilism 2011</a> plaatsvinden, dat geheel gewijd zal zijn aan mobiele webontwikkeling. Een <a href="http://mobilism.nl/2011/speakers">mooie sprekerslijst</a> staat garant voor een topcongres.</p>
<p>Aangezien twee van de drie organisatoren Fronteers-bestuursleden zijn, willen we Fronteers-leden (die <em>op dit moment</em> lid zijn) een eenmalige aanbieding doen. We hebben 25 kaarten gereserveerd, die voor de early-bird prijs van 455 euro te koop zijn. Aangezien de early bird verder afgelopen is, is dit de goedkoopste manier om het congres bij te wonen — je bespaart 140 euro.</p>
<p>Dit aanbod geldt tot en met 31 januari.</p>
<p>Als je een kaartje wilt bestellen en Fronteers lid bent, kun je een kortingscode opvragen middels een mailtje naar <a href="mailto:krijn@fronteers.nl">krijn@fronteers.nl</a>.</p>
<p>We hopen minstens 25 Fronteers leden te kunnen begroeten op 12 en 13 mei.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 10 februari, in Leeuwarden</title>
<link href="https://www.fronteers.nl/nl/blog/2011/01/bijeenkomst-februari"/>
<updated>2011-01-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/01/bijeenkomst-februari</id>
<content xml:lang="nl" type="html"><p>Op 10 februari organiseert Fronteers in samenwerking met Lable een bijeenkomst over mobiele toepassingen van het web, met Jurriaan Mous over de webapplicatie voor de zorg die Lable met behulp van Google Web Toolkit ontwikkelt en Jacco de Boer, over ontwerpuitdagingen bij een mobiele nieuwsapplicatie.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>19:00 inloop</li>
<li>19:30 welkomswoord van Fronteers</li>
<li>19:35 Jurriaan Mous over het bouwen van een zorgdossier in HTML5/CSS3/GWT</li>
<li>20:30 pauze</li>
<li>20:45 Jacco de Boer over de iPad app van de Leeuwarder Courant</li>
<li>21:45 borrel</li>
</ul>
<h2>Een zorgdossier in HTML5/CSS3/GWT</h2>
<p>Lable werkt aan EZLP, een zorgdossier als webapplicatie. Deze wordt ontwikkeld samen met de verzorgers in de ouderenzorg.</p>
<p>Digitale architect Jurriaan Mous zal vertellen over de techniek achter deze webapplicatie en de lessen die zijn geleerd tijdens de ontwikkeling. Zijn talk zal gaan over het bouwen van serieuze webapplicaties in Java gecompiled naar geoptimaliseerde Javascript met behulp van Google Web Toolkit, het werken met eigengebouwde CSS compilers om browsercompatibiliteit te garanderen, het omgaan met NOSQL databases in je frontend en het bouwen van een degelijk framework voor een mooie toekomst.</p>
<h2>De mobiele krant</h2>
<p>De Leeuwarder Courant werkt aan een betaalde nieuwsapplicatie voor de iPad. Jacco de Boer gaat ons meer vertellen over de ontwerpuitdagingen en touchscreen specifieke vragen die daarbij boven komen drijven en wat werkt.</p>
<p>Aanmelden kan via het <a href="https://www.fronteers.nl/bijeenkomsten/2011/lable">aanmeldformulier</a></p>
</content>
</entry>
<entry>
<title>Fronteers zoekt vrijwilligers</title>
<link href="https://www.fronteers.nl/nl/blog/2011/01/fronteers-zoekt-vrijwilligers"/>
<updated>2011-01-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2011/01/fronteers-zoekt-vrijwilligers</id>
<content xml:lang="nl" type="html"><p>Zoals je waarschijnlijk weet, draait Fronteers geheel op vrijwilligers. Naast het werk van het bestuur en de verschillende commissies worden ook de bijeenkomsten, deze website en het congres allemaal door vrijwilligers georganiseerd en onderhouden. Alles bij elkaar een hele hoop werk, waar de huidige vrijwilligers helaas niet altijd aan toekomen. We zijn dan ook op zoek naar personen die mee willen helpen om ervoor te zorgen dat alle grootse plannen en kleine klusjes ten uitvoer gebracht kunnen worden.</p>
<p>Hieronder vind je een aantal taken waarvoor we momenteel nog mensen zoeken:</p>
<ul>
<li>Blogposts over WCAG 2 schrijven</li>
<li>Voorzitter commissie onderwijs</li>
<li>Lid commissie onderwijs (docent)</li>
<li>Bronnen voor front-end ontwikkelaars op deze site updaten</li>
<li>Cursussen organiseren</li>
<li>Examenvragen opstellen</li>
<li>Examenvragen online zetten</li>
<li>Proefexamens organiseren</li>
</ul>
<p>Meer informatie over de bovenstaande taken en de mogelijkheid om je als vrijwilliger aan te melden vind je op de pagina <a href="https://www.fronteers.nl/vereniging/vrijwilligers">vrijwilligers gezocht!</a>.</p>
</content>
</entry>
<entry>
<title>Workshop CSS Positionering op 20 januari</title>
<link href="https://www.fronteers.nl/nl/blog/2010/12/workshop-css-positionering"/>
<updated>2010-12-21T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/12/workshop-css-positionering</id>
<content xml:lang="nl" type="html"><p>Wil je het jaar goed beginnen of je CSS kennis weer eens bijspijkeren? Dan is dit je kans! Op donderdag 20 januari 2011 geeft PPK zijn <a href="https://www.fronteers.nl/workshops/css-positionering-peter-paul-koch">cursus CSS Positionering</a>. De cursus zal worden gegeven bij Seats2Meet in Utrecht op minder dan een steenworp afstand van station Utrecht Centraal.</p>
<p>Na een jaartje van stilte op cursusgebied beginnen we 2011 goed met een cursus CSS Positionering. De cursus zal gegeven worden door PPK bij Seats2Meet in Utrecht. Het is even afwachten hoe een en ander gaat bevallen bij Seats2Meet maar in principe willen we hier vanwege de centrale ligging en de beschikbare faciliteiten, ons vaste cursushonk van maken.</p>
<p>De cursus is open voor zowel leden als niet-leden. Voor <a href="https://www.fronteers.nl/leden">leden</a> bedragen de kosten €50,- en niet-leden betalen €100,- Het maximale aantal deelnemers is 12 zodat enige persoonlijke aandacht gegarandeerd kan worden. Voor dit bedrag krijg je een volledig verzorgde cursusdag van 10:00u tot 17:00u inclusief een uitgebreide lunch. Wees er daarom snel bij en <a href="https://www.fronteers.nl/workshops/css-positionering-peter-paul-koch">meld je aan</a>.</p>
<p>Het is de bedoeling om vanaf nu elke paar maanden, of vaker als daar behoefte aan is, een workshop te geven. Dit hangt uiteraard ook af van de beschikbaarheid van <a href="https://www.fronteers.nl/nl/activiteiten/workshops/#meer-informatie-voor-trainers">trainers</a>.
Voor begin 2011 hebben we in elk geval een workshop JavaScript in het verschiet. Aangezien niet iedereen JavaScript kent op hetzelfde niveau zal deze waarschijnlijk gegeven worden in een beginners, gevorderden en expert vorm. Met welke we zullen beginnen, weten we nog niet precies.</p>
</content>
</entry>
<entry>
<title>Seminar: Alles over WCAG 2.0 en Webrichtlijnen 2</title>
<link href="https://www.fronteers.nl/nl/blog/2010/12/seminar-wcag-2-en-webrichtlijnen-2"/>
<updated>2010-12-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/12/seminar-wcag-2-en-webrichtlijnen-2</id>
<content xml:lang="nl" type="html"><p>De officiële Nederlandse vertaling van WCAG en Webrichtlijnen 2 zijn (bijna) klaar. Stichting Accessibility organiseert met W3C ter gelegenheid hiervan een seminar in twee delen over de belangrijkste verschillen en verbeteringen: Wat betekenen de nieuwe richtlijnen voor uw site of voor u als bouwer. Moeten er zaken aangepast of blijft alles hetzelfde t.o.v. de huidige versies van deze documenten. Het seminar vindt plaats op vrijdag 10 december. Op beide dagdelen is apart in te schrijven. Dit seminar is een vervolg op het seminar dat we vorig jaar december hebben georganiseerd.</p>
<p>In het ochtendprogramma, dat zich vooral richt op frontend-ontwikkelaars, zal diep op de technisch-inhoudelijke kant van de nieuwe (web)richtlijnen worden ingegaan. Er zijn presentaties door diverse bij de ontwikkeling van de nieuwe norm betrokken specialisten zoals Stephen Hay, Raph de Rooij en Eric Velleman. Daarnaast zal Steven Pemberton van het W3C een presentatie geven over de geweldige mogelijkheden van XForms voor formulieren.</p>
<p>In het middagprogramma zullen vooral de beleidsmatige vraagstukken aan de orde komen, met best practice voorbeelden van webbouwers, bedrijven en gemeenten. Daarnaast zal er gesproken worden door het Ministerie van Binnenlandse zaken en is er informatie over inbedding van de nieuwe richtlijnen in het Waarmerk drempelvrij.nl.</p>
<p>Lokatie: Figi, Zeist
Kosten: € 195,00 dagdeel, € 295,00 hele dag (leden van Fronteers ontvangen 50% korting op de toegangsprijs)</p>
<p>Lees meer op <a href="http://www.accessibility.nl/internet/training/wcag20wr-seminar/">accessibility.nl/internet/training/wcag20wr-seminar/</a>.</p>
</content>
</entry>
<entry>
<title>Verslag Webrichtlijnendag 15 november in Amersfoort</title>
<link href="https://www.fronteers.nl/nl/blog/2010/11/webrichtlijnendag"/>
<updated>2010-11-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/11/webrichtlijnendag</id>
<content xml:lang="nl" type="html"><p>Op 15 november was er een &quot;terugkomdag&quot; voor gemeenten die hadden deelgenomen aan een training webrichtlijnen. Er waren presentaties, workshops en een informatiemarkt. Mijn collega-fronteer Wim van Iersel en ik waren gevraagd om onze vereniging te vertegenwoordigen.</p>
<p>De insteek van de dag was niet zozeer technisch, maar was meer gericht op projectleiders en content managers bij gemeenten die bezig zijn hun website (beter) te laten voldoen aan de webrichtlijnen.</p>
<p>Bert Mulder, lector van de Haagse Hogeschool, gaf in zijn presentatie een mooi overzicht van de ontwikkeling door de jaren heen van het gebruik van internet door de overheid. In eerste instantie was het alleen van belang voor gemeenten om 'online te zijn'. Pas later werd er beter gekeken naar de werking van deze websites en of ze wel toegankelijk waren voor een breed publiek.
Dat het niet alleen een kwestie van techniek is maar ook van content, kwam goed naar voren in een voorbeeld van een (oud) WMO-loket, waarin niet alleen het taalgebruik veel te ingewikkeld was, maar ook verschillende stromen content nogal ongelukkig naast elkaar kwamen te staan. We kregen als tip om op Youtube de filmpjes van ‘Lekker Slim’ te bekijken en de teksten daarop af te stemmen: dan begrijpt iedereen het!</p>
<p>In de eerste workshopronde was ik bij de sessie van Robert Jan Verkade en Stephen Hay over Webrichtlijnen 2. Robert Jan liet in zijn slides een foto zien met daarop een hele stapel papieren die alleen nog maar de verschillen (herformuleringen) tussen versie 1 en 2 beschreef. Hij raadde de deelnemers niet aan om deze door te lezen omdat het toch vooral technische punten zijn. Stephen voegde hier nog wel even aan toe dat deze teksten voor front-end developers wel erg interessant zijn. Dus we weten wat ons te doen staat...
De kern van het betoog was gelukkig positief: WR2 gaat verder op de principes van WR1, dus als je nu bezig bent met je site WR1 compliant te krijgen zal geen enkele moeite voor niks zijn. Versie 2 wordt flexibeler doordat bijvoorbeeld niet meer wordt vastgehouden aan stricte validatie en doctypes, maar meer aan een juist gebruik van de gekozen taal. Het gebruik van open specificaties wordt ook erg belangrijk. Daarnaast wordt tegemoetgekomen aan de webbouwers en contentbeheerders door online concrete goede en foute voorbeelden bij de richtlijnen te zetten.</p>
<p>Na de lunch en informatiemarkt woonde ik de workshop bij van Stichting Accessibility en Qualityhouse over het toetsingsproces voor 'het groene mannetje'. De heren legden vrij gedetailleerd uit hoe de keuring in zijn werk gaat. Wat duidelijk naar voren kwam, is dat je er niet bent met een eenmalige inspanning. Wanneer je het logo op je site zet, verplicht je jezelf tot een jaarlijkse - even grondige - herkeuring. Bezoekers van de site kunnen ook een klacht indienen bij de stichting Drempelvrij wanneer zij constateren dat de site niet (meer) toegankelijk is. Dit klachtenformulier zit achter het logo, waar veelvuldig op geklikt wordt (vooral bij Wehkamp), maar wat in het algemeen nog nauwelijks tot ingestuurde klachten heeft geleid. Wel krijgen ze mailtjes waarom hun bestelling nog niet is afgeleverd...</p>
<p>Afsluiter van de dag was voor mij de workshop van Simon Besters, die liet zien hoe het de gemeente Goirle gelukt was aan de webrichtlijnen te voldoen. Het was leuk om te zien hoe hij met hele concrete voorbeelden kwam over bijvoorbeeld kleurcontrast en headings en problemen waar ze tegenaan liepen tijdens het proces, zoals het omzetten van pdf's naar de toegestane A-1a variant. Qua totale manuren en geld dat erin was gestopt leek het erg mee te vallen. Het was even doorbijten om 1200 pagina's door te spitten en om te zetten, maar dan heb je ook wat! Deelnemers van grotere gemeenten keken wel wat jaloers: wij hebben duizenden pagina's....
Hoe dan ook leek me dit een zeer motiverende presentatie om zelf ook voor drie sterren te gaan.</p>
<h2>Meer informatie:</h2>
<ul>
<li><a href="http://www.webrichtlijnen.nl/actueel/de-webrichtlijnen-leven-volop-bij-gemeentes">http://www.webrichtlijnen.nl/actueel/de-webrichtlijnen-leven-volop-bij-gemeentes</a></li>
<li><a href="http://www.drempelvrij.nl/waarmerk">http://www.drempelvrij.nl/waarmerk</a></li>
<li><a href="http://www.goirle.nl/">http://www.goirle.nl/</a></li>
</ul>
</content>
</entry>
<entry>
<title>Bijeenkomst op 13 december, in Groningen</title>
<link href="https://www.fronteers.nl/nl/blog/2010/11/bijeenkomst-december"/>
<updated>2010-11-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/11/bijeenkomst-december</id>
<content xml:lang="nl" type="html"><p>Op maandag 13 december is Fronteers weer in het Noorden van het land, deze keer bij <a href="http://iwink.nl/">iWink</a> te Groningen. Peter Beverloo vertelt over Audio APIs en Simon Wisselink over front-end performance.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>19.00 inloop</li>
<li>19.25 welkomstwoord</li>
<li>19.30 Peter Beverloo over Audio APIs</li>
<li>20.30 pauze</li>
<li>20.45 Simon Wisselink over front-end performance</li>
<li>21.45 borrelen/netwerken</li>
</ul>
<h2>Audio APIs</h2>
<p>Eén van de onderwerpen waarvoor het web nog geen goed platform biedt is audio. Met de het nieuwe audio-element in HTML5 is een goede stap gezet in de richting van betere ondersteuning, maar veel verder dan afspelen gaat dit nog niet. Om dit te verbeteren zijn teams van Mozilla, Google en Apple bezig om een API te ontwerpen voor de analyse, manipulatie en creatie van geluid binnen iedere webapplicatie.</p>
<h2>Front-end performace</h2>
<p>Onderzoek heeft aangetoond dat snelle webpagina's beter scoren op conversie dan langzame webpagina's. Daarbij gaat het met name om de totale wachttijd die de gebruiker ervaart. Als Front-ender zijn er tal van dingen die je kunt doen om deze tijd te verkorten. Simon Wisselink zal in deze sessie aan de hand van een voorbeeldsite ingaan op de aanbevelingen van Yahoo (YSlow-plugin voor Firefox) en Google (Pagespeed-plugin voor Firefox) en zo laten zien hoe je de snelheid van je webpagina's gemakkelijk kunt verbeteren.</p>
<h2>Routebeschrijving</h2>
<p>De bijeenkomst wordt gehouden in Brasserie Bites in de Mediacentrale. Bites is gevestigd aan Helperpark 276A, 9723 ZA Groningen. Er is een routebeschrijving te vinden op de website van Bites.</p>
<p>Zoals altijd is de bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Geef je op, zodat we weten voor hoeveel mensen we catering nodig hebben.</p>
</content>
</entry>
<entry>
<title>Fronteers boekenclub?</title>
<link href="https://www.fronteers.nl/nl/blog/2010/11/fronteers-boekenclub"/>
<updated>2010-11-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/11/fronteers-boekenclub</id>
<content xml:lang="nl" type="html"><p>Tijdens het congres is in de wandelgangen het idee ontstaan om een inkoopactie te starten voor het nieuwe boek van Andy Clarke, <a href="http://hardboiledwebdesign.com/">Hardboiled Web Design</a>. Voordat we er echt werk van gaan maken uit te zoeken hoe we dit het best kunnen opzetten (en of het concept herbruikbaar gaat zijn voor andere boeken waar Fronteersleden mogelijkerwijs in geïnteresseerd zouden zijn) willen we graag van jullie weten hoeveel mensen hier überhaupt interesse in hebben.</p>
<p>Verder hebben we al een aantal concrete ideeën waar we graag van horen of jullie dat zien zitten:</p>
<ul>
<li>Paperback of Hardcover;</li>
<li>Extra korting voor leden van Fronteers;</li>
<li>Distributie via de meetings van Fronteers om te besparen op verzendkosten.</li>
</ul>
<p>Laat hieronder je mening horen over dit iniatief en dan gaan we op korte termijn bekijken wat er mogelijk is. Happy reading!</p>
</content>
</entry>
<entry>
<title>Meld je aan voor de Algemene Ledenvergadering 2010</title>
<link href="https://www.fronteers.nl/nl/blog/2010/11/meld-je-aan-voor-de-algemene-ledenvergadering-2010"/>
<updated>2010-11-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/11/meld-je-aan-voor-de-algemene-ledenvergadering-2010</id>
<content xml:lang="nl" type="html"><p>Woensdag 24 november a.s. houden we onze jaarlijkse algemene ledenvergadering (ALV). De ALV vindt plaats in de Haasse/Vestdijkzaal van de Openbare Bilbliotheek Amsterdam (Oosterdokskade 143, 1011 DL). De OBA is uitstekend per openbaar vervoer bereikbaar, de bibliotheek bevindt zich op loopafstand van Amsterdam Centraal Station (je kunt ook tram 26 pakken, de IJtram). We beginnen om 19.00 uur en denken maximaal twee uur nodig te hebben.</p>
<p>De agenda is als volgt:</p>
<ol>
<li>Welkom en opening door de voorzitter</li>
<li>Toelichting commissies</li>
<li>Terugblik 2010</li>
<li>Ingebrachte beleidsvoorstellen</li>
<li>Besluiten eerdere ALV’s</li>
<li>Begroting</li>
<li>Kascommissieverkiezing</li>
<li>Bestuursverkiezing</li>
<li>Rondvraag</li>
<li>Sluiting</li>
</ol>
<p>De commissievoorzitters (of hun vervangers) geven een korte toelichting op het gedane werk in het afgelopen jaar en ontvouwen hun toekomstplannen voor 2011. Natuurlijk staan zij ook open voor vragen. Verder treedt (in lijn met de statuten) bestuurslid Tom Greuter af en stelt hij zich herkiesbaar.</p>
<p>Het bestuur nodigt alle leden nadrukkelijk uit om vragen, ideeën of voorstellen in te dienen. De vereniging is van iedereen, en de koers bepalen we met zijn allen. Alles wat je kwijt wilt kun je melden via het <a href="https://www.fronteers.nl/nl/vereniging/contact/">contactformulier</a>. Duik eens in de <a href="https://www.fronteers.nl/vereniging/bestuur/notulen">notulen</a> voor inspiratie.</p>
<p>Meld je zo gauw mogelijk aan voor de ALV middels onderstaand formulier, zodat wij ons enigzins een beeld kunnen vormen van de verwachte toeloop. Je komst is niet voor niks. Ten eerste bepaal je mede de koers van Fronteers in 2011, ten tweede scoor je die exclusieve Fronteersgadget die niemand anders heeft (<em>onder voorbehoud</em>). Samen reizen met iemand? Neem even <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact</a> op met de ledenadministratie en we koppelen jullie aan elkaar.</p>
<h2>Aanmeldingen</h2>
<ol>
<li>Tom Greuter (Amsterdam, bakfiets)</li>
<li>Vasilis van Gemert (Amsterdam, fiets)</li>
<li>Peter Beverloo (Amsterdam, ov)</li>
<li>Sander Aarts (Tilburg, unknown)</li>
<li>Hidde de Vries (Utrecht, ov)</li>
<li>Rein Groot (Amsterdam, fiets)</li>
<li>Kor Dwarshuis (Amsterdam, fiets)</li>
<li>Sander van Lambalgen (Den Haag, ov)</li>
<li>Peter-Paul Koch (Amsterdam, fiets)</li>
<li>Glenn Glerum (Groningen, ov)</li>
<li>Thijs Reijgersberg (Haarlem, ov)</li>
<li>Wim van Iersel (Tilburg, ov)</li>
<li>Edwin Martin (Hilversum, ov)</li>
<li>Luc De Brouwer (Venlo, unknown)</li>
<li>Mallory (Sliedrecht, ov?) Wil graag meerijden met iemand uit de omgeving Dordrecht/Breda.</li>
<li>Justin Halsall (Amsterdam, fiets)</li>
<li>Krijn Hoetmer (Almere, ov)</li>
<li>Talbert Boef (Amsterdam, fiets)</li>
<li>Arjan Eising (Beilen, ov)</li>
<li>Matijs Brinkhuis (Utrecht, ov)</li>
<li>Elmer Bulthuis (Haarlem/Den Haag, ov)</li>
<li>En nog 1 persoon</li>
</ol>
</content>
</entry>
<entry>
<title>Vooraankondiging ALV</title>
<link href="https://www.fronteers.nl/nl/blog/2010/10/vooraankondiging-alv"/>
<updated>2010-10-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/10/vooraankondiging-alv</id>
<content xml:lang="nl" type="html"><p>Blok deze datum in je agenda! Woensdag 24 november vindt de jaarlijkse Algemene Ledenvergadering van Fronteers plaats, om 19 uur nabij station Amsterdam C.S.</p>
<p>Leden bepalen mede de koers van Fronteers. Als lid van de vereniging heb je er recht op om te weten wat we het afgelopen jaar hebben gedaan en wat onze plannen zijn voor de toekomst. Kom daarom naar de Algemene Ledenvergadering (ALV) van Fronteers.</p>
<p>We zullen stilstaan bij de activiteiten van de <a href="https://www.fronteers.nl/vereniging/commissies">commissies</a>, de begroting en de gebruikelijke stoelendans van het bestuur. Het volledige programma volgt nog.</p>
<p>Om vast warm te draaien kun je je verdiepen in de <a href="https://www.fronteers.nl/vereniging/bestuur/notulen/27-11-09">notulen van vorig jaar</a>. Als je zaken aan de orde wilt stellen, voorstellen in wilt dienen of andere goede ideeën hebt, neem dan <a href="https://www.fronteers.nl/nl/vereniging/contact/">contact op met het bestuur</a>, graag zelfs!</p>
<p>We willen rond 19.00 uur beginnen en verwachten maximaal twee uur nodig te hebben. Daarna is er natuurlijk tijd voor een (dit jaar extra bijzonder) webstandaardenbiertje!</p>
</content>
</entry>
<entry>
<title>Artikel in NRC</title>
<link href="https://www.fronteers.nl/nl/blog/2010/10/artikel-in-nrc"/>
<updated>2010-10-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/10/artikel-in-nrc</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 5 oktober <a href="http://www.readwriteweb.com/archives/internet_explorer_drops_below_50_market_share_worl.php">werd</a> <a href="http://www.zeldman.com/2010/10/07/no-comment/">bekend</a> dat Internet Explorer wereldwijd tot onder de 50% martkaandeel is gezakt — als we althans <a href="http://gs.statcounter.com/">StatCounter</a> mogen geloven (wat ikzelf op dit moment doe). (<a href="http://gs.statcounter.com/#browser-NL-monthly-200809-201010">In Nederland</a> is dat aandeel overigens nog 64%.)</p>
<p><a href="http://nl.linkedin.com/in/march">Marc Hijink</a> van <a href="http://nrc.nl/">NRC Handelsblad</a> pikte dit nieuwtje op, zag in dat hij achtergrondinformatie miste, ging naar <a href="https://www.fronteers.nl/congres/2010">Fronteers 2010</a> en schoot daar de keynote spreker van dag 1, <a href="http://adactio.com/">Jeremy Keith</a>, aan voor nadere uitleg.</p>
<p>Jeremy kweet zich overtuigend van zijn taak en het resultaat is een uiterst helder stuk in het NRC van zaterdag 9 oktober, waar de browsersituatie correct in staat beschreven, alle vijf browsers behandeld worden, en ook aandacht wordt besteed aan progressive enhancement op mobiel en de videoformaatoorlog. Ook Fronteers wordt expliciet genoemd.</p>
<p>Voor zover ik weet is dit de eerste keer dat de ideeën van webontwikkelaars zo veel aandacht krijgen in de Nederlandse pers.</p>
<p>Jammer blijft natuurlijk dat het artikel online niet te vinden is. Oude media, zullen we maar zeggen. Gelukkig is er wel een <a href="http://cl.ly/1d8f6b531a10e8b7e665">scan</a> beschikbaar.</p>
<p>Mocht iemand zich geroepen voelen het in het Engels te vertalen, dan zou Jeremy daar blij mee zijn.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 4 november in Gent (België)</title>
<link href="https://www.fronteers.nl/nl/blog/2010/09/bijeenkomst-netlog"/>
<updated>2010-09-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/09/bijeenkomst-netlog</id>
<content xml:lang="nl" type="html"><p>Op donderdag 4 november is Fronteers te gast bij Netlog in Gent (jawel, in België!). Er worden twee presentaties voorzien. Eerst komt <a href="http://www.quirksmode.org/about/">Peter-Paul Koch</a> (PPK) praten over <em>mobile web development</em>; vervolgens vertelt <a href="http://lensco.be/">Lennart Schoors</a> wat over <em>web design for right-to-left languages</em>.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:00 ontvangst met broodjes en een drankje</li>
<li>19:00 Peter-Paul Koch over <em>mobile web development</em></li>
<li>20:00 Lennart Schoors over <em>web design for right-to-left languages</em></li>
<li>21:00 naborrelen</li>
</ul>
<h2>Routebeschrijving</h2>
<p>Netlog NV is gevestigd aan het Emile Braunplein 18, 9000 Gent. Er is een plannetje beschikbaar op <a href="https://www.fronteers.nl/bijeenkomsten/2010/netlog">de detailpagina van deze bijeenkomst</a>.</p>
<h2>Kom jij ook?</h2>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 50 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Verslag actieve ledenuitje 2010</title>
<link href="https://www.fronteers.nl/nl/blog/2010/09/verslag-actieve-ledenuitje-2010"/>
<updated>2010-09-21T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/09/verslag-actieve-ledenuitje-2010</id>
<content xml:lang="nl" type="html"><p>Zaterdag 11 september hebben de actieve leden van Fronteers gezeild over het Markermeer. Actieve leden zijn leden die in een of meer commissies zitten. We hebben met z'n vijftienen een gezellige dag gehad, met als afsluiting een lekkere barbecue.</p>
<p>Na rond 13 uur af te hebben gesproken met elkaar bij Café de Pont, aan de overkant van het IJ bij Amsterdam Centraal, gingen we met drie auto's naar Muiden. Daar wachtten enkele leden die met het OV kwamen op de boot. Na kennis gemaakt te hebben met de schipper en zijn hulpen, voeren we af richting het Noorden van het Markermeer.</p>
<p>Onderweg zagen we onder andere het Muizenfort, en we voeren langs het eiland Pampus. De schipper wist een en ander te vertellen over de historie van het gebied. Ondertussen mochten enkele leden hard meehelpen om de zeilen te hijsen.</p>
<p>We hadden uitstekend weer. Er stond genoeg wind uit het zuidoosten, en de zon zorgde ervoor dat we in een t-shirt konden genieten van de oer-Nederlandse wateren. We sloten de dag af met een barbecue.</p>
<p><img src="https://www.fronteers.nl/_img/2010/09/actieve-leden-uitje.jpg" alt="Enkele leden hard aan het werk om de zeilen te heisen." /></p>
<p>Onder andere <a href="http://picasaweb.google.nl/100182639623410231517/FronteersVrijwilligersdag2010">Edwin Martin</a>, <a href="http://www.flickr.com/photos/tomgreuter/tags/fronteerszeilen2010/">Tom Greuter</a> en <a href="http://www.flickr.com/photos/arjaneising/sets/72157624981868442/">ondergetekende</a> hebben foto's gemaakt. Bovenstaande foto is gemaakt door Edwin Martin.</p>
<p>Als je volgend jaar ook bij het ledenuitje wilt zijn, dan kun je actiever worden binnen Fronteers. We zoeken onder andere leden die in de commissie Diplomering en Onderwijs willen zetelen. Ook het opzetten van iets nieuws ondersteunen we van harte!</p>
</content>
</entry>
<entry>
<title>'Fronteers 2010: We gaan (weer) uitverkopen!'</title>
<link href="https://www.fronteers.nl/nl/blog/2010/09/fronteers-2010-gaat-uitverkopen"/>
<updated>2010-09-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/09/fronteers-2010-gaat-uitverkopen</id>
<content xml:lang="nl" type="html"><p>Nog maar <em>twee weken</em> en dan is het eindelijk zover. Fronteers 2010 belooft weer een succes te worden! Hieronder de laatste update vanuit de commissie.</p>
<h2>Laatste sprekers bekend</h2>
<p>Via <a href="https://twitter.com/FronteersConf/status/23903002230">Twitter</a> hebben we een tijdje terug de laatste vier sprekers van dit jaar toegevoegd. <a href="https://www.fronteers.nl/congres/2010/speakers#stephen-hay"><em>Stephen Hay</em></a> en <a href="https://www.fronteers.nl/congres/2010/speakers#christian-heilmann"><em>Chris Heilmann</em></a>, bekend van de afgelopen twee jaar, komen weer terug om hun visitekaartje af te geven. Stephen zal ons vertellen over <a href="https://www.fronteers.nl/congres/2010/sessions#real-world-responsive-design">Real-world Responsive Design</a> en Chris heeft iets bijzonders voor ons in petto als afsluiting van het congres.</p>
<p>Naast deze twee oudgedienden van Fronteers hebben we <a href="https://www.fronteers.nl/congres/2010/speakers#paul-irish"><em>Paul Irish</em></a> en <a href="https://www.fronteers.nl/congres/2010/speakers/#robert-nyman"><em>Robert Nyman</em></a> aan de haak geslagen! Robert zal ons met <a href="https://www.fronteers.nl/congres/2010/sessions#javascript-like-a-box-of-chocolates">JavaScript - Like a box of chocolates</a> een introductie geven in JavaScript en alle niet-JavaScripters in de zaal laten zien waarom ze toch de stap zouden moeten overwegen. Paul gaat met <a href="https://www.fronteers.nl/congres/2010/sessions#the-state-of-html5-inaugural-address">The State of HTML5: Inaugural Address</a> laten zien hoe je HTML5 <em>nu</em> optimaal kunt gebruiken.</p>
<h2>Sprekerswissel</h2>
<p>Helaas heeft Jeff Croft aangegeven dat hij het dit jaar niet redt om naar Amsterdam te komen. Gelukkig hebben we <a href="https://www.fronteers.nl/congres/2010/speakers#meagan-fisher">Meagan Fisher</a> op het laatste moment bereid gevonden om zijn plaats in te nemen en ons te verblijden met haar komst. Haar onderwerp is nog niet helemaal bekend, maar je kunt een visueel spektakel verwachten waarbij de natuur en CSS bij elkaar gebracht worden.</p>
<h2>Workshop &quot;Bringing Your Design to Life with CSS3&quot; door Dan Rubin</h2>
<p>De <a href="https://www.fronteers.nl/congres/2010/workshops/css3-dan-rubin">CSS3 workshop van Dan Rubin</a>, op dinsdag 5 oktober in Felix Meritis, heeft ondertussen 21 bezoekers getrokken. Hiervoor zijn dus nog een aantal plaatsen beschikbaar. Ken je nog een designer die je graag wat meer over de (on)mogelijkheden van CSS wilt laten weten, stuur hem of haar dan naar deze workshop.</p>
<h2>Programma bekend</h2>
<p>Ook <a href="https://www.fronteers.nl/congres/2010/schedule">het programma</a> is vorige week bekendgemaakt. Vanaf deze week zullen we de eendagsbezoekers benaderen om hun keuze door te geven (als je dit leest en je weet al welke dag je wilt komen, <a href="https://www.fronteers.nl/congres/2010/contact">laat het ons dan weten alsjeblieft</a>). Er kunnen nog kleine wijzigingen plaatsvinden in het programma, dus hou het programma in de gaten.</p>
<h2>Bijna uitverkocht</h2>
<p>Op dit moment hebben we <a href="https://www.fronteers.nl/congres/2010/attendees">410 bezoekers</a>(!) op de teller staan en we verwachten in de komende week de laatste 40 kaartjes te verkopen. Aan iedereen die dus nog zit te twijfelen (we kunnen ons totaal niet voorstellen waarom, maar oke): maak snel je keuze!</p>
<h2>Sluiting kaartverkoop op 29 september</h2>
<p>Een andere reden om snel te beslissen is dat de kaartverkoop voor het congres op <em>woensdag 29 september om 12 uur 's middags sluit</em>. Of eerder, indien we voor die tijd de 450 namen al bereikt hebben. Hierdoor hebben de vrijwilligers die achter de schermen zwetend zwoegen om alles rond te krijgen nog een week de tijd om alles met een definitieve bezoekerslijst klaar te maken. Iedereen die na deze datum nog binnen probeert te komen, kan een kille &quot;Nee&quot; verwachten. Hopelijk hiervoor jullie begrip.</p>
<p>Het aftellen is begonnen, fijne meevallers zullen zich aandienen en ook minieme tegenslagen zullen we met open armen ontvangen. Net als alle 450 front-end developers uit binnen- en buitenland die op 7 en 8 oktober de Reguliersbreestraat in Amsterdam gaan vullen.</p>
<p>Tot dan!</p>
<p>Aaron, Edwin, Hidde, Justin, Kilian, Krijn, Peter B., Peter S., Peter vd Z., Thijs, Vasilis en Wes</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 7 september, in Haarlem</title>
<link href="https://www.fronteers.nl/nl/blog/2010/08/bijeenkomst-september"/>
<updated>2010-08-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/08/bijeenkomst-september</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 7 september is Fronteers te gast bij <a href="http://iprofs.nl/">IPROFS</a> in Haarlem. Er zullen twee presentaties gegeven worden: Wilfred Nas gaat een praatje houden over HTML5 best practices, en Raph de Rooij update ons over de laatste ontwikkelingen rond Webrichtlijnen versie 2.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18:30 inloop (drinken/borrelhapjes)</li>
<li>19:20 welkomstwoord: Remco Nabuurs</li>
<li>19:30 eerste spreker: Wilfred Nas</li>
<li>20:15 cq. 20:30 korte pauze (drinken/borrelhapjes)</li>
<li>20:30 cq. 20:45 tweede spreker: Raph de Rooij</li>
<li>21:15 cq. 21:30 ruimte voor vragen/discussie aan/met webrichtlijnen team</li>
<li>21.30 Borrelen/netwerken</li>
</ul>
<h2>HTML5 en formulieren ( en andere niet sexy zaken )</h2>
<p>De laatste jaren wordt er een hype gebouwd om HTML5 en dan met name om de 'sexy' elementen als <code>video</code>, <code>canvas</code> en SVG. Zelfs CSS3 wordt in deze hype meegenomen. Zonde, aangezien er een boel nuttige elementen zijn die je nu kunt gebruiken in je werk, attributen als placeholder en elementen als <code>input type=&quot;email&quot;</code> zijn nu al te gebruiken. Ik belicht wat zaken die ondergesneeuwd zijn en die je werk vandaag makkelijker kunnen maken.</p>
<h2>Routebeschrijving</h2>
<p>IPROFS is gevestigd aan de Claus Sluterweg 125, 2012 WS Haarlem. Er is een routebeschrijving beschikbaar op de site van IPROFS.</p>
<p>Zoals altijd is deze bijeenkosmt gratis toegankelijk voor zowel leden als niet-leden. Er is echter beperkt plaats, voor circa 45 mannen en vrouwen.</p>
</content>
</entry>
<entry>
<title>Donderdag 2 september zomerborrel in Antwerpen</title>
<link href="https://www.fronteers.nl/nl/blog/2010/08/zomerborrel-antwerpen"/>
<updated>2010-08-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/08/zomerborrel-antwerpen</id>
<content xml:lang="nl" type="html"><p>Nu we ook Belgische front-end ontwikkelaars als lid krijgen, is het hoog tijd een zomerborrel in België te beleggen. Een datum is geprikt: 2 september gaan we in samenwerking met <a href="http://twoooze.be/">Twoooze</a> borrelen bij de Cargo Zomerbar.</p>
<p>De Cargo Zomerbar is gevestigd aan de <a href="http://maps.google.com/?q=Viaduct+Dam+1%2C+2060+Antwerpen+%28cargo+zomerbar%29">Viaduct Dam 1, 2060 te Antwerpen</a>. Vanaf 18 uur ben je welkom om bier, wijn of iets anders te drinken. Het eerste rondje wordt door Fronteers gesponsord. Geef even door dat je komt, door hier—inclusief je Twitter gebruikersnaam—een reactie te plaatsen, of door een @reply te sturen aan <a href="https://twitter.com/twoooze">Twoooze</a>.</p>
</content>
</entry>
<entry>
<title>Fronteers bereikt de 300 leden</title>
<link href="https://www.fronteers.nl/nl/blog/2010/08/300-leden"/>
<updated>2010-08-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/08/300-leden</id>
<content xml:lang="nl" type="html"><p>Sinds gisteren telt Fronteers meer dan <a href="https://www.fronteers.nl/leden">300 leden</a>! Precies een jaar geleden begonnen we met het schrijven van deze post, die toen 'Fronteers bereikt de 200 leden' getiteld was. Blijkbaar gaat het hard. Wow!</p>
<p>Leuk en aardig dat gesmijt met getallen, maar wat doet Fronteers nou eigenlijk? Het grote probleem van onze vereniging is nog steeds dat we draaien op een relatief klein clubje actieve vrijwilligers, dat ook nog eens erg druk is met werk. Dingen gaan dus langzaam. Maar er gebeurt wel wat.</p>
<p>De <a href="https://www.fronteers.nl/vereniging/commissies/onderwijs">Commissie Onderwijs</a> is bezig met de volgende docentendag, <a href="https://www.fronteers.nl/vereniging/commissies/workshops">workshops</a> komen eraan, ons jaarlijks <a href="https://www.fronteers.nl/vereniging/commissies/congres">congres</a> lijkt weer een succesje te worden, we hebben invloed op de <a href="https://www.fronteers.nl/vereniging/commissies/webrichtlijnen">Webrichtlijnen</a> en de maandelijkse <a href="https://www.fronteers.nl/bijeenkomsten">bijeenkomsten</a> lopen gestaag door. Op <a href="http://www.linkedin.com/groups?gid=38840">LinkedIn</a> kunnen leden voorlopig terecht met vragen aan andere leden (totdat we <a href="https://www.fronteers.nl/vereniging/commissies/online-community">een eigen forum</a> hebben), en op <a href="http://webchat.freenode.net/?channels=fronteers">IRC</a> wordt het ook steeds drukker.</p>
<p>Qua vacatures zit het ook wel goed. Ondertussen hebben we, sinds de <a href="https://www.fronteers.nl/blog/2008/11/lancering-vacaturebank">lancering</a> eind 2008, 87 vacatures geplaatst. Front-end web development lijkt dus een gevestigde discipline te zijn in Nederland.</p>
<p>Al die vacatures zorgen voor aardig wat geld in het laatje. Daarom hebben we als bestuur besloten om alle actieve vrijwilligers te bedanken met een dagje op het water, begin september. Een verslag van deze dag volgt zeer waarschijnlijk nog op de website.</p>
<p>Peter-Paul, Tom, Arjan, Sander, Krijn, Matijs, Niels, Wybe, Justin, Martin, Yvonne, Mio, Sander, Kilian, Wilfred, Sander, Kor, Tom-Eric, Glenn, Peter, Edwin, Vasilis, Wes, Hidde, Peter, Bart, Wim, Anne, Nikolai, Marcel en alle vrijwilligers die geholpen hebben rondom de organisatie van de bijeenkomsten: bedankt voor de tijd die jullie in Fronteers steken!</p>
<p>Om de 300 leden te vieren, houden we volgende week woensdag, 18 augustus vanaf een uurtje of 18, weer een borrel bij <a href="http://maps.google.nl/maps?f=q&amp;source=s_q&amp;hl=nl&amp;geocode=&amp;q=winkel+van+sinkel+utrecht&amp;sll=52.469397,5.509644&amp;sspn=3.654648,9.766846&amp;ie=UTF8&amp;hq=Winkel+van+Sinkel&amp;hnear=Winkel+van+Sinkel,+3512+Utrecht&amp;ll=52.095486,5.118599&amp;spn=0.027472,0.076303&amp;z=14&amp;iwloc=A">De Winkel van Sinkel</a> in Utrecht. Ben jij er ook bij?</p>
</content>
</entry>
<entry>
<title>'Fronteers 2010: nog maar twee maanden! En nu al 300 aanmeldingen!'</title>
<link href="https://www.fronteers.nl/nl/blog/2010/08/fronteers-2010-nog-twee-maanden"/>
<updated>2010-08-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/08/fronteers-2010-nog-twee-maanden</id>
<content xml:lang="nl" type="html"><p>Over twee maanden, op 5, 6, 7 en 8 oktober, zal <a href="https://www.fronteers.nl/congres/2010">Fronteers 2010</a> plaatsvinden in <a href="https://www.fronteers.nl/congres/2010/venue">Pathé Tuschinski in Amsterdam</a>. Ondertussen hebben we <a href="https://www.fronteers.nl/congres/2010/attendees">300 bezoekers</a> op de teller staan: een evenaring van het aantal van <a href="https://www.fronteers.nl/congres/2009/attendees">vorig jaar</a> en bijna twee keer zoveel sinds onze <a href="https://www.fronteers.nl/blog/2010/06/fronteers-2010-einde-early-bird">vorige aankondiging</a>. Vandaag komen we aanzetten met twee nieuwe sprekers en maken we de eerste sessies bekend.</p>
<h2>Sprekers</h2>
<p><em><a href="https://www.fronteers.nl/congres/2010/speakers#jake-archibald">Jake Archibald</a></em>, een van de grappigste sprekers die toevallig ook nog eens veel verstand heeft van JavaScript, zal ons komen vertellen hoe je herbruikbare JavaScript opzet. Als front-end developer bij de BBC en mede-auteur van de <a href="http://www.bbc.co.uk/glow/">Glow Javascript Library</a> heeft hij hier een duidelijke mening over.</p>
<p><em><a href="https://www.fronteers.nl/congres/2010/speakers#stoyan-stefanov">Stoyan Stefanov</a></em> zal ons op de hoogte brengen van de laatste stand van zaken rondom client-side performance, een onderwerp dat nog steeds erg relevant is.</p>
<p>De komende tijd hebben jullie nog <em>vier</em> sprekers van ons te goed. Je kunt onderwerpen verwachten als geavanceerde CSS, JavaScript voor beginners, HTML5 awesomeness en een pleidooi over waarom wij front-enders het mooiste beroep ter wereld hebben.</p>
<h2>Sessies</h2>
<p>De <a href="https://www.fronteers.nl/congres/2010/sessions">eerste vier onderwerpen</a> zijn zojuist ook online gezet: <em>The Design of HTML5</em>, <em>High Performance JavaScript</em>, <em>Vector Graphics for the Web</em> en <em>Reusable Code, for good or for awesome!</em>. De overige sessies zullen in de komende tijd online worden gezet, zodra we de details ontvangen van onze sprekers.</p>
<h2>Sponsoring</h2>
<p>We zijn nog steeds op zoek naar <a href="https://www.fronteers.nl/congres/2010/sponsorships">enkele sponsoren</a>. Mocht je geïnteresseerd zijn of nog steeds vinden dat je baas hier écht bij moet zijn, <a href="https://www.fronteers.nl/congres/2010/contact">laat het ons dan weten</a> en je gaat als VIP mee naar het sprekersdiner op woensdag.</p>
<h2>Volg ons op Twitter</h2>
<p>Via <a href="https://twitter.com/FronteersConf">@FronteersConf</a> proberen we iedereen op de hoogte te houden van lopende zaken. Heb je vragen of opmerkingen? Laat dan wat van je horen!</p>
<h2>Tot in oktober!</h2>
<p><a href="https://twitter.com/edwinm">Edwin</a>, <a href="https://twitter.com/kilianvalkhof">Kilian</a>, <a href="https://twitter.com/krijnhoetmer">Krijn</a>, <a href="https://twitter.com/pesla">Peter</a> en <a href="https://twitter.com/vasilis">Vasilis</a></p>
</content>
</entry>
<entry>
<title>Fronteers zomerborrel (en hap) #2 (wederom) a.s. woensdag</title>
<link href="https://www.fronteers.nl/nl/blog/2010/07/zomerborrel-deel-2"/>
<updated>2010-07-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/07/zomerborrel-deel-2</id>
<content xml:lang="nl" type="html"><p>Omdat we er geen genoeg van kunnen krijgen (en jullie waarschijnlijk ook niet) gaan we weer met z'n allen wat eten (en drinken!) in Utrecht. Dit keer in <a href="http://maps.google.nl/maps?f=q&amp;source=s_q&amp;hl=nl&amp;geocode=&amp;q=Kafe+Belgi%C3%AB,+Utrecht&amp;sll=52.095486,5.118599&amp;sspn=0.035065,0.090895&amp;ie=UTF8&amp;hq=Kafe+Belgi%C3%AB,&amp;hnear=Utrecht&amp;t=h&amp;z=16&amp;iwloc=A">Kafé België</a>.</p>
<p>Het eerste rondje is van Fronteers en de tweede van Matijs. Laat even weten of je komt in de reacties. Tot dan!</p>
</content>
</entry>
<entry>
<title>Publieke review Webrichtlijnen versie 2</title>
<link href="https://www.fronteers.nl/nl/blog/2010/07/publieke-review-webrichtlijnen-2"/>
<updated>2010-07-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/07/publieke-review-webrichtlijnen-2</id>
<content xml:lang="nl" type="html"><p>Iedereen die affiniteit heeft met de Webrichtlijnen kan tijdens de publieke review van versie 2 tot en met 13 september 2010 een reactie geven op (onderdelen van) de Webrichtlijnen. Heb je dus wat tijd over? Neem dan even een kijkje op <a href="http://review.wrv2.nl/">http://review.wrv2.nl/</a>, waar goed uitgelegd wordt hoe je mee kunt helpen.</p>
<p>Benieuwd naar wat er zoal veranderen gaat? Lees dan de <a href="http://review.wrv2.nl/mapping/">mapping tussen Webrichtlijnen versie 1 en versie 2</a>.</p>
<p>Als je specifieke opmerkingen hebt, stuur die dan op de <a href="http://review.wrv2.nl/#procedure">juiste manier</a> in, maar wat vinden jullie in het algemeen van de nieuwe opzet van de Webrichtlijnen? Gaat dit merkbare invloed hebben op je werk?</p>
</content>
</entry>
<entry>
<title>Fronteers zomerborrel a.s woensdag</title>
<link href="https://www.fronteers.nl/nl/blog/2010/07/zomerborrel"/>
<updated>2010-07-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/07/zomerborrel</id>
<content xml:lang="nl" type="html"><p>Om deze warme dagen enigszins leuk te houden ben je hierbij uitgenodigd om aanstaande woensdag (14 juli) een gezellig biertje te komen drinken bij De Winkel van Sinkel in Utrecht. Vanaf een uur of zes staat het bier koud!</p>
<p>De Winkel van Sinkel ligt <a href="http://maps.google.nl/maps?f=q&amp;source=s_q&amp;hl=nl&amp;geocode=&amp;q=winkel+van+sinkel+utrecht&amp;sll=52.469397,5.509644&amp;sspn=3.654648,9.766846&amp;ie=UTF8&amp;hq=Winkel+van+Sinkel&amp;hnear=Winkel+van+Sinkel,+3512+Utrecht&amp;ll=52.095486,5.118599&amp;spn=0.027472,0.076303&amp;z=14&amp;iwloc=A">aan de Oudegracht</a> op loopafstand van Utrecht CS.</p>
<p>Het eerste rondje is van Fronteers. Je kunt in de reacties laten weten of je komt.</p>
</content>
</entry>
<entry>
<title>'Fronteers 2010: drie nieuwe sprekers, de tweede workshop en einde early-bird'</title>
<link href="https://www.fronteers.nl/nl/blog/2010/06/fronteers-2010-einde-early-bird"/>
<updated>2010-06-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/06/fronteers-2010-einde-early-bird</id>
<content xml:lang="nl" type="html"><p>Vandaag kondigen we drie nieuwe sprekers aan, maken we meer bekend over de tweede workshop die we aanbieden en tellen we af naar het einde van de early-bird periode, die nog slechts een week zal duren. Ondertussen hebben <a href="https://www.fronteers.nl/congres/2010/attendees">--140--<strong>167</strong> front-end developers</a> uit binnen- en buitenland de weg naar een kaartje al gevonden. Wellicht ben jij de volgende?</p>
<h2>Sprekers</h2>
<p>Zo net voor het einde van de early-bird periode willen we graag nog drie sprekers met jullie delen. We hadden hem vorig jaar al benaderd voor een presentatie, maar toen kon hij helaas niet. Dit jaar is hij echter wel van de partij. <em><a href="https://www.fronteers.nl/congres/2010/speakers#brad-neuberg">Brad Neuberg</a></em> zal ons komen vertellen over SVG, de mogelijkheden in combinatie met HTML5 en een gaaf project waar hij op dit moment mee bezig is, waardoor ook huidige IE-versies gewoon SVG slikken. We verwachten dat SVG de komende jaren een stuk belangrijker gaat worden voor front-end developers, zeker gezien het feit dat IE9 SVG gaat ondersteunen en Apple steeds meer anti-Flash wordt. Deze trein mag je dus zeker niet missen!</p>
<p>Een ander hekel puntje in <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/">HTML5</a> is toegankelijkheid. We zijn er iedere dag mee bezig, onder het mom van de Webrichtlijnen of gewoon omdat we het een belangrijk onderdeel van ons werk vinden. <em><a href="https://www.fronteers.nl/congres/2010/speakers#steve-faulkner">Steve Faulkner</a></em> en <em><a href="https://www.fronteers.nl/congres/2010/speakers#hans-hillen">Hans Hillen</a></em> zullen daarom een duo-presentatie geven over hoe je HTML5 op de juiste, toegankelijke manier gebruikt, en waar nodig met ARIA verrijkt. <em>Built-in</em> en <em>bolt-on</em> accessibility dus. Als je denkt dat HTML5 toegankelijkheid overboord gooit en alleen voor de buzzword bingo bonuspunten gaat, heb je het mis. Kom naar Fronteers 2010! :)</p>
<p>De overige <em>zes</em> namen zullen we in de komende maanden bekendmaken.</p>
<h2>Workshop &quot;Bringing Your Design to Life with CSS3&quot; door Dan Rubin</h2>
<p>De <a href="https://www.fronteers.nl/congres/2010/workshops/css3-dan-rubin">tweede workshop</a> zal plaatsvinden op dinsdag 5 oktober, in Felix Meritis. Deze workshop is voornamelijk gericht op designers, die graag ook zelf de (on)mogelijkheden van CSS willen leren kennen. Waar de <a href="https://www.fronteers.nl/congres/2010/workshops/advanced-css-andy-clarke">workshop van Andy</a> zich dus vooral focust op coders die graag alle geavanceerde snufjes van CSS willen leren, kun je bij Dan terecht als je als webdesigner wil weten wat er tegenwoordig allemaal kan met HTML en CSS.</p>
<p>Heb jij een collega-designer die PSD's &quot;over de muur gooit&quot;, maar stiekem toch ook over die muur meekijkt en het best interessant vindt wat er in de browser allemaal mogelijk is, dan is deze workshop zeker aan te bevelen.</p>
<h2>Einde van de early-bird periode: volgende week</h2>
<p>Zoals we vorige maand al aankondigden, zal de early-bird periode eind juni aflopen; <em>volgende week woensdag</em> dus. We hebben ondertussen al <a href="https://www.fronteers.nl/congres/2010/attendees">zo'n <strike>140</strike> <strong>170</strong> bezoekers</a> op de lijst staan en we verwachten in deze laatste week nog heel wat kaartjes te verkopen. Wacht dus niet langer en <a href="https://www.fronteers.nl/congres/2010/tickets">koop je ticket nu!</a> :)</p>
<p>Alle Fronteersleden krijgen vrijdag ook nog een herinnering met de kortingscode in hun inbox. We nemen aan dat we hiermee iedereen genoeg informatie en tijd hebben gegeven om hun keuze te maken. Na de early-bird zal de prijs van een toegangskaartje waarschijnlijk met € 100,- omhoog gaan.</p>
<h2>Sponsoring</h2>
<p>We zijn nog steeds op zoek naar <a href="https://www.fronteers.nl/congres/2010/sponsorships">enkele sponsoren</a>. Mocht je geïnteresseerd zijn of nog steeds vinden dat je baas hier écht bij moet zijn, <a href="https://www.fronteers.nl/congres/2010/contact">laat het ons dan weten</a> en je gaat als VIP mee naar het sprekersdiner op woensdag.</p>
<h2>Volg ons op Twitter</h2>
<p>Via <a href="https://twitter.com/FronteersConf">@FronteersConf</a> proberen we iedereen op de hoogte te houden van lopende zaken. Heb je vragen of opmerkingen? Laat dan wat van je horen!</p>
<h2>Tot in oktober!</h2>
<p>Alle sprekers zijn super enthousiast, de catering wordt om van te watertanden, de techniek wordt tot in de puntjes verzorgd, videomateriaal van alles sessies wordt van hoge kwaliteit, het hotel voor de sprekers is geregeld, onze MC is zich al aan het voorbereiden (dank <a href="https://twitter.com/juice10">Justin</a>!) en een blik extra vrijwilligers staat klaar om zich uit de naad te werken op de dagen zelf (dank <a href="https://twitter.com/hdv">Hidde</a>, <a href="https://twitter.com/beverloo">Peter</a>, <a href="https://twitter.com/ysbreker">Thijs</a>, <a href="https://twitter.com/kuvos">Peter</a>, <a href="https://twitter.com/wesoudshoorn">Wes</a> en <a href="https://twitter.com/aaronpeters">Aaron</a>!). Kortom, wij hebben er zin in! En we hopen jullie ook!</p>
<p><a href="https://twitter.com/edwinm">Edwin</a>, <a href="https://twitter.com/kilianvalkhof">Kilian</a>, <a href="https://twitter.com/krijnhoetmer">Krijn</a>, <a href="https://twitter.com/pesla">Peter</a> en <a href="https://twitter.com/vasilis">Vasilis</a></p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 7 juli, in Rotterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2010/06/bijeenkomst-juli"/>
<updated>2010-06-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/06/bijeenkomst-juli</id>
<content xml:lang="nl" type="html"><p>Op woensdag 7 juli is Fronteers te gast bij <a href="http://mangrove.nl/">Mangrove</a> in Rotterdam. Thema van deze avond is design. Bram van Rijen a.k.a. Nozzman zal spreken over inspiratie, en Hans Kemp zal dieper ingaan op het onderwerp interaction design.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>19:00 inloop</li>
<li>19:30 introductie Mangrove</li>
<li>19:45 Bram van Rijen a.k.a. Nozzman (Mangrove)</li>
<li>20:30 korte pauze</li>
<li>20:45 Hans Kemp (Hogeschool Rotterdam)</li>
<li>21:30 borrel</li>
</ul>
<h2>Inspiratie</h2>
<p>Inspiratie. Je kunt er op gaan zitten wachten, maar meestal komt het dan juist niet. Inspiratie komt niet zomaar uit de lucht vallen. Terwijl dat blanco canvas voor je toch echt snel voorzien moet worden van een fijn design of bevlogen code. Tóch zijn er manieren om de inspiratie op gang te krijgen. Hoe? Dat legt Bram van Rijen a.k.a. <a href="http://nozzman.nl/">Nozzman</a> uit in een sessie die niet zozeer inspireert, maar hopelijk wel inspiratie gaat veroorzaken. Bram is art-director bij Mangrove en is tevens actief als illustrator, cartoonist en kunstenaar.</p>
<h2>Interaction design uitgelicht</h2>
<p>De rol van de user experience designer is niet altijd even duidelijk. Bij 'design' denken veel mensen eigenlijk vooral aan het bedenken van een logo of het maken van een huisstijl. Terwijl de user experience designer juist veel eerder in het proces het verschil maakt. In dit verhaal wil ik aan de hand van een aantal voorbeelden en 'design principles' laten zien hoe je als user experience designer dit verschil kunt maken. Door inspiratie, en vooral door vele meters te maken.</p>
<h2>Routebeschrijving</h2>
<p>Mangrove ligt op een steenworp afstand van station Rotterdam Centraal, aan de Delftsestraat 33. Er staat een <a href="http://www.mangrove.nl/index.php?pageID=6">korte routebeschrijving</a> op de website van Mangrove.</p>
<p>De bijeenkomst is gratis toegankelijk voor zowel leden als niet-leden. Het is wenselijk dat je je even opgeeft, dan weet de organisatie hoeveel personen er komen.</p>
</content>
</entry>
<entry>
<title>Grip2010, 25 euro korting voor jouw opdrachtgever</title>
<link href="https://www.fronteers.nl/nl/blog/2010/05/grip2010"/>
<updated>2010-05-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/05/grip2010</id>
<content xml:lang="nl" type="html"><p>Op 22 en 23 juni 2010 wordt in Grand Hotel Karel V te Utrecht een tweedaagse workshop voor opdrachtgevers van webprojecten gegeven: <a href="http://grip2010.nl/">Grip2010</a>. Heb jij een leuke opdrachtgever of werkgever die inmiddels 1-3 jaar webprojecten leidt? Dan is de workshop echt iets voor hem of haar.</p>
<p>Het hele traject van een internetproject komt aan bod. Van offerte tot afronding. Vorig jaar waren <a href="http://www.grip2010.nl/over/#ervaringen">de reacties op de workshop heel goed</a>, dus je kunt je opdrachtgever gerust op de workshop attenderen.</p>
<p>Als lid van Fronteers kun je de kortingscode &quot;fronteers&quot; geven en dan krijgt je opdrachtgever 25 euro korting bij de aanmelding.</p>
</content>
</entry>
<entry>
<title>Hack de Overheid</title>
<link href="https://www.fronteers.nl/nl/blog/2010/05/hack-de-overheid"/>
<updated>2010-05-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/05/hack-de-overheid</id>
<content xml:lang="nl" type="html"><p>Wij ontvingen een berichtje van onze vrienden van <a href="http://www.hackdeoverheid.nl/">HackDeOverheid</a>. Wie? &quot;HackdeOverheid wil geeks en ambtenaren een ruimte bieden om een dialoog rond technologische innovatie, maatschappelijke verandering, overheidsdiensten en politieke transparantie mogelijk te maken.&quot; Wat? Gewoon lekker spelen met open data!</p>
<p>HackdeOverheid houdt aanstaande zaterdag 29 mei haar tweede editie. Dan gaan burgers, geeks, journalisten en overheid samen aan ideeën en protoypen werken op basis van overheidsdata. Mooie voorbeelden van het hergebruiken van open overheidsdata zijn <a href="http://www.openkvk.nl/">OpenKvk</a> die KvK informatie makkelijker ontsluit en <a href="http://www.ikregeer.nl/">Ikregeer</a> dat Tweede Kamerstukken toegankelijker maakt.</p>
<p>Dus als je zin hebt in een dagje data-pitchen, barcampen en wobben, meld je dan gauw aan bij <a href="http://www.hackdeoverheid.nl/">HackDeOverheid</a>. De dag vindt plaats in het mooiste gebouw van de Amsterdamse Baarsjes, het <a href="http://www.het-sieraad.nl/">Sieraad</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 14 juni, in Utrecht</title>
<link href="https://www.fronteers.nl/nl/blog/2010/05/bijeenkomst-juni"/>
<updated>2010-05-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/05/bijeenkomst-juni</id>
<content xml:lang="nl" type="html"><p>Op 14 juni is Fronteers te gast bij <a href="http://www.setuputrecht.nl/">SETUP</a> in Utrecht. Het thema van deze bijeenkomst is 'het semantische web' en we hebben een spreker uit de praktijk en een onderzoeker bereid gevonden ons hier meer over te komen vertellen.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>19:00 inloop</li>
<li>19:30 introductie SETUP</li>
<li>19:45 Thomas Markus (Universiteit Utrecht)</li>
<li>20:30 korte pauze</li>
<li>20:45 Andreas Creten (My Name is E)</li>
<li>21:30 borrel</li>
</ul>
<h2>Het semantische web</h2>
<p>De eerste talk wordt verzorgd door <a href="https://twitter.com/tmarkus">Thomas Markus</a> van Universiteit Utrecht. Hij heeft een pragmatische en radicaal andere kijk op het integreren en uitwisselen van verschillende informatiebronnen zonder een database. Thomas zal vertellen hoe Semantic Web technologie nieuwe mogelijkheden schept en web developers productiever maakt.</p>
<h2>Data portability</h2>
<p>Als we bij het maken van onze applicaties gebruik maken van open standaarden zijn gebruikers vrij om te kiezen wat ze met hun gegevens doen en waar ze hun gegevens bewaren, over de applicatie grenzen heen. De tweede spreker van vanavond is <a href="http://www.andreascreten.be/">Andreas Creten</a>, oprichter van <a href="http://www.madewithlove.be/">madewithlove</a>. Andreas zal spreken over hoe data portability ons leven gemakkelijker kan maken.</p>
<h2>Over SETUP</h2>
<p>SETUP is hét centrum voor technologie en nieuwe media in Utrecht. Bij SETUP worden bijeenkomsten, workshops en andere events zoals tentoonstellingen en feesten georganiseerd. Tijdens deze activiteiten worden nieuwe ideeën, mogelijkheden en kansen op het gebied van technologie en nieuwe media onderzocht.</p>
<p>SETUP is gevestigd op de Neude in Utrecht, boven het gebouw van ABN-AMRO (dat op dit moment wordt verbouwd).</p>
<p>De bijeenkomst is gratis toegankelijk voor zowel leden als niet-leden. Het is wenselijk dat je je even opgeeft, dan weet de organisatie hoeveel personen er komen.</p>
<p>Tot op 14 juni!</p>
</content>
</entry>
<entry>
<title>Fronteers 2010 komt er aan!</title>
<link href="https://www.fronteers.nl/nl/blog/2010/05/fronteers-2010-komt-er-aan"/>
<updated>2010-05-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/05/fronteers-2010-komt-er-aan</id>
<content xml:lang="nl" type="html"><p>Hierbij weer een update over <a href="https://www.fronteers.nl/congres/2010">ons congres</a> dat op 5, 6, 7 en 8 oktober in Amsterdam zal plaatsvinden. Vandaag maken we twee nieuwe sprekers bekend. De early-bird korting loopt nog tot eind juni, dus we hopen je hiermee over de streep te trekken. Ook kondigen we een tweede workshop aan.</p>
<h2>Sprekers</h2>
<p>Allereerst zijn we zeer trots op het feit dat we <em>de</em> <em>Brendan Eich</em> mogen verwelkomen als een van de sprekers van dit jaar. De vader van JavaScript zal ons komen vertellen wat ons te wachten staat met betrekking tot de slechtst begrepen programmeertaal ter wereld. Ook zal hij aansnijden hoe browsers nu en in de toekomst omgaan met performance op dit gebied, een onderwerp dat de laatste tijd veel aandacht krijgt.</p>
<p>Omdat we ook dit jaar design-gerelateerde onderwerpen zeker niet links willen laten liggen, hebben we <em>Jina Bolton</em> op ons verlanglijstje staan. Ook zij heeft zeer enthousiast &quot;ja&quot; gezegd op ons verzoek om te komen en zal ons dus wat meer over sexy web design en CSS gaan vertellen.</p>
<p>Tijdens de wat geavanceerdere JavaScript sessies zorgen we er trouwens voor dat er een minder technische activiteit tegenover staat. Fronteers 2010 zal, net als de afgelopen twee jaar, uit één track bestaan, maar tijdens deze talks houden we een informeel opgezette CSS Q&amp;A sessie in zaal drie. Vorig jaar waren er wat klachten over het JavaScript-gehalte, en dat hopen we op deze manier dit jaar voor te zijn.</p>
<h2>Tweede workshop</h2>
<p>Iemand die wellicht bij zo'n CSS sessie aanwezig is, is <em>Dan Rubin</em>. Hij zal op dinsdag een workshop geven (details volgen nog), en ook tijdens het congres aanwezig zijn. Deze workshop vindt ook plaats in <a href="https://www.fronteers.nl/congres/2010/workshops#venue">het Kremlin van Felix Meritis</a> en staat verder los van het congres. Kosten van deze workshop zijn € 275,- voor leden en € 350,- voor niet-leden.</p>
<p>Wij geloven dat we jullie tijdens het congres van dit jaar het beste op het gebied van front-end development aanbieden. De geweldige line-up in combinatie met de mogelijkheid om een workshop te volgen, maakt het een enorm breed en interessant programma dit jaar.</p>
<h2>Einde early-bird</h2>
<p>Eind juni zal de early-bird aflopen. Tot die tijd blijven <a href="https://www.fronteers.nl/congres/2010/tickets">de prijzen</a> gelijk. Hoe de prijzen na juni gaan veranderen, is nog niet bekend. Zeker is dat de prijzen na juni omhoog gaan. Wees er dus snel bij, want de kaarten <a href="https://www.fronteers.nl/congres/2010/attendees">gaan hard</a>. Op 28 april hebben alle leden een mailtje met een kortingscode gekregen. Heb je deze niet ontvangen? Neem dan even <a href="https://www.fronteers.nl/congres/2010/contact">contact met ons op</a>.</p>
<p><img src="https://www.fronteers.nl/_img/congres/2009/attendees-2.jpg" alt="" /></p>
<h2>Help ons</h2>
<p><a href="https://www.fronteers.nl/congres/2010/venue">Tuschinski</a> biedt dit jaar een hoop meer stoelen dan afgelopen jaar, toen we in no-time uitverkocht raakten. We hebben <em>jou</em> nodig om dit jaar weer dezelfde stunt uit te halen. Help mee ons congres te promoten door erover te bloggen, te tweeten, like-buttons te klikken, et cetera. Fronteers 2010 is een congres voor en door de vereniging en wat is er nou mooier dan dit met <a href="https://www.fronteers.nl/leden">250 leden</a> uit te dragen naar de buitenwereld?</p>
<p>Hopelijk tot ziens in oktober! Of eerder op een van onze maandelijkse bijeenkomsten :)</p>
<p><a href="https://twitter.com/edwinm">Edwin</a>, <a href="https://twitter.com/kilianvalkhof">Kilian</a>, <a href="https://twitter.com/krijnhoetmer">Krijn</a>, <a href="https://twitter.com/pesla">Peter</a> en <a href="https://twitter.com/vasilis">Vasilis</a> (en alle andere vrijwilligers die meehelpen!)</p>
</content>
</entry>
<entry>
<title>'Fronteers 2010: kaartverkoop, sprekers en workshops'</title>
<link href="https://www.fronteers.nl/nl/blog/2010/04/fronteers-2010-kaartverkoop"/>
<updated>2010-04-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/04/fronteers-2010-kaartverkoop</id>
<content xml:lang="nl" type="html"><p>Na een radiostilte van bijna twee maanden is het weer tijd voor een update van onze kant, wat betreft <a href="https://www.fronteers.nl/congres/2010">Fronteers 2010</a> op 7 en 8 oktober. Vandaag zetten we de kaartverkoop online (Fronteers leden krijgen hierover nog een mailtje, dus hou je nog even in), kondigen we twee nieuwe sprekers aan en maken we wat meer bekend over onze plannen rondom workshops.</p>
<h2>Sprekers</h2>
<p>Na Jeremy Keith en Jeff Croft zijn we verheugd te mogen melden dat <em><a href="http://www.themaninblue.com/">Cameron Adams</a></em> en <em><a href="http://www.nczonline.net/">Nicholas Zakas</a></em> hebben toegezegd ons congres te komen verrijken. Cameron is de man bij wie je moet zijn als het gaat om <a href="http://www.themaninblue.com/experiment/">interessante experimenten in de browser</a> of <a href="http://www.themaninblue.com/writing/perspective/2010/03/22/">vergelijkende warenonderzoeken</a> tussen SVG, <code>&lt;canvas&gt;</code> en Flash. Nicholas is een grootheid op het gebied van <a href="http://www.nczonline.net/writing/">JavaScript performance</a> en zal ons hierover meer komen vertellen.</p>
<p>In totaal kunnen jullie minimaal 14 <em>ongesponsorde</em> sessies verwachten.</p>
<h2>Workshops</h2>
<p>Omdat design vorige jaren een ondergeschoven kindje was op ons congres, hebben we dit jaar besloten een aantal design-gerelateerde workshops te laten geven. We hebben Andy Clarke gecharterd voor woensdag 6 oktober. Hij zal dan zijn workshop <a href="https://www.fronteers.nl/congres/2010/workshops/advanced-css-andy-clarke">Advanced CSS styling</a> in het <a href="https://www.fronteers.nl/congres/2010/workshops#venue">Kremlin van Felix Meritis</a> geven. Voor deze workshop zijn 30 plaatsen beschikbaar. Je kunt hier dus een meer persoonlijke benadering dan bij het congres zelf verwachten. De focus van deze intensieve workshop ligt op één specifiek onderwerp en je verlaat de dag gegarandeerd met een berg nieuwe kennis.</p>
<p>We zijn op dit moment nog aan het onderhandelen met andere workshoppers, dus misschien dat de dinsdag en maandag ook nog gevuld gaan worden. Wees er in ieder geval snel bij, want Andy gaat ook zijn <a href="http://forabeautifulweb.com/">For A Beautiful Web</a> marketingmachine gebruiken om de Amsterdamse zaal vol te krijgen met internationale bezoekers.</p>
<h2>Kaartverkoop</h2>
<p>Zoals gezegd gaat vandaag ook de early-bird kaartverkoop online. Net als vorig jaar gebruiken we hiervoor <a href="http://paydro.net/">Paydro</a>, en kun je betalen via creditcard, iDEAL of op factuur. De kaartprijzen liggen iets hoger dan vorig jaar, aangezien we dit jaar geen sponsortalks hebben en <a href="https://www.fronteers.nl/congres/2010/venue">Tuschinski</a> iets prijziger is (maar <em>wat een locatie</em>).</p>
<p>Hieronder de prijzen voor dit jaar (exclusief 19% btw):</p>
<table>
<thead>
<tr>
<th>Type ticket</th>
<th>Prijs</th>
</tr>
</thead>
<tbody>
<tr>
<td>Early-bird ticket voor 2 dagen</td>
<td>€ 275,00</td>
</tr>
<tr>
<td>Early-bird ticket voor 1 dag</td>
<td>€ 175,00</td>
</tr>
<tr>
<td>Early-bird ticket voor 2 dagen voor Fronteers leden</td>
<td>€ 200,00</td>
</tr>
<tr>
<td>Early-bird ticket voor 2 dagen voor nieuwe Fronteers leden (per 27-04)</td>
<td>€ 225,00</td>
</tr>
<tr>
<td>Early-bird ticket voor 1 dag voor Fronteers leden</td>
<td>€ 125,00</td>
</tr>
<tr>
<td>Workshop Advanced CSS styling</td>
<td>€ 350,00</td>
</tr>
<tr>
<td>Workshop Advanced CSS styling voor Fronteers lede</td>
<td>€ 275,00</td>
</tr>
<tr>
<td>Workshop Advanced CSS styling voor nieuwe Fronteers leden (per 27-04)</td>
<td>€ 300,00</td>
</tr>
</tbody>
</table>
<p><a href="https://www.fronteers.nl/leden">Fronteers leden</a> krijgen via de mailinglist in de komende dagen hun kortingscode doorgemaild, dus hou de hand nog even op de knip. Mensen die vanaf vandaag lid worden krijgen ook korting, maar niet de volledige korting (aangezien deze hoger ligt dan de lidmaatschapskosten). Voor de niet-leden: <a href="https://www.fronteers.nl/congres/2010/tickets">boek je tickets nu!</a></p>
<p>Voor de workshop geldt geen early-bird korting, dus deze prijzen zullen hetzelfde blijven. Wat de overige definitieve prijzen worden <em>na</em> de early-bird weten we nog niet, dus die houden jullie nog van ons tegoed. De early bird periode duurt tot eind juni; wees er dus op tijd bij!</p>
<h2>Sponsoring</h2>
<p>We zijn nog steeds op zoek naar <a href="https://www.fronteers.nl/congres/2010/sponsorships">enkele sponsoren</a>. Mocht je geïnteresseerd zijn of vinden dat je baas hier nodig bij moet zijn, laat het ons dan weten en je gaat als VIP mee naar het sprekersdiner op woensdag.</p>
<h2>Volg ons op Twitter</h2>
<p>Via <a href="https://twitter.com/FronteersConf">@FronteersConf</a> gaan we vanaf nu wat vaker korte updates geven, dus als je ons nog niet volgt, ga daar dan eens mee beginnen :)</p>
<h2>That's it</h2>
<p>Voor nu is dit het; het woord is aan jullie. Help mee ons en jullie congres te promoten via je blog, Twitter of gewoon op de werkvloer en laten we er samen voor zorgen dat <em>Fronteers 2010</em> weer een indrukwekkend, memorabel, uniek, kick-ass congres wordt.</p>
<p>Als je vragen of opmerkingen hebt, zoals over alles bij Fronteers; schroom niet om iets van je te laten horen!</p>
<p><a href="https://twitter.com/edwinm">Edwin</a>, <a href="https://twitter.com/kilianvalkhof">Kilian</a>, <a href="https://twitter.com/krijnhoetmer">Krijn</a>, <a href="https://twitter.com/pesla">Peter</a> en <a href="https://twitter.com/vasilis">Vasilis</a> (en alle andere vrijwilligers die ons meehelpen!)</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 6 mei, in Groningen</title>
<link href="https://www.fronteers.nl/nl/blog/2010/04/bijeenkomst-mei-groningen"/>
<updated>2010-04-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/04/bijeenkomst-mei-groningen</id>
<content xml:lang="nl" type="html"><p>Op donderdag 6 mei zal Fronteers te gast zijn bij <a href="http://tfe.nl/">theFactor.e</a> in Groningen. Twee bijeenkomsten in mei dus. De avond zal in het teken staan van het oplossen van de problemen die je tegenkomt als je met een CMS aan de webrichtlijnen wilt voldoen.</p>
<h2>Het programma is als volgt</h2>
<ul>
<li>19.00 uur: Inloop</li>
<li>19.30 uur: Introductie theFacor.e door Thijs Helfrich</li>
<li>19.45 uur: Daniel Doesburg en Gerard Wijngaarden over TYPO3 en de webrichtlijnen</li>
<li>20.45 uur: korte pauze</li>
<li>21.00 uur: Koen Willems</li>
<li>22.00 uur: Borrelen</li>
</ul>
<h2>Koen Willems over zijn WYSIWYM-editor</h2>
<p>Twee maanden geleden gaf Koen Willems in Den Haag een presentatie, waarin hij stil stond bij de eisen die tegenwoordig aan een rich text editor gesteld moeten worden.</p>
<p>Aan het eind daarvan gaf hij een korte demonstratie van een door hem omgebouwde editor, waarin het WYSIWYM-principe is toegepast. Op 6 mei zal dieper worden ingegaan op de problemen en uitdagingen die daarbij naar boven kwamen en zal ook worden stilgestaan bij usability-aspecten. Ook zullen de verdere plannen voor de editor worden toegelicht.</p>
<p>theFacor.e is gevestigd aan de Friesestraatweg 215a, 9743 AD te Groningen.</p>
<h2>Routebeschrijving met het OV</h2>
<ol>
<li>Neem bus 3 richting Vinkhuizen vanaf Groningen Centraal;</li>
<li>Stap uit bij halte Goudlaan/Siersteenlaan;</li>
<li>Vanaf de halte ga je bij de rotonde linksaf;</li>
<li>Onder de tunnel door en dan weer linksaf;</li>
<li>Rechtdoor tot je bij de ommelanden uitkomt (oude melk fabriek);</li>
<li>Eerste verdieping van het middelste gebouw. (Het is vanaf de bushalte +/- 5minuten lopen.)</li>
</ol>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden, maar is het wenselijk dat je je even opgeeft, zodat de organisatie weet hoeveel personen er komen.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 19 mei, in Breda</title>
<link href="https://www.fronteers.nl/nl/blog/2010/04/bijeenkomst-mei-breda"/>
<updated>2010-04-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/04/bijeenkomst-mei-breda</id>
<content xml:lang="nl" type="html"><p>Op 19 mei zal Fronteers te gast zijn bij <a href="http://www.e-sites.nl/">E-sites</a> in Breda. Er zal een praatje gehouden worden over de huidige ontwikkelingen op het gebied van CSS en er gaat wat verteld worden over HTML5 Apps.</p>
<h2>Het programma is als volgt</h2>
<ul>
<li>18.30 uur: Inloop</li>
<li>19.15 uur: Introductie E-sites door Boye Oomens</li>
<li>19.30 uur: Anne van Kesteren over de huidige ontwikkelingen op het gebied van CSS</li>
<li>20.30 uur: Nikolai Onken over HTML5 apps</li>
<li>21.30 uur: Borrelen</li>
</ul>
<h2>Huidige ontwikkelingen rond CSS</h2>
<p><a href="http://annevankesteren.nl/">Anne van Kesteren</a> zal iets gaan vertellen over de huidige ontwikkelingen binnen CSS. Denk hierbij aan onder andere transformaties en animaties. Misschien dat hij ook nog een tipje van de sluier kan oplichten over hoe het er tijdens <a href="http://www.w3.org/blog/CSS">CSS WG</a> meetings aan toe gaat.</p>
<h2>HTML5 Apps</h2>
<p><a href="https://twitter.com/nonken">Nikolai Onken</a> zal ingaan op <a href="http://www.quirksmode.org/blog/archives/2010/03/html5_apps.html">HTML5 Apps</a>:
“Developing HTML5 apps for different mobile devices comes with a whole new set of challenges. In this talk I will show you how platform independent mobile apps can be developed and deployed using the different available runtimes etc. for iPhone, Android, Palm, Blackberry, Nokia and Windows Mobile. You will see what the hurdles are and what is possible and realistic today. Cross platform development is not a myth anymore — you will get insight on how to get started yourself.”</p>
<h2>Locatie</h2>
<p>E-sites is gevestigd aan de Reduitlaan 33, 4814 DC te Breda. Een <a href="http://www.e-sites.nl/over/1595-routebeschrijving.html">routebeschrijving</a> is te vinden op de website van E-sites.</p>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden, maar is het wenselijk dat je je even opgeeft, zodat de organisatie weet hoeveel personen er komen.</p>
</content>
</entry>
<entry>
<title>Oprichting commissie voor cursussen</title>
<link href="https://www.fronteers.nl/nl/blog/2010/03/commissie-cursussen"/>
<updated>2010-03-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/03/commissie-cursussen</id>
<content xml:lang="nl" type="html"><p>Het is tijd om een commissie op te richten die de cursussen opzet, regelt en aan de man brengt. Er gaan al langere tijd stemmen op om trainingen aan te bieden. Daar lijkt veel interesse in te zijn, zowel voor aanbieders als afnemers.</p>
<p>Mijn ervaring is echter dat het organiseren van trainingen veel meer werk is dan het op het eerste oog lijkt. Je moet trainers regelen, mensen die de trainingen willen volgen, ruimte om de trainingen te volgen, koffie/thee/etc, schema, rooster, financiën, de hele mikmak.</p>
<p>Daarom stel ik voor dat we een commissie oprichten die zich hiermee bezig gaat houden. Hier zijn een man of drie vier voor nodig. Deze hoeven zelf niet per se trainingen te geven, maar moeten het geheel wel kunnen opzetten en organiseren.</p>
<p>Ik stel mezelf beschikbaar om hier in plaats te nemen. Liever niet als voorzitter, overigens. Tevens wil ik zelf ook trainingen verzorgen m.b.t. JavaScript.</p>
<p>Als je interesse hebt in de commissie, in het geven of nemen van trainingen, stuur dan <a href="https://www.fronteers.nl/vereniging/commissies/workshops#formulier-1">een mailtje aan de commissie</a> of bezoek ons op <a href="http://webchat.freenode.net/?channels=fronteers">#fronteers op irc.freenode.net</a>.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 25 maart, in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2010/03/bijeenkomst-maart"/>
<updated>2010-03-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/03/bijeenkomst-maart</id>
<content xml:lang="nl" type="html"><p>Op donderdag 25 maart zal Fronteers te gast zijn bij <a href="http://appoint.nl/">Appoint</a> te Amsterdam. Er zal een presenatie gegeven worden over de UX en templating van Drupal 7, en een discussie over webdevelopers.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 uur: inloop.</li>
<li>19.30 uur: korte introductie over Appoint door commercieel directeur Michiel Suijkerbuijk.</li>
<li>19.35 uur: Bojhan Somers en Roy Scholten over UX en templating van Drupal 7.</li>
<li>20.30 uur: Michiel Suijkerbuijk zal een discussie leiden over webdevelopers.</li>
<li>21.00 uur: borrel, netwerken.</li>
</ul>
<h2>UX en templating van Drupal 7</h2>
<p>Drupal 7 heeft veel veranderingen gebracht op het gebied van de gebruiksvriendelijkheid. Er is veel werk gestoken in het vriendelijker maken van Drupal, vooral voor de minder technische gebruikersgroep.</p>
<p>Bojhan Somers en Roy Scholten, maintainers van de Drupal 7 User Experience hebben zich bezig gehouden met de vele UX initiatieven in de afgelopen twee jaar. We maken een tour langs de nieuwe mogelijkheden en staan stil bij de veranderingen op user experience en theming gebied:</p>
<ul>
<li>De Drupal 7UX strategie en doelen</li>
<li>Demonstratie verbeteringen in Drupal 7UX</li>
<li>Drupal 7 theming verbeteringen</li>
<li>Reflectie op het proces, en de toekomst van Drupal</li>
</ul>
<h2>Discussie over webdevelopers</h2>
<p>Gespreksleider Michiel zal aan het einde van de bijeenkomst de mening peilen over een aantal stellingen. Appoint is vooral geïnteresseerd in de dagelijkse problemen bij de inzet van Web Developers. Tevens wil Appoint graag de mening peilen van de deelnemers over de succesfactoren en valkuilen bij complexe projecten.</p>
<h2>Locatie</h2>
<p>Appoint is gevestigd aan de Silodam 402, 1013 AW, Amsterdam.</p>
<p>Zoals altijd is deze bijeenkomst gratis toegankelijk voor zowel leden als niet-leden, maar is het wenselijk dat je je even opgeeft, zodat de organisatie weet hoeveel personen er komen.</p>
</content>
</entry>
<entry>
<title>Aankondiging Fronteers 2010</title>
<link href="https://www.fronteers.nl/nl/blog/2010/03/aankondiging-fronteers-2010"/>
<updated>2010-03-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/03/aankondiging-fronteers-2010</id>
<content xml:lang="nl" type="html"><p>De afgelopen maanden is de <a href="https://www.fronteers.nl/vereniging/commissies/congres">congres commissie</a> druk bezig geweest met de voorbereidingen van <a href="https://www.fronteers.nl/congres/2010">Fronteers 2010</a>. Vandaag is het moment aangebroken dat we onze voortgang even onder de aandacht willen brengen. Hieronder dus enkele wapenfeiten.</p>
<p>Het congres zal dit jaar plaatsvinden op <em>donderdag 7 en vrijdag 8 oktober 2010</em> in <a href="http://nl.wikipedia.org/wiki/Tuschinski_Theater">Pathé Tuschinski</a> in Amsterdam. We verwachten daar in totaal 14 (ongesponsorde) sessies te houden, dus de kwaliteit zal dit jaar weer van een hoog niveau zijn. En voor iedereen die er in 2009 ook bij was; de stoelen zijn in Tuschinski iets beter ;).</p>
<p><img src="https://www.fronteers.nl/_img/congres/2010/venue/tuschinski.jpg" alt="Pathé Tuschinski is een ronde, ruime bioscoopzaal met meerdere verdiepingen." /></p>
<p>In de dagen voorafgaand aan het congres zullen we ook een aantal workshops organiseren. We zijn hiervoor in onderhandeling met enkele grote namen. Hiervan verwachten we de eerste op korte termijn aan te kunnen kondigen. In ieder geval lijkt het ons verstandig dat designers in de dagen voor het congres ook een dagje 'vrij' plannen!</p>
<p>Ondertussen hebben we een groot deel van de sprekers (<a href="https://www.fronteers.nl/blog/2009/11/suggereer-sprekers-fronteers10">een selectie uit de lijst die jullie aangeleverd hebben</a>) al benaderd, en hebben de meesten van hen <em>zeer</em> enthousiast 'Ja!' gezegd. De catering is zo goed als rond en we zijn met de laatste details bezig rondom de financiën. Misschien deze, maar sowieso volgende maand, zal de kaartverkoop van start gaan. Fronteers leden kunnen zoals gebruikelijk een korting verwachten, hoewel die iets minder is dan vorige jaren. De contributie is immers ook weer omlaag gegaan. Qua kaartprijs kun je ongeveer uitgaan van de prijzen van vorig jaar.</p>
<p><img src="https://www.fronteers.nl/_img/congres/2010/fluff/keycords.jpg" alt="" /></p>
<p>Bij een aankondiging als deze verwacht men natuurlijk ook alvast een aantal namen van sprekers, dus laten we die meteen maar geven. De eerste twee sprekers zijn <a href="http://adactio.com/">Jeremy Keith</a> en <a href="http://jeffcroft.com/">Jeff Croft</a>, twee grootheden in de wereld van HTML en CSS, met een duidelijke mening over de laatste 'versies' van deze basistechnieken van iedere front-ender.</p>
<p>Natuurlijk zijn we dit jaar ook op zoek naar een aantal sponsoren, die graag hun naam willen verbinden aan ons congres. Neem voor meer informatie hierover contact op met Peter, via <a href="mailto:congres@fronteers.nl">congres@fronteers.nl</a>.</p>
<p>Verder willen we nog even zeggen dat we als commissie al erg enthousiast zijn over het verloop, en dat we vrij zeker weten dat dit weer een schitterend congres gaat worden. Hopelijk krijgen we de zaal (lees: de benedenring) weer vol, net als vorig jaar. Hiervoor hebben we het volste vertrouwen in jullie!</p>
<p><a href="https://twitter.com/edwinm">Edwin</a>, <a href="https://twitter.com/kilianvalkhof">Kilian</a>, <a href="https://twitter.com/krijnhoetmer">Krijn</a>, <a href="https://twitter.com/pesla">Peter</a> en <a href="https://twitter.com/vasilis">Vasilis</a></p>
</content>
</entry>
<entry>
<title>Spontaanborrel a.s. woensdag</title>
<link href="https://www.fronteers.nl/nl/blog/2010/03/spontaanborrel-woensdag"/>
<updated>2010-03-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/03/spontaanborrel-woensdag</id>
<content xml:lang="nl" type="html"><p>Woensdag 3 maart is er een Spontaanborrel ergens in Utrecht!</p>
<p>Wat kan je er nog meer over zeggen. Kom gezellig een biertje pakken in de Winkel van Sinkel te Utrecht, woensdag (3 maart) vanaf een uur of zes!</p>
</content>
</entry>
<entry>
<title>Congres video's, en de keuze voor Theora</title>
<link href="https://www.fronteers.nl/nl/blog/2010/01/congres-videos-keuze-voor-theora"/>
<updated>2010-01-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/01/congres-videos-keuze-voor-theora</id>
<content xml:lang="nl" type="html"><p>Na een iets langere periode wachten dan waar we met z'n allen op gehoopt hadden, zijn we dinsdag begonnen met de eerste video's van Fronteers 2009 online te zetten. Op dit moment zijn beschikbaar: <a href="https://www.fronteers.nl/congres/2009/sessions/a-web-of-confusion">A Web of Confusion</a> door Douglas Crockford, <a href="https://www.fronteers.nl/congres/2009/sessions/roll-your-own-effects-framework">Roll Your Own Effects Framework</a> door Thomas Fuchs, <a href="https://www.fronteers.nl/congres/2009/sessions/the-future-state-of-layout">The future state of layout</a> door Stephen Hay, <a href="https://www.fronteers.nl/congres/2009/sessions/the-type-we-want-using-fonts-on-the-web">The Type We Want</a> door Jonathan Snook, en <a href="https://www.fronteers.nl/congres/2009/sessions/even-faster-web-sites">Even Faster Web Sites</a> door Steve Souders. Alle video's die we de komende dagen en weken (maanden?) online gaan zetten zullen worden gelinkt vanaf de <a href="https://www.fronteers.nl/congres/2009/sessions">sessions pagina</a> van het congres. Om de video's te tonen maken we gebruik van het <a href="http://www.w3.org/TR/html5/video.html#video"><code>&lt;video&gt;</code></a> element, en de <a href="http://en.wikipedia.org/wiki/Theora">Theora</a> codec. Dit is niet zonder enige discussie gepaard gegaan...</p>
<p>Op dit moment gebruikt ongeveer 65% van de bezoekers van de Fronteers website een browser die het <code>&lt;video&gt;</code> element in combinatie met de Theora codec ondersteunt. Dit zijn specifiek Firefox 3.5/3.6 (en andere Gecko 1.9.1+ browsers zoals SeaMonkey 2), Chrome 3/4, en (pre-)alpha builds van Opera 10.50. De (toch nog) 20% IE gebruikers zullen geen video in hun browser zien, maar kunnen de video's wel downloaden, en met hun mediaspeler naar keuze afspelen. (In het onwaarschijnlijke geval dat deze geen Theora ondersteunt is <a href="http://www.videolan.org/vlc/">VLC</a> een goed en open-source alternatief.) En dan zijn er ongeveer 10% aan Safari gebruikers, die op de plaats van het video element wel de posterframe zullen zien, maar door het gebrek aan ondersteuning van de Theora codec in Safari, niet de video zullen kunnen afspelen. Deze bezoekers zullen net als de IE gebruikers de video moeten downloaden om hem te kunnen bekijken, en er is fiks gediscussieerd op het Fronteers IRC kanaal of dit de juiste keuze was, of dat we ook een versie van de video's zouden moeten aanbieden die gebruik maakt van de <a href="http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC">H.264</a> codec. (Deze codec wordt naast Safari ook ondersteund door Chrome, maar niet door de open-source Chromium.) Opvallend genoeg heeft het na het online zetten van de eerste video nog twee dagen geduurd voordat iemand zelfs maar opperde de video's d.m.v. Flash ook aan IE gebruikers in de browser te tonen.</p>
<p>De kernvraag is: Wat is belangrijker, het op dit moment geven van een zo goed mogelijke ervaring aan zoveel mogelijk bezoekers, of het in de strijd gooien van ons collectief gewicht om toe te werken naar een situatie waarin iedere internetgebruiker zonder enige hindernissen video's kan bekijken en creëren. Wij als Fronteers hebben een voorbeeldfunctie, en willen (zoals op het oprichtingscongres is <a href="https://www.fronteers.nl/vereniging/bestuur/notulen/18-09-07">besloten</a>, en op de afgelopen ALV nog eens is <a href="https://www.fronteers.nl/vereniging/bestuur/notulen/27-11-2009">bevestigd</a>), &quot;standaardenorganisaties en implementerende partijen ertoe [..] bewegen het welzijn van front-end ontwikkelaars te verbeteren middels betere standaarden, technieken, documentatie en implementaties.&quot; Aan de andere kant, kunnen we als front-end ontwikkelaars wel serieus genomen worden als we niet de op dit moment voor zoveel mogelijk mensen best werkende oplossing kiezen?</p>
<p>Voor de mensen die niet op de hoogte zijn van de problematiek rondom video codecs, een korte samenvatting. HTML5 specificeert het <code>&lt;video&gt;</code> element. Oorspronkelijk ging dit gepaard met het specificeren van de te gebruiken codec, namelijk Theora. Apple, als een van de vijf grote browser makers, had hier echter zwaarwegende bezwaren tegen aangezien ze bevreesd waren voor &quot;submarine&quot; patenten op deze video codec. Dit risico bestaat natuurlijk altijd, maar met andere codecs hadden ze het risico al genomen (bijvoorbeeld via iTunes), en nog een volgend risico nemen was klaarblijkelijk onacceptabel. H.264 als de te specificeren video codec is niet acceptabel voor open source browser makers (specifiek Mozilla, maar ook relevant voor webkit-gebaseerde browsers zoals Chromium, Konqueror, e.a.), aangezien er veel software patenten op H.264 rusten. Hoewel een organisatie als Mozilla theoretisch de kosten van een licentie zou kunnen opbrengen (voor dit jaar 5 miljoen dollar, ongeveer 6% van de jaarlijkse omzet van Mozilla, met verdere jaarlijkse prijsstijgingen bijna zeker), zouden gebruikers van de Mozilla source code niet gerechtigd zijn H.264 te gebruiken. Dit gaat tegen het principe van open source software in, en is <a href="http://shaver.off.net/diary/2010/01/23/html5-video-and-codecs/">onacceptabel voor Mozilla</a>. (Gebruik maken van op het OS geinstalleerde codecs is voor Mozilla ook <a href="http://weblogs.mozillazine.org/roc/archives/2010/01/video_freedom_a.html">geen oplossing</a>; dit brengt grote beveiligingsproblemen met zich mee, en gaat tegen Mozilla's missie voor een open web in.) Tevens vindt Opera H.264 onacceptabel, voornamelijk (?) omwille van de zeer hoge licentie kosten. Gezien deze impasse, en om de realiteit beter te reflecteren, is de specificatie van een te gebruiken codec uit HTML5 verwijderd. De zoektocht naar een voor iedereen acceptabele codec blijft wel doorgaan.</p>
<p>Met een gebrek aan een van hogerhand opgegeven mandaat voor de codec die algemeen gebruikt gaat worden op het web, heeft de strijd zich verplaatst naar implementaties en gebruikers. H.264 wordt ondersteund door de grote media bedrijven, en de hieraan gelieerde partijen. H.264 heeft een voorsprong in gebruik, en ondersteuning in hardware. Daartegenover staat Theora met ondersteuning van de open source software wereld, en alle kleine partijen die zelf video op het web willen kunnen zetten. H.264 is op dit moment gratis te gebruiken voor het produceren van video's op kleine schaal, maar door de jaarlijks veranderende licentie structuur bestaat er totaal geen zekerheid dat dit altijd zo zal blijven. <a href="http://www.0xdeadbeef.com/weblog/2010/01/html5-video-and-h-264-what-history-tells-us-and-why-were-standing-with-the-web/">De geschiedenis leert ons</a>, en alle tekenen wijzen er inderdaad op, dat dit, mocht H.264 <em>de</em> meestgebruikte videocodec worden, over een aantal jaren zal veranderen.</p>
<p>De situatie op dit moment is sterk in flux; alles is mogelijk, en kleine acties kunnen een groot effect hebben. Theora heeft, dankzij Firefox en Chrome, op dit moment veruit het grootste percentage aan directe ondersteuning in een browser. Mozilla werkt er tevens hard aan om de kwaliteit van de codec nog verder te verbeteren. (Er bestaan veel mythes over technische inferioriteit van de Theora codec, voornamelijk door oude tests uit de tijd dat de bitstream codec net was vastgelegd, maar er nog weinig tijd was besteed aan het implementeren van encoders en decoders; <a href="http://people.xiph.org/~greg/video/ytcompare/comparison.html">recente</a> <a href="http://people.xiph.org/~maikmerten/youtube/">tests</a> laten zien dat verschillen in kwaliteit minimaal zijn.) Daar tegen over staat dat YouTube en Vimeo in eerste experimenten met <code>&lt;video&gt;</code> <a href="http://youtube-global.blogspot.com/2010/01/introducing-youtube-html5-supported.html">gebruik maken van H.264</a>. (Voornamelijk omdat hun video's al in dit formaat gecodeerd waren?) Er zijn <a href="http://lists.xiph.org/pipermail/theora/2009-July/002415.html">tekenen</a> dat Apple Theora wil heroverwegen, en met de aankoop van On2 heeft Google de oorsprong van de Theora codec in handen, wat mogelijkerwijs meer zekerheid kan gaan geven op het gebied van submarine patenten.</p>
<p>Het komende jaar gaat waarschijnlijk beslissend zijn. Komen we uit op een situatie waar H.264 <em>de</em> video standaard voor het web wordt, en moet iedereen die iets met video doet hier geld voor gaan betalen aan de MPEG-LA? Of weet Theora genoeg momentum te behalen om Apple en grote video sites over te halen gebruik van deze codec te gaan maken, waarmee we in een wereld terecht komen waar video op het web een vrij en open formaat wordt, waar iedereen optimaal gebruik van kan maken?</p>
<p>Ik weet welke situatie mijn voorkeur heeft, en ik weet welke situatie beter is voor ons als web ontwikkelaars. Wij web ontwikkelaars spelen tevens zelf een rol in deze strijd, en onze keuzes kunnen van belang zijn. Hoe meer video van hoge kwaliteit op het web gepubliceerd wordt in Theora (en <em>niet</em> in H.264), des te hoger wordt de kans dat Apple besluit dat het het risico waard is om ook Theora te ondersteunen in Safari. Fronteers is dan wel geen Wikipedia (welke site al hun video's in Theora zal hosten), maar we beginnen ondertussen toch enige omvang en naam te hebben, en kunnen deze hier nuttig gebruiken om te helpen streven naar een open web.</p>
<p>Wat is jullie mening? Doen we hier goed aan, of moeten we niet zo zeuren en lekker praktisch H.264 video via een Flash interface aanbieden? Is het belangrijker om nu 100% van onze bezoekers tevreden te stellen, of mogen we juist wel wat idealisme tonen en zeggen, &quot;Wij weten wat op lange termijn het beste is!&quot;?</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 4 februari, in Den Haag</title>
<link href="https://www.fronteers.nl/nl/blog/2010/01/bijeenkomst-februari"/>
<updated>2010-01-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/01/bijeenkomst-februari</id>
<content xml:lang="nl" type="html"><p>Op donderdag 4 februari 2010 zal de Fronteers bijeenkomst plaatsvinden bij <a href="http://www.ictu.nl/">Stichting ICTU</a> te Den Haag. Deze bijeenkomst zal iets vroeger starten dan normaal in verband met de tijdige sluiting van het gebouw. We starten dan ook met een buffet zodat je niet met een lege maag de presentaties hoeft bij te wonen.<strong>Update: <a href="https://www.fronteers.nl/bijeenkomsten/2010/stichting-ictu">verslag en video's van deze avond</a> staan online.</strong></p>
<p>Het programma (onder enig voorbehoud) is als volgt:</p>
<ul>
<li>17:00 uur: inloop</li>
<li>17:30 uur: buffet en netwerken</li>
<li>18:30 uur: introductie Stichting ICTU</li>
<li>18:45 uur: presentatie Webrichtlijnen versie 2 Sneak preview, door Raph de Rooij</li>
<li>19:45 uur: presentatie &quot;Evolutie van WYSIWYG naar WYSIWYM&quot;, door Koen Willems</li>
<li>20:30 uur: netwerken, borrelen etc.</li>
<li>21:30 uur: eruit gegooid worden en in een café in de buurt verder gaan</li>
</ul>
<h2>Webrichtlijnen versie 2 Sneak preview</h2>
<p>De nieuwe webrichtlijnen worden anders van opzet dan de huidige. Raph gaat het hebben over de verbeterpunten van de webrichtlijnen, uitgangspunten van de nieuwe versie van de webrichtlijnen en WCAG 2.</p>
<h2>Evolutie van WYSIWYG naar WYSIWYM</h2>
<p>Eén van de grotere problemen bij het onderhouden van een website die aan de Webrichtlijnen moet (blijven) voldoen wordt veroorzaakt door de gebruikte editor. Het uitgangspunt van scheiding van content en presentatie brengt met zich mee dat het WYSIWYG-principe niet meer voldoet en dat de focus verlegt moet worden naar WYSIWYM. In het open source segment schijnt daarvoor nog geen goede applicatie voorhanden te zijn.</p>
<p>Koen Willems zal in zijn presentatie stilstaan bij de eigenschappen en kenmerken die de ideale editor moet hebben en zal daarbij voorbeelden geven aan de hand van een volledig door hem ‘omgebouwde’ editor.</p>
<p>Zoals gebruikelijk is deze bijeenkomst voor zowel leden als niet-leden. Stichting ICTU zit in een overheidsgebouw waar legitimatie verplicht is en waar je vooraf aangemeld moet worden. Zorg voor een geldig legitimatiebewijs (bijvoorbeeld paspoort of rijbewijs) anders kom je echt niet binnen. <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">Meld je op de site aan</a> en geef alle namen van de personen die meekomen op. Maandag 1 februari 2010 is de laatste dag dat je je kan aanmelden.</p>
</content>
</entry>
<entry>
<title>Nieuwjaarsbijeenkomst Internet Society</title>
<link href="https://www.fronteers.nl/nl/blog/2010/01/nieuwjaarsbijeenkomst-isoc"/>
<updated>2010-01-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2010/01/nieuwjaarsbijeenkomst-isoc</id>
<content xml:lang="nl" type="html"><p>Alle Fronteers leden zijn van harte uitgenodigd voor een bijzondere Nieuwjaarsbijeenkomst, die zal worden gehouden op donderdag 14 januari in NEMO in Amsterdam (het grote groene gebouw vlakbij Centraal Station), vanaf 19:00 uur. Hieronder de uitnodiging die wij ontvangen hebben.</p>
<p>Dit evenement wordt georganiseerd samen met negentien andere lokale en internationale Internet-gerelateerde organisaties die in Nederland gevestigd zijn. Deelnemende organisaties naast Fronteers zijn Internet Society Nederland, Bits of Freedom, RIPE NCC, W3C Benelux, AMS-IX, Terena, Surfnet, Vereniging Open Domein, Accessibility.nl, Gridforum.nl, OpenDoc Society, NLUUG, ISPconnect, SIDN, NLnet, NLnet Labs, Dutch Hosting Provider Association, stichting HXX, Digitaal Erfgoed Nederland en Vrijschrift.</p>
<p>We zijn verheugd dat twee gerelateerde overheidsprogramma's, het Forum Standaardisatie (dat IT-standaarden vaststelt voor de Nederlandse overheid) en het programma Nederland in Open Verbinding (dat open standaarden en open source binnen de Nederlandse overheid bevordert) eveneens aansluiting hebben gezocht. Hun bijeenkomst vindt eveneens plaats direct voorafgaand aan onze Nieuwjaarsbijeenkomst (vanaf 16.30 uur), en jullie zijn daar eveneens van harte bij welkom. Kortom, het wordt een memorabele dag voor de Nederlandse internetgemeenschap!</p>
<p>Het betekent ook dat naast andere Fronteers-leden je zeker tegen vele oude bekenden zult aanlopen. En natuurlijk nieuwe contacten kunt opdoen met interessante mensen uit andere hoeken van het internet. Van experts op het gebied van de laatste webtechnologieen tot accessibility, van hostingbedrijven tot charitatieve investeerders, van digitale burgerrechten tot nummerblokbeheerders - iedereen is er.</p>
<p>Naast het bijwonen van het sociale gedeelte kun je ook er voor kiezen om lightning talks bij te wonen over interessante onderwerpen zoals aanstormende internettechnologieen, digitaal erfgoed, de IT-agenda van de overheid, het electronisch patientendossier, universeel toegankelijke games, reverse engineering, en digitale burgerrechten die op de avond plaats zullen vinden. Er wordt een bescheiden buffet geserveerd vanaf 18.00 met dank aan Forum Standaardisatie en het programma Nederland Open in Verbinding.</p>
<p>Kom met ons het glas heffen op het nieuw jaar op 14 januari 2010 vanaf 19.00 uur (geschatte eindtijd 23.00) bij NEMO, Oosterdok 2 in Amsterdam.</p>
<p>Meer informatie en aanmelden, graag voor 9 januari, op <a href="http://isoc.nl/activ/2010-nieuwjaar.htm">http://isoc.nl/activ/2010-nieuwjaar.htm</a></p>
<p>P.S. Als je geïnteresseerd bent in het Nederlandse overheidsbeleid op het gebied van open standaarden en open source, ben je van harte welkom om het programma bij te wonen van Forum Standaardisatie en Nederland open in Verbinding vanaf 16.30 uur. Het programma verschijnt binnenkort op <a href="http://noiv.nl/">http://noiv.nl/</a></p>
</content>
</entry>
<entry>
<title>WCAG 2.0 seminar in Den Haag</title>
<link href="https://www.fronteers.nl/nl/blog/2009/12/wcag20-seminar"/>
<updated>2009-12-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/12/wcag20-seminar</id>
<content xml:lang="nl" type="html"><p>Op woensdag 16 december zal de Stichting Accessibility in samenwerking met het ISOC en W3C in de Koninklijke Bibliotheek in Den Haag een seminar organiseren over <a href="http://www.w3.org/TR/WCAG/">WCAG 2.0</a>.</p>
<p>WCAG 2.0 is eind 2008 geïntroduceerd en zal begin 2010 ook in een officiële Nederlandse vertaling beschikbaar zijn. Wat hebben we aan deze nieuwe standaard? Wat is het verschil met <a href="http://www.w3.org/TR/WCAG10/">WCAG 1.0</a> en wat betekent de nieuwe standaard voor de wet– en regelgeving op nationaal en internationaal niveau? Op deze vragen zal een aantal sprekers een antwoord proberen te geven. Daarnaast zal de coördinator van het W3C Web Accessibility Initiative (WAI) uitgebreid ingaan op WCAG 2.0.</p>
<p>Kosten voor het seminar zijn 195 euro exclusief 19% btw. Voor klanten van de Stichting Accessiblity en leden van ISOC en W3C geldt een korting van 50%. Bezoek <a href="http://www.accessibility.nl/internet/training/SeminarWCAG2/">de site van de Stichting Accessibility</a> voor meer informatie, het programma en om je aan te melden.</p>
</content>
</entry>
<entry>
<title>Fronteers winterborrel</title>
<link href="https://www.fronteers.nl/nl/blog/2009/12/fronteers-winterborrel"/>
<updated>2009-12-02T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/12/fronteers-winterborrel</id>
<content xml:lang="nl" type="html"><p>Er is op --donderdag 17 december--++maandag 4 januari++ weer zo'n leuke, informele Fronteers borrel. Deze --speciale 'DoMiFroBo'--++nieuwjaarsborrel++ vindt plaats bij De Winkel van Sinkel in Utrecht.</p>
<p>De Winkel van Sinkel ligt <a href="http://maps.google.nl/maps?f=q&amp;source=s_q&amp;hl=nl&amp;geocode=&amp;q=winkel+van+sinkel+utrecht&amp;sll=52.469397,5.509644&amp;sspn=3.654648,9.766846&amp;ie=UTF8&amp;hq=Winkel+van+Sinkel&amp;hnear=Winkel+van+Sinkel,+3512+Utrecht&amp;ll=52.095486,5.118599&amp;spn=0.027472,0.076303&amp;z=14&amp;iwloc=A">aan de Oudegracht</a> op loopafstand van Utrecht CS. De borrel begint rond 17:00 uur en uiteraard is er na de borrel gelegenheid om nog iets te eten.</p>
<p>Dus wil je weer eens gezellig bijpraten, discussiëren over werk of toch juist niet? Kom dan donderdag langs in Utrecht. Je kunt in de reacties even laten weten of je komt.</p>
<p><em>Update:</em> deze borrel is omgedoopt tot nieuwjaarsborrel, en wel op maandag 4 januari 2010. Zelfde tijd en locatie!</p>
</content>
</entry>
<entry>
<title>Meld je aan voor de Algemene Ledenvergadering 2009</title>
<link href="https://www.fronteers.nl/nl/blog/2009/11/meld-je-aan-voor-de-algemene-ledenvergadering-2009"/>
<updated>2009-11-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/11/meld-je-aan-voor-de-algemene-ledenvergadering-2009</id>
<content xml:lang="nl" type="html"><p>Vrijdag 27 november a.s. houden we onze jaarlijkse algemene ledenvergadering (ALV). De ALV vindt plaats in de <a href="http://www.bvalmere.nl/vereniging/sporthal">sporthal van Badminton Vereniging Almere</a>. We beginnen om 19.30 uur en denken maximaal twee uur nodig te hebben.</p>
<p>De agenda is als volgt:</p>
<ol>
<li>Welkom en opening door de voorzitter</li>
<li>Toelichting commissies</li>
<li>Ingebrachte beleidsvoorstellen</li>
<li>Besluiten eerdere ALV’s</li>
<li>Begroting 2009</li>
<li>Begroting 2010</li>
<li>Kascommissieverkiezing</li>
<li>Bestuursverkiezing</li>
<li>Rondvraag</li>
<li>Sluiting</li>
</ol>
<p>De commissievoorzitters zullen een korte toelichting geven op hun gedane werk en hun plannen voor 2010 en staan verder natuurlijk open voor vragen. Ook zullen we eerdere aangenomen voorstellen uit 2007 en 2008 tegen het licht houden. Arjan Eising is herkiesbaar en Matijs Brinkhuis is verkiesbaar voor een positie in het bestuur. Mocht je zelf nog vragen, ideeën of voorstellen hebben, meld ze dan middels het <a href="https://www.fronteers.nl/contact">contactformulier</a>. Zie ook de eerdere <a href="https://www.fronteers.nl/vereniging/bestuur/notulen">notulen</a>.</p>
<blockquote>
<p>Na een jaar of zeven in een business consultant-achtige rol te hebben gewerkt bij achtereenvolgens 's lands grootste openbaar vervoerder en 's lands grootste telecom provider was ik heel erg toe aan wat nieuws. Na een half jaartje heerlijk niksen en nadenken over waar ik dan wel zin in had, ben ik begin 2008 voor mezelf begonnen als webdeveloper. Een behoorlijke carrière switch eigenlijk. Gaandeweg ben ik meer werk aan de voorkant gaan doen en tegenwoordig noem ik mezelf dus Front-end Developer.</p>
</blockquote>
<p>(Hidden)</p>
<p>(Hidden)</p>
<h2>Aangemeld</h2>
<ul>
<li>Arjan Eising</li>
<li>Krijn Hoetmer</li>
<li>Matijs Brinkhuis</li>
<li>Peter-Paul Koch</li>
<li>Sander van Lambalgen</li>
<li>Tom Greuter</li>
<li>Sander Aarts</li>
<li>Jules Ernst</li>
<li>Glenn Glerum</li>
<li>Rein Groot</li>
<li>Wes Oudshoorn</li>
<li>Jan van Hellemond</li>
<li>Kilian Valkhof</li>
<li>Wim van Iersel</li>
<li>Tibo Beijen</li>
<li>Sander Leer</li>
<li>Edwin Martin</li>
<li>Wybe Weysters</li>
<li>Kor Dwarshuis</li>
</ul>
</content>
</entry>
<entry>
<title>Bijeenkomst op 3 december, in Rotterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2009/11/bijeenkomst-december"/>
<updated>2009-11-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/11/bijeenkomst-december</id>
<content xml:lang="nl" type="html"><p>Na een paar wilde dagen <a href="https://www.fronteers.nl/congres/2009">Fronteers 2009</a>, terug naar de orde van de dag: de maandelijkse bijeenkomsten :) Op donderdag 3 december komen we in Rotterdam bij elkaar bij <a href="http://www.dlma.nl/">DLMA</a>, waar een mooi programma voor ons in elkaar is gezet:</p>
<ul>
<li>18.30 uur: Inloop</li>
<li>19.30 uur: Waarom klanten niet willen luisteren</li>
<li>20.30 uur: ExpressionEngine 2.0</li>
<li>21.30 uur: Borrelen, netwerken, etc.</li>
</ul>
<h2>Waarom klanten niet willen luisteren</h2>
<p>Wat zou het werkende leven er toch stukken beter uitzien als de klant gewoon naar ons zou luisteren. De vragen die ze durven te stellen, zijn vaak meer een belediging van onze kwaliteiten dan iets waar je wat mee kan. En het technisch niveau is zo schrikbarend laag dat we geeneens meer aan uitleggen gaan beginnen - de meesten weten niet het verschil tussen een browser en een platform. Zucht... maar wat te doen?</p>
<h2>ExpressionEngine 2.0</h2>
<p>Op 1 december 2009 is het cms ExpressionEngine 2.0 eindelijk uitgebracht. Wat zijn de nieuwe features van deze nieuwe release? Hoe verhoudt ExpressionEngine zich tot Wordpress en Drupal? Een aantal praktisch tips voor een optimaal werken met ExpressionEngine. Een werkende EE 2.0 installatie zal aanwezig zijn om zelf in rond te neuzen!</p>
<h2>DLMA</h2>
<p>DLMA is <a href="http://www.dlma.nl/over-ons/contact.php">te vinden</a> op <a href="http://maps.google.nl/maps?f=q&amp;source=s_q&amp;hl=nl&amp;geocode=&amp;q=Nieuwe+Binnenweg+137,+3014+GJ+Rotterdam&amp;sll=52.469397,5.509644&amp;sspn=3.949239,9.876709&amp;ie=UTF8&amp;hq=&amp;hnear=Nieuwe+Binnenweg+137,+3014+Rotterdam,+Zuid-Holland&amp;ll=51.917485,4.466329&amp;spn=0.007809,0.027466&amp;t=h&amp;z=16&amp;iwloc=A">Nieuwe Binnenweg 137, 3014 GJ Rotterdam</a> en met het OV te bereiken door vanaf Rotterdam CS tram 4 te pakken en uit te stappen bij halte Mathenesserlaan.</p>
<p>Zoals gebruikelijk is de toegang gratis voor zowel leden als niet-leden, maar dien je je even <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">aan te melden</a>.</p>
<p>Tot op 3 december!</p>
</content>
</entry>
<entry>
<title>Presentations Fronteers 2009</title>
<link href="https://www.fronteers.nl/nl/blog/2009/11/presentations-fronteers-2009"/>
<updated>2009-11-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/11/presentations-fronteers-2009</id>
<content xml:lang="nl" type="html"><p>A short wrap-up of the presentations held at Fronteers 2009. Update: most videos are available on <a href="https://www.fronteers.nl/congres/2009/sessions">the sessions page</a>.</p>
<h2>Day 1</h2>
<ol>
<li>Molly Holzschlag - What's New With the Mobile Web</li>
<li>Peter-Paul Koch - <a href="http://www.quirksmode.org/blog/archives/2009/11/presentations_t.html">The Mobile Web, or the masochist’s guide to gleeful self-flagellation</a></li>
<li>Chris Heilmann - <a href="http://www.wait-till-i.com/2009/11/05/of-hamsters-feature-creatures-and-missed-opportunities-my-talk-at-fronteers-2009/">Of Hamsters, Feature Creatures and Missed Opportunities</a></li>
<li>Martin Savelkoul - Building and maintaining a complex frontend codebase</li>
<li>Stephen Hay - <a href="http://www.the-haystack.com/2009/11/05/slides-for-my-fronteers-2009-presentation-online/">The future state of layout</a></li>
<li>John Resig - <a href="http://www.slideshare.net/jeresig/understanding-javascript-testing">Understanding JavaScript Testing</a></li>
<li>Steve Souders - <a href="http://stevesouders.com/docs/fronteers-20091105.pptx">Even Faster Web Sites</a></li>
</ol>
<h2>Day 2</h2>
<ol>
<li>Douglas Crockford - <a href="http://crockford.com/codecamp/ajaxsecurity.ppt">Ajax Security</a></li>
<li>Pete LePage - <a href="https://www.fronteers.nl/_downloads/2009/html5-features-in-ie8.pptx">Using HTML5 Features In Internet Explorer 8</a></li>
<li>Jonathan Snook - <a href="http://www.slideshare.net/jonathansnook/the-type-we-want-2438381">The Type We Want: Using Fonts on the Web</a></li>
<li>Robbert Broersma - The challenges and rewards of writing a 120K JavaScript application</li>
<li>Thomas Fuchs - <a href="http://script.aculo.us/downloads/emile.pdf">Roll Your Own Effects Framework</a></li>
<li>Nicole Sullivan - <a href="http://www.slideshare.net/stubbornella/the-cascade-grids-headings-and-selectors-from-an-oocss-perspective-ajax-experience-2009">Object Oriented CSS</a></li>
<li>Dion Almaer &amp; Ben Galbraith - The Future of Web Applications</li>
</ol>
<h2>Other interesting links:</h2>
<ul>
<li><a href="http://www.flickr.com/search/?q=fronteers09&amp;s=int">Flickr photo's</a></li>
<li><a href="https://wave.google.com/wave/?pli=1#restored:search:with%253Apublic%20fronteers">Google Wave transcripts of day 2</a></li>
</ul>
<p>To be updated. Please add your links and comments.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 3 november, in Amsterdam: Sex, food, and JavaScript</title>
<link href="https://www.fronteers.nl/nl/blog/2009/10/bijeenkomst-november"/>
<updated>2009-10-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/10/bijeenkomst-november</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 3 november zal er een speciale Fronteers-bijeenkomst plaatsvinden bij Mirabeau te Amsterdam. Molly Holzschlag en Chris Heilmann, die naar Amsterdam zijn gekomen voor <a href="https://www.fronteers.nl/congres/2009/information">Fronteers 2009</a>, zullen er een speciale sessie houden getiteld &quot;Sex, food, and JavaScript.&quot;</p>
<p>Het belooft een avond te worden waar luchtigheid zal worden afgewisseld met advies over webtechnologieen, speciaal JavaScript. Molly zal de titel van de sessie nader verklaren.</p>
<p>Dit alles vindt plaats te Amsterdam bij Mirabeau op het <a href="http://mirabeau.nl/contact-amsterdam-centrum.asp">kantoor Weteringschans</a>. Inloop is vanaf 18 uur, en rond 19 uur zullen we beginnen. Zoals gebruikelijk is de toegang gratis. Er zijn circa 50 plaatsen beschikbaar, en er zullen lichte verversingen worden geserveerd.</p>
<p>Tot dan!</p>
<p><em>Update:</em> Ondertussen zit deze bijeenkomst <a href="https://www.fronteers.nl/bijeenkomsten/planning">helemaal vol</a>.</p>
<p><em>Update 2</em>: Helaas is Molly door haar rug gegaan en neemt ze rust zodat haar Fronteers 2009 sessie niet in gevaar komt. Ze zal er vanavond dan ook niet bij zijn.</p>
</content>
</entry>
<entry>
<title>Two free tickets for Fronteers 2009</title>
<link href="https://www.fronteers.nl/nl/blog/2009/10/two-free-tickets-for-fronteers-2009"/>
<updated>2009-10-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/10/two-free-tickets-for-fronteers-2009</id>
<content xml:lang="nl" type="html"><p>When we sold out Fronteers 2009 in September we loudly proclaimed that no more tickets were to be had. Point is: we weren't entirely truthful. There still are two tickets available. They're even free. You just have to do something in order to get them.</p>
<p>Microsoft, which sponsors Fronteers 2009, will give away two tickets to the two persons who create the most beautiful or interesting IE8 Web Slices.</p>
<p>The contest will be judged by Pete LePage, and he will consider the following three factors:</p>
<ol>
<li>Quality of the HTML (does it validate, is it clean, readable, etc)</li>
<li>Quality of the design of the Web Slice (does it look pretty)</li>
<li>Quality of the information (is the information relevant to the site, is it useful)</li>
</ol>
<p>In order to participate, leave a comment with a link to the page that contains your Web Slice. The submission period ends on <em>Monday 26 October</em>, and the winners will be announced later that week.</p>
<p>Here is some more information about Web Slices:</p>
<ul>
<li>Tutorial: <a href="http://blogs.msdn.com/ie/archive/2009/03/03/create-a-dynamic-web-slice-in-5-minutes.aspx">Create a dynamic Web Slice in 5 minutes</a></li>
<li>Tutorial: <a href="http://www.code-magazine.com/Article.aspx?quickid=0811052">Create Your Own Web Slices</a></li>
<li>Example: <a href="http://www.cindyli.com/site/comments/creating_a_web_slice_for_your_flickr_badge/">Creating a Web Slice for your flickr badge</a></li>
</ul>
</content>
</entry>
<entry>
<title>Fronteers 2009: sprekerswissel en rooster</title>
<link href="https://www.fronteers.nl/nl/blog/2009/10/fronteers-2009-sprekerswissel-en-rooster"/>
<updated>2009-10-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/10/fronteers-2009-sprekerswissel-en-rooster</id>
<content xml:lang="nl" type="html"><p>Over drie weken is het Fronteers 2009 congres, en er zijn een paar kleinigheden aan te kondigen.</p>
<p>Allereerst is er een sprekerswissel. Nate Koechley gaat het helaas niet halen om aanwezig te zijn, maar gelukkig hebben we <a href="http://snook.ca/">Jonathan Snook</a> bereid gevonden in zijn plaats te komen en ons bij te praten over <code>@font-face</code> en de interessante nieuwe designtechnieken die hiermee mogelijk zijn geworden.</p>
<p>Het <a href="https://www.fronteers.nl/congres/2009/schedule">congresrooster</a> is nu ook compleet, zodat je precies weet wie je wanneer kunt verwachten.</p>
<p>Helaas is het congres helemaal, volledig, voor de volle 100% uitverkocht. Er zijn geen kaartjes meer, zelfs niet als je het lief vraagt.</p>
<p>We hopen diegenen die wel een kaartje hebben op 5 november te kunnen begroeten.</p>
</content>
</entry>
<entry>
<title>Workshop mobiel web en W3C Widgets te Rotterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2009/10/workshop-mobiel-web-en-w3c-widgets-te-rotterdam"/>
<updated>2009-10-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/10/workshop-mobiel-web-en-w3c-widgets-te-rotterdam</id>
<content xml:lang="nl" type="html"><p>Aanstaande maandag geef ik een workshop mobiel web en W3C Widgets aan de Hogeschool van Rotterdam. Deze zal duren van 10:00 tot circa 17:00 uur.</p>
<p>Ik zal hier wat vertellen over het mobiele web en W3C Widgets in het bijzonder, en het is de bedoeling dat we ook zelf widgets gaan bouwen.</p>
<p>Naast circa 25 studenten heeft de Hogeschool van Rotterdam nog extra plaatsen weten los te peuteren voor algemeen geinteresseerden. Hierbij dus een oproep om te komen als dit je interessant lijkt.</p>
<p><a href="http://www.hogeschool-rotterdam.nl/page.html?id=123299">Locatie</a>:
Hogeschool Rotterdam,
lokaal MH.11.405
Museumpark 40,
3015 CX ROTTERDAM</p>
<p>Laat even een commentje achter als je van plan bent te komen, dan weten we ongeveer hoeveel externen we kunnen verwachten.</p>
<p>Mocht je een telefoon hebben die W3C Widgets aankan, dan is het verstandig die mee te nemen. Het gaat hier om Nokia S60 telefoons met de Vodafone Widget Manager OF elke telefoon met Opera Mobile 9.51 of hoger geinstalleerd.</p>
<p>In de <a href="http://www.betavine.net/bvportal/resources/widgets/research%22">Vodafone SDK</a> is een developer release van de Widget Manager voor S60 te vinden.</p>
<p>Ik hoop een aantal Fronteers-leden in Rotterdam te kunnen begroeten.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 15 oktober, in Utrecht</title>
<link href="https://www.fronteers.nl/nl/blog/2009/10/bijeenkomst-oktober"/>
<updated>2009-10-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/10/bijeenkomst-oktober</id>
<content xml:lang="nl" type="html"><p>Volgende week donderdag, 15 oktober, zijn we te gast bij <a href="http://www.efocus.nl/">eFocus</a> uit Utrecht.</p>
<p>Het programma is als volgt:</p>
<p>18.30 uur: Inloop
19.30 uur: Introductie van eFocus
19.45 uur: Hedwyg van Groenendaal, over een goed Internet Project Plan
20.45 uur: Netwerken, borrelen, etc</p>
<h2>Hedwyg van Groenendaal, over een goed Internet Project Plan</h2>
<p><a href="http://www.hedwyg.nl/overhedwyg.php">Hedwyg</a> adviseert, creëert, doceert, ontwikkelt en schrijft boeken. Zij is specialist in webdesign en al sinds 1993 actief met internet. In 1996 heeft ze haar eigen internet- en webdesignbureau <a href="http://www.viamilia.com/">Via Milia</a> opgericht en in 2000 werd daar een internetopleidingscentrum aan toegevoegd. In oktober 2001 verscheen haar eerste boek Flash ActionScript. In mei 2003 verscheen haar tweede boek Webdesign van concept tot realisatie, een handleiding voor hoe je een goed doordacht Internet Project Plan schrijft als basis voor een succesvolle website. Hierover zal zij meer vertellen.</p>
<p>Het adres van het hoofdkantoor van eFocus is Kanaalweg 29, 3526 KM Utrecht. Een <a href="http://www.efocus.nl/home/wie_is_efocus/route/">routebeschrijving</a> is online te vinden.</p>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen door zowel leden als niet-leden van Fronteers. Het is wel noodzakelijk om je <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">op te geven</a>, zodat we weten hoeveel mensen er naar de bijeenkomst komen.</p>
<p>Tot volgende week!</p>
</content>
</entry>
<entry>
<title>Fronteers 2009 - sprekers en kaartverkoop</title>
<link href="https://www.fronteers.nl/nl/blog/2009/09/fronteers-2009-sprekers-en-kaartverkoop"/>
<updated>2009-09-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/09/fronteers-2009-sprekers-en-kaartverkoop</id>
<content xml:lang="nl" type="html"><p>Zoals bekend wordt op 5 en 6 november aanstaande het <a href="https://www.fronteers.nl/congres/2009">Fronteers 2009 congres</a> gehouden. Hoewel pas de helft van de sprekers was aangekondigd, zijn we al vrijwel uitverkocht. Dit is een mooi resultaat, maar ook enigszins onverwacht.</p>
<p>In elk geval willen we hierbij graag de <a href="https://www.fronteers.nl/congres/2009/speakers">volledige lijst</a> van Fronteers 2009 sprekers bekend maken. Op de hoofdtrack zullen spreken:</p>
<ul>
<li>Dion Almaer en Ben Galbraith</li>
<li>Douglas Crockford</li>
<li>Thomas Fuchs</li>
<li>Stephen Hay</li>
<li>Molly Holzschlag (gesponsord door Opera)</li>
<li>Chris Heilmann</li>
<li>Peter-Paul Koch (gesponsord door Vodafone)</li>
<li>Nate Koechley</li>
<li>Pete LePage (gesponsord door Microsoft)</li>
<li>John Resig</li>
<li>Nicole Sullivan</li>
<li>Steve Souders</li>
</ul>
<p>Daarnaast zijn er twee sessies van een half uur, die gevuld zullen worden door</p>
<ul>
<li>Vasilis van Gemert (gesponsord door Mirabeau)</li>
<li>Laurens van den Oever (gesponsord door Xopus)</li>
</ul>
<p>Al met al staat dit garant voor een uitstekend congres.</p>
<p>Wat de kaarten betreft; die zijn bijna uitverkocht en de verkoop is op dit moment stilgelegd. Deze rappe uitverkoop heeft ons verrast; we hadden verwacht tegen deze tijd nog 30 tot 50 kaarten over te hebben. Over de zomer is er echter zo goed verkocht dat dat niet het geval is, en we hebben verder geen vragen gesteld en het sluitende budget dat we aan deze verkoop overhouden, met blijdschap geaccepteerd.</p>
<p>Gelukkig heeft de helft van de Fronteers-leden al een kaartje gekocht. Deze 50% komt overeen met onze ervaringen van vorig jaar, dus we nemen aan dat alle leden die dat willen, intussen toegang tot het congres hebben.</p>
<p>Op dit moment zijn we druk bezig om te inventariseren en te administreren, zodat we exact kunnen bepalen hoeveel kaarten we nog over hebben. We verwachten dat we nog 3 tot 8 kaarten kunnen verkopen.</p>
<p>Er gelden geen kortingen meer voor deze kaarten; ze zijn allemaal 350 euro. Wie het eerst komt, die het eerst maalt; als deze kaarten op zijn, zijn ze ook <em>echt</em> op.</p>
<p>Het begin van de verkoop zal het eerst aangekondigd worden op onze <a href="https://twitter.com/fronteers09">Twitter feed</a>. Volg ons dus als je het direct wil horen wanneer de laatste kaarten beschikbaar komen.</p>
<p>We hopen je op Fronteers 2009 te kunnen begroeten.</p>
</content>
</entry>
<entry>
<title>Fronteers Nazomerborrel</title>
<link href="https://www.fronteers.nl/nl/blog/2009/09/nazomerborrel"/>
<updated>2009-09-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/09/nazomerborrel</id>
<content xml:lang="nl" type="html"><p>Naar aanleiding van de zeer geslaagde <a href="https://www.fronteers.nl/blog/2009/07/vrijmifrobo">eerste VrijMiFroBo</a> in de 1e Klas Pub op Amsterdam CS wordt er op 18 september opnieuw een VrijMiFroBo 'georganiseerd'. Het is de bedoeling vanaf een uurtje of vijf gezellig een drankje te gaan doen bij <a href="http://www.kingarthur-utrecht.com/">King Arthur</a> in Utrecht.</p>
<p>King Arthur ligt <a href="http://maps.google.nl/maps?f=q&amp;source=s_q&amp;hl=nl&amp;geocode=&amp;q=Oudegracht+101-103+-+3511+AE+Utrecht&amp;sll=52.469397,5.509644&amp;sspn=3.480579,9.755859&amp;ie=UTF8&amp;ll=52.092849,5.116732&amp;spn=0.006855,0.019054&amp;t=h&amp;z=16&amp;iwloc=A">aan de Oude Gracht</a> op loopafstand van Utrecht CS. Als er net als in Amsterdam mensen zijn die na de borrel een hapje willen gaan eten, dan kan dat.</p>
<p>Laat hieronder even weten of je er ook bij bent. Da's handig voor je mede-Fronteers die jou altijd al eens onder het genot van een drankje wilden spreken. Mochten we nu met erg veel zijn dan kunnen we King Arthur vragen om een hoekje voor ons te reserveren.</p>
<p>Tot de 18e!</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 86 en 87: Formulieren en JavaScript</title>
<link href="https://www.fronteers.nl/nl/blog/2009/08/webrichtlijnen-formulieren-en-javascript"/>
<updated>2009-08-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/08/webrichtlijnen-formulieren-en-javascript</id>
<content xml:lang="nl" type="html"><p>Vermijd automatische doorverwijzing bij interactie met formulieren. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/formulieren/navigatie/automatische-doorverwijzing/#r-pd-13-4">R-pd.13.4</a>) Gebruik geen client-side script of formulieren als de enige manier om informatie op de site te bereiken. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/formulieren/navigatie/scriptlozen-zoekspiders/#r-pd-13-5">R-pd.13.5</a>)</p>
<p>Tegen de eerste webrichtlijn van vandaag <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/formulieren/navigatie/automatische-doorverwijzing/#r-pd-13-4">13.4</a> wordt vaak gezondigd. Veel websites gebruiken een selectiemenu als navigatie en springen gelijk na het selecteren naar de betreffende pagina. Is het niet zo dat veel bezoekers juist verwachten om vanzelf naar een pagina te worden gebracht na het kiezen uit een dergelijk selectiemenu? Is deze richtlijn daardoor niet verouderd? Zelfs usabilityguru Jakob Nielsen beweert dat regels af en toe veranderen omdat het gebruik van het web niet stilstaat, maar constant evolueert en de gebruikers mee-evolueren. Is het niet juist gebruikersvriendelijk om vanzelf te worden doorgelinkt? Daarnaast is een &quot;Ga&quot;-knop eenvoudig toe te voegen door deze tussen <code>&lt;noscript&gt;</code>-tags te zetten.</p>
<p>De tweede webrichtlijn <a href="http://www.webrichtlijnen.nl/richtlijnen/#r-pd-13-5">13.5</a> is om een website optimaal beschikbaar te maken voor zoekmachines. Zoekmachines ondersteunen in het algemeen geen JavaScript en ze zullen ook geen formulieren versturen. Om alle pagina's van een website geïndexeerd te krijgen, zullen ze moeten worden opgenomen in lijsten met links, die voor de zoekmachine toegankelijk zijn.</p>
<p>Deze praktijk zien we bij de meeste database-gebaseerde websites terugkomen en mag als algemeen bekend worden aangemerkt. Hoe ga jij hiermee om? Maak je lijsten met links speciaal voor zoekmachines of zijn de links dezelfde die gebruikers zien? Zijn er gevallen waarbij je juist niet de informatie via links toegankelijk maakt?</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 7 juli, in Arnhem</title>
<link href="https://www.fronteers.nl/nl/blog/2009/06/bijeenkomst-juli"/>
<updated>2009-06-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/06/bijeenkomst-juli</id>
<content xml:lang="nl" type="html"><p>Dinsdag 7 juli zal Fronteers te gast zijn bij de <a href="http://www.han.nl/">Hogeschool van Arnhem en Nijmegen</a> te Arnhem. Deze keer staat de bijeenkomst geheel in het teken van toegankelijkheid.</p>
<p>Het programma van 7 juli is als volgt:</p>
<ul>
<li>18.30 uur: Inloop</li>
<li>19.30 uur: Bram Duvigneau, over toegankelijkheid in de praktijk</li>
<li>20.30 uur: Jeroen Wijering, over usability &amp; accessibility van online video</li>
<li>21.30 uur: Netwerken, borrelen, etc.</li>
</ul>
<h2>Toegankelijkheid in de praktijk, door Bram Duvigneau</h2>
<p>Als blinde web-ontwikkelaar is Bram Duvigneau in een unieke positie om webtoegankelijkheid zowel vanuit de theoretische als de praktische kant te kunnen bekijken. Over die theorie is al genoeg gezegd en geschreven, maar wat is de praktijk? Werken alle blinden echt nog in Lynx en zijn ze anti-javascript of valt het allemaal wel mee? Wat kun je doen om je content en prachtige web 2.0 applicaties niet alleen toegankelijk, maar ook makkelijk in het gebruik te maken voor mensen die het web op een andere manier bekijken?</p>
<h2>Usability &amp; accessibility van online video, door Jeroen Wijering</h2>
<p>Het praatje van <a href="http://www.longtailvideo.com/">Jeroen</a> zal bestaan uit de volgende twee onderdelen:</p>
<ol>
<li>Usability, oftewel gebruiksvriendelijkheid. Dit onderdeel geeft een overzicht van de verschillende soorten plugins, codecs en servers die momenteel en binnenkort beschikbaar zijn om video te embedden en tonen in een website. Daarbij is er aandacht voor support in verschillende browsers, standaardisatie, problemen op het gebied van bandbreedte / firewalls, ontwikkelingen mbt settopboxes en mobiele telefoons en de tools om e.e.a. op te zetten.</li>
<li>Accessibility, oftewel toegankelijkheid. Dit onderdeel zoomt iets meer in op implementatie. Behandeld worden de WCAG regels voor online video, de vormgeving van videoplayers, closed captioning, closed audiodescriptions en het embedden. Aan de orde komen o.a. &quot;best practices&quot; voor video controls, het maken van en de voordelen van closed captions en een audiodescriptie en het zodanig embedden dat een pagina XHTML valid is én alternatieve browsers / systemen ondersteund worden.</li>
</ol>
<h2>Bereikbaarheid en opgave</h2>
<p>De HAN, afdeling Informatica, Media en Communicatie, is gevestigd aan de Ruitenberglaan 26, 6826 CC te Arnhem. Er is een <a href="http://www1.han.nl/restyle/route/route_new.xml?map=arnhem&amp;code=12&amp;lang=nl">routebeschrijving</a> te vinden op de website van de HAN.</p>
<p>Zoals gebruikelijk is de bijeenkomst gratis bij te wonen door zowel leden als niet-leden van Fronteers. Het is wel noodzakelijk om je <a href="https://www.fronteers.nl/bijeenkomsten/planning/#formulier-1">op te geven</a>, zodat we weten hoeveel mensen er naar de bijeenkomst komen.</p>
</content>
</entry>
<entry>
<title>Workshop CSS Positionering</title>
<link href="https://www.fronteers.nl/nl/blog/2009/06/workshop-css-positionering"/>
<updated>2009-06-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/06/workshop-css-positionering</id>
<content xml:lang="nl" type="html"><p>Donderdag 27 augustus zal Fronteers, met ondersteuning van <a href="http://isoc.nl/">ISOC</a>, een cursus CSS Positionering geven. Na deze cursus kan de kandidaat een ontwerp (denk aan een .psd bestand) omzetten naar HTML en CSS bestanden, zonder gebruik te maken van tabellen. De cursus is bedoeld voor mensen die met CSS bezig zijn, maar er nog weinig ervaring mee hebben.</p>
<p>De cursus zal gegeven worden in de <a href="http://www.kb.nl/">Koninklijke Bibliotheek</a> te Den Haag. Fronteers en <a href="http://isoc.nl/">ISOC</a> leden kunnen de cursus voor 10 euro bijwonen. Niet-leden betalen 35 euro. Beide bedragen zijn exclusief 19 procent btw. Er is slechts plaats voor tien personen, het is dus zaak dat je je tijdig opgeeft. Opgave kan middels het formulier op de pagina <a href="https://www.fronteers.nl/workshops/css-positionering">workshops/css-positionering</a>. Op die pagina is ook meer informatie te vinden over de cursus.</p>
<p>Fronteers wil meer cursussen geven dan alleen deze cursus. Heb je behoefte aan een bepaalde cursus op het gebied van front-end ontwikkeling? Laat het dan weten door een reactie achter te laten bij dit weblog bericht.</p>
</content>
</entry>
<entry>
<title>Front-end vraagstukken: Best practice voor 'superscript'</title>
<link href="https://www.fronteers.nl/nl/blog/2009/06/fe-vraag-best-practice-superscript"/>
<updated>2009-06-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/06/fe-vraag-best-practice-superscript</id>
<content xml:lang="nl" type="html"><p>In het kader van front-end vragen uit de vereniging (<a href="https://www.fronteers.nl/contact">vragen blijven welkom</a>) zoekt Jules Ernst advies over best practices inzake subscript en superscript.</p>
<p>Webrichtlijn 3.9 <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/tekstopmaak/#superscript-subscript">schrijft voor</a> dat superscript en subscript waar mogelijk vermeden moeten worden.</p>
<p>Er circuleren diverse oplossing om bijvoorbeeld het copyright-teken in kleine letters zodanig in de hoogte te krijgen dat de regelhoogte hier geen schade van ondervindt.</p>
<p>We zijn voor onze wiki op zoek naar een correcte oplossing om bijvoorbeeld de naam van ons programmabureau correct weer te geven. De naam luidt: Overheid heeft Antwoord(c), waarbij (c) het copyright teken moet zijn die als superscript in de lucht hangt.
De HTML zou er zo uit kunnen zien: <code>&lt;span class=&quot;copyright&quot;&gt;&amp;copy;&lt;/span&gt;</code></p>
<p>Is dit de manier waarop iedereen dit zou aanpakken, of valt er een alternatieve oplossing te bedenken? Welke CSS zou je gebruiken? (En mocht je je geheugen willen verfrissen over deze specifieke webrichtlijn, <a href="https://www.fronteers.nl/blog/2008/04/webrichtlijnen-definities-wijzigingen">zie de discussie bij de weblog post hierover</a>.)</p>
</content>
</entry>
<entry>
<title>Fronteers organiseert seminar tijdens Kings of Code</title>
<link href="https://www.fronteers.nl/nl/blog/2009/06/seminar-kings-of-code"/>
<updated>2009-06-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/06/seminar-kings-of-code</id>
<content xml:lang="nl" type="html"><p>Op dinsdag 30 juni vindt de tweede editie van <a href="http://kingsofcode.nl/">Kings of Code</a> plaats, een conferentie over de laatste ontwikkelingen en best practices op het gebied van web development. Net als vorig jaar is Fronteers een community partner, maar dit jaar organiseren we tijdens de <a href="http://www.kingsofcode.nl/pages/side-events">side events</a> op 29 juni een front-end seminar met drie interessante sprekers. Lees verder om te zien hoe Fronteers leden korting kunnen krijgen.</p>
<p><img src="https://fronteers.nl/_img/2009/06/kings-of-code.png" alt="Kings of Code" /></p>
<p>Bekende developers komen spreken en delen hun visie en knowhow over web development. Zo zullen Thomas Fuchs (Script.aculo.us) en Amy Hoy (Slash7) een presentatie geven over JavaScript Performance en zal Steven Pemberton (hoofd van de W3C XHTML2 Working Group) zijn visie delen over de toekomst van code. Andere onderwerpen die aan bod komen zijn o.a. SEO, CouchDB, User Experience en de filosofie achter Ruby on Rails.</p>
<p>Op het <a href="http://www.kingsofcode.nl/pages/side-events#sideevent_fronteers">seminar van Fronteers</a>, op 29 juni 's ochtends, zullen drie Fronteers leden komen spreken over hun specialiteit:</p>
<ul>
<li>Edwin Martin geeft een presentatie over Advanced jQuery Techniques</li>
<li>Nikolai Onken zal spreken over Dojo for mobile widgets</li>
<li>Marcel Beumer komt vertellen over wat je allemaal met <code>&lt;canvas&gt;</code> kan</li>
</ul>
<p>Alle drie de sprekers zullen niet bang zijn om code te laten zien, en lekker hands-on bezig te zijn met hun materie. Dit seminar is toegankelijk voor alle mensen die naar Kings of Code gaan.</p>
<p>Voor geïnteresseerden, Fronteers leden betalen € 175,- (i.p.v. € 195,-) voor Kings of Code bij het gebruik van de volgende promocode: <a href="http://kingsofcode.paydro.net/">fronteers</a>.</p>
</content>
</entry>
<entry>
<title>UX Book Club voorafgaand aan Fronteers bijeenkomst</title>
<link href="https://www.fronteers.nl/nl/blog/2009/06/ux-book-club"/>
<updated>2009-06-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/06/ux-book-club</id>
<content xml:lang="nl" type="html"><p>Voorafgaand aan de <a href="https://www.fronteers.nl/blog/2009/05/bijeenkomst-juni">Fronteers bijeenkomst van 11 juni</a> komen geïnteresseerden van <em>UX Book Club Groningen</em> bij elkaar. In augustus zal hun eerste officiële eigen bijeenkomst plaatsvinden. Het is de bedoeling dat tijdens bijeenkomsten boeken m.b.t. User Experience worden besproken en kennis met elkaar wordt gedeeld. Inmiddels hebben 11 designers, managers, studenten en docenten zich aangemeld.</p>
<p>Ben jij ook geïnteresseerd en lijkt het je leuk om je kennis te delen en van anderen te leren? Meld je even aan op <a href="http://uxbookclub.org/doku.php?id=groningen">http://uxbookclub.org/doku.php?id=groningen</a>, bij henkwijnholds [at] gmail.com of zorg dat je 11 Juni 2009 om 18:45u aanwezig bent op de Fronteers meeting. Neem dan je agenda en eventueel je favoriete UX boek mee!</p>
</content>
</entry>
<entry>
<title>Update Fronteers 2009</title>
<link href="https://www.fronteers.nl/nl/blog/2009/06/update-congres"/>
<updated>2009-06-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/06/update-congres</id>
<content xml:lang="nl" type="html"><p>Zoals we al eerder aangekondigd hebben, wordt op donderdag 5 en vrijdag 6 november aanstaande het <a href="https://www.fronteers.nl/congres/2009">Fronteers 2009 congres</a> gehouden in Felix Meritis in Amsterdam. Naast Nate Koechley en Steve Souders zullen ook <em><a href="http://ejohn.org/about/">John Resig</a></em> van jQuery en <em><a href="http://www.stubbornella.org/content/nicole-sullivan/">Nicole Sullivan</a></em> acte de presence geven om over JavaScript libraries respectievelijk Object Oriented CSS te praten. In totaal kan je 12 sprekers van wereldklasse verwachten; de overige acht sprekers zullen later aangekondigd worden.</p>
<p>Het congres wordt gesponsord door Vodafone; we zijn in onderhandeling met andere sponsors.</p>
<p>De <a href="https://www.fronteers.nl/congres/2009/tickets">kaartverkoop</a> is vandaag van start gegaan. Een van de meest gehoorde kritiekpunten vorig jaar was dat het onmogelijk was om een kaart voor 1 dag te kopen. Derhalve bieden we dit jaar wel eendagskaarten aan, naast de gebruikelijke kaarten voor beide dagen. Overigens is het exacte programma nog niet vastgesteld en kunnen we dus nog niet met zekerheid zeggen welke spreker op welke dag wordt ingepland.</p>
<p>Op dit moment geldt er een early-bird korting, die op vrijdag 10 juli afloopt. Deze korting is reeds verwerkt in de kaartprijs.</p>
<p>Naast deze korting krijgen <em>leden van Fronteers</em> nog een <em>extra forse korting</em> op de kaartprijs. Deze korting is niet verwerkt in de kaartprijs. <a href="https://www.fronteers.nl/leden">Alle leden</a> hebben vandaag een e-mail met uitleg hierover ontvangen. Mocht je als lid geen mailtje hebben gehad, neem dan even <a href="https://www.fronteers.nl/contact">contact</a> met ons op.</p>
<p>Ook Nederlandse studenten komen in aanmerking voor dezelfde korting. Neem hiervoor even <a href="https://www.fronteers.nl/contact">contact</a> met ons op.</p>
<p>Net zoals vorig jaar zitten lichte verfrissingen en een (warme) lunch op de dag(en) die je gekozen hebt bij de toegangsprijs inbegrepen. Daarnaast hebben alle bezoekers, dus ook degenen die uitsluitend een kaart voor vrijdag kopen, toegang tot de borrel op donderdagavond.</p>
<h2>Alle informatie over Fronteers 2009 op een rijtje:</h2>
<ul>
<li><a href="https://www.fronteers.nl/congres/2009">Algemene informatie</a></li>
<li><a href="https://www.fronteers.nl/congres/2009/venue">Locatie</a></li>
<li><a href="https://www.fronteers.nl/congres/2009/speakers">Sprekers</a></li>
<li><a href="https://www.fronteers.nl/congres/2009/tickets">Tickets</a></li>
</ul>
<p>Op de volgende manieren kun je op de hoogte blijven van alle vorderingen rondom Fronteers 2009:</p>
<ul>
<li><a href="http://feeds.feedburner.com/FronteersCongres">RSS feed</a></li>
<li><a href="https://www.fronteers.nl/congres#per-mail">E-mail</a></li>
<li><a href="https://twitter.com/fronteers09">Twitter (@fronteers09)</a></li>
</ul>
<p>We hopen je op 5 en 6 november te mogen begroeten op Fronteers 2009. Wij hebben er in ieder geval al zin in!</p>
</content>
</entry>
<entry>
<title>Verslag Docentendag</title>
<link href="https://www.fronteers.nl/nl/blog/2009/05/verslag-docentendag"/>
<updated>2009-05-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/05/verslag-docentendag</id>
<content xml:lang="nl" type="html"><p>Een uitverkochte studiedag, wat wil je als organisatie nog meer? De voortekenen waren goed. De scholen reageerden enthousiast en na enige dagen druppelden de eerste aanmeldingen binnen.</p>
<p>De opkomst op 7 mei was goed, van de 24 aanmeldingen kwamen 20 mensen naar Mirabeau te Amsterdam waar zij met koffie en koek werden onthaald. De dag begon met een iets gewijzigd programma; Raph kon namens het ICTU niet aanwezig zijn. Stephen nam zijn taken waar met als resultaat een geïmproviseerde lezing over Webrichtlijnen die goed werd ontvangen.</p>
<p>Sander Leer sprak over de inrichting van het <a href="http://sceneone.nl/frontend-in-het-ICA-curriculum.pdf">curriculum van de HAN</a> (Hogeschool Arnhem en Nijmegen). De vraag waar en hoe webdevelopment in het curriculum past kwam voortdurend terug. Zijn lezing ging over in een discussie over curriculuminrichting die zich tijdens de lunch in gematigde vorm voortzette.</p>
<p>Na de lunch mocht Stephen voor de tweede keer het podium bestijgen.
Ook voor hem een unicum, twee keer spreken op één studiedag. Hij vertelde over <a href="http://www.the-haystack.com/playground/presentations/fronteers-docentendag-2009/">CSS3 en de pijn van layouting</a>. CSS3 brengt ons, ergens ver in de toekomst, manieren om heel eenvoudig een mooie layout neer te zetten. Andere features, vooral op het gebied van het vormgeven van tekst, zijn gelukkig al eerder te gebruiken.</p>
<p>Peter-Paul Koch mocht als spreker <a href="http://quirksmode.org/presentations/docentendag/docentendag.pdf">de dag besluiten</a> met zijn visie op Fronteers, het web-onderwijs in Nederland en de rol van curricula daarin. Hij wil vooral de dialoog met de onderwijswereld aangaan, kijken waar een organisatie als Fronteers kan helpen met het vakgebied opstellen voor het onderwijs. Zijn vraag aan docenten was dan ook of de online curricula nuttig lesmateriaal waren, en wat eraan verbeterd kan worden.</p>
<p>Door de stortvloed aan informatie is besloten de rondleiding door Mirabeau te laten vervallen. De borrel vond uiteraard wel doorgang, de dag werd in stijl afgerond.</p>
<p>Na afloop van de docentendag hebben drie docenten zich aangemeld voor deelname aan de commissie onderwijs! Dit zijn Sander Leer (HAN), Mio van der Lijn (Hogeschool Rotterdam) en Yvonne Pouw (Grafisch Lyceum Rotterdam). Wij hopen met hen een leuke en waardevolle samenwerking tegemoet te gaan.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 84 en 85: Volgorde en groeperen van invoervelden</title>
<link href="https://www.fronteers.nl/nl/blog/2009/05/webrichtlijnen-tabindex-fieldset"/>
<updated>2009-05-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/05/webrichtlijnen-tabindex-fieldset</id>
<content xml:lang="nl" type="html"><p>Gebruik het tabindex attribuut om van de standaard tab-volgorde op formuliervelden af te wijken wanneer deze volgorde niet toereikend is voor correct gebruik van het formulier door toetsenbordgebruikers. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/formulieren/toegankelijkheid/toetsenbord-navigatie/#r-pd-13-2">R-pd.13.2</a>) Breng groepering van invoervelden aan door middel van het fieldset element. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/formulieren/toegankelijkheid/invoervelden-groeperen/#r-pd-13-3">R-pd.13.3</a>)</p>
<p>Zoals de Webrichtlijnen al melden: &quot;Gebruik het tabindex attribuut zo min mogelijk: de volgorde van de invoervelden in de HTML broncode bepaalt de standaard tabvolgorde. Deze is meestal toereikend.&quot; Het voorbeeld in <a href="https://www.fronteers.nl/blog/2008/09/webrichtlijnen-tabben">Webrichtlijn 52 &amp; 53: Tabben tussen links</a> is misschien een uitzondering; zie ook de discussie bij die post. Is hierin ondertussen nog iets veranderd? Is <code>tabindex</code> niet alleen nog maar relevant voor webapplicaties die last hebben van divitis en <a href="http://www.w3.org/TR/wai-aria-practices/#keyboard" title="WAI-ARIA Best Practices - Keyboard and Structural Navigation">&quot;toegankelijk&quot; gemaakt moeten worden</a>?</p>
<p>Interessanter is het groeperen van invoerelementen door middel van het <code>fieldset</code> element en het eventueel labelen van zo'n groep met het <code>legend</code> element.</p>
<p>Hoe vaak gebruik jij het <code>fieldset</code> element? Gebruik je dit bij ieder formulier, of alleen als een formulier aan bepaalde eisen voldoet? En doe je ook wel eens aan geneste <code>fieldset</code>s, zoals <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">hier op de site</a>, of is dat juist overkill?</p>
<p>Aangezien de Webrichtlijnen het niet als richtlijn opnemen en het valide is bij gebruik van een strict doctype (en conforming als je HTML 5 gebruikt): wanneer gebruik jij <em>wel</em> een <code>fieldset</code>, maar <em>geen</em> <code>legend</code>?</p>
<p>En omdat het stijlen van de <code>legend</code> soms &quot;erg lastig&quot; is, bieden de Webrichtlijnen je een alternatief: het gebruik van een <em>heading</em> in plaats van een <em><code>legend</code></em>. Wat vind jij hiervan? Gebruik jij liever <code>legend</code>s of <code>h1</code>–<code>h6</code>? Tegen welke problemen loop jij aan? Zijn er niet genoeg tutorials die laten zien dat het wel kan, zoals <a href="http://www.sitepoint.com/article/fancy-form-design-css/">Fancy Form Design Using CSS</a> dat doet?</p>
</content>
</entry>
<entry>
<title>Herinnering bijeenkomst 8 mei</title>
<link href="https://www.fronteers.nl/nl/blog/2009/05/herinnering-bijeenkomst-mei"/>
<updated>2009-05-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/05/herinnering-bijeenkomst-mei</id>
<content xml:lang="nl" type="html"><p>Voor iedereen die het gemist heeft en/of nog twijfelt: komende vrijdag zijn we te gast bij Mirabeau in Eindhoven. Op het programma staan een presentatie over CSS frameworks (zowel client-side als server-side) door <a href="http://kilianvalkhof.com/">Kilian Valkhof</a> en eentje over WAI-ARIA door <a href="http://arjaneising.nl/">Arjan Eising</a>.</p>
<p>Alle informatie is te vinden in <a href="https://www.fronteers.nl/blog/2009/04/bijeenkomst-mei" title="Bijeenkomst op 8 mei, in Eindhoven">de aankondigingspost</a>.</p>
<p><a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">Aanmelden</a> kan via de site.</p>
<p>Tot vrijdag! :)</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 8 mei, in Eindhoven</title>
<link href="https://www.fronteers.nl/nl/blog/2009/04/bijeenkomst-mei"/>
<updated>2009-04-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/04/bijeenkomst-mei</id>
<content xml:lang="nl" type="html"><p>Vrijdag 8 mei zijn we te gast bij <a href="http://www.mirabeau.nl/">Mirabeau</a> in Eindhoven. Een druk maandje voor ze, aangezien ze de <a href="https://www.fronteers.nl/blog/2009/04/docentendag">Docentendag</a> de dag ervoor in Amsterdam ook al hosten.</p>
<p>Het programma voor 8 mei is als volgt:</p>
<ul>
<li>18.30 uur: Inloop</li>
<li>19.15 uur: Vasilis van Gemert, over Mirabeau</li>
<li>19.30 uur: <a href="http://kilianvalkhof.com/">Kilian Valkhof</a>, over CSS frameworks (zowel client-side als server-side)</li>
<li>20.30 uur: <a href="http://arjaneising.nl/">Arjan Eising</a>, over <a href="http://www.w3.org/WAI/intro/aria">WAI-ARIA</a></li>
<li>21.30 uur: Netwerken, borrelen, etc.</li>
</ul>
<p><a href="http://www.mirabeau.nl/contact-eindhoven.asp">Mirabeau Eindhoven</a> is gevestigd in de Admirant toren te Eindhoven. De Admirant toren is uitstekend bereikbaar met de trein en ligt aan de centrum kant van het centraal station (loopafstand ongeveer 5 minuten):</p>
<p>Emmasingel 29-31
5611 AZ Eindhoven
<a href="http://www.mirabeau.nl/contact-eindhoven-auto.asp">Routebeschrijving met auto</a>
<a href="http://www.mirabeau.nl/contact-eindhoven-ov.asp">Routebeschrijving met OV</a></p>
<p>Zoals gebruikelijk is deze bijeenkomst gratis toegankelijk voor leden en niet-leden, maar dien je je wel even <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">aan te melden</a>.</p>
<p>Op donderdag 11 juni gaan we trouwens weer op bezoek in Groningen, maar daarover later meer. Zet de datum in ieder geval alvast in je agenda.</p>
<p>Tot de 8e!</p>
</content>
</entry>
<entry>
<title>Fronteers Vragenuurtje</title>
<link href="https://www.fronteers.nl/nl/blog/2009/04/vragenuurtje"/>
<updated>2009-04-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/04/vragenuurtje</id>
<content xml:lang="nl" type="html"><p>Hoewel we als vereniging op meerdere manieren open staan voor vragen en discussie (<a href="https://www.fronteers.nl/blog/2008/03/fronteers-op-irc">irc</a>, <a href="https://www.fronteers.nl/contact">contact</a>, <a href="https://www.fronteers.nl/vereniging/bestuur">bestuur</a>, <a href="https://www.fronteers.nl/vereniging/commissies">alle commissies</a>, <a href="https://www.fronteers.nl/blog">het weblog</a>), bestaat bij ons toch nog steeds het vermoeden dat de drempel om via deze methoden zomaar wat vragen te uiten te hoog ligt, en dat vragen, onduidelijkheden en discussiepunten bij (potentiële) leden ons vaak niet bereiken.</p>
<p>Dit vinden we een probleem, en daarom willen we nu een keertje expliciet (middels deze weblog post) iedereen aanmoedigen om vragen te stellen over de vereniging en onze bezigheden, danwel aan het bestuur, danwel aan de verschillende commissies, danwel aan andere leden.</p>
<p>Hoewel het bestuur en de commissievoorzitters zullen meelezen en vragen zullen beantwoorden, willen we tevens expliciet alle (actieve) leden aansporen om ook de hier gestelde vragen te beantwoorden, en jullie mening over discussiepunten te laten horen. Waar de vereniging mee bezig is wordt niet door hogerhand opgelegd, maar komt juist volledig voort uit wat <em>jullie</em> (c.q. wij) doen. Dus, brand maar los!</p>
</content>
</entry>
<entry>
<title>Status update Commissie Diplomering</title>
<link href="https://www.fronteers.nl/nl/blog/2009/04/status-update-commissie-diplomering"/>
<updated>2009-04-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/04/status-update-commissie-diplomering</id>
<content xml:lang="nl" type="html"><p>Na een periode van radiostilte hieronder vanuit de Commissie Diplomering een status update.</p>
<p>Het eerste jaar van de commissie was productief. We hebben een opzet gemaakt voor de examens, eerst theorie en daarna praktijk. Er zijn bijna 200 theorievragen opgesteld en er heeft een proefexamen plaatsgevonden. Allemaal goede zaken die er voor zorgden dat ik bij de algemene ledenvergadering dan ook positief meldde dat we in dit tempo door zouden blijven gaan.</p>
<p>In de praktijk ging het echter anders, dagelijkse werkzaamheden namen meer tijd in beslag dan verwacht. Dit had tot gevolg dat de voltallige commissie, exclusief de voorzitter (ikzelf dus), liet weten niet meer beschikbaar te zijn.</p>
<p>Op dit moment zijn we bezig met het invoeren van de vragen, zodat we ze kunnen testen. Voor de andere werkzaamheden, zoals het opzetten van verdere proefexamens en het opstellen van meer vragen, vraag ik bij deze vrijwilligers.</p>
<p>Dus mocht je willen bijdragen aan de commissie, neem dan contact op met de commissie, met <a href="https://www.fronteers.nl/vereniging/commissies/diplomering#formulier-1">dit formulier</a> of via <a href="http://www.twitter.com/wnas">twitter</a>.</p>
</content>
</entry>
<entry>
<title>Fronteers Docentendag</title>
<link href="https://www.fronteers.nl/nl/blog/2009/04/docentendag"/>
<updated>2009-04-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/04/docentendag</id>
<content xml:lang="nl" type="html"><p>Donderdag 7 mei zal de Fronteers Onderwijs Commissie samen met <a href="http://mirabeau.nl/">Mirabeau</a> een informele studiedag organiseren voor docenten front-end development. Er zijn lezingen—door sprekers uit het vakgebied—over onder andere de <a href="http://webrichtlijnen.nl/">webrichtlijnen</a>, <a href="http://www.w3.org/TR/css3-roadmap/">CSS3</a> en <a href="http://www.opera.com/company/education/curriculum">Opera's Web Standards Curriculum</a>. Diverse Nederlandse opleidingen zijn hiervoor ondertussen schriftelijk uitgenodigd.</p>
<p>De dag vangt aan om half elf. Tijdens het middaguur wordt een lunch verzorgd. Aan het einde van de dag kan met collega docenten geborreld worden. Tussendoor wordt naast de lezingen ook een rondleiding gegeven. Meer informatie, zoals adresgegevens en het programma, staat op <a href="https://www.fronteers.nl/docentendag">fronteers.nl/docentendag</a>.</p>
<p>Ben je een docent front-end en/of gerelateerde technieken? Aanmelden kan gratis door het <a href="https://www.fronteers.nl/docentendag#formulier-1">aanmeldformulier</a> in te vullen. Mocht je geen docent zijn, maar er wel een kennen, schroom dan niet hem of haar te verwijzen naar de <a href="https://www.fronteers.nl/docentendag">Docentendag pagina</a>.</p>
</content>
</entry>
<entry>
<title>Front-end vraagstukken: Gebruik van javascript libraries</title>
<link href="https://www.fronteers.nl/nl/blog/2009/03/fe-vraag-gebruik-javascript-libraries"/>
<updated>2009-03-27T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/03/fe-vraag-gebruik-javascript-libraries</id>
<content xml:lang="nl" type="html"><p>In het kader van front-end vragen uit de vereniging (<a href="https://www.fronteers.nl/contact">vragen blijven welkom</a>) stelt Jeroen Mulder een aantal gerelateerde vragen over het grootschalig gebruik van javascript libraries:</p>
<p>Unobtrusive Javascript is voor de meeste front-end ontwikkelaars een normale zaak geworden. Libraries als jQuery, Dojo en Prototype maken het met functionaliteiten als CSS selectors en event binding nog makkelijker om snel en unobtrusive functionaliteiten in een bestaand document te verwerken.</p>
<p>In een website waar op steeds meer plaatsen functionaliteiten in Javascript worden ontwikkeld, hoe zorg je er voor dat een middel tot groot developmentteam dit op een wijze doet die de onderhoudbaarheid en front-end performance niet verslechteren?</p>
<p>Specifiek voor degenen die uitgebreide ervaring hebben met het gebruik van een Javascript library: hoeveel werk doe je nog naast het gebruik van de library om de code herbruikbaar en onderhoudbaar te houden?</p>
<p>Ik denk dan met name aan de volgende drie vraagstukken:</p>
<ol>
<li>
<p>Hoe weet een ontwikkelaar of bepaalde Javascript nog wel wordt gebruikt? En zo ja, op welke pagina's? Het gebruik van CSS selectors in Javascript maakt het net als in CSS zelf niet makkelijk om te zien hoe en waar welke code van toepassing is.</p>
</li>
<li>
<p>Hoe debugged een ontwikkelaar een document waarbij de Javascript functionaliteit op een unobtrusive manier wordt toegewezen? Als verschillende stukken code invloed hebben op de interactie van een element, hoe weet een ontwikkelaar waar hij of zij moet zoeken voor de verantwoordelijke code?</p>
</li>
<li>
<p>Hoe organiseer je het beste vele kleine Javascript functionaliteiten verspreid over een grote website? Kies je voor een aanpak waarbij je de functionaliteit als plugin inpakt welke volledig autonoom kan werken? Of kies je voor een aanpak waarbij de functionaliteit gevoed moet worden met een stel elementen en instellingen, welke vervolgens zichzelf registreert bij de onDOMReady handler?</p>
</li>
</ol>
</content>
</entry>
<entry>
<title>Front-end vraagstukken: Communicatie over Webrichtlijnen</title>
<link href="https://www.fronteers.nl/nl/blog/2009/03/fe-vraag-communicatie-webrichtlijnen"/>
<updated>2009-03-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/03/fe-vraag-communicatie-webrichtlijnen</id>
<content xml:lang="nl" type="html"><p>De commissie online community is bezig een forum voor Fronteers op te zetten. Omdat dit alles niet zo snel gaat als we graag zouden willen, en we toch af en toe vragen langs zien komen waarbij we het idee hebben van &quot;<em>dat</em> zou perfect op het forum gevraagd kunnen worden,&quot; willen we tot de tijd dat het forum live gaat het weblog gebruiken om leden toch in staat te stellen in één keer een breed publiek te bereiken met hun front-end vragen. Mocht je zelf een front-end vraag uit de praktijk hebben waar je graag input vanuit de hele vereniging over zou hebben—algemeen, om een brede discussie over een onderwerp los te maken, danwel specialistisch, waarbij je zoekt naar iemand die ervaring heeft met het preciese onderwerp waar je meer over wil weten—<a href="https://www.fronteers.nl/contact">stuur hem dan in</a>. We zullen regelmatig één van de ingezonden vragen uitkiezen om op het weblog te plaatsen.</p>
<p>Mike van Hoenselaar trapt af met de eerste vraag:</p>
<p>De Webrichtlijnen zijn steeds vaker orde van de dag. Ook voor mij, ondanks dat ik geen websites ontwikkel voor overheden. Ik ben constant bezig om deze toe te passen. Toch loop ik tegen enkele dingen aan die ik graag beantwoord zou willen zien. Hoe kun je als front-end ontwikkelaar het beste intern de Webrichtlijnen communiceren, ook als je bedrijf geen overheidssites maakt en dus niet &quot;verplicht&quot; wordt om ze te gebruiken? Zowel naar je collega’s als naar je baas/management? Hoe hebben andere Fronteers dit intern geregeld?</p>
</content>
</entry>
<entry>
<title>Notulen bestuursvergadering 16 maart 2009</title>
<link href="https://www.fronteers.nl/nl/blog/2016/12/16-03-2009"/>
<updated>2009-03-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2016/12/16-03-2009</id>
<content xml:lang="nl" type="html"><p>Notulen bestuursvergadering Fronteers, 16 maart 2009 gehouden bij Info.nl in Amsterdam. Aanwezig: Arjan Eising, Krijn Hoetmer, Peter-Paul Koch, Sander van Lambalgen, Tom Greuter en Wybe Weysters (bij het agenda-onderdeel over de Commissie Onderwijs).</p>
<h2>Commissie Onderwijs</h2>
<p>Robert Jan Verkade heeft zijn functie als commissievoorzitter neergelegd. Wybe Weysters neemt voorlopig tot aan de volgende ALV het stokje van hem over en licht de stand van zaken in de commissie toe aan het bestuur.</p>
<p>7 mei a.s. organiseert de Commissie Onderwijs de <a href="https://www.fronteers.nl/docentendag">Docentendag</a>. Primair doel is om docenten op het front-end vlak kennis te laten maken met Fronteers en vice versa. Op de agenda van de docentendag staan ondermeer:</p>
<ul>
<li>
<p>Het <a href="http://www.opera.com/company/education/curriculum/">webstandaardencurriculum</a> van Opera.</p>
</li>
<li>
<p>Een rondleiding door een internetbedrijf (inz. Mirabeau Amsterdam, waar de docentendag plaatsvindt).</p>
</li>
<li>
<p>Presentaties over front-endgerelateerde onderwerpen.</p>
</li>
<li>
<p>Niels Sijm verzorgt namens de cie. de contacten met het ICTU.</p>
</li>
<li>
<p>PPK biedt aan om contact op te nemen met Opera. Wellicht kan er vanuit hun curriculum meer verteld worden. Een andere vraag die hierbij speelt is de vertaling van het curriculum naar het Nederlands. Wybe stelt voor om eerst binnen de cie. te kijken hoe dit aangepakt kan worden (wellicht in samenwerking met het ICTU). Als hij er niet uitkomt zal het bestuur die taak van hem overnemen.</p>
</li>
<li>
<p>Krijn zal de informatie over de docentendag online zetten. Wellicht kan dit aangevuld worden met een post van Wybe over de verworvendheden van de commissie Onderwijs tot nu toe.</p>
</li>
<li>
<p>Sander wil erover nadenken of het mogelijk is om docenten in het aankomende fronteersforum een eigen plek te geven.</p>
</li>
</ul>
<p>Als het Nederlandstalige curriculum eenmaal rond is, denkt Wybe dat de cie. Onderwijs een meer faciliterende houding kan aannemen. Zo zou de commissie eens in de twee jaar een docentendag kunnen organiseren en verder vooral naar de beschikbare bronnen moeten gaan verwijzen. In dit licht valt het onderhoud van het <a href="https://www.fronteers.nl/vereniging/commissies/onderwijs/bronnen">bronnenoverzicht van Maaike</a> ook onder de cie. Onderwijs.</p>
<h2>Fronteers Congres 2009</h2>
<h3>Financiële planning congres</h3>
<p>Sander wil graag inzicht in de financiële planning van het congres, met name om inzicht te krijgen in de risico's en hoe deze vermeden kunnen worden. Peter-Paul antwoordt:</p>
<ul>
<li>De kosten zijn even hoog als vorig jaar.</li>
<li>De kaartjes worden duurder.</li>
<li>We verwachten meer kaartjes te verkopen.</li>
<li>Momenteel is er nog niets bekend over sponsors. PPK houdt het bestuur op de hoogte.</li>
</ul>
<h3>Andere congresgerelateerde zaken</h3>
<ul>
<li>De locatie staat vast, het wordt <a href="http://www.felix.meritis.nl/">Felix Meritis</a> in Amsterdam.</li>
<li>De kaartverkoop start op zijn vroegst 11 mei.</li>
<li>Op de volgende bestuursvergadering bepalen we go / no go.</li>
</ul>
<h2>Betaalde artikelen op fronteers.nl</h2>
<p>PPK vroeg zich af of we wat zien in het plaatsen van bestaande artikelen op fronteers.nl. Het zou een stok achter de deur kunnen zijn om kwalitatief goede artikelen op de site tgeplaatst te krijgen.</p>
<p>Het voorstel wordt afgewezen. Er zijn veel vrijwilligers die zich belangeloos inzetten voor Fronteers. We zien daarom geen reden om in dit geval onderscheid te maken en auteurs wel te betalen.</p>
<h2>Nieuwe voorzitter gezocht</h2>
<p>PPK zou graag willen dat iemand anders de voorzittersrol van hem overneemt. Fronteers moet niet te afhankelijk zijn van PPK. De voornaamste taken zijn:</p>
<ul>
<li>Contact met commissievoorzitters onderhouden.</li>
<li>Overzicht houden van alle activiteiten.</li>
<li>Mensen achter de vodden aan zitten.</li>
</ul>
<p>Momenteel staat geen van de andere bestuursleden te trappelen om de voorzittersrol op zich te nemen.</p>
<h2>Korte opmerkingen</h2>
<p>P. Friederichs had de vraag opgeworpen of we een standaardcontract voor ZZP'ers op konden stellen. Hij zou hier zelf een voorzet voor doen, maar we hebben er niets meer van gehoord. Krijn gaat er achteraan.</p>
<p>Arjan stelt voor een wedstrijd te organiseren a la CSS OFF. Arjan wil de organisatie op zich nemen. De eerste prijs zou een toegangskaartje naar Fronteers 2009 kunnen zijn.</p>
<p>Arjan en Peter-Paul willen master classes voor beginners organiseren. PPK denkt aan iets als &quot;CSS-positioning voor mensen die pas onlangs overgestapt zijn op CSS&quot;. Arjan wil iets met JavaScript doen. Arjan neemt de organisatie op zich en maakt een draaiboek.</p>
<p>Er is een vraag van een lid binnengekomen over arbeidsvoorwaarden van front-enders. We vragen ons als bestuur af of we ons hiermee moeten/willen bemoeien. Arjan gaat inventariseren hoe andere verenigingen hiermee omgaan.</p>
<h2>Portefeuilleverdeling en doelen</h2>
<table>
<thead>
<tr>
<th>Portefeuilleverdeling</th>
<th>Voor</th>
<th>[Doel (per eind mei 2009)]</th>
</tr>
</thead>
<tbody>
<tr>
<td>Financiën en ledenadministratie</td>
<td>Krijn</td>
<td>Alle leden hebben betaald. Automatische incasso is uitgezocht.</td>
</tr>
<tr>
<td>Online community</td>
<td>Krijn</td>
<td>Profielen en login. Leden kunnen hun interesses, technieken en avatars kwijt in hun profiel. Als dit gerealiseerd is komt het forum.</td>
</tr>
<tr>
<td>Website</td>
<td>Krijn</td>
<td>Atom-feed toevoegen</td>
</tr>
<tr>
<td>Vacaturebank</td>
<td>Arjan</td>
<td>Prijs omlaag schroeven voor oude klanten? Bedrijf dat bijeenkomst organiseert mag gratis vacature plaatsen? Actief bedrijven aanschrijven. Evaluatie na afloop.</td>
</tr>
<tr>
<td>Congres</td>
<td>PPK</td>
<td>Kaartverkoop geregeld.</td>
</tr>
<tr>
<td>Bijeenkomsten</td>
<td>Arjan</td>
<td>De eerste is achter de rug, voor een tweede hebben we een datum.</td>
</tr>
<tr>
<td>Masterclasses</td>
<td>PPK</td>
<td>Meer over bekend.</td>
</tr>
<tr>
<td>ALV</td>
<td>Tom</td>
<td>Voorstel voor datum en locatie.</td>
</tr>
<tr>
<td>Webrichtlijnen</td>
<td>PPK</td>
<td>-</td>
</tr>
<tr>
<td>Onderwijs</td>
<td>Arjan</td>
<td>Verantwoordelijk voor weblogposts</td>
</tr>
<tr>
<td>Diplomering</td>
<td>PPK</td>
<td>Online proefexamen gereed.</td>
</tr>
<tr>
<td>Marketing</td>
<td>Sander</td>
<td>Visie (wat is onze doelgroep?) - brochure</td>
</tr>
<tr>
<td>Nieuwsbrief</td>
<td>Sander</td>
<td>-</td>
</tr>
<tr>
<td>Engelse reageerders</td>
<td>PPK</td>
<td>Link verwijderen vanaf quirksmode.org.</td>
</tr>
<tr>
<td>Correspondentie die buiten de $1)uilles valt</td>
<td>Tom</td>
<td>-</td>
</tr>
</tbody>
</table>
</content>
</entry>
<entry>
<title>Webrichtlijn 83: Invoervelden en labels</title>
<link href="https://www.fronteers.nl/nl/blog/2009/03/webrichtlijnen-invoervelden-labels"/>
<updated>2009-03-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/03/webrichtlijnen-invoervelden-labels</id>
<content xml:lang="nl" type="html"><p>Gebruik het label element om tekst expliciet met een invoerveld in een formulier te associëren. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/formulieren/toegankelijkheid/invoervelden-labels/#r-pd-13-1">R-pd.13.1</a>)</p>
<p>Deze richtlijn kun je op drie manieren naleven:</p>
<pre><code>&lt;!-- Mogelijkheid 1: --&gt;
&lt;label&gt;
Uw naam:
&lt;input type=&quot;text&quot; name=&quot;naam&quot;&gt;
&lt;/label&gt;
&lt;!-- Mogelijkheid 2: --&gt;
&lt;label for=&quot;naam&quot;&gt;Uw naam:&lt;/label&gt;
&lt;input type=&quot;text&quot; name=&quot;naam&quot; id=&quot;naam&quot;&gt;
&lt;!-- Mogelijkheid 3: --&gt;
&lt;label for=&quot;naam&quot;&gt;
Uw naam:
&lt;input type=&quot;text&quot; name=&quot;naam&quot; id=&quot;naam&quot;&gt;
&lt;/label&gt;
</code></pre>
<p>In het tweede geval heb je een <code>for=&quot;&quot;</code> en <code>id=&quot;&quot;</code> paartje nodig. Welke manier heeft jouw voorkeur? Waarom?</p>
<p>Hoe ver ga je met labels in het volgende voorbeeld:</p>
<p><img src="https://fronteers.nl/_img/2009/03/labels.png" alt="Een simpel formulier met tekstlabels en invoervelden, met achter 1 invoerveld het woord &quot;uur&quot; en voor 2 invoervelden een €-teken." /></p>
<p>En hack je in het volgende voorbeeld met positioning, of gebruik je gewoon 2 labels, ondanks <a href="http://www.456bereastreet.com/archive/200809/multiple_form_labels_and_screen_readers/">de problemen</a>:</p>
<p><img src="https://fronteers.nl/_img/2009/03/foutmelding.png" alt="Een invoerveld met een tekstlabel aan de linkerkant en een foutmelding eronder." /></p>
<p>Hoe vaak kom je nog tegen dat een checkbox of een radio button niet geassocieerd is met een tekstlabel? Erger je je dan ook zo enorm?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 82: Het gebruik van frames</title>
<link href="https://www.fronteers.nl/nl/blog/2009/02/webrichtlijnen-frames"/>
<updated>2009-02-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/02/webrichtlijnen-frames</id>
<content xml:lang="nl" type="html"><p>Gebruik geen frames op websites. Dit geldt voor zowel reguliere frames binnen framesets, als zogenaamde iframes. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/frames/richtlijnen/#r-pd-12-1">R-pd.12.1</a>)</p>
<p>Dat frames <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/frames/nadelen/">veel nadelen hebben</a>, weet (<a href="https://www.fronteers.nl/blog/2008/02/webrichtlijnen-r-pd-2-4-en-r-pd-2-5#reactie-718">bijna</a>) iedereen. <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/">HTML 5</a> ondersteunt ze dan ook niet, hoewel <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#frames-and-framesets">het tekenen ervan</a> wel gesneden koek is. Kunnen wij nog cases bedenken waarbij <code>frameset</code> en <code>frame</code> wel toegevoegde waarde hebben?</p>
<p>Geldt hetzelfde echt voor <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#the-iframe-element">inline frames</a>? Hier zijn toch wel goede toepassingen voor te bedenken? Of geldt het invoegen van een <a href="https://www.fronteers.nl/blog/2009/02/wordt-noorwegen-ons-voorbeeld#reactie-816">IE6 upgrade bannertje</a> niet als een goede case? Heeft een <code>iframe</code> dezelfde nadelen als gewone frames?</p>
<p>Wat vind jij trouwens van de nieuwe <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#attr-iframe-sandbox"><code>sandbox</code></a> en <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#attr-iframe-seamless"><code>seamless</code></a> attributen die HTML 5 introduceert voor inline frames?</p>
<p>En wordt het embedden van een HTML document met het <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#the-object-element"><code>object</code> element</a> eigenlijk ook gezien als een <code>iframe</code>? Of kun je op die manier toch die functionaliteit krijgen <em>en</em> een puntje scoren voor deze Webrichtlijn? Komt dit door een <a href="http://www.accessibility.nl/toetsing">formele inspectie</a>?</p>
</content>
</entry>
<entry>
<title>Wordt Noorwegen ons voorbeeld?</title>
<link href="https://www.fronteers.nl/nl/blog/2009/02/wordt-noorwegen-ons-voorbeeld"/>
<updated>2009-02-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/02/wordt-noorwegen-ons-voorbeeld</id>
<content xml:lang="nl" type="html"><p>Even los van het feit dat ze natuurlijk de <a href="http://www.opera.com/">beste browser</a> op aarde maken, zijn een aantal Noren begonnen met <a href="http://www.cjohansen.no/en/browsers/norway_tells_ie6_users_to_shape_up">een offensief</a> tegen Internet Explorer 6.</p>
<p>Ook <a href="http://blog.peterhaza.no/current-international-web-sites-warning-against-internet-explorer-6/">andere landen</a> volgen het voorbeeld. Ondertussen is op het <a href="https://www.fronteers.nl/blog/2008/03/fronteers-op-irc">Fronteers IRC kanaal</a> een discussie losgebarsten over de mogelijkheden hier in ons kleine kikkerlandje. We hebben <a href="https://www.fronteers.nl/leden">aardig wat leden</a> die werken aan de grootste Nederlandse sites (hoewel, Hyves is nog niet vertegenwoordigd ;-), dus gezamenlijk moeten we toch iets kunnen betekenen. Het is nog geen <a href="https://www.fronteers.nl/blog/2009/02/to-hell-with-bad-browsers">vinger</a>, maar wellicht kunnen wij helpen met iets als dit:</p>
<pre><code>&lt;!--[if lte IE 6]&gt;
&lt;div id=&quot;ie6-upgrade&quot;&gt;
&lt;p&gt;Je gebruikt een &lt;strong&gt;zeer verouderde versie&lt;/strong&gt; van Internet Explorer, die een hoop veiligheidsproblemen heeft en hedendaagse webstandaarden slecht ondersteunt. Voor een betere, snellere en veiligere ervaring op het gehele internet en om beter op de toekomst voorbereid te zijn, adviseren we je om &lt;a href=&quot;http://www.microsoft.com/windows/downloads/ie/getitnow.mspx&quot;&gt;Internet Explorer gratis te upgraden&lt;/a&gt;. Werk je bij een bedrijf waarbij je dit zelf niet kunt doen? Vraag dan je systeembeheerder(s) om deze essentiële update.&lt;/p&gt;
&lt;p&gt;Je kunt er ook voor kiezen om een &lt;strong&gt;andere browser&lt;/strong&gt; te gaan gebruiken: &lt;a href=&quot;http://www.opera.com/download/&quot;&gt;Opera&lt;/a&gt;, &lt;a href=&quot;http://www.mozilla.com/firefox/&quot;&gt;Firefox&lt;/a&gt;, &lt;a href=&quot;http://www.apple.com/safari/download/&quot;&gt;Safari&lt;/a&gt; of &lt;a href=&quot;http://www.google.com/chrome&quot;&gt;Chrome&lt;/a&gt; zijn allemaal gratis en vele malen veiliger en sneller dan Internet Explorer.&lt;/p&gt;
&lt;/div&gt;
&lt;![endif]--&gt;
</code></pre>
<p>Wie doet er mee? Laat het hieronder weten!</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 10 maart, in Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2009/02/bijeenkomst-maart"/>
<updated>2009-02-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/02/bijeenkomst-maart</id>
<content xml:lang="nl" type="html"><p>Dinsdag 10 maart zijn we te gast bij het <a href="http://www.ma-web.nl/">Mediacollege Amsterdam</a>.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18.30 uur: Inloop</li>
<li>19.15 uur: Hugo Verlaat, introductie over het Mediacollege Amsterdam, kortweg Ma</li>
<li>19.30 uur: <a href="http://bitstorm.nl/">Edwin Martin</a>, over jQuery en enkele geavanceerde mogelijkheden</li>
<li>20.30 uur: Vincent Hillenbrink &amp; Marcel Beumer, over SAFE en Suave</li>
<li>21.30 uur: Netwerken, borrelen, etc.</li>
</ul>
<h2>jQuery?</h2>
<p><a href="https://www.fronteers.nl/bijeenkomsten/2008/concept7">Dojo</a>, <a href="https://www.fronteers.nl/congres/2008/speakers#tom-occhino">MooTools</a>, en <a href="https://www.fronteers.nl/congres/2008/speakers#christian-heilmann">YUI</a> hebben van Fronteers al wat aandacht gehad, maar jQuery is nog wat onderbelicht gebleven. Dit gaat door onder andere Edwin dit jaar veranderen. Voor zowel beginnende als de al wat gevorderde jQuery gebruiker interessant. En nee, we zijn niet anti-Prototype, maar daarover wellicht <a href="https://www.fronteers.nl/congres/2009">later</a> meer :)</p>
<h2>SAFE? Suave?</h2>
<p>Stand-Alone Front-Ends, oftewel SAFE, is een combinatie van een ontwikkelaanpak en een architectuur, waarbij de front-end ontwikkelaar centraal staat. Een SAFE applicatie draait direct op elke web server, maar ook vanaf de desktop (bijvoorbeeld via een gemaild .zip bestand). Dankzij een &quot;virtuele server&quot; geschreven in JavaScript en een techniek genaamd &quot;page hijacking&quot; is voor zowel het ontwikkelen als het bekijken van een SAFE applicatie een browser voldoende. Deze aanpak heeft in de praktijk meestal een zeer positieve invloed op website projecten, niet alleen voor de web developer, maar ook voor andere project-teamleden.</p>
<p>Het web development framework Suave implementeert a) een virtuele JavaScript server, b) een aantal verschillende page hijacking strategieën en c) een meerstaps XSLT transformator die databound view templates genereert. Met Suave zijn verschillende front-ends ontwikkeld die zowel stand-alone als geïntegreerd in uiteenlopende architecturen draaien, waaronder Java en .NET. Daarnaast bevat het ook een command line build tool op basis van Rhino, die alle view templates in een web applicatie automatisch genereert. Suave is nog volop in ontwikkeling, maar omdat het spoedig - hopelijk 3e kwartaal - een open source project wordt, is een voorproefje zeker op z'n plaats.</p>
<p>Vincent en Marcel zullen ons vanavond iets meer vertellen over hun visie en de plannen die zij hebben.</p>
<h2>Waar?</h2>
<p>Het Ma is zowel met openbaar als met eigen vervoer goed te bereiken. Voor het gemak volgt hieronder een opsomming van mogelijke aanvliegroutes. Trein uitstappen op station Sloterdijk dan nog een korte wandeling van 15 minuten richting Contactweg 36. Tram 12 uitstappen op Haarlemmerweg dan nog 15 minuten lopen. Stadsbus 48 uitstappen op de halte Contactweg vervolgens nog 4 minuten lopen. Auto vanaf de A10/E22 naar de S102. Van de S102, Transformatorweg naar <a href="http://maps.google.com/maps?q=52.390911,4.856719">Contactweg 36, 1014 AN Amsterdam</a>. De auto kan op het parkeerterrein van het Mediacollege Amsterdam worden neergezet. Het is af te raden te parkeren voor de deur, aangezien daar een vergunning voor nodig is.</p>
<p>Zoals gebruikelijk is deze bijeenkomst gratis toegankelijk voor leden en niet-leden, maar dien je je wel even <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">aan te melden</a>.</p>
<p>Tot de 10e!</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 79, 80 &amp; 81: Tabellen voor lay-out</title>
<link href="https://www.fronteers.nl/nl/blog/2009/02/webrichtlijnen-tabellen-voor-layout"/>
<updated>2009-02-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/02/webrichtlijnen-tabellen-voor-layout</id>
<content xml:lang="nl" type="html"><p>Bij het aanpassen van een bestaande website: gebruik CSS voor de presentatie en lay-out van webpagina’s en zie af van tabellen voor lay-out. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/layout/richtlijnen/#r-pd-11-8">R-pd.11.8</a>) Bij het gebruik van tabellen voor lay-out: gebruik niet meer dan één tabel en gebruik zoveel mogelijk CSS voor de vormgeving van deze tabel. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/layout/richtlijnen/#r-pd-11-9">R-pd.11.9</a>) Bij het gebruik van tabellen voor lay-out: pas geen toegankelijkheidsmarkup toe. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/layout/richtlijnen/#r-pd-11-10">R-pd.11.10</a>)</p>
<p>Hmm, dus het <em>mag</em> wel... Of niet? <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/layout/richtlijnen/">&quot;Om aan de Webrichtlijnen te kunnen voldoen, is het gebruik van CSS voor lay-out echter vereist.&quot;</a> Lekker duidelijk?</p>
<p>Nog even in het kort de voordelen van tabellen voor lay-out:</p>
<ul>
<li>Het concept is relatief eenvoudig te begrijpen door webontwikkelaars</li>
<li>De meeste ontwikkelsoftware biedt vergaande ondersteuning voor het creëren van lay-out via tabellen</li>
<li>Ze ‘werken’</li>
</ul>
<p>En de nadelen:</p>
<ul>
<li>Ze voldoen niet aan het principe van scheiding tussen structuur en vormgeving</li>
<li>Ze zijn inflexibel in vergelijking tot CSS</li>
<li>Ze kosten webontwikkelaars meer tijd</li>
<li>Ze brengen een probleemloos onderhoud van de inhoud in het geding</li>
<li>Indien onnadenkend toegepast, kunnen ze de toegankelijkheid van een pagina belemmeren</li>
</ul>
<p>Richtlijn 11.9 lijkt een vrijbrief voor ontwikkelaars van sites die in de volgende categorieën vallen:</p>
<ul>
<li>De kennis en ervaring van de betrokken webontwikkelaars is ontoereikend</li>
<li>De om te bouwen site is te omvangrijk en maakt daarom het omzetten van de code te langdurig en te complex</li>
</ul>
<p>Zal deze achterdeur vaak gebruikt gaan worden, als de Webrichtlijnen <a href="http://webwereld.nl/nieuws/54738/gemeenten-moeten-eind-2010-aan-webrichtlijnen-voldoen.html">straks</a> <a href="https://www.fronteers.nl/blog/2009/02/webrichtlijnen-verplichten">verplicht worden</a> voor alle overheden? Wordt dit op dit moment al gedaan? Wie heeft hier ervaring mee?</p>
<p>Waarom zijn de Webrichtlijnen hier niet gewoon streng? Zou dat misschien de <a href="http://www.den-dopper.com/2009/02/10/hoe-kan-de-verkoopbaarheid-en-bruikbaarheid-van-de-webrichtlijnen-vergroot-worden/">verkoopbaarheid</a> nog moeilijker maken?</p>
</content>
</entry>
<entry>
<title>“To Hell With Bad Browsers”</title>
<link href="https://www.fronteers.nl/nl/blog/2009/02/to-hell-with-bad-browsers"/>
<updated>2009-02-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/02/to-hell-with-bad-browsers</id>
<content xml:lang="nl" type="html"><p>Precies 8 jaar geleden publiceerde Jeffrey Zeldman zijn artikel <a href="http://www.alistapart.com/articles/tohell">To Hell With Bad Browsers</a>. In datzelfde jaar kwam Internet Explorer 6 uit. En ondertussen bedienen we deze browser nog steeds met <a href="http://www.positioniseverything.net/explorer.html">hacks</a>. Wanneer wordt het tijd om IE6 ook de vinger te geven?</p>
<p>Hoe zit dit bij jullie? Hoeveel werk steek jij nog in IE6? Houden designers zich (onbewust) in, omdat ze geen PNG'tjes met alpha transparantie &quot;kunnen&quot; gebruiken? Is het echt zo erg om een beetje rond te strooien met een <code>zoom: 1;</code> hier en daar? Of zit het probleem vooral bij JavaScript gerelateerd werk?</p>
<p>Zijn de 4% IE6 gebruikers hier op fronteers.nl een beetje tekenend voor overige sites, of zit het meer in de buurt van de 60% (!), zoals op youngprofessionaloftheyear.nl (een site die vooral leeft bij de grotere bedrijven van Nederland)? Zien jullie ook Firefox pieken 's avonds en in het weekend, en diepe IE dalen rond diezelfde tijd? Wat kunnen we hier aan doen? <em>Willen</em> we hier wel wat aan doen? <a href="http://friendlybit.com/browsers/motivation-for-building-for-ie6/">Wie helpen we</a> als we <a href="http://www.robertnyman.com/2009/02/09/stop-developing-for-internet-explorer-6/">stoppen met hacken</a>?</p>
<p>Heeft het zin als we IE6 gewoon een <a href="http://www.dustindiaz.com/naked-day/">naked year</a> bezorgen, zoals Dan Cederholm <a href="http://www.simplebits.com/notebook/2009/02/13/iegone.html">zou <em>kunnen</em> doen</a>:</p>
<pre><code>&lt;!--[if !IE]&gt;&lt;!--&gt;
&lt;link rel=&quot;stylesheet&quot; href=&quot;screen.css&quot;&gt;
&lt;!--&lt;![endif]--&gt;
&lt;!--[if gte IE 7]&gt;
&lt;link rel=&quot;stylesheet&quot; href=&quot;screen.css&quot;&gt;
&lt;![endif]--&gt;
</code></pre>
<p>Waarom durven we het niet gewoon? <em>To Hell With Bad Browsers!</em> Of zijn we met z'n allen bang dat dat als &quot;To Hell With Some Of Our Users&quot; gezien gaat worden? De bezoekers mogen toch niet de dupe worden? Hoe lang houden we deze situatie nog in stand? Wordt het een combinatie van percentages bekijken en afwegen tegen de kosten van het ontwikkelen voor IE6 (die apart op een offerte kunnen staan), of is dit een vicieuze cirkel?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 73 t/m 78: Anatomie en toegankelijkheid van een tabel</title>
<link href="https://www.fronteers.nl/nl/blog/2009/02/webrichtlijnen-anatomie-tabellen"/>
<updated>2009-02-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/02/webrichtlijnen-anatomie-tabellen</id>
<content xml:lang="nl" type="html"><p>Gebruik het <code>th</code> (table header) element voor het beschrijven van een kolom of rij in een tabel met relationele informatie. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/relationele-informatie/anatomie/#r-pd-11-2">R-pd.11.2</a>) Groepeer rijen met alleen <code>th</code> (table header) cellen met het <code>thead</code> (table head) element. Groepeer de rest van de tabel met het <code>tbody</code> (table body) element. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/relationele-informatie/anatomie/#r-pd-11-3">R-pd.11.3</a>) Gebruik het <code>scope</code> attribuut voor het associëren van tabellabels (<code>th</code> cellen) met kolommen of rijen. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/relationele-informatie/toegankelijkheid/#r-pd-11-4">R-pd.11.4</a>) Gebruik het <code>header</code> [sic] en <code>id</code> element [sic] voor het associëren van tabellabels (<code>th</code> cellen) met individuele cellen in complexe tabellen. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/relationele-informatie/toegankelijkheid/#r-pd-11-5">R-pd.11.5</a>) Geef afkortingen voor tabellabels (<code>th</code> cellen) via het <code>abbr</code> (abbreviation) attribuut wanneer de lengte van de inhoud van het tabellabel zodanig van lengte is dat herhaling in een spraakbrowser irritatie kan wekken. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/relationele-informatie/toegankelijkheid/#r-pd-11-6">R-pd.11.6</a>) Gebruik het <code>caption</code> element of heading markup voor het geven van een koptekst boven een tabel. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/relationele-informatie/toegankelijkheid/#r-pd-11-7">R-pd.11.7</a>)</p>
<p>Iedereen zal de elementen <code>tr</code>, <code>th</code> en <code>td</code> wel kennen. Maar wanneer gebruik jij <code>thead</code>, <code>tbody</code> (expliciet) en <code>tfoot</code>? Het voorbeeld waarbij een <code>thead</code> bij een print (op papier dus) meerdere keren terugkomt kennen we ondertussen wel, dus die telt niet ;o)</p>
<p>&quot;Een rij met alleen <code>th</code> cellen&quot; is toch iets wat een stuk software zonder problemen automatisch als <code>thead</code> kan zien? Is dit misschien de reden waarom tabellen <a href="http://projectcerbera.com/web/study/2007/tables/">op zoveel verschillende manieren</a> in elkaar geklust worden? Aan de <a href="http://www.456bereastreet.com/archive/200410/bring_on_the_tables/">goede tutorials</a> ligt het niet, toch?</p>
<p>In onze oneindige zoektocht naar <em>toegankelijkheid</em> is het simpelweg gebruiken van <code>th</code> elementen natuurlijk niet genoeg. Een tabel &quot;toegankelijk maken&quot; moet namelijk wel moeilijk en op zichzelf al een niet bepaald toegankelijk klusje zijn. <code>scope</code>, <code>headers</code>, <code>id</code> en <code>abbr</code> attributen (ja, de Webrichtlijnen bevatten in R-pd.11.5 2 fouten, foei!) maken tabellen niet echt leuk om te bewerken. Zeker als die 4 eigenschappen geen invloed hebben op iets wat de content manager <em>ziet</em>. Als een tabel zo complex is dat je deze <em>extra</em> informatie mee moet geven, is het dan niet handiger (voor iedereen) om de data in de tabel anders te presenteren? En is het extra werk <a href="http://james.html5.org/tables/table_inspector.html">echt wel nodig</a>?</p>
<p>Waarom zou je <code>&lt;th abbr=&quot;Werkzaamheden Randstad&quot;&gt;Werkzaamheden in de Randstad en omstreken&lt;/th&gt;</code> gebruiken, in plaats van <code>&lt;th&gt;Werkzaamheden Randstad&lt;/th&gt;</code>, met eventueel <code>title=&quot;Werkzaamheden in de Randstad en omstreken&quot;</code>? Waarom wel rekening houden met &quot;spraakbrowsers&quot;, maar niet met smalle schermen (of designs)?</p>
<p>Waarom is het <code>summary</code> attribuut trouwens niet in een Webrichtlijn verwerkt? Voelden ze soms al <a href="http://esw.w3.org/topic/HTML/SummaryForTABLE">nattigheid</a> m.b.t. de toekomst en HTML 5? Voor iedereen die de ontwikkeling rondom HTML 5 niet volgt: <code>summary</code> en <code>abbr</code> zitten er (nog) niet in. Wat is jouw mening hierover?</p>
<p>En voor alle slimme CMS'en die <em>automatisch</em> <code>headers</code>, <code>id</code>, <code>scope</code> en <code>summary</code> (&quot;tabel bevat 5 rijen en 6 kolommen&quot;) attributen toevoegen om punten op <a href="http://www.webrichtlijnen.nl/toetsen/">de Webrichtlijnentoets</a> te scoren: hou daar eens mee op ;-)</p>
</content>
</entry>
<entry>
<title>Fronteers 2009 congres</title>
<link href="https://www.fronteers.nl/nl/blog/2009/02/fronteers-2009-congres"/>
<updated>2009-02-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/02/fronteers-2009-congres</id>
<content xml:lang="nl" type="html"><p>Aangezien het <a href="https://www.fronteers.nl/congres/2008">Fronteers 2008 congres</a> een doorslaand succes was, hebben <a href="https://www.fronteers.nl/vereniging/commissies/congres">we</a> besloten in 2009 opnieuw een technisch webcongres te organiseren. Het werk is nog maar net begonnen, maar we hebben data en een plaats vastgelegd. We kunnen ook al twee sprekers aankondigen.</p>
<p><a href="https://www.fronteers.nl/congres/2009">Fronteers 2009</a> zal gehouden worden op donderdag 5 en vrijdag 6 november in <a href="https://www.fronteers.nl/congres/2009/venue">Felix Meritis</a> te Amsterdam. De kaartverkoop start in mei, en net zoals vorig jaar kunnen Fronteers-leden een forse korting tegemoet zien.</p>
<p>We hebben <a href="http://stevesouders.com/">Steve Souders</a> bereid gevonden ons voor te lichten over de nieuwste inzichten in JavaScript performance, en <a href="http://nate.koechley.com/">Nate Koechley</a> zal spreken over de voortgaande professionalisering van front-end engineering.</p>
<p>Hoewel je nog maanden hebt om te beslissen of je wel of niet zult komen, raden we je aan 5 en 6 november alvast in je agenda te noteren. Op de <a href="https://www.fronteers.nl/congres">congrespagina</a> kan je je emailadres achterlaten; we sturen je dan het laatste congresnieuws door zodra het beschikbaar is.</p>
<p>Tot ziens op Fronteers 2009!</p>
</content>
</entry>
<entry>
<title>Webrichtlijnen verplichten?</title>
<link href="https://www.fronteers.nl/nl/blog/2009/02/webrichtlijnen-verplichten"/>
<updated>2009-02-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/02/webrichtlijnen-verplichten</id>
<content xml:lang="nl" type="html"><p>Heet van de pers: SP-kamerlid Ronald van Raak <a href="http://www.nu.nl/internet/1911961/sp-wil-verplichte-webrichtlijnen-alle-overheden.html">wil dat de Webrichtlijnen verplicht worden</a> voor alle overheden.</p>
<p>Zoals bekend is naleving van de Webrichtlijnen op dit moment niet verplicht, hoewel de ministeries er zich vrijwillig aan hebben gecommitteerd en zich over het algemeen aan deze verplichting houden. Lagere overheden zouden dit ook kunnen doen, maar tot op heden gaat dat zoals bekend mondjesmaat.</p>
<p>Staatssecretaris Bijleveld (Binnenlandse Zaken, CDA) <a href="http://www.minbzk.nl/actueel?ActItmIdt=116388">liet vorige maand weten</a> dat zij een wettelijke verplichting op gespannen voet vond staan met de eigen verantwoordelijkheden van de lagere overheden en er dus van af wilde zien.</p>
<p>Van Raak wil lagere overheden toch verplichten de Webrichtlijnen te volgen. Van Raaks argumentatie (zoals gerapporteerd op nu.nl) gaat overigens voornamelijk in op de voordelen die gehandicapten van de Webrichtlijnen ondervinden; bouwkwaliteit wordt niet genoemd.</p>
<p>Wat vinden wij hiervan? Moeten alle Nederlandse overheden verplicht worden de Webrichtlijnen na te volgen? Of blijft dit een eigen verantwoordelijkheid van de overheidsinstanties in kwestie?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 72: Tabellen voor relationele informatie</title>
<link href="https://www.fronteers.nl/nl/blog/2009/02/webrichtlijnen-tabellen-voor-relationele-informatie"/>
<updated>2009-02-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/02/webrichtlijnen-tabellen-voor-relationele-informatie</id>
<content xml:lang="nl" type="html"><p>Gebruik tabellen voor het weergeven van relationele informatie en niet voor lay-out. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/relationele-informatie/#r-pd-11-1">R-pd.11.1</a>)</p>
<p>Zojuist is er weer <a href="http://rondam.blogspot.com/2009/02/why-css-should-not-be-used-for-layout.html#comments">een hevige discussie</a> over <a href="http://www.flownet.com/ron/css-rant.html">het gebruik van tabellen voor layout</a> losgebarsten. Dat kunnen wij natuurlijk ook, met deze richtlijn!</p>
<p>Wie is het eens met de stelling &quot;CSS should be used for styling, tables should be used for layout&quot;? Zit wel wat in, toch? :-)</p>
<p>Gaan <a href="http://www.sitepoint.com/books/csswrong1/">CSS tables</a> (<code>display: table;</code>, etc.) een einde maken aan deze discussie, of heeft dat hetzelfde probleem? Het idee is toch dat je markup en layout van elkaar wilt scheiden? Is het volgende echt zoveel beter dan een table layout?</p>
<pre><code>&lt;style&gt;
#main { display: table-row; }
#nav { display: table-cell; }
#content { display: table-cell; }
&lt;/style&gt;
&lt;div id=&quot;main&quot;&gt;
&lt;div id=&quot;nav&quot;&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&quot;/&quot;&gt;Home&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;/over&quot;&gt;Over&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;/contact&quot;&gt;Contact&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt; &lt;!-- #nav --&gt;
&lt;div id=&quot;content&quot;&gt;
&lt;h1&gt;Over&lt;/h1&gt;
&lt;p&gt;Over ons...&lt;/p&gt;
&lt;p&gt;Etc.&lt;/p&gt;
&lt;/div&gt; &lt;!-- #content --&gt;
&lt;/div&gt; &lt;!-- #main --&gt;
</code></pre>
<p>Hiermee zit je toch net zo vast aan je layout als met het volgende:</p>
<pre><code>&lt;table&gt;
&lt;tr&gt;
&lt;td&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&quot;/&quot;&gt;Home&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;/over&quot;&gt;Over&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;/contact&quot;&gt;Contact&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/td&gt;
&lt;td&gt;
&lt;h1&gt;Over&lt;/h1&gt;
&lt;p&gt;Over ons...&lt;/p&gt;
&lt;p&gt;Etc.&lt;/p&gt;
&lt;/td&gt;
&lt;/tr&gt;
&lt;/table&gt;
</code></pre>
<p>Maar nu even zonder gekheid: wie weet er überhaupt nog hoe je tabellen gebruikt voor layout? Moet je deze discussie ooit nog aangaan in je werk, en zo ja, welke argumenten hoor je daar?</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 19 januari, in Breda</title>
<link href="https://www.fronteers.nl/nl/blog/2009/01/bijeenkomst-januari"/>
<updated>2009-01-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2009/01/bijeenkomst-januari</id>
<content xml:lang="nl" type="html"><p>Maandagavond 19 januari 2009 (gelukkig nieuwjaar overigens!) zijn we te gast bij <a href="http://www.e-sites.nl/">e-sites</a> in Breda.</p>
<p>Het programma is als volgt:</p>
<ul>
<li>18.30 uur: Inloop</li>
<li>19.15 uur: Introductie door e-sites</li>
<li>19:30 uur: <em><a href="http://andrescholten.nl/index.php/andre-scholten/">André Scholten</a></em>, over SEO</li>
<li>20.30 uur: <em><a href="http://annevankesteren.nl/about">Anne van Kesteren</a></em>, over HTML5 (duh), cross-site XMLHttpRequest en querySelector(All)</li>
<li>21.30 uur: netwerk en borrel</li>
</ul>
<p>Een <a href="http://www.e-sites.nl/over/1595-routebeschrijving.html">uitgebreide routebeschrijving</a> is te vinden bij e-sites. Kom je met de trein, dan is het <a href="http://maps.google.nl/maps?f=q&amp;hl=nl&amp;geocode=&amp;q=Reduitlaan+33,+4814+DC+BREDA&amp;sll=52.469397,5.509644&amp;sspn=3.882285,9.887695&amp;ie=UTF8&amp;ll=51.592922,4.770577&amp;spn=0.007732,0.019312&amp;t=h&amp;z=16">een klein kwartiertje lopen</a> vanaf station Breda.</p>
<p>Zoals gebruikelijk is deze bijeenkomst gratis toegankelijk voor leden en niet-leden, maar dien je je wel even <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">aan te melden</a>.</p>
<p>Tot de 19e!</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 67 &amp; 68: Richtlijnen voor het gebruik van CSS</title>
<link href="https://www.fronteers.nl/nl/blog/2008/12/webrichtlijnen-gebruik-van-css"/>
<updated>2008-12-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/12/webrichtlijnen-gebruik-van-css</id>
<content xml:lang="nl" type="html"><p>CSS dient in gelinkte bestanden geplaatst te worden en niet gemengd te worden met de HTML broncode. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/css/richtlijnen/#r-pd-9-1">R-pd.9.1</a>) Pagina's dienen bruikbaar te blijven wanneer CSS door een webbrowser niet ondersteund wordt. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/css/richtlijnen/#r-pd-9-2">R-pd.9.2</a>)</p>
<p>Wanneer vind jij dat je CSS wel mag mengen met HTML? Met andere woorden; wanneer zijn <code>&lt;style&gt;</code> (zonder <code>@import</code>) en <code>style=&quot;&quot;</code> verdedigbaar?</p>
<p>Wat gebruik je liever; <code>&lt;link rel=&quot;stylesheet&quot; href=&quot;foo.css&quot;&gt;</code> of <code>&lt;style&gt;@import url('foo.css');&lt;/style&gt;</code>? Of ontwijk je <code>@import</code> vanwege <a href="http://developer.yahoo.com/performance/rules.html#csslink">een andere regel</a>?</p>
<p>Hoe vaak test jij gemaakte templates of sites terwijl stylesheets uit staan? Welke tools gebruik je daarvoor? En waar let je dan op?</p>
<p>Gebruik jij trouwens nog steeds CSS hacks en/of filters om bijvoorbeeld Netscape en IE5 voor de Mac te ontzien? Of vinden we IE6 en IE7 met een paar conditional comments tegenwoordig al genoeg extra werk?</p>
<p>De webrichtlijnen maken er geen richtlijn van, maar <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/css/technieken/printen/">print stylesheets</a> (<code>rel=&quot;stylesheet&quot; media=&quot;print&quot;</code> dus) worden wel genoemd. Gebruiken we die ondertussen ook allemaal? En vind je dan dat alle pagina's perfect printbare equivalenten moeten hebben, of is het voor sommige pagina's (zoals een homepage) minder belangrijk? Hoe bepaal je trouwens hoe je de print stylesheet opzet? In hoeverre wordt hier (ook) een design voor gemaakt en over nagedacht?</p>
<p>En om af te sluiten met een flauw puntje: <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/css/technieken/css-vs-tabellen/">tabellen voor lay-out</a>. Hoe vaak heb jij zin om het <a href="http://giveupandusetables.com/">op te geven</a>? ;)</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 63 t/m 66: Links naar downloadbare bestanden</title>
<link href="https://www.fronteers.nl/nl/blog/2008/11/webrichtlijnen-downloadbare-bestanden"/>
<updated>2008-11-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/11/webrichtlijnen-downloadbare-bestanden</id>
<content xml:lang="nl" type="html"><p>Bij het aanbieden van downloadbare bestanden, informeer de bezoeker over hoe deze te downloaden en vervolgens te gebruiken. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/downloadbare-bestanden/#r-pd-8-20">R-pd.8.20</a>) Serveer bestanden met het correcte MIME type. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/downloadbare-bestanden/#r-pd-8-20">R-pd.8.21</a>) Open links naar downloadbare bestanden niet in een automatisch nieuw venster. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/downloadbare-bestanden/#r-pd-8-22">R-pd.8.22</a>) Serveer downloadbare bestanden niet met opzet een onbekend of incorrect MIME type om de browser tot een bepaald gedrag te dwingen. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/downloadbare-bestanden/#r-pd-8-23">R-pd.8.23</a>)</p>
<p>Hoe informeer jij bezoekers over bijvoorbeeld het type en de grootte van het bestand? Doe je dit middels het <code>title</code> attribuut, of tussen haakjes? En wat is in dat laatste geval handiger? De uitleg <em>in</em> de link, of <em>na</em> de link? Gebruik je voor het type van het bestand ook het <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/structured-client-side-storage.html#attr-hyperlink-type"><code>type</code> attribuut</a>, of gaat dat te ver?</p>
<p>Bij wie ligt volgens jou de verantwoordelijkheid voor correcte MIME-types? Hoort dit thuis in een CMS, bij de back-end ontwikkelaars of moet dit vastliggen in de serverconfiguratie? Dit zou een makkelijk te wijzigen lijstje met variabelen moeten zijn, maar waarom is dit zo vaak een probleem? Ligt dit aan (verouderde) software op de server, of aan onwetendheid bij een bepaalde partij? Hoe ga je hier mee om?</p>
<p>Links naar downloads niet laten openen in een nieuw venster is een duidelijke richtlijn, maar waarom moeten we voorkomen dat plugins in een browser het bestand ook <em>in</em> de browser openen? We mogen toch aannemen dat gebruikers hiervoor bewust gekozen hebben bij het installeren van een plugin? Of dat browser bouwers hier wat onderzoek naar gedaan hebben, voordat ze tijd en energie staken in het ontwikkelen van een plugin-architectuur? De <code>Content-disposition: attachment</code> opmerking leidt nog net niet tot een richtlijn, maar hoe kan het dat zoveel mensen het <em>niet</em> prettig vinden als een bestand in de browser geopend wordt, terwijl dit wel de standaard instelling is?</p>
<p>En bij welk type bestand trekken we de grens? Waarom zou je JPG'jes wel in je browser laten openen, maar PDF'jes niet? Als browsers straks zelf video's af kunnen spelen, worden ze dan gezien als downloads, of niet?</p>
</content>
</entry>
<entry>
<title>Lancering Fronteers Vacaturebank</title>
<link href="https://www.fronteers.nl/nl/blog/2008/11/lancering-vacaturebank"/>
<updated>2008-11-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/11/lancering-vacaturebank</id>
<content xml:lang="nl" type="html"><p>Vanaf vandaag is de <a href="https://www.fronteers.nl/vacaturebank">Fronteers Vacaturebank</a> voor iedereen open. In de afgelopen maanden hebben we de interesse gemeten en feedback van bedrijven verzameld. In de komende maanden hopen we, ondanks de kredietcrisis, een aantal mooie vacatures te mogen plaatsen, die zich met name op front-end web development richten.</p>
<p>Alle begin is moeilijk, maar we hebben 2 bedrijven gevonden die met ons van start willen gaan. Of beter gezegd; 2 bedrijven die op dit moment een vacature hebben, vonden ons en hebben contact gezocht. Hopelijk kunnen we Yes2Web uit Delft en Tappan Communicatie uit Den Haag snel aan de juiste mensen helpen. Ze zoeken respectievelijk een <a href="https://www.fronteers.nl/vacaturebank/front-end-webdeveloper-yes2web">Front-end Webdeveloper</a> en een <a href="https://www.fronteers.nl/vacaturebank/junior-webdeveloper-tappan">Junior Webdeveloper</a>.</p>
<p>De Vacaturebank bevatte al een tijdje enkele vacatures van onze <a href="https://www.fronteers.nl/congres">congres</a> sponsoren. Helaas zijn deze niet allemaal gevuld, maar hopelijk kunnen we door meer bekendheid en promotie van de Vacaturebank vanaf nu wat meer mensen bereiken. Dus, ken je iemand die nog op zoek is, ben je misschien zelf op zoek naar een andere baan, of wil je dat onzekere freelance leven eindelijk vaarwel zeggen? Neem eens een kijkje bij de <a href="https://www.fronteers.nl/vacaturebank">Fronteers Vacaturebank</a>.</p>
<p>Natuurlijk houden we je ook op de hoogte <a href="http://feeds.feedburner.com/FronteersVacaturebank">per RSS</a> en kun je <a href="https://www.fronteers.nl/vacaturebank#per-mail">je e-mailadres achterlaten</a>, zodat je nieuwe vacatures rechtstreeks in je mailbox ontvangt.</p>
<p>Tot slot; voor bedrijven die ook graag een vacature willen plaatsen, hebben we <a href="https://www.fronteers.nl/vacaturebank/vacature-toevoegen">enkele voorwaarden</a> opgesteld.</p>
</content>
</entry>
<entry>
<title>Herinnering: bijeenkomst op 13 november</title>
<link href="https://www.fronteers.nl/nl/blog/2008/11/herinnering-bijeenkomst-november"/>
<updated>2008-11-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/11/herinnering-bijeenkomst-november</id>
<content xml:lang="nl" type="html"><p>Voor iedereen dit het gemist heeft, of die nog twijfelt: aanstaande donderdag organiseert SWIS een bijeenkomst in Leiden.</p>
<p>De tijd vliegt: Aangezien we volgende maand op bezoek zullen zijn bij Concept7 in het noorden van het land, zal dit alweer de laatste bijeenkomst van het jaar in de Randstad zijn. Komt dus allen! Zie voor meer informatie <a href="https://www.fronteers.nl/blog/2008/11/bijeenkomst-november">de agenda</a> en <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">meld je aan</a>.</p>
<p>Lenny de Rooy, usability consultant bij Tribal Internet Marketing, zal een presentatie geven over het gebruiksvriendelijk maken van websites. Tijdens de presentatie zullen concrete tips worden gegeven waarmee je ervoor kunt zorgen dat bezoekers makkelijker hun weg kunnen vinden en de website beter zal renderen. De tips hebben betrekking op uiteenlopende aspecten, zodat de navigatie, teksten, formulieren, de zoekfunctie en het bestelproces, en zullen worden toegelicht aan de hand van diverse praktijkvoorbeelden.</p>
<p>Kamiel Wanrooij van EveryWeb Solutions zal samen met een collega een introductie geven van beperkingen die mensen kunnen hebben bij het gebruik van websites, en de meest gemaakte fouten en oplossingen hiervoor behandelen om deze doelgroep het gebruik van de website zo makkelijk mogelijk te maken. Dit doen ze door de deelnemers een beeld te geven van hoe een internetgebruiker met een (visuele) handicap een aantal websites ervaart.</p>
<p>Tot donderdag!</p>
</content>
</entry>
<entry>
<title>Aanpassing Normdocument Webrichtlijnen</title>
<link href="https://www.fronteers.nl/nl/blog/2008/11/aanpassing-normdocument-webrichtlijnen"/>
<updated>2008-11-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/11/aanpassing-normdocument-webrichtlijnen</id>
<content xml:lang="nl" type="html"><p>In de praktijk blijkt het soms een onhaalbare opgave om een bestaande website volledig in overeenstemming met de Webrichtlijnen te brengen. Dat doet zich met name voor bij hele grote websites of websites met heel veel oude content. De kosten die verbonden zijn aan het aanpassen van dergelijke oude content kunnen dan in de praktijk te hoog zijn. Een officiële toets door een van de inspectie-instellingen van de Stichting Waarmerk drempelvrij zal in de huidige situatie daarom altijd negatief uitpakken.</p>
<p>Om aan dit bezwaar tegemoet te komen overweegt de <a href="http://www.drempelvrij.nl/stichting">Normcommissie van de Stichting Waarmerk drempelvrij</a> een aanpassing van zogenoemde <a href="http://www.drempelvrij.nl/webrichtlijnen">Normdocument Webrichtlijnen caesura en sampling</a>. Voordat daartoe wordt overgegaan zou de Normcommissie hierover graag reacties ‘uit het veld’ horen.</p>
<p>Het gaat om de volgende toevoeging aan het Normdocument Webrichtlijnen caesura en sampling:</p>
<p>Bij bestaande grote websites kan er soms voor worden gekozen bestaande pagina’s niet in overeenstemming met het Normdocument Webrichtlijnen te brengen.
Dergelijke pagina’s kunnen op verzoek van de eigenaar van de website buiten de sample worden gelaten mits:</p>
<ol>
<li>De website aantoonbaar eerder online was dan de datum van vaststelling van het Normdocument (20 juli 2007).</li>
<li>Onmiskenbaar op de site wordt aangegeven dat pagina’s, die voor een vastgelegde cesuurdatum online zijn geplaatst, niet in overeenstemming met het Normdocument zijn en deze pagina’s als zodanig herkenbaar zijn.</li>
<li>Pagina’s, die na die cesuurdatum online zijn geplaatst, wel in overeenstemming met het Normdocument zijn.</li>
</ol>
<p>Het komt er in het kort dus op neer dat oude pagina’s onder bepaalde omstandigheden buiten de sample bij de toetsing aan de Webrichtlijnen kunnen worden gelaten (de sample is de steekproef van pagina’s die door de inspectie-instelling worden getoetst.)
Nieuwe pagina’s (dus na een door de webeigenaar zelf aangegeven datum) moeten er wel aan voldoen.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 59 t/m 62: Links naar e-mailadressen</title>
<link href="https://www.fronteers.nl/nl/blog/2008/11/webrichtlijnen-emailadressen"/>
<updated>2008-11-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/11/webrichtlijnen-emailadressen</id>
<content xml:lang="nl" type="html"><p>Links naar e-mailadressen: het e-mailadres waaraan het te versturen bericht is gericht dient zichtbaar te zijn in de linktekst. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/email-adressen/#r-pd-8-16">R-pd.8.16</a>) Links naar e-mailadressen: de URL in het href attribuut van een link naar een e-mailadres, mag alleen het mailto protocol en een e-mailadres bevatten. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/email-adressen/#r-pd-8-17">R-pd.8.17</a>) Pas geen technische maatregelen toe op de website om een e-mailadres te verhullen voor spam robots. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/email-adressen/#r-pd-8-18">R-pd.8.18</a>) Ga uiterst voorzichtig om met het publiceren van e-mailadressen van bezoekers van de website. Informeer de bezoeker over welke gegevens worden gepubliceerd op de site, of publiceer het e-mailadres van de bezoeker niet. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/email-adressen/#r-pd-8-19">R-pd.8.19</a>)</p>
<p>Ondanks dat het niet mag: welke hacks/trucjes gebruik jij om e-mailadressen in links &quot;onbereikbaar&quot; te maken voor spambots?</p>
<p>Een probleem met contactformulieren is dat het voor de bezoeker vaak niet duidelijk is naar wie dit formulier verzonden wordt en wat er onder water dus allemaal gebeurt. Hoe ga je om met dit probleem?</p>
<p>Een ander probleem met (contact)formulieren is dat (spam)robots deze ook automatisch invullen, en zo dus alsnog je inbox vervuilen. Ook bij gastenboeken of reactieformulieren komt dit veel voor. Hoe ga je hier mee om?</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 13 november, in Leiden</title>
<link href="https://www.fronteers.nl/nl/blog/2008/11/bijeenkomst-november"/>
<updated>2008-11-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/11/bijeenkomst-november</id>
<content xml:lang="nl" type="html"><p>Volgende week donderdag gaan we op bezoek bij <a href="http://www.swis.nl/">SWIS</a>, in leiden.</p>
<p>Het programma ziet er als volgt uit:</p>
<ul>
<li>18.30 uur: Inloop</li>
<li>19.30 uur: <em>Demo toegankelijkheid m.b.v. screenreader</em>, door Kamiel Wanrooij van <a href="http://everywebsolutions.nl/">EveryWeb Solutions</a></li>
<li>20.30 uur: <em>Usability tips &amp; tricks</em>, door Lenny de Rooy, Usability Consultant bij <a href="http://www.tribal-im.nl/">Tribal Internet Marketing</a></li>
<li>21.30 uur: Afsluiting, discussies, networking &amp; bier</li>
</ul>
<p>SWIS bevindt zich op een kleine tien minuten lopen van Leiden Centraal Station. De <a href="http://www.swis.nl/contact/adres_en_route">volledige routebeschrijving</a> staat online.</p>
<p>Lenny de Rooy, usability consultant bij Tribal Internet Marketing, zal een presentatie geven over het gebruiksvriendelijk maken van websites. Tijdens de presentatie zullen concrete tips worden gegeven waarmee je ervoor kunt zorgen dat bezoekers makkelijker hun weg kunnen vinden en de website beter zal renderen. De tips hebben betrekking op uiteenlopende aspecten, zodat de navigatie, teksten, formulieren, de zoekfunctie en het bestelproces, en zullen worden toegelicht aan de hand van diverse praktijkvoorbeelden.</p>
<p>Kamiel Wanrooij van EveryWeb Solutions zal samen met een collega een introductie geven van beperkingen die mensen kunnen hebben bij het gebruik van websites, en de meest gemaakte fouten en oplossingen hiervoor behandelen om deze doelgroep het gebruik van de website zo makkelijk mogelijk te maken. Dit doen ze door de deelnemers een beeld te geven van hoe een internetgebruiker met een (visuele) handicap een aantal websites ervaart.</p>
<p>Zoals gebruikelijk is deze bijeenkomst toegankelijk voor zowel leden als niet-leden. Dus, <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">meld je aan</a>.</p>
<p>Tot volgende week!</p>
</content>
</entry>
<entry>
<title>Herinnering: bijeenkomst op 16 oktober</title>
<link href="https://www.fronteers.nl/nl/blog/2008/10/herinnering-bijeenkomst-oktober"/>
<updated>2008-10-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/10/herinnering-bijeenkomst-oktober</id>
<content xml:lang="nl" type="html"><p>Voor iedereen dit het gemist heeft, of die nog twijfelt: aanstaande donderdag organiseert Mangrove een bijeenkomst in Rotterdam.</p>
<p>Met zo'n 50 aanmeldingen belooft het al redelijk druk/gezellig te worden. Zie voor meer informatie <a href="https://www.fronteers.nl/blog/2008/09/bijeenkomst-oktober">de agenda</a> en <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">meld je aan</a>.</p>
<p>Tot donderdag!</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 55 &amp; 56: Links voor seriële navigatie</title>
<link href="https://www.fronteers.nl/nl/blog/2008/10/webrichtlijnen-seriele-navigatie"/>
<updated>2008-10-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/10/webrichtlijnen-seriele-navigatie</id>
<content xml:lang="nl" type="html"><p>Geef blinde bezoekers extra mogelijkheden om lange lijsten met links over te slaan. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/seriele-navigatie/#r-pd-8-12">R-pd.8.12</a>) Geef boven aan pagina’s met veel onderwerpen een pagina-index met links om naar de verschillende onderwerpen te navigeren. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/seriele-navigatie/#r-pd-8-13">R-pd.8.13</a>)</p>
<p>Mogelijkheden om <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/seriele-navigatie/#lange-lijsten-overslaan">lange lijsten met links over te slaan</a>?! Horen die niet gewoon thuis in de screenreader software die men gebruikt? En wat is <em>lang</em>?</p>
<p>Met 'skiplinks' aan het begin van een document kan ik nog leven, net als met de 'back to top' links (hoewel die <a href="http://stijlgids.overheid.nl/actueel/weblog/rapport_usability_onderzoek_stijlgids/">volgens sommige rapporten</a> toch niet gebruikt worden, zie pagina 26 &amp; 60). Maar soms gaat het te ver.</p>
<p>Wat jullie?</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 16 oktober, in Rotterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2008/09/bijeenkomst-oktober"/>
<updated>2008-09-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/09/bijeenkomst-oktober</id>
<content xml:lang="nl" type="html"><p>Nu we allemaal weer hersteld zijn van het congres, gaan we verder met de orde van de dag. Voor iedereen die nog steeds niet genoeg heeft gekregen van zijn of haar collega's en ons vak, organiseert <a href="http://www.mangrove.nl/">Mangrove</a> op donderdag 16 oktober weer een bijeenkomst, in Rotterdam.</p>
<p>Het programma ziet er als volgt uit:</p>
<ul>
<li>18.30 uur: Inloop</li>
<li>19.30 uur: <em>The web's hidden agenda</em>, door Wietse Hage, co-founder en front-end developer bij Milq Media</li>
<li>20.30 uur: <em>Frameworks killed the front-end star</em>, door Joris Verbogt, developer bij Mangrove en Ruben Bos, front-end developer bij Mangrove</li>
<li>21.30 uur: Afsluiting, discussies, networking &amp; bier</li>
</ul>
<p>Volgens Ruben twee mooie presentaties, die beide in het teken staan van toekomstige ontwikkelingen in ons vakgebied en veel discussie teweeg zullen gaan brengen. Kom dus ook naar <a href="http://mangrove.nl/index.php?pageID=1700">Mangrove</a> de 16e!</p>
<p>Zoals gebruikelijk is deze bijeenkomst toegankelijk voor zowel leden als niet-leden, en dien je je even <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">aan te melden</a>, zodat ze bij Mangrove weten hoeveel biervaten er ingeslagen moeten worden.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 52 &amp; 53: Tabben tussen links</title>
<link href="https://www.fronteers.nl/nl/blog/2008/09/webrichtlijnen-tabben"/>
<updated>2008-09-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/09/webrichtlijnen-tabben</id>
<content xml:lang="nl" type="html"><p>Voorzie in een logische volgorde van de links op de pagina. Gebruik het tabindex attribuut om van de standaard tabvolgorde van links af te wijken wanneer deze volgorde niet toereikend is voor correct gebruik van de pagina door toetsenbordgebruikers. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/tabben/#r-pd-8-9">R-pd.8.9</a>) Maak het tabben naar links niet onmogelijk. Verwijder niet de focus rectangle rondom een link of de mogelijkheid tot focus op een link. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/tabben/#r-pd-8-10">R-pd.8.10</a>)</p>
<p>Wanneer gebruik jij het <code>tabindex</code> attribuut? Is onderstaande code een goede case, omdat gebruikers misschien verwachten dat je na je gebruikersnaam kunt tabben naar je wachtwoord? Of zou je de volgorde van de markup wijzigen?</p>
<pre><code>&lt;p&gt;
&lt;label for=&quot;user&quot;&gt;Gebruikersnaam:&lt;/label&gt;
&lt;input type=&quot;text&quot; name=&quot;user&quot; id=&quot;user&quot; tabindex=&quot;1&quot;&gt;
&lt;/p&gt;
&lt;p&gt;
&lt;label for=&quot;pass&quot;&gt;Wachtwoord:&lt;/label&gt;
(&lt;a href=&quot;/wachtwoord-vergeten&quot; tabindex=&quot;3&quot;&gt;vergeten?&lt;/a&gt;)
&lt;input type=&quot;password&quot; name=&quot;pass&quot; id=&quot;pass&quot; tabindex=&quot;2&quot;&gt;
&lt;/p&gt;
</code></pre>
<p>Begrijp jij nog welke waardes je het attribuut mag geven? <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/tabben/">Tussen 1 en 32768?</a> <a href="http://www.w3.org/TR/html4/interact/forms.html#adef-tabindex">Tussen 0 and 32767?</a> <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#tabindex">Of ook negatieve waardes?</a></p>
<p>Hoeveel designers en/of opdrachtgevers en/of marketingafdelingen willen de <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/tabben/#focus-rectangle">focus rectangle</a> nog steeds niet accepteren? Ga je de discussie aan, of geef je toe en doe je <code>:focus { outline: none; }</code> of iets wat erop lijkt? Of het nog mooiere <code>onfocus=&quot;this.blur()&quot;</code> en equivalenten?</p>
<p>En is dit alles wel ons probleem? Moeten we gebruikers die graag met het toetsenbord door een site navigeren niet gewoon uitleggen hoe <a href="http://en.wikipedia.org/wiki/Spatial_navigation">spatial navigation</a> werkt?</p>
<p>Of kunnen we niet gewoon <a href="http://www.sitepen.com/blog/2008/09/22/accessibility-experiment/">een site compleet opnieuw maken</a>? Eentje speciaal voor gebruikers die graag tabben?</p>
</content>
</entry>
<entry>
<title>Help mee het Fronteers 2009 congres te organiseren!</title>
<link href="https://www.fronteers.nl/nl/blog/2008/09/organisatie-fronteers-2009"/>
<updated>2008-09-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/09/organisatie-fronteers-2009</id>
<content xml:lang="nl" type="html"><p>Hoewel we nog druk bezig zijn met de laatste restjes afronding van Fronteers 2008 - waarvan overigens <a href="https://www.fronteers.nl/congres/2008/slides">de slides</a> nu grotendeels online staan, en <a href="http://www.bachelor-ict.nl/fronteers08">video's vanaf 3 oktober zullen gaan verschijnen</a> - is de realiteit van het organiseren van een congres dat eigenlijk <em>nu</em> al begonnen moet worden met nadenken over het congres van volgend jaar.</p>
<p>Een buitengewoon groot deel van de organisatie van Fronteers 2008 heeft in de handen van Peter-Paul Koch gelegen. Zoals ook op de ALV is genoemd is de hoeveelheid tijd die dit hem heeft gekost niet voor herhaling vatbaar. We zijn nu dus ook naarstig op zoek naar mensen die zich volledig willen inzetten voor de organisatie van het congres van volgend jaar, waarbij zeker een voorzitter die het voortouw wil nemen met het trekken van het hele traject met open armen zal worden ontvangen.</p>
<p>Gelukkig zal het wiel niet opnieuw uitgevonden moeten gaan worden, en er zal een draaiboek aanwezig gaan zijn (in ieder geval in eerste opzet) aan de hand waarvan de organisatie aangepakt kan worden. Tevens zal Peter-Paul betrokken zijn bij de commissie om zijn ervaringen en kennis te delen. Toch zal er nog steeds een flinke hoeveelheid werk verzet moeten worden om wederom een congres van hetzelfde wereldformaat als Fronteers 2008 neer te zetten, en natuurlijk zijn er ook verbeterpunten waar aandacht aan besteed zal moet worden (met de marketing van het congres bovenaan de lijst).</p>
<p>Lijkt het jou wel wat om &quot;mede-organisator van Fronteers 2009&quot; op je CV te kunnen zetten? Om de beste front-enders ter wereld samen te brengen hier in Nederland? Om in een enthousiast team te werken aan het opzetten van een wederom geweldig congres? <a href="https://www.fronteers.nl/vereniging/commissies/congres">Meld je dan nu aan voor de congres commissie!</a></p>
</content>
</entry>
<entry>
<title>Commissie Marketing zoekt leden</title>
<link href="https://www.fronteers.nl/nl/blog/2008/09/commissie-marketing-zoekt-leden"/>
<updated>2008-09-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/09/commissie-marketing-zoekt-leden</id>
<content xml:lang="nl" type="html"><p>Tijdens de algemene ledenvergadering bleek dat er vanuit het bestuur en vanuit de vereniging behoefte was om Fronteers meer te promoten. Vanuit dat idee is besloten de commissie marketing op te richten. Voor deze commissie zoeken wij nu leden, die zich samen willen inzetten voor meer bekendheid voor Fronteers en nieuwe communicatie- en promotiemogelijkheden te bedenken.</p>
<p>Met de mensen die zich aanmelden willen we samen de doelstellingen van de commissie opstellen en die in het komende jaar bereiken. De doelstellingen waar we momenteel aan denken zijn: Fronteers onder verschillende groepen bekender maken, de status van &quot;Fronteers-lid&quot; te verhogen, en meer leden te werven. De verwachting is dat deze commissie veel samen zal gaan werken met de commissie online community.</p>
<p>Wil je lid worden van deze commissie, stuur dan een email naar <a href="mailto:marketing@fronteers.nl">marketing@fronteers.nl</a> met daarin je motivatie en hoeveel tijd je verwacht beschikbaar te hebben voor de commissie marketing.</p>
</content>
</entry>
<entry>
<title>Verslag Fronteers 2008</title>
<link href="https://www.fronteers.nl/nl/blog/2008/09/verslag-fronteers-2008"/>
<updated>2008-09-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/09/verslag-fronteers-2008</id>
<content xml:lang="nl" type="html"><p>Twee dagen lang spraken grote (internationale) namen uit de industrie over alles wat met CSS, HTML, JavaScript, zoekmachineoptimalisatie, gebruiksvriendelijkheid en toegankelijkheid te maken heeft. Net als vorig jaar speelde Fronteers 2008 zich af in Pakhuis De Zwijger in Amsterdam. Een (onvolledige) sfeerimpressie:</p>
<h2>Fronteers congres 2008: Dag 1</h2>
<p>Al bij binnenkomst wijst de hoge concentratie iPhones en laptops erop dat we de goede zaal zijn binnengestapt. Aan CSS-guru Bert Bos de eer om het tweedaagse Fronteers-congres te openen. Bert Bos is een van de uitvinders van CSS (Cascading Style Sheets) en werkt momenteel mee aan de nieuwe CSS3-standaard, die front-end developers van een hoop kleine ergernissen zal verlossen.</p>
<h2>Ajax, JavaScript frameworks &amp; goede lunch</h2>
<p>Terwijl de eerste paneldiscussie, Webrichtlijnen, opstart, wordt het druk in de grote zaal voor de sessie van Backbase. Toch een beetje Nederlands voorloper als het om Ajax-technologie gaat. Medeoprichter Gerbert Kaandorp demonstreert het (commerciële) backbase-framework en legt uit hoe deze is opgezet en gebruikt kan worden. Een interessante presentatie.</p>
<p>Na het vechten om het laatste goed belegde broodje, wordt het tijd voor een veelbelovend middagprogramma! Tom Occhino, core developer aan JavaScript-framework Mootools, luidt het middagprogramma in met zijn keynote over object geörienteerd programmeren met JavaScript. Een interessante en vlotte presentatie, alleen is het jammer dat hij iets teveel tijd uittrekt voor het vergelijken van Mootools met 'concurrerende' JavaScript-frameworks.</p>
<h2>Video's zonder flash</h2>
<p>De discussies houden maar niet op in de meeting-room, waar inmiddels Dean Edwards, Stuart Langridge en Chris Heilmann met het publiek discussieren over Javascript. Anne van Kesteren, werkzaam bij Opera en heel actief in de werkgroep HTML5 bij het W3C, geeft een sessie over HTML5 in de grote zaal. Het hoogtepunt van de dag.</p>
<p>HTML5 is een nieuwe versie van HTML die voorlopig nog in ontwikkeling is. Anne toont ons onder meer het video-element, één van de laatste toevoegingen aan deze nieuwe HTML-standaard. Hierdoor wordt het mogelijk om video in websites te plaatsen zonder gebruik te maken van technieken zoals flash.</p>
<h2>Fronteers-partyboot</h2>
<p>De dag wordt afgesloten door Stephen Hay die een goed verhaal vertelt over maintainable CSS. Toch blijven de meningen verdeeld en blijven er verschillende werkwijzes om je CSS te onderhouden. Die discussie gaat 's avonds op de Fronteers-partyboot dan ook tot diep in de nacht rustig verder.</p>
<h2>Fronteers congres 2008: Dag 2</h2>
<p>De eerste dag bij Fronteers was het elke keer weer raak. In elke zin zat wel een verborgen sneer naar Internet Explorer en met name versie 6. Een hele taak dus voor Pete LePage om de kritische zaal enthousiast te krijgen over Internet Explorer 8. Pete LePage brandt gelijk los over de verbeteringen in Internet Explorer 8, momenteel alleen nog als beta te downloaden. De browser lijkt naast een betere ondersteuning voor moderne (en toekomstige) webstandaarden ook eindelijk de webontwikkelaar serieus te nemen. Ons dus.</p>
<h2>Verbeteringen voor developers</h2>
<p>Eindelijk is er een developer tool als Firebug ingebouwd, inclusief de mogelijkheid om van rendering engine te switchen. CSS 2.1 wordt ondersteund, client-side storage in HTML5 is opgenomen, er kunnen 6 inplaats van 2 html request tegelijk plaatsvinden en goed afvangen van de backbutton bij AJAX applicaties is eindelijk mogelijk. Ook komt Microsoft met een <a href="http://msdn.microsoft.com/en-us/library/cc196992.aspx">Webslice microformat</a>, waarmee website-onderdelen als widgets aan de bezoeker aangeboden kunnen worden.</p>
<h2>Conclusie over IE8?</h2>
<p>Mooie dingen, maar er mag ook gezegd worden dat veel verbeteringen al meerdere jaren in andere browsers zijn opgenomen. Van een goede paginasearch onder je CTRL+F-knop worden we niet meer enthousiast. Internet Explorer en ook het ontwikkelteam is serieus aan het worden en dat is mooi voor zowel ontwikkelaars als eindgebruikers.</p>
<h2>Maintainable Javascript</h2>
<p>Het Yahoo! developers network is lekker bezig. Eerder dit jaar waren veel developers bij Kings of Code al erg onder de indruk van Nate Koechley en dit keer komt Chris Heilmann een hoop nuttige dingen vertellen in de sessie Maintainable Javascript. Chris heeft aardig wat <a href="http://www.wait-till-i.com/books/">boeken</a> en publicaties op zijn naam staan, was Chief Development bij Yahoo! en vervult nu voor Yahoo! de rol van Developer evangelist. Zijn sessie is grappig, helder en geeft een hoop tips om Javascript onderhoudbaar te maken voor anderen. Veel internetbureaus zullen hem dankbaar zijn.</p>
<h2>Kiezen tussen Javascript frameworks</h2>
<p>In de meetingroom is weer een gezonde discussie gaande over Javascript Frameworks, Mootools (Tom Occhino), Backbase (Gerbert Kaandorp) en Base2 (Dean Edwards) zijn aanwezig. Conclusie van de ontwikkelaars zelf: de frameworks verschillen weinig, maar zorg dat je Javascript en het framework dat je kiest, met name als beginner, ook echt begrijpt.</p>
<h2>SEO &amp; Accessibility</h2>
<p>De volgende paneldiscussie, 'SEO en Accessibility', gaat over overeenkomsten tussen het toegankelijk maken en voor zoekmachines optimaliseren van websites. Naast Vasilis van Gemert van Mirabeau is de sympatieke Brit <a href="http://www.brucelawson.co.uk/">Bruce Lawson</a> aanwezig. In de discussie wordt onder andere de nieuwe <a href="http://www.w3.org/TR/wai-aria/">WAI-ARIA standaard</a> genoemd, een W3C specificatie voor het ontwikkelen van toegankelijke Rich Internet Applications.</p>
<p>Dan is het tijd voor de toegift van Fronteers 2008, Andy Clarke, die als een ‘Liam Galagher’ over de mogelijkheden van CSS positioning begint te zingen. Te gekke dingen, maar het merendeel lijkt meer geschikt als inspiratie dan realistische en onderhoudbare oplossingen.</p>
<p>Het congres was een succes. Wat was volgens jullie de beste sessie van deze editie?</p>
<p><em>Ruben Bos is auteur van <a href="http://www.webdesignrules.nl/">Webdesign Rules!</a> en werkt als front-end developer bij <a href="http://www.mangrove.nl/">Mangrove</a>.</em></p>
</content>
</entry>
<entry>
<title>Webrichtlijnen zoekt proefkonijnen</title>
<link href="https://www.fronteers.nl/nl/blog/2008/09/webrichtlijnen-zoekt-proefkonijnen"/>
<updated>2008-09-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/09/webrichtlijnen-zoekt-proefkonijnen</id>
<content xml:lang="nl" type="html"><p>Zoals bij menig front-end ontwikkelaar bekend zal zijn, heeft de Nederlandse overheid <a href="http://webrichtlijnen.nl/">Webrichtlijnen</a> ontwikkeld. Voor toegankelijke, snelle en beter te onderhouden websites, zullen alle websites van de Rijksoverheid eind 2010 aan deze Webrichtlijnen moeten voldoen.</p>
<p>Momenteel wordt een stappenplan ontwikkeld om toepassing van deze Webrichtlijnen gemakkelijker te maken, voor zowel de opdrachtgever als opdrachtnemer. Het doel daarvan, is het versterken van het opdrachtgeverschap bij de (door-)ontwikkeling van websites, zodat uiteindelijk de websites aan de Webrichtlijnen voldoen. Het stappenplan wordt in 2008 en 2009 getoetst door een tiental pilots. Mat behulp van de resultaten daarvan, wordt het gebruik van de Webrichtlijnen nog gemakkelijker in de toekomst.</p>
<p>Het programma Overheid heeft Antwoord (ICTU) is voor 2008 en 2009 op zoek naar organisaties die binnenkort een nieuwe website bouwen of een bestaande website gaan aanpassen. U komt dan in aanmerking als pilot website. Ons belang daarbij is het beoordelen van de praktische toepasbaarheid van alle stappen in het proces. Als uw webproject geselecteerd wordt, krijgt u gratis begeleiding door een adviseur bij het doorlopen van het proces.</p>
<p>Aanmelden als pilot, kan via de <a href="http://www.advies.overheid.nl/webrichtlijnen-stappenplan-pilot/">website van de Webrichtlijnen</a>. Daar is ook meer informatie te vinden, over de criteria waaraan een pilotwebsite moet voldoen.</p>
</content>
</entry>
<entry>
<title>Congres en ALV: een eerste terugblik</title>
<link href="https://www.fronteers.nl/nl/blog/2008/09/congres-en-alv-een-eerste-terugblik"/>
<updated>2008-09-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/09/congres-en-alv-een-eerste-terugblik</id>
<content xml:lang="nl" type="html"><p>Het succesvolle Fronteers Congres 2008 is helaas al weer achter de rug. We zijn nu druk bezig gedetailleerde verslaggeving te maken, waaronder een overzicht van alle presentaties. De hoofdsessies van vrijdag zijn op film gezet en verschijnen binnenkort op fronteers.nl. Natuurlijk kun je nu al terugblikken via bijvoorbeeld <a href="http://www.flickr.com/photos/tags/fronteers2008/">Flickr</a>, <a href="http://technorati.com/search/fronteers2008?authority=n&amp;language=n">Technorati</a> of <a href="http://delicious.com/search?p=forfronteers08">delicious</a>.</p>
<p>De gerenommeerde sprekers, van Bert Bos tot Dean Edwards, trokken veel mensen naar het Fronteers Congres. Veel bezoekers zijn direct met het kopen van hun kaartje lid geworden van Fronteers. Mede daardoor heeft onze vereniging momenteel 125 leden!</p>
<p>Helaas was het congres niet uitverkocht. Gebrek aan marketing is hiervoor waarschijnlijk de voornaamste reden. Sowieso hebben we de conclusie getrokken dat Fronteers wel meer op de voorgrond mag treden. Op de gisteravond gehouden ALV is op initiatief van de leden daarom een commissie <em>Marketing</em> opgericht. Kilian Valkhof heeft het voorzitterschap op zich genomen.</p>
<p>Ook de ALV was een succes. 25 leden waren aanwezig en zij stemden unaniem Sander van Lambalgen, Krijn Hoetmer en Peter-Paul Koch in het bestuur. Binnenkort verschijnt van de ALV een gedetailleerd verslag op fronteers.nl.</p>
</content>
</entry>
<entry>
<title>Fronteers 2008 van start</title>
<link href="https://www.fronteers.nl/nl/blog/2008/09/fronteers-2008-van-start"/>
<updated>2008-09-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/09/fronteers-2008-van-start</id>
<content xml:lang="nl" type="html"><p>Vandaag is De Dag; vanaf 08:00 uur verzamelen Nederlandse front-end professionals zich bij <a href="https://www.fronteers.nl/congres/2008/locatie">Pakhuis De Zwijger</a> om <a href="https://www.fronteers.nl/congres/2008/schedule">een tiental presentaties en een zestal panels</a> van vooraanstaande nationale en internationale specialisten op het gebied van CSS, JavaScript, toegankelijkheid, SEO, professionalisering en de <a href="http://webrichtlijnen.overheid.nl/">Webrichtlijnen</a> bij te wonen.</p>
<p>Aangezien er nog enige kaartjes beschikbaar zijn, hebben we ervoor gezorgd dat je zowel vandaag als morgen een kaartje aan de ingang kunt kopen. Vandaag (donderdag) kost dat 250 euro, morgen (vrijdag) kost het 150 euro. Let op: aan de deur geldt geen Fronteers ledenkorting. Deze kaartverkoop loopt via het online systeem (credit card of iDeal). We nemen geen contant geld aan.</p>
<p>Op = op; als we uitverkocht zijn, krijg je helaas geen toegang meer. Vroeg komen is dus beter dan laat komen.</p>
<p>Wellicht zien we enige van jullie straks of morgen op het congres.</p>
</content>
</entry>
<entry>
<title>Algemene Ledenvergadering Fronteers 2008</title>
<link href="https://www.fronteers.nl/nl/blog/2008/09/alv-agenda"/>
<updated>2008-09-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/09/alv-agenda</id>
<content xml:lang="nl" type="html"><p>Aanstaande donderdag en vrijdag vindt het Fronteers Congres 2008 plaats. Op vrijdagavond, aansluitend op het congres, vindt de jaarlijkse algemene ledenvergadering (ALV) van Fronteers plaats. Alle leden zijn hiervoor van harte uitgenodigd.</p>
<p>De ALV heeft plaats op vrijdag 12 september in <a href="http://www.dezwijger.nl/">Pakhuis de Zwijger</a>, van 19.00 tot 21.00 uur. De ALV wordt net als vorig jaar voorgezeten door Koen Willems.</p>
<p>Agenda:</p>
<ol>
<li>Welkom en opening door de voorzitter</li>
<li>Toelichting commissies</li>
<li>Toelichting op niet-ingevulde commissies</li>
<li>Ingebrachte beleidsvoorstellen</li>
<li>Begroting 2009</li>
<li>Kascommissieverkiezing</li>
<li>Bestuursverkiezing</li>
<li>Rondvraag</li>
<li>Sluiting</li>
</ol>
<p>Er zullen 4 beleidsvoorstellen worden ingebracht waarover gestemd moet worden. Deze voorstellen zijn:</p>
<p>Voorstel 1:
Het bestuur reserveert het komende jaar 500 euro voor reiskosten voor de commissie Onderwijs. Het gaat hierbij niet om reiskosten naar vergaderingen, maar om reiskosten van commissieleden die op bezoek gaan bij hogescholen of universiteiten. De voorzitter van deze commissie, Robert Jan Verkade, bepaalt wie wat en hoeveel mag declareren. Mocht hij het maximum van 500 euro bereikt hebben en meer geld nodig hebben, dan dient hij zich weer bij het bestuur te vervoegen.</p>
<p>Voorstel 2:
In de loop van 2009 gaat hopelijk de diplomering lopen. Als we 40 of meer gediplomeerde leden hebben, publiceren we een lijst op Fronteers.nl. (Gediplomeerde niet-leden tellen niet mee, maar worden wel gepubliceerd op fronteers.nl.)</p>
<p>Voorstel 3:
Er wordt een Congrescommissie ingesteld die het Fronteers Congres 2009 gaat organiseren. Deze commissie kan gebruik maken van Peter-Paul Koch's uitgebreide netwerk, maar Peter-Paul zal geen belangrijke rol in deze commissie op zich nemen. Belangrijkste taken van de commissie: het organiseren én het promoten van het Fronteers Congres 2009. Leden kunnen zich tot en met 31 oktober aanmelden voor deze commissie. Daarna krijgen zij tot 1 januari 2009 de tijd om hun plannen voor de organisatie te ontvouwen. Mocht het bestuur op 1 januari geen vertrouwen hebben in de plannen van deze commissie dan wil het bestuur Voorstel 4 in gang laten treden.</p>
<p>Voorstel 4:
Voor het Congres 2009 komt Peter-Paul Koch met een plan en regelt hij de sprekers. De organisatie en marketing besteden we uit aan een extern bureau. Hiervoor reserveren we 5.000,- euro.</p>
<p>Naast de beleidsvoorstellen vinden er ook verkiezingen plaats.</p>
<p>Verkiezing 1:
Er moet een kascommissie gekozen worden die de inkomsten en uitgaven van Fronteers gaat controleren. Gedacht wordt aan 2 personen. Zij mogen geen zitting hebben in het bestuur.</p>
<p>Verkiezing 2:
Peter-Paul Koch treedt af als bestuurslid, en is herkiesbaar. Verder hebben 2 leden zich aangemeld voor het bestuur: Krijn Hoetmer en Sander van Lambalgen. Zij presenteren zich hieronder in het kort. Voor de goede orde: alle drie kandidaten kunnen in het bestuur gekozen worden. Elke kandidaat moet dan 50% van de uitgebrachte stemmen halen. Het huidige bestuur geeft de voorkeur aan een bezetting van 5 man.</p>
<blockquote>
<p>Sinds 27 april 2007 ben ik bij (de oprichtingsplannen van) Fronteers betrokken. Eerst als kat-uit-de-boom-kijker, daarna als ppk-met-zijn-plannen-in-de-gaten-houder in de Commissie Diplomering (waar ik helaas niet veel heb kunnen betekenen; sorry Wilfred), daarna als loze-HTML-commentaarregels-toevoeger aan en CMS-implementeerder-en-hoster van onze website, fronteers.nl, die eind 2007 online ging.</p>
</blockquote>
<blockquote>
<p>Ik ben een freelance (ja, nog eentje) web applicatie ontwikkelaar, waarbij mijn verantwoordelijkheden zich meestal uitstrekken langs het hele traject van database architectuur tot het opzetten van de CSS. Het front-end gedeelte van deze werkzaamheden heeft mij altijd het meest aangesproken (vooral complex JavaScript werk), en toen ik begin Juli 2007 voor het eerst hoorde van Fronteers ben ik hier dan ook bijna gelijk bij betrokken geraakt.</p>
</blockquote>
<p>Het bestuur van Fronteers hoopt jullie aanstaande vrijdag te zien!</p>
<p>Met vriendelijke groet,</p>
<p>Tom Greuter
Secretaris Fronteers</p>
<p>P.S.
Als je van plan bent aanwezig te zijn, kun je je <a href="https://www.fronteers.nl/vereniging/bestuur#formulier-1">aanmelden</a>. Aanmelden is niet verplicht, maar geeft ons enig inzicht in het aantal leden dat van plan is te komen. Thnx!</p>
</content>
</entry>
<entry>
<title>Fronteers 2008 - nog 3 dagen</title>
<link href="https://www.fronteers.nl/nl/blog/2008/09/fronteers-2008-nog-3-dagen"/>
<updated>2008-09-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/09/fronteers-2008-nog-3-dagen</id>
<content xml:lang="nl" type="html"><p>De voorbereidingen voor <a href="https://www.fronteers.nl/congres/2008">Fronteers 2008</a> zijn zo goed als voltooid. Alle medewerkers, zowel Fronteers vrijwilligers als externe leveranciers, weten wat ze moeten doen, een draaiboek ligt klaar en tot nu toe zijn er geen onaangename verrassingen geweest.</p>
<p>We kregen wat vragen over de beschikbaarheid van kaartjes. Derhalve is het goed te vermelden dat we nog niet uitverkocht zijn en dat je nog gewoon een <a href="https://www.fronteers.nl/congres/2008/kaartverkoop">kaartje kunt kopen</a>. Om voor de korting in aanmerking te komen dienen Fronteers leden een kaartje te kopen via de link in de speciale mail die ze hebben ontvangen. (Niet gekregen? <a href="https://www.fronteers.nl/contact">Licht ons in</a>).</p>
<p>Inmiddels is ook het <a href="http://network.fronteers.nl/">ConfNetwork</a> online, waar alle bezoekers een login voor hebben gekregen. Heb je geen login gehad? <a href="http://network.fronteers.nl/editions/2008/user/new">Meld je dan even aan</a>.</p>
<p>We hopen je donderdag en vrijdag te kunnen begroeten.</p>
</content>
</entry>
<entry>
<title>Fronteers 2008: Anne van Kesteren</title>
<link href="https://www.fronteers.nl/nl/blog/2008/08/fronteers-2008-update"/>
<updated>2008-08-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/08/fronteers-2008-update</id>
<content xml:lang="nl" type="html"><p>De voorbereidingen voor <a href="https://www.fronteers.nl/congres/2008">Fronteers 2008</a> zijn in volle gang. Vandaag kunnen we aankondigen dat <a href="http://annevankesteren.nl/">Anne van Kesteren</a> heeft toegezegd een sessie over HTML5, en dan vooral over het <code>&lt;video&gt;</code> element, te gaan verzorgen.</p>
<p>Verder is de <a href="https://www.fronteers.nl/congres/2008/sessions">sessiepagina</a> live gegaan, zodat je weet waar onze <a href="https://www.fronteers.nl/congres/2008/speakers">sprekers</a> het precies over gaan hebben.</p>
<p>Alle <a href="https://www.fronteers.nl/leden">98 leden</a> hebben gisteravond een mailtje gehad met uitleg over hoe ze hun toegangskaart met korting kunnen aanschaffen. Heb je deze mail niet ontvangen? Neem dan even <a href="https://www.fronteers.nl/contact">contact op</a> met de ledenadministratie.</p>
<p>We hopen je op 11 en 12 september te kunnen begroeten.</p>
</content>
</entry>
<entry>
<title>Fronteers 2008: kaartverkoop van start; sprekerswijziging</title>
<link href="https://www.fronteers.nl/nl/blog/2008/08/update-fronteers-2008-congres"/>
<updated>2008-08-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/08/update-fronteers-2008-congres</id>
<content xml:lang="nl" type="html"><p>Zoals al eerder aangekondigd, zal op 11 en 12 september as. in Pakhuis De Zwijger te Amsterdam het tweede jaarlijkse Fronteers congres plaatsvinden.</p>
<p>De <a href="https://www.fronteers.nl/congres/2008/kaartverkoop">kaartverkoop</a> is inmiddels van start gegaan; je kunt dus bestellen. Het verdient de voorkeur dit redelijk snel te doen; met circa 250 kaarten in de verkoop en circa 150 voorinschrijvingen van geinteresseerden zou het wel eens rap kunnen gaan. Bovendien geldt tot en met 31 augustus een early-bird korting van 50 euro.</p>
<p>Fronteers-leden krijgen korting op de toegangsprijs en hebben hierover reeds apart bericht ontvangen. Komende week ontvangen zij per e-mail een speciale pagina waarop de korting verwerkt is. Leden hoeven dus <em>niet</em> een kaartje te kopen via <a href="https://www.fronteers.nl/congres/2008/kaartverkoop">de normale weg</a>. We houden genoeg kaarten voor leden achter de hand, dus paniek is niet nodig.</p>
<p>We hebben een wijziging in het programma. Nate Koechley van Yahoo! is helaas verhinderd aan Fronteers 2008 deel te nemen. Gelukkig hebben we <a href="http://www.stuffandnonsense.co.uk/">Andy Clarke</a>, schrijver van &quot;Transcending CSS: The Fine Art of Web Design&quot;, bereid gevonden een sessie over CSS Positioning op zich te nemen.</p>
<p>Ook de nevensessies beginnen nu vorm aan te nemen. Er zullen nevensessies zijn over CSS, de Webrichtlijnen, SEO en toegankelijkheid, de professionalisering van ons beroep, en twee sessies over JavaScript, beide met Dean Edwards.</p>
<p>Tijdens deze sessies kan het publiek vragen stellen aan de specialisten. Naast de sprekers zullen Chris Mills en Bruce Lawson van Opera, Vasilis van Gemert van Mirabeau, Koen Willems van de Webrichtlijnen en Wilfred Nas van Fronteers aan deze panels deelnemen.</p>
<p>De <a href="https://www.fronteers.nl/congres/2008/speakers">sprekerslijst</a> is nu redelijk definitief, maar wijzigingen zijn nog steeds voorbehouden.</p>
<p>Fronteers hoopt je op 11 en 12 september te mogen begroeten.</p>
</content>
</entry>
<entry>
<title>Herinnering bijeenkomst 19 augustus</title>
<link href="https://www.fronteers.nl/nl/blog/2008/08/herinnering-bijeenkomst-augustus"/>
<updated>2008-08-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/08/herinnering-bijeenkomst-augustus</id>
<content xml:lang="nl" type="html"><p>Als je je nog niet aangemeld hebt voor <a href="https://www.fronteers.nl/blog/2008/07/bijeenkomst-augustus">de bijeenkomst bij Indivirtual van volgende week</a>, doe dat dan nu :)</p>
<p>Indivirtual heeft ruimte gereserveerd voor zo'n 50 personen. Op dit moment hebben we <a href="https://www.fronteers.nl/bijeenkomsten/planning">ongeveer 30 aanmeldingen</a>. Hou hier dus even rekening mee.</p>
<p>Thomas Ummels heeft helaas deze week af moeten zeggen, maar Robert Gaal van <a href="http://wakoopa.com/">Wakoopa</a> heeft aangeboden de leegte op te vullen, met een interessant verhaal over het managen van je front-end code. Thanks Robert!</p>
</content>
</entry>
<entry>
<title>Fronteers 2008 congres - 11 en 12 september</title>
<link href="https://www.fronteers.nl/nl/blog/2008/08/fronteers-2008-congres-11-en-12-september"/>
<updated>2008-08-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/08/fronteers-2008-congres-11-en-12-september</id>
<content xml:lang="nl" type="html"><p>Zoals al eerder aangekondigd zal op 11 en 12 september het Fronteers 2008 congres plaatsvinden in Pakhuis De Zwijger te Amsterdam. Inmiddels is de <a href="https://www.fronteers.nl/congres/2008/sprekers">sprekerslijst</a> vrijwel compleet, en zijn ook de <a href="https://www.fronteers.nl/congres/2008/kaartverkoop">kaartprijzen</a> bekend.</p>
<p>Tien bekende sprekers zullen diepgravende technische sessies beleggen over onderwerpen die front-end developers na aan het hart liggen. JavaScript zal behandeld worden door onder andere <a href="http://dean.edwards.name/">Dean Edwards</a> en <a href="http://kryogenix.org/">Stuart Langridge</a>, terwijl <a href="http://cinnamon.nl/">Stephen Hay</a> en mede-uitvinder <a href="http://www.w3.org/People/Bos/">Bert Bos</a> zich over de geheimen van CSS zullen buigen. Tenslotte zal <a href="http://nate.koechley.com/">Nate Koechley</a> de verdergaande professionalisering van ons vakgebied bespreken.</p>
<p>De kaartverkoop zal zeer spoedig starten; inmiddels kan je de beschikbare informatie op je gemak bekijken op de <a href="https://www.fronteers.nl/congres/2008">Fronteers 2008 pagina's</a>.</p>
<p>Het congres wordt gesponsord door <a href="http://backbase.com/">Backbase</a>, <a href="http://info.nl/">info.nl</a> en <a href="http://mirabeau.nl/">Mirabeau</a>; verder zijn er nog enkele sponsor-slots open.</p>
</content>
</entry>
<entry>
<title>Algemene Ledenvergadering 2008</title>
<link href="https://www.fronteers.nl/nl/blog/2008/07/alv"/>
<updated>2008-07-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/07/alv</id>
<content xml:lang="nl" type="html"><p>Na afloop van het <a href="https://www.fronteers.nl/congres/2008">Fronteers congres</a>, zal de ALV van 2008 plaatsvinden. Tijdens deze vergadering zal teruggeblikt worden op het afgelopen jaar. Ook zal er besloten worden wat er het komende bestuursjaar gaat gebeuren met Fronteers. Wij roepen dan ook op, nu al van je te laten horen.</p>
<h2>Voorstellen van ideeën</h2>
<p>Heb je een goed idee, dat mede front-end ontwikkelaars ook zal aanspreken? Je kunt dat idee dan aandragen. Tijdens de vergadering zal gestemd worden op de ideeën. Je kunt je idee vooraf al bespreken met andere leden in het <a href="https://www.fronteers.nl/blog/2008/03/fronteers-op-irc">IRC kanaal</a> of tijdens een van de <a href="https://www.fronteers.nl/bijeenkomsten/planning">komende bijeenkomsten</a>.</p>
<p>Om een idee aan te dragen kun je een e-mail sturen naar <a href="mailto:bestuur@fronteers.nl">bestuur@fronteers.nl</a>. We verzoeken deze ideeën in te sturen voor 31 augustus.</p>
<h2>Bestuur</h2>
<p>Tijdens de ALV zal ook het bestuur van Fronteers gekozen worden. Conform de statuten dient 1 bestuurslid zijn zetel ter beschikking te stellen, terwijl de overige blijven zitten. Dit om de continuïteit in het bestuur te garanderen.</p>
<p>Dat bestuurslid zal Peter-Paul Koch zijn; hij treedt af en stelt zich herkiesbaar. Daarnaast stelt Krijn Hoetmer, die reeds geruime tijd de facto penningmeester is, zich verkiesbaar. Tom Greuter en Arjan Eising zullen als bestuursleden aanblijven.</p>
<p>Het huidige bestuur voelt de behoefte aan een vijfde lid, zodat we wat meer handen hebben om de taken over te verdelen. Geïnteresseerde leden kunnen zich aanmelden op <a href="mailto:bestuur@fronteers.nl">bestuur@fronteers.nl</a>. Dat dient ook voor 31 augustus te gebeuren.</p>
<p>Tijdens de ledenvergadering zal gestemd worden, en alle bestuurskandidaten met meer dan 50 procent van de stemmen komen in het bestuur. De gekozen bestuursleden kiezen vervolgens uit hun midden een voorzitter, secretaris en penningmeester.</p>
<p>Op een later tijdstip wordt meer gepubliceerd op dit weblog, over de agenda, aangedragen ideeën en kandidaten voor het bestuur.</p>
</content>
</entry>
<entry>
<title>Opera Web Standards Curriculum</title>
<link href="https://www.fronteers.nl/nl/blog/2008/07/opera-web-standards-curriculum"/>
<updated>2008-07-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/07/opera-web-standards-curriculum</id>
<content xml:lang="nl" type="html"><p>Een groot probleem bij het verkondigen en leren van de webstandaarden is een gebrek aan goed lesmateriaal. Zeker, er bestaan tientallen boeken en honderden websites die tips en truuks bevatten, complexe onderwerpen goed uitleggen, en filosoferen over bepaalde aspecten van de webstandaarden. Niettemin overvalt je als beginner soms een gevoel van machteloosheid; er is zoveel te leren dat het lastig is uit te vinden waar je moet beginnen. Veel boeken en sites veronderstellen enige basiskennis, maar wat als je juist die basiskennis mist?</p>
<p>Daarom is het <a href="http://www.opera.com/wsc/">Opera Web Standards Curriculum</a> zo'n belangrijke stap voorwaarts. Doel van deze serie artikelen is het geven van een compleet overzicht van alles wat een front-end ontwikkelaar moet weten; van basis-HTML via informatiearchitectuur en kleurentheorie tot gevorderde CSS en JavaScript.</p>
<p>Deze cursus is bedoeld voor iedereen die moderne webontwikkeling wil leren, of die even snel iets wil opzoeken (&quot;wat is het correcte gebruik van </p><address>?&quot;). Opera hoopt dat vooral universiteiten en hogescholen deze cursus zullen gebruiken om hun lesprogramma te verbeteren, maar de artikelen zijn ook zeer geschikt voor interne trainingen.<p></p>
<p>Uiteindelijk zal de serie uit circa 50 artikelen bestaan, die elk één onderwerp tot in detail uitwerken. Er zijn bijvoorbeeld aparte artikelen over <a href="https://dev.opera.com/articles/view/17-images-in-html/">het gebruik van plaatjes</a>, <a href="https://dev.opera.com/articles/view/11-typography-on-the-web/">typografie</a> of <a href="https://dev.opera.com/articles/view/14-choosing-the-right-doctype-for-your/">het kiezen van het juiste doctype</a>. De bedoeling is dat elk artikel genoeg stof geeft voor een les van circa 1 uur, waarbij de studenten van tevoren een extra uur hebben besteed aan het lezen van het artikel.</p>
<p>Op dit moment zijn er 23 artikelen online, en de bedoeling is dat er vanaf nu tot eind september nog eens circa 25 worden gepubliceerd. Dit is dus een werk in voortgang, maar het is nu al duidelijk dat het Opera Web Standards Curriculum een belangrijke rol zal vervullen in het leren en verbreiden van webstandaarden.</p>
</address></content>
</entry>
<entry>
<title>Webrichtlijn 51: Kleuren en stijlen van links</title>
<link href="https://www.fronteers.nl/nl/blog/2008/07/webrichtlijnen-kleuren-stijlen-links"/>
<updated>2008-07-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/07/webrichtlijnen-kleuren-stijlen-links</id>
<content xml:lang="nl" type="html"><p>Links moeten duidelijk te onderscheiden zijn van andere tekst. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/kleuren-stijlen/#r-pd-8-8">R-pd.8.8</a>)</p>
<p>Twee simpele 'regeltjes' voor ons: <code>text-decoration: underline;</code> over het algemeen alleen bij links gebruiken, en netjes gebruik maken van <a href="http://meyerweb.com/eric/thoughts/2007/06/11/who-ordered-the-link-states/">Lazy Visitors Hate Following Anchors</a> (<code>:link</code>, <code>:visited</code>, <code>:hover</code>, <code>:focus</code> en <code>:active</code>).</p>
<p>Wat zou er gebeuren als WYSYWIG editors voor het web de <code>&lt;u&gt;</code>nderline knop uit de toolbar zouden halen?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 48, 49 &amp; 50: Links en client-side scripts</title>
<link href="https://www.fronteers.nl/nl/blog/2008/07/webrichtlijnen-links-en-client-side-scripts"/>
<updated>2008-07-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/07/webrichtlijnen-links-en-client-side-scripts</id>
<content xml:lang="nl" type="html"><p>Bij het gebruik van client-side script in combinatie met een link: maak de scriptfunctionaliteit een uitbreiding op de basisfunctionaliteit van de link. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/client-side-scripts/#r-pd-8-5">R-pd.8.5</a>) Bij het gebruik van client-side script in combinatie met een link: indien de link nergens naartoe leidt, confronteer de bezoeker zonder ondersteuning voor client-side script dan niet met een niet-werkende link. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/client-side-scripts/#r-pd-8-6">R-pd.8.6</a>) Bij het gebruik van client-side script in combinatie met een link: indien noodzakelijk, gebruik client-side script als een uitbreiding op server-side functies. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/client-side-scripts/#r-pd-8-7">R-pd.8.7</a>)</p>
<p><code>&lt;a href=&quot;javascript:foo();&quot;&gt;</code> is natuurlijk verschrikkelijk <em>evil</em>! Doe dan op z'n minst <code>&lt;a href=&quot;#&quot; onclick=&quot;foo();&quot;&gt;</code> (of <code>onclick=&quot;[javascript:foo();](http://www.hedgerwow.com/360/dhtml/js_label/)&quot;</code>, wat wel zo professioneel staat). Maar wat als je deze link met JavaScript genereert?</p>
<p>Wat doe je als je een lijst met 20 links hebt, waarvan je er slechts 5 wilt tonen (althans, dat wil de ontwerper). Onder de lijst staat een mooi linkje met 'Meer links', die de overige 15 toont? Hoe voeg je dit met JavaScript toe en wat zet je in het <code>href</code> attribuut van de link? Hoort dit eigenlijk wel een <code>&lt;a&gt;</code>'tje te zijn?</p>
<p>Tabbladen zijn volgens mij een mooi voorbeeld van hoe je links en scripting kunt combineren. Hoe los je dit op, als je het zelf script? Zorg je ervoor dat de links bookmarkable zijn, of in een nieuwe browser tab zijn te openen? Gebruik je <code>return false;</code> in de links, of laat je de browser 'springen' naar <code>#het-id</code>?</p>
<p>Hoe ver ga je bij bijvoorbeeld carrouselletje met <em>sfeerafbeeldingen</em>, waar je met JavaScript doorheen kunt klikken? Is dit iets wat je op de back-end ook laat werken, of vinden we dat te veel gedoe? En in dat laatste geval, wat zet je in de <code>href=&quot;&quot;</code>? En dezelfde vraag voor <em>blokken tekstuele content</em>, die in een carrousel staan, en waar je stoere Web 2.0 Ajax (<em>niet</em> AJAX) effectjes overheen gooit.</p>
<p>En na al dat geneuzel met het nadenken over twee paden in je site (eentje met en eentje zonder JavaScript) kom je erachter dat je het toch nog niet goed doet. Want je mooie Ajax carrousel werkt misschien 'perfect' met en zonder JavaScript, maar hoe werkt het bijvoorbeeld in screenreaders die JavaScript wel ondersteunen, maar animaties met verdwijnende en verschijnende content niet uit kunnen drukken? <a href="http://www.w3.org/WAI/intro/aria">ARIA</a>, met <a href="http://juicystudio.com/article/wai-aria-live-regions.php">Live Regions</a>? Of vinden we het al goed genoeg dat we de webrichtlijnen naleven?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 44, 45, 46 &amp; 47: Linktekst</title>
<link href="https://www.fronteers.nl/nl/blog/2008/06/webrichtlijnen-linktekst"/>
<updated>2008-06-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/06/webrichtlijnen-linktekst</id>
<content xml:lang="nl" type="html"><p>Beschrijf niet het mechanisme achter het volgen van een link. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/goede-linktekst-schrijven/#r-pd-8-1">R-pd.8.1</a>) Schrijf heldere, beschrijvende tekst voor links. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/goede-linktekst-schrijven/#r-pd-8-2">R-pd.8.2</a>) Gebruik het minimum aan tekst dat nodig is om te begrijpen waar de link naartoe leidt. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/goede-linktekst-schrijven/#r-pd-8-3">R-pd.8.3</a>) Geef voldoende informatie over de bestemming van een link om onaangename verrassingen voor de bezoeker te voorkomen. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/goede-linktekst-schrijven/#r-pd-8-4">R-pd.8.4</a>)</p>
<p>Allemaal logische richtlijnen, die vooral belangrijk zijn voor content managers. De Webrichtlijnen halen ook het <code>title</code> attribuut aan. <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/goede-linktekst-schrijven/#title-attribuut">Klik hier</a> om dat voorbeeld te bekijken. Wanneer gebruik jij dit attribuut om een link te verduidelijken?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 42 &amp; 43: Achtergrondafbeeldingen</title>
<link href="https://www.fronteers.nl/nl/blog/2008/06/webrichtlijnen-achtergrondafbeeldingen"/>
<updated>2008-06-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/06/webrichtlijnen-achtergrondafbeeldingen</id>
<content xml:lang="nl" type="html"><p>Decoratieve afbeeldingen dienen zoveel mogelijk door CSS geplaatst te worden. Informatieve afbeeldingen dienen door HTML geplaatst te worden. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/afbeeldingen-alternatieve-tekst/achtergrondafbeeldingen/#r-pd-7-6">R-pd.7.6</a>) Het gebruik van CSS Image Replacement technieken die worden toegepast op essentiële informatie wordt afgeraden. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/afbeeldingen-alternatieve-tekst/achtergrondafbeeldingen/#r-pd-7-7">R-pd.7.7</a>)</p>
</content>
</entry>
<entry>
<title>Fronteers-bijeenkomst: 27 juni Arnhem</title>
<link href="https://www.fronteers.nl/nl/blog/2008/06/bijeenkomst-juni"/>
<updated>2008-06-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/06/bijeenkomst-juni</id>
<content xml:lang="nl" type="html"><p>Vrijdag 27 juni zal Fronteers te gast zijn bij de Hogeschool van Arnhem en Nijmegen, bij de faculteit Informatica, Media en Communicatie. Voorafgaand aan de bijeenkomst zal de commissie Diplomering proefexamens afnemen, zie voor meer informatie de <a href="https://www.fronteers.nl/blog/2008/06/commissie-diplomering-zoekt-proefpersonen">blogpost Commissie Diplomering zoekt proefpersonen</a>.</p>
<p>Zowel leden als niet-leden zijn van harte welkom bij deze bijeenkomst, maar reserveren is <em>wel</em> verplicht.</p>
<h2>Het programma is als volgt:</h2>
<ul>
<li>18.30 uur: Zaal open, koffie, bier en fris.</li>
<li>19.00 uur: Wilfred Nas, voorzitter van de <a href="https://www.fronteers.nl/vereniging/commissies/diplomering">Commissie Diplomering</a>, over de resultaten van de afgelopen maanden en de <a href="https://www.fronteers.nl/blog/2008/06/commissie-diplomering-zoekt-proefpersonen">afgenomen proefexamens</a>.</li>
<li>19.45 uur: Robert Gaal over <a href="https://www.fronteers.nl/blog/2008/05/hoe-manage-jij-je-front-end-code">het managen van front-end code</a>.</li>
<li>20.30 uur: Arjan Eising over &quot;toegankelijke webapplicaties: kijken voorbij de webrichtlijnen&quot;.</li>
<li>21.15 uur: Bier, fris en networking.</li>
</ul>
<p>De bijeenkomst vindt plaats in gebouw 4 van de Hogeschool van Arnhem en Nijmegen (faculteit Techniek / Informatica, Media en Communicatie), Ruitenberglaan 26, 6826 CC, Arnhem. Zie ook de <a href="http://www1.han.nl/restyle/centraal/route/route.xml?map=arnhem&amp;code=4&amp;lang=nld&amp;restyle=on">routebeschrijving op de website van de HAN</a>. Je kan je opgeven middels het <a href="https://www.fronteers.nl/bijeenkomsten/planning">formulier op de bijeenkomstenpagina</a>. Tot vrijdag de 27ste!</p>
</content>
</entry>
<entry>
<title>Commissie Diplomering zoekt proefpersonen</title>
<link href="https://www.fronteers.nl/nl/blog/2008/06/commissie-diplomering-zoekt-proefpersonen"/>
<updated>2008-06-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/06/commissie-diplomering-zoekt-proefpersonen</id>
<content xml:lang="nl" type="html"><p>De commissie Diplomering heeft de afgelopen maanden gewerkt aan de opzet van diplomering van front-end ontwikkelaars. Zij zijn daarmee zo ver gevorderd, dat er proefexamens afgenomen kunnen worden. Deze proefexamens zullen plaatsvinden op vrijdag 27 juni in Arnhem.</p>
<p>Als je tijd en zin hebt om 27 juni de Commissie Diplomering te helpen bij het ontwikkelen van de diplomering, dan verzoeken wij je om jezelf aan te melden. Om 13 uur zal begonnen worden met de theorievragen, en later in de middag zullen vragensessies plaatsvinden. Voor de mensen die hieraan meehelpen, wordt 's avonds een pizzaatje geregeld. Aansluitend zal een Fronteers bijeenkomst plaatsvinden. Meer daarover in een volgende blogpost.</p>
<h2>Alle informatie in het kort:</h2>
<ul>
<li>Datum: vrijdag 27 juni</li>
<li>Locatie: Hogeschool van Arnhem en Nijmegen (faculteit Techniek / Informatica, Media en Communicatie), Ruitenberglaan 26, 6826 CC, Arnhem. Zie ook de <a href="http://www1.han.nl/restyle/centraal/route/route.xml?map=arnhem&amp;code=4&amp;lang=nld&amp;restyle=on">routebeschrijving op de website van de HAN</a></li>
<li>Aanmelden kan door een bericht te sturen met het formulier op de <a href="https://www.fronteers.nl/vereniging/commissies/diplomering">pagina van de commissie Diplomering</a></li>
</ul>
<p>Wij hopen je te mogen begroeten op 27 juni.</p>
</content>
</entry>
<entry>
<title>Sharepoint sessie op 16 juni</title>
<link href="https://www.fronteers.nl/nl/blog/2008/06/sharepoint-sessie"/>
<updated>2008-06-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/06/sharepoint-sessie</id>
<content xml:lang="nl" type="html"><p>Op maandag 16 juni organiseert Ordina een Sharepoint sessie in Nieuwegein.</p>
<p>Beste Fronteers,</p>
<p>Er zijn plaatsen voor jullie gereserveerd op de tribune tijdens de <a href="http://www.innoveerjijmee.nl/default.asp/id,342/index.html">Ordina Open Innoveerjijmee</a> sessie van 16 juni bij ons in Nieuwegein. Kom je ook?</p>
<p>De sessie is gratis toegankelijk voor iedereen. Je bent van harte welkom. We verwachten je vanaf 17:30u. Schrijf je in via <a href="http://www.innoveerjijmee.nl/default.asp/id,307/index.html">innoveerjijmee.nl</a>.</p>
<h2>Sharepoint sessie, door Jan Tielens van U2U op 16 juni</h2>
<h2>Onderwerp</h2>
<p>Web 2.0-technologieën zoals ASP.NET AJAX 1.0 en Silverlight 1.0/2 zijn populair voor het verbeteren van de webgebruikerservaring in ASP.NET-webapplicaties en SharePoint. Het eerste deel van deze sessie leert u deze gebruiken in WSS 3.0 en MOSS 2007. Als front-end developers krijgen we steeds meer te maken met nieuwe technologien zoals AJAX en Silverlight. Ook vraagt de markt om implementaties van standaard pakketten als Sharepoint.</p>
<p>Het bouwen van Web Parts is een van de meest populaire manieren om SharePoint aan te passen aan de eigen noden en wensen. Het tweede deel van deze sessie kijkt verder dan de typische ‘Hello World’ Web Parts en bespreekt geavanceerde topics zoals custom toolparts, connectable web parts, verbs, Code Acces Security etc. Ook de combinatie met ASP.NET AJAX wordt uitvoerig besproken.</p>
<h2>Programma</h2>
<ul>
<li>17.30u: Ontvangst in het Ordina Grand Cafe met buffet</li>
<li>18.30u: Presentatie Jan Tielens – “Sharepoint &amp; Silverlight: Building RIAs for WSS 3.0 and MOSS 2007”</li>
<li>19.40u: Pauze</li>
<li>19.50u: Presentatie Jan Tielens – “SharePoint Web Part Development: Advanced Web Part Development”</li>
<li>21.00u: Borrel</li>
</ul>
<p>Als front-end developer is dit een mooie kans om je kennis te verbreden, en te zien en horen wat de mogelijkheden zijn om van Sharepoint 2007 een rich internet application te maken. <a href="http://www.innoveerjijmee.nl/default.asp/id,307/index.html">Meld je dus nu aan op innoveerjijmee.nl</a> en vermeld mijn naam bij de opmerkingen.</p>
<p>Met vriendelijke groet,</p>
<p>Wilco Havenaar</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 39: Het longdesc attribuut en d-links</title>
<link href="https://www.fronteers.nl/nl/blog/2008/06/webrichtlijnen-longdesc"/>
<updated>2008-06-10T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/06/webrichtlijnen-longdesc</id>
<content xml:lang="nl" type="html"><p>Gebruik geen d-links op overheidswebsites. Het gebruik van het longdesc (long description) attribuut verdient de voorkeur wanneer de alternatieve tekst op het alt attribuut ontoereikend is voor het begrip van de informatie in de afbeelding. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/afbeeldingen-alternatieve-tekst/longdesc-attribuut/d-links/#r-pd-7-3">R-pd.7.3</a>)</p>
<p>Dus, wie gebruikt <code>longdesc</code>, <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/afbeeldingen-alternatieve-tekst/longdesc-attribuut/uitgebreide-beschrijvingen/">op een goede manier</a>?</p>
<p>Welke CMS'en bieden ondersteuning voor dit attribuut? En hoe werken die dan?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 37, 38, 40 &amp; 41: Het alt attribuut</title>
<link href="https://www.fronteers.nl/nl/blog/2008/06/webrichtlijnen-alt-attribuut"/>
<updated>2008-06-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/06/webrichtlijnen-alt-attribuut</id>
<content xml:lang="nl" type="html"><p>Het alt (alternative) attribuut dient te worden gebruikt op ieder img (image) en area element en dient te worden voorzien van een effectieve alternatieve tekst. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/afbeeldingen-alternatieve-tekst/alt-attribuut/#r-pd-7-1">R-pd.7.1</a>) Gebruik geen alt attribuut voor het oproepen van tooltips. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/afbeeldingen-alternatieve-tekst/alt-attribuut/tooltips/#r-pd-7-2">R-pd.7.2</a>) Afbeeldingen die staan geplaatst binnen een link dienen een niet-lege alternatieve tekst te hebben om bezoekers die de afbeelding niet zien in staat te stellen de link te volgen. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/afbeeldingen-alternatieve-tekst/navigatie-image-maps/#r-pd-7-4">R-pd.7.4</a>) Geef bij het gebruik van image maps voor zowel het img element als ieder area element een effectieve alternatieve tekst aan via het alt attribuut. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/afbeeldingen-alternatieve-tekst/navigatie-image-maps/#r-pd-7-5">R-pd.7.5</a>)</p>
<p>De webrichtlijnen zijn erg duidelijk over het <code>alt</code> attribuut en de <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/afbeeldingen-alternatieve-tekst/">vele voorbeelden</a>.</p>
<p>Deze post gaat over het verplichte karakter van het attribuut en <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/afbeeldingen-alternatieve-tekst/alt-attribuut/alternatieve-tekst-schrijven/">het schrijven van effectieve teksten</a>. Dit laatste zou toch vaste kost moeten zijn voor iedere content manager? Hoe kan een CMS een gebruiker begeleiden in het schrijven van een goede tekst?</p>
<p>Wat vinden we trouwens van het het idee om <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/section-embedded0.html#alt"><code>alt</code> optineel te maken</a> (in een enkel geval)? Er is al <a href="http://lists.w3.org/Archives/Public/public-html/2008Apr/thread.html">genoeg over gediscussieerd</a>, maar okay..</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 35: De DocType Declaratie</title>
<link href="https://www.fronteers.nl/nl/blog/2008/05/webrichtlijnen-doctype"/>
<updated>2008-05-20T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/05/webrichtlijnen-doctype</id>
<content xml:lang="nl" type="html"><p>Elk HTML of XHTML document moet beginnen met een geldige DocType Declaratie. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/paginastructuur/doctype/#r-pd-6-1">R-pd.6.1</a>)</p>
<p>Hoeveel waarde hecht jij aan de doctype? Is het niet gewoon een irritant ding dat we steeds maar weer kopiëren en plakken?</p>
<p>Waarom gebruiken we vanaf nu niet gewoon <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/section-writing0.html#the-doctype"><code>&lt;!doctype html&gt;</code></a> wat hetzelfde effect heeft in browsers (standards mode triggeren)?</p>
<p>Zijn er, zoals de webrichtlijnen beweren, editors die de doctype gebruiken? En heb je daar wat aan tijdens het ontwikkelen van een site?</p>
</content>
</entry>
<entry>
<title>Hoe manage jij je front-end code?</title>
<link href="https://www.fronteers.nl/nl/blog/2008/05/hoe-manage-jij-je-front-end-code"/>
<updated>2008-05-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/05/hoe-manage-jij-je-front-end-code</id>
<content xml:lang="nl" type="html"><p>De meeste front-enders kennen dit probleem vast wel: je CSS of Javascript code raakt onoverzichtelijk. Je hebt teveel aparte bestanden of te lange bestanden en het wordt moeilijk om dingen terug te vinden, zelfs met een goeie zoekfunctie. Classes worden overbodig en niet verwijderd, stukken markup hebben niet de ID die je verwacht, functies zijn onderverdeeld in verkeerde bestanden, etc. Het is allemaal niet onmogelijk om bij te houden natuurlijk, iedereen heeft zo z'n routine. En daar gaat deze post over!</p>
<p>Hoe manage jij je front-end code? Gebruik je bijvoorbeeld <a href="http://haml.hamptoncatlin.com/docs/rdoc/classes/Sass.html">SASS</a> of <a href="http://code.google.com/p/blueprintcss/">Blueprint</a>? Is er de perfecte IDE die het meer managable maakt? Specificeer je voor alles Classes in Javascript? Heb je een naam-structuur uitgedacht voor je bestanden en mappen? Kortom: wat doe jij om rotzooi te voorkomen? Laat het ons weten.</p>
<p>Kleine kanttekening: ik ben zelf ook vaak bezig met Ruby On Rails en de <a href="http://en.wikipedia.org/wiki/DRY">DRY</a> en <a href="http://en.wikipedia.org/wiki/Model-view-controller">MVC</a> methodes daarvan spreken me erg aan. Misschien is een open-source front-end framework met die principes een idee?</p>
</content>
</entry>
<entry>
<title>Verslag bijeenkomst bij EveryWeb Solutions</title>
<link href="https://www.fronteers.nl/nl/blog/2008/05/verslag-bijeenkomst-bij-everyweb-solutions"/>
<updated>2008-05-16T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/05/verslag-bijeenkomst-bij-everyweb-solutions</id>
<content xml:lang="nl" type="html"><p>Afgelopen dinsdag was Fronteers te gast bij EveryWeb Solutions. Fronteers leden Tom-Eric Gerritsen en Arjan Eising hebben hiervan <a href="https://www.fronteers.nl/bijeenkomsten/2008/everyweb-solutions">een verslag</a> geschreven.</p>
<p>Diegenen die aanwezig waren bij de bijeenkomst, zullen ook gemerkt hebben dat de presentatie van Ruud ietwat in het water viel. Dit voorval wordt nu goedgemaakt met <a href="http://steltenpower.com/FronteersMeetSVG.html">een uitgebreide verzameling links</a> naar SVG onderwerpen. We hopen binnen Fronteers meer van SVG te horen dan alleen deze presentatie.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 34: Open standaarden</title>
<link href="https://www.fronteers.nl/nl/blog/2008/05/webrichtlijnen-open-standaarden"/>
<updated>2008-05-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/05/webrichtlijnen-open-standaarden</id>
<content xml:lang="nl" type="html"><p>In het geval dat belangrijke informatie via een gesloten standaard wordt aangeboden, dient men dezelfde informatie ook via een open standaard aan te bieden. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/open-standaarden/#r-pd-5-1">R-pd.5.1</a>)</p>
<p>Als je bij het gebruik van PNG tegen problemen aanloopt met kleurverschillen in browsers (beschreven in <a href="http://hsivonen.iki.fi/png-gamma/">The Sad Story of PNG Gamma “Correction”</a> en <a href="http://morris-photographics.com/photoshop/articles/png-gamma.html">The PNG Gamma Dilemma</a>), zijn de volgende tools wellicht handig:</p>
<ul>
<li><a href="http://psydk.org/PngOptimizer.php">PngOptimizer</a></li>
<li><a href="http://entropymine.com/jason/tweakpng/">TweakPNG</a></li>
<li><a href="http://pmt.sourceforge.net/pngcrush/">PNGCRUSH</a></li>
</ul>
<p>Wat denk jij trouwens van <a href="http://www.w3.org/Graphics/SVG/">SVG</a> als formaat voor afbeeldingen? Is deze open standaard al volwassen genoeg om te gebruiken? Zou er iets veranderen als je <a href="http://intertwingly.net/blog/2008/04/11/SVG-and-MathML-Annexes-to-HTML5">SVG rechtstreeks in je HTML kon plakken</a>?</p>
<p>Wellicht dat we <a href="https://www.fronteers.nl/blog/2008/05/herinnering-bijeenkomst-13-mei">vanavond</a> meer te horen krijgen over de voordelen van SVG.</p>
<p>En gaat HTML5 <a href="http://www.w3.org/QA/2007/12/when_will_html_5_support_soone.html">een oplossing voor het <code>&lt;video&gt;</code> probleem</a> vinden? Wat zou het voor het web betekenen als browsers een open standaard voor video (en audio) implementeren? Flash is nu nog de grote speler bij online video, maar is dat wel zo'n probleem? Zeker gezien <a href="http://www.adobe.com/openscreenproject/">recente stappen van Adobe</a>?</p>
</content>
</entry>
<entry>
<title>Herinnering: bijeenkomst 13 mei</title>
<link href="https://www.fronteers.nl/nl/blog/2008/05/herinnering-bijeenkomst-13-mei"/>
<updated>2008-05-09T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/05/herinnering-bijeenkomst-13-mei</id>
<content xml:lang="nl" type="html"><p>Zoals eerder aangekondigd zal er op 13 mei (dat is dinsdag aanstaande) een Fronteers-bijeenkomst gehouden worden in Hotel Arena te Amsterdam, georganiseerd door <a href="http://everywebsolutions.nl/">EveryWeb Solutions</a>. De toegang is gratis, en niet-leden zijn van harte welkom. Wel verzoeken we je je komst te melden via het <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">het aanmeldingsformulier</a>.</p>
<h2>Feiten</h2>
<ul>
<li>Waar: De Kloosterzaal van <a href="http://maps.google.nl/maps?f=q&amp;hl=en&amp;geocode=&amp;q=%27s-Gravesandestraat+51,+1092+AA+Amsterdam,+nederland&amp;sll=52.360742,4.907541&amp;sspn=0.013497,0.039911&amp;ie=UTF8&amp;ll=52.361345,4.915352&amp;spn=0.026994,0.079823&amp;t=h&amp;z=14">Hotel Arena</a></li>
<li>Wanneer: De zaal gaat om 18:30 uur open; de eerste presentatie zal rond 19:00 uur aanvangen.</li>
<li>Wat: Een presentatie van een medewerker van <a href="http://www.everywebsolutions.nl/">EveryWeb Solutions</a> over toegankelijkheid voor blinden en slechtzienden, en een presentatie van <a href="http://svg.startpagina.nl/">Ruud Steltenpool</a> over SVG.</li>
<li>En verder: Hapjes en drankjes staan klaar.</li>
</ul>
</content>
</entry>
<entry>
<title>Bevindingen commissie Openbaar Ledenregister</title>
<link href="https://www.fronteers.nl/nl/blog/2008/05/bevindingen-commissie-openbaar-ledenregister"/>
<updated>2008-05-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/05/bevindingen-commissie-openbaar-ledenregister</id>
<content xml:lang="nl" type="html"><p>In januari heeft Sander Aarts zich aangemeld om de commissie Openbaar Ledenregister te leiden. Het bestuur heeft toen drie vragen bij de commissie neergelegd. Vorige week heeft de commissie een advies uitgebracht en zichzelf ontbonden. Het bestuur heeft het advies onverkort overgenomen.</p>
<p>Hier volgt het eindrapport van commissievoorzitter Sander Aarts:</p>
<p>Zodra je een online ledenlijst voorziet van extra functionaliteit, neigt het al gauw naar een online community. Vandaar dat de Commissie Openbaar Ledenregister besloten heeft het register in eerste instantie zo simpel mogelijk te houden en het stokje vervolgens door te geven aan de Commissie Online Community, die het dan vanuit een iets breder perspectief kan benaderen.</p>
<p>De commissie had als 'opdracht' de volgende 3 vragen te beantwoorden:</p>
<h2>1. Welke leden zullen er precies in het Openbaar Ledenregister getoond worden?</h2>
<p>Commissie:
Alle leden.
Aangezien er echter nog geen contributie geheven is, en er dus officieel nog geen leden zijn, zullen in eerste instantie alle potentiële leden waarvan het adres bekend is getoond worden. Zodra er gestart wordt met het innen van contributie en er minimaal 50 betalende leden zijn zullen alleen deze 'werkelijke' leden worden getoond.</p>
<h2>2. Welke informatie zal er precies in het Openbaar Ledenregister getoond worden?</h2>
<p>Commissie:
De naam van het lid en eventueel die van zijn/haar werkgever.
Omdat de lijst behoorlijk wat concurrenten (werkgevers/zelfstandigen) samenbrengt op een pagina en we degenen bovenaan de lijst, met name boven de vouw, niet teveel willen bevoordelen, hebben we ervoor gekozen om de lijst voorlopig niet te voorzien van links. De commissie is van mening dat een online community met persoonlijke profielpagina's betere mogelijkheden biedt om dit af te vangen.</p>
<h2>3. Is er een reden te bedenken om geen openbaar ledenregister aan te leggen?</h2>
<p>Commissie:
Afgezien van de zojuist genoemde onderlinge concurrentie hebben we geen bezwaar kunnen bedenken.</p>
<p>De Commissie Openbaar Ledenregister is van mening dat zij, met het beantwoorden van deze vragen, haar taak vervuld heeft en dus ontbonden kan worden. De leden van deze commissie zijn allemaal overgegaan in de Online Community, en <a href="https://www.fronteers.nl/leden">het ledenregister</a> valt hier vanaf nu ook onder.</p>
<h2>Commissie Online Community</h2>
<p>Samen met drie nieuwe leden (Kor Dwarshuis, Arjan Eising en Tom-Eric Gerritsen) gaat de Commissie Online Community nu van start, met onderstaande vragen als richtlijnen:</p>
<ul>
<li>Wat kunnen we doen om leden online met elkaar in contact te brengen?</li>
<li>Wat kunnen we doen om de kennis van leden onderling te delen?</li>
<li>Wat wordt de inhoud van de profielen van leden?</li>
<li>(In hoeverre) moet er een mailinglist komen?</li>
<li>(In hoeverre) moet er een forum komen?</li>
<li>Wat doen we met andere community websites, zoals LinkedIn en Facebook?</li>
<li>Gaat <a href="https://www.fronteers.nl/blog/2008/03/fronteers-op-irc">IRC</a> gelogged worden, en zijn die logs voor iedereen toegankelijk of alleen voor leden?</li>
</ul>
</content>
</entry>
<entry>
<title>Gesprek Fronteers.nl en FeWeb.be</title>
<link href="https://www.fronteers.nl/nl/blog/2008/05/gesprek-fronteers-feweb"/>
<updated>2008-05-07T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/05/gesprek-fronteers-feweb</id>
<content xml:lang="nl" type="html"><p>Op vrijdag 4 april hebben Arjan Eising en ik een gesprek gehad met <a href="http://www.bartdewaele.be/">Bart De Waele</a>, bestuurslid van <a href="http://feweb.be/">FeWeb</a>, de Vlaamse Federatie van Webontwikkelaars. Dit was bedoeld als kennismakingsgesprek en om te kijken of deze twee verenigingen eventueel tot een samenwerking kunnen komen.</p>
<p>FeWeb heeft een andere insteek dan Fronteers; de leden zijn bedrijven en geen personen, en daardoor houdt FeWeb zich ook bezig met zaken zoals het berekenen van de totale economische waarde van de Vlaamse Internetwereld, of juridische en organisatorische aspecten; zaken waar Fronteers zich (vooralsnog) niet mee bezig houdt. (In Nederland zou dit ook eerder onder de auspiciën van het <a href="http://www.pibn.nl/">PIBN</a> vallen.)</p>
<p>Niettemin zijn er voldoende aanknopingspunten om tot verdere samenwerking te komen. Net als Fronteers houdt FeWeb zich actief bezig met Educatie: ze hebben onlangs alle Vlaamse hogescholen om de tafel gekregen om over de problemen in het webonderwijs te praten. Uiteraard willen we graag meer weten over de ervaringen die FeWeb daarmee heeft opgedaan.</p>
<p>FeWeb wil graag meer weten over de Fronteers-diplomering, dat is wellicht iets dat FeWeb ook kan gebruiken om goede van minder goede front-enders te onderscheiden. Het zou dus kunnen dat de Fronteers-diplomering, als deze eenmaal klaar is, ook in Vlaanderen gebruikt zal worden.</p>
<p>Hoewel we nog weinig concrete actiepunten hebben, hebben zowel Fronteers als FeWeb het gevoel dat een samenwerking logisch is en tot nuttige resultaten kan leiden.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 27 t/m 33: URL's</title>
<link href="https://www.fronteers.nl/nl/blog/2008/05/webrichtlijnen-over-urls"/>
<updated>2008-05-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/05/webrichtlijnen-over-urls</id>
<content xml:lang="nl" type="html"><p>Produceer unieke, onveranderende URL's (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/permanente-unieke-urls/produceren/#r-pd-4-1">R-pd.4.1</a>) Dynamisch gegenereerde URL's dienen nog steeds naar dezelfde inhoud te verwijzen als inhoud wordt gewijzigd of toegevoegd. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/permanente-unieke-urls/produceren/dynamische-urls/#r-pd-4-2">R-pd.4.2</a>) Vermijd het gebruik van sessies in URL's. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/permanente-unieke-urls/produceren/sessies/#r-pd-4-3">R-pd.4.3</a>) Zorg voor doorverwijzing naar de nieuwe locatie bij het verplaatsen van informatie. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/permanente-unieke-urls/produceren/doorverwijzing/#r-pd-4-4">R-pd.4.4</a>) Automatische doorverwijzing dient, indien mogelijk, uitgevoerd te worden door de server. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/permanente-unieke-urls/produceren/doorverwijzing/methodes/#r-pd-4-5">R-pd.4.5</a>) Gebruik vriendelijke URL's, die leesbaar en herkenbaar zijn. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/permanente-unieke-urls/vriendelijke-urls/#r-pd-4-6">R-pd.4.6</a>) Zet een leesbare, uitbreidbare directory-structuur op. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/permanente-unieke-urls/vriendelijke-urls/#r-pd-4-7">R-pd.4.7</a>)</p>
<p>Helaas zitten vrijwel al deze punten niet binnen het bereik van een front-ender, en zijn we hierbij afhankelijk van het te gebruiken CMS, framework of back-end taal. Het enige wat wij kunnen doen, is <em>geen</em> gebruik maken van frames en <code>&lt;meta http-equiv=&quot;refresh&quot;&gt;</code>.</p>
<p>Waar we het wel over kunnen hebben, zijn onze voorkeuren. Wat vind <em>jij</em> een mooie <a href="http://en.wikipedia.org/wiki/Uniform_Resource_Locator">URL</a> (of <a href="http://en.wikipedia.org/wiki/Uniform_Resource_Identifier">URI</a>, of <a href="http://en.wikipedia.org/wiki/Internationalized_Resource_Identifier">IRI</a>)?</p>
<p>De webrichtlijnen spreken over het opzetten van een leesbare, uitbreidbare directory-structuur. Hoe doe je dit met bijvoorbeeld tags (die gecombineerd kunnen worden)?</p>
<p>Als je wel de controle over de infrastructuur van de URL's hebt, hoe ver ga je dan? Zorg jij dat iedere pagina op slechts 1 URL te vinden is? Hoe ver ga je met HTTP? Denk je na over het verschil tussen een <code>301</code> header, en een <code>302</code>? En als een pagina verwijderd is, gebruik je dan een <code>410</code>, in plaats van een <code>404</code>?</p>
<p>Hebben wij als front-enders, of de webrichtlijnen..als webrichtlijnen, genoeg overtuigingskracht (gehad) om grote, logge back-end systemen met nette URL's te laten werken? Of is dit vooral te danken aan SEO bedrijven en zoekmachines?</p>
</content>
</entry>
<entry>
<title>Locatie bijeenkomst 13 mei bekend</title>
<link href="https://www.fronteers.nl/nl/blog/2008/04/locatie-bijeenkomst-mei"/>
<updated>2008-04-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/04/locatie-bijeenkomst-mei</id>
<content xml:lang="nl" type="html"><p>De locatie van de bijeenkomst op 13 mei is Hotel Arena.</p>
<p>Het adres van Hotel Arena is <a href="http://maps.google.nl/maps?f=q&amp;hl=en&amp;geocode=&amp;q=%27s-Gravesandestraat+51,+1092+AA+Amsterdam,+nederland&amp;sll=52.360742,4.907541&amp;sspn=0.013497,0.039911&amp;ie=UTF8&amp;ll=52.361345,4.915352&amp;spn=0.026994,0.079823&amp;t=h&amp;z=14">'s-Gravesandestraat 51, 1092 AA Amsterdam</a>.</p>
<p>Voor meer informatie over de bijeenkomst, zie <a href="https://www.fronteers.nl/blog/2008/04/bijeenkomst-mei">de aankondiging</a>.</p>
</content>
</entry>
<entry>
<title>Kings of Code</title>
<link href="https://www.fronteers.nl/nl/blog/2008/04/kings-of-code"/>
<updated>2008-04-28T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/04/kings-of-code</id>
<content xml:lang="nl" type="html"><p>Op 27 mei aanstaande zal in <a href="http://www.dezwijger.nl/">Pakhuis De Zwijger</a> te Amsterdam het <a href="http://kingsofcode.nl/">Kings of Code congres</a> plaatsvinden, gericht op web programmeurs, zowel front-end als back-end. Sprekers zijn <a href="http://ejohn.org/">John Resig</a> (jQuery), <a href="http://nate.koechley.com/">Nate Koechley</a> (Yahoo!), Mark Birbeck (<a href="http://www.w3.org/">W3C</a>), Folke Lemaitre (<a href="http://netlog.com/">Netlog.com</a>), Nate Abele (<a href="http://www.cakephp.org/">CakePHP</a>) en ikzelf.</p>
<p>Kaarten kosten € 160, maar er is een early bird korting van € 30, die tot 1 mei geldt. Het is nog maar een paar dagen tot 1 mei, maar gelukkig heeft Fronteers een promo-code gekregen, bij gebruik waarvan de korting van kracht zal blijven.</p>
<ul>
<li>Promocode: fronteers</li>
</ul>
<p>We hopen op 27 mei enige Fronteers-leden te kunnen begroeten.</p>
</content>
</entry>
<entry>
<title>Voorlopige ledenlijst Fronteers gepubliceerd</title>
<link href="https://www.fronteers.nl/nl/blog/2008/04/ledenlijst"/>
<updated>2008-04-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/04/ledenlijst</id>
<content xml:lang="nl" type="html"><p>De <a href="https://www.fronteers.nl/leden">voorlopige ledenlijst</a> van Fronteers is op de website gepubliceerd. Hierin staan alle leden waarvan het adres bekend is. Dit zijn er zo'n 80, van de in de totaal 140 namen die in de database staan.</p>
<p>Sta je er nog niet bij? Dan kan het zijn dat we simpelweg je adres nog niet hebben genoteerd. Geef je in dat geval nogmaals op via <a href="https://www.fronteers.nl/inschrijven">het aanmeldformulier</a>. Let erop dat we alleen <em>persoonlijke</em> adressen voor facturatie bijhouden, niet die van werkgevers. We hebben hiervoor gekozen, om een aantal vragen en mogelijke problemen voorlopig uit de weg te gaan.</p>
<p>Het kan ook zijn dat je in de tussentijd een andere werkgever hebt gekregen. Vul om dit te wijzigen ook het aanmeldformulier nogmaals in, met de correcte gegevens. Inloggen op de site, zodat je zelf je gegevens aan kunt passen, wordt later mogelijk voor ieder lid.</p>
<p>Vanaf ongeveer 10 mei zullen we beginnen met het innen van contributie bij de leden die op deze lijst staan. Zodra we de 50 contribuanten gepasseerd zijn (waarschijnlijk ergens in juni), zal de ledenlijst alleen de betalende leden bevatten.</p>
<p>In een tweede fase zullen profielpagina's beschikbaar komen voor deze leden, waarbij de inhoud hiervan zal worden bepaald in overleg met de Commissie Online Community.</p>
</content>
</entry>
<entry>
<title>Bijeenkomst op 13 mei</title>
<link href="https://www.fronteers.nl/nl/blog/2008/04/bijeenkomst-mei"/>
<updated>2008-04-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/04/bijeenkomst-mei</id>
<content xml:lang="nl" type="html"><p>Er is alweer wat tijd verstreken sinds de vorige Fronteers-bijeenkomst. Daarom zijn we verheugd te kunnen melden dat het Amsterdamse bedrijf <a href="http://everywebsolutions.nl/">EveryWeb Solutions</a> heeft aangeboden een nieuwe bijeenkomst te verzorgen op dinsdag 13 mei, met twee interessante sprekers.</p>
<p>Iemand van EveryWeb Solutions heeft vroeger computerles aan blinden en slechtzienden gegeven, heeft daar flinke ervaring met toegankelijkheid voor deze groepen aan overgehouden, en zal ons hier iets over vertellen. Daarna zal Ruud Steltenpool een presentatie over SVG, de mogelijkheden en problemen houden.</p>
<p>De zaal gaat om 18:30 uur open, de eerste sessie zal rond 19:00 uur aanvang nemen. Er zal ook gelegenheid zijn voor bier en networking.</p>
<p>De locatie voor deze bijeenkomst is de Kloosterzaal van Hotel Arena. Het adres van Hotel Arena is <a href="http://maps.google.nl/maps?f=q&amp;hl=en&amp;geocode=&amp;q=%27s-Gravesandestraat+51,+1092+AA+Amsterdam,+nederland&amp;sll=52.360742,4.907541&amp;sspn=0.013497,0.039911&amp;ie=UTF8&amp;ll=52.361345,4.915352&amp;spn=0.026994,0.079823&amp;t=h&amp;z=14">'s-Gravesandestraat 51, 1092 AA Amsterdam</a>.</p>
<h2>RSVP</h2>
<p>EveryWeb Solutions verzoekt mensen die willen langskomen zich van tevoren op te geven. Dit kan middels <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">het aanmeldingsformulier</a> op deze site.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 25 &amp; 26: Lijsten</title>
<link href="https://www.fronteers.nl/nl/blog/2008/04/webrichtlijnen-lijsten"/>
<updated>2008-04-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/04/webrichtlijnen-lijsten</id>
<content xml:lang="nl" type="html"><p>Gebruik ol (ordered list) en ul (unordered list) elementen voor het aangeven van lijsten. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/lijsten/#r-pd-3-13">R-pd.3.13</a>) Gebruik het dl (definition list), het dt (definition term) en dd (definition data) element voor het aangeven van een lijst met definities. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/lijsten/#r-pd-3-14">R-pd.3.14</a>)</p>
<p>De webrichtlijnen raden voor (uitgebreide) inhoudsopgaven het gebruik van het <code>&lt;ul&gt;</code> element aan. Zijn we het daar mee eens?</p>
<p>Gebruik jij voor menuutjes wel eens een <code>&lt;ol&gt;</code> element? Wanneer?</p>
<p>En zijn er situaties waarbij een ongeordende lijst toch nummering kan hebben? Met andere woorden: is <em>geordend</em> hetzelfde als <em>genummerd</em>?</p>
<p>Gebruik jij definitielijsten ook wel eens voor iets anders dan een lijst met begrippen en definities? Is het gebruik bij <a href="https://www.fronteers.nl/vereniging/commissies/onderwijs/bronnen/tips-en-tutorials">de bronnen</a> en hier in de reacties volgens jou goed gebruik van <code>&lt;dl&gt;</code>?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 22, 23 &amp; 24: Referenties en citaten</title>
<link href="https://www.fronteers.nl/nl/blog/2008/04/webrichtlijnen-referenties-citaten"/>
<updated>2008-04-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/04/webrichtlijnen-referenties-citaten</id>
<content xml:lang="nl" type="html"><p>Gebruik het cite element voor referenties naar personen en titels. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/referenties-citaten/#r-pd-3-10">R-pd.3.10</a>) Vermijd het gebruik van het q (quotation) element. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/referenties-citaten/#r-pd-3-11">R-pd.3.11</a>) Gebruik het blockquote element voor het aangeven van (lange) citaten. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/referenties-citaten/#r-pd-3-12">R-pd.3.12</a>)</p>
<p>Zijn we het wat betreft referenties naar personen eens met de <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/referenties-citaten/#referenties">Webrichtlijnen</a> of met <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/section-text-level.html#the-cite">HTML 5</a>? En waar heb jij <code>&lt;cite&gt;</code> verder wel eens gebruikt?</p>
<p>Over het te vermijden <code>&lt;q&gt;</code> element is een tijdje terug een <a href="http://stijlgids.overheid.nl/actueel/weblog/afkortingen_en_citaten_aangeven/">interessante discussie</a> gehouden op het <a href="http://stijlgids.overheid.nl/actueel/weblog/">Stijlgids Weblog</a>. Hebben wij daar nog iets aan toe te voegen? En levert HTML 5 weer <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/section-text-level.html#q">een oplossing</a>?</p>
<p>Over het <code>&lt;blockquote&gt;</code> element is iedereen het volgens mij al eens. Die is puur en alleen om een stuk tekst in te laten springen, en de Webrichtlijnen hebben het daar natuurlijk gewoon verkeerd.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 19, 20 &amp; 21: Tekstopmaak, definities, wijzigingen, superscript en subscript</title>
<link href="https://www.fronteers.nl/nl/blog/2008/04/webrichtlijnen-definities-wijzigingen"/>
<updated>2008-04-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/04/webrichtlijnen-definities-wijzigingen</id>
<content xml:lang="nl" type="html"><p>Gebruik het dfn (definition) element voor het aangeven van termen, elders gedefiniëerd in een definitielijst. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/tekstopmaak/#r-pd-3-7">R-pd.3.7</a>) Gebruik het ins (insertion) en del (deletion) element voor het aangeven van regelmatige wijzigingen in de inhoud van een pagina. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/tekstopmaak/#r-pd-3-8">R-pd.3.8</a>) Vermijd het gebruik van het sup (superscript) en sub (subscript) element waar mogelijk. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/tekstopmaak/#r-pd-3-9">R-pd.3.9</a>)</p>
<p>Even vlug door de laatste 3 richtlijnen van tekstopmaak heen, wat natuurlijk niet wil zeggen dat de discussie hierover ook kort moet zijn!</p>
<h2>Definities</h2>
<p>Wat betreft het <code>&lt;dfn&gt;</code> element zijn de webrichtlijnen lekker summier:</p>
<blockquote>
<p>Termen die geschikt zijn voor opname in een definitielijst of glossary elders op de pagina of website, kan worden opgemaakt met het dfn (definition) element.</p>
</blockquote>
<p><em>Wie</em> doet dit? En wat heb je eraan als je het doet?</p>
<h2>Wijzigingen</h2>
<blockquote>
<p>Als de informatie op een pagina aan regelmatige wijziging onderhevig is en het belangrijk is dat deze wijzigingen als zodanig zichtbaar zijn, gebruik dan het ins (insert) element voor toevoegingen en het del (deletion) element voor verwijderingen.</p>
</blockquote>
<p>Dit betekent dus dat een automatische <a href="http://en.wikipedia.org/wiki/Diff"><code>diff</code></a> met <code>&lt;ins&gt;</code> en <code>&lt;del&gt;</code> elementen niet per se goed is. Of niet?</p>
<p>Op welke site heb jij markup voor wijzigingen in proza wel eens goed toegepast gezien?</p>
<p>En heb jij deze twee elementen wel eens oneigenlijk gebruikt om een validerende pagina op te leveren? Opeens &quot;mag&quot; dit dan:</p>
<pre><code>&lt;a href=&quot;#foo&quot;&gt;
&lt;ins&gt;
&lt;div&gt;
&lt;h3&gt;Foo&lt;/h3&gt;
&lt;p&gt;Bar&lt;/p&gt;
&lt;/div&gt;
&lt;/ins&gt;
&lt;/a&gt;
</code></pre>
<h2>Superscript en subscript</h2>
<p>Hierin zijn de webrichtlijnen wel duidelijk: probeer <code>&lt;sup&gt;</code> en <code>&lt;sub&gt;</code> te vermijden. Zijn we het daar mee eens? Zijn dit gevaarlijke elementen?</p>
</content>
</entry>
<entry>
<title>Handig: veel nuttige links voor front-end ontwikkelaars</title>
<link href="https://www.fronteers.nl/nl/blog/2008/04/bronnen"/>
<updated>2008-04-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/04/bronnen</id>
<content xml:lang="nl" type="html"><p>Zoals de meeste ervaren webontwikkelaars wel weten, is er veel onbetrouwbare informatie over het vak te vinden. In boeken, maar vooral op het internet. De meeste mensen die net met het vak beginnen weten dat niet. En dan kan het zomaar gebeuren dat iemand je wijsmaakt dat tabellen een heel handige manier zijn om een pagina op te maken. Of dat het helemaal niet nodig is om al die ingewikkelde codes te leren: je kunt de pagina's ook gewoon tekenen in Dreamweaver!</p>
<p>Daarom leek het de commissie Onderwijs een goed idee om een collectie samen te stellen met links naar betrouwbare informatiebronnen over front-end ontwikkeling. Dit kan als startpunt dienen voor beginnende ontwikkelaars - en misschien dat zelfs een ervaren html'er er nog iets van opsteekt. Daarnaast kan het een informatiebron zijn voor docenten. Ik heb hiervoor <a href="https://www.fronteers.nl/vereniging/commissies/onderwijs/bronnen">een eerste opzet</a> gemaakt, die vanaf vandaag op deze site te vinden is. Je vindt er links naar goede tutorials, gezaghebbende weblogs, handige tools en nog veel meer.</p>
<p>De sites over Flash zijn uitgezocht door <a href="http://reefscape.net/">Bob Corporaal</a>, maar de meeste andere links heb ik zelf gekozen. Ik heb ongetwijfeld nog een aantal goede sites gemist. Opmerkingen en aanvullingen zijn dan ook zeer welkom! Het is de bedoeling dat de pagina's vanaf nu bijgehouden en aangevuld worden.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 18: Tekstopmaak, afkortingen</title>
<link href="https://www.fronteers.nl/nl/blog/2008/04/webrichtlijnen-tekstopmaak-afkortingen"/>
<updated>2008-04-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/04/webrichtlijnen-tekstopmaak-afkortingen</id>
<content xml:lang="nl" type="html"><p>Gebruik het abbr (abbreviation) element voor afkortingen indien er onduidelijkheid zou kunnen ontstaan over de betekenis ervan, de afkorting een zeer belangrijke rol speelt in de tekst of wanneer de afkorting niet voorkomt in het Nederlands woordenboek. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/tekstopmaak/#r-pd-3-6">R-pd.3.6</a>)</p>
<p>Zoals de webrichtlijnen ook opmerken wordt <code>&lt;abbr&gt;</code> standaard niet ondersteund door Internet Explorer. <code>&lt;acronym&gt;</code> werkt wel, maar heeft een andere betekenis. Welke gebruik jij? Pas je nog technieken toe om <code>&lt;abbr&gt;</code> wel functioneel te maken binnen Internet Explorer? Hoe kijk je aan tegen de balans tussen het <em>nut</em> van dit element, en de hoeveelheid werk om het juist te gebruiken?</p>
</content>
</entry>
<entry>
<title>Fronteers congres</title>
<link href="https://www.fronteers.nl/nl/blog/2008/03/fronteers-congres"/>
<updated>2008-03-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/03/fronteers-congres</id>
<content xml:lang="nl" type="html"><p>Zoals bekend heeft de Algemene Ledenvergadering afgelopen september besloten dat de eerstvolgende ALV zal worden opgeluisterd door een congres. De voorbereidingen hiervoor zijn inmiddels in gang gezet, en er begint een klein beetje duidelijkheid te komen. De gegevens hieronder zijn nog niet helemaal 100% zeker, maar het is wellicht verstandig alvast een aantekening in je agenda te maken en je baas op de hoogte te stellen. Bovendien willen we graag je mening weten over de inhoud.</p>
<ul>
<li>Wanneer? Donderdag 11 en vrijdag 12 september</li>
<li>Waar? <a href="http://www.dezwijger.nl/">Pakhuis De Zwijger</a> te Amsterdam, net als vorig jaar</li>
<li>Wat? Op dit moment zijn we nog met het programma bezig, en we willen daarover graag jouw input (zie onder).</li>
<li>Kosten? In tegenstelling tot vorig jaar zullen er kosten verbonden zijn aan het congres. Het exacte bedrag is nog niet bekend, maar Fronteers-leden krijgen in elk geval korting.</li>
</ul>
<p>Aansluitend aan dit congres zal de Fronteers Algemene Ledenvergadering plaatsvinden; naar het zich laat aanzien op vrijdag 12 september na afloop van het congres. Hierover volgen nog nadere mededelingen zodra er meer bekend is. Uiteraard zal de ALV gratis toegankelijk zijn voor alle Fronteers-leden.</p>
<p>Wat het programma van het congres betreft: hierover is de congres-organisatie nog in conclaaf. Op dit moment neigen we naar een sterke JavaScript-component, aangezien er veel interesse in deze schitterende taal is.</p>
<p>Niettemin zijn nog lang niet alle puntjes op de i gezet, en daarom zouden we graag jouw mening weten. De vraag voor vandaag is dan ook: wat voor sessies zou je graag op het congres zien? Onderwerpen? Vorm? Sprekers? Andere opmerkingen?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 16: Paragrafen, nieuwe regels en alinea’s</title>
<link href="https://www.fronteers.nl/nl/blog/2008/03/webrichtlijnen-alineas"/>
<updated>2008-03-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/03/webrichtlijnen-alineas</id>
<content xml:lang="nl" type="html"><p>Gebruik het p (paragraph) element voor het aangeven van paragrafen. Gebruik niet het br (linebreak) element voor het scheiden van paragrafen. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/paragrafen/#r-pd-3-4">R-pd.3.4</a>)</p>
<p>Onder de noemer 'Schrijf zowel grammaticaal correcte, als beschrijvende markup (R-pd.3.1)' deze richtlijn over paragrafen.</p>
<p>Wat is voor ons een paragraaf? Het <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/paragrafen/#vb-paragraaf-markup">voorbeeld</a> in de webrichtlijnen is vrij logisch. Maar waarvoor gebruik jij nog meer een <code>&lt;p&gt;</code> element?</p>
<p>Wanneer was de laatste keer dat jij <code>&lt;br&gt;&lt;br&gt;</code> typte? Kun je hiermee leven als iemand anders het doet (zoals hier in de reacties :)?</p>
<p>Heb je links naar documenten waar <code>&lt;br&gt;</code> echt volledig mis<code>&lt;br&gt;</code>uikt wordt? En weet jij, los van gedichten en adressen, nog een legitieme toepassing voor dit element?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 13, 14 &amp; 15: Beschrijvende markup, kopregels</title>
<link href="https://www.fronteers.nl/nl/blog/2008/03/webrichtlijnen-beschrijvende-markup-kopregels"/>
<updated>2008-03-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/03/webrichtlijnen-beschrijvende-markup-kopregels</id>
<content xml:lang="nl" type="html"><p>Schrijf zowel grammaticaal correcte, als beschrijvende markup. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/#r-pd-3-1">R-pd.3.1</a>) Gebruik markup voor kopregels die de hiërarchie van de informatie op de pagina uitdrukken. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/kopregels/#r-pd-3-2">R-pd.3.2</a>) Sla in de markup geen niveaus in de hiërarchie van kopregels over. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/kopregels/#r-pd-3-3">R-pd.3.3</a>)</p>
<p>De webrichtlijnen leggen veel focus op <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/voorbeelden/">semantische markup</a>. <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/#beschrijvende-valide-verschil">Validiteit wordt even aangehaald</a> (hoewel dat <em>niet</em> hetzelfde is als well-formedness). Gestreefd wordt naar zowel <em>grammaticaal correcte</em> (valide) als <em>beschrijvende</em> (semantische) markup. Ik denk dat we <a href="https://www.fronteers.nl/blog/2008/01/webrichtlijnen-r-pd-2-1">validiteit</a> al aardig besproken hebben, dus laten we meteen beginnen met semantiek en <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/beschrijvende-markup/het-schrijven-van/kopregels/">kopregels</a>.</p>
<p>In HTML 4.01 hebben we <a href="http://www.w3.org/TR/html4/struct/global.html#h-7.5.5">de keuze</a> uit <code>&lt;h1&gt;</code>, <code>&lt;h2&gt;</code>, <code>&lt;h3&gt;</code>, <code>&lt;h4&gt;</code>, <code>&lt;h5&gt;</code> en <code>&lt;h6&gt;</code>, waarmee we de hiërarchie van de informatie op een pagina kunnen uitdrukken. Volgens de webrichtlijnen mogen we geen niveau overslaan op een pagina. Hoeveel CMS'en volgen die richtlijn ook echt?</p>
<p>Wat doe jij meestal met de <code>&lt;h1&gt;</code>? Zet je het logo van een site wel eens op het hoogste niveau (zoals hier op fronteers.nl)? Waarom wel/niet? En gebruik jij wel eens meerdere <code>&lt;h1&gt;</code>'tjes op 1 pagina?</p>
<p>Geef je navigatiemenu's ook altijd een kop? En hou je daarbij rekening met de hiërarchie in de pagina, of zet je daar soms stiekem gewoon een <code>&lt;h6&gt;</code> boven? :)</p>
<p>Zijn er trouwens SEO experts die meelezen en hierover nog iets kunnen vertellen? Hoe belangrijk vinden zoekmachines een goede koppenstructuur? En is het echt zo dat (verborgen) koppen boven een menu de overige kopjes op datzelfde niveau in een pagina minder belangrijk maken? En wat vindt de SEO wereld van bijvoorbeeld <code>&lt;h2&gt;&lt;img src=&quot;...&quot; alt=&quot;Koptekst&quot;&gt;&lt;/h2&gt;</code>?</p>
<p>Tot slot: wat vinden we van toekomstige oplossingen die bijvoorbeeld <a href="http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.5.">XHTML 2</a> en <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sections.html#headings">HTML 5</a> voor ogen hebben?</p>
</content>
</entry>
<entry>
<title>Fronteers op IRC</title>
<link href="https://www.fronteers.nl/nl/blog/2008/03/fronteers-op-irc"/>
<updated>2008-03-06T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/03/fronteers-op-irc</id>
<content xml:lang="nl" type="html"><p>Vanaf heden is het IRC kanaal #fronteers op freenode - <a href="irc://irc.freenode.net/fronteers">irc://irc.freenode.net/fronteers</a> - opgericht. De doelstelling bij dit kanaal is om een zeer laagdrempelige vorm van communicatie aan te bieden voor alle Fronteers leden, voor zaken waar je geen email aan zou verspillen, maar die toch nuttig kunnen zijn om af en toe eens met mede front-enders te bespreken.</p>
<p>Natuurlijk is IRC niet een medium wat iedereen aanspreekt (net als mailinglists dat niet zijn, en web forums niet, en facebook niet, en...), en niemand wordt dan ook geacht hierin aanwezig te zijn, noch zal dit IRC kanaal ooit essentiëel zijn voor betrokkenheid bij de vereniging. Maar mocht IRC <em>wel</em> jouw medium zijn, dan is dit kanaal vanaf heden dus beschikbaar. Ook niet-leden zijn natuurlijk welkom. De commissie Online Community zal zich binnenkort uiten over andere online vormen van communicatie.</p>
<p>Het is met het opzetten van een nieuw IRC kanaal altijd een gok hoe deze zal lopen. Misschien blijkt er helemaal geen animo voor te zijn, en blijft het kanaal na de eerste paar weken volledig uitgestorven. Misschien wordt het een babbel en klets kanaal met weinig toegevoegde waarde. Maar misschien weet het de juiste balans te vinden van low-volume, high-signal interactie, met een mix van technische vragen en sociale interactie. Het is een experiment, en we zullen vanzelf zien hoe het loopt.</p>
<p>Mocht je nog nooit van IRC gebruik gemaakt hebben, dan heeft Wikipedia <a href="http://en.wikipedia.org/wiki/List_of_IRC_clients">een lijst met mogelijke IRC clients</a>. Het laagdrempeligst zijn waarschijnlijk de ingebouwde IRC clients van Opera en SeaMonkey, waarbij deze laatste ook als <a href="https://addons.mozilla.org/en-US/firefox/addon/16">extensie voor Firefox</a> beschikbaar is. Als je een IRC client hebt geïnstalleerd zou je vervolgens op de link uit de eerste paragraaf moeten kunnen klikken om automatisch naar het IRC kanaal te gaan. Via je browser kun je <a href="https://webchat.freenode.net/?channels=fronteers">freenode Web IRC</a> gebruiken.</p>
<p>Tenslotte nog een policy puntje: we volgen de <a href="http://freenode.net/channel_guidelines.shtml">freenode guidelines</a> en publiceren geen logs voor dit kanaal. Toch zullen individuele deelnemers aan de conversatie wel logs bijhouden, dus vergeet niet dat IRC een publiek medium is.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 12: Web Content Accessibility Guidelines (WCAG) 1.0</title>
<link href="https://www.fronteers.nl/nl/blog/2008/03/webrichtlijnen-wcag"/>
<updated>2008-03-04T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/03/webrichtlijnen-wcag</id>
<content xml:lang="nl" type="html"><p>Bouw een website volgens de richtlijnen van de Web Content Accessibility Guidelines (WCAG 1.0) van het W3C. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/webstandaarden/wcag/#r-pd-2-9">R-pd.2.9</a>)</p>
<p>Weinig aan toe te voegen...</p>
<p>Of misschien toch, met de <a href="http://wcagsamurai.org/errata/errata.html">Samurai Errata</a>? ;-)</p>
</content>
</entry>
<entry>
<title>Onderzoek naar marktplaats voor freelance opdrachten</title>
<link href="https://www.fronteers.nl/nl/blog/2008/03/onderzoek-naar-marktplaats-voor-freelance-opdrachten"/>
<updated>2008-03-03T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/03/onderzoek-naar-marktplaats-voor-freelance-opdrachten</id>
<content xml:lang="nl" type="html"><p>Pim Hoogendoorn zoekt naar front-end programmeurs die hij voor zijn afstudeerproject kan interviewen. Hieronder staat zijn boodschap.</p>
<p>Nee, geen artikel over het komen tot een betere aansluiting tussen afgestudeerden en de front-end markt. Wel een verzoek van een student bezig in zijn afstudeerjaar. Aangenaam, <a href="http://www.willenium.nl/">Pim Hoogendoorn</a>, student <a href="http://www.voltijd.hva.nl/interactieve-media/">Interactieve Media</a> aan de Hogeschool van Amsterdam. De opleiding om Interactieve Media Professional te worden of zoals ik; een front-end developer.</p>
<p>Ik zit inmiddels in het laatste jaar en ben bezig met mijn afstudeerproject omtrent een online marktplaats voor freelancers. Deze marktplaats moet gevuld gaan worden met korte termijn opdrachten voor freelancers. Denk bij korte termijn aan opdrachten van 1 a 2 weken tot maximaal twee maanden. Ook kunnen freelancers zich aanmelden en hun beschikbaarheid tonen. Deze marktplaats zal zich eerst richten op front- en back-end developers. En misschien in de toekomst op opdrachten in andere branches.</p>
<p>Nu heb ik een enquete gemaakt voor freelancers om mij te helpen bij mijn onderzoek naar deze marktplaats. En nu wil ik u als lezer uitnodigen om <a href="http://www.zoomerang.com/survey.zgi?p=WEB227HW7U58M8">mijn enquete</a> in te vullen.</p>
<p>Alvast bedankt voor uw medewerking. En misschien schrijf ik dat artikel over de betere aansluiting later nog eens. Ik spreek tenslotte uit ervaring.</p>
</content>
</entry>
<entry>
<title>Communicatie tussen design en development</title>
<link href="https://www.fronteers.nl/nl/blog/2008/02/communicatie-tussen-design-en-development"/>
<updated>2008-02-25T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/02/communicatie-tussen-design-en-development</id>
<content xml:lang="nl" type="html"><p>Fronteers-lid Reinier Ladan zoekt naar front-end programmeurs die hij voor zijn afstudeerscriptie kan interviewen. Hieronder staat zijn boodschap.</p>
<p>Het web is veranderd. Interactieve websites heten tegenwoordig Rich Internet Applications en Web 2.0 is geen modeverschijnsel meer. Steeds meer interactie vindt plaats binnen een webpagina zonder naar een andere url te springen. Ook de methodiek van het ontwikkelen van zulke producten en diensten is veranderd. Alles moet 'agile' en met veel iteraties en uiteraard alles in Beta.</p>
<p>Maar is de communicatie tussen designers en ontwikkelaars nog wel helder? Komt alles wat de designer heeft bedacht ook goed aan bij de ontwikkelaar? En snapt de ontwikkelaar dan ook meteen hoe een en ander te bouwen? Over dit raakvlak tussen interactiondesigners en front-end developers gaat mijn scriptie. Ik zoek front-end developers die hieraan willen meewerken. Hoe? Ik kom graag twee keer langs. De eerste keer om een interview van maximaal een uur af te nemen met vragen over de huidige flow van design naar front-end development binnen het bedrijf en mogelijke verbeteringen in de communicatie. Een tweede keer kom ik graag langs om mijn bevindingen en verbetervoorstellen voor te leggen en daarover te discussiëren.</p>
<p>Ik hoop hiermee een methodiek te ontwikkelen waarmee designers en front-end developers op 1 lijn komen te liggen als het gaat om het ontwikkelen van RIA's en web 2.0 producten.</p>
<p>Interesse? Mail me op <a href="mailto:reinierl@gmail.com">reinierl@gmail.com</a> of bel met 0624872725. Mijn dank is groot!</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 9: Cascading Style Sheets (CSS) Level 2.1</title>
<link href="https://www.fronteers.nl/nl/blog/2008/02/webrichtlijnen-css"/>
<updated>2008-02-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/02/webrichtlijnen-css</id>
<content xml:lang="nl" type="html"><p>Gebruik CSS Level-2.1 volgens de W3C specificatie voor het vormgeven van overheidswebsites. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/webstandaarden/css2-1/#r-pd-2-6">R-pd.2.6</a>)</p>
<p>Eindelijk 'ns wat anders dan dat geneuzel over markup :) Laten we het eens gaan hebben over de presentatie van een website; Cascading Style Sheets.</p>
<p>De <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/css/voordelen/">voordelen van CSS</a> zijn voor iedereen ondertussen waarschijnlijk wel bekend, maar het is niet verkeerd om ze nog eens door te nemen.</p>
<p><a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/css/richtlijnen/#css-3">CSS Level 3 wordt afgeraden</a>, dus volgens de richtlijn mogen we alleen de volgende selectors gebruiken:</p>
<ul>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#universal-selector"><code>*</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#type-selectors"><code>E</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#descendant-selectors"><code>E F</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#child-selectors"><code>E &gt; F</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#first-child"><code>E:first-child</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#link-pseudo-classes"><code>E:link</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#link-pseudo-classes"><code>E:visited</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#dynamic-pseudo-classes"><code>E:active</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#dynamic-pseudo-classes"><code>E:hover</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#dynamic-pseudo-classes"><code>E:focus</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#lang"><code>E:lang(c)</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#adjacent-selectors"><code>E + F</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#attribute-selectors"><code>E[foo]</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#attribute-selectors"><code>E[foo=&quot;warning&quot;]</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#attribute-selectors"><code>E[foo~=&quot;warning&quot;]</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#attribute-selectors"><code>E[lang|=&quot;en&quot;]</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#class-html"><code>DIV.warning</code></a></li>
<li><a href="http://www.w3.org/TR/CSS21/selector.html#id-selectors"><code>E#myid</code></a></li>
</ul>
<p>Wie gebruikt er al <a href="http://www.w3.org/TR/css3-selectors/#selectors">selectors uit CSS Level 3</a>? Wat zijn daarbij je ervaringen?</p>
<p>Hoe ga je om met IE-only stijlen als <code>zoom: 1;</code> en <code>filter: alpha(opacity=25);</code>? Gebruik je die gewoon, ondanks dat ze niet in de standaard zijn opgenomen? Dezelfde vraag natuurlijk voor <code>word-wrap: break-word;</code>, <code>-moz-opacity</code>, <code>-o-background-size</code> en andersoortige eigenschappen die je niet weg kunt moffelen achter een <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/css/richtlijnen/ondersteuning-browsers/#conditional-comments">conditional comment</a>.</p>
<p>En kan iedereen zich trouwens vinden in de <a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/css/richtlijnen/ondersteuning-browsers/#drie-groepen-browsers">drie groepen browsers</a> die de Webrichtlijnen onderscheidt?</p>
<p>Zien we deze richtlijn als een beperking? Of als een handvat waar we wat aan hebben? Wanneer vind jij dat CSS Level 3 of modules daarvan ook toegestaan mogen worden?</p>
</content>
</entry>
<entry>
<title>Cursus front-end in de maak</title>
<link href="https://www.fronteers.nl/nl/blog/2008/02/cursus-front-end"/>
<updated>2008-02-14T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/02/cursus-front-end</id>
<content xml:lang="nl" type="html"><p>Degenen die de mailinglijst van Fronteers vanaf het begin gevolgd hebben, zullen weten dat ik destijds begonnen ben met het vertalen van <a href="http://htmldog.com/">HTMLdog.com</a>. Op deze website staan heldere teksten die voor beginnende front-end ontwikkelaars een goed leermiddel kan zijn. Voor het vertaalwerk vroeg ik mensen te helpen, vele handen maken immers licht werk.</p>
<p>Na een explosieve start met diverse vertalers, daalde spirit tot een nulpunt bij zowel mij als de andere vertalers toen de zomervakantie voorbij was. Dit is iets wat ik van mezelf -als aanstichter van het project- erg betreur. In de actieve tijd is een groot deel van de beginners artikelen vertaald. Het leek echt alsof alles binnen een maand klaar zou zijn.</p>
<p>Het is de bedoeling een compleet nieuwe website op te zetten. Deze zal specifiek gericht zijn op docenten en studenten. We kunnen als front-end ontwikkelaars dan gemakkelijk mensen doorsturen, als die websites willen leren maken. Geen verwarrende artikelen voor gevorderden, geen storende nieuwsberichten welke alleen professionals begrijpen. De website zal een heldere plaats zijn om de cursus te volgen, of te downloaden. De vertaalde werken van HTMLdog zouden ook slechts de basis zijn van de website, waarna deze uitgebreid kan worden. Denk aan een basiscursus JavaScript.</p>
<p>Maar zoals gezegd, is indertijd het project aan een stille dood gestorven. Daar wil ik nu echter verandering in brengen. Ik heb een planning gemaakt om in de komende maanden alle vertalingen gereed te maken, en de website goed getest online te plaatsen. Na de zomervakantie kan de cursus omarmd worden door onderwijzend Nederland en België.</p>
<p>Hiervoor heb ik echter wat hulp nodig. De mensen die destijds hebben geholpen heb ik weer benaderd, maar wil toch een oproep doen om meer helpende handen te vinden. Als je graag mee wilt helpen, dan kun je <a href="http://arjaneising.nl/about/#contact">contact opnemen met mij</a>. Ik zal je dan van meer informatie voorzien.</p>
<p>Hierbij overigens ook direct een oproep voor nieuwe ideeën. Wat zou jij van een website met cursus als deze verwachten? Reacties kun je hier achterlaten.</p>
</content>
</entry>
<entry>
<title>Bestuurswijzigingen: penningmeester en secretaris</title>
<link href="https://www.fronteers.nl/nl/blog/2008/02/bestuurswijzigingen-penningmeester-en-secretaris"/>
<updated>2008-02-13T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/02/bestuurswijzigingen-penningmeester-en-secretaris</id>
<content xml:lang="nl" type="html"><p>Penningmeester gevonden; secretaris tijdelijk uit de running.</p>
<p>Zoals bekend is Fronteers reeds sinds augustus op zoek naar een penningmeester, en heeft de financiele en administratieve afhandeling van het lidmaatschap enige vertraging opgelopen door het ontbreken daarvan.</p>
<p>Gelukkig heeft er zich vorige week eindelijk iemand aangemeld: Krijn Hoetmer, die jullie reeds kennen van zijn inspanningen om de Fronteers-site in de lucht te krijgen en houden. Derhalve zal Krijn zich over de financiele zaken buigen, zodat de rest van het bestuur zich op andere dingen kan richten.</p>
<p>Formeel wordt Krijn geen bestuurslid, aangezien hij niet door de ALV verkozen is. In praktijk draait hij wegens zijn website-werk overigens al enige tijd mee in het bestuur, dus er zal niet veel veranderen.</p>
<p>Daarnaast gaat secretaris Tom Greuter er voor enige tijd uit wegens een operatie en herstelperiode. Tijdens zijn afwezigheid zal bestuurslid Arjan Eising zijn taken waarnemen. We wensen Tom een spoedig herstel; voorlopig is de verwachting dat hij rond eind mei weer in staat zal zijn zijn bestuursfunctie volledig te vervullen.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 7 &amp; 8: Gebruik de Strict variant voor nieuwe websites, en ontwijk de Frameset variant</title>
<link href="https://www.fronteers.nl/nl/blog/2008/02/webrichtlijnen-strict-markup"/>
<updated>2008-02-12T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/02/webrichtlijnen-strict-markup</id>
<content xml:lang="nl" type="html"><p>Bij de bouw van een nieuwe website: gebruik van HTML 4.01 of XHTML 1.0 de Strict variant. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/webstandaarden/html4-01/#r-pd-2-4">R-pd.2.4</a>) Gebruik geen frames op overheidswebsites. Gebruik daarom ook niet van HTML 4.01 of XHTML 1.0 de Frameset variant. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/webstandaarden/html4-01/#r-pd-2-5">R-pd.2.5</a>)</p>
<p>Dus...is er nog iemand die nieuwe templates met een Transitional doctype begint?</p>
<p>Het lijkt alsof we een beetje in herhaling vallen, maar dat is ook zo ;) Misschien moeten we voor de discussie maar wat richtlijnen samen gaan pakken.</p>
<p>Aangezien frames niet meer van deze tijd zijn en niet meer toegestaan zijn op overheidssites, wordt het gebruik van de Frameset doctype ook afgeraden. Is iedereen het met deze richtlijn eens? Zijn frames echt zo slecht voor toegankelijkheid?</p>
<p>Heb jij in de afgelopen 2 jaar nog (i)frames gebruikt? Zo ja, waarvoor?</p>
</content>
</entry>
<entry>
<title>Verslag bijeenkomst 8 februari</title>
<link href="https://www.fronteers.nl/nl/blog/2008/02/verslag-bijeenkomst"/>
<updated>2008-02-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/02/verslag-bijeenkomst</id>
<content xml:lang="nl" type="html"><p>Een verslag van de bijeenkomst van afgelopen vrijdag is zojuist op de website gepubliceerd.</p>
<p>Lees <a href="https://www.fronteers.nl/bijeenkomsten/2008/info-nl">het verslag</a>.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 6: Gebruik bij voorkeur alleen de Strict variant (R-pd.2.3)</title>
<link href="https://www.fronteers.nl/nl/blog/2008/02/webrichtlijnen-transitional-markup"/>
<updated>2008-02-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/02/webrichtlijnen-transitional-markup</id>
<content xml:lang="nl" type="html"><p>Bij het aanpassen van een bestaande website: gebruik van HTML 4.01 of XHTML 1.0 alleen de Transitional variant als het gebruik van de Strict variant onmogelijk of onwenselijk is. (<a href="http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/webstandaarden/html4-01/#r-pd-2-3">R-pd.2.3</a>)</p>
<p>Het lijkt een rekbaar begrip: &quot;onmogelijk of onwenselijk&quot;. Waar leg je de grens?</p>
</content>
</entry>
<entry>
<title>Bijeenkomst 8 februari is vol</title>
<link href="https://www.fronteers.nl/nl/blog/2008/02/bijeenkomst-8-februari-is-vol"/>
<updated>2008-02-05T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/02/bijeenkomst-8-februari-is-vol</id>
<content xml:lang="nl" type="html"><p>De Fronteersmeeting van aanstaande vrijdag 8 februari bij Info.nl is vol. We hebben inmiddels meer dan 50 aanmeldingen binnen en dat is wel zo'n beetje het maximum dat in de kantine van <a href="http://www.info.nl/">Info.nl</a> past.</p>
<p>Diegenen die zich nu nog aanmelden voor de bijeenkomst zullen op een wachtlijst geplaatst worden. Mochten zich mensen afmelden, dan kunnen we de open plaatsen opvullen. Daarom wil ik met klem verzoeken of diegenen die zich al aangemeld hebben, maar bij nader inzien toch niet kunnen komen, zich af willen melden bij <a href="mailto:tom@info.nl">Tom Greuter</a>. De sprekers van vrijdag, Peter-Paul Koch en Anne van Kesteren, zullen vast niet voor het laatst spreken op een Fronteersbijeenkomst, dus er komt ongetwijfeld nog een gelegenheid om hun te zien.</p>
<p>De presentatie van Peter-Paul zal overigens niet gaan over de scheiding tussen presentatie en gedrag, zoals <a href="https://www.fronteers.nl/blog/2008/01/fronteers-bijeenkomst-8-februari-amsterdam">eerder</a> aangekondigd, maar over de nieuwe versie van Internet Explorer, IE8. In zijn presentatie zal Peter-Paul niet alleen ingaan op het bekende ALA-artikel <a href="http://www.alistapart.com/articles/beyonddoctype">Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8</a>, maar wil hij ook een overzicht geven van hoe een en ander nou precies gaat werken.</p>
<p><em>Update 11 februari</em>: <a href="https://www.fronteers.nl/bijeenkomsten/2008/info-nl">Het verslag staat online</a>.</p>
</content>
</entry>
<entry>
<title>Commissie Diplomering zoekt vragen</title>
<link href="https://www.fronteers.nl/nl/blog/2008/01/commissie-diplomering-zoekt-vragen"/>
<updated>2008-01-26T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/01/commissie-diplomering-zoekt-vragen</id>
<content xml:lang="nl" type="html"><p>De <a href="http://fronteers.nl/vereniging/commissies/diplomering">Commissie Diplomering</a> is al aardig op stoom, de laatste maanden zijn we een aantal keren bij elkaar gekomen en we hebben op dit moment een redelijk uitgekristalliseerd plan geformuleerd. Voordat we dat helemaal openbaar gaan maken, willen we het wel eerst uittesten. En daar hebben we jullie hulp bij nodig. Een van de onderdelen van het <em>examen</em> is namelijk een rondje theorie.</p>
<p>Dit doen we om een zo objectief mogelijk oordeel te kunnen vellen. Het probleem met ons werkgebied is namelijk dat er heel moeilijk kan worden getest op een waarheid.</p>
<blockquote>
<p>In our wonderful world of web design, there are 3,647 ways to accomplish the same goal. Approximately.</p>
</blockquote>
<p>Zo is het mogelijk om bijna ieder probleem op verschillende manieren op te lossen. Waar we dus naar op zoek zijn, zijn vragen over CSS en HTML die zo objectief mogelijk te toetsen zijn. Een goede plek om te beginnen is bij <a href="http://www.w3.org/TR/">de specificaties van het W3C</a>. Bij deze dus de oproep om theorie vragen (en eventueel de bijbehorende antwoorden) over CSS en HTML in te sturen, zodat we zo snel mogelijk genoeg vragen hebben om een (proef)examen te houden.</p>
<p>Mocht je hierover nog vragen hebben of meer informatie willen hebben, neem dan <a href="http://wnas.nl/index.php/contact">contact</a> met me op of spreek me aan bij de volgende <a href="https://www.fronteers.nl/blog/2008/01/fronteers-bijeenkomst-8-februari-amsterdam">bijeenkomst</a>.</p>
</content>
</entry>
<entry>
<title>Fronteersbijeenkomst 8 februari: 2e spreker bekend</title>
<link href="https://www.fronteers.nl/nl/blog/2008/01/fronteersbijeenkomst-8-februari-2e-spreker-bekend"/>
<updated>2008-01-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/01/fronteersbijeenkomst-8-februari-2e-spreker-bekend</id>
<content xml:lang="nl" type="html"><p>Na Peter-Paul Koch is nu ook de tweede spreker op de Fronteersbijeenkomst van 8 februari bekend: <a href="http://annevankesteren.nl/">Anne van Kesteren</a>.</p>
<p>Anne zal een korte presentatie geven over het onlangs door het W3C gepubliceerde <a href="http://www.w3.org/TR/2008/WD-html5-20080122/">HTML 5</a> - de markuptaal van het Web. Na deze presentatie van circa vijftien minuten is er ruim tijd voor discussie.</p>
<p>Zie de <a href="https://www.fronteers.nl/blog/2008/01/fronteers-bijeenkomst-8-februari-amsterdam">oude aankondiging</a> voor het volledige programma van 8 februari. Om jezelf aan te melden, kun je <a href="https://www.fronteers.nl/bijeenkomsten/planning#formulier-1">dit formulier</a> gebruiken.</p>
<p><em>Update 11 februari</em>: <a href="https://www.fronteers.nl/bijeenkomsten/2008/info-nl">Het verslag staat online</a>.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 4: Gebruik HTML 4.01 of XHTML 1.0 (R-pd.2.1)</title>
<link href="https://www.fronteers.nl/nl/blog/2008/01/webrichtlijnen-html-of-xhtml"/>
<updated>2008-01-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/01/webrichtlijnen-html-of-xhtml</id>
<content xml:lang="nl" type="html"><p>Gebruik HTML 4.01 of XHTML 1.0 volgens de W3C specificaties voor de markup van overheidswebsites. (<a href="http://webrichtlijnen.overheid.nl/handleiding/ontwikkeling/productie/webstandaarden/html4-01/#r-pd-2-1">R-pd.2.1</a>)</p>
<p>Wat doe je als je van een partij als eis krijgt XHTML <em>1.1</em> te gebruiken? Zoek je dan gewoon die mooie <a href="http://hsivonen.iki.fi/doctype/">Doctype</a>? Of ga je <a href="http://www.w3.org/TR/xhtml-media-types/#summary">steigeren</a>?</p>
<p>Hoe is je ervaring met back-end ontwikkelaars en/of CMS pakketten? Welke problemen kom je wanneer tegen? Wanneer &quot;laat je over je heen lopen&quot; en wanneer niet?</p>
<p>Hoe is de verdeling tussen HTML 4.01 en XHTML 1.0 in je werk? Heb je een persoonlijke voorkeur? Waarom? Hoe ver ga je als je voor een bepaalde smaak hebt gekozen? Laat je een <code>&lt;br /&gt;</code> toe in HTML 4.01? Of een <code>&lt;br&gt;</code> in een XHTML 1.0 document? Waarom zou het <a href="http://hixie.ch/advocacy/xhtml">iets uitmaken</a> als alles als <code>text/html</code> wordt verstuurd en browsers het toch als een tag-soepzooitje zien?</p>
<p>En is deze hele discussie---en misschien de richtlijn zelf---nog wel relevant met <a href="http://www.w3.org/html/wg/html5/">HTML 5</a> in het verschiet?</p>
</content>
</entry>
<entry>
<title>Commissie Openbaar Ledenregister</title>
<link href="https://www.fronteers.nl/nl/blog/2008/01/commissie-openbaar-ledenregister"/>
<updated>2008-01-17T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/01/commissie-openbaar-ledenregister</id>
<content xml:lang="nl" type="html"><p>Sander Aarts heeft zich aangemeld als voorzitter voor de commissie Openbaar Ledenregister. Deze commissie zoekt nog leden.</p>
<p>De commissie zal zich in eerste instantie buigen over enkele vragen, die op de <a href="https://www.fronteers.nl/vereniging/commissies/openbaar-ledenregister">commissiepagina</a> worden beschreven. Op deze pagina staat ook een formulier waarmee geinteresseerden zich als lid kunnen aanmelden.</p>
<p>Naast Openbaar Ledenregister heeft de Algemene Ledenvergadering van 18 september nog vier andere commissies ingesteld:</p>
<ul>
<li>Certificatie: dient Fronteers een formele, geaccrediteerde certificatie in te stellen in plaats van of naast een informele diplomering?</li>
<li>Flash: wat kan Fronteers betekenen voor de Flash-gemeenschap?</li>
<li>Online Community: op welke wijze kan een online community een bijdrage leveren aan Fronteers? Hoe dient deze online community er precies uit te zien?</li>
<li>Webrichtlijnen: hoe kunnen we de Webrichtlijnen beter onder de aandacht brengen? Indien een Webrichtlijn in de praktijk voor problemen zorgt, kunnen we dan aanbevelingen doen voor een verbeterde versie?</li>
</ul>
<p>Voor geen van deze vier commissies hebben zich nog leden aangemeld. Mocht je geinteresseerd zijn een van deze commissies als voorzitter te gaan opzetten, dan kan je <a href="https://www.fronteers.nl/contact">contact</a> met ons opnemen.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 3: Niet rekenen op optionele technologie (R-pd.1.3)</title>
<link href="https://www.fronteers.nl/nl/blog/2008/01/webrichtlijnen-optionele-technologie"/>
<updated>2008-01-15T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/01/webrichtlijnen-optionele-technologie</id>
<content xml:lang="nl" type="html"><p>Maak de functie van de website niet afhankelijk van optionele technologie, zoals CSS en client-side script: optionele technologie dient de informatie op de site en het gebruik ervan te complementeren en niet de toegang ertoe te belemmeren wanneer deze technologie niet ondersteund wordt. (<a href="http://webrichtlijnen.overheid.nl/handleiding/ontwikkeling/productie/filosofie/gelaagd-bouwen/optionele-technologie/#r-pd-1-3">R-pd.1.3</a>)</p>
<p>Volgens de richtlijn zijn er uitzonderingen. Ben jij het met die uitzonderingen eens?</p>
<p>Hou je rekening met het feit dat afbeeldingen uit kunnen staan? En dan niet met betrekking tot <a href="http://annevankesteren.nl/2004/12/alt-attribute">het <code>alt</code> attribuut</a>, maar met oog op <code>image replacement</code> technieken (<code>text-indent: -9999px; background-image: url(foo.png);</code> bijvoorbeeld). Hoe ver ga je?</p>
<p>Voeg jij HTML met functionaliteit waar JavaScript voor vereist is altijd toe met JavaScript zelf? Of maak je soms een uitzondering? In welke gevallen?</p>
<p>Wanneer adviseer je klanten of opdrachtgevers trouwens <a href="http://webrichtlijnen.overheid.nl/handleiding/ontwikkeling/productie/filosofie/gelaagd-bouwen/site-aanpassen/">om de hele site opnieuw te (laten) bouwen</a>?</p>
</content>
</entry>
<entry>
<title>Fronteers-bijeenkomst: 8 februari Amsterdam</title>
<link href="https://www.fronteers.nl/nl/blog/2008/01/fronteers-bijeenkomst-8-februari-amsterdam"/>
<updated>2008-01-11T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/01/fronteers-bijeenkomst-8-februari-amsterdam</id>
<content xml:lang="nl" type="html"><p>Na een pauze voor de feestdagen hervat Fronteers zijn bijeenkomstencyclus weer. De eerste bijeenkomst in het nieuwe jaar zal plaatsvinden in de kantine bij <a href="http://info.nl/">Info.nl</a> te Amsterdam op vrijdag 8 februari.</p>
<p>Hierbij nodigen we alle geinteresseerden uit deze bijeenkomst bij te wonen. Niet-leden zijn van harte welkom, de toegang is gratis, maar reserveren is <em>wel</em> noodzakelijk. Dit kun je doen bij Tom Greuter van Info.nl via de <a href="https://www.fronteers.nl/bijeenkomsten/planning">aanmeldingspagina</a>.</p>
<p>Het programma ziet er als volgt uit:</p>
<ul>
<li>18:00 uur - Zaal open; welkom</li>
<li>19:00 uur - Eerste presentatie</li>
<li>20:00 uur - Tweede presentatie</li>
<li>21:00 uur - Eind tweede presentatie; bier en networking</li>
</ul>
<p>Tijdens dit geheel zal info.nl voor enige catering zorgen; een pilsje of frisje plus een hapje zijn dus beschikbaar.</p>
<p>Ikzelf zal een presentatie houden over de scheiding tussen presentatie en gedrag; oftewel: welke effecten zou je in CSS moeten coderen en welke in JavaScript? Persoonlijk ben ik van mening dat CSS thans teveel wordt gebruikt voor effecten die eigenlijk in de JavaScript-laag thuishoren, en ik zal proberen de aanwezigen daarvan te overtuigen. Uiteraard wordt dit gevolgd door discussie.</p>
<p>Als tweede spreker zal <a href="http://annevankesteren.nl/">Anne van Kesteren</a> een korte presentatie geven over het onlangs door het W3C gepubliceerde <a href="http://www.w3.org/TR/2008/WD-html5-20080122/">HTML 5</a> - de markuptaal van het Web. Na deze presentatie van circa vijftien minuten is er tijd voor een discussie over HTML 5.</p>
<p>Ik hoop op een flinke opkomst. Tot de 8e.</p>
<p><em>Update 5 februari</em>: De Fronteersmeeting van aanstaande vrijdag 8 februari bij Info.nl is vol. Diegenen die zich nu nog aanmelden voor de bijeenkomst zullen op een wachtlijst geplaatst worden.</p>
<p><em>Update 11 februari</em>: <a href="https://www.fronteers.nl/bijeenkomsten/2008/info-nl">Het verslag staat online</a>.</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 2: Gelaagd bouwen (R-pd.1.2)</title>
<link href="https://www.fronteers.nl/nl/blog/2008/01/webrichtlijnen-gelaagd-bouwen"/>
<updated>2008-01-08T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/01/webrichtlijnen-gelaagd-bouwen</id>
<content xml:lang="nl" type="html"><p>Deze week de tweede richtlijn: Bouw websites volgens het principe van gelaagd bouwen. (<a href="http://webrichtlijnen.overheid.nl/handleiding/ontwikkeling/productie/filosofie/gelaagd-bouwen/#r-pd-1-2">R-pd.1.2</a>)</p>
<p>Probeer jij altijd rekening te houden met <em>Progressive Enhancement</em> en/of <em>Graceful Degradation</em>? Vind jij dat er een verschil is tussen die twee? Spelen budgetten en deadlines een rol bij je beslissingen? Wanneer vind jij iets wat opgeleverd is eigenlijk onacceptabel? In hoeverre test je de verschillende lagen die je maakt?</p>
</content>
</entry>
<entry>
<title>Webrichtlijn 1: Scheiding tussen structuur en vormgeving (R-pd.1.1)</title>
<link href="https://www.fronteers.nl/nl/blog/2008/01/webrichtlijnen-scheiding-structuur-vormgeving"/>
<updated>2008-01-01T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2008/01/webrichtlijnen-scheiding-structuur-vormgeving</id>
<content xml:lang="nl" type="html"><p>Het leek ons leuk (Gelukkig nieuwjaar overigens!) om een discussie aan te zwengelen over de <a href="http://webrichtlijnen.overheid.nl/">webrichtlijnen van de overheid</a>. Niet in het wilde weg: wat vind je nou van die richtlijnen, maar juist per richtlijn: hoe waardevol, correct, belangrijk is hij? 125 richtlijnen, iedere week 1. Zo zijn we wel even bezig! :P Deze week de eerste richtlijn: Houd structuur en vormgeving zoveel mogelijk gescheiden: gebruik HTML of XHTML voor de structuur van de site en CSS voor de vormgeving ervan. (<a href="http://webrichtlijnen.overheid.nl/handleiding/ontwikkeling/productie/filosofie/scheiding-structuur-vormgeving/#r-pd-1-1">R-pd.1.1</a>)</p>
<p>Wanneer wijk jij af van deze richtlijn? Wanneer plaats je CSS <em>wel</em> rechtstreeks in een HTML bestand? Wat vind je van het toestaan van HTML <em>of</em> XHTML (de discussie over versienummers komt later...)? Wanneer is het lastig om deze richtlijn na te leven? Kun jij je vinden in alle <a href="http://webrichtlijnen.overheid.nl/handleiding/ontwikkeling/productie/filosofie/scheiding-structuur-vormgeving/voordelen/">voordelen</a> of zie jij ook nadelen?</p>
</content>
</entry>
<entry>
<title>De doelstellingen van het W3C zijn meer een visie dan echte regels</title>
<link href="https://www.fronteers.nl/nl/blog/2007/12/doelstellingen-w3c-meer-visie-dan-regels"/>
<updated>2007-12-24T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2007/12/doelstellingen-w3c-meer-visie-dan-regels</id>
<content xml:lang="nl" type="html"><p>Op ons <a href="https://www.fronteers.nl/blog/2007/12/welkom">welkomstbericht</a> hebben we tientallen reacties gehad. Sommige reacties zijn daarom enigszins ondergesneeuwd. De discussie die <a href="https://www.fronteers.nl/blog/2007/12/welkom#reactie-40">Cyppher</a> aan wilde zwengelen, wil ik daarom hier herhalen.</p>
<p>Het W3C is van een initiatiefrijke en visionaire organisatie 'gegroeid' naar een logge en op-zichzelf-achterlopende groep mensen. Prachtig dat standaarden ontwikkeld worden, maar vervelend dat een hoop van die standaarden in de praktijk niet werken. Mijn stelling: De doelstellingen van het W3C zijn meer een visie dan echte regels.</p>
</content>
</entry>
<entry>
<title>Opzeggingen van Lon &amp; Tino</title>
<link href="https://www.fronteers.nl/nl/blog/2007/12/opzeggingen"/>
<updated>2007-12-23T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2007/12/opzeggingen</id>
<content xml:lang="nl" type="html"><p>Het ligt niet in mijn bedoeling om elke opzegging van een lid publiekelijk bekend te maken via dit blog, maar de opzeggingen van Lon Boonen (in november) en Tino Zijdel (in december) wil ik jullie niet onthouden. Zij waren namelijk in september jl. nog kandidaat-bestuursleden. Om diverse redenen hebben zij helaas opgezegd.</p>
<p>Zonder Lon en Tino missen we een uitgesproken kritisch geluid binnen Fronteers. Ik verwacht en hoop van de leden dat zij het bestuur kritisch zullen blijven volgen en ons er op aan zullen spreken wanneer zij menen dat dit nodig is. Persoonlijk heb ik daar alle vertrouwen in, want al tijdens de <a href="https://www.fronteers.nl/vereniging/bestuur/notulen/18-09-07">ALV</a> hebben jullie je stem duidelijk laten horen! Ik hoop dat dit blog een goed medium is voor de noodzakelijke discussies.</p>
</content>
</entry>
<entry>
<title>RSS beschikbaar</title>
<link href="https://www.fronteers.nl/nl/blog/2007/12/rss-beschikbaar"/>
<updated>2007-12-22T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2007/12/rss-beschikbaar</id>
<content xml:lang="nl" type="html"><p>Op veler verzoek heeft Krijn gisteren de RSS-feed van het blog geactiveerd, dus hang hem gauw in je favoriete reader! Een feed van aankomende bijeenkomsten is in de maak.</p>
</content>
</entry>
<entry>
<title>Welkom op Fronteers.nl - deel 2</title>
<link href="https://www.fronteers.nl/nl/blog/2007/12/welkom-op-fronteers-nl-deel-2"/>
<updated>2007-12-21T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2007/12/welkom-op-fronteers-nl-deel-2</id>
<content xml:lang="nl" type="html"><p>De website staat nu twee dagen live en we zijn al overstelpt door een grote hoeveelheid reacties, zowel op de website als via de mail. We willen van Fronteers een levendige community maken, dus we zijn blij verrast! Er hebben zich nieuwe leden aangemeld, anderen hebben aangegeven zich actief in te willen zetten voor een bepaalde commissie en daarnaast hebben we ook een hoop tips gehad.</p>
<p>Uiteindelijk zullen we bij iedereen terugkomen, al zal dat niet binnen een paar dagen gebeuren. Mede door de vakantie van Peter-Paul is onze eerstvolgende bestuursvergadering pas op 15 januari. Dus even geduld alsjeblieft als je denkt &quot;waarom hoor ik nu niets van die gasten?&quot;</p>
<p>Je kunt je afvragen waarom we dan de website niet wat later live gebracht hebben? Tja, eigenlijk wilde ik hem gewoon de wereld in schoppen. Achter de schermen kun je wel eeuwig doorgaan met finetunen, maar mij leek de website nu goed genoeg. Bovendien is de ALV alweer drie maanden achter de rug; tijd voor wat HTML-sneeuw!</p>
</content>
</entry>
<entry>
<title>Welkom op Fronteers.nl</title>
<link href="https://www.fronteers.nl/nl/blog/2007/12/welkom"/>
<updated>2007-12-19T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2007/12/welkom</id>
<content xml:lang="nl" type="html"><p>Welkom op de gloednieuwe website van Fronteers, vakvereniging voor front-end developers. Na een paar maanden (non-non-stop) zwoegen en zweten is het dan eindelijk zover!</p>
<p>De tijdelijke naam <em>Gilde van Front-Enders</em> is tijdens <a href="https://www.fronteers.nl/vereniging/bestuur/notulen/18-09-07">het oprichtingscongres</a> in september weggestemd. Hierna is <em>Fronteers</em> gekozen als verenigingsnaam en in oktober is de vereniging daadwerkelijk opgericht. Middels deze site hopen we iedereen die vragen en onduidelijkheden heeft tegemoet te komen.</p>
<p>De informatie op <a href="http://www.quirksmode.org/branche/">de tijdelijke site van Peter-Paul Koch</a> is ondertussen verouderd. Wellicht dat die pagina's de komende tijd komen te vervallen of door een <code>301</code> doorgestuurd worden naar deze site, maar dat is aan Peter-Paul.</p>
<h2>De website</h2>
<p>Het live brengen van de site heeft iets langer geduurd dan in eerste instantie gehoopt. Zoals een paar onbemande <a href="https://www.fronteers.nl/vereniging/commissies">commissies</a> aantonen, zijn vrijwilligers en de tijd die zij vrijmaken schaars. Zo ook voor het ontwerpen, bouwen en inrichten van deze site.</p>
<p>Voor het ontwerp en logo moeten we trouwens Andries Reitsma van <a href="http://www.edendesign.nl/">Eden Design</a> hartelijk bedanken. Bij dezen dus! Er zullen nog wel wat puntjes bijgeschaafd moeten worden, maar daar hebben we de kerstdagen voor :)</p>
<p>Er staan sowieso nog een hoop toevoegingen in de planning:</p>
<ul>
<li>Verslagen van de reeds gehouden bijeenkomsten</li>
<li>De ledenlijst met voornaam, achternaam en werkgever</li>
<li>Een onderdeel voor leden achter een login (o.a. adresgegevens online wijzigen)</li>
<li>Een soort helpdesk met gestructureerde, onderbouwde links naar interessante sites</li>
<li>Een zoekfunctie voor de site</li>
<li>Een 'schrijf zelf' onderdeel voor het weblog</li>
<li>Diverse RSS feeds (bijeenkomsten, weblog, reacties)</li>
<li>Hier en daar verbeteringen in de teksten</li>
<li>…en waarschijnlijk nog een hoop meer</li>
</ul>
<p>Voor nu is dit in ieder geval onze website. Hopelijk kan front-end Nederland zijn en haar weg hier vinden.</p>
<p>Reacties? Kritiek? Ideeën? Laat je horen! :)</p>
</content>
</entry>
<entry>
<title>Penningmeester gezocht</title>
<link href="https://www.fronteers.nl/nl/blog/2007/12/penningmeester-gezocht"/>
<updated>2007-12-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2007/12/penningmeester-gezocht</id>
<content xml:lang="nl" type="html"><p>Het bestuur is nog steeds op zoek naar een penningmeester voor Fronteers.</p>
<p>Nu we een officieel geregistreerde vereniging zijn, krijg ik als secretaris allemaal rare post opgestuurd van de KvK, de Belastingdienst en een hele serie derde partijen, wiens voornaamste intentie lijkt te zijn om onze vereniging op een of andere wijze een poot uit te draaien.</p>
<p>Geïnteresseerden voor de functie kunnen zich <a href="https://www.fronteers.nl/contact">melden bij het bestuur</a> (gaarne opstellen in rijen van drie).</p>
</content>
</entry>
<entry>
<title>Notulen bestuursvergadering 9 oktober online</title>
<link href="https://www.fronteers.nl/nl/blog/2007/12/notulen-bestuursvergadering-9-oktober-2007-online"/>
<updated>2007-12-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2007/12/notulen-bestuursvergadering-9-oktober-2007-online</id>
<content xml:lang="nl" type="html"><p>De notulen van de bestuursvergadering van 9 oktober 2007 zijn nu online te lezen. Deze vergadering werd gehouden net na de officiële oprichting van Fronteers bij de notaris.</p>
<p>Lees <a href="https://www.fronteers.nl/vereniging/bestuur/notulen/09-10-07">de notulen</a>.</p>
</content>
</entry>
<entry>
<title>Notulen ALV online</title>
<link href="https://www.fronteers.nl/nl/blog/2007/12/notulen-alv-online"/>
<updated>2007-12-18T00:00:00Z</updated>
<id>https://www.fronteers.nl/nl/blog/2007/12/notulen-alv-online</id>
<content xml:lang="nl" type="html"><p>De notulen van de Algemene Ledenvergadering van 18 september (tijdens het oprichtingscongres) staan nu online op de Fronteers website.</p>
<p>Zojuist heb ik <a href="https://www.fronteers.nl/vereniging/bestuur/notulen/18-09-07">de notulen van de oprichtingsvergadering</a> van Fronteers van 18 september jl. online gezet. De notulen zijn ingezien en zonodig aangevuld door alle kandidaat-bestuursleden van die avond, en door de voorzitter. De notulen moeten eindelijk goedgekeurd worden door de leden, op de volgende ALV.</p>
</content>
</entry>
</feed>
If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid Atom 1.0" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src
attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
http://www.feedvalidator.org/check.cgi?url=https%3A//fronteers.nl/feeds/blog.xml