Een kijkje in ‘the Life of Brian’

Article JAVA Magazine 04 – 2021

Brian Vermeer is een Java Champion, bestuurslid van de NLJUG en geeft regelmatig presentaties op conferenties, zoals Devoxx en J-Fall. Kortom, hij is erg succesvol. Nadat ik Brians presentatie van ‘10 tips voor Springboot Docker beveiliging’ had gevolgd, viel me op dat Brian al eerder presentaties gaf met het getal 10, namelijk: ‘10 common mistakes in Java functional programming’. Zat hier een trend in? Is dit wellicht Brians manier om zichzelf in onderwerpen te verdiepen? Vandaag mag ik Brian Vermeer interviewen en nemen we een kijkje in zijn manier van werken.

 

Hoi Brian, leuk dat je vandaag hier bent. En gefeliciteerd nog met de titel ‘Java Champion’! Hoe is het met je en wat is er dit jaar allemaal in je leven gebeurd?

Hi Maja, met mij gaat het prima. Ondanks corona erg druk met onderzoek, het schrijven van artikelen, het schrijven van software en uiteraard de vele online presentaties. Bovendien ben ik dus eerder dit jaar Java Champion geworden en heeft Business Insider mij in het lijstje ‘Top 21 Developers Shaping Tech’ opgenomen. Het gaat dus lekker.

 

Wat tof en fijn om te horen! En daarnaast deel je dus ook hier en daar je kennis over Java en Docker. Hoe kwam je op je 10 tips en wat motiveert je om dit nu met de wereld te delen?

Sowieso is het mijn werk als developer advocate om gedegen kennis neer te zetten richting de Java developers en in dit geval kwam Docker aan de beurt. Ik zag dat er veel blogposts en informatie over Docker op internet staan, maar hoe bouw ik nu een Docker container als Java developer op een goede en veilige manier? Deze 10 tips zijn kleine behapbare stappen voor een developer die prima als basis gebruikt kunnen worden. Als developer wil je iets bouwen en heb je vaak niet de tijd om alles in detail uit te zoeken. Mijn doel is om een soort ‘cheat sheet’ of ‘best practice plan’ te maken die actiegericht is, zodat een developer denkt: hier kan ik wat mee.

 

Wel handig dat je deze tips hebt uitgewerkt! Dat scheelt ontwikkelaars zeker tijd en geeft ze een goede start. Maar ja, toen jij ermee aan de slag ging, was er dus geen kant-en-klare presentatie die je even kon bekijken. Hoe pak je zo’n onderwerp aan als je er nog niet bekend mee bent?

Ik begin vooral met waar ik wel bekend mee ben. Van veel dingen weet je al wat. In mijn stukken schrijf ik vanuit een security-oogpunt en kijk ik kritisch naar waar de problemen zitten in deze aanpak. Ik begin met experimenteren. Bij alles wat ik schrijf of presenteer zit er ook een project achter. Ik vraag me eerst af ‘hoe werkt het nou eigenlijk?’ en ‘wat zijn de gevolgen?’. En daarna ‘kan ik het uitleggen?’. Overigens zijn heel veel dingen niet uniek voor de Java taal. En ik ga gewoon onderzoeken en met mensen praten.

 

Zo’n project is een combinatie van onderzoek doen, proberen, eigen spullen lek schieten en verifiëren bij mensen of het waar is wat je hebt uitgevonden. Vooral de verificatie is belangrijk. Je kan wel denken of zeggen dat iets klopt en het kan wel in een specifiek voorbeeld waar zijn, maar iemand anders kan helpen om inzicht te krijgen of het echt wel klopt.

 

Je hebt het over ‘met mensen praten’. Met wie praat je dan?

Weet je, misschien is dit wel de meest belangrijke vraag. Ik ben developer advocate en mijn team is developer relations. Dit betekent dat wij relaties aangaan met andere mensen in het veld. Ik werk bijvoorbeeld veel samen met mensen van andere bedrijven in het Java ecosysteem, maar ik werk ook samen met security engineers binnen ons eigen bedrijf. Ook mail ik een van de meest bekende security Java Champions Jim Manico [1] en stel ik vragen. Daarnaast is het actief zijn op mailing lists en slack groepen ook een prima manier om dingen na te vragen. Door het spreken en schrijven en omgaan met mensen die over dezelfde dingen enthousiast zijn, bereik je communities en die communities helpen elkaar.

 

