I'm nitpicking a bit on code naming...

In a code review that I did today, I left a final note to the author of some new piece of code:

Sorry for nitpicking on code naming. The approaches you take are good, but naming is hard (but important!):

> There are only two hard things in Computer Science: cache invalidation and naming things.

(see here a list of variations on these two hard problem 'jokes' in Computer Science)

I enjoy the ruby programming language because you can get a long way by just assuming things. A collection implements each, every object has nil?, in rails, I can get the relationship of a record and use scopes to filter the relationships as defined in the class of that related record. If it ands with a questionmark, it returns a boolean(y). Anyway.

So while they might say: "never assume things", and sure, a lot of things are chaos, but ideally not our code base :) I prefer to work from assuming t…

Should I be upgrading all my dependencies on a regular basis?

For projects I maintain, I try to keep dependencies up to date on a regular basis. But not all people work like that, some live by the adage of "if it ain't broken don't fix it", but that is not an approach I subscribe to in software development.

A common reason to update software dependencies is to fix security issues or bug fixes that plague the project at hand. My main argument in favour of making more frequent updates is that when you suddenly need to make an update (because of an imminent security threat) it won't be hard; when dependencies haven't been updated in a long time it can be hard to to make the update.

There are risks involved in updating dependencies: A new version might introduce breaking changes, things that you rely on suddenly don't work or exist anymore. It might even introduce new bugs that may not be apparent on the first run. And when your test suite is not on par, verifying if everything works as expected is time consuming. But that can all be address…

Blog concept: Sketchy optimisations

Recently a colleague was showing me a concept he was working on. He drafted a change in a fight against so-called 1+n-queries (actually for some reason unknown to me they're called n+1 queries, but my head isn't able to process the problem with just one more query after n queries…); in software development using ORMs like active record it is quite easy to make a single database request objects that when a presented within a view trigger other queries for every object because it has a relationship. Round trips to databases are generally bad as they take time.

For his change, he introduced a new class that we could seemingly reuse, with a just another (a bad code-smell) declaration of relations between objects and whether these should be preloaded when retrieving the primary object. This was in response to indeed a quite bad part of our code that entailed returning objects with counts of selected associations, but instead of counting these in the database, the current code was a…

Total cost of ownership valt niet te generaliseren

Om de zoveel tijd komt de term weer terug: 'TCO'. Total Cost of Ownership. Hoeveel het allemaal bij elkaar kost. Het werd in het verleden ondermeer uit de kast gehaald door Microsoft om te waarschuwen voor de kosten die de conversie van naar opensource software met zich mee zouden brengen. Onder TCO wordt dan ook gekeken naar o.a. opleiding, de kosten van licenties, wat de onderhoudsmedewerkers kosten (linux beheerders zouden duurder zijn dan mensen met een microsoft diploma). Wat willekeurige observaties.

Jaren terug genoteerd:

> Grappig om te zien hoe hij met het bijna niets kostende stukje software (van een grote speler) vele uren bezig is om via de complexe interface iets relatiefs simpels voor elkaar te krijgen: een factuur te printen. Straks gaat het zich terugbetalen, zo gaat het argument… maar ik heb er weinig vertrouwen in. Niet in dit geval. Wanneer je werkt met relatief grote bedragen worden er niet zoveel facturen verstuurd. Automatische koppelingen met de bank is …

Meerdere wegen naar Rome

Niet alle offerteaanvragen waarop ik reageer gaan goed. Onlangs kreeg ik een reactie terug dat ik iets niet geoffreerd had. En dat klopte, ik had een alternatief geoffreerd. Toegeven, ik was eigenwijs. Ik had het naar mijn idee redelijk beargumenteerd, en wat mensen die ik had laten meelezen waren erg enthousiast: een boekhoudsysteem ga je niet opnieuw bouwen.

Het was naar mijn mening niet slim om wijdverspreide functionaliteit vanuit het niets opnieuw te bouwen (je bouwt immers ook geen mailinglijst software vanuit het niets, niet? 🤦‍♂️).

Er zijn meerdere wegen naar Rome. En als de klant een route heeft gevonden, wie ben jij dan om daar als leverancier ineens vanaf te wijken? Probleem was immers ook dat klanten van die klant al eigen keuzes hadden gemaakt voor verschillende boekhoudpakketten, die er toch al naast gebruikt werden. En om met al die pakketten diep te integreren zou toch wel eens lastig kunnen worden. Ik dach…

