Coding in an absurd reality

Disclaimer: aan de reacties te zien interpreteren mensen dit stukje als het 'afzeiken' van iemand. Dat verbaast me, want zo is het helemaal niet bedoeld. Ik zag gewoon een bepaald fenomeen, waar ik mezelf ook weleens op betrap, en wilde dat beschrijven. Ik verwijt de topicstarter van het topic niets en ik denk dat hij een redelijk topic heeft geopend. Wie dit zuiver ten nadele van de topicstarter interpreteert, maakt een hele andere, ook veelvoorkomende, denkfout: "dit is niet op mij van toepassing".


Als er in een proces dingen mislopen, hebben mensen de neiging de schuld te leggen bij het onderdeel dat ze het minst goed begrijpen. Een voorbeeld hiervan op een heel toegepast niveau is te zien in dit topic.

De topicstarter heeft een PHP script geschreven om een veld in een database uit te lezen en afhankelijk van de waarde een bepaalde actie te laten ondernemen. Om dit op bepaalde tijdstippen, en met bepaalde rechten, te laten gebeuren, wordt het script in de cron table van een bepaalde user gezet, zodat de cron daemon voor die vereisten kan zorgen. Vervolgens werkt het niet. De foutmelding is helder en bekend voor iedereen die weleens programmatisch een MySql database heeft geprobeerd te benaderen: je hebt de hostname verkeerd, de poort verkeerd, de database is gewoon down, etc. Het probleem is je configuratie of de manier waarop je code de configuratie gebruikt.

Hij start vervolgens echter een topic met de titel "Cronjob geeft problemen met MySql". In de topicstart vermeld hij de inhoud van het script niet, waarschijnlijk 'omdat het daar toch niet aan kan liggen'. De oorzaak hiervan is dat hij heeft geconcludeerd dat het probleem bij de cron daemon moet liggen, aangezien het mis ging toen hij het script vanuit de crontab uit liet voeren. De conclusie voor iemand die weet hoe die werkt is: de cron daemon opereert voor hem op magisch, niet goed begrepen, wijze, waardoor dit probleem daar, volkomen ten onrechte, op afgeschoven wordt.

N.B. Het viel me op omdat ik twee dingen in het topic zag gebeuren tengevolge daarvan:

• Een deel van de lezers wordt op het verkeerde been gezet en
• De relevante informatie die de begrijpende lezers nodig hebben ontbreekt.

P.S. Als je in je code geen expliciete configuratie doet en er, doordat het script van de crontab uitgevoerd wordt, impliciete paden en gebruikers gekozen worden, dan is dat nog steeds geen cron probleem. Het probleem is dan dat je niet met de betreffende gebruiker getest hebt. Ook zonder cron zou dat probleem voorkomen. Daarom is het niet zinvol, en afleidend, om de schuld daar te leggen.

P.P.S. In dit geval was een deel van de relevante informatie overigens toevalligerwijs wel in de topicstart aanwezig.

P.P.P.S. Het is ook mogelijk dat de topicstarter het geheel wel begrijpt, maar er gewoon niet in geslaagd is de vraag helder te formuleren.

Today my newspaper headlined with a phrase best translated as "Withdraw cash from ATM machines while you can!". This is bad for three reasons:

1. The phrasing scares people
2. It is bound to deepen the problem, by encouraging people to withdraw money and worsen the liquidity of the banks.
3. It is quite pointless to withdraw (large amounts of) money. If our banks go bankrupt (and if one goes, they'll all go), the value of money becomes questionable. After a few days, it probably will not be worth anything anymore. If you are worried, start hoarding food and water. You can't eat euros.

But then, I wouldn't worry anyway. I'd almost hope everything goes down, just to see how it plays out, in economic as well as in social terms.

I'm amazed at the number of comments to posts of bloggers here in which the commenter wonders about the use of the English language. As far as I'm concerned, English is the lingua franca of the internet. The things I write about are seldomnly limited to the Netherlands and I'd like as many people as possible to be able to use and enjoy my posts. If that means sacrificing quality, because I'm less proficient at English than at Dutch, so be it.

What amazes me even more, is the number of commenters that seem to think it's fair game to criticise the writer's use of the English language. If you'd make the same comments at the forum, you'd be moderated as offtopic and, in many cases, as a nitpicker. If you think this post contains spelling errors, wrong grammar or bad style, feel free to email me about it. Just please don't clutter the comments with it.

Edit:
Come to think of it, actually, feel free to comment on spelling, grammar and style in the comments, but please do it in a seperate comment. I will delete it as soon as I have read it.

At many forums, I see people posting questions that they could easily answer themselves, if they would only read the specification for the relevant technology. Now of course, specifications are generally known to be voluminous and dense and consequently hard to read and sparse on relevant information. You are better of finding a tutorial, reference guide or simply using Google.

However, not so with the w3c specs. If you have a problem in html, xml, xslt, xpath, etc., the relevant w3c spec is really the first place you should look. They are very readable, littered with examples and have two other major advantages above, for instance, w3schools.com:

• They are always complete
• They are always correct

Especially the last one is not to be underestimated, lest you spend a day on a problem that turns out to be an error in a w3schools tutorial.
* Confusion pleads guilty of the last

The Google Web Toolkit was announced as the next silver bullet in building (Java) web applications. After working on a project where it was used to build the front-end, I have to admit that not having to write any ECMAscript definitely has its benefits. Primarly: not having to worry about, or stumbling upon problems with, cross-browser functionality, the ability to use the same code both server-side and client-side and the ability to unit-test the client-side code.

However, this comes at a cost. There are two major disadvantages to using GWT:

1. The time a development cycle (deploy, test, adjust, redeploy) takes.
   When the code has been deployed to Google's 'hosted mode' browser, many code changes can be tested within a matter of seconds, by 'refreshing' the webapp. Think of it as automatic hot redeploy. Deploying the code to that browser currently takes around a minute, which wouldn't be a problem, if it weren't for the fact that not all code changes can be tested without a redeploy. A minute per development cycle is just too long, even if it affects only 10% of the cycles.
2. The learning curve.
   To use GWT properly, you are forced to use decent MVC and client-server design patterns. This doesn't sound bad and for a couple of seasoned programmers it isn't. Unfortunately, for junior programmers the learning curve seems to be rather steep.