Gestern Abend habe ich im Rahmen des Treffens der PHP User Group Rheinhessen einige Tools, Helferlein und ausgewachsene Frameworks vorgestellt, die Entwickler beim Schreiben von Tests unterstützen können. In den vergangenen Monaten sind nämlich einige in meiner Bookmark-Liste gelandet. Viele dieser Tools sind opinionated, also eigensinnig, was durchaus kontroverse Meinungen in unserer Runde herausforderte.
Wir tauschten uns auch über Best Practices im Bereich Testing aus: Wie wichtig ist eine hohe Code Coverage? Sollten Test Cases im selben Namespace liegen wie die zu testenden Objekte? Wie gehen wir mit Testdaten in Datenbanken um? Sollte unter verschiedenen PHP-Versionen getestet werden (z.B. bei TravisCI)? Ich glaube, jeder konnte etwas vom gestrigen Abend für sich mit nach Hause bzw. mit ins Projekt nehmen.
Weil ich meine Slides relativ kurzfristig zusammengestellt habe, möchte ich sie hier (noch) nicht veröffentlichen. Die von mir gesammelten Tools will ich aber niemandem vorenthalten:
"Tester's Little Helpers" vollständig lesen
Seit geraumer Zeit besitze ich ein Arduino UNO, habe damit aber noch nicht viel mehr gemacht als ein paar LEDs zum Blinken zu bringen oder einen Servomotor anzusteuern. Vielleicht sollte ich mir endlich ein Ethernet-Shield dazukaufen, denn so völlig offline kann ich gar nicht mehr denken, weswegen mir da teilweise die Ideen fehlen O_o Außerdem werden die Arduino-Boards üblicherweise in einem vereinfachten C-Dialekt programmiert, der zwar einfach zu erlernen ist, aber auch nur bedingt Spaß macht (vor allem mit der offiziellen IDE) 
Zum Glück gibt es aber, wie bei Open Source-Projekten nicht ungewöhnlich, schöne Alternativen.
Firmata
Firmata ist ein Programm, welches - einmal auf das Arduino-Board übertragen - die Kommunikation mit Software auf einem anderen Computer ermöglicht. Firmata definiert gleichzeitig also auch das Protokoll, über welches mit dem Arduino (in beide Richtungen) kommuniziert werden kann. Wenn ich das richtig sehe, wurde Firmata zunächst für den Einsatz mit Processing entwickelt. Mittlerweile gibt es aber eine ganze Reihe von Client-Bibliotheken für verschiedene Sprachen.
Das Arduino-Board kann also von einem Host, auf dem die Software läuft, angesteuert werden; es können aber auch Sensoren oder z.B. ein Potentiometer ausgelesen werden. Für mich persönlich ergibt diese Kommunikation mehr Sinn als das pure Aufspielen eines Sketches, der dann auf dem Arduino-Board autonom vor sich hinläuft.
"Arduino mit PHP und Javascript programmieren" vollständig lesen
Test Driven Development soll auch Spaß machen, dachte sich Jeff Welch und forderte vor ein paar Tagen auf Twitter: „Make your tests fabulous“. Da ich mich tags zuvor mit Unit Tests für JavaScript mittels Mocha und Jasmine beschäftigt hatte, musste ich einfach antworten:
"NyanCat-Reporter für PHPUnit" vollständig lesen
Warum eigentlich API-Dokumentationen?
Eine gute Dokumentation ist wichtig für jedes Projekt, egal ob es sich dabei um ein von der Community entwickeltes Open Source-Tool handelt oder um eine für einen Kunden geschriebene Software. Eine API-Dokumentation erleichtert es Entwicklern, neu ins Projekt einzusteigen oder sich einen Überblick über alle relevanten Teile des Projekts zu verschaffen.
Ein weiterer Vorteil von API-Dokumentationen ist, dass sie sich schnell und automatisch generieren lassen. Dieser Schritt kann in den Build-Prozess integriert werden, so dass immer eine aktuelle, ggf. auch versionierte Dokumentation vorliegt. Sie sind sozusagen der leicht erfüllbare Mindeststandard für eine Dokumentation.
Denn, seien wir ehrlich, eine API-Dokumentation erklärt und veranschaulicht nicht (das machen Codebeispiele und handgeschriebene Dokumentationen), sondern ist eher eine Art Nachschlagewerk. Durch die immer besseren Funktionalitäten von IDEs verliert es sogar mittlerweile an Bedeutung. Ich persönlich schaue nur selten in einer API-Dokumentation nach, wenn ich das Projekt schon in meiner Entwicklungsumgebung vorliegen habe. Your mileage may vary
"API-Dokumentationen mit ApiGen erstellen" vollständig lesen
I suppose this post has to be in English because the PHP Benelux Conference 2013 was an international conference with participants from 17 countries. It took place in Edegem near Antwerp last weekend. Friday and Saturday that is.
Day 1
After four hours on the road, I arrived at the venue on Friday shortly after noon. The keynote by The Grumpy Programmer Chris Hartjes was scheduled for 13:20 so I had enough time to register and chat to some people. Most of them were from Belgium and the Netherlands, but I also met some German and Swiss guys there. The keynote was fun and addressed some important issues concerning software quality and security.
Next up was Igor Wieder's session on Silex Anatomy and Symfony Components, and it was a solid session although the focus was not on Silex so much, but on his microframework YOLO. Like Silex, it's based on the Symfony Components, but does some things differently.
I then skipped the next session slot and checked in at my hotel. Fortunately, I made it back in time for Kris Buytaert's session 7 tools for your DevOps stack. I really think DevOps is a great movement and would love to use more tools like those he talked about. But there's definitely a learning curve ...
Sadly, I missed the so-called "Social", the social event that evening, because I felt tired and slightly ill, so I preferred to go to bed early and collect my strength for ...
"My PHP Benelux 2013" vollständig lesen