Enkele maanden nadat we besloten de stap te zetten om Zend Certified Engineer te worden, werd het weer eens tijd voor een nieuwe uitdaging. Logischerwijze viel de keuze ditmaal op MySQL, de toonaangevende open-source database.
Sun (onlangs nog overgenomen door 's werelds grootste database-specialist Oracle), het bedrijf achter MySQL, biedt hiertoe 4 mogelijke certificaten, met name:
Sun Certified MySQL Associate (SCMA)
Sun Certified MySQL Developer (SCMDEV)
Sun Certified MySQL Database Administrator (SCMDBA)
Sun Certified MySQL Cluster Database Administrator (SCMCDBA)
Gezien we bij Netlash steengoeie web-applicaties bouwen, werd uiteraard geopteerd voor het MySQL Developer certificaat, wat bestaat uit 2 examens. De eerste optie (Associate) bevat 1 examen en is eigenlijk eerder een veredelde initiatie. Nummer 3 (Database Administrator) bestaat ook uit 2 examens, maar is dan weer gericht op db-admins. De laatste (Cluster Database Administrator) is een verderzetting van het 3e certificaat, waarvoor 1 extra examen wordt afgenomen.
Studiemateriaal
De heilige graal bij deze onderneming werd - hoe kan het ook anders - het boek "MySQL 5.0 Certification Study Guide", geschreven en gepubliceerd door mensen uit het team van MySQL zelf en specifiek bedoeld voor dit certificaat. Hoe groot mijn ego en zelfvertrouwen ook is: vooraleer ik 2 maal 154 vooruit schuif voor beide examens ben ik toch liever wat voorbereid.
Het boek is in elk geval een must voor elke MySQL ontwikkelaar. Vergelijkbaar met het voorbereidend boek voor het Zend-examen, was dit boek opnieuw eerder een naslagwerk dan een boek om MySQL te "leren". Je wordt dus wel degelijk verondersteld enige ervaring te hebben met MySQL. Veel nieuwigheden heb ik nu echter ook niet bijgelerd, al geef ik toe dat ik bij momenten een Aha-Erlebnis beleefde. De ervaring zat vooral in de kleine details zoals: "maak een auto-incremented column unsigned - de auto-increment gaat toch niet negatief, dus ga je beter voor de hogere positieve limiet."
De examens
Maar toen werd het tijd voor het echte werk: de 2 examens. Eerst maakte ik nog even de overweging of ik al wel meteen beide examens wou doen of deze toch liever op verschillende data deed: ik had namelijk nog enkele hoofdstukken te gaan in het boek. Gezien de eerstvolgende mogelijke afspraak pas ten vroegste 3 weken later kon plaatsvinden, besloot ik er echter ineens volledig voor te gaan en schreef me voor beiden in via Prometric. Tegelijk beloofde het dan ook meteen een lange nacht te worden om nog snel de rest van het boek te doorworstelen, maar dan zou het in elk geval nog vers in mijn hoofd zitten.
En toen was het tijd voor de grote test. De 1u45 "plezier" per examen bleken in realiteit slechts 1u30 te zijn, waarin je - tijdens deze examentijd - nog wordt verwacht de algemene voorwaarden te lezen en te accepteren. Mocht jij dus toevallig die eenzaat zijn die EULA's wel leest, doe dit dan best al even op voorhand, want op het examen tikt de timer lustig verder.
Dit anderhalf uur bleek echter nog steeds meer dan voldoende tijd. De vragen in het examen zijn verzorgd op een 2-tal kleine foutjes na en heel duidelijk uitgeschreven. Op geen enkel moment zal een vraag verwarrend overkomen en het gehalte aan instinkers valt heel goed mee.
Persoonlijk vond ik het examen iets té theoretisch. Daar waar we bij het Zend-examen commentaar hadden dat het handboek ervoor eigenlijk te weinig nauw aanleunt bij het examen, leunt dit boek er juist wel te dicht bij aan: nagenoeg alle vragen lijken rechtstreeks uit het boek te komen. Je moet uiteraard heel goed snappen waarover alles gaat, maar hopen ervaring heb je naar mijn mening ook niet nodig.
Conclusión!
Vanaf heden ga ik dus ook onder de titel "Sun Certified MySQL Developer" door het leven. De eerste momenten klonk het wat raar wanneer mensen me zo nariepen op straat, maar ondertussen lijk ik stilaan gewoon te worden aan al deze nieuwe fans.
Maar even serieus: ik behaalde op examen 1 een score van 80% en op nummer 2 werd dit 72%. Gezien voor beide examens de limiet op 60% ligt, ben ik dus geslaagd! Het bewijs van de vele inspanning en toewijding is nu ook officiëel, wat uiteraard een grote voldoening met zich meebrengt, maar tegelijk is dit voor onze klanten opnieuw een extra garantie van onze kunde, geaccrediteerd door dé autoriteit op dit vlak.
Op vrijdag 11 juni waren we met een groot deel van het team (Karolien, Davy, Dieter, Yoni, Matthias, Stephen, Ad en ikzelf) aanwezig op de dagopleiding rond het Anysurfer Certified-project.
AnySurfer is een kwaliteitslabel voor websites die voor iedereen toegankelijk zijn — ook voor mensen met een functiebeperking.
Het Anysurfer Certified project is een project waarbij webbureaus die de expertise hebben om websites/webapplicaties te bouwen worden opgeleid om websites te bouwen die voor alle bezoekers toegankelijk zijn, ook voor bezoekers met een beperking. Daarnaast kunnen deze websites het kwaliteitslabel halen.
De opleiding
Het eerste deel van de opleiding bestond vooral uit een uitgebreide demo van Bart Simons. Bart is sinds zijn geboorte blind en is dus de perfecte man om ons op een goede manier duidelijk te maken waarop wij moeten letten om websites voor mensen met een beperking toegankelijk te maken.
Bart gebruikt een normale browser, met daarin javascript en flash geactiveerd. De extra tools die hij gebruikt zijn een screenreader en een brailleregel. Tijdens de demo - om het voor ons toegankelijk te maken - heeft hij gelukkig de snelheid van voorlezen op ongeveer de helft van zijn gewoonlijke snelheid gezet, en zelfs dat was voor ons soms heel snel.
Bart toonde aan de hand van enkele goede en slechte websites aan hoe een gebruiker met een beperking een website ervaart. Ik denk dat deze demo voor de meeste mensen de beste manier was om aan te tonen dat je door je verstand te gebruiken en enkele kleine extra aanpassingen de site op een heel eenvoudige manier toegankelijk kan maken.
Na de lunch gaf Roel uitleg bij de vernieuwde checklist (gebasseerd op WCAG 2.0). Er werd bij alle punten voldoende uitleg en/of voorbeelden gegeven.
Roel, zelf kleurenblind, is iemand die gebeten is door het toegankelijkheids-virus. En met veel passie en kennis over ieder punt uitleg kon geven. Aangezien Roel ook zelf websites ontwikkelt kan hij zich makkelijk verplaatsen in de rol van webdeveloper/webdesigner.
Besluit
Heel wat zaken die in de checklist zijn opgenomen zijn een kwestie van gezond verstand en worden al gedaan bij Netlash. Het is ook een kwestie van het gebruiken van standaarden.
Met een heel klein beetje moeite of extra zaken die we default gaan implementeren in Fork kunnen we ervoor zorgen dat onze websites toegankelijk zijn zonder veel extra werk.
Het is ook dat punt dat Roel terecht aanbracht. Een toegankelijke website is niet hetzelfde als "veel extra werk". Bovendien zijn heel wat zaken op de checklist ook een voordeel voor de SEO van je website.
Naast de richtlijnen die specifiek weggelegd zijn voor de designer en developer is een grote verantwoordelijkheid weggelegd voor de redacteurs van de website. Zij moeten zich evengoed bewust zijn van deze richtlijnen en bij het ingeven van content hiermee rekening houden.
Persoonlijk denk ik dat de opleiding een must is voor iedereen die werkt als designer of developer, maar evengoed voor redacteuren en vertegenwoordigers van webbureaus.
Om beter te kunnen inschatten hoe de kleurcombinatie die we willen gebruiken zich zal gedragen in de ruimte maken we schetsen. De combinatie van de antracietkleurige gepolijste betonvloer, het grijs van het plafond en de metalen steunen, het wit/rode meubilair en de rode wand van de balie hebben we hier eens tegenover elkaar gezet.
Een schets vertelt natuurlijk niet alles, maar 't geeft toch al een idee: er mag best wat meer rood in.
In de Online voorspellingen 2010 werd het al uitgebreid aangekaart: het mobiele web wordt dit jaar in België belangrijker en belangrijker.
Ook bij Netlash maken we meer en meer mobiele websites. Uiteraard konden we met onze eigen site niet achterblijven.
Gezien we allemaal enthousiaste iPhone gebruikers zijn, besloten we een eerste vingeroefening specifiek voor de iPhone uit te werken.
De website werkt ook op andere GSM's met een browser gabseerd op Webkit, zoals bvb. de HTC Hero, die op Google's Android OS draait.
Ons standpunt rond mobiele websites is nog niet veranderd: we geloven nog steeds dat websites (die in een mobiele browser draaien) een grotere toekomst tegemoet gaan dan native applicaties. En we zijn er nog steeds van overtuigd dat we 'device-independent' moeten werken — websites moeten draaien op elk toestel. Maar vooraleer we een volledig onafhankelijke mobiele website bouwden, wilden we al eens een eerste test doen met een website specifiek voor iPhone.
Hieronder vind je een paar screenshots. Klik voor de grote versie.
De aannemers op de werf van ons nieuwe kantoor komen op kruissnelheid. Vandaag waren ze in de weer met de isolatie van de vloer en de vloerverwarming. Eind deze maand moet ons deel van de ruimte voorzien zijn van de definitieve gepolijste betonnen vloer.
Vóór het bouwverlof staan de tussenwanden en kunnen we eindelijk in't echt zien wat de ruimte gaat worden. In het najaar volgt dan de verhuis. Eerst zorgen dat de bouw correct verloopt.
Sinds de steile opmars van Facebook (3.2 miljoen Belgische gebruikers op datum van april 2010) krijg ik regelmatig de vraag van bedrijfsleiders en marketing managers: heeft het nog wel zin om een eigen site uit te bouwen? Is het niet beter om al onze pijlen te richten op Facebook - daar zit ten slotte een groot publiek!
Da's een beetje een omgekeerde redenering. Het klopt dat er heel veel mensen op Facebook zitten; maar er zitten nog meer mensen op het web in het algemeen. Het is niet omdat je een Facebook fanpagina of groep hebt (Niet zeker welk van beide je wilt? Lees dan zeker het artikel Facebook: groep of fanpagina op het blog van partner Talking Heads.) dat er plots heel veel vrienden of fans zullen opduiken - of zelfs maar dat er veel bezoekers zullen zijn. Net hetzelfde als bij een website: het is niet omdat je een site hebt, dat er veel bezoekers zullen komen.
De mechanismen om bezoekers naar je Facebook pagina te krijgen zijn anders dan die van een gewone website; en het klopt dat sociale netwerken een groot deel van die mechanismen ingebouwd en vergemakkelijkt hebben (het "deel met je vrienden" aspect).
Maar zowel voor een website als voor een Facebook pagina zal je tijd/energie/geld (ze zijn soms onderling inwisselbaar) moeten stoppen in het opbouwen van een publiek.
Bovendien is er nog een ander, groter gevaar. Sociale netwerken zijn net als de newest hottest club in town. Vandaag is deze ene club zeer 'in', en wil iedereen naar die club gaan. Maar morgen gaat iedereen naar die club, en is hij plots niet meer 'in' - en begint iedereen naar de volgende uit te kijken. Dit is exact wat er met MySpace gebeurd is. Een drietal jaar geleden was MySpace dé plaats om aanwezig te zijn; momenteel is dit in België zo dood als een pier, en is iedereen overgeschakeld naar Facebook of Netlog.
Het blijft dan ook een strategisch risico om al je eieren in één mand te leggen en je volledige online bedrijfsaanwezigheid op een sociaal netwerk te zetten - een sociaal netwerk waarvan je de levensduur, populariteit of zelfs maar de functionaliteiten niet zelf onder controle hebt.
Wat uiteraard niet wil zeggen dat je de kracht en aantrekking van sociale netwerken dient te negeren.
De visie van Netlash is dan ook: bouw je eigen website uit als een centrale hub, en gebruik andere online middelen, zoals sociale netwerken, maar ook e-mail marketing en campagne-websites als aandrijvers van duurzame trafiek.
De kracht van sociale netwerken als Facebook, Netlog, Twitter en LinkedIn is inderdaad net dat daar het sociale aspect ingebouwd zit; mensen kunnen heel makkelijk informatie doorsturen naar hun netwerk.
In mijn ogen is het dan ook belangrijk om twee dingen te doen:
Een aanwezigheid op de relevante sociale netwerken te hebben.
Een integratie op je eigen website te hebben van de relevante sociale netwerken.
Je moet zeker als bedrijf aanwezig zijn op sociale netwerken. Uiteraard maak je daar een keuze in: het is onmogelijk om op elk netwerk even actief aanwezig te zijn. Identificeer dié plaatsen waar jouw doelgroep aanwezig is. Zorg dat je minstens je profiel daar geclaimed hebt - en draag er zorg voor dat alles in jouw profiel doorlinkt naar je eigen website. Op de minder belangrijke netwerken zorg je voor automatische inhoud: laat daar de technologie voor jou werken, gebruik bijvoorbeeld de automatische import van RSS-feeds vanuit je eigen blog. Op de belangrijkste netwerken zorg je voor een eigen stem, met communicatie die afgestemd is op dat netwerk en op die doelgroep.
(Zoals steeds is het daar belangrijk om de ROI van je online strategie af te wegen. Elke aanwezigheid zal inspanningen kosten; elke gepersonaliseerde aanwezigheid zal nog meer inspanningen kosten. Je moet afwegen of je bedrijf daar de nodige middelen voor kan vrijmaken, en of die kost opweegt ten opzichte van het rendement.)
Zo zorg je voor een instroom vanuit sociale netwerken naar je eigen website; en maak je maximaal gebruik van de sociale mogelijkheden van die netwerken.
Omgekeerd bouw je best ook de mogelijkheden van die sociale netwerken in je eigen website in. Je moet faciliteren dat bezoekers de inhoud die op je eigen website verschijnt kunnen doorsturen naar hun eigen netwerken; zodat ze die niet zelf moeten gaan transporteren.
Zo creëer je een feedback loop tussen je eigen website en de rest van het internet.
De tijd dat een website een afgezonderd, op zichzelf staand eiland op het wilde internet was, is definitief voorbij. Het membraan tussen jouw site en het internet moet zo transparant mogelijk worden.
Maar tegelijkertijd moet je realistisch zijn en beseffen dat jouw eigen website het centrum van je online strategie moet blijven.
Eén van de vier kernwaarden bij Netlash is innovatie: we ambiëren om vandaag online dié dingen te doen die binnen drie jaar bon ton zijn. Dat houdt ook in dat we nadenken over de toekomst van computers - en we zien de mogelijkheden en potentie van touch screen tablets, met als exponent de iPad, als zeer beloftevol. Aangezien één van onze focuspunten informatie-architectuur en interaction design is, willen we ook op de iPad daarmee experimenteren.
Vandaar dat we samen met onze klant Broken Frontier een eerste iPad app uitgewerkt hebben: The Frontiersman.
Uit het persbericht: "The Frontiersman is het eerste digitale magazine over comics op de iPad. The Frontiersman is een publicatie van comics nieuwssite Broken Frontier en werd ontwikkeld in samenwerking met webbureau Netlash. The Frontiersman verschijnt wekelijks op dinsdag. The Frontiersman covert alle aspecten van de comics universe, van mainstream tot onafhankelijke uitgevers, van digitale comics tot comics op het grote scherm. Wij brengen een gezonde mix van van interviews, diepgaande artikels en exclusieve previews van top artiesten."
We zien dit als een eerste verkenning van de mogelijkheden van de iPad, en willen hierop verder gaan.
Zelf aan het nadenken over publiceren op de iPad? Contacteer ons, we denken graag mee.
Voor de comics liefhebbers onder jullie: de eerste editie van The Frontiersman heeft interviews met Mark Millar en John Romita, Jr. over Kick-Ass, Paul Gravett over Tove Jansson’s Moomin exhibition, en Jonathan Hickman over S.H.I.E.L.D. Je kan het magazine ook downloaden als pdf op de website van Broken Frontier.
Dit examen is een erkende PHP-onderscheiding die wordt uitgereikt door Zend - The PHP Company. Het test de kennis van PHP en de real-life ervaring van de kandidaat. Op dit moment zijn er in België 75 mensen die zichzelf PHP5 Zend Certified Engineer mogen noemen.
Omdat niemand graag onvoorbereid naar zo'n examen gaat hebben we eerst wat meer informatie ingewonnen en een test-examen afgelegd. De manier van vraagstellen tijdens het test-examen is dezelfde als die op het uiteindelijke examen, namelijk 70 vragen waarvoor je 90 minuten de tijd krijgt.
Er zijn verschillende soorten vragen:
meerkeuze met 1 correct antwoord
meerkeuze met meerdere correcte antwoorden (het aantal staat steeds vermeld)
invulvragen
De eerste kennismaking met het test-examen was voor mezelf zeer aangenaam. Na een kleine 45 minuten was ik klaar en behaalde ik een mooie score: Excellent.
Na deze eerste kennismaking met het test-examen hebben we (Davy, Matthias, Tijs) besloten om er volledig voor te gaan. De juiste zaken (practice-exam-vouchers, boek en exam-vouchers) werden aangekocht. Met deze zaken in handen zijn we begonnen ons verder voor te bereiden.
Voorbereiding
Als we het boek mogen geloven dan is het boek de ideale voorbereiding op het examen. Het boek behandelt alle topics die terugkomen in de test-examens, van de basis van PHP over OOP tot Security. Het boek is zeker geen beginnerstutorial, in een aantal hoofdstukken gaat men heel specifiek te werk.
Om heel eerlijk te zijn heb ik uit het boek heel weinig bijgeleerd — dat is ook niet de bedoeling van het boek — het was eerder een herhaling en bevestiging van wat ik al wist.
Om onszelf toch voor een deadline te stellen hadden we het examen vastgelegd op 2 april. Door de deadline werd de druk om goed voorbereid te zijn nét iets hoger. Na het boek volledig doorgenomen te hebben, deden we allemaal nog een aantal tests. Hierdoor kan je zien op welke topics je harder moet werken. Voor mij was het pijnpunt "Streams & Network-programming".
Test-examens
De test-examens zijn van een redelijk niveau. Er zijn een aantal vragen die gemakkelijk onder de noemer instinkers kunnen gecatalogeerd worden. Bijvoorbeeld een stuk code met daarin een syntax-error, maar bij de antwoorden staat het resultaat dat de code zou reproduceren indien er geen syntax-error was.
Sommige vragen gaan dan weer over een specifieke functie, een eenvoudig voorbeeld: Welke functie gebruik je om de waardes binnen een array op te tellen?1
Het examen
Op vrijdag 2 april zijn we dus afgezakt naar het examencentrum van DevoTeam. Na enkele omzwervingen in Brussel hebben we uiteindelijk het correcte gebouw gevonden (recht over de ingang van paleis 11 aan de heizel - Google Maps).
Uiteraard waren we daar — zoals het hoort — te vroeg, en kregen we dus de kans om in de lobby nog een beetje te herhalen. Om 09u30 hebben we onszelf aangemeld, maar er waren wat problemen met hun intern netwerk, dus ons examen zou iets later plaatsvinden.
Maar na een uurtje konden we toch beginnen. We werden aangemeld op een computer en zijn gestart met het examen.
Het werd een zenuwslopende sessie, de vragen waren toch een pak specifieker dan verwacht. Net zoals de test-examens krijg je 90 minuten om de 70 vragen te beantwoorden.
Ikzelf heb eerst alle vragen waarvan ik zeker was opgelost, de vragen waar ik minder zeker van was heb ik gemarkeerd for review. Na de 70 vragen krijg je een overzicht met daarop aangeduid welke vragen je nog moet beantwoorden (incomplete) en vragen die je gemarkeerd hebt. Ik heb eerst de onbeantwoorden vragen nagekeken en opgelost. Erna heb ik de vragen die ik gemarkeerd heb nog eens goed nagekeken.
Als laatste heb ik dan alle vragen nog eens nagekeken, daarna heb ik met een klein hartje op de knop "End Exam" geklikt. Een aantal hartkloppingen later krijg je het resultaat te zien. In tegenstelling tot de test-examens krijg je geen feedback per topic maar enkel de melding of je al dan niet geslaagd bent.
Maar ikzelf heb er toch een aantal bedenkingen bij. Naar mijn mening zijn de vragen op het examen een pak specifieker en dus moeilijker dan de test-examens. Enkel het boek instuderen zal je zeker geen garantie bieden om te slagen. Je hebt echt real-life ervaring nodig en je moet een verdomd goede kennis hebben van heel specifieke functies.
Maar goed, we zijn alledrie geslaagd en kunnen dus met trots zeggen dat er sinds 2 april 3 Zend Certified Engineers bij Netlash werken.
Tips
Wil je zelf ook deelnemen aan het examen, dan kunnen onderstaande tip zeker van pas komen:
Zorg ervoor dat je ervaring hebt en dit op alle topics van het boek. Een website maken voor je nonkel zal niet genoeg zijn.
Denk niet dat het enkel over code gaat, bekijk dus zeker en vast eens php.ini en begrijp wat daarin staat.
Zorg dat je het concept van by-value en by-reference goed beheerst.
Op Barcamp Antwerpen gaf Tijs Vrolix een presentatie getiteld “10 reasons why now is the perfect time to get serious about the mobile web”. Je kan de slides van deze presentatie bekijken op SlideShare). Het was een erg interessante presentatie, die me tot nieuwe gedachten heeft geleid omtrent een strategie voor het mobiele web.
Eerst even een schets van mobile development vandaag.
Het probleem met het mobiele web is dat er duizend en één verschillende devices en browsers zijn. Als je wil dat je mobiele website op elk platform werkt, ga je ervoor moeten zorgen dat je alle devices kan testen.
Je gaat een heleboel verschillende types GSM’s aankopen, sukkelen met mobiele abonnementen (of erger: de SIM kaart telkens verwisselen). Je gaat helemaal gefrustreerd worden door de browser inconsistenties, en nog veel meer door het onkunnen van de oudere apparaten.
Er is het Symbian platform, er is de iPhone, er zijn Blackberries en er is Android. Dan heb je nog de high end telefoons van Nokia, en de tig verschillende versies van Windows Mobile. En dan hebben we het nog maar enkel over smartphones gehad. Als we even tellen heb je dan al minstens 6 emulators en fysieke devices nodig.
Dan krijg je een testing setup die er ongeveer zo uit ziet:
(En dat was dan nog voor een project dat slechts op 4 platformen moest werken)
Het goede nieuws: er is beterschap op komst.
De nieuwere toestellen evolueren bijna eenduidig in dezelfde richting: een device dat het internet toont zoals het bedoeld was.
Deze evolutie is vooral te danken aan het gebruik van de open source browser Webkit. Deze browser wordt omarmd door zowel Apple, Google, RIM (Blackberry) en Palm.
Een andere grote factor in die eenduidigheid is schermresolutie en form factor: bijna alle toestellen zijn, met de iPhone als grote voortrekker, een stuk glas van 3,5”, met een resolutie van 320px op 480px of hoger.
Kijk even naar deze grafiek, uit een onderzoek van Morgan Stanley:
Klik voor een grotere versie.
De iPhone en Android tesamen zijn verantwoordelijk voor bijna drie kwart van de pageviews; terwijl ze slechts 13% van de markt bezetten.
Internet op mobiele telefoons bestaat al een tijdje, maar eigenlijk gebruikte bijna niemand het. Heel kort door de bocht, het mobiele internet 3 jaar geleden: zakenmannen die e-mails binnenhalen op hun dure Blackberry of HTC.
Nu zijn er betaalbare smartphones waarop het internet bruikbaar geworden is, en mensen internetten er ook effectief op. Je neefje loopt rond met een Android telefoon en zijn zus heeft een iPhone.
Ook een factor: we hebben een goed netwerk in België: er is nagenoeg overal EDGE en 3G coverage. De netwerken worden elk jaar beter. Providers pushen het mobiele internet.
Ik zei in het begin van dit artikel: “Het probleem met het mobiele web is dat er duizend en één verschillende devices en browsers zijn.”.
Dit probleem is zichzelf aan het oplossen.
Er zijn voor mij namelijk nog maar 2 soorten smartphones over:
Toestellen in staat om het internet weer te geven zoals je dat kan op een desktop
Toestellen niet in staat om het internet weer te geven zoals je dat kan op een desktop
En mobile development wordt:
De eerste categorie toestellen krijgt de normale site
De tweede categorie toestellen krijgt de normale site in tekstvorm: enkel HTML, geen CSS, geen Javascript
Deze scheiding maken noem ik de forward thinking strategie voor het mobiele web. In deze strategie ga ik er van uit dat devices evolueren naar wat de iPhone nu is, en dat we binnenkort allemaal een smartphone hebben. Ik ga er ook van uit dat diegene die geen smartphone hebben, ook niet geïnteresseerd zijn in mobiel internetten.
Weg dus met dertien versies van een mobiele website te bouwen: bouw één versie, volgens de webstandaarden, en serveer een tekst-only versie aan de toestellen die minder kunnen.
(Ik ben er eigenlijk zelfs van overtuigd dat een HTML only een betere gebruikservaring zorgt op, zeg maar, een Nokia N95, of een HTC Diamond)
Net zoals in accessibility de praktijk om twee versies van een site te maken (één gewone, en één “toegankelijke”) achterhaald is geworden door betere standaarden en betere webbouwers - zo zal het idee om twee versies van een site te maken (één gewone, en één mobiele) nutteloos gemaakt worden door betere browsers, grotere schermen op mobieltjes, en beter onderlegde webbouwers.
Dit klopt: de praktijk om twee versies van een website te maken is achterhaald. We volgen de webstandaarden, en de sites die we maken werken de facto op de mobiele toestellen.
Maar: mobiel kan nog zoveel meer zijn dan een normale website.
Met de evolutie in de mobiele wereld in het achterhoofd, is het ondertussen realistisch geworden om een mobiele website te maken die effectief meerwaarde biedt.
Een mobiele versie van je site zal makkelijker lezen:
Je kan de focus leggen die mobiel relevanter zijn. Op de homepage van de mobiele Netlash website staat bijvoorbeeld een rechtstreekse link naar Google Maps, voor mensen die ons kantoor zoeken. En er staat een link waarmee je rechtstreeks kunt bellen, zonder het nummer in te moeten tikken.
Ik geloof, net als Tijs, dat 2010 effectief het jaar van het mobiele web wordt.
In onze webapplicaties - zeker diegene met eencommunity - worden er heel wat mails verzonden, om de mails herkenbaar te maken zijn deze opgemaakt met behulp van HTML en CSS.
Enkele mailclients (zoals bijvoorbeeld GMail) strippen deze CSS uit de HTML, hierdoor krijg je dus minder leesbare mails, de oplossing hiervoor is om de CSS voor ieder element in het style-attrribute te plaatsen. Hier zijn wel een aantal nadelen aan verbonden.
Onderhoudbaarheid, wat als iedere link een andere kleur moet krijgen?
Veel werk voor de designer, elk element moet voorzien worden van specifiek styling.
Wat als de inhoud niet vaststaat, maar door de gebruiker via het CMS ingegeven is?
Wel, nu is er een handige PHP-class die de CSS-styling gaat omzetten naar inline-styling.
De meeste mensen en bedrijven die websites bouwen zijn er een beetje ingerold - vanuit een ander beroep of een andere expertise. (Ikzelf ben, in een ver verleden, afgestudeerd als boekhouder...) Normaal eigenlijk, want in de jaren '90 bestonden er geen opleidingen tot webbouwer.
De twee belangrijkste instromen kwamen vanuit twee tegenovergestelde richtingen: langs de ene kant de designers, die ervaring hadden in vormgeven voor drukwerk of voor andere digitale media; langs de andere kant de developers, die ervaring hadden in het programmeren.
Die erfenis slepen veel webbureau's nog altijd mee. Ofwel hebben ze een zware technische insteek (en huren ze dan free-lance designers in), ofwel vertrekken ze vanuit de vormgeving (en gebruiken standaard technologie om dat te laten werken).
Ik ben er van overtuigd dat een website bouwen een geïntegreerd proces is, waar verschillende expertises samen moeten werken naar een goed eindresultaat. (Over die webdesign profielen heb ik het vroeger al gehad.)
Een goede website is een samenspel tussen technologie, design, usability en marketing. Die vier factoren zijn even belangrijk en moeten alle vier evenveel gewicht krijgen. En elk van die vier vraagt een eigen specialisatie. (Die vaak tegengesteld is - zoals het bon mot gaat: designers zijn van Venus, developers zijn van Mars.)
Het is juist uit de discussie tussen die vier, soms zelfs de ruzie, dat er iets moois komt.
Dit is het model waarbinnen we bij Netlash werken:
Centraal in elk project staat onze klant. Meestal werken we daar samen met de marketing manager, of communicatieverantwoordelijke. (In KMO's, waar we ook heel veel voor werken, is dat vaak de zaakvoerder zelf.)
We vertrekken altijd van de bestaande marketingstrategie van onze klant. Het is onze klant (of zijn marketing manager) die het beste het bedrijf, de doelstellingen, de doelgroepen en de strategie van het bedrijf kent.
Daarnaast zijn er drie soorten Netlash-medewerkers betrokken bij het project, elk met hun eigen expertise: een webdeveloper, een webdesigner en een informatie-architect. (Zie: Wie is wie bij Netlash.)
De developer zorgt voor de juiste technische uitvoering; de designer voor een vormgeving die de doelstellingen van de site ondersteunt. Ondertussen zet de informatie-architect de krijtlijnen van het concept uit, én bewaakt hij tijdens het hele proces de bruikbaarheid (hij is als het ware de 'verdediger' van de eindgebruikers van de site).
Dit wordt gecoördineerd door een project manager: die verzorgt de communicatie tussen het team en de klant, en is verantwoordelijk voor de bewaking van scope, timing en budget.
Elk van die mensen is cross-disciplinair. Een moeilijk woord, om te zeggen dat ze ook over het muurtje durven kijken. Iedereen moet minstens vlekkeloos html/css kunnen hanteren - of ze nu developer, designer of IA zijn. Naast hun eigen expertise moeten ze ook feeling hebben voor de andere aspecten: ik verwacht van een programmeur dat hij mee nadenkt over de bruikbaarheid, en dat de informatie-architect een bepaald gevoel voor esthetiek heeft.
Het is juist door die verschillende experten bij elkaar te zetten en ze nauw met elkaar te laten communiceren (in een aangename omgeving) dat er een evenwichtig en effectief eindresultaat komt.
Zo'n geïntegreerd webbureau zal volgens mij altijd voorsprong hebben op losse samenwerkingsverbanden (op voorwaarde dat het klein genoeg blijft om zijn flexibiliteit, snelheid en innovatie te bewaren).
Op 16 en 17 februari ging in Parijs de eerste internationale Symfony conferentie, Symfony Live 2010, door. Symfony is een web PHP framework dat als doel heeft om complexe webapplicaties sneller te bouwen en het onderhoud van deze applicaties beter en gemakkelijker te maken.
Bij Netlash maken we geen gebruik van symfony, maar ik heb de laatste maanden wel een sterke persoonlijke interesse voor dit framework. En het is heel interessant om de evoluties en denkpatronen te volgen in andere communities.
De conferentie was goed georganiseerd en ging door in een mooie conferentiezaal in het Cité Universitaire. Het was een groot succes met 350 aanwezigen. Er waren heel wat interessante presentaties over Doctrine, het gebruik van Zend Framework componenten en het gebruik van Git als Version Control System. Ik heb wel een beetje de technische voorbeelden en 'best practices' gemist over Symfony zelf. De presentaties die hierover gingen misten een beetje diepgang.
Het hoogtepunt van deze tweedaagse was de preview release van Symfony 2. Het meest opmerkelijke hierbij is het (nog meer) opzij schuiven van eigen ontwikkelde stukken code en het gebruik maken van onderdelen uit het Zend Framework (Zend_Log en Zend_Cache). Hiermee volgt Symfony verder z'n visie "Don't reinvent the wheel". Deze presentatie van Fabien Potencier kan je bekijken op Slideshare:
Al bij al een heel gezellige conferentie die heel duidelijk de mooie community rond Symfony in de verf zette. Alle presentaties en de reacties van de aanwezigen kan je nalezen op Joind.in.
Voor het versturen van e-mails in een privé-project had ik een functie nodig die een HTML-mail kon omvormen naar een plain text mail. Meestal wordt dit gedaan door simpelweg de PHP functie strip_tags op de HTML-mail los te laten. Dit geeft echter problemen als je bijvoorbeeld -style- tags in je code staan hebt. De strip_tags functie zal de begin- en eindtags wel 'strippen' maar zal alles ertussen laten staan. En een plain text mail met p { font-size: 12px; } en dergelijke in is nu niet echt proper. Daarom heb ik dus de functie getPlainText gemaakt.
// replace break rules with a linefeed and make sure a paragraph also ends with a new line Hier gaan we dus -br- tags vervangen door enters. En aangezien paragrafen ook moeten gescheiden worden van elkaar en meerdere paragrafen in de html op 1 regel kunnen staan zorgen we ervoor dat deze al in html vorm op verschillende lijnen staan.
// remove tabs De tabs die door indentatie in de html-code staan mogen in de plain-text versie ook verwijderd worden.
// remove the head- and style-tags and all their contents De reden waarom deze functie geschreven is. De strip_tags functie van php zal enkel de start- en eind-tags van deze elementen verwijderen, waardoor alles dat tussen deze tags staat behouden blijft. Door een preg_replace te doen van deze html-tags en hun inhoud is dit probleem opgelost.
// replace links with the inner html of the link with the url between () Indien je de parameter $includeAHrefs niet overschrijft met de waarde false zal deze regel de links in de html vervangen door de html die binnen de link staat met daarachter de url tussen haakjes. Dit zorgt ervoor dat links in je html-document niet verloren gaan, wat wel het geval is bij strip_tags.
// replace images with their alternative content Hetzelfde voor de afbeeldingen. Deze regels zal de afbeelding vervangen door de alt parameter van het img-element.
// strip tags En nu pas laten we de strip tags functie los op de tekst.
// replace 'line feed' characters with the 'carriage return/line feed' character pair We vervangen de line feeds of "
" karakters door het carriage return line feed paar zodat volgende regel kan uitgevoerd worden.
// replace double, triple, ... line feeds to one new line Deze regel zorgt ervoor dat de overbodige witregels in de tekst vervangen worden door 1 witregel.
// decode html entities Deze regel zal html entiteiten zoals é vervangen door hun plain text waarden (in dit geval dus é) door middel van de Spoon functie htmlentitiesDecode. Voor meer info over Spoon kan je terecht op spoon-library.be. Als je niet met Spoon werkt kan je hier natuurlijk ook altijd de standaard php functie html_entity_decode gebruiken.
Een voorbeeld:
Als voorbeeld wou ik de Netlash nieuwsbrief van 21 januari even door deze functie halen.
We hebben hier bij Netlash wel al een aantal webprojecten afgewerkt. Door de jaren heen is er een bepaalde systematiek uitgekristaliseerd - een manier van werken, een stappenplan, waarvan we ondertussen weten dat dit de goede manier is om een website tot stand te laten komen.
In dit artikel wil ik deze methodiek met jullie delen, en jullie feedback daarop vragen (want alles kan altijd beter, niet?).
De stappen die we nemen zijn er met een goede reden. Zie het bouwen van een website als het beklimmen van een berg. Ja, je kan zonder zekeringen helemaal naar boven klimmen. Maar toch zal je beter op regelmatige intervallen een haak in de bergwand slaan om je musketon vast te maken. Als je niet gevallen bent, bij het naar boven klimmen, heb je inderdaad een hele hoop extra en overbodig werk gehad met die musketons. Maar als je wel mistrapt en valt, zorgen de borgen ervoor dat je maar een kleine afstand opnieuw moet omhoogklimmen - en niet de dodelijke val over de volledige diepte meemaakt.
Vandaar dit proces. Een aantal van de stappen lijken overbodig, maar ze zorgen wel voor een constante kwaliteitsgarantie over projecten heen.
0. Voorbereiding
Na de eerste prospectiegesprekken wordt de prospect meestal onze klant. We starten met een beetje administratie: zorgen dat de afspraken rond facturatie goed gemaakt zijn, en een duidelijke planning. Op de stappen die hieronder volgen wordt een datum gekleefd, zodat zowel onze klant als wijzelf duidelijk weten wanneer wat van ons verwacht wordt.
Tegelijkertijd sturen we al een eerste vragenlijst door (voer voor een andere blogpost) rond inhoud en vorm.
1. Analyse
De eerste echte stap is heel eenvoudig samen te vatten: 'goed nadenken'.
Mijn vader zei me altijd: "Beter twee keer meten en maar één keer zagen - da's efficiënter". Wel, da's ook zo bij het bouwen van websites.
Dit is vooral praten. Praten met onze klant: hoe zit zijn bedrijf of organisatie in elkaar, wat zijn de doelgroepen, wat is de doelstelling van de site?
We doen dit in eerste instantie met een echte kick-off meeting. Daarin overlopen we met onze klant nog eens de zaken uit de voorbereidingsfase - en vragen we hem de pieren uit zijn neus over zijn bedrijf of organisatie.
Typisch verzamelen we al die informatie in een mindmap; zo kunnen we onze gedachten op een gestructureerde manier ordenen.
Hier worden ook de functionele vereisten van de website verzameld: wat moet de site doen, op welke manier? Je kan dit gerust een functionele analyse noemen.
2. Informatie-architectuur
Die verzamelde informatie - hoe geordend of chaotisch ook - gaan we structureren, hiërarcheren, labelen. Dit heet informatie-architectuur.
We bouwen al een eerste ruwe versie van de site in html - wat wij een structuurdocument noemen. Dit is een lege versie van de site: zonder layout, zonder functionaliteit, vaak ook zonder afgewerkte teksten.
We zouden dit op papier (of in Powerpoint of in Visio of ...) kunnen doen (en vaak doen we dat ook eerst); maar een klikbare versie legt de flow doorheen de site bloot. Als je effectief van pagina naar pagina kan klikken via werkende links, voel je hoe de site in elkaar zit, en waar de 'kleine haperingskes' zitten.
Je voelt hoe het klikt.
Dit is een iteratief proces: op basis van de informatie die we verzamelden, maken we een eerste voorstel, en zetten dat online voor onze klant. We vragen feedback, sturen bij, leveren een nieuw voorstel op, vragen feedback... tot het goed zit.
Dit is de belangrijkste fase in het hele proces.
Vergelijk het met het bouwen van een huis: vooraleer je begint te metselen, teken je toch eerst een plan? Dit structuurdocument is het architectuurplan van de website.
Na goedkeuring van het structuurdocument starten we met de layout-fase.
We vertrekken hiervoor vanuit de wensen van de klant. In de voorbereidende fase vroegen we hem een like/dislike lijst: een lijst van andere websites die hij visueel goed vind (en waarom) of niet goed vind (en waarom).
Daarnaast gebruiken we ook het aangeleverde huisstijlmateriaal. We hebben al het volledige spectrum meegemaakt: van 'er is helemaal niets, doe maar' tot 'hier is onze 260 pagina's tellende huisstijlgids'.
Onze designers beginnen altijd met schetsen, op papier. Ze baseren zich daarbij op het bovenstaande structuurdocument:
Die eerste ruwe schetsen worden verder verfijnd en uitgewerkt:
Daarna beginnen we aan het eerste ontwerp in Photoshop. We starten daarvoor met een binnenpagina - wat wij het 'werkpaard' noemen. (Het 'werkpaard' is die pagina die zonder extra ondersteuning al het harde werk moet doen: overbrengen van betekenis.)
Deze fase (eerste echte ontwerp in Photoshop) dient om de stijl van de site vast te leggen. Het is niet de bedoeling om hier alle details al vast te leggen. Wel om onze klant een gevoel te geven van hoe de site er zal uitzien. Vertrekkend van dit eerste ontwerp zullen de webdesigners dan extrapoleren naar andere pagina's.
Het gaat dus over de grote layout-lijnen. Vandaar dat we niet met de homepagina starten - de binnenpagina, de inhoudspagina zal veel meer van deze layout-lijnen blootleggen.
Ook dit is een iteratief proces: we leveren een eerste voorstel, vragen feedback, sturen bij...
Als die algemene stijl goedgekeurd is, werken we ook de andere pagina's uit: de homepagina, een blogpagina, een contactformulier...
4. Slice
Deze goedgekeurde Photoshop documenten worden uitgewerkt in html/css templates.
Ze worden opgemaakt volgens onze interne normen, en klaargezet om geïntegreerd te worden in ons CMS.
5. Development
Ondertussen zijn de webdevelopers al druk bezig om de functionaliteit die op maat moet geprogrammeerd worden uit te werken. Ze baseren zich daarbij op de functionele analyse uit stap 1 en het structuurdocument uit stap 2.
We hebben al heel veel veelgevraagde functionaliteiten uitgewerkt als standaard modules voor Fork CMS; maar tegelijkertijd geloven we dat elke site maatwerk vraagt.
Die maat-functionaliteit wordt dus uitgewerkt in nieuwe Fork-modules.
6. Integratie
De structuur, het design, en het programmeerwerk worden geïntegreerd in het Content Management Systeem, Fork dus.
Als we ons werk in de vorige stappen goed gedaan hebben, staat hier een werkende website die voor 90% goed zit.
7. Testen
Het spreekt vanzelf dat we dit uitgebreid testen; we leveren ook een testversie op aan onze klant zodat ook hij kan testen.
Onze klant moet uiteraard niet testen of het werkt (dat is onze job) - wel of alles er in zit, of alles op de juiste plaats zit, of we alles goed begrepen hebben...
Maar zoals gezegd, door de stapsgewijze aanpak waarbij de klant op elk moment mee stuurt, zal dit een quasi afgewerkte site zijn.
8. Content
Als alles aan beide kanten uitvoerig getest is, leveren we de site op.
Dat is het moment waarop onze klant inhoud in het CMS kan plaatsen. Ik 'eis' meestal van mijn klanten dat ze effectief zelf in het CMS werken - zo leren ze het kennen, en als er nog vragen of kleine wijzigingen opduiken dan kan dit nu, en niet als de site live is en de ganse wereld zit mee te kijken.
Op dat moment kan de klant niet alleen de teksten aanpassen, maar ook de beelden.
De website wordt op de definitieve server geplaatst (en nog eens getest, om verrassingen te voorkomen), maar voorlopig onder een niet-definitieve URL.
9. Live
Als alle inhoud geplaatst is, kan de website live gaan. We koppelen dan de definitieve URL aan de server.
Vanaf dat moment kan de klant die site volledig zelf beheren. Om het met een overdrijving te zeggen: na afloop van het proces wil ik die klant niet meer zien. Dit is uiteraard niet waar; maar voor dagelijkse aanpassingen moeten onze klanten volledig zelfstandig met het Content Management Systeem kunnen werken. (Als voor elke dt-fout een klant naar zijn webbureau terug moet, creëert dit alleen maar frustratie. Het webbureau moet dit inplannen, de klant wil dit onmiddellijk; het webbureau moet dit factureren, de klant wil dat gratis... Vandaar is een flexibel en uitgebreid CMS levensnoodzakelijk.)
Uiteraard ondersteunen we op elk moment onze klant; en staan we klaar voor functionele wijzigingen of uitbreidingen van de site - dan start dit proces opnieuw.
We volgen elk project op met een support-periode: een aantal weken na oplevering dat we die site met de loep mee volgen - zodat we snel kunnen ingrijpen mochten er bugs opduiken of als er kleine wijzigingen nodig zouden zijn.
Als onze klant dat wil (meestal enkel bij grotere projecten), bouwen we dit structureel in met een onderhoudscontract.
Dit zijn dus de stappen die we volgen bij het uitbouwen van onze websites. Nogmaals in een grafiek gegoten:
De verschillende stappen na elkaar in een slideshow tonen het onstaansproces van zo'n site:
We hebben ondertussen geleerd dat de stappen in dit proces nodig zijn. Als we er één overslaan, betekent dit heel vaak problemen of frustratie verder op de lijn.
Dit betekent niet dat we een maand afgezonderd in een hokje gaan zitten met een koude pizza en een fles cola - onze klant stuurt op elk moment mee. We spelen als het ware ping-pong met hem.
Het gevolg is dat we net zo veeleisend zijn voor onze klanten als we zijn voor onszelf. Maar dat is de enige manier om tot een goed eindresultaat te komen.
Zo, da's de korte samenvatting van ons webdesign proces. Hebben jullie feedback? Hoe verloopt het bij jullie? Hoe zouden jullie dit proces verbeteren?
Queries optimaliseren, veel developers zien het als een straf. Het kan nochtans eenvoudig zijn, maar zoals bij alles moet je eerst begrijpen wat er gebeurt vooraleer je kan gaan ingrijpen.
Om te begrijpen hoe MySQL een query behandelt kan je het EXPLAIN-statement gebruiken. Met behulp van dit statement kom je heel wat te weten.
Een voorbeeld:
EXPLAIN SELECT d.id, d.profile_id, ... FROM designs AS d INNER JOIN templates AS t ON d.template_id = t.id INNER JOIN profiles AS p ON d.profile_id = p.id WHERE d.active = 'Y' AND d.offline = 'N' AND d.template_id > 0 AND (d.date_expire IS NULL OR d.date_expire > NOW());
Als resultaat krijg je iets zoals hieronder:
id
select_ type
table
type
possible_ keys
key
key_ len
ref
rows
Extra
1
simple
t
range
primary
primary
4
null
4
Using where; Using index
1
simple
d
all
null
null
null
null
585
Using where
1
simple
p
eq_ref
primary, idx_id_active
primary
4
db.d. profile_id
1
Using index
In deze tabel zijn er verschillende kolommen met elk hun eigen betekenis, hieronder bespreken we de relevante kolommen. Meer informatie over alle kolommen kan je terugvinden op dev.mysql.com.
select_type
Het gebruikte SELECT-type. Mogelijke waardes zijn:
SIMPLE
Zoals het woord als zegt: een eenvoudige SELECT.
PRIMARY
Omringende SELECT-query.
UNION
Tweede of laatste SELECT in een query die gebruik maakt van UNION.
DEPENDANT UNION
Tweede of laatste SELECT in een query die gebruikt maakt van UNION en afhankelijk is van de omringende query.
UNION RESULT
Resultaat van de UNION.
SUBQUERY
Eerste SELECT in de subquery.
DEPENDANT SUBQUERY
Eerste SELECT in de subquery en afhankelijk van de omringende query.
DERIVED
Afgeleide tabel (maw: er staat een subquery in de FROM-clause).
UNCACHEABLE SUBQUERY
Subquery waarvan iedere rij moet worden geherevalueerd.
UNCACHEABLE UNION
Tweede of laatste SELECT in een query die gebruikt maakt van een UNION in de subquery.
table
De gebruikte tabel.
type
Het type van JOIN, er zijn verschillende waardes mogelijk.
De verschillende types worden hieronder aflopend gesorteerd. De volgorde van de MySQL manual wordt gerespecteerd, en deze omschrijft de volgorde als 'gesorteerd van het beste type naar het slechtste'. In de praktijk is deze volgorde niet van 'snel naar traag', gezien dit alles afhangt van wat je exact verwacht van je query.
system
Indien de tabel maar 1 rij bevat.
const
Je vergelijkt met een constante en is daarom snel.
SELECT * FROM table WHERE id = 1;
eq_ref
Er is maar 1 rij uit deze tabel die past bij (de combinatie van) de vorige rijen. Hier gaat het dus om een PRIMARY KEY of UNIQUE index in de tabel die wordt gejoined.
SELECT t1.*, t2.* FROM table1 AS t1 INNER JOIN table2 AS t2 ON t2.id = t1.fk;
ref
Bij (de combinatie van) de vorige rijen kunnen meerdere rijen van deze kolom matchen omdat de kolom waarop de tabellen gejoind worden geen unieke waarden bevat.
SELECT * FROM table1 AS t1 INNER JOIN table2 AS t2 ON t2.not_unique = t1.fk;
fulltext
In tegenstelling tot bovenstaande query-types wordt hier niet gezocht op een exacte waarde in je dataset, maar wordt een match gedaan op de volledige inhoud van je rij om te bekijken of de waarde voorkomt en hoe vaak deze voorkomt.
Hierbij worden intern ook enkele speciale handelingen uitgevoerd: zo worden bijvoorbeeld zoekwoorden die in meer dan 50% van de rijen voorkomen of taal-specifieke stopwoorden (zoals some, then, …) niet meegerekend.
Met 'IN NATURAL LANGUAGE MODE' zal het nodig zijn een FULLTEXT index aan te maken op de columns die je wenst te doorzoeken. Bij 'IN BOOLEAN MODE' is dit niet nodig (opzoeken zal hierdoor wel trager gaan), en kunnen ook speciale operators meegegeven worden om heel specifiek te gaan zoeken. Deze zal uiteraard om deze reden ook nog trager zijn dan de NATURAL LANGUAGE MODE omdat dit een veel complexere operatie kan worden.
SELECT * FROM table WHERE MATCH(column) AGAINST('search');
ref_or_null
Idem als 'ref', maar hier wordt ook gecontroleerd op null-waarden.
SELECT * FROM table1 AS t1 LEFT OUTER JOIN table2 AS t2 ON t2.not_unique = t1.fk;
index_merge
Dit type geldt voor queries waarbij het resultaat de uitkomst is van meerdere verschillende selecties (typisch bij OR). Intern worden deze verschillende selecties apart uitgevoerd en de resultaten hiervan worden gecombineerd weergegeven als omvattende resultset die voldoet aan de volledige expressie.
SELECT * FROM table WHERE column1 = X OR column2 = Y;
unique_subquery
De kolommen die gematcht worden zijn het resultaat van een subquery die unieke kolommen geeft.
SELECT * FROM table1 WHERE column IN (SELECT id FROM table2);
index_subquery
Dit type is gelijk aan unique_subquery, behalve dat in plaats van een subquery met unieke waarden, deze werkt met niet-unieke kolommen.
SELECT * FROM table1 WHERE column IN (SELECT not_unique FROM table2);
range
Enkel rijen binnen een bepaalde range van een index moeten worden onderzocht, de gebruikte index kan je terugvinden in de key-kolom.
SELECT * FROM table WHERE id BETWEEN 10 AND 20; SELECT * FROM table WHERE id IN (10, 11, 12);
index
Idem als ALL (zie onder), maar enkel de index moet onderzocht worden.
SELECT * FROM table WHERE id = 1;
ALL
De volledige tabel moet onderzocht worden. Indien dit voorvalt los je dit best op.
possible_keys
Een oplijsting van de indexen die MySQL kan gebruiken. Dit wil niet zeggen dat er één zal gebruikt worden.
Indien deze kolom leeg is, dan zijn er geen bruikbare indexen gevonden. Het kan dan nuttig zijn om op basis van de WHERE-clause een toepasselijke index te maken.
key
Hier kan je zien welke key (index) gebruikt is.
ref
Hier kan je zien welke kolom vergeleken werd met de gebruikte index.
rows
Het (geschatte) aantal rijen dat MySQL zal onderzoeken.
Als je gebruik maakt van JOINS dan moet je de resultaten in deze kolom met elkaar vermeningvuldigen, zo bekom je het totale aantal rijen. Het spreekt vanzelf dat een lager totaal een snellere query oplevert.
Impossible WHERE noticed after reading const tables
Indien de WHERE-clause altijd false oplevert.
No tables
Indien de query geen FROM-clause heeft.
Using filesort
Om de rijen correct te sorteren moet MySQL de gevonden resultaten opnieuw overlopen.
Using index
Er is een enkel een index gebruikt om de rijen te selecteren.
Using temporary
Om de query op te lossen moet een tijdelijke tabel gemaakt worden. Dit valt meestal voor indien je GROUP BY of ORDER BY gebruikt.
Using where
Om de query op te lossen is de WHERE-clause gebruikt. Indien dit niet voorkomt is er ofwel iets mis met je query of onderzoek je bewust alle rijen van de tabel. Let wel: dit kan een vertraging aanduiden als er veel data is.
Zoals je kan afleiden uit bovenstaande lijst vermijd je best 'Using filesort' en 'Using temporary', dit zijn de twee gevallen die een query traag maken.
Wat is een index?
Om een query te optimaliseren moeten we natuurlijk begrijpen wat een index is.
Zie een index als een inhoudsopgave van een boek. Door een inhoudsopgave kan je snel naar een bepaald onderwerp in het boek gaan zonder alle pagina's te moeten lezen.
MySQL gebruikt de index in een aantal situaties:
zoeken van rijen
elimineren van niet-relevante rijen, indien er meerdere mogelijke indexen zijn zal MySQL deze nemen met de minste rijen
om verschillende tabellen te JOINEN
minimum- en maximumwaardes ophalen
sorteren van resultaten
Zonder indexen moet MySQL de volledige tabel gaan overlopen om resultaten te vinden, met een index hoeft MySQL enkel het relevante stuk te doorlopen.
Je kan nu denken dat je op iedere kolom en op elke mogelijke combinatie een index kan leggen. Dit is echter geen goed idee - en ook niet mogelijk - want een index wordt bij iedere INSERT, UPDATE, DELETE herberekend, waardoor deze statements dan weer trager worden. Hoe meer indexen hoe trager het geheel, hou dit dus ook in het achterhoofd bij het optimaliseren van een query.
Bij het maken van een index kan een type meegeven. Iedere type heeft zijn eigen eigenschappen.
PRIMARY KEY
De combinatie van velden is uniek doorheen de tabel, per tabel kan er maximaal 1 PRIMARY KEY zijn.
UNIQUE
De combinatie van velden is uniek doorheen de tabel.
INDEX
In tegenstelling tot een UNIQUE index hoeft de combinatie van velden niet uniek te zijn.
FULLTEXT
Een speciaal type van index dat gebruikt word voor full-text-searches. (enkel beschikbaar voor MyISAM-tabellen)
Je kan een index aanmaken met volgende MySQL-statement:
ALTER TABLE table1 ADD [type] (column, column);
Hoe kies je nu een juiste index?
Vooraleer je indexen begint aan te brengen moet je nadenken of het wel nut heeft. Is het een tabel met weinig data, dan kan het zijn dat de query sneller is als alle rijen worden overlopen. Is het een query die weinig gebruikt wordt? Dan kan je je beter concentreren op queries die veel worden uitgevoerd (bijvoorbeeld bij iedere klik).
Een klein rekenvoorbeeld: je hebt een query die 1 maal per dag word uitgevoerd en 10 seconden duurt, door middel van indexes kan je die terugbrengen naar 2 seconden, dan heb je 8seconden gewonnen.
Stel nu dat er een query is die 1000 keer per dag wordt uitgevoerd en die 1 seconden duurt en je kan optimaliseren tot 200ms dan win je 1000 x 800ms en dus in totaal 8000 seconden.
Opmerking: Dit is een theoretisch voorbeeld.
Een goede index zorgt ervoor dat MySQL de WHERE-clause zo snel mogelijk kan oplossen. Als je bijvoorbeeld e.active = 'Y' AND e.hidden = 'N' in je query hebt staan dan is het slim om een index op active en hidden te leggen.
Je kan eigenlijk volgende leidraad gebruiken: eerst de kolommen in de WHERE-clause, dan de kolommen in de SELECT-clause.
Opmerking: Dit is een leidraad, geen vaststaand feit.
Als we een aantal indexen leggen en onze eerste query terug uitvoeren komen we op volgend resultaat:
id
select_ type
table
type
possible_ keys
key
key_ len
ref
rows
Extra
1
simple
t
range
primary
primary
4
null
4
Using where; Using index
1
simple
d
ref
idx_designs_products
idx_designs_products
4
db.t.id
37
Using where
1
simple
p
eq_ref
primary, idx_id_active
primary
4
db.d. profile_id
1
Using index
Andere voorbeelden om queries te optimaliseren
STRAIGHT_JOIN
Bij het uitvoeren van een query met JOINS over verschillende tabellen, maakt MySQL zelf een query plan. Dit bepaalt in welke volgorde de tabellen worden geprocessed en gejoined.
Dit zal more often than not de meest effeciënte manier van joinen zijn, echter niet altijd. Het kan natuurlijk altijd voorkomen dat juist die ene vaak gebruikte query doorheen een grote dataset door MySQL net niet goed genoeg geïnterpreteerd wordt, met een groot prestatieverlies als gevolg. Dit kan je oplossen met STRAIGHT_JOIN.
Door middel van SRAIGHT JOIN kan je zelf bepalen in welke volgorde je tabellen zullen worden gejoined, of eerder: MySQL zal je tabellen van links naar rechts joinen in plaats van zelf de volgorde te beslissen. Met dan zorgvuldig zelf de tabellen in de juiste volgorde neer te poten, kan je sommige queries efficiënter maken.
SELECT STRAIGHT_JOIN * FROM table1 AS t1 INNER JOIN table2 AS t2 ON t1.col = t2.col;
Werken met DATETIME
In veel CMS-en is er de mogelijkheid om een publicatie-datum van een artikel aan te geven. Dit is een potientieel risico voor trage queries.
Omdat een tijdstip iedere seconde anders is, kan de query maximaal 1 seconde gecached worden.
SELECT e.*, m.* FROM blog_entries AS e INNER JOIN meta AS m ON e.meta_id = m.id WHERE e.active = 'Y' AND e.hidden = 'N' AND e.date_publish < NOW() ORDER BY e.date_publish DESC;
Het is overbodig om de gebruiker tot op de seconde te laten specifieren wanneer een een artikel moet getoond worden. Je kan er dus beter voor zorgen dat bij het opslaan de seconden op 00 staan. En je query herschrijven als volgt (uiteraard met het correcte tijdstip):
SELECT e.*, m.* FROM blog_entries AS e INNER JOIN meta AS m ON e.meta_id = m.id WHERE e.active = 'Y' AND e.hidden = 'N' AND e.date_publish < "2009-11-03 13:37:00" ORDER BY e.date_publish DESC;
Hierdoor kan je query maximaal 1 minuut gecached worden. Je zou natuurlijke en stap verder kunnen gaan en enkel kwartieren kunnen toelaten.
ORDER BY RAND()
Als we onze server-admins mogen geloven dan sterft er iedere keer je ORDER BY RAND() gebruikt een klein schattig konijntje. ORDER BY RAND() is een heel intensieve operatie bij grote tabellen.
Je kan dit beter oplossen in je code, bijvoorbeeld met de PHP-functie shuffle.
Heb je echter een slechts een kleine result-set nodig die random moet gegenereerd worden uit een grote hoeveelheid data, dan biedt shuffle natuurlijk ook geen goed resultaat, omdat je dan die grote hoeveelheid data (even) in het geheugen zal moeten dulden, terwijl je slechts een kleine hoeveelheid data hiervan nodig hebt. Hoe kan je dit beter?
// get the maximum ID $max = 'SELECT MAX(id) FROM table;'; // do n queries, where n is the number of rows to retrieve // this should be more effective then one ORDER BY RAND()-query for ($i = 0; $ < [totaal-aantal-benodigde-random-rijen]; $i++) { get random row $results[$i] = 'SELECT * FROM table LIMIT '. rand(0, $max) .', 1;'; }
Waarom is dit nu efficienter dan ORDER BY RAND()? Wel, voor iedere rij in de tabel moet bij ORDER BY RAND() een willekeurig getal worden gegenereerd, hierna moet er op al deze willekeurige getallen ook nog gesorteerd worden.
Disclaimer: zie deze blogpost niet als de heilige graal om je website met tienduizende bezoekers te gaan optimaliseren. Voor zo'n situaties kan je beroep doen op DB-admins, deze kunnen op basis van je applicatie en logs gaan kijken wat er specifiek moet geoptimaliseerd worden.
Vooraleer ik de ondernemers-sprong waagde en webwerker werd, was ik in loondienst bij een Grote Belgische Bank.
Ik werkte een tijd in een kantoor in Landegem, een klein dorpje ten zuiden van Gent. Eén van de eigenschappen van dat dorpje is dat er zowel een beschutte werkplaats, een MPI, als een aantal tehuizen voor mensen met een handicap gevestigd zijn.
Toegankelijkheid en mijn bankverleden
In dat bankkantoor leerde ik dagelijks omgaan met mensen met een functiebeperking; laat me zeggen dat de uitdaging om het online banking pakket toegankelijk te krijgen eind jaren negentig aanzienlijk waren.
Het maakte me bewust van de vragen en noden van die specifieke bevolkingsgroep - maar vooral: het deed me inzien dat je bij alles wat je doet inclusief moet werken en denken, en niet noodzakelijk vanuit je eigen wereldbeeld moet vertrekken.
Anysurfer en Netlash
Vandaar dat het verhaal van Anysurfer onmiddellijk bij me aansloeg. Voor veel mensen met een functiebeperking is het internet dé manier om makkelijk deel te nemen aan de alledaagse dingen uit ons leven (dingen als online shoppen, banksoftware gebruiken of de uurroosters van De Lijn raadplegen). Websites maken met aandacht voor de richtlijnen van Anysurfer strookte met mijn visie rond duurzaam ondernemen.
Het kwam uiteraard goed uit dat een toegankelijke website vaak tegelijkertijd ook een SEO-geoptimaliseerde en gebruiksvriendelijke website is.
Vandaar dat we besloten om zoveel mogelijk de regels van Anysurfer te volgen bij het bouwen van onze sites. Vandaar ook dat we ook met onze eigen Netlash website expliciet het Anysurfer label wilden halen.
Anysurfer en ABconcerts.be
We waren dan ook blij te horen dat onze partner en klant Ancienne Belgique ook nadenkt over toegankelijkheid voor bezoekers met een handicap. Meer nog, ruim 300 personen met een handicap genieten op donderdag 21 januari 2010 van een exclusief en gratis concert van Channel Zero in de AB in Brussel.
De AB wil met dit concert beklemtonen dat ook bezoekers met een handicap meer dan welkom zijn op hun evenementen. Niet enkel voor dit concert dus, maar een heel jaar door. Daarom heeft het AB-team samen met Team Netlash de nodige inspanningen gedaan hebben om de website ook in een nog toegankelijker versie uit te werken.
Naast de AB Website werkt AB ook volop aan de toegankelijkheid van de ticketingspagina's (tickets.abconcerts.be) voor personen met een functiebeperking. Door de technische complexiteit van dit gedeelte van de site zullen de pagina's in de loop van het voorjaar (2010) gewijzigd worden, conform de richtlijnen van Anysurfer.
Je kan de vernieuwde toegankelijke versie nu al bekijken (zie de link bovenaan links op de site), samen met de toegankelijkheidsverklaring.
Jullie feedback is uiteraard, zoals steeds, meer dan welkom.
Een trendrapport dat gecrowdsourced wordt? Is zoiets mogelijk?
Ik wou het alleszins proberen.
60 verschillende stemmen, zo divers als mogelijk: van student tot internetmarketeer, van founder van een startup tot CEO van een gevestigd reclamebureau, van academicus tot minister. Met de nodige duwtjes hier en daar kreeg ik evenveel voorspellingen over online in 2010 binnen.
Het eindresultaat is iets minder voorspellend geworden, als wel een document over 'wat houdt de Vlaamse digirati op dit moment bezig'.
Voor wie de samenvatting wil:
De meesten zijn er van overtuigd dat in 2010 mobiel internet (16 vermeldingen) definitief mainstream wordt. Er zijn ook hoge verwachtingen over augmented reality (13 vermeldingen).
Terwijl velen zien dat sociale netwerken (9 vermeldingen) in het weefsel van onze maatschappij doordringen, en bedrijven massaal met sociale media aan de slag gaan (9 vermeldingen), zijn er toch heel wat bedenkingen over veiligheid en privacy (9 vermeldingen). Ondertussen moeten die sociale media geld beginnen opbrengen, en ligt de focus op ROI en conversie (7 vermeldingen). Sommigen zien alweer een social media fatigue (5 vermeldingen) optreden; anderen zien email vervangen worden door sociale media (5 vermeldingen).
De tablets en e-books (9 vermeldingen) worden een hype; zou dit met de aandacht voor 'groen' (9 vermeldingen) te maken hebben?
Nog drie buzzwords: alles moet real time (9 vermeldingen) zijn, liefst nog location based (6 vermeldingen) en in de cloud (5 vermeldingen).
Je kan het trendrapport hier downloaden in pdf-formaat: Online Trendrapport 2010 (.pdf, 16.3 Mb).
Maar je kan het hier ook rustig doorbladeren:
Voldoende inspiratie?
Volgend jaar verwacht ik alleszins jullie voorspellingen in mijn mailbox!
Door Concentra werd me gevraagd om een presentatie te geven over mijn visie op media en internet.
Ik pretendeer zeker niet te weten waar media naar toe gaan, en hoe dat moet gebeuren.
Toch probeerde ik om de grote trends weer te geven, en zo de discussie op gang te trekken. (Vergelijk het met de workshop 'Trends in e-business' die ik in 2004 voor Partena gaf.)
Hieronder vind je mijn presentatie:
Er zitten 5 hoofdstukjes in:
Content: Gaat het over kwaliteit of kwantiteit? En hoe krijgen beide begrippen een invulling online?
Distributie: Is dit nog steeds de controlerende factor online? En hoe is dit anders dan offline?
Informatie: Online hoef je je niet te beperken tot het format tekst+foto, maar kan je gebruik maken van de interactiviteit van internet.
Nieuws: De Nu-Nu-Nu generatie heeft andere verwachtingen van nieuws.
Community: Media kunnen waarde creëren door een stem, een filter, een kader te bieden in de overvloed aan informatie.
Geen wereldschokkende bevindingen uiteraard; en voor wie met internet dagelijks omgaat zelfs evidenties.
Op 3 december gaat het Social Media Forum door: een dag lang concrete informatie en cases over Social Media, hoe er geld mee te verdienen, en hoe het in te zetten voor je bedrijf.
Inge Wiame, Business Development Manager Benelux - Netlog Presentation of the renewed Netlog platform
Tom Remans, Marketing Manager - Luon Client-case Solo : social media as part of an integrated marketing approach
Nico Henderijckx, Online Marketing Manager - Sony VAIO of Europe Client-case Sony VAIO: “VAIO of Europe - Social media approach
Charles Crouch, Lecturer Boston University Planning a social media campaign
Clo Willaerts, Marketing manager sanoma magazines How to make money with Social Media
Genevieve Tissot, Managing director BlueKiwi Client case social media platform
Kim Leunen, Account Manager S²Media Why you should join / Define your goals / How to Measurements & tools / Case - tips & tricks
Evan Van Lissum, Managing partner The Parking Lot Social branding : New kids on the blog
Bart de Waele, Co-founder Talking Heads Nike Running & Social Media
De sleutel tot een goed grafisch ontwerp ligt voor een groot deel bij het proces. Zowel beginnende als ervaren ontwerpers kunnen voordeel halen uit het optimaliseren van dit proces.
1. Begin met een goede briefing
Begin door een duidelijke beschrijvende briefing aan de klant te vragen. Stel eventueel zelf een vragenlijst op die de klant kan invullen. Probeer zoveel mogelijk concrete zaken te verzamelen. Wanneer de klant een vaag buikgevoel beschrijft, kan je vragen of hij dit kan illustreren met voorbeelden van andere sites, logo’s en stijlen.
Wanneer je voelt dat je weet welke richting de klant uit wil, kan het handig zijn zelf een kleine verzameling elementen bij elkaar te zoeken. Deze verzameling kan je gebruiken om later terug de stijl op te roepen die de klant voor ogen heeft.
2. Evalueer bestaande stijlelementen
Zorg dat de klant je al zijn oud materiaal stuurt en evalueer of zijn logo en kleuren passen bij de eerder beschreven stijl. Vraag zeker ook na of de klant goed fotomateriaal heeft. Unieke professionele foto’s kunnen vaak het verschil maken bij een ontwerp.
Kijk alle elementen na en controleer of alles bruikbaar is. Open alle vector bestanden om na te gaan of ze daadwerkelijk vector zijn. Bekijk de resolutie van eventuele foto’s en kijk de kleurprofielen na.
3. Visualiseer de inhoud en bepaal het doel
Bekijk de structuur die de informatie architect met de klant heeft gemaakt en overloop wat het doel is van elke pagina en element. Bepaal wat moet opvallen en wat minder moet opvallen vanuit het oogpunt van de bezoeker.
Het is de taak van de designer om ervoor te zorgen dat hij de bezoeker doorheen de pagina gidst, en alles ziet wat hij hoort te zien. Wanneer te veel elementen om aandacht vechten zal de bezoeker zijn weg doorheen de pagina niet vinden.
4. Maak minstens 4 voorstudies
Eens je het doel en de klemtonen van alle elementen weet, maak je best enkele schetsen. Het schetsen is een cruciale stap bij het ontwerpen. Het stimuleert de creativiteit en spaart veel tijd uit. Een viertal schetsen uitwerken per pagina is het absolute minimum.
Ontwerpen van 3 verschillende Netlash ontwerpers.
Stop echter niet te veel tijd in een schets. Schets eerder alles neer wat je te geest komt en visualiseer wat er zal werken en wat niet. Werk de beste schetsen uit in fijnere voorstudies om zo je idee bij te schaven.
5. Werk een eerste voorstel uit
Open je favoriete webdesign programma om je ontwerp vorm te geven en ga aan de slag om je visie om te zetten in pixels. Laat je ontwerp evolueren en laat je zeker niet limiteren door je schetsen.
Hou rekening met de beperkingen van browsers en schermresoluties en maak je ontwerp altijd op ware grootte. Probeer de inhoud zo realistisch mogelijk te houden, indien mogelijk zelfs de definitieve copy. Wanneer je die laatste knop en pixel juist geplaatst hebt, is het tijd om het document te sluiten. Neem een korte pauze of werk even iets anders af.
6. Knijp die ogen eens half dicht
Open nu je document en kijk wat je eerste indruk is. Vallen de elementen die moeten opvallen (zie stap 3) op? Neem wat afstand van je scherm en knijp je ogen dicht tot alles wat troebel is.
Zo kun je makkelijk evalueren of je ontwerp in balans is. Eventueel vraag je aan iemand om even je ontwerp te bekijken. Zorg wel dat je open staat voor hun kritiek! Het is soms niet prettig om negatieve kritiek te horen op een ontwerp waar je net enkele uren aan hebt gewerkt.
Voldoet je ontwerp niet aan de verwachtigen en doelstellingen? Ga terug naar stap 1, passeer langs start en neem een Nalu.
Voldoet je ontwerp wel aan de verwachtingen en doelstellingen? Ga dan naar stap 7.
7. Geniet van je rockstar moment
Proficiat! Je bent voor heel even een webdesign rockstar! Spring even op je bureau en doe een luchtgitaarsolo. Blijf echter niet te lang in je roes, je ontwerp moet nog gesliced en geïntegreerd worden zodat de hele wereld ervan kan genieten.
In Bright staat deze maand een uitgebreid artikel over Dieter Rams, naar aanleiding van een tentoonstelling over hem in het Londense Design Museum.
Dieter Rams was veertig jaar hoofd van het designteam van elektronicaproducent Braun. Hij was verantwoordelijk voor een belangrijke stroming in het industriële design van vorige eeuw.
Meer nog, hij beïnvloedde rechtstreeks één van de huidige iconografische designers, namelijk Jonathan Ive, hoofddesigner van Apple.
Hoe groot zijn invloed is kan je in onderstaande fotomontage zien (bovenaan werk van Rams, onderaan werk van Ive):
Dieter Rams is één van de mensen die ons hier bij Netlash richting geven.
Beschouw bijvoorbeeld volgende quote van hem:
“Good designers must always be avant-gardists, always one step ahead of the times. They should – and must – question everything generally thought to be obvious. They must have an intuition for people’s changing attitudes. For the reality in which they live, for their dreams, their desires, their worries, their needs, their living habits. They must also be able to assess realistically the opportunities and bounds of technology.”
Dit komt uit een speech uit 1980 die Rams aan de Braun advisory board gaf. Hierin geeft hij aan dat de mens, de gebruiker centraal moet staan - tegelijkertijd rekening houdend met de mogelijkheden en beperkingen van de technologie.
Hij formuleerde ook de 10 principes waaraan goed design volgens hem voldoet:
Good design is innovative.
Good design makes a product useful.
Good design is aesthetic.
Good design makes a product understandable.
Good design is unobtrusive.
Good design is honest.
Good design is long-lasting.
Good design is thorough down to the last detail.
Good design is environmentally friendly.
Good design is as little design as possible.
Het zijn principes die we hier ook in onze websites proberen te stoppen. Ik vertaal het even naar onze sector:
De concepten en ontwerpen van onze sites moeten voorlopen. We proberen trendsetters te zijn, in plaats van trendvolgers.
Een goede site legt de inhoud bloot - en probeert geen valse verwachtingen te creëren.
Een goede site is duurzaam; hij wordt gebouwd met flexibele content in gedachten. Het CMS ondersteunt een veranderende omgeving en een veranderende site.
Consequentie is essentiëel bij een gebruiksvriendelijke website. Knoppen zijn knoppen, acties hebben dezelfde kleur, links zijn onderlijnd.
Naast het intensievere werk voor de MySQL-server kan dit ook een vertraging op de site opleveren. De data moet namelijk opgehaald worden, verwerkt worden en getoond worden aan de bezoeker.
Bij wijze van voorbeeld: Stel je voor dat je een array hebt met daarin de ID's van de vrienden van de huidige ingelogde gebruiker. Wat de meeste developers nu doen is een loopje starten en in deze loop de waardes ophalen per friend-ID.
// loop friends foreach($friendIds as $id) { // get friend data $friendData = $this->db->getRecord('SELECT p.nick, p.avatar, ... FROM profiles AS p WHERE p.id = '. $id .';');
// code to generate output ... } ?>
In het bovenstaande voorbeeld hebben we dus een groot aantal queries (lees n+1), namelijk:
1 om de ID's van de vrienden op te halen
1 per vriend om zijn specifieke data op te halen
Met behulp van de MySQL-functie IN() kunnen we dit terug brengen naar 2 queries.
// get all profiledata at once $profileData = $this->db->retrieve('SELECT p.nick, p.avatar, ... FROM profiles AS p WHERE p.id IN ('. implode(',', $friendIds) .');');
// loop profiles foreach($profileData as $friend) { // code to generate output ... } ?>
Zoals je nu kan zien hebben we 2 queries:
1 om de ID's van de vrienden op te halen
1 om de data voor al deze vrienden in één keer op te halen
Opmerking: Ik wil er wel de nadruk op leggen dat dit een fictief voorbeeld is. De code is dus ook niet terug te vinden in de vernoemde websites. In dit voorbeeld zou het nog nuttiger zijn om niet alleen de ID's op te halen maar meteen de data, maar dit terzijde.
Google heeft er weer een nieuwe baby bij. Gisteren lanceerde Google het concept Google Knol, een variant op de internetencyclopedie Wikipedia. Het concept liep al sinds december in een testversie. Een "knol" is een inhoudelijke bijdrage van een expert rond...
Midden juni startte Fortis internationaal met de campagne '"Here today. Where tomorrow?". De campagne loopt in meer dan 50 landen. De eenvoud van de curve maakt dit tot een sterk herkenbaar verhaal. Het moment van de communicatie kan in een...
Slimme marketeers kennen al langer de kracht van het woord "nieuw" in communicatie-uitingen. Uit onderzoek van enkele neurowetenschappers blijkt nu dat de verleiding om voor iets nieuw te kiezen biologisch verklaard kan worden. In het vakblad Neuron beschreven wetenschappers een...
Dit weekend verscheen in De Morgen een artikel over de redenen achter het succes van Belgische bureaus op het reclamefestival in Cannes. Een aantal quotes van vooraanstaande reclamemakers uit het artikel om aan te geven waar het om draait in...
Als voetbalfan schakel ik tijdens het EK over naar de NOS. Scherpe analyses, sober commentaar, en animerende praatprogramma's zorgen voor mooie televisieavonden. Daarnaast zijn ook de reclameblokken meer dan de moeite. De themaspots van verzekeringsmaatschappij Nationale Nederlanden zijn weer een...
Merken scheppen een band. Dat moet het uitgangspunt geweest zijn van de oprichters van de datingsite BrandDating. BrandDating probeert mensen te matchen op basis van hun merkvoorkeur. Bij BrandDating stel je jezelf voor aan de hand van merken. Merken zeggen...
Dit weekend verscheen in De Standaard het artikel "Iedereen Gucci' over het boek "Deluxe. How luxury Lost Its Luster" van de Amerikaanse modejournaliste Dana Thomas. Het boek schetst het afglijden van merken zoals Gucci, Prada, Vuitton en Armani van luxeartikel...
Winkelen is de afgelopen maanden flink duurder geworden. De stijgende voedingsprijzen wegen steeds zwaarder op het budget van de consument. Als gevolg daarvan gaan mensen een prijsbewuster shopgedrag vertonen. Het succes van de discounters is daar niet vreemd aan. Daarnaast...
Afgelopen week zijn in New York voor de twaalfde keer de Webby Awards uitgereikt. Dit initiatief bekroont in meer dan honderd categorieën de beste websites ter wereld. De volledige lijst van winnaars en genomineerden kan je hier raadplegen. Een aantal...
Bedrijven moeten dringend ophouden met het zoeken naar "young potentials" of "jonge en dynamische mensen". Dit is alvast de boodschap die het Centrum voor Gelijkheid van Kansen en Racismebestrijding via een persbericht de wereld instuurt. Het Centrum voerde een heuse...
Wit is weer helemaal in als kleur van nieuwe wagens. Tot voor kort waren witte auto's het kneusje van de sector, zeker op de tweedehandsmarkt. Mijn schoonvader, een garagehouder met jarenlange ervaring, vatte het als volgt samen: "Met een witte...
Studio 100 is een fenomeen. Als geen ander slaagt het bedrijf uit Schelle erin om de jeugdige doelgroep in te palmen met hun concepten. De succesformule van Studio 100 is gebouwd op de zeer sterke wisselwerking tussen hun verschillende productgroepen:...
Deze week is de campagne Only in Belgium voorgesteld. Na de periode van politieke instabiliteit, moet het merk België terug op de kaart gezet worden bij buitenlandse investeerders. De campagne verwijst met Belgische figuren als stripheld Lucky Luke, de surrealistische...
1. Vind je ook dat marketing vaak beter kan? 2. Zit ondernemerschap in je genen? 3. Word je soms de witte raaf genoemd? 4. Heb je een passie voor marketing & communicatie? 5. Droom je soms conceptueel? Indien 5 x...
Enkele maanden nadat we besloten de stap te zetten om 
Op vrijdag 11 juni waren we met een groot deel van het 
In de 
Sinds de steile opmars van Facebook (
Eén van de vier kernwaarden bij Netlash is innovatie: we ambiëren om vandaag online dié dingen te doen die binnen drie jaar bon ton zijn. Dat houdt ook in dat we nadenken over de toekomst van computers - en we zien de mogelijkheden en potentie van touch screen tablets, met als exponent de iPad, als 
Onlangs besloot Davy om deel te nemen aan het 
Op 
In onze webapplicaties - zeker diegene met 
Onze sector is een jonge sector. Het web zelf is amper twintig jaar oud; in België hebben we een 
Op 16 en 17 februari ging in Parijs de eerste internationale Symfony conferentie, 
Voor het 
We hebben hier bij Netlash wel al 
Queries optimaliseren, veel developers zien het als een straf. Het kan nochtans eenvoudig zijn, maar zoals bij alles moet je eerst begrijpen wat er gebeurt vooraleer je kan gaan ingrijpen.
Mag ik jullie een geheimpje vertellen?
De voorbije jaren (
Door Concentra werd me gevraagd om een presentatie te geven over mijn visie op media en internet.
Op 3 december gaat het Social Media Forum door: een dag lang concrete informatie en cases over Social Media, hoe er geld mee te verdienen, en hoe het in te zetten voor je bedrijf.
De sleutel tot een goed grafisch ontwerp ligt voor een groot deel bij het proces. Zowel beginnende als ervaren ontwerpers kunnen voordeel halen uit het optimaliseren van dit proces.
In 
Bij een 
