Month: January 2009

Ook op het internet geen koopzondag

Bij een vooral christelijk kabinet, kan je natuurlijk altijd vreemde dingen verwachten. Rook- en paddoverboden kun je altijd nog motiveren door de verwijzen naar de gezondheidsrisico’s. Het opkopen van banken is natuurlijk ook vreemd. Echt vervelend wordt het pas als het beleid wordt gebruikt om te evangeliseren. Het in ere herstellen van de christelijke rustdag op zondag. Geen of minder koopzondagen is het plan, dat het 20.000 banen kost, maakt dan niet eens meer zoveel uit. Wat ik mij vooral af vraag is, voor wie zijn dat soort maatregelen bedoelt? Zijn er echt mensen die zich storen aan het open zijn van de winkels op zondag? (Ik heb er nu i.i.g. één gevonden, zie verder). Zelfs voor die paar mensen die op zondag nog naar de kerk gaan, lijkt mij het handig als daarna nog even kunnen shoppen, als ze toch langs de winkel komen. Buiten dat alles lijkt het mij gewoon handig om de winkels open te doen, wanneer zoveel mogelijk mensen tijd (en zin) hebben om wat te gaan kopen. Beste logisch dat dit op zondag is want dan hebben veel niet-winkeliers een vrije dag. Een ander probleem is dat van al die bemoeizucht mensen ‘gekke dingen‘ gaan doen….

Toch aardig dat ik het bovenstaande allemaal heb opgeschreven, want hoe meer winkels er dicht zijn, hoe meer mensen op internet zullen kopen. En dat zou dan uiteindelijk weer goed voor mij moeten zijn….. via verschillende website doe ik mee aan zgn. affiliate (affiliatie) programma’s. Wanneer ik (affiliate) iemand via een hyperlink doorstuur naar een webshop (adverteerder) en die persoon koopt daar dan ook iets, dan ontvang ik over die aankoop een provisie. Dat werkt bijvoorbeeld als volgt; onderaan het artikel “De nieuwe 17-inch MacBook Pro” staat een link ““Koop een 17-inch MacBook Pro“. Wanneer iemand na het lezen van het artikel nu een Macbook via de genoemde link koopt, dan verdiend de auteur van dat artikel daar dus aan.
Een andere adverteerder waar ik affliate ben is babypark.nl en daarom kwam ik vandaag op die website (ik werk wel op zondag dus). Tot mijn grote verbazing las ik daar het volgende:
—
Onze site is op zondag gesloten.
Graag zien wij u op andere dagen van de week terug.
Onze medewerkers zullen u dan volledig van dienst zijn.

Bedankt voor uw begrip en tot ziens.
—
Tja…. het mag natuurlijk. Als affiliate van deze webshop vind ik het een stuk minder leuk. Tot vandaag dacht ik altijd dat het plaatsen van een telefoonnummer, voor telefonisch bestellen op de site, de ‘grootste zonde’ was van adverteerders in de affiliatiebranche. Wanneer iemand telefonische bestelt, kan de verkoop niet meer aan de affliate worden toegekend. Althans het kan wel, maar het gebeurd vaak niet. Het sluiten van de website op een willekeurige (zon)dag is voor de affiliates ook niet echt gunstig.

Overigens verwijst de bovengenoemde link naar babypark.nl naar actiebaby.nl. Misschien wordt dat ook aangepast, ik moet nu echt tot maandag wachten omdat te kunnen controleren. De links die ik gebruik komen dus van affiliate4you.nl, dat is een bedrijf dat bemiddelt tussen affiliates en de adverteerders.

Veel affiliate programma’s werken d.m.v. cookies, de cookies van babypark.nl zijn bijvoorbeeld 100 dagen geldig. Dat betekent dus dat wanneer een bezoeker later terugkomt op webshop, waar hij in eerste instantie kwam via een affiliate-link, toch nog een commissie kan opleveren voor de affiliate.

De website van actiebaby.nl legt op zondag wel cookies vast. Kunnen dan ook niet gewoon de orders automatisch vastgelegd worden voor verwerking op maandag, vraag ik mij dan meteen af.

