Article archive

Thoughts about choosing a programming language


As our team is currently discussing which language we want to use for the next project, I thought about that question a lot recently. Here I will share some of my thoughts about the criteria I use to evaluate a programming language.

We mostly write the usual kind of server applications, and I think for our use case most languages are good (or good enough) in terms of performance. The focus of this article is mainly on developer productivity, or effectiveness, instead.


Cool scala features, compared to PHP


I worked with PHP in my day-to-day job for more than three years now. Since PHP is not really the best tool for many projects, I looked around for other languages available. There were two languages which looked interesting to me:

  • go, which is very opinionated
  • scala, which is not at all opinionated (multi-paradigm etc.)

In many ways, this two languages are contrary. One important goal for the go-lang creators was to keep the language simple, so that it can be used efficiently after a short period of learning time. Scala on the other hand is quite feature-rich, and generally needs a lot of time to learn.

While I liked the idea of a simple (but still well designed) language, I was also impressed by the possibilities that an advanced language like scala can give us. So I decided to invest time in learning scala.

In this article, I want to describe some of the features I like very much, and compare them with PHP. If you're interested in the go language, please have a look at this article, describing go for php devs. It's written by Evert Pot, which decided to go with go ...

Another thing to note: This is not intended to be an article about how bad PHP is. PHP has improved a lot in the last years, both the language itself and the way that the majority of the community writes code. In my opinion PHP may be the right tool for some projects. But from a technical perspective, I think there are better options available today.

So now, let's look at scala:


Lazy evaluation with PHP Generators


After learning different concepts from functional languages, I came to realize that some of them can be applied to PHP code as well. I lastly wrote a small library helping to process CSV data structures. I wrote functions to process collections of data to return Generators. PHP Generators are a kind of iterators, which generate values only as they are needed (i.e. the iterator generates values lazily). All of the functions are designed in a way that they can be combined to a "pipeline". The pipeline itself is a function which returns a Generator. This concept of combining functions to build more complex functions is also called function composition. This is a core concept of any functional programming language, most often there is a very elegant syntax for it. An example in Haskell:

numOfWords = length . words

Here, length is a function which takes a List and returns its size; and words is a function which splits a string into a List of words. I just defined a new function, numOfWords, which composes this two functions into a function which counts the number of words in a string.

While there is no such elegant syntax for this in PHP, the concept can still be applied. Under the hood, the . operator in Haskell is a function itself, which takes two functions as input, and returns a new function. PHP allows us to build such a function ourselves:

function compose($fnA, $fnB): \Closure
{
  return function ($input) use ($fnA, $fnB) {
    return $fnB( $fnA($input) );
  }
}

This does the same as the . function is haskell, except that it applies the functions from left to right instead of right to left. I think it's easier to understand this way in PHP code.

So, to summarize this introduction, we will talk about this two concepts in the following article:

  • lazy evaluation (using PHP Generators)
  • composing functions

If this concepts are new to you, at this point you're probably asking what advantages this concepts can bring to you. By explaining the code I wrote for my CSV Tools, I hope you see where this concepts can be used in the real world to improve PHP code.


Deptrac zur Verwaltung der Abhängigkeiten zwischen Software-Komponenten


Deptrac ist ein neues Tool, das uns dabei hilft, die Abhängigkeiten zwischen einzelnen Komponenten unserer Software zu verwalten. Sinnvolle Regeln für diese Abhängigkeiten zu definieren ist eine wesentliche Aufgabe des Software-Designs.

Ich glaube, dass Deptrac eine große (und positive) Auswirkung auf die Entwicklung der PHP-Community haben kann. Um das zu Begründen, werde ich in diesem Artikel erst einige Worte über Software-Design, insbesondere Software-Komponenten schreiben, um dann zu versuchen, den Nutzen zu zeigen, den ich mir von diesem Tool für die Qualität von PHP Projekten erhoffe.


Makefiles for PHP Projects


