Bij de oprichting van Embrace IT eind 2017 gold vooral het motto move fast. Ruim een jaar verder wordt het tijd om de oorspronkelijke (kuch, WordPress) site te vervangen met iets toekomstbestendigers. Een mooie gelegenheid om na te denken over onze boodschap, en te werken aan onze presentatie.
Zeker voor een bedrijf dat web developers opleidt en aan klanten levert verwacht je toch een minimum standaard. Ik hoop dat de site die je nu onder ogen hebt daar aan voldoet. Tegelijkertijd is het zonde om veel tijd te besteden aan een fantastische site voor onszelf. Liever zijn we voor onze klanten aan de slag.
Gelukkig is het zeer goed mogelijk om met een bescheiden investering een moderne site te bouwen. Dat vergt wat slimme keuzes om bestaande - en meestal gratis beschikbare - software te gebruiken. Niet verwonderlijk dat web development zo'n vlucht heeft genomen; een moderne site bestaat misschien voor 1% uit nieuwbouw, en voor 99% uit aan elkaar geknoopte bestaande software. Maar dat betekent niet dat er geen uitdaging te vinden is. Daarom voor de geïnteresseerde lezer een korte kennismaking: wat komt er kijken bij een moderne website? Of anders gezegd: een kijkje achter de schermen van embraceit.nl.
Gelukkig is het zeer goed mogelijk om met een bescheiden investering een moderne site te bouwen
De eerste keuze is de technologie. Eén mogelijke route is werken met low-code website builders zoals bijv. Squarespace. Dergelijke platforms zijn voor ons doel echter niet flexibel genoeg. Als developers willen we meer controle! Laten we dergelijke platforms buiten beschouwing, dan komen we bij de web frameworks (back-end, front-end, of beide).
Web frameworks maken het ontwikkelen van een webapplicatie eenvoudig, maar voegen allen ook hun eigen smaak en eigenaardigheden toe. En er is een overdaad aan opties! Alleen al de back-ends: Voel je je veilig in de armen van Microsoft met ASP.NET Core / MVC? Vind je het fijn om alles in JavaScript te doen en ga je voor NodeJS? Of ben je liever hip & happening met Clojure of Erlang? Python (Django, Flask), PHP (Zend, Laravel), Ruby (Ruby on Rails)... en zo zijn er nog veel meer.
Voor embraceit.nl was een Python back-end de logische keuze. Kennis van Python is namelijk de grootste gemene deler tussen onze developers. Ook de keuze tussen Flask en Django was niet moeilijk, gezien het feit dat we meer ervaring hebben met de tweede (en de deadlines altijd kort zijn).
Django staat bekend als "batteries-included" web framework; het bevat alles wat je nodig hebt. Zo heeft Django bijvoorbeeld een ORM zodat je geen SQL-queries voor je database hoeft te schrijven, en een eigen templating syntax, waarmee webpagina's kunnen worden gemaakt (een soort verrijkte HTML). Dat maakt een front-end framework zoals Angular of React overbodig, al raden we voor complexere webapps het gebruik daarvan altijd aan. Voor embraceit.nl was Django echter meer dan genoeg.
Mijn collega gebruikte in een eerste aanzet voor het project het toepasselijk genaamde Django CMS. Django CMS bevat echter geen functionaliteit voor blogs. En hoewel er een open source project is die de functionaliteit toevoegt, was ondersteuning voor Django 2.x een paar maanden terug nog niet voorhanden. Daarnaast achtten we de betrouwbaarheid van dat project (weinig betrokken developers, langzame ontwikkeling) niet voldoende. We zijn daarom overgestapt op Wagtail CMS. Ook deze keuze was niet geheel willekeurig; recent heb ik voor een opdrachtgever Wagtail als headless CMS gebruikt in een Django/Angular app.
Hoewel we met Django en Wagtail een goede basis leggen hebben we nog een aantal aanvullingen nodig voor de front-end. Ten eerste: responsiveness. Websites worden vaker op een telefoon getoond dan op het 27'' scherm waar de developer zich graag achter verschuilt. We gebruiken daarvoor de breed geaccepteerde standaard; Bootstrap 4.
De standaard layout van Bootstrap 4 is echter niet, zeg maar, sexy. Daarom gebruiken we ook een bootstrap 4 thema, Spacial. Het enige pakket dat we voor de site hebben aangeschaft, overigens. Nu leveren thema's als Spacial een goede service; de webapp ziet er aardig uit zonder dat er een designer aan te pas hoeft te komen. Voor developers zijn dergelijke pakketten vaak echter een nachtmerrie. Het thema komt binnen in één theme.min.css bestand, inclusief pagina-voorbeelden, verwijzingen naar afbeeldingen, iconsets en fonts, bootstrap, bootstrap overrides (argh!). En dan mag je daar nog je eigen smaak en stijl aan toe proberen te voegen; een recept voor frustratie. Gelukkig hebben goede thema's altijd met de optie om de assets van de grond af opnieuw op te bouwen, zo ook Spacial. Het kost alleen wat meer tijd en moeite.
Voor het embrace thema hebben we een gulp task runner (NodeJS) geschreven om het thema opnieuw op te kunnen bouwen, en tijdens development bij iedere wijziging live te kunnen hercompileren vanuit SASS. Daarmee brengen we de grootte van het bestand terug tot onder de 300kb, inclusief Bootstrap zelf. Een kleine optimalisatie zou nog zijn om de Bootstrap CSS vanaf een CDN te laden (de verbinding met de CDN is mogelijk sneller dan die met onze server), maar voor nu is dat niet nodig. Voor wie dat leuk vindt hieronder een deel van de task runner.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | /** * transpiles sass to css */ function styles(process = false) { log(`--postcss=${process}`) return function parseSass() { return gulp.src(PATHS.scss.theme) .pipe(sass().on('error', sass.logError)) .pipe(sourcemaps.init()) .pipe(rename({suffix: '.min'})) .pipe(gulpif(process, postcss([prefix(), minify()]))) .pipe(header(BANNER)) .pipe(sourcemaps.write('./')) .pipe(gulp.dest(PATHS.scss.dest)) } } function watchSass() { const sw = gulp.watch(PATHS.scss.src, styles(false)) sw.on('change', path => log(`File ${path} changed`)) sw.on('add', path => log(`File ${path} was added`)) sw.on('unlink', path => log(`File ${path} was removed`)) } |
Als CMS neemt Wagtail het grootste deel van de benodigde functionaliteit voor rekening. Eenvoudig gezegd definiëren we in Django een aantal page models, en koppelen we daaraan een aantal in Wagtail ingebouwde edit handlers. De schrijver van een blog (of andere content op de site) logt in op de site in het admin panel en kan via een redelijk intuïtieve interface alle gewenste content invoeren. Hoewel het het nodige werk is om de page models en edit handlers van iedere pagina te definiëren, daar vervolgens een Django template aan te koppelen en de opmaak in SASS/CSS te schrijven, is dat vanuit een architectuur-perspectief niet zo spannend. Als site voor een technisch georiënteerde blog hebben we echter nog wat functionaliteit nodig die niet out of the box beschikbaar is.
Een voorbeeld daarvan staat hierboven: we willen code snippets kunnen delen. Liefst in verschillende talen. En dat dat er dan een beetje mooi uitziet.
Voor het automatisch stylen van blokken code bestaat gelukkig ook open source software. Specifiek voor Python is er Pygments, een tool die code leest, een gok doet welke taal het betreft, en HTML gestylede output genereert. Om Pygments te kunnen gebruiken hebben we in Django een filter geschreven, waarmee we de tekst die we via Wagtail invoeren (zie afbeelding) achter de schermen door Pygments laten omtoveren tot het resultaat op de pagina ziet. Wat een beetje uitzoekwerk en 20 regels code al niet kan doen!
Een tweede voorbeeld heeft ook te maken met het weergeven van code; het runnen van code vanaf de blog. Specifiek wilden we graag Codepen ondersteunen. Een fantastische tool waarmee je een HTML/CSS/JavaScript niet alleen kunt tonen, maar code en resultaat naast elkaar kunt zien, en ermee kunt experimenteren. Maar dan moeten we dat wel via Wagtail kunnen embedden. Gelukkig is er het oEmbed protocol, waarmee services als Youtube, Twitter, etc. kunnen worden opgenomen in sites. Wagtail ondersteunt dat protocol. Codepen ook. Alleen ontbreekt Codepen in de in Wagtail ingebouwde lijst met oEmbed providers. Ook daar dus ruimte om met een kleine ingreep (<50 regels code) mooie functionaliteit toe te voegen: met een custom EmbedFinder vertellen we Wagtail wat het met de codepen link moet doen, en dat leidt dan tot het onderstaande.
Er zijn nog wel een paar zaken van belang, bijvoorbeeld de hosting van de website (doen we zelf via DigitalOcean), analytics (via SimpleAnalytics - privacy-vriendelijk!), search-engine optimisation en het correct instellen van DNS en SSL encryptie.
weten wanneer iets goed genoeg is, met het vertrouwen dat we snel meer functionaliteit toe kunnen voegen als het nodig is
En zo is er ook altijd wel one more thing als het gaat om onze wensen voor de site. Zoek- en filter functionaliteit voor op de bloglijst bijvoorbeeld - toch handig als de lijst met blogs straks langer wordt. En oh, zou het niet beter zijn om het huidige handmatige deployment proces te vervangen met een continuous integration service zoals CircleCI? Absoluut! Maar weten wanneer iets goed genoeg is, met het vertrouwen dat we snel meer functionaliteit toe kunnen voegen als het nodig is - omdat de basis goed is - dat is ook een deel van het vak. De eerste stap is gezet. Hello, World!