Een langer artikel over het optimaliseren van queries volgt binnenkort echter het volgende wil ik vast met jullie delen.

Mocht je je afvragen waarom bepaalde queries de eerste keer dat ze worden uitgevoerd zolang duren en vervolgens een stuk korter duren, dat wordt meestal veroorzaakt door de in MySQL ingebakken query cache. Voor een goede meting is het dus nodig deze query cache te herinitialiseren bij elke teste / meting. Dit kan met behulp van het volgende statement:

RESET QUERY CACHE

Op die manier krijg je betrouwbare resultaten uit je metingen. Echter geheel betrouwbaar zijn ze nog niet, de tijd die een query in beslag neemt is bijvoorbeeld ook nog afhankelijk van het feit of MySQL een tabel reeds geopend heeft, en misschien is er (bijvoorbeeld op UNIX systemen) nog wel een tussenlaag in het besturingssysteem die bepaalde gegevens cachet. Hoe dan ook maakt bovenstaand statement de boel een stuk betrouwbaarder!

Een voorbeeld om het bovenstaande te verduidelijken kan geen kwaad, om het makkelijker te maken doen we in het voorbeeld ook nog een JOIN tussen twee tabellen. Deze JOIN is echter niet persé nodig om dit voorbeeld van toepassing te laten zijn.

SELECT COUNT(DISTINCT tabel1.kolom1) AS disKol1, SUM(tabel2.kolom1) sumKol2, disKol1*sumKol2 AS score FROM tabel1, tabel2 WHERE tabel1.id = tabel2.id ORDER BY score DESC

Het resultaat van deze query is niet erg enerverend, namelijk de foutmelding (reference to group function) . Geen success dus. Net voordat ik het op wilde geven kwam ik via google op de meest simpele oplossing waarvan ik tot op heden niet begrijp dat ik hem zelf niet heb verzonnen en dat is natuurlijk niet de aliassen gebruiken. In plaats daarvan gewoon het aggregate statement herhalen zo dus:

SELECT COUNT(DISTINCT tabel1.kolom1) AS disKol1, SUM(tabel2.kolom1) sumKol2, COUNT(DISTINCT tabel1.kolom1)*SUM(tabel2.kolom1) AS score FROM tabel1, tabel2 WHERE tabel1.id = tabel2.id ORDER BY score DESC

Ontzettend simpel en effectief gezien het feit dat MySQL de resultaten van de functies cached en dus niet nogmaals berekend! En je dan voor te stellen dat ik al bijna helemaal opnieuw begonnen was…

Hoe dan ook vandaag kwam ik via LinuxToday op een blog post waarin de release van versie 2.0 van PDT ter sprake kwam. Wat betreft PDT, of eigenlijk Eclipse in het algemeen, of eerlijker nog programma’s geschreven in Java, ik ben er niet kapot van. Waar ik me regelmatig aan stoor tijdens het gebruik van Java software is het onvermogen van Java of misschien Java ontwikkelaars om de gebruikersinterface te integreren met het besturingssysteem. Natuurlijk, Java is bedoeld als platform onafhankelijke programmeertaal / omgeving echter wat mij betreft is dit in de manier waarop het toegepast wordt eerder een tekortkoming dan een plus punt.

Terug naar Eclipse, een afwijkende grafische interface is niet altijd gelijk een slechtere. Vooral voor Windows gebruikers laat de standaard interface meer dan eens te wensen over. Wat dat betreft moet ik eerlijk zeggen dat Eclipse, en specifiek deze nieuwe versie van PDT een aardig indruk maakt. Bepaalde elementen zijn gemakkelijk terug te vinden op plaatsen waar je dat van Eclipse gewent bent. Maar nog steeds vindt ik dat Eclipse als volledige IDE nog steeds erg teleurstelt.

Wat is de meerwaarde van een volledige IDE? Ik denk dat dit voor de meeste ontwikkelaars toch code hinting / completion is en net zoals in de vorige release van PDT vindt ik dat hier de nodige dingen ontbreken. Natuurlijk is er syntax coloring, en met behulp van control + spatie worden functienamen voor je afgemaakt. In de praktijk merk ik alleen dat ik de functienamen zo wel weet, alleen de (volgorde) van argumenten is het geen wat ik altijd vergeet. Jammer genoeg is dat nu net wat Eclipse niet kan vertellen waardoor ik nog regelmatig op PHP.net te vinden ben zoekend naar de juiste argumenten en return types. Wat volwassen IDE’s voor andere programmeertalen ook al jaren hebben is custom code completion, het afmaken / hinten van zelf gedefinieerde functie / methode namen, inclusief de argumenten, ook dit ontbreekt in de nieuwe versie van PDT.

Natuurlijk zijn er ook genoeg redenen om PDT wel te gebruiken, (met een beetje klooien) zijn er uitstekende debug mogelijkheden, perfecte code completion in de vorm van automatische haakjes en accolades. Jammer is alleen dat het bij PHP ontwikkelaars meer routine is om print_r($var); die(); te doen dan gebruik te maken van een debugger. Eclipse PDT is een goede IDE voor webontwikkelaars en in het bijzonder PHP programmeurs.  Echter voor mij voelt persoonlijk voelt het programma te lomp, log en groot voor de functionaliteit die het biedt. Voorlopig biedt Notepad++ mij in ieder geval alle functionaliteit waar ik als webontwikelaar naar opzoek ben en dat op een lichte en soepele manier. Alleen jammer dat het geen opensource software is…