Mail je ook mensen die je niet kent?

Soms wel. Dat hangt ervan af. Soms gaat het ook via via. Als ik weet dat iemand die persoon kent, vraag ik ‘kan je me introduceren?’. Dat is een soft landing. Maar ook zonder connecties kun je prima contact opnemen. Dat kan ook via Twitter of LinkedIn. Je kunt reageren op iemands artikel. Zolang je dat op een goede manier doet, kan je daar veel uithalen. Als je gaat ranten, ben je niet goed bezig. In heel veel communities ben je welkom als je er maar tijd in steekt. Vervolgens leer je mensen kennen die je weer verder kunnen helpen en vice versa.

 

Heb je een stappenplan of tips die je ons kan aanraden om met een artikel aan de slag te gaan?

Begin met iets waar je interesse in hebt, wat dicht bij je huidige kennis ligt. Ik ga niets uitzoeken wat me niet interesseert. Als ik er al iets van weet, is het makkelijker om door te pakken. Kijk welke problemen je zelf daarin ondervonden hebt. Vaak zijn het problemen en horror stories waar het mee begint. Of in ieder geval potentiële problemen. Dat probleem los je dan op en daarna kun je terugkijken waarom je het zo hebt opgelost. Daar zit een denkwijze achter. Dit verwerk ik in een artikel of ik maak er een presentatie over, zodat het voor een ander ook toepasbaar is.

 

Dan is de stap daarvoor wellicht nog veel belangrijker als ik het zo hoor. Namelijk, hoe ga je met een nieuw onderwerp, dus een nieuw probleem aan de slag?

Eerst zoek ik naar wat er wel is, wat er bekend is, waar de problemen zitten. Daarbij kijk ik wel weer of het dicht bij me ligt. Ik begin klein. Ik google dus eerst wat er bekend is. Ik lees artikelen door en kijk of ik het daarmee eens ben met de kennis die ik al heb. Soms verifieer ik dit weer bij andere mensen. Onder artikelen staat vaak commentaar. Ook hier kijk ik weer of ik het daarmee eens ben. Dan vergelijk ik wat ik lees met mijn achtergrond en kijk naar hoe de theorie die ik geleerd heb toegepast wordt. Ik vraag me dan bijvoorbeeld af: hoe hebben de Java architecten dit bedoeld? En desnoods ga ik het ze vragen. Mensen zoals Brian Goetz [2] en Stuart Marks [3] zijn ook gewoon mensen die je een mailtje of berichtje kan sturen. Misschien krijg je geen reactie, misschien wel. Het betekent in ieder geval wel heel veel lezen. Vaak zijn dingen vastgelegd in specificaties en die moet ik dan dus doorgronden wil ik het fijne ergens van weten.

 

Dit klinkt inderdaad alsof je op deze manier steeds dieper in een onderwerp verzeild raakt, ja. Dankjewel Brian dat je vandaag tijd nam voor het Java Magazine en hopelijk horen we binnenkort weer nuttige tips en tricks over Java en security.

 

Voor Daan: het lijkt mij goed om onderstaande tekst visueel te laten opvallen. Daarom heb ik het in een kader geplaatst.

 

Beste lezer, waar weet jij veel vanaf? Heb je een onderwerp waar je je helemaal in hebt verdiept en waarvan je jouw kennis graag deelt met vakgenoten van de NLJUG? Neem dan contact met ons op en wie weet! Misschien sta jij in het volgende Java magazine met je eigen artikel.

 

Referenties

1 ​​https://twitter.com/manicode

2 https://twitter.com/BrianGoetz

3 https://twitter.com/stuartmarks

 

Bio Brian:

Brian is een Java Champion, Developer Advocate voor Snyk en Software Engineer met meer dan 10 jaar hands-on ervaring in het bouwen van (web)applicaties. Daarnaast is Brian bestuurslid van de NLJUG en de VirtualJUG.

Bio Maya:

Maja Reißner is software developer bij SIDN.