Onlangs gingen wij met enkele collega's voor 5 dagen naar de Drupal devdays in Cluj-Napoca, Roemenië.
Drupal heeft vele events over de hele wereld, maar de devdays is dé plek bij uitstek om in de developer community te duiken en hands-on ervaring op te doen.
Voor enkele collega's was het de eerste keer dat ze op de Drupal devdays aanwezig waren en dit zullen we niet snel vergeten! We hebben veel bijgeleerd en hetgeen ons het meest is bijgebleven, lees je hier.
Op de devdays zijn er vele sessies door al dan niet bekende mensen uit de Drupal community. Maar wij hebben ons vooral toegespitst op het contributen aan Drupal.
Contributen aan een open source code wil zeggen dat je in je vrije tijd, of zoals wij tijdens onze werkuren, meehelpt aan issues uit de Drupal issue queues.
Elk steentje dat we bijdragen helpt Drupal en zijn ecosysteem om weer wat te groeien. Zelfs al is het maar een typo uit de documentatie halen. Het belangrijkste is dat je gewoon durft doen! Durf patches uploaden, vertel wat je denkt, wat je proces is en waar je eventueel naartoe wil.
Keep it simple. Soms is de oplossing voor een issue zo groots dat je in plaats van 1 monumentale patch alles onderverdeeld in tussenstappen. Elke tussenstap is een nieuwe comment met patch. Zo kan iedereen die aan het issue mee werkt je stappen volgen en is het eens zo duidelijk.
Doorheen de 4 dagen dat wij in de sprint-room doorbracht hebben, was er iets dat er met kop en schouder bovenuit stak, nl. testing. Elk issue, elke patch die iets van impact heeft op zowel contrib als core Drupal moet ondersteund worden door automatische tests. Soms zijn de tests in een patch vele malen groter dan de eigenlijke aanpassing. Die tests geven echter een bepaalde zekerheid en garantie dat andere mechanismen niet ineens kapot zijn en dat alles dus lekker blijft bollen.
De test infrastructuur van Drupal.org is dan ook best wel indrukwekkend. Elke patch die je ergens toevoegt, wordt automatisch opgepikt en tests tegen gelopen. Je krijgt (relatief) snel feedback over je patch, test resultaten, coding standard conflicten etc. Relatief snel wil zeggen dat je uiteraard even moet wachten op je resultaten. In het geval van een patch tegen Drupal Core wil dat zeggen dat er ongeveer 26.500(!) tests worden gerund. Als de test bot meezit, klokt dat af op een uur voor alle tests. Een patch tegen een contrib module is uiteraard een pak sneller omdat er minder tests gelopen moeten worden. Maar de hoeveelheid en doorlooptijd hangt natuurlijk volledig af van de tests voor die module.
Belangrijk om in het achterhoofd te houden bij het schrijven van tests is dat je geen tests schrijft die slagen, maar net op zoek gaat naar dingen die kunnen falen. Tijdens het schrijven van tests kan het bv. zijn dat je nog bepaalde inconsistenties tegenkomt. Of je kan zelfs een stap verder gaan en een test schrijven die faalt omdat er een andere bekende bug nog opgelost moet worden. Zolang die test faalt weet je dat die andere bug er nog in zit. Hier is er een voorbeeld. Wim Leers (Drupal Core Comitter) bevestigd dat een test faalt door een bug uit een ander ticketje. En dit wordt er opzettelijk ingelaten. Zodra de test slaagt weten we dat het ander issue gefixed is.
Op het einde van de rit is de belangrijkste les die we geleerd hebben: Als je wil contributen, doe het gewoon! Hoe klein je bijdrage ook is. Het maakt echt wel een verschil, zeker tegenover niets doen.
Op de 5 dagen dat ik in de sprint-room doorbracht hebben wij, in verhouding, met kleine contributies toch een verschil gemaakt. De Entity Embed module heeft een Release Candidate 2 gekregen!