SELECT (kolom1 * kolom2 ) + kolom3 FROM tabel

Echter, wanneer in bovenstaande query kolom 3 gelijk is aan NULL is het resultaat van de berekening ook NULL. Logischerwijs is dit niet gewenst, na flink graven in de MySQL handleiding heb ik op deze pagina de oplossing gevonden. Namelijk de IFNULL functie. Een stukje copy/paste dan maar:

IFNULL(expr1,expr2)
If expr1 is not NULL, IFNULL() returns expr1, else it returns expr2. IFNULL() returns a numeric or string value, depending on the context in which it is used:
mysql> SELECT IFNULL(1,0);
-> 1
mysql> SELECT IFNULL(NULL,10);
-> 10
mysql> SELECT IFNULL(1/0,10);
-> 10
mysql> SELECT IFNULL(1/0,’yes’);
-> ‘yes’

Met deze informatie wordt de bovenstaande query dus als volgt:

SELECT (kolom1 * kolom2 ) + IFNULL(kolom3,0) FROM tabel

Handig toch?

De complexiteit van webapplicaties en beveiliging heeft een aantal oorzaken, ten eerste is er, zoals in elke applicatie het gebruiksgemak. Veel webontwikkelaars zijn bang dat een hoge mate van beveiliging mogelijke klanten, bezoekers en geinteresseerden afschrikt. Immers wie heeft zin om zestien keer in het uur een wachtwoord opnieuw in te geven? Echter de belangrijkste fouten die worden gemaakt tijdens het ontwerp en de bouw van een webapplicatie hebben geen enkele invloed op het gebruiksgemak van het uiteindelijk eindproduct, denk aan buffer overflows door slechte input validatie, of sql injectie door het afraffellen van fatsoenlijke query escaping.

Een ander aspect wat het beveiligen van webapplicaties zo complex maakt is de diversiteit van de productieomgeving. Bij een normale desktopapplicatie zijn er een groot aantal omgevingsfactoren die vooraf duidelijk vast liggen, of af te bakenen zijn. Voorbeelden zijn het besturingssysteem, de beschikbare software de identiteit van de gebruiker etcetera. In tegenstelling tot een desktopapplicatie staat er bij een webapplicatie maar heel weinig vast wat betreft de omgeving. De bezoeker is niet geidentificeerd, het aantal combinaties van webbrowser en besturingssysteem is nagenoeg oneindig en de applicatie is bereikbaar voor iedereen die een internetverbinding tot zijn beschikking heeft. En dat zijn er best veel.

Dan is er nog het grote aantal verschillende ondersteunende softwarepakketten waar een webontwikkelaar mee te maken krijgt, zoals het besturingssysteem van de server, de webserver, de scripttaal, de databaseserver. Al deze onderdelen kunnen leiden tot beveiligingsproblemen die in de ontwikkelomgeving niet waren voorzien bijvoorbeeld als gevolg van versie verschillen, configuratie verschillen etcetera. Soms kunnen een aantal triviale kwetsbaarheden in combinatie zorgen voor een groot probleem in de webapplicatie, en dat terwijl er in eerste instantie helemaal geen beveiligingsprobleem in de webapplicatie bestond.

Een boek waarvan ik van mening ben dat elke softwareontwikkelaar (en dus ook webontwikkelaar, al ontkennen die graag dat ze dat zijn) gelezen moet hebben is “Secure Coding Principles & Practices” door Mark G. Graff & Kenneth R. van Wyk. Het boek bevat een scala aan praktijk voorbeelden, toe te passen principes en richtlijnen die direct relevant zijn tijdens de ontwikkeling van elk soort applicatie.

Waarschijnlijk de beste en makkelijkste manier om duidelijk te maken welk deel van webontwikkeling ik normaal gesproken in aanmerking noem is toch een, onvermijdelijk een opsomming. In willekeurige volgorde dan maar.

• PHP;
• MySQL;
• XHTML;
• CSS;
• Javascript.

Maar goed, omdat een opsomming bijna net zo weinig zegt als helemaal niets is het tijd voor enige toelichting. Ongeveer 6 jaar geleden kwam ik voor het eerste serieus in aanraking met webontwikkeling, tot die tijd was het vooral frames aan elkaar klikken met Dreamweaver. Niet snel daarna kwam onvermijdelijk het scripten, waarom PHP? Dat was vooral de schuld van collega’s uit die periode. Waarom MySQL? Waarom niet! Nog steeds denk ik dat voor de meeste (niet microsoft) webontwikkelaars MySQL de enige serieuze optie is voor een als databaseoplossing.

Hoe dan ook, zes jaar later, 2009, waar werken we tegenwoordig mee? Het makkelijkst samen te vatten is natuurlijk te verwijzen naar de libraries die we bij Funkology _altijd_ gebruik in de eerste plaats Zend Framework , ten tweede de template engine Smarty. Wat betreft Javascript framework is er voor mij persoonlijk maar een optie en dat is jQuery.

Tot zover een hele, hele, hele korte introductie waar het hier (waarschijnlijk ooit) over zal gaan.