GNU Make is a proven and well known build tool. For PHP projects though, it is not often used. First, there's no "compile" task which requires a build tool. Maybe it's also considered to be a Linux only tool, and most PHP projects strive to be platform independent. If you're running your applications on Unix systems only, then consider using it for your next project -- you might be surprised how useful this tool may be! Here's what I like the most about it:

  • It uses simple shell commands (and you can do a lot with Unix tools!)
  • It lets you define a proper dependency graph, and only "builds" what needs to be rebuilt. Thus it can save a lot of time.

The goal of this article is to show valid use cases where Makefiles could be used in PHP projects. It's not a good tutorial to learn the syntax and to get started. For this, see the manual or let google help you :-)

If you need an example of a Makefile which could be used in PHP projects, see this simple project skeleton which I recently published on github.


Routing with PHP's built in server


PHP has a built in development server, which is very handy during development. However, I had some difficulties to get it working correctly. After a lot of debugging, and reading bug reports and the php documentation I learned some things:

  • It can serve static files
  • It has some uncommon rules how to set some $_SERVER variables when the url path contains a dot. (The reason for this is probably that a dot in the url path indicates that the resource is a file rather than a dynamically generated document). And this is not documented very clearly!

If you're setup is not working but you don't have time to read the article, try my gist for a quick example.


"PHP-Projekte in Mini Apps aufteilen: Micro Services mit Kompromissen"


Ich möchte in diesem Artikel gerne einen Ansatz vorstellen, um komplexere Projekte etwas zu modularisieren. Mit komplex meine ich vor allem solche, die verschiedene Komponenten von Drittanbietern verwenden, auf die man vielleicht selbst nicht direkten Einfluss hat. Probleme bei solchen Projekten können sein:

  • Sie "passen" nicht zu dem im Hauptprojekt verwendeten Framework, nutzen z. B. ein eigenes Mini-Framework, das die Code-Menge nochmal erheblich erhöht.
  • Es entstehen Abhängigkeitskonflikte, oder die Komponente hindert uns daran, für unser Code die neuste Version einer Library zu verwenden.

Als praktisches Beispiel:

  • Das eigentliche Projekt ist eine komplexe Website auf Basis des Zend Frameworks
  • Für die Dateiverwaltung auf dem Server wollten wir einen bestehenden Filemanager verwenden. Dieser bietet ein composer package, und einen Front controller (index.php Datei), die man an einem beliebigen Ort, z.B. unter /fileadmin installieren sollte.
  • Dummerweise verwendet der Filemanager das Symfony Framework
  • Für unsere App haben wir zusätzlich zum ZF noch die symfony/filesystem Komponente eingebunden.

Soweit funktioniert alles. Nun möchten wir aber das neuste Feature der Filesystem Komponente nutzen, wir erhöhen also in unserer composer.json Datei die Version von symfony/filesystem. Beim anschließenden composer update dann die Überraschung: Geht nicht, unser Filemanager benötigt eine andere Version. Abhängigkeitskonflikt.


PHP Entwicklungsumgebung mit Docker, Nginx und PHP-FPM


Es wurde schon einiges über Docker geschrieben. Ich denke, dass dessen Konzept der Isolation von Komponenten in eigene Container gerade für die Entwicklung von PHP Web-Anwendungen hervorragend geeignet ist. Da PHP selbst keinen Server mitbringt (der für Produktionsumgebung geeignet ist), ist mindestens eine zusätzliche Komponente, nämlich der Webserver, zwingend notwendig. In 98% der Fälle kommt dann noch ein Datenbank-Server hinzu. Die "Mindestanforderungen" an die Entwicklungsumgebung, um erst einmal starten zu können, sind also relativ hoch. Es gibt also Verwendung für die verschiedenen Container, aus denen eine Docker-Anwendung sich zusammensetzt.

Dieser Artikel ist kein Tutorial, sondern soll nur die Eignung von Docker als Entwicklungsumgebung für PHP-Entwickler diskutieren. Er ist so geschrieben, dass keine spezifischen Vorkenntnisse zu Docker notwendig sind, um diese Diskussion nachverfolgen zu können. Der Artikel soll natürlich dazu anregen, Docker selbst auszuprobieren, allerdings ist dafür die Materie doch zu komplex, um in einem kurzen Artikel behandelt zu werden. Es gibt im Netz ausreichend Lesestoff dazu.