J-Spring 2019

Net als de afgelopen 2 jaar is Eleven aanwezig met een aantal ontwikkelaars op J-Spring. J-Spring is een van de conferenties die wordt georganiseerd door de Nederlandse Java gebruikers groep (NLJUG). Het is een relatief kleine conferentie, de keuze in presentaties zijn beperkt, maar ergens ook weer prettig: zo heb je niet dat je de helft van de presentaties mist.

Eerste keynote

Net als voorgaande jaren waren weer interessante sprekers. Na de opening was het tijd voor eerste keynote van Wouter Oet. Een keer een keynote van een developer in plaats van een CTO of Team Lead. Wouter bracht een interessante visie op het delen van kennis. Een aantal punten waar we als Eleven ook nog wat mee kunnen:

• Samen code reviews doen (auteur en reviewer), dit kwam ook terug in een latere presentatie
• Om van elkaar te leren kun je tijdens (bijvoorbeeld) een retrospective ieder teamlid zijn grootste prestatie en grootste fout laten benoemen

Efficiëntie door leesbare code

Na de koffiepauze gaf Peter Hilton een presentatie met de titel: "Why you should care about code style and what you should care about". Hij benadrukte het belang van leesbare code aangezien je als programmeur het grootste deel van je tijd code van anderen (of jezelf) leest. Het schrijven van leesbare code is iets waar we bij Eleven ook actief aan werken met onze gedeelde code formatting settings en actieve controle op leesbaarheid tijdens de reviews. Een interessant onderwerp kwam hier ter sprake: het altijd geautomatiseerd formatteren van je code.

Dit is een item waar vaak de meningen over verdeeld zijn, b.v. op welk moment doe je dit? Voor het committen van je code, tijdens het pushen of zelfs op een ander moment? Wat te doen als het formatteren je code breekt, wanneer merk je dit dan op? Dit is een item dat we intern bij Eleven ook nog nader gaan bekijken. Met het automatisch formatteren van je code hoef je daar niet meer over na te denken en kunnen we nog efficiënter werken.

JAVA dependencies, to inject or not to inject

Later op de dag vertelde Brian Vermeer in een interessante presentatie over de explosieve groei van het gebruik van dependencies. Met het introduceren van dependencies maken we gebruik van reeds bestaande code en beperken we de benodigde ontwikkeltijd voor onze applicaties. De code is daarentegen wel gemaakt door een derde partij en heeft als resultaat dat het grootste deel van onze code die we in productie zetten daardoor niet onze eigen code is.

Voor ons bevestigde dit het belang van constant code blijven controleren op kwetsbaarheden in deze dependencies, ook al is het van een betrouwbare leverancier. Bij Eleven hebben we dit standaard voor alle applicaties van onze klanten geautomatiseerd door middel van Sonar (heet tegenwoordig SonarQube).

Veilige werkwijze voor OAuth2

Emond Papegaaij heeft een sessie gehouden over Oauth2 en de verschillende flows die er beschikbaar zijn binnen de Oauth2 standaard. Hieruit kwam naar voren dat flows waarbij API keys en/ of credentials door de cliënt gemanaged worden zeer af te raden zijn omdat je bijvoorbeeld een javascript cliënt niet kan vertrouwen. De flow genaamd Authorization Code Grant, is de meeste aan te raden variant waarbij je een access token en refresh token ontvangt en hiermee toegang tot de betreffende resources kan krijgen. Deze variant gebruiken we bij Eleven ook voor een aantal applicaties.

Er werd ook aandacht besteed aan hoe mobile clients zonder client secret toch veilig Oauth2 zouden kunnen uitvoeren middels PKCE: Proof Key for Code Exchange. OpenID connect werd ook kort aangehaald, waarbij dit als aanvulling gebruikt wordt boven op de Oauth2 laag. Hiermee kan de cliënt de identiteit van de eindgebruiker verifiëren op basis van de authenticatie die wordt uitgevoerd door een Authorization-server. Tijdens deze presentatie werd het ook wel duidelijk dat het hier om complexe materie gaat en is het erg fijn dat wij als developers kunnen leunen op Spring-security die een hoop lastige zaken al uit handen voor je nemen.

Teamwork: Samen code reviews doen

Naast flink wat technische presentaties werden er ook nog luchtigere presentaties gehouden bijvoorbeeld over samenwerken met je team. Code review wordt vaak gedaan bij bedrijven, maar meestal met een geautomatiseerde tool waarop je feedback op je code geeft (of krijgt). Echter is dit vaak een onpersoonlijk aanpak en kan dit extra wedervragen opleveren.

Een alternatieve werkwijze is om om code reviews samen te doen aan 1 bureau zodat je direct toelichting kan geven waarom je voor een bepaalde oplossing hebt gekozen. Daarnaast ben je beter in staat een nuance mee te geven of kan je samen tot een heel ander inzicht komen. Op deze manier kun je tijdens een reviewsessie veel beter van elkaars werk en inzichten leren.

Naast code review, kan het ook helpen om voor het starten aan een nieuw opdracht deze met je teamleden door te nemen, maar met name door te nemen hoe iemand zo’n opdracht zou benaderen. Waar zou hij of zij mee beginnen, welke uitdagingen zij zien, etc

Verder zijn er natuurlijk weer allerlei nieuwe onderwerpen voorbij gekomen om verschillende Innovation Days mee te vullen.

We kunnen weer even vooruit!