Minder geheugengebruik & maak je systeem ‘hack-proof’ met PHP 5.4

Er zijn behoorlijk wat ingewikkelde topics gerelateerd aan PHP dit jaar, zoals het geheugengebruik en het ‘hack-proof’ maken van je systemen. De PHP-community staat bekend om zijn grote open source projecten: deze zijn goed vertegenwoordigd op PHP Benelux 2013, een conferentie in België. Composer, GitHub en Zend Framework zijn onderwerpen die aan bod kwamen tijdens de presentaties.

Werken met Git

Tijdens de conferentie namen we deel aan twee workshops: Git and Github en een Testable code-workshop. Git is een versiebeheersysteem voor code. Het onderscheidt zich van andere systemen doordat het een snel en lichtgewicht systeem is. Door middel van live voorbeelden werd door Ben Straub uitgelegd hoe je het beste met Git kan werken en hoe anderen ermee omgaan. Zonder al te technisch te worden: het was een erg interessante workshop die niet alleen praktisch van aard was, maar ook inging op de vraag hoe Git onder de motorkap werkt.

Testbare code schrijven belangrijk

Hoe belangrijk het is om testbare code te schrijven, werd duidelijk tijdens de workshop (PDF) die werd gegeven door Tobias Schlitt en Benjamin Eberlei. In een ideale situatie moeten eerst testen geschreven worden, alvorens de werkelijke functionele functie wordt geschreven. Maar aangezien dit tijdrovend is, is dit in de meeste gevallen niet haalbaar. Wat wel belangrijk is, is dat code testbaar is. Op het moment dat er dan een bug ontstaat, moet er een test geschreven worden die bepaalt welk resultaat een stuk code terug moet geven.

Door bijvoorbeeld phpunit te gebruiken, wordt bij iedere nieuwe update getest of de code nog steeds zo werkt als zou moeten en voorkom je dat de bug ooit nog terug kan komen. In eerste instantie zal het wat meer tijd kosten om testbare code te schrijven. Echter, op de langere termijn zal het veel tijdswinst opleveren. Wanneer code niet testbaar is, zal het bij iedere bug steeds langer duren om het te repareren. Bij testbare code blijft het overzichtelijk en zal de tijd om bugs te repareren gelijk blijven.

Being grumpy for a living: blijf tegenwicht geven aan de optimisten

Chris Hartjes staat in de PHP-community bekend als iemand die veel klaagt over de dingen die hij tegenkomt tijdens zijn werk, bijvoorbeeld  rare creatieve code, code die niet volgens standaarden geschreven wordt en vooral over Microsoft. Zijn presentatie, met de titel ‘Being grumpy for a living’, beschrijft dat je in een bedrijf mensen nodig hebt om tegenwicht te geven aan de optimisten en altijd de ‘ja-maar’ vragen blijven stellen. Grumpy zijn is nuttig, maar je moet er niet in doorslaan. Met het juiste beetje tegenwicht blijft je project en bedrijf perfect in balans.

Regex-clinic: backtracking & looking forward

Direct na de keynote gaf Andrei Zmievski een regex-clinic. Programmeurs werken dagelijks met regex en maken de meest rare combinaties waar achteraf niemand meer wat van snapt. Deze presentatie was voor een ingewikkeld onderwerp als regexen vrij luchtig en duidelijk. Het beste had Andrei voor het laatst bewaard: onderwerpen als backtracking en looking forward. Deze onderdelen worden zelden gebruikt en liet menige hersenen kraken. De presentatie is een must read voor iedereen die met regexen werkt.

Kortere syntax en closures met PHP 5.4

Ondanks dat PHP 5.4 (PDF) versie al enige tijd uit is, wordt deze versie nog maar weinig gebruikt. Zoals we van PHP gewend zijn, worden vaak de beste onderdelen uit andere programmeertalen in een PHP-vorm gegoten. Zo kan er vanaf PHP 5.4 gebruik gemaakt worden van een kortere syntax om variabelen te definiëren, zoals we ook van Javascript gewend zijn, en daarnaast kan er gebruik gemaakt worden van closures.

Onnodige functies verdwenen

Een ander groot voordeel van deze PHP-versie is dat oude functies, die eigenlijk niemand meer zou moeten gebruiken, nu eindelijk weg zijn. Zo is de ‘safe mode’ verdwenen: die impliceert veiligheid, maar daar is een developer zelf verantwoordelijk voor. Ook de ‘magic quotes’ zijn verdwenen, deze functie zorgde ervoor dat speciale tekens in de database een slash kregen, zodat de database geen foute input kreeg. Nu word je gedwongen zelf de input te escapen. Daarnaast wordt nu standaard de output in UTF-8 formaat gegenereerd.

We hoeven ons dus geen zorgen meer te maken over speciale tekens en er hoeft niets meer met een meta-tag in HTML aangegeven te worden. Daarnaast zorgt PHP 5.4 voor een vermindering van 20% van het geheugengebruik en is het op veel plaatsen een stuk sneller dan zijn voorganger. PHP 5.4 is dus zeker het overwegen van het overstappen waard.

Met Selenium geautomatiseerde front-end testen

Selenium is een tool die geautomatiseerd front-end-testen uit kan voeren. Door middel van een Firefox-plugin kun je je acties binnen de website opnemen. Van muisklik tot het invullen van formuliervelden. Deze acties kun je vervolgens door Selenium laten afspelen.  Als beheerder van een website kan je nu geautomatiseerd controleren of formulieren op de site nog werken en daarna kijken of de juiste conversiepixels ingeladen worden. De opgenomen acties kun je vervolgens exporteren naar een UnitTest-systeem (PHP en Java worden ondersteund).

Op deze manier gebruiken wij Selenium dagelijks. Bij elke release van onze codebases wordt op een testserver de nieuwe versie van de website gelanceerd. Daarna wordt met Selenium alle interactie op de website getest, zodat we er zeker van zijn dat de website nog werkt na de codebase-update.

De regels van SOLID projecten

Er zijn een vijftal principes waaraan code moet voldoen om een SOLID project (PDF) te maken. SOLID is een afkorting die als ezelsbruggetje gebruikt kan worden en komt op het volgende neer:

• Single Responsibility Principle: één stuk code moet ook maar voor één functionaliteit gebruikt worden. Er mag maar één reden zijn om dat stuk code aan te passen.
• Open Closed Principle: het moet altijd mogelijk zijn een stuk code uit te breiden, zonder de code aan te passen.
• Liskov Substitution Principle: stukken code die afgeleid zijn van andere stukken, moeten zonder problemen vervangen kunnen worden door hun afgeleide code.
• Interface Segregation Principle: beperk het gebruik van geforceerde stukken code tot alleen de essentiële stukken.
• Dependency Inversion Principle: stukken code mogen niet afhankelijk zijn van code van een lager niveau.

Door je aan deze regels te houden, zorg je ervoor dat de code overzichtelijk blijft, dat collega’s ook begrijpen wat de code precies doet, dat de code testbaar is en dat het geheel makkelijk te onderhouden is.

Composer: externe code libraries managen

Composer is een tool die externe code libraries managed in softwareprojecten. Je geeft met een tekstbestand aan welke libraries je nodig hebt en wat hier de minimale versie van moet zijn. Vervolgens kun je composer het commando geven om een update te draaien en zo krijg je de juiste softwareversie in je project. Veel programmeurs houden dit nog zelf bij en dat kost veel tijd.

De database met softwarepakketten wordt onderhouden door de PHP-community. Zo kun je ook je eigen software libraries toevoegen aan de database. Ondertussen zijn er meer dan 6000 libraries beschikbaar voor composer, dus waarschijnlijk ook de library die je zoekt.

Je webapplicatie beveiligen tegen mogelijke cyberattacks

Ilia Alshanetsky is in het dagelijkse leven security engineer en heeft uitgelegd (PDF) hoe je je webapplicatie kan beveiligen tegen alle mogelijke cyberattacks. Tijdens zijn presentatie vertelt hij dat de huidige coderingen van wachtwoorden (bijvoorbeeld sha1, sha* en md5) relatief makkelijk te kraken zijn met een server vol grafische kaarten. Grafische kaarten zijn namelijk veel sneller in het rekenen met deze coderingen. Een machine met een stuk of twintig van die kaarten hebben een sha key binnen enkele seconden ontcijferd.

Maar gelukkig is er bcript ontwikkeld, waarmee je sterke wachtwoorden kunt creëren. Wanneer je een bcript-wachtwoord maakt kun je rekenkracht van je server toewijzen (hoe meer en langer, hoe sterker de sleutel): deze wachtwoorden kosten een hackingserver meer dan een dag om te ontcijferen.

Wat kan een niet-PHP-er leren van PHP Benelux?

De PHP-community staat bekend om zijn open source-projecten en vooral het delen daarvan. Op veel conferenties worden er wel cases getoond, maar wordt er vervolgens niet verteld hoe men het resultaat behaald heeft. Er komen veel cijfers aan bod over de gestegen omzet en de ROI die verbeterd is, maar niets over de tools en hoe deze ingezet zijn.

Deze conferentie staat er lijnrecht tegenover. Er zijn een aantal presentaties gegeven waarbij een probleem voorgelegd wordt, de presentator zijn oplossing presenteert en deze ook gepubliceerd heeft zodat iedereen hem kan gebruiken. Composer en het Symfony Framework zijn hier een goed voorbeeld van. Composer is ontstaan tijdens het PHPBB (een open source forum) en Symfony was eigenlijk alleen bedoeld voor de klanten van Sensio.

Lessons learned: zorg voor kwaliteit, stabiliteit & schrijf unit-testen

Nu de ene na de andere site gehacked wordt (LinkedIn en Twitter bijvoorbeeld) is security een hot topic, alles moet bullet-proof zijn. Maar security is niet alleen het dichtbouwen van je systeem, maar ook de kwaliteit en stabiliteit. Zorg ervoor dat je technisch team unit-testen schrijft en dat deze automatisch uitgevoerd worden bij elke release door middel van een continious integratie server (Jenkins bijvoorbeeld). Zo weet je dat de nieuwe features de oude niet gebroken hebben. Heb je een bug of lek in het systeem zitten? Met een unit-test kun je uitsluiten dat dit ooit nog voorkomt.