Wanneer je aan meerdere PHP projecten werkt krijg je er vroeg of laat mee te maken dat deze projecten met verschillende PHP versies werken. Je kunt dan meerdere omgevingen hiervoor inrichten, maar het is ook mogelijk om meerdere versies tegelijkertijd op één en dezelfde omgeving te draaien.
In dit artikel leg ik je in 10 eenvoudige stappen uit hoe je dit pijnloos kunt doen.
Als developer heb je natuurlijk een ontwikkelomgeving nodig. Je kunt daarvoor een server inrichten of op je eigen machine een ontwikkelomgeving inrichten. Als je voor het laatste kiest, dan raad ik je aan om voor een ontwikkelomgeving in een virtual machine te kiezen, omdat dat een aantal belangrijke voordelen biedt.
Interfaces zijn één van de minst begrepen features van PHP. Op zich is dat niet zo gek want op het eerste gezicht doen interfaces eigenlijk niets. Een class met een aantal lege functies, wat moet je daar mee?
In een taal als Java zijn interfaces heel normaal en gebruikelijk, maar in PHP lang niet altijd. Ik denk dat dat komt omdat Java en PHP anders worden toegepast. Java is echt full blown OOP en wordt meestal gebruikt voor zware en professionele applicaties van b.v. banken. PHP wordt ook steeds vaker voor zwaardere applicaties gebruikt, maar ook voor hele eenvoudige websites, vooral toen PHP net ontstond. PHP is van origine een scripting taal die zich langzaam steeds meer heeft ontwikkeld tot een echt object-georiënteerde programmeertaal. En daar horen interfaces bij.
Het meest interessante wedevelopment nieuws van deze week:
Elke zichzelf respecterende developer gebruikt Git of zou dit moeten doen. Vooral het werken met branches is in Git een no-brainer en één van de beste features. Zelf werk ik voornamelijk op de command line met Git en dan is het wel handig om direct te kunnen zien in welke branch je werkt. Met het OS van mijn keuze is dit echter geen standaard feature, maar dat kan gemakkelijk opgelost worden.
Afgelopen week plaatste ik hier een crossbrowser scriptloader welke extern Javascript asynchroon laadt en daarbij de volgorde van de scripts behoudt.Veel zogeheten third party scripts zoals Google Analytics en de talloze share buttons van o.a. Facebook en Twitter worden echter via inline Javascript ingeladen en zijn niet altijd even bevorderlijk voor de laadtijd. Tijd dus voor een scriptloader die ook inline Javascript asynchroon laadt
Eén van mijn stokpaardjes is optimalisatie en ik probeer dan ook alles uit de kast te halen om een website zo snel mogelijk te laten laden. Zo ongeveer 80% van de laadtijd van een website bestaat uit het laden van de pagina in de browser en hier valt dan ook de meeste winst te halen. Javascript kan tijdens het laden voor veel vertraging zorgen en dus is het raadzaam om scripts die niet direct nodig zijn pas ná het laden van de pagina op te halen. Hiervoor bestaan scriptloaders zoals LabJS en de load method van Modernizr. Ik besloot om zelf een compacte scriptloader te schrijven
Collega Yuri Vorontsov deed een opmerkelijke ontdekking toen in eerste instantie bleek dat een flinke uitbreiding van het ColdFusion cluster een verslechterd geheugengebruik opleverde. De applicatie waar we beiden aan werken is een zeer inefficiënte legacy applicatie welke rond het einde van het jaar flink meer traffic te verduren krijgt. Omdat deze applicatie beyond repair is en binnenkort vervangen wordt is de enige oplossing dan meer capaciteit. Onze verrassing was dan ook groot toen de monitoring juist een slechter geheugengebruik leek weer te geven
Een scherpe observatie van Adam Tuttle op zijn blog Fusiongrokker. Zoals heel veel developers gebruikt Adam Chrome voor development vanwege de uitstekende developer tools. Hij merkte op dat de prefetching feature van Chrome niet alleen heel mooi is, maar ook onverwacht voor problemen kan zorgen als je niet oplet. Adam lette wel op en stelt dat je prefetching beter kunt uitzetten bij het testen van je website
Na een discussie met een ColdFusion collega over de geldigheidsduur van een sessie realiseerde ik me eigenlijk pas dat mijn begrip van session timeouts in PHP niet goed was. In ColdFusion is het heel eenvoudig om aan tegeven hoe lang een sessie geldig blijft bij een periode van inactiviteit. In PHP is dit lastiger en het werkt bovendien anders
Omdat Javascript aan de client kant, oftewel in de browser draait hebben we te maken met cross-browser issues. Wat door de ene browser wel wordt ondersteund werkt in een andere browser niet of misschien net iets anders. Om ervoor te zorgen dat je script in alle browsers correct werkt moet je dit soort verschillen dus kunnen detecteren.
Vanaf het ontstaan van Javascript wordt dit al gedaan met browserdetectie en dat is vanaf het begin al geen goed idee geweest.
Omdat Javascript vanaf het begin is gebruikt (misbruikt?) door allerlei "script kiddies" die de code zonder nadenken in websites plakten hebben we vandaag de dag nog steeds te maken met de overblijfselen uit dat tijdperk, waar ik al eerder over schreef. In deze posting meer over een Javascript overblijfsel waar veel misverstanden over bestaan en dat is dan ook de reden dat het nog steeds regelmatig voorkomt
In de eerdere postings over de symptomen van dubieus Javascript schreef ik hoe slecht Javascript de performance van je site negatief kan beïnvloeden. Dit is vooral merkbaar bij DOM-bewerkingen die sowieso al zwaar zijn. Vooral DOM-bewerkingen die in een loop worden gedaan kunnen je site piepend en krakend tot stilstand brengen. Gelukkig zijn hier twee simpele oplossingen voor
Wanneer je een Cache-control header met statische content meestuurt - en dat zou je zeker moeten doen - dan is file versioning een vereiste. Dit houdt in dat je de bestandsnaam van statische content, zoals o.a. CSS, Javascript en plaatjes, verandert met een versienummer wanneer het betreffende bestand verandert. Maar ook als je niet aan caching doet is dit sterk aan te raden
Javascript draait client-side, oftewel in de browser, en het voordeel daarvan is dat er geen netwerkverbinding nodig is om bewerkingen uit te voeren. Het betekent wel dat slecht Javascript een browser heel traag kan maken of laten crashen.
Het is dan ook goed om aandacht te besteden aan goede performance. Gelukkig kan dat al makkelijk door fouten te voorkomen die voortkomen uit hersenloos programmeren of - daar is 'ie weer - copy-paste Javascript.
In deel 1 van de symptomen van dubieus Javascript schreef ik over de fouten in copy-paste Javascript: code die klakkeloos in een webpagina is geplakt zonder dat men weet hoe het nou eigenlijk werkt.
Soms blijft het bij verouderde code die wordt geplakt en die eigenlijk niet zo heel veel kwaad kan, maar vaker kan het echt fout gaan waardoor een applicatie vastloopt of de performance ervan wordt geschaad. In dit deel meer hierover
Eerder plaatste ik al een posting over slecht Javascript en deze posting is de eerste in een serie van tien over de symptomen van dubieus Javascript. Maar waarom over Javascript? Is Javascript dan zoveel slechter dan andere programmeertalen? En wat is er dan zo slecht aan?
Javascript zelf is niet slecht, integendeel zelfs, ik ben er een groot fan van. Javascript heeft wel een aantal eigenaardigheden en ook een bijzondere geschiedenis
Als je zoals ik aan een legacy applicatie werkt met veel oude code van bedenkelijk niveau, word je vaak al nerveus als je aan de Javascript moet beginnen die er ook in zit. Niet zelden is Javascript een soort van "sluitpost": code die er nog eens aan toe wordt gevoegd om het een en ander te verfraaien of cross-browser issues op te lossen. Twee symptomen van dubieus Javascript: inline code en foute eventhandlers
Weer een mooie toevoeging aan CSS, namelijk position:sticky. Voorlopig alleen nog ondersteund in Chrome Canary en Webkit Nightly maar het is te verwachten dat ook andere browsers spoedig zullen volgen.
Maar wat is position:sticky?
Het valt een beetje tussen position:relative en position:fixed in. Een element met position: sticky gedraagt zich hetzelfde als een element met position:relative totdat er bij het scrollen van de pagina een bepaalde offset wordt bereikt. Als die offset is bereikt gedraagt het element zich als bij position:fixed, totdat het parent element uit de viewport wordt gescrolled.
Degenen die me goed kennen en met me gewerkt hebben zullen hun wenkbrauwen fronsen bij deze kop. Zij kennen mijn bijna dagelijkse tirades tegen Internet Explorer en zo'n beetje alles wat met Microsoft te maken heeft.
Altijd maar die hacks die je moet toepassen om een site ook in IE draaiend te krijgen, hoe simpel de site ook is. Er is a-l-t-i-j-d wel wat met IE.
Okay, ik weet ook dat het XMLHttpRequest object een Microsoft uitvinding is, net als innerHTML en de drag-and-drop API. En die filters waren ook best cool, maar natuurlijk niet cross-browser en met beroerde performance, dus daar deed je niet veel mee. IE heeft ook goeie dingen gebracht, maar mijn favoriete browser zal het nooit worden. Ik wist echter niet dat IE nog véél meer innovaties heeft gebracht.
Bij het genereren en bewerken van de Google sitemap voor deze blog kwam ik voor een rare verrassing te staan: een correcte XPath-query die maar geen resultaten wilde geven. Als webdeveloper ken je dit probleem wel: je weet zeker dat je code klopt en toch gaat er iets mis.
Het probleem bleek te zitten in de default namespace van de sitemap.
Als je statische content serveert vanaf een subdomein of ander domein (en dat zou je moeten doen) en gebruik maakt van font-face, dan kun je er tegenaan lopen dat dit in Firefox niet werkt. Standaard staat Firefox namelijk geen cross-domain gebruik van fonts toe. Gelukkig is er een eenvoudige oplossing.
De captcha hiernaast kwam ik vanmorgen op een blog tegen toen ik een reactie wilde plaatsen. Omdat spambots tegenwoordig steeds beter in staat zijn om de tekst in plaatjes te lezen wordt de tekst vervormd om het lezen moeilijker te maken. En zoals je ziet is dat hier prima gelukt, deze captcha is simpelweg niet te lezen.
Het is ook niet de eerste keer dat ik een captcha tegenkom die heel moeilijk is, al is deze wel heel extreem. Voor de duidelijkheid: ik heb de captcha meerdere keren vernieuwd en meerdere keren was deze onmogelijk op te lossen.
Als je de broncode van deze blog bekijkt zie je behalve gecomprimeerde HTML (leve XSLT...) dat ik ook gebruik maak van microdata.
Naar aanleiding van een controversiële posting van Heydon Pickering ben ik me hierin meer gaan verdiepen en ook gaan toepassen. Microdata is en vorm van metadata die met attributen aan HTML-tags wordt toegevoegd om meer informatie aan de HTML toe te voegen. Dit is vooral nuttig om zoekmachine spiders een beter idee te geven van de inhoud van de pagina en hoe deze informatie dient te worden geïnterpreteerd. Daarnaast kan b.v. Google ook betere zoekresultaten weergeven, zoals in deze posting goed is te zien.
Voor de herbouw van de site van een klant ben ik op zoek gegaan naar het font wat werd gebruikt in de header. Deze was alleen beschikbaar als .jpg en de oorspronkelijke designer is niet meer bereikbaar. Aangezien een app als Evernote tekst in plaatjes kan lezen dacht ik dat er vast wel iets was om een font in een plaatje te identificeren. En dat is er: What the Font
Selfmade allround webdeveloper, met name geïnteresseerd in software-architectuur, internetmarketing en optimalisatie op het gebied van code, websitelaadtijd en serverperformance.