Frank.be

Ik moet dringend mijn verlsagje over RailsConfEurope afwerken. Een van de Coole mensen die ik de tweede dag sprak, was Charles Nutter, één van de twee ontwikkelaars van JRuby die door Sun aangenomen werden om JRuby verder uit te werken. Dat je met JRuby coole dingen kon doen, was toen al duidelijk, maar ik zag dat er meer mogelijk was, en informeerde bij hen naar hun plannen voor een Ruby “compiler”. Ik was blij verrast te horen dat ze dachten die binnen een maand af te hebben.

Groot was dan ook mijn vreugde toen ik deze morgen las dat ze ermee klaar waren. Hun JRuby compiler is af! Waarom is dat nu zo stoer? Wel, Ruby is een interpreted taal. Dat wil zeggen dat elk lijntje source code elke keer dat het geladen wordt, geanalyseerd en uitgevoerd wordt, net zoals bij bv. PHP of Perl. Dat geeft veel vrijheden, maar vertraagt ook de uitvoering van de code. De JRuby compiler vertaalt Ruby code naar “Java Bytecode”, die veel sneller uitgevoerd kan worden. Gevolg: je programma zal waarschijnlijk een stuk sneller werken! Het mooie aan de oplossing van Charles en co, is dat JRuby nog altijd een Ruby interpreter aan boord blijft hebben. Sommige stukken code kan je immers onmogelijk compileren (bv eval stukken). Ook deze constructies blijven dus mogelijk in JRuby.

We gaan de eerstvolgende dagen wat Benchmarks draaien, en zullen de resultaten zeker publiceren!

Sinds een aantal weken is Openminds “Zimbra partner”. Je hebt waarschijnlijk al van Zimbra gehoord: het is dat bedrijf waar Yahoo! onlangs 350 miljoen dollar cash voor betaalde. Zimbra maakt een mooi product: een (semi-)Open Source Exchange killer, met een web2.0 sausje over. Het kan onder meer volgende dingen:

• IMAP/POP3 compatibel (in tegenstelling tot Gmail!)
• Outlook en Apple AddressBook en iCal compatibel
• Web2.0 style webmail (met tagging, drag en drop, kortom, ajax-sausje, …)
• Gedeelde adresboeken en kalenders
• Raadpleegbaar op je Smartphone, PDA, Palm of iPhone
• Blackberry gaat, maar is nog even lastig momenteel

We gaan dit aanbieden als alternatief voor Hosted Exchange. De prijzen liggen nog niet helemaal vast, maar zouden tussen de 4 en de 15 eur per maand liggen, afhankelijk van welke features je precies nodig hebt, de grootte van je mailbox en hoeveel mailboxen je in totaal hebt.

Op dit moment zoek ik nog testers. Je kan een maand gratis genieten van het volledige pakket, inclusief PDA en smartphone synchronisatie. Interesse? Mail me!

Eén van de manieren om je webapplicatie te beveiligen tegen SQL-injectie, is gebruik te maken van Prepared Statements. Een voorbeeldje van zo’n prepared statement is:

$types = array("text");
$statement = $con->prepare("SELECT * FROM countries 
    WHERE tld = ?", $types, MDB2_PREPARE_RESULT);
$resultset = $statement->execute(array($landcode));
if(PEAR::isError($resultset)) {
    die('failed... ' . $resultset->getMessage());
}

Op deze manier ben je immers zeker dat de SQL query correct zal doorgegeven worden en dat er geen onverwachte dingen kunnen gebeuren. Als je niet via prepared statements werkt, kan het zijn dat iemand via de variabele $landcode foute data doorgeeft.

Lang leve prepared statements dus! Helaas hebben ze ook een groot nadeel als je MySQL gebruikt als database engine. MySQL kan immers geen resultaten van prepared statements cachen! Waarvoor dient die Query Cache en waarom is die zo belangrijk?

Stel dat je homepage bijvoorbeeld je 5 laatste artikels bevat. Telkens iemand je homepage opvraagt, vraagt je CMS/blog-platform/… de 5 laatste artikels aan de database. Je database slaat de resultaten van die zoekopdracht op in de “Query Cache”, zodat de volgende bezoeker de resultaten sneller te zien krijgt. De database moet de zoekopdracht niet meer gaan uitvoeren, hij weet het resultaat immers al.

Op het eerste zicht moet je dus kiezen tussen veiligheid (via prepared statement) en snelheid (gebruik maken van de query cache). Een hartverscheurende keuze dus! Omdat MySQL niet de enige database engine is die de on-efficiënt omspringt met prepared statements, implementeren verschillende frameworks de prepared statements “client side”. Dit wil zeggen dat ze de prepared statements zelf afhandelen en ze als “normale” queries doorstuurt naar de database. MySQL ziet met andere woorden enkel de normale queries, niet de prepared statements, en kan deze requests dus gewoon cachen. Best of both worlds dus, als je framework in staat is die afhandeling van de prepared statements zelf te maken.

MDB2 kan dit in recente versies ook! Gebruik je dus MDB2, pas dan je connect strings op volgende manier aan. Vervang

$this->handler =& MDB2::connect($dsn);

door

$options = array('emulate_prepared' => true);
$this->handler =& MDB2::connect($dsn,$options);

Ik heb dit recent getest op een applicatie van een klant, en de performantie-winst bedroeg meer dan 30%.

Vandaag (eigenlijk gisteren al) was het Blog Action Day. Door omstandigheden ben ik wat laat met mijn artikeltje, maar dat heeft me ook tijd gegeven om na te denken. Ik zou het bijvoorbeeld eenvoudig kunnen houden en bloggen over het feit dat Al Gore de nobelprijs voor de Vrede gewonnen heeft. Ik vraag me al heel het weekend of of dat een positieve of een negatieve zaak is. Langs de ene kant heeft hij veel gedaan. Hij was het ook die mij nog meer dan ervoor deed nadenken over het stroomverbruik van servers. De uitbater van het Datacenter waar wij een “suite” hebben had ons al doen nadenken over het stroomverbruik door pricing mechanismen voor te stellen waarbij zuinigheid beloond werd. Maar het was Gore’s film die me verder deed stilstaan bij de ecologische impact van onze sector.

Langs de andere kant moet je je afvragen wat hij gedaan heeft voor de Vrede. Het Rode Kruis, Amnesty, Lech Walesa, desmond Tutu, Moeder Theresa. Dat zijn mensen die iets gedaan hebben voor de Wereldvrede. Gore heeft voor de Vrede tot nu toe evenveel gedaan als El Baradei of Rabin, en verdient die prijs dus even zeer of even min als hen. “Misschien ga je nog eens aan hem denken als ze de eerste oorlog over drinkwater voeren”, zei Sofie me dit weekend. Ik weet het niet, ik heb er een dubbel gevoel bij…

Nu, Blog Action Day was in eerste instantie bedoeld om bloggers aan te zetten te praten over ecologie en milieu in hun direct leefwereld. Reden te meer om nog eens ons persbericht van enkele weken terug boven te halen. We pakten toen heel uit met cijfers over ons Groene Hosting project.

Dat project laat onze klanten toe om vrijwillig de CO2 uitstoot veroorzaakt door hun site, te compenseren. Uiteraard hanteren we voor die off-set projecten dezelfde hoge standaarden als voor onze andere dienste zodat onze klanten erop aan kunnen dat hun bijdrages besteed worden aan projecten die er echt toe doen. We hebben die dienst nu een maand of zes geleden gelanceerd, en zijn bijzonder trots te kunnen aankondigen dat meer dan 3 op 4 klanten compleet vrijwillig voor dat project kiest! Misschien staan onze klanten verder dan de gemiddelde KMO als het aankomt op “maatschappelijk verantwoord ondernemen”, maar zo zie je maar: klanten zijn wel degelijk bereid te betalen om te proberen iets te doen aan de opwarming van de aarde!