Bart De Waele » net

net | log (10 unread)

Convert CSS naar inline styles

Posted: March 11th, 2010, 1:37pm CET

Tags: [edit]
In onze webapplicaties - zeker diegene met een community - 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.

Je kan de class terugvinden op: http://classes.verkoyen.eu/css_to_inline_styles, daar staat ook de nodige documentatie en een voorbeeld van hoe je de class kan gebruiken.

Combineer dit met de functie die Annelies eerder schreef en je bent klaar om jouw gebruikers de beste mail te sturen.
Convert CSS naar inline styles geschreven door Tijs in: webdevelopment

Tags: css to inline styles, email nieuwsbrief, php
Het geïntegreerde webbureau

Posted: March 10th, 2010, 2:30pm CET

Tags: [edit]

Onze sector is een jonge sector. Het web zelf is amper twintig jaar oud; in België hebben we een vakorganisatie die nog geen zeven jaar oud is.

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).

Wat is jullie mening?

Het geïntegreerde webbureau geschreven door Bart in: webdesign

Tags: integratie, webbureau, webdesign
Symfony Live 2010

Posted: March 1st, 2010, 5:29am CET

Tags: [edit]

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.
Symfony Live 2010 geschreven door Bert in: opleiding

Tags: conferentie, symfony
HTML naar plain text omvormen

Posted: February 2nd, 2010, 10:07pm CET

Tags: [edit]
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.
De functie:
De uitleg:
// 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 "\n" 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.

Bekijk achtereenvolgens eens de originele nieuwsbrief, de plain text inhoud gemaakt met strip_tags en de plain text inhoud gemaakt met getPlainText.
Opmerkingen:
Zodat jullie ze niet meer moeten geven, enkele opmerkingen:
- Niet alle html karakters worden goed vervangen.
- Afhankelijk van de html code zullen er hier en daar toch nog meerdere witregels staan.
- Het beste resultaat wordt natuurlijk nog altijd verkregen als je zelf de plain inhoud van je nieuwsbrief maakt.
Nog opmerkingen zijn uiteraard welkom :-)
Update (13/02/2010)
De nieuwe versie kan je hier vinden.
Het resultaat op de Netlash nieuwsbrief van 21 januari vind je hier.

Wat is er veranderd?
- hoofdingen worden nu aangeduidt door **
- lijst items worden aangeduidt met -
- na hoofdingen, paragrafen en lijst items worden er witregels geplaatst
- script elementen worden nu ook gestript zodat de functie niet enkel voor e-mail nieuwsbrieven geschikt is
Dit maakt het geheel nog beter leesbaar en zorgt voor een minimum aan opmaak.

(Deze blogpost is geschreven door Netlash webdevelopster Annelies, en verscheen eerst op haar persoonlijke blog.)

HTML naar plain text omvormen geschreven door Annelies in: webdevelopment

Tags: e-mail, email nieuwsbrief, plain text, strip, tags
Webdesign proces bij Netlash

Posted: January 25th, 2010, 7:40am CET

Tags: [edit]

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?

Het gaat over het verzamelen van informatie: de transfer van kennis die in het hoofd van onze klant zit, naar onze hoofden - om die dan te bevruchten met onze kennis van wat werkt online en wat niet.

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.

Het voorbeeld hierboven is dat van de vernieuwde bSeen website - je vind de twee iteraties van het structuurdocument hier.

3. Design

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.

(Bovendien is de homepagina al lang niet meer de belangrijkste pagina van een website.)

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.

Het eindresultaat van de bovenstaande staooeb voor de bSeen website kan je online bekijken.

10. Support

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?
Webdesign proces bij Netlash geschreven door Bart in: webdesign

Tags: kwaliteit, proces, webdesign

MySQL EXPLAIN als hulp

Posted: January 23rd, 2010, 1:37pm CET

Tags: [edit]

mysql 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.

extra

In deze kolom kan je informatie vinden over hoe MySQL de query oplost. Mogelijke waardes zijn:
(enkel relevante waardes zijn vermeld, meer op: [dev.mysql.com])

Distinct
MySQL zoekt naar unieke waardes.
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.

Bronnen: MySQL, Openminds, PHPhulp, #netlash, Learning MySQL, Web Database Application with PHP & MySQL.

MySQL EXPLAIN als hulp geschreven door Tijs, Matthias, Annelies, Davy, Dave in: webdevelopment

Tags: explain, mysql, performance, tips

Anysurfer

Posted: January 19th, 2010, 3:20pm CET

Tags: [edit]

Mag ik jullie een geheimpje vertellen?

Ik heb een bankverleden.

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.

Anysurfer geschreven door Bart in: webdesign

Tags: ab, accessibility, anysurfer, toegankelijk
Online trendrapport 2010 : de voorspellingen

Posted: December 30th, 2009, 12:30pm CET

Tags: [edit]

De voorbije jaren (2008, 2009) probeerde ik een aantal voorspellingen te doen over de richting van online in het komende jaar.

Vorig jaar vroeg ik daarbovenop aan twintig experts wat hun voorspellingen voor 2009 waren. Dit jaar gingen we nog een stap verder: we vroegen openlijk aan iedereen die zich geroepen voelde om een bijdrage te leveren.

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!
Liever een papieren versie?
Het trendrapport is een lijvig document van maar liefst 91 pagina’s. Misschien lees je het liever in je luie zetel? Je kan een paperback versie bestellen via lulu.com.

Bestel nu

Online trendrapport 2010 : de voorspellingen geschreven door Bart in: trend

Tags: online, trend, trendrapport, trends, trendwatching, voorspellingen, web
Oude media versus nieuwe media

Posted: December 28th, 2009, 3:05pm CET

Tags: [edit]
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:
1. Content: Gaat het over kwaliteit of kwantiteit? En hoe krijgen beide begrippen een invulling online?
2. Distributie: Is dit nog steeds de controlerende factor online? En hoe is dit anders dan offline?
3. Informatie: Online hoef je je niet te beperken tot het format tekst+foto, maar kan je gebruik maken van de interactiviteit van internet.
4. Nieuws: De Nu-Nu-Nu generatie heeft andere verwachtingen van nieuws.
5. 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.

Edit: De Werktitel maakte een samenvatting van de presentatie.

Oude media versus nieuwe media geschreven door Bart in: marketing

Tags: media, visie
Social Media Forum

Posted: November 25th, 2009, 10:16am CET

Tags: [edit]
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.
1. Inge Wiame, Business Development Manager Benelux - Netlog
  Presentation of the renewed Netlog platform
2. Tom Remans, Marketing Manager - Luon
  Client-case Solo : social media as part of an integrated marketing approach
3. Nico Henderijckx, Online Marketing Manager - Sony VAIO of Europe
  Client-case Sony VAIO: “VAIO of Europe - Social media approach
4. Charles Crouch, Lecturer Boston University
  Planning a social media campaign
5. Clo Willaerts, Marketing manager sanoma magazines
  How to make money with Social Media
6. Genevieve Tissot, Managing director BlueKiwi
  Client case social media platform
7. Kim Leunen, Account Manager S²Media
  Why you should join / Define your goals / How to Measurements & tools / Case - tips & tricks
8. Evan Van Lissum, Managing partner The Parking Lot
  Social branding : New kids on the blog
9. Bart de Waele, Co-founder Talking Heads
  Nike Running & Social Media
10. Didier Ongena, Director Microsoft Advertising
Meer info op www.socialmediaforum.be.

Ik zal er alleszins zijn - jullie ook?
Social Media Forum geschreven door Bart in: opleiding

Tags: event, forum, opleiding, social media