Is maatwerk te duur?

Definieer maatwerk: Iets op maat gemaakt, of met de hand gemaakt speciaal voor jou? Of is het iets dat precies past, ongeacht hoe het gemaakt is?

De massa wil geen maatwerk om het maatwerk, de meeste mensen zullen blij zijn met iets dat (heel) goed past. Confectie van een goed merk kan heel goed passen, en wellicht nagenoeg perfect na wat kleine aanpassingen. Écht onderscheidend kan confectie als serieproduct moeilijk zijn, maar het is daarentegen niet alléén het pak dat de man of vrouw maakt. Er zijn nog schoenen, een blouse, de wijze waarop hij of zij het haar draagt. Het is het samenspel.

De samenhang van verschillende onderdelen maakt ook het bedrijf. Maatwerk om het maatwerk is bijna altijd te duur wanneer het helemaal speciaal met de hand gemaakt voor jou. Maar wat verkocht wordt als maatwerk-software in de IT wereld is eigenlijk nooit volledig met de hand gemaakt.

Maar besef ook dat zelfs dat dure atelier niet de stof zelf weeft. Om de lagere budgetten te bedienen h…

Niet hier uitgevonden

Op m’n verzoek om vooral met vragen te komen in mijn kortgeleden begonnen mailinglijst hierbij een antwoord op een lezersvraag:

> “Ben ook wel benieuwd waarom je gekozen hebt voor het hosten van een eigen mailinglist vs de beschikbare saas oplossingen als mailchimp e.d.”

Het bouwen van je eigen mailing-systeem heeft trekken van het “Not invented here”-syndroom. En ja: ik had deze mailing heel erg gemakkelijk met iets als MailChimp kunnen sturen. MailChimp zou bij de omvang van deze mailinglist gratis zijn, leuke statistieken geven, een grafische editor geven en waarschijnlijk was m'n fout waarin iedereen bij de eerste verzending ‘Rick’ werd genoemd niet voorgekomen. "Niet hier uitgevonden" is dus een hele domme reden om iets niet te gebruiken, maar waarom dan toch eigen mailinglist-tool maken?

Foto door [Kelly Sikkema](https://unsplash.com/photos/r077pfFsdaU?utm_source=unsplash&utm_medium=referral&utm_content=creditC…

Technische schuld

De software wereld zit vol met Engelse begrippen. “Technical Debt” is ook zo’n begrip. Maar wat is het?

Een dag geleden zag ik dit bericht waarin Technical Debt werd vergeleken met een continue slecht gestapeld Tetris spel. Een rake vergelijking: als je niet oppast wordt de technische structuur van een applicatie een stapeling op zichzelf oplosbare problemen, maar vormt het in z’n geheel een nagenoeg niet te redden constructie.

Maar waar hebben we het dan over?

Technische schuld wijkt af van financiële schuld. Om financiële schuld te maken moet je geld lenen van een ander. Technische schuld ontstaat doordat er geen tijd wordt gestoken in het goed op orde maken van de techniek. Zo is het een goede gewoonte om kritische zaken en/of zaken die erg foutgevoelig zijn in de applicatie te voorzien van automatische tests (“kan die rol wel/niet bij die gegevens?”, “gaat het ook goed als hier een negatief getal …

“If something is too complex to understand, it must be wrong”

While looking for the source of another quote (something along the lines of “If it takes you too long, you're probably doing it wrong”, which I recall having picked up in the Rails community (if you recognize it, please let me know)) I found the following bold statement. We're not talking science here, we're talking software development (actually this guy is talking Java Spring development):

> “If something is too complex to understand, it must be wrong”

from Arjen Poutsma

Some background on this quote can be found on this Xebia website.

Yep, I'm working on a project that seems to have grown way too complex for what it actually should have been.

Happy coding ;)

Digital rot

A few years ago I created, together with some other green-party members, a website: bodemlozeputten.nl. It was a small local website aimed to make voters aware of all the money that was thrown after bad in that region. Like reopening an airport that has never been able to run profitably even in times when the state was still subsidising it with its military presence. Or the amount of money spent by the local municipalities on land, which had by then already created huge debts for several municipalities and still hasn't turned out to be a profitable for neither the citizens, the local economy, nor the municipalities themselves. It was a small website, hosted at the free hosting option that Heroku offered. And a few days ago I received an email that I should've spent more attention to an issue with this website that I kind of neglected. And now the website is showing an error message: "Application error". And while [it is not rea…

Dan had je maar niet...

Veel programmeurs zijn naast lichtelijk autistisch ook lichtelijk anarchistisch. Informatie moet vrij zijn, code het liefst openbaar, er moet gehackt kunnen worden en alsjeblieft geen centrale autoriteit. Maar hoe om te gaan met dat anarchistische resultaat, het internet?

Deels komt de anarchistische grondhouding van programmeurs voort uit de academische wereld waaruit de IT voortkomt en waarin beeldbepalende technologieën als het internet groot zijn geworden (nadat het door de Amerikaanse defensie was opgezet). Voor de vooruitgang is dit zeer goed geweest, juist dankzij het nagenoeg niet aanwezig zijn van belemmeringen en de continue uitwisseling van ideeën kon het internet onbegrensd groeien tot wat het nu is.

Wat gecreëerd is in een anarchistisch milieu gedraagt zich echter ook anarchistisch en zo zitten we nu met een internet dat op zich wel redelijk veilig kán zijn, maar wel alleen wanneer je om kunt gaan …

Computer says yes

Al weer 7 jaar geleden liet Robert Dijkgraaf in Zomergasten zien hoe alles weer uit van alles bestaat. Kleine onderdelen die samen weer grotere gehelen vormen die samen weer nog grotere gehelen vormen en zo verder, en terug. Hij illustreerde dit aan de hand van een alweer 30 jaar oud filmpje: powers of 10.

Powers of 10: Van 100 tot 1024 naar 10-14

Op hun eigen schaal lijken alle onderdelen waaruit iets bestaat weer mooie afgeronde dingen. En op een afstand lijken al deze onderdelen ook nog eens perfect samen te hangen.

Ook in ontworpen zaken zie je dergelijke herhaling en samenhang. Een chip lijkt in detail wel een metropool. En de printplaat waarop deze bevestigd zit eveneens. En in een echte metropool bevinden zi…

Een beter e-mailprogramma voor Mac OS-X

De afgelopen tijd heb ik geëxperimenteerd met alternatieve e-mailprogramma's voor mijn Mac. Een alternatief dus voor Apple's eigen Mail.app. Ik stuur zo'n 30-40 mails per dag waarvan een groot deel naar Outlook gebruikers. En hier begon mijn frustratie: zij zien mijn mails niet zoals ze er uit horen te zien, sterker nog: delen vielen soms weg en de gebruikers ontvingen spookbijlagen (meer hierover later). Naast deze, en andere kleine frustraties en gewoon nieuwsgierigheid leidde er toe dat ik actief op zoek ging naar het beste e-mailprogramma.

Tijdens deze zoektocht heb ik mijzelf verplicht tot het daadwerkelijk gebruiken van de e-mailprogramma's in 'productie'. Dat was gelukkig niet zo lastig meer zoals het vroeger ooit was. Alle mail staat immers tegenwoordig op IMAP servers, en wordt niet langer 'definitief' gedownload vanaf (POP) servers (een Exchange-server forceer ik overigens actief in IMAP door gebruik te maken va…

Geen bug maar een foutje

Deze week probeerde ik een bug (een foutje) uit te leggen aan een van mijn klanten:

> “Het probleem is opgelost. Omdat ik weet dat je het op prijs stelt om te weten hoe het zit zal ik het uitleggen: > Om de gegevensuitvraag te versnellen hebben we 2 verschillende caches, dit zo gegroeid, een tijdelijke en een langdurige. De fout zat ‘m in het feit dat de langdurige cache niet werd bijgewerkt omdat de tijdelijke cache aangaf dat er niets veranderd was, terwijl in het echt wel iets veranderd was. De langdurige cache, waarvan we gebruik maken tijdens het sorteren werd dus niet bijgewerkt. Aangezien de kortdurende cache eigenlijk overbodig is geworden toen we de langdurige hebben gebouwd, heb ik deze er tussenuitgehaald.”

‘Verrassend’ genoeg kwam dat niet over. Toen hetzelfde verhaaltje opnieuw getypt, maar dan met net iets andere acteurs:

> “Het probleem is opgelost. Omdat ik weet dat je het op prijs stelt om te weten hoe het zit zal ik het uitleggen. > Omdat Jan nogal tra…