MiRa — het systeem vervangen dat ik twintig jaar eerder schreef

Situatie

MiRa is het ledensysteem van een Vlaamse organisatie die actieve gepensioneerden samenbrengt — opgebouwd in drie niveaus: provincies, dan federaties, dan lokale afdelingen. Vrijwilligers houden er de ledengegevens mee bij naarmate mensen aansluiten, van afdeling veranderen of afhaken; ze registreren wie in welk bestuur zit, op welk niveau en voor hoelang; ze beheren groepen die dwars door de hiërarchie lopen; en ze houden een gedeelde kalender bij van terugkerende activiteiten, gecategoriseerd en in handen van de afdeling die ze organiseert. Elk niveau ziet enkel waar het recht op heeft, en elke wijziging wordt bijgehouden.

De naam was een bewuste keuze en die heeft echt werk verzet. Mira is een oude Vlaamse voornaam — geen afkorting, geen productwoord. De mensen die hiermee werken zijn gepensioneerde vrijwilligers, geen IT'ers, en ze kregen een computersysteem in handen om de gegevens van hun organisatie te beheren. Een menselijke naam in hun eigen taal is toegankelijker dan een reeks beginletters, en twintig jaar later praten mensen over Mira zoals ze over een collega praten: wat Mira zegt, of Mira het nieuwe adres al heeft. Dat was net de bedoeling.

Ik ken de beperkingen ervan ongewoon goed, want ik heb het origineel zelf geschreven. Twintig jaar geleden was het een Perl-toepassing onder Apache mod_perl met HTML::Mason-templates, en ze heeft twee decennia lang onafgebroken haar werk gedaan.

Dat is meteen het goede nieuws en het probleem in één zin. Software die twintig jaar meegaat, verdient echt vertrouwen — en bouwt intussen stilletjes een afhankelijkheid op van een stack waar steeds minder mensen veilig aan durven komen. Er was geen crisis die stilstand rechtvaardigde, geen ruimte om iets te verliezen, en twintig jaar aan vrijwilligersgewoontes om te respecteren.

Wat ik gebouwd heb

Hetzelfde systeem, herbouwd op Rails 8.1, met de hiërarchie expliciet gemodelleerd in plaats van impliciet in queries — provincies met federaties met afdelingen, en daaraan opgehangen: lidmaatschappen, groepen die door de structuur heen lopen, bestuursmandaten, en een kalender met activiteiten en hun herhalingen, alles onder rechten per niveau en met een onwijzigbaar auditspoor.

De migratie woog zwaarder door dan de herbouw. In plaats van een eenmalige conversie is de import gebouwd als herhaalbare taken: eerst de opzoektabellen, daarna de kerngegevens, rechtstreeks uit de bestaande databank wanneer je maar wil. Net omdat hij zo vaak kon draaien als nodig, is het nieuwe systeem keer op keer tegen echte productiegegevens getoetst, en werd de overschakeling een ingestudeerde operatie in plaats van een gebeurtenis.

Het detail waar ik naar zou wijzen, zijn de wachtwoorden. Het oude systeem bewaarde Unix-crypt()-hashes, en die vallen niet terug te rekenen. De gebruikelijke opties zijn ofwel elk lid dwingen tot een reset — veel ondersteuningswerk, en een slechte eerste indruk van het nieuwe systeem — ofwel de zwakke hashes meenemen. In plaats daarvan controleert een eigen authenticatiestrategie de oude hash bij het aanmelden en herberekent ze het wachtwoord meteen met bcrypt, waarna de oude waarde verdwijnt. Aan geen enkel lid is een reset gevraagd, en de zwakke hashes zijn weggeëbd naarmate mensen zich aanmeldden.

De oorspronkelijke Nederlandstalige URL's zijn behouden, zodat favorieten en gewoontes de verhuis overleefd hebben.

Resultaat

De federatie draait op een stack die haar volgende ontwikkelaar zal herkennen, en de vrijwilligers kregen een snellere interface die ook op een gsm werkt — zonder dat iemand hun job opnieuw moest leren of moest bewijzen wie hij was.

Mijn eigen twintig jaar oude code vervangen was een nuttige les in eerlijkheid. Wat het slechtst verouderd was, waren net de slimme beslissingen; wat overeind bleef, was het saaie, expliciete modelleren van het domein — en, zo blijkt, de naam. Ik heb de vervanging in dat besef gebouwd, vanuit de veronderstelling dat iemand anders ze in 2045 zal onderhouden.