Naast de #WeAreDevs ben ik ook nog naar de CodeMotion conferentie geweest, dit samen met 800 mede-developers, Hieronder een kleine samenvatting van de leukste en de meest interessante talks.

How to write maintainable code, Peter Hilton

In deze talk legde Peter Hilton uit wat unmaintainable (slecht te onderhouden) code is, wat daar de consequenties van zijn en hoe je de maintainability kan verbeteren. Hij liet voorbeelden zien van slechte naamgeving in code en hoe je naamgeving kan verbeteren, bijvoorbeeld door geen afkortingen en vage namen te gebruiken. Soms worden er namen gebruikt met meerdere woorden die ingekort kunnen worden zoals "appointment_list" en "company_person", hier bestaan woorden voor "calendar" en "employee". Goed leesbare code heeft minder comments en documentatie nodig. Een paar comments en een readme.md bestand kan voldoende zijn (README-driven development). Hier vindt je de slides

The road to continuous deployment: a case study, Michiel Rook

Michiel Rook deelde zijn ervaring met de strangler pattern en legde uit hoe je het kan gebruiken bij het herschrijven van een grote, oude/legacy code base. Met de strangler pattern wordt de legacy applicatie geleidelijk, pagina voor pagina, vervangen door nieuwe code. Afhankelijk van welke pagina je bezoekt wordt je door een proxy doorgestuurd naar de oude applicatie of nieuwe service. Uiteindelijk wanneer de volledige applicatie herschreven is kunnen de oude applicatie en de proxy uitgeschakeld worden. De strangler pattern heeft als voordeel dat je kleine stappen kunt maken, minder risico hebt en frequenter kan nieuwe features live kan zetten.

In dit project werd gebruikt gemaakt van continuous deployment: code wordt automatisch getest en gereleased. Omdat er in git niet gebruik wordt gemaakt van branches komen alle commits in productie terecht. Dit lost het probleem met code bouncing op. Code bouncing gebeurt wanneer verschillende teams in branches aan nieuwe features werken. Wanneer een team de feature wil mergen met de master ontstaat er een merge conflict. Dit team moet dan met de andere teams zoeken naar een oplossing. Tegen de tijd dat het conflict is opgelost is de master branch alweer verder gegaan en zijn er nieuwe conflicten ontstaan. Zo duurt het heel lang voordat nieuwe features live komen. Als alle commits direct naar de master branch gaan worden conflicten snel opgelost en is het mogelijk om sneller features live te zetten. Door middel van feature toggles kan je voorkomen dat nieuwe features zichtbaar zijn voor gebruikers, bijvoorbeeld als je een nieuwe feature eerst intern wil testen.

Relevant search results (with elasticsearch), Jettro Coenradie

Deze talk werden de concepten precision, recall en relevancy geintroduceerd.

Precision: alleen relevante zoekresultaten laten zien. Recall: geen relevante zoekresultaten verbergen. Relevancy: content krijgt een score op basis van de behoeften van de gebruiker. De meest relevante resultaten worden als eerst getoond.

De relevantie wordt berekend op basis van TF (Term Frequency) en IDF (Inverse Document Frequency). TF: hogere score wanneer de zoekterm meerdere keren in een document voorkomt. IDF: lagere score wanneer de zoekterm in vele documenten voorkomt, de zoekterm zelf wordt minder belangrijk.

Om relevantere resultaten te tonen kan je Signals gebruiken om te markeren welke onderdelen van de content het belangrijkst zijn (bijvoorbeeld als een 'titel' is belangrijker dan een 'categorie'). Zoektermen kunnen gefilterd worden om speciale tekens, stopwoorden en synoniemen eruit te halen en hoofdletters om te zetten naar kleine letters.