En wie echt niet kan wachten, via http://www.google.nl/search?q=site%3Ababypark.nl kun je de artikelen op de site terugvinden en bekijken. Dat kan zelfs op zondag, bestellen dus niet.

Misschien moet ze hier in Den Haag toch ook eens naar kijken. In andere landen bemoeit de overheid zich ook veelvuldig met toegang tot websites. Het beste lijkt mij om op zondag gewoon het hele internet te sluiten. Dan kunnen mensen lekker naar de stad om de etalages van de gesloten winkels te bekijken.

Reverse Ajax

Voor een project wil ik het volgende testen: door het oproepen van een URL met parameter, bijvoorbeeld http://www.w3masters.nl/opslaan/?woord=test, wordt de parameter opgeslagen in de database. Na het opslaan in de database wordt in een webapplicatie een pop-up geopend, die de opgeslagen parameter toont.

Dit betekent dus dat de webserver de data naar de webapplicatie (browser) moet pushen. Deze techniek heeft de naam Comet gekregen. (zie ook: http://ajaxpatterns.org/HTTP_Streaming) Het is daarbij niet wenselijk dat er steeds een mysql-query gedaan moet worden om te controleren over er nieuwe data is.

Om dit te bereiken is een extra Comet server nodig. De clients maken een connectie naar deze server en tonen een pop-ups als er nieuwe data beschikbaar is. Bij het samenstellen van de pop-up kan extra data uit de database worden opgehaald. Het script (php) dat wordt aangeroepen bij de eerder genoemde URL, schrijft de parameter naar de database en geeft het ID van de parameter door aan de Comet server. De clients ontvangen het ID en kunnen dus vervolgens de pop-up tonen.

Voor het opzetten van een comet server lijkt Jetty zeer geschikt. Jetty is opensource webserver geschreven in Java. Jetty bevat tevens een servlet implementatie van het Bayuex protocol van cometd. Cometd is een implementatie comet van de Dojo Foundation. Bij Jetty zittten tevens een aantal cometd demo’s, zie http://docs.codehaus.org/display/JETTY/Cometd+(aka+Bayeux). Net als de meeste andere comet voorbeelden, zit hier ook een chat applicatie bij. Met enige aanpassing zou deze applicatie de gezochte functionaliteiten kunnen leveren. Een eenvoudige “hello world” is hier te vinden.
Het Bayuex protocol voorziet niet in autorisatie en/of authentificatie. Autorisatie zou dus via de webserver zelf geregeld moeten worden. Jetty kan dit o.a. met JAAS, zie http://docs.codehaus.org/display/JETTY/JAAS.

Een alternatieve Comet server zou Comep kunnen zijn. Comep is een comet server geschreven in PHP. Comep levert ook enkele voorbeelden mee. Deze voorbeelden leken in eerste instantie niet te werken. Ook Meteor zou geschikt zijn, Meteor is geschreven in Perl. Meteor moet onder poort 80 draaien, wat een nadeel kan zijn als je deze dus wilt gebruiken op een server waar ook bijvoorbeeld Apache draait. De reden die hiervoor gegeven werd was dat Meteor anders vatbaar was voor cross-site scripting. Ik vraag mij af waarom dat op port 80 dan niet zo is? En als dat inderdaad niet zo is hoe dat dan zit met de andere hier besproken servers? Het artikel “Real Time Angst” geeft een zeer mooi voorbeeld van de kracht en mogelijkheden van Comet. Dit voorbeeld is ook op Meteor gebouwd. Hoewel ik dus niet opzoek was naar live data streaming is wel me wel duidelijk geworden dat Meteor een goed opensource alternatief is voor bijvoorbeeld het commerciële Lightstreamer.

Overigens lijkt een server zoals Jetty voor een eerste prototype van mijn project toch nog wat te complex. Het artikel
“How to implement COMET with PHP” komt met twee eenvoudigere voorbeelden. De comet server is hier feitelijk een php-script in een ‘oneindige’ loop. Ook wordt geen gebruik gemaakt van het Bayuex protocol. Toch heeft het tweede voorbeeld wel ongeveer de functionaliteit die ik nodig heb. Je kunt regel tekst aan een .txt bestand toevoegen (in mijn geval dus het ID). Op de client wordt deze regel getoond, de laatst toegevoegde regel en alle regels die nieuw worden toegevoegd.

Evaluatie Digitalus cms 1.5 beta

Af en toe denk ik er over na om opensourcecms te herschrijven naar het Zend Framework. Er zijn natuurlijk veel php frameworks, toch lijkt Zend daarvan op dit moment de enige te zijn, die een standaard kan worden. Onlangs stuitte ik op Digitalus cms, dat reeds ontwikkeld is op het Zend Framework, het leek mij daarom interessant om eens te bekijken hoe de nieuwe 1.5 beta werkt en in elkaar zit.
Beta bleek al snel een groot wordt. Wat je krijg is de basis, met een installer die redelijk werkt. Pas na het lezen op het forum kwam ik er achter, dat de cache directory chmod 0777 moest hebben. Er wordt in deze beta slechts één module meegeleverd, de contact form module, die overigens niet werkt.
De reden om niet de stable versie maar de beta te testen is dat de stable versie in de eerste plaats niet gebouwd is met het Zend Framework. Ook beschikt de stable versie niet over de mogelijkheid een meertalige website te bouwen. Dit laatste is één van mijn minimale eisen.

MVC

Het cms maakt gebruik van het Model-View-Controller ontwerp patroon dat in Zend Framework geïmplementeerd is. Dit maakt de opzet van het systeem en de code overzichtelijk. In eerste instantie komt het vreemd over dat de views php-code bevatten. Dit is geen manco van Digitalus cms. Dit komt voort uit het Zend Framework. De ontwikkelaars van het Framework zeggen hierover: “PHP is itself a powerful template system”.

Artikelen en pagina’s

Wanneer je binnen het cms een pagina aanmaakt kan daar vervolgens met een html-editor, in dit geval WYSIWYG jQuery Plugin, content aan worden toegevoegd. Dat werkt prima. Zelf zou ik er de voorkeur aan geven om meerder artikelen per pagina te kunnen koppelen. Voordeel daarvan is dat je aan elk artikel apart extra functionaliteiten kunt koppelen. Op termijn zou dit opgelost kunnen worden via een aparte module.
Pagina’s kunnen slechts één module bevatten. Grootste nadeel daarvan is dat je geen content meer boven of onder de module kunt toevoegen. Dit probleem wordt opgelost door onder en boven de module een mogelijkheid te bieden, extra tekst in te voeren.

Automatische metatags

Bij Digitalus cms kan per pagina worden ingesteld wat de metatags (keywords en description) zijn, ook kan de titel van de pagina worden aangepast. Bij het beheren van meerdere website, met veel content wordt dit al snel te arbeidsintensief. Mijn voorkeur zou dan ook zijn dit net als bij Opensourcecms.eu te automatiseren.
De opzet van ./library/DSF/Builder/Action/Page.php maakt dit met een kleine aanpassing, mogelijk in de functie loadContent een aanroep te doen naar $this->setMeta en zo de metatags te maken op basis van de content die via de variabele content->content[‘content’]; beschikbaar is in deze functie.

Meertalige websites

Digitalus cms biedt de mogelijkheid om per artikel een vertaling aan te maken. Op de webpagina’s is dit zichtbaar te maken d.m.v. hyperlinks, die aangeven dat er ook een vertaling aanwezig is. Zelf zie ik de vertaling liever op een hoger (pagina) niveau, zodat niet alleen het artikel vertaald wordt maar ook de url, metatags (indien niet voor automatische metatags gekozen wordt, zie vorige paragraaf) en de menu’s op de betreffende pagina. Deze laatste optie, kan wel tot complexe situaties leiden, indien maar een gedeelte van de website vertaald is. Onmogelijk is het niet, zie bijvoorbeeld http://www.ellenpari.nl/

Modules

Ook de modules zijn opgezet volgen het MVC-partoon. Uitbreiding van het systeem, wordt daarmee eenvoudig en inzichtelijk. Wel vraag ik mij af hoe modules met meer complexere instellingen in de admin interface verwerkt moeten gaan worden. Binnen de interface lijkt wel ruimte te zijn gemaakt om een module in te stellen, maar niet om deze ook werkelijk te beheren, bijvoorbeeld in het geval van een webshop of forum.

Server farm

Installatie in een zgn. Server farm vind ik wenselijk. Hiermee bedoel ik dus dat er meerdere website opzelfde cms-code kunnen draaien. Mede door de MVC-implementatie zou dit mogelijk moeten zijn. In de huidige directory-structuur is hiervoor echter nog geen duidelijk onderscheid gemaakt. Het publieke deel (de feitelijk site) zou uitsluitend moeten bestaan uit templates, css, images en eventueel bijvoorbeeld een .htaccess bestand en een cache-directory.

Geheugengebruik en performance

Rekentijd en geheugengebruik krijgen bij cms-implementaties vaak weinig aandacht. Op zich is dat vreemd want in de eerste plaats bepalen deze factoren de laadtijd van de pagina. Daarnaast bepalen rekentijd en geheugengebruik het aantal gelijktijdige gebruikers dat een website of webserver kan afhandelen.

Ik heb een vergelijking gemaakt tussen Digitalus cms en Opensourcecms.eu, door een pagina te laden, met een artikel, menu, en ‘broodkruimel’-pad.

Digitalus cms:
<!– CPU usage user program: 0.248015 sec –>
<!– CPU usage OS for user program: 0.052003 sec –>
<!– Total cpu usage: 0.300018 sec (user + OS)–>
<!– Memory usage totaal: 5,184,296 bytes –>
<!– Memory usage cms: 5,127,524 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

Opensourcecms.eu:
<!– CPU usage user program: 0.092006 sec –>
<!– CPU usage OS for user program: 0.044003 sec –>
<!– Total cpu usage: 0.136009 sec (user + OS)–>
<!– Memory usage totaal: 1,708,364 bytes –>
<!– Memory usage cms: 1,468,084 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>
<!– Database version: –>

Naast de langere rekentijd van Digitalus cms is te zien dat het geheugengebruik bijna 3x zo groot is. Mogelijke oorzaken hiervan zijn:

  • De overhead van Zend Framework
  • In de code kom ik veel nieuwe class/object initalisaties tegen, waar een Singleton misschien efficiënter zou kunnen zijn
  • Het cms lijkt voor elke pagina alle beschikbare ‘helpers’ e.d. in te laden terwijl ze niet allemaal nodig zijn
  • Hoewel het menu en ‘broodkruimel’-pad op een pagina vaak weinig veranderd, moet het elke keer opnieuw berekend worden, wat vaak gepaard gaat met rekenintensieve recursies.

Hoewel het niet openstellen van de cache-directory fouten gaf bij het installeren, lijkt de cache nu nog niet gebruikt te worden. Dit zou de performance kunnen verbeteren, als is er natuurlijk altijd iemand die de eerste pagina of zijn eerste pagina moet opvragen.

Opensourcecms.eu legt bij wijzigen in de pagina/websitestructuur een cache-bestand aan. Vanuit de in dit cache-bestand opgeslagen paginastructuur, kunnen menu’s, sitemaps en ‘broodkruimel’-paden worden samengesteld, zonder steeds opnieuw dezelfde queries naar de database te hoeven doen.

Code

De code van deze 1.5 beta versie is overzichtelijk en leesbaar. Mede door de inzet van Zend Framework ook consequent van opbouw. Documentatie van de code ontbreekt helaas nog volledig. Ook lijkt er bij de ontwikkeling dus nog weinig aandacht voor performance te zijn.

Conclusie

Digitalus cms laat zien dat er met Zend Framework een goed opgezet cms gebouwd kan worden. De keuze om een splitsing te maken in een public en admin deel, met elk zijn eigen views en controllers vind ik verhelderend. Het meenemen van meertaligheid vind ik goed, al is deze in mijn ogen dus nog niet ver genoeg doorgevoerd. Performance vraagt volgens mij nog wel aandacht. Zonder verdere verbeteringen zullen de vertalingen en menu-opzet op dit moment nog leiden tot het publiceren van ‘duplicate content’, wat dus ook nog aandacht vraagt.
Websites bouwen op een beta versie is natuurlijk sowieso geen aanrader. Zelf ga ik Digitalus cms i.i.g de komende maanden in de gaten houden.
De community lijkt overigens niet heel erg groot en/of actief te zijn. Daarnaast hoop ik dat de ontwikkelaars niet vergeten om eerste een stabiele basis te bouwen, voordat alle nieuwe en mooie functionaliteiten worden uitgewerkt.

PHP programming (tools)

Voor Opensourcecms.eu was ik op zoeken naar een meer professionelere aanpak en ontwikkelomgeving.

Ontwikkelomgeving

De eerste stap was de ontwikkelomgeving. Jarenlang heb ik gebruik gemaakt van de Zend IDE (Zend Studio). Dat leek ooit een goede keus, gezien dat bijvoorbeeld de mogelijkheid bood om Zend Encoder en Zend Guard te gebruiken. Twee tools om o.a. je code te kunnen beschermen en daar eventueel een licentie key aan te kunnen koppelen. Zend Encoder heb ik in het verleden wel eens gebruikt, maar de laatste jaren niet meer.

Na een tip die ik kreeg bij webdesiging.nl uit Nijmegen ben ik enkele maanden geleden overgestapt op Eclipse. Overigens wordt Zend Studio tegenwoordig ook aangeboden als plugin voor Eclipse. Ik heb gebruik gemaakt van het PDT Project (PHP Development Tools). Hiermee kon ik direct aan de slag. Tot op heden heb ik geen extra-plugins gedownload en bevalt het prima.

Versiebeheer

Tot op heden had ik uitsluitend een lokaal CVS Repository in gebruik. De maakte het voor andere lastig mee te ontwikkelen aan Opensourcecms.eu of zelfs om het te gebruiken. Ik heb er over gedacht om SVN te gaan gebruiken, maar tot op heden voldeed CVS ook prima. In plaats van zelf CVS te installeren heb ik gekozen om een account aan te maken op Sourceforge.net en daar gebruik te maken van de CVS. Het project is te vinden op: http://sourceforge.net/projects/opensourcecmseu/

Test-driven development

Test-driven development heeft zich de afgelopen jaren wel bewezen. Daar zou ik dus eigenlijk ook wel mee aan de slag willen. PHPunit is de tool die ik daarbij kan gebruiken. De documentatie geeft ook wat voorbeelden, die mij een beter idee geven voor het schrijven van tests. Test voor alle bestaande code schrijven leek mij niet te doen, maar ik heb mij wel voorgenomen, voor elke nieuwe bug en zoveel mogelijk voor nieuwe code wel tests te gaan schrijven.

Documentatie

De code wordt pas echt herbruikbaar en vooral overdraagbaar als deze voorzien is van goede documentatie. Phpdoc biedt de mogelijkheid deze documentatie automatisch te genereren. De documentatie wordt gemaakt uit de comments, die in de code staan. Het is even wennen en soms zoeken welke comments er moeten worden toegevoegd. Ik verwacht dat het wel snel routine zal worden.

Coding standaards

Het hanteren van de standaard voor coderen, houdt de code leesbaar en begrijpelijk voor andere programmeurs. Bij de ontwikkeling van Opensourcecms maak ik gebruikt van het Zend Framework. Daarom heb ik er voorgekozen om de Zend Framework Coding Standard for PHP te gaan gebruiken.
Checkstyle kan helpen de standaard te bewaken en overzichtelijk maken waar er van afgeweken is.
Verder is er voor Eclipse een speciale plugin voor Checkstyle. De komende weken moet ik nog testen of deze ook echt werkt en toepasbaar is op de Zend Framework Coding Standard.

Phpundercontrol

Phpundercontrol is een addon tool voor CruiseControl. Deze tools brengen veel van het bovengenoemde samen. het eindresultaat is een grafische interface, waar de documentatie te vinden is, die is samengesteld met Phpdoc. Verder wordt inzichtelijk gemaakt of de code de tests doorstaan (PHPunit) en hoeveel procent van de code gedekt is met een test (code coverage). Tot slot zijn ook de resultaten van Checkstyle terug te vinden. Gezien veel van mijn code nu nog niet voldoet aan de coding standards, geeft deze laatste tool enige problemen. Er kan in PHP nu niet voldoende geheugen gealloceerd worden om de Checkstyle over alle code uit te voeren.
Phpundercontrol gebruikt de laatste versie van de code uit het CVS Repository op Sourceforge.net.

OpenID wat kun je ermee

OpenID al veel van gehoord nog nooit wat mee gedaan. Onlangs zag ik dat ik op sourceforge.net ook kon inloggen met een OpenID. Voor wie niet weet wat OpenID is: OpenID is een gedecentraliseerd authenticatiemechanisme om Single Sign-on op het Internet mogelijk te maken. En dat klinkt dan weer als een leuke extra functionaliteit voor Opensourcecms.eu. Bovendien las ik dat Sourceforge.net de implementatie met het Zend Framework had gedaan, wat het nog eens extra interessant maakte.

Eerst maar eens een OpenID identiteit aanmaken, dat had ik kunnen doen door een keuze te maken op Openid.net, eigenlijk bleek ik al een aantal OpenID identiteiten te hebben o.a. via Yahoo. Altijd handig meerdere identiteiten 🙂 Er blijken echter ook twee Nederlandse OpenID-providers te zijn. Logmij.in en Mijnopenid.nl, chauvinistisch als ik ben kies ik daar natuurlijk voor. Logmij.in leek mij eigenlijk het meest interessant, omdat zij een met SSL beveiligde verbinding aanbieden. De .in in de domeinnaam gaf mij echter het gevoel mijn nieuwe identiteit direct aan India te verkopen. Dus gekozen voor Mijnopenid.nl. Registratie was eenvoudig, daarna mijn OpeniD nog bevestigen via een link per e-mail (wel een beetje ouderwets).
De URL van mijn OpenID identiteit luidt nu: http://mijnopenid.nl/is/allop.

Vervolgens terug naar Sourceforge.net, daar de URL opgegeven. Ik
wordt nu doorverwezen naar: http://mijnopenid.nl/

Daar krijg ik de vraag: “Wil je inloggen op https://sourceforge.net?” Altijd /
Eenmalig / Nee

Daarna (altijd gekozen) krijg ik nog de volgende vraag:
De pagina https://sourceforge.net vroeg om extra informatie.

De pagina vroeg de volgende gegevens:
Nickname (allop) (optioneel)
Email (bas@emailcommunications.nl) (optioneel)
Fullname (optioneel) [Wijzig]
Country (optioneel) [Wijzig]
Language (nl) (optioneel)
Timezone (Europe/Paris) (optioneel)

Feitelijk zou Sourceforge.net de koppeling hier al kunnen leggen op basis van mijn e-mailadres, maar dat doen ze dus niet.

Na verzenden kom ik terug op sourceforge.net, waar ik de volgende vraag krijg:

OpenID verified! Please associate your identity
Check our site doc for more information on OpenID.
Existing SourceForge Account
Log in

Username:

Password:

Nadat ik dat gedaan heb, kan ik dus ook inloggen met mijn openidurl.

Op mijnopenid.nl zie ik nu ook staan:

Jouw_sites

* https://sourceforge.net
Trek machtiging in

Kortom het werkt. Was wel veel werk…… en dat alleen om mijn wachtwoord niet te vergeten. Gezien ik altijd “bas” als wachtwoord neem vergeet ik dat ook niet zo snel…….

zie ook: Met OpenID geen wachtwoorden meer vergeten