Sperrobjekt Weblog

While preparing the April meetup of the PHP User Group Rheinhessen, Christian came up with an idea: Let's take a look at one of the least used and most "exotic" internal functions of PHP and discuss them. Soon, the question arose, "which functions are only infrequently used?" - A: "Let's take a look at PHP repos on Github!"

After studying Github's Search API, it soon became clear that it's not possible to search all PHP repositories for functions this way. What I had to do was to write a simple crawler that POSTed search queries to the search form on the Github website (while respecting the rate limit, of course).

The results were parsed and saved to a JSON file, and I built a bar chart that visualizes the collected data:

"The most frequently used PHP functions on GitHub" vollständig lesen

Seit gestern unterstützt Github das offene GeoJSON-Format zur Repräsentation von Geodaten. GeoJSON-Dateien werden nun mittels Leaflet direkt auf einer Landkarte angezeigt. Mit Leaflet selbst ist das zwar auch sehr einfach zu bewerkstelligen, aber in Github funktioniert alles völlig automatisch.

Um mit dem neuen Feature und überhaupt mit GeoJSON herumzuspielen, habe ich ein neues Repository angelegt und angefangen, Fußballstadien in GeoJSON abzulegen. Genauer: Die Stadien der Vereine, die kommende Saison in der Regionalliga Südwest spielen (Herzlich Willkommen, OFC ;P). Das Ganze ist nur eine Spielerei, aber natürlich sind Interessierte eingeladen, das Repo zu forken und zu ergänzen

Die Daten für die Bundesländer habe ich übrigens im Repo deutschlandGeoJSON gefunden. Weitere hilfreiche Tools beim Erstellen der Liste waren neben der Wikipedia und Openstreetmap vor allem der GeoLocator und GeoJSONLint.

Kurzes Update: Die Vector Tiles der interaktiven Karten werden von MapBox geliefert, die einen ausführliche Artikel zu den neuen Github-Karten veröffentlicht haben. Außerdem bieten sie ein Geocoding-Script für Google Spreadsheets an.

Only two days after I pushed the first version of my VersionEyeBundle for Symfony2 to GitHub, Fabien Potencier announced SensioLab's new Security Advisories Checker. This service work quite similar to VersionEye, but instead of uploading your composer.json file your composer.lock file is required to figure out which dependencies are really installed - and if there are any known security issues.

SensioLabs have an upload form in the browser, but conveniently offer an API, too. And, of course, the code of their security-checker is on GitHub. So what could be more natural than to add the results of the security check to the Web Profiler Toolbar right next to all the other useful information? Right. I wrote a second bundle, called VulnerabilitiesBundle, that displays security advisories in the toolbar and the profiler view.

Please keep in mind that this is an early development version that is only intended for use in DEV environments (even if it will be stable someday). It just doesn't make sense on production servers. Feel free to fork, test, and report any issues you encounter. Of course, contributions in the form of pull requests, are more than welcome

At last week's Webmontag Frankfurt (?), Robert Reiz talked about continuous updating of dependencies with VersionEye. VersionEye, in its own words, is a

cross-platform search engine and crowdsourcing app for open source software libraries.

Essentially, the service tracks more than 170.000 libraries in languages like Java, Ruby, PHP, Python, and many more, and monitors any updates to those libs. Registered users can keep track of their projects and the libraries used in these projects. If any updates occur upstream, VersionEye sends out a mail. As a developer, you don't have to manually check on all the GitHub repositories anymore, VersionEye does that for you.

VersionEye also allows you to create beautiful graphs like this one here on the right. It also lists all the licenses of all the libraries used in your project, an let's you see which libraries you use most often.

Using it with PHP

Adding a PHP project to the service couldn't be simpler (if you use Composer, which you should!): Just upload your composer.json to VersionEye, and you're all set up. The same goes for project files like package.json (node.js), requirement.txt (Python Package Index), pom.xml (Maven) or Ruby Gemfiles. You can also connect VersionEye to your GitHub account, and it will notify you of outdated dependencies in your repositories.

Robert also said that there already is a VersionEye module for ZF2 and the ZendDeveloperTools that calls the VersionEye JSON API to track dependencies. However, I could not find a Symfony2 bundle with this functionality. So I wrote one.

"VersionEyeBundle for Symfony2" vollständig lesen

Geben wir es ruhig zu, der PHP-Code von Serendipity ist nicht mehr State of the Art, sondern zum großen Teil noch auf dem Stand von PHP 4. Dass dieser Code immer noch sehr zuverlässig funktioniert, und ob und wie mit dem aktuellen Stand umzugehen ist, soll hier nicht das Thema sein. Ich möchte hier auf die Entwicklung von Serendipity-Plugins eingehen, die nicht umsonst in einem eigenen Repository leben. Deren Qualität lässt sich mithilfe von Unit Tests sicherstellen.

PHPUnit für Plugins

Auch wenn die Grundfunktionalität von Serendipity durch Unit Tests abgedeckt ist: Die Plugin-Entwicklung ist bisher nicht so einfach zu testen. In meinen letzten Projekten waren Unit Tests mit PHPUnit ein zunehmend zentraler Bestandteil der Entwicklung. Entweder damit ich nachträglich sicherstellen konnte, dass Klassen und Methoden bei Veränderungen und Refactoring noch taten, was sie tun sollten; oder weil ich testgetrieben entwickelte, das heißt zuerst die Unit Tests und dann erst den zu testenden Code schrieb. Dieses Vorgehen möchte ich nicht mehr missen, und es hat mich gestört, dass es bei der Entwicklung von Serendipity-Plugins nicht ohne Weiteres möglich war.

Daher habe ich mich hingesetzt und PHPUnit so in meine lokale Serendipity-Installation, die ich zum Entwickeln verwende, integriert, dass ich einzelne (Event-)Plugins separat testen kann. Die spezifischen Herausforderungen ließen sich recht schnell überwinden:

• In Serendipity werden Plugins stark getrennt vom Core über Event-Hooks ausgeführt. Diese Hooks müssen natürlich einzeln getestet werden können.
• Viele Variablen sind als global deklariert oder werden per Referenz "herumgereicht". Das erfordert einige Workarounds, die heute dank Dependency Injection und ähnlichen Entwurfsmustern zum Glück überflüssig sind.
• Data Fixtures: Um Serendipity für die Tests "hochzufahren", wird eine Datenbankverbindung benötigt. Mir ist es bisher nicht gelungen, eine der unter Database Testing aufgeführten Methoden umzusetzen. Besser gesagt: Ich war einfach zu faul und habe die nötigen Daten in einer SQLite-Datenbank hinterlegt.

"PHPUnit für die Entwicklung von Serendipity-Plugins" vollständig lesen