How to compare the speed and code size of programming languages? What language is really slow but also very compact in writing? Are the Ruby religionists right? And is TCL-script really as annoyingly, depressingly bad at performance (and else) as some legacy systems (that we @ISAAC have to integrate with) seem to prove to us every day? I found a nice article with very interesting graphics the other day, via a posting at Slashdot. Note when you scroll directly to the graphs: there are several Java versions in the results.
The rest is shamelessly ripped from "The Square root of X divided by zero" blog, by Guillaume Marceau.
(orginally posted at: http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html )
The speed, size and dependability of programming languages
The Computer Language Benchmarks Game is a collection of 1368 programs, consisting of 19 benchmark reimplemented across 72 programming languages. It is a fantastic resource if you are trying to compare programming languages quantitatively. Which, oddly, very few people seems to be interested in doing.
The Benchmark Game spends a lot of efforts justifying itself against claims that the benchmarks are always flawed and that the whole exercise is pointless. I don't think it is. In fact, I've found that The Game is remarkably effective at predicting which forum hosts programmers annoyed at the slowness of their language, and that's good enough for me.
I was happy to find that in addition to speed The Game also publishes a line-of-code metric for each benchmark programs in each language. Thanks to this The Game let us at explore a fascinating aspect of programming language design: the tension that exist between expressiveness and performance. It is this tension that gives the expression "higher-level programming language" a pejorative connotation. When you are coding this high, you might be writing beautiful code, but you are so far away from the hardware you can't possibly get good performance, right?
If you drew the benchmark results on an XY chart you could name the four corners. The fast but verbose languages would cluster at the top left. Let's call them system languages. The elegantly concise but sluggish languages would cluster at the bottom right. Let's call them script languages. On the top right you would find the obsolete languages. That is, languages which have since been outclassed by newer languages, unless they offer some quirky attraction that is not captured by the data here. And finally, in the bottom left corner you would find probably nothing, since this is the space of the ideal language, the one which is at the same time fast and short and a joy to use.
Each pinkish dot in this chart comes from one language implementing one benchmark solution, so there are 1368 dots, minus a few missing implementations. Both axes show multipliers of worsening from best. That is, if a particular solution is not the best one, the axis show how many times worse it is when compared to the best. The barrier of dots on the left side means that it is common to have many solutions near the best performer (The best performer is usually one of a handful of C compilers.) On the right side and beyond it, there are a number of distant points which are clipped out of view by the edge. As it stands, the right edge represents 8-fold worse performance than the best solution.
The distribution of pink points is more uniform along the Y axis (verbosity) than along the X (slowness), suggesting that the world has not hit a wall in the progression of the expressiveness of programming languages the way it has with performance.
Like many scientific datasets, the data coming from The Computer Language Benchmark Game is rich in shapes, insight and stories. In order to retain as much of the shape as possible, it is critical to avoid calculating averages, as averages tend to smooth over the data and hide interesting sources of variation. The average function does to numbers what Gaussian blur does to pictures. Avoid it if you want to see the edges.
One such source of variation that attracted my curiosity was dependability: how well does the language performs across a variety of tasks, such as those composing the benchmark suite? A language might be concise most of the time, but if once a month a quirk of the language forces the code to be five times as large as what it ought to be, it's a problem.
In order to show dependability, and to avoid relying on averages and standard deviations, I drew star charts in the following manner. Take, for example, the Java benchmarks. Starting with the previous chart and its 1368 dots, I added a gray line from the XY position of each Java benchmark to the position of the overall average of all the Java programs.
The center of the star is Java's average performance, and the branches shoot out to the individual benchmarks. The resulting shape says something about Java. On the X axis (slowness), we see that the performance is impressive, often brushing near the "wall of best performance" of C on the left. But on a few occasions the performance breaks down and the star shoots to the right. On the Y axis (code size), the star spreads across the chart, twice brushing near the top. Also the center of the star is slightly above the centroid of the background cloud. In other words, Java is not a particularly concise language, and in fact it is sometime depressingly convoluted, but its performance is excellent except when it's not.
The next chart arranges the entire collection of the 72 programming languages available at The Computer Language Benchmark Game into a 8x9 grid. The chart is a so-called 'small multiples' design: each swatch in the grid has the same axes in the same scales as each other. It's the same setup as the one for Java that we just saw. The 1368 dots in the background are the same throughout. The intent is to make it easy to compare the shape of the star between languages (across the page), and against the general trend (in the background).
The swatch of the languages are grouped into columns according to their overall performance. Thus the fastest languages are in the first column on the left and the slowest are on the right. Within each column the swatches are sorted by average code size, with the best one at the bottom. In this way, the disposition of the grid mimics the axes within the swatches.
This chart is a treasure of narratives.
The languages in the first column all have tall thin pogo-stick stars. They show strikingly consistent performance, maxing out the CPU times after times. Their code sizes, on the other hand, are spread all over. The bottom left three languages, Cmucl, Regina and Stalin are outliers. These languages do not have enough benchmark implementations in the database to generate fully fleshed stars.
In the rightmost three columns we find many bushy stars, flat and wide. These are the scripting languages whose communities have not invested as much effort into building optimizing compilers for their language as they have spent tweaking its expressiveness. There are, however, a few spectacular exceptions. Lua, which has always been noted for its good performance among scripting languages, shows a beautiful round star in the swatch at (5, 2), counting from the bottom left. Even better, the star of Luajit (3, 1) seems to squeeze itself in the coveted bottom left corner, amongst academic Juggernauts such as Mlton (2, 1), Ocaml (3, 2), Gambit (4, 1), and Haskell (4, 2).
The shape of the Haskell star, specifically the way that it bends up, suggest to me that writing high-performance programs in Haskell is a bit of a black art, and that some of the benchmarks submissions could be improved if someone got around to it. It also suggests that the tweaks introduced to boost the performance occupy a lot of code space. (I hope someone from the Haskell community will be able to confirm whether this is the case)
I find the swatch for the language Clean at (1, 8) quite interesting, in light of the oddly shaped Haskell star. Clean is a lazy language just like Haskell. Its star looks like the result of smashing Haskell star against the left wall, as if a huge effort of optimization had paid off.
Psyco (4, 1) is a decent improvement on the standard Python (7, 1) evaluator but it is still rather bushy. On the plus side, both versions of Python can claim many of the smallest programs in the collection. Ruby (8, 1) might also compete for titles, but unfortunately its performance is so bad its star falls off the performance chart.
C# (3, 4) has the same shape as Java (3, 7), merely 1, 2, or three rows down, depending on how you count. The arrival of Scala (6, 7) in the Java world is a mixed blessing. While it fixes the worse convolutions (it has no top-of-the-square points) it also introduces terrible performance hiccups (the points which shoots out to the right.)
Is interesting to see Groovy (7, 5) right next to MzScheme (6, 5). Both languages have similarities in terms of the features that would impact the performance of the evaluator. You would expect Groovy to display better performance since it uses the Java virtual machine and all its optimizations, but the reverse is true.Finally, the top right corner is occupied by specialty languages, with their momentous stars which reach across the performance spectrum along both axes, from the very best to the very worst.
Does introducing functional features kill performance?
No, it does not. In the following chart, the ordering is the same as in the large chart. Languages which include functional features such as lambda, map, and tail call optimization are highlighted in green. C compilers, C++ and C-derivatives are in blue. The blues dominate the first column. The greens occupy the main diagonal, from the oddball corner to the "ideal" corner. Ultimately the first factor of performance is the maturity of the implementation.
Source code
The code to generate these charts runs in PLT Scheme (MzScheme) v4.1.5. You will need the data file from The Game's cvs repository.
zondag 31 mei 2009
Graphical comparison of programming languages
vrijdag 15 mei 2009
Teamwork op hoog niveau: het ISAAC Self-Service Diner
Donderdag 14 mei vond bij ISAAC het ISAAC Self-Service Diner plaats in het kader van teambuilding en algemene gezelligheid.
Alle werknemers van ISAAC werden ingedeeld in teams met hun eigen taken en verantwoordelijkheden:
het boodschappenteam, de afwassers, het tafeldekteam, de bediening en natuurlijk de koks voor het voorgerecht, hoofdgerecht en nagerecht.
Samen heeft iedereen zijn taken goed vervuld, alles liep op rolletjes en het eten was heerlijk!
vrijdag 8 mei 2009
Forms controleren met JQuery
JQuery maakt het gebruik van Javascript in websites eenvoudiger met een kleine core library die is uit te breiden met plugins. Deze plugins zijn beschikbaar voor haast alles wat je mogelijk zou willen doen. Zo ook voor het valideren van formulieren. Hiervoor zijn meerdere plugins beschikbaar maar de beste is toch wel de "validation" plugin. Met deze plugin is het mogelijk om met slechts een enkele regel javascript een eenvoudige controle uit te voeren op een formulier. Je controleert dan enkel of een aantal velden zijn ingevuld. Complexere controles zijn mogelijk door regels en functies toe te voegen aan de validatie.
Stel je hebt het volgende formulier op je site:
<form id="formulier">
<input type="text" name="voornaam" id="voornaam" />
<input type="text" name="achternaam" id="achternaam" />
<input type="submit" value="opslaan" />
</form>
Om op dit formulier te controles toe te voegen zijn twee stappen nodig:
De eerste stap is eenvoudig, stel "achternaam" is verplicht, ons formulier ziet er dan als volgt uit:
<form id="formulier">
<input type="text" name="voornaam" id="voornaam" />
<input type="text" name="achternaam" id="achternaam" class="required" />
<input type="submit" value="opslaan" />
</form>
de tweede stap zetten we in de "ready" methode van jquery:
<script>
$(document).ready(function(){
$("#formulier").validate();
};
</script>
Dat is alles, wanneer de gebruiker nu het veld "achternaam" niet invult krijgt hij de melding dat het veld verplicht is. Naast "required" zijn er meer classes beschikbaar in de plugin, zoals "email" voor het valideren van e-mailadressen, "url" voor het valideren van url's, enz. Naast deze standaard methoden kun je ook je eigen toevoegen. Laten we zeggen dat "achternaam" niet alleen verplicht is, maar ook alleen letters mag bevatten. We kunnen dan onze eigen methode maken om dit te controleren.
<script>
$.validator.addMethod('tekst', function (value) { return /^[A-Za-z]*)$/.test(value) }, 'Achternaam mag alleen tekst zijn');
</script>
De bovenstaande code voegt een methode toe om dit te doen met de naam 'tekst'. Hiervoor gebruik je de methode "addMethod()" waar je drie parameters aan meegeeft. Als eerste de naam van de nieuwe methode. De tweede parameter is een functie die de controle uitvoert en een true teruggeeft als de meegegeven waarde voldoet en een false als hij niet voldoet. De laatste parameter is de foutmelding die getoond moet worden. Na de methode toegevoegd te hebben kan de naam ("tekst" in dit geval) samen met de andere functies als class aan een inputveld toegevoegd worden.
Naast het toevoegen van methodes is er ook nog de mogelijkheid om regels toe te voegen. Regels kunnen worden gebruikt om een functie ergens van afhankelijk te maken. Bijvoorbeeld, stel we willen wel dat "achternaam" verplicht is, maar alleen als er niks is ingevuld bij "voornaam". We kunnen dan aan de methode "validate()" een regel toevoegen die dit controleert.
<script>
$(document).ready(function(){
$("#formulier").validate({
rules: {
achternaam : {
required: {
depends : function() { return ($("#voornaam").val() == '');}
}
}
}
});
};
</script>
De bovenstaande code voegt de regel voor "achternaam" toe. hierin staat een "depends" (een afhankelijkheid) die controleert of de ingevulde waarde bij "voornaam" leeg is of niet.
Als laatste willen we natuurlijk een aangepaste foutmelding tonen als achternaam niet is ingevuld. Ook dit voegen we toe aan de validate methode, achter de rules.
<script>
$(document).ready(function(){
$("#formulier").validate({
rules: {
achternaam : {
required: {
depends : function() { return ($("#voornaam").val() == '');}
}
}
},
messages: {
required: "Dit veld is verplicht"
}
});
};
</script>
In het messages blok kunnen we een opsomming maken van alle methodes die we in de classes invullen met daarachter een tekst. Deze tekst wordt getoond wanneer de validatie op dit punt niet goed gaat.
Dit is de basis van de functionaliteit van de validation plugin, natuurlijk is nog meer mogelijk dan alleen het bovenstaande, maar hiermee vang je 99% van de formulier-validaties op.
donderdag 23 april 2009
Roefeldag bij ISAAC
In het kader van de roefeldag heeft ook ISAAC twee groepjes kinderen gedurende een middag uitgelegd wat wij doen en hoe wij dit doen. Onder begeleiding van een ISAAC medewerker, mochten de kinderen een LEGO robot programmeren zodat deze zelfstandig een parcours kon afleggen. Het was een plezierige en succesvolle middag waarbij we als organisatie konden terugblikken op een leuke nieuwe ervaring om ons werk eens te laten zien aan de volgende generatie.
Jantje Beton Roefeldag
De naam Jantje Beton Roefeldag komt van het Belgische woord 'roefelen' wat 'snuffelen' of 'ontdekken' betekent. Al meer dan 15 jaar laat Jantje Beton kinderen van 7 tot 13 jaar een kijkje nemen in de wereld van volwassenen. Een mooie gelegenheid om organisaties, verenigingen en bedrijven in hun buurt te leren kennen en te beleven wat volwassenen nou zoal de hele dag doen. Tijdens een roefeldag doen kinderen zelf mee en mogen ze zelf de rol van bijvoorbeeld bakker, brandweerman of portier vervullen.
dinsdag 21 april 2009
Vers brood door Twitter
Om de Twitter-hype te sponsoren hier nog een berichtje van een slimme hippe bakker in de UK. Het is een RE-blog dus bij deze de originele versie in het engels:
twitter-enabled box alerts customers to fresh bread
Everyone knows that baked goods tend to be best when fresh from the oven; the challenge for bakery customers is predicting when that might be. New technology from London agency Poke now removes the guesswork, however, by enabling bakeries to alert their customers via Twitter any time a new batch is done.
Much the way fans of LA's Kogi Korean BBQ can follow the company on Twitter to find out where its taco truck is at any given moment, so BakerTweet allows bakers to keep their customers informed. But because bakery kitchens don't tend to be hospitable to electronic devices—replete as they are with flour, eggs and other messy stuff—BakerTweet uses a specially designed box that can withstand the messiest kitchen conditions. Bakers begin by creating an account online with BakerTweet using their regular computer, inputting all the baked items they want to Twitter about along with the body of the Tweet that will be sent out for each. Back in the kitchens, the wall-mountable BakerTweet box captures that information, allowing bakers to simply turn a dial to select which item they want to Tweet about at that moment ("Fresh Buns," for example) and then push a button to send the full Tweet wirelessly to Twitter. Customers following the bakery then get updated immediately when it's time to go get those buns. A video on Vimeo demonstrates BakerTweet in action.
Poke staff originally developed BakerTweet for the Albion Cafe—its neighbour in Shoreditch, London, and currently the site of the only prototype device—for the very practical purpose of finding out the best time to go get stuff there. (To find out what's available, they simply follow @albionsoven.) However, as the company sagely notes itself, the technology is eminently applicable to just about any business that needs to communicate quickly and easily in real time about offers, pricing, stocks or other information. There's no word yet on pricing or availability; nevertheless, BakerTweet is not only a no-brainer to be implemented by bakers the world over as soon as possible, it's also yet another tasty illustration of the increasingly blurred lines between the online and offline worlds, as our sister site describes in its OFF=ON briefing. One to implement, adapt or partner with in the application of your choice!
Website: www.bakertweet.com
Spotted: Springwise
dinsdag 31 maart 2009
Java Swing: past, present and future
Toch wordt in de tussentijd de toolkit wel bijgehouden. Er worden nog steeds bugs uit gehaald en de performance kan blijkbaar nog altijd beter. Tevens worden er verschillende libraries met generieke componenten in de JDK opgenomen die het programmeren in Swing vergemakkelijken. Dit zijn vaak hoger level componenten, ontwikkeld door Swing gebruikers, die een bepaalde functionaliteit bieden die je anders zelf zou moeten ontwikkelen of steeds overnieuw zou moeten schrijven. Op die manier is er voor Swing applicaties steeds minder boilerplate code nodig omdat je steeds meer componenten tot je beschikking hebt die je standaard kunt gebruiken. Denk hierbij aan de SwingWorker, het TimingFramework en JOGL. De laatste maakt zelfs 3D rendering in Swing applicaties mogelijk!
Swing is van nature een toolkit die basisfunctionaliteit voor grafische applicaties biedt, maar wat niet veel mensen beseffen is dat dit juiste de kracht van de toolkit is. Dat heeft ook Sun ingezien en daarom willen ze in de volgende versie van de JDK (ja ja, versie 7 alweer!) gewoon verder gaan met het optimaliseren van de Swing engine. Tevens wordt er hard aan gewerkt om Swing in steeds meer frameworks te integreren. JavaFX bijvoorbeeld zal Swing componenten kunnen gebruiken voor bepaalde functionaliteit in dergelijke applicaties. Het verder uitbreiden van toepasbare Swing componenten laat Sun lekker over aan iedereen die hier aan mee wil werken. Ze hebben zelfs een website opengezet (http://openjdk.java.net/) dat als het zenuwstelsel hiervoor moet dienen.
Ik ben benieuwd wat er van Swing in de toekomst gaat komen. De volgende JDK brengt geen wereldschokkende uitbreiding van de toolkit met zich mee, maar ik denk dat het juist aan de Swing communities is om de toepasbaarheid van Swing te vergroten. Nog steeds, na al die jaren dat Swing in ontwikkeling is, denk ik dat het voor veel ontwikkelaars een ondergewaardeerde toolkit is. Het potentieel van een robuuste, goed presterende applicatie met een mondwaterende gebruikersinterface behoort zeker tot de mogelijkheden maar de mogelijkheid hiervan is niet bij iedereen bekend. Natuurlijk is Swing niet de enige speler meer op de markt als het aankomt op een web- of desktopapplicatie met een mooie grafische interface. Toch is deze toolkit veruit de meest generieke, wat ook meteen zijn kracht en tegelijk zijn zwakte vormt.
vrijdag 20 maart 2009
Wellicht Java?
Recentelijk heb ik een weblog geschreven over een bepaalde "monad", namelijk de "Maybe Monad".
Maar toen ik er bijna klaar mee was kwam ik erachter dat ik ook nog een post moest schrijven voor deze ISAAC weblog. Het artikel is een beetje te groot, en wellicht te esoterisch, om zomaar te vertalen naar het Nederlands. Daarom geef ik hier een samenvatting.
Het volledige artikel is hier te lezen.
De Maybe Monad, in de simpelste van termen, gaat over de vraag, "Wat moet een functie teruggeven als de combinatie van parameters eigenlijk tot niks uitkomt?" Om een voorbeeld te noemen, delen door nul. De meeste talen die we tegenkomen in ons werk bij ISAAC geven, in dit geval, over het algemeen een "exception", of in geval van Javascript "NaN". In feite is een exception throwen precies wat er zou moeten gebeuren, omdat delen door nul nog helemaal niet is opgelost door de wiskunde. Maar een aantal talen naast Java leveren een antwoord op deze vraag met een mechanisme dat "lichter" is dan een exception. Om dit te doen word in vrijwel alle gevallen een variatie van de Maybe Monad gebruikt. In een aantal talen is dit enorm simpel uitgedrukt, bijvoorbeeld Haskell:
data Maybe = Some a
Nothing
Of in Scala:trait Option {}
sealed case class Some[A](val a:A) extends Option[A] {}
sealed case object None extends Option[Any] {}
Maar dat zijn Haskell en Scala, en niet Java. Gelukkig is het (bijna) net zo simpel als in deze talen. Net zo simpel als een Pair of (simpele) Tuple class die iedereen wel eens schrijft tijdens een project. De Scala versie hierboven is eigenlijk enorm vereenvoudigd (maar is, binnen Scala helemaal functioneel te gebruiken), het heeft extra methoden, bijvoorbeeld een "getOrElse", die voor Some a terug geeft, en voor None de parameter die je meegeeft. Daarnaast is Option "Iterable", dat wil zeggen, je kan het in een for-loop gebruiken. Deze dingen zijn zeker nodig in Java, omdat Java geen Pattern Matching heeft, zoals Haskell en Scala (Haskell leeft erop!). Daarnaast zijn constant instanceof checks in je code niet veel beter dan null checks.
In Java is de Maybe Monad niet veel moeilijker in het gebruik dan het bovenstaande (code is te vinden in de post hierboven):public Maybe
Het grootste voordeel is dat je de mogelijkheid dat het "fout" kan gaan expliciet gemaakt word, i.p.v. een runtime exception (zoals ArithmaticException, bij het delen door 0). Je wilt die niet zomaar krijgen in een 24/7/365 systeem alleen omdat een informatieleverancier ergens (per ongelijk) een 0 plaatst. Maar om try/catch om iedere deel operatie te zetten is ook weer te vervelend, het zelfde met iedere keer if statements om een deel operatie. Nu kan je gewoon, simpel, getOrElse aanroepen. Ik moet toegeven, in Haskell en Scala heb je het mooie Pattern Matching mechanisme, waar dit allemaal elegant word opgelost. Hoewel dit in Java iets minder elegant is, is het nogaltijd eleganter dan exceptions of velen if statements.
Daarnaast beschrijf ik hoe je de Map interface kan uitbreiden zodat deze Some teruggeeft als de key daadwerkelijk bestaat, en None teruggeeft als deze niet bestaat. Heel handig als null een goede waarde is voor een value bij een Key. Je hoeft dan niet nog een keer de key op te zoeken. En dat gebeurd ook niet in de aangepaste get, omdat er alleen Some of None waardes erin staan zal het zo zijn dat als er null terugkomt (intern) het alleen kan betekenen dat de key niet bestaat, en dan kan None teruggegeven worden.
Als laatste gaat de post over wat het nou toch is met die null, waarom ergeren we er ons toch iedere keer aan, en blijven we er toch bij terugkomen? Een van de karakteristieken van null is dat je het aan iedere type kan toewijzen, dit lijkt heel vreemd, en dat is het in feite ook. Null is een zogenaamde "Bottom Type", en is een type (in een Type System) dat (impliciet) een subtype is van alle andere types in het Type System. In Java is, bijvoorbeeld, Object een bottom type, zelfs Object subclasses Object in Java. Maar, er zit een gotcha aan, null heeft geen type. En dat is (vind ik) nou jammer, het betekend gewoon dat er allerlei special cases in de JVM en de Type System van Java zitten, alleen maar om die null waarde zonder type. Maar waarom is null nou bedacht?
Die eer komt toe aan Sir Tony Hoare, in 1965, en hij noemt het zijn "Million Dollar Mistake". Het was toendertijd zo gedaan omdat het simpeler was om te maken. Ik zal zeker de eerste zijn om te zeggen dat luiheid over het algemeen een goede karakter eigenschap is voor een programmeur, maar nu, 44 jaar later, moet zelfs ik bekennen dat er gevallen zijn waar luiheid schade berokkend. Null references zijn er een van. Het is wellicht grappig om te weten dat C++ null pointers kan hebben, maar niet null references (het zou een compiler bug zijn als dat mogelijk was!). Maar de pijn lijkt een beetje verbeterd nu er Elvis operators (zoals ze deze noemen in Groovy) komen in Java7.
En toch, ik vrees dat we voor een lange tijd niet af zijn van "null". Gelukkig hebben we gezien dat er "betere" dingen zijn in het geval "geen waarde". Dus, als je je afvraagt "wat moet ik doen als ik eigenlijk niks kan teruggeven vanuit deze functie?" Dus geen exception (tenzij het echt "exceptioneel" is) en ook geen null, want dat is een waarde, maar geen "None" terug! Maak het expliciet, de wereld zal je er dankbaar voor zijn.
zondag 8 maart 2009
Compatibility wars: nieuwe browser wars?
Het is een tijdje redelijk rustig geweest aan het browserfront. Elke maand een procentje Firefox erbij en een procentje Internet Explorer minder in de wereldwijde gebruikersstatistieken, maar dat was het dan ook wel qua spanning. Inter Explorer 6 wil (helaas) maar niet echt doodgaan in de lijstjes, hoewel er vanuit Skandinavië dappere pogingen worden gedaan om deze jaren oude security- en stadaardhel de nek om te draaien met een "Upgrade dan tenminste naar IE7"-actie. En zoals mijn CTO Front-end-collega Koen onlangs wijs sprak: "Ik heb eigenlijk liever dat IE6 gebruikers upgraden naar IE7 dan naar Firefox, want dan kunnen ze tenminste niet meer terug!". Juist! Zo erg is het met IE6. Weg ermee dus, en upgraden, hup!
Het lijkt er echter op dat we na een relatief rustige periode weer een nieuwe "oorlog der titanen" tegemoed gaan. Google kwam met het slim gethreadde hipster-browsertje Chrome (lekker snel maar niet echt een killer app naar mijn mening), maar Apple mengt zich nu ook zeer serieus in de strijd met de nieuwe Safari. En deze fraaie Safari 4-beta is 100% ACID 3-compatible! Voor de niet-zo-browser-en-web-savvy-lezer: ACID is een testsuite voor browsers om te beoordelen hoe goed een browser zich aan de webstandaarden weet te houden. IE6 scoort bijna of-the-record aan de onderkant, maar Safari 4 beta is in staat gewoon de volle 100% te scoren. Het kan dus gewoon wél! Voor webontwikkelaars is de gedachte aan een wereld met alleen maar ACID 3-compatible browsers op het internet, als een soort ultieme Red-Shoe-Diariesdroom: alles maar één keer testen, en het werkt meteen op elke PC of Mac! Oh boy oh boy! Als dat toch eens waarheid kon gaan worden!
Enfin, intussen zit Microsoft ook niet helemaal stil (IE8 komt er aan), maar helaas komt deze lang zo ver niet als Safari in de tests. IE zet wel weer een stap (en eerlijk: dit keer best een flinke), maar een echte sprong naar compatibiliteit zoals Safari en de nieuwe Opera die maken is het niet. Firefox doet zoals verwacht braaf mee in deze vooruitgangsdrift, maar lijkt wat problemen te hebben met de nieuwe Javascript-engine. Nu is een random crash en memory leak hier en daar natuurlijk ook wel traditie voor een Firefox-betaversie.
We kunnen bij ISAAC alleen maar hopen dat al die internet hatende systeembeheerders die hun medewerkers (for hell's sake) dwingen te blijven draaien op IE6 tenminste over gaan stappen naar IE8. Maar liever nog naar Safari dus, want dat lijkt een échte browser te gaan worden.
De heren van GeenStijl.nl linkten vandaag een erg interessant artikel over de "nieuwe" browser battle die in aantocht is. Een vergelijking van negen huidige en aankomende websurfapplicaties. Het is een artikel van MaximumPC.com, en brengt je in een paar minuten up-to-date met de huidige stand-van-zake op browsegebied. Klikt allen!
Zoals David Duchovny aflevering na aflevering zei: "Dear red shoes...", let this dream become reality!
maandag 2 maart 2009
DotCMS
Er is steeds meer vraag van klanten naar CMS functionaliteit, zodat ze zelf hun content kunnen beheren. Dan hoeven ze niet voor elke kleine aanpassing ISAAC te bellen, en hoeft ISAAC niet veel tijd te besteden aan kleine wijzigingen die altijd langer duren dan gepland. Er is binnen ISAAC gekozen voor DotCMS, een gebruiksvriendelijk java-based open-source systeem dat ook onder JBoss kan draaien. Dat betekent dat ISAAC hiermee makkelijk aan de slag kan, en ook extra wensen van de klant kan bewerkstelligen die buiten de huidige functionaliteit van het CMS systeem vallen.
DotCMS is op verschillende manieren te gebruiken. Zo kan het worden gebruikt om een hele website te beheren, of het kan worden gebruikt om alleen kleine delen van (bestaande) websites te CMS'en. Dus kan ISAAC op deze manier verschillende niveau's van CMS-baarheid aanbieden aan klanten.
Delen van de website in DotCMS
DotCMS is oorspronkelijk bedoeld als CMS systeem voor een hele website, of in elk geval voor webpagina's. Je maakt een template (blauwdruk) van een pagina en hergebruikt dat in je website. Maar hoe de template eruit komt te zien heb je zelf in de hand. Je kan dus een HTML template maken, maar ook een XML template. ISAAC gebruikt deze mogelijkheid om content structuren aan te maken en te beheren in DotCMS, en de content aan te bieden via XML (SOAP communicatie bijvoorbeeld). Zo kan een andere website uit DotCMS zijn content halen.Op deze manier kan een heleboel functionaliteit van DotCMS worden gebruikt en hoef je niet de hele website in DotCMS te zetten. En je hoeft geen eigen mini-CMS te maken. Dit scheelt een hoop tijd (en geld) en biedt klanten toch al aardige CMS functionaliteit. En met handig programmeerwerk kun je voorkomen dat er meerdere calls naar DotCMS nodig zijn om meerdere soorten content op te halen, dus veel latencty heb je niet.
De hele website in DotCMS
Uiteraard kun je ook de hele website in DotCMS zetten, op die manier is alles aanpasbaar voor de klant. Daarmee krijg je alle functionaliteit die in DotCMS zit tot je beschikking. Maar waar ik iedereen voor wil behoeden is dat het gebruik van DotCMS ook nadelen met zich meebrengt... Je werkt namelijk in een bepaalde structuur en daar zit je aan vast (dat is logisch, alleen ziet de klant dat anders). Daarom moet er een duidelijk beeld worden geschept bij de klant wat er nu precies wel en niet mogelijk is in DotCMS. De details zal ik hier niet noemen, maar voor medewerkers heb ik een wiki pagina gemaakt genaamd DotCMS_Schattingen. De naam verklapt al dat er schattingen staan per onderdeel, en er staat een lijst met details over functionaliteiten. Deze kunnen je helpen bij het praten met de klant en het maken van schattingen.
woensdag 25 februari 2009
Safari 4 public beta: benchmark time!
Today Apple released the latest version of their browser: Safari 4. It's only a public beta but with an impressive list of new features including a JavaScript engine that is 4.5 times faster than the previous Safari version, I couldn't resist: benchmark time!
For this benchmark I used the webkit SunSpider benchmark. This benchmark only tests the core JavaScript language, not the DOM or other browser APIs. Looking at the current RIA trend this makes sense: more and more of the application logic (and therefore data structure) is being run inside the browser, so core data structure manipulation will become much more important in the future.
The benchmark runs a couple of tests that consist of crypto and 3d calculations, some bit operations, string and date manipulations, recursion, and object access tests. It returns the time it took to complete each test and the sum of all the tests is the overall score. Here is an example of one of my runs on safari 4 (time in milliseconds).
For the benchmark I used my Dell latitude D830, running Windows XP. I tested the following 5 browsers:
- The new Safari 4
- Google Chrome 1.0
- IE 7
- IE 6
- Firefox 3.0
- Opera 9.6
After running the same test 5 times in each of the browsers I found the following results (lower bar is better)
In my very non-scientific tests the new Safari 4 is just a fraction faster than Google Chrome and about 2.2 times faster than Firefox and Opera. But it's much much faster than IE6 and IE7: a whopping 13 times on my machine.
Apple itself claims to be 3 times faster than Firefox and even 30 times faster than IE7, using SunSpider and iBench as benchmarks. My findings where not this extreme, but impressive nonetheless.
I guess Google's goal to raise the bar on JavaScript performance was a success. With their dependance on fast JavaScript for all their cloud apps I guess they are the ones that will be most pleased with this new version of Safari.
Oh, and don't forget our ultimate benchmark. Yeah baby!