Coding in an absurd reality

In EJB3 in Action the authors assert

However, interceptor callbacks are extremely useful when you need them.

Otherwise, it's a fine book .

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.

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.

When you put together an XSD to specify how certain XML documents should look, you are always confronted with the choice to make parts of the information you wish to convey either an element or an attribute. Some people seem to think attributes are pointless and proponents of XML alternatives JSON and YAML sometimes opine as much.

Now I'm not going to make a thorough analysis of when to use elements and when to use attributes, because that has already been done on a great number of occasions. What I wish to do, is to give a simple example of a case in which an attribute makes the information that is to be conveyed easier to understand:

NB. After H!ghGuy's first response I realized I forgot to give an important piece of information: my intention is to store responses to a questionnaire. This is part of a larger piece if XML, storing, for instance, a name, address, etc.

XML:

1 2 3 4 5

<questionnaire>   <answer question="1">D</answer>   <answer question="3b">Cow</answer>   <answer question="last">144</answer> </questionnaire>

If the 'question' reference needs to be an element, you get either

XML:

1 2 3 4 5 6 7

<questionnaire>   <answer>     <question>1</question>     <answer_contents>D</answer_content>   </answer   ... </questionnaire>

in which case the fact that the element requires an awkward name is indication enough that something is wrong, or

XML:

1 2 3 4 5 6

<questionnaire>   <answer>     <question>1</question>     D   </answer   ...

Here D is not actually an 'element' in the way 'element' is used above, but it is an obvious alternatieve.

In the last case, the question seems to be part of the answer element, just like the actual answer is part of the answer element. That just doesn't sit right with me, as they have a decidedly different relationship to the concept of an 'answer'. In JSON and YAML the same solutions appear and I think all are equally unsatisfying.

In short: child elements together constitute the parent element. If you need to provide a piece of meta-information or want to 'annotate' an element, using an attribute is a clear way in which to distinguish this kind of information from the constitutive kind.