PHP Day 2017 (Dresden)

PHP Day 2017 (Dresden) August 24th, 2017, by Matthew Setter

As I traveled home from PHP Day 2017 in Dresden, I decided to put my thoughts together about the conference, and share them with you, if you weren't there to enjoy the day yourself.

PHP Day 2017 is the third time the PHP Day conference has been held, in Dresden (Germany). It's a local, community conference, organised by the PHP community in Dresden and the surrounding area.

If you don't want to read, and instead just want to listen to a run-down of the conference, check out episode #27 of Free the Geek.

It's Getting Bigger

This year it had one, key, difference: sponsors! To be perfectly honest, I've never been to a developer conference which wasn't sponsored. What's more, I don't see anything wrong with sponsors; though I know some people do.

To me, though, sponsors help make the event possible. Like anything in life, conferences cost money. If you don't have sponsors, you're either not going to be able to do a lot, or you're going to price your tickets out of reach of many, potential, attendees.

So having sponsors can be a win-win situation. They provide conferences with extra funding, which covers the cost of the venue, food, drinks, lanyards, websites, as well as beer! In return, they get exposure for their brand to a very targeted audience.

What's not to love about that arrangement? This is being said not having organised a conference, purely as someone who's attended them for around nine years. That said, let's get to talking about the conference.

The Conference

The conference is smaller than many I've been to. It's held on one day, has one track, and finished up with two lighting talks. By contrast, I'm used to much larger, multi-track conferences, with un-conferences as part of the schedule as well. Some examples are PHPUK, and ZendCon.

I got to talking about this with the deep-thinker, and gentleman, @localheinz (Andreas Möller) during the day. He said that he preferred a one-track conference, as you didn't get stuck having to choose between equally good talks.

I'd not given it that much thought up until that point. But when he said it, I remembered several times when I'd had to choose between what seemed like two equally valuable talks. It also reminded me that sometimes I'd pick one talk over another, only to find out that the talk's content didn't always match the abstract.

As a result, I'd either sit through them, not learning much, or quietly slink out of the talk and try and catch the remainder of the other talk. Having only one track took a lot of these problems away.

The Talks

Enough of me blabbing, let's get to the talks. The first one was about PHIVE, by Arne Blankerts and Sebastian Heuer. If you've been using Composer to manage your PHP project's dependencies (and I hope that you have) then you'll have experienced a sense of circular dependency hell.

If you've not, let me explain it through a quick example. Your project requires three external packages. You've listed them in your project's composer.json and then run either composer install or composer update.

At that point the fun begins, as you see a message telling you that the package installation cannot complete because of a package conflict.

Why'd this happen? Because one of the three, core, packages that you need requires several other packages. But another of the three blocks that package being installed, as it needs the same package either at an earlier or later version.

See the problem? There's more to it than this simple example can highlight. But you get the idea.

Given that, some developers got frustrated and started working through another approach to satisfying project dependencies in PHP projects. It's called Phive (The PHAR Installation and Verification Environment). Here's a brief overview from the package's documentation:

PHIVE makes installation easy by providing a means to resolve the given alias to an actual download location, including the verification of the certificate supplied by the server. Once downloaded, the archive's SHA1, SHA256 or SHA512 hash is verified and so its OpenPGP/GnuPG or OpenSSL signature.

Instead of re-downloading the same phar multiple times, the archive is kept at a shared location (by default in ~/.phive) and only a symbolic link is created for the project. You can of course also explicitly request a copy of the phar to be made in favor of symbolic links (use --copy).

PHIVE lets you build a Phar archive of the dependencies that your project needs. What's more, it handles verification of the hash and signature. That way you know that it's not been tampered with as well.

A set of command-line tools come with the project that help manage the building of PHAR archives, and the project has support for such tools as PHPUnit, phpDocumentor, and PHPLOC.

Now the catch is, as best I understand, that a package has to be updated to work with PHIVE, it won't "just work". However, it seems like the project's got both momentum and a significant amount of enthusiasm behind it. So I'd suggest, if it continues to gain traction, that it may be only a matter of time before your favourite package of choice is supported.

Middleware Web APIs in PHP 7.x by Jan Burkl

This was an interesting talk for me because I've been a long-time Zend Framework user, and have recently published a Zend Expressive book. I didn't really learn much new, I'll be honest. However, to see that Zend is so enthusiastic about middleware-based applications is very encouraging.

What was interesting, was to hear from someone inside Zend about their perspective. One little tidbit that I wasn't, completely, aware of was Matthew Weier O'Phinney officially deprecating the Zend Framework 1, 2, & 3 naming structure.

This is a good thing, as many users have commented to me that the numbering convention was increasingly confusing, especially in light of the new package naming convention, such as Diactoros, Stratigility, and Zend Expressive.

PostgreSQL as a NoSQL Database by Stephan Hochdörfer

This was the second time that I heard Stephan's talk on PostgreSQL as a NoSQL database. It's still a great talk which uncovers and helps spread the fact that PostgreSQL is much more than just a relational database.

The key difference in this version of the talk was that it was a lot shorter than before. It was condensed down to about 40 - 45 mins. That said, I learned about other JSON-related functionality available in PostgreSQL.

If you've never considered PostgreSQL as anything other than a relational database, if you've felt that you need to have a mix of relational, graph, document (and other NoSQL) databases in your application's mix, then you'll want to watch this talk. Stephan showed how you can have everything in one database.

Now whether you would, and how you would do it, comes down to your design decisions and trade-offs. But it's good to know that PostgreSQL, a very stable and mature product, offers the ability to implement NoSQL functionality.

One thing worth a particular mention is part of a discussion between Stephan, Marco (Pivetta), and myself after the talk was finished. We were all talking about the talk and the subject of the architecture of MySQL and PostgreSQL was brought up.

I think Marco said that he had read a lot about the design decisions that the PostgreSQL team took over the years, and how they're really paying off now.

To provide more background, if you've used PostgreSQL over the years, then you'll know that, for quite some time, it's always lagged in performance against MySQL. However, as of version 9.2, there is only a negligible difference in speed between the two vendors.

Marco said that the development team wasn't all that concerned about the speed difference in the earlier times, as they had a commitment to what they believed would be the better application architecture over the long term.

Then Stephan mentioned that he'd been talking with someone at MySQL, who said that they're increasingly having trouble implementing new features, owing to their initial designs for speed. It's turning out to be harder for the MySQL team to add new features these days, whereas it's far simpler for the PostgreSQL team.

The Good, the Bad, and the Complicated of Event Sourcing by Marco Pivetta

Now here was a talk that I was keen to hear (again). I was fortunate to sit down with Marco when he was in Nuremberg some months ago, before he had given the talk for the first time.

It was fascinating to see both how excited he was about Event Sourcing, as well as just how fascinating the topic is. If you're not familiar with Event Sourcing, to quote Martin Fowler:

Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes.

Marco discussed the topic in a lot of detail - to be fair, since I've not spent as much time developing of late, I had to really focus to keep up. In some parts he went quite quickly, in others the pace was just right.

As I didn't take as much in this time as I'd like, I don't have much to offer. That said, watch a recording of it, and let me know what you think.

The prooph/micro framework by Alexander Miertsch

Before I get into this talk, I want to say thank you to Alexander for an unexpected compliment.  He said that "I look younger in person" (it's a sad fact of having gray hair).

That said, as with Marco's talk on Event Sourcing, I didn't really take in too much from Alexander's talk on the prooph/micro framework. This isn't to say that I didn't try, just that it took some concentration (near the end of the day) to take in the concepts.

This was impacted by the fact that the approach that Alexander's approach to development is markedly different from my current approach. Given that, my coverage isn't going to be that extensive. So here's some information that I've collected from the framework's documentation.

prooph components is a set of loosely coupled PHP packages that can be composed to a powerful toolbox. prooph components include everything to get you started with CQRS and Event Sourcing. Enterprise-ready CQRS and Event Sourcing packages for PHP with support for the most famous PHP web frameworks.

These components are:

  • Event Sourcing
  • Event-Store
  • Snapshot-Store
  • Persistent Projections
  • CQRS Service-Bus
  • Message Queue

Sorry that I don't have much more to offer here. What I heard, I was very intrigued by. But I'm going to have to find a new project so that I can try out the framework and the related concepts.

Note: after I published this post, Alexander was kind enough to get in touch with me. Here’s a slight paraphrase of what he shared with me about the project.

prooph components is like Zend or Symfony but exclusively for CQRS and Event Sourcing. In fact it can, and is, used together with Zend, Symfony, and other web frameworks. You can say that it is a replacement for an ORM, and provides a way to design your system with a clear focus on behavior and not state.

The topic of my talk "prooph/micro" is just one of our components and it is experimental. PHP is not a functional language, but we tried to use basic ideas from the functional world and combine them with event sourcing. The experiment turned out to be very interesting and I think we will see more functional style in PHP in the future.

Having said this, prooph components are not all implemented in a functional way but only prooph micro. With our core packages you can work in the common OOP fashion like shown by Marco in his talk.

Pushing PHP's limits with ReactPHP by Christian Lück

Rounding out the day, was a talk about ReactPHP. Christian lead in with a very excited pitch about being passionate about performance, and getting the most out of the applications that he develops. Which is what lead him to start ReactPHP.

ReactPHP is "Event-driven, non-blocking I/O with PHP". To quote the package's documentation:

ReactPHP is a low-level library for event-driven programming in PHP. At its core is an event loop, on top of which it provides low-level utilities, such as: Streams abstraction, async dns resolver, network client/server, http client/server, interaction with processes. Third-party libraries can use these components to create async network clients/servers and more.

And here's a code example, also from the documentation, so that you get a glimpse into how it works:

$loop = React\EventLoop\Factory::create();

$server = new React\Http\Server(function (Psr\Http\Message\ServerRequestInterface $request) {
    return new React\Http\Response(
        200,
        array('Content-Type' => 'text/plain'),
        "Hello World!\n"
    );
});

$socket = new React\Socket\Server(8080, $loop);
$server->listen($socket);

echo "Server running at http://127.0.0.1:8080\n";

$loop->run();

I've never used ReactPHP, and to be honest I wasn't sure what to expect. However, Christian went over a number of different use cases that a project with ReactPHP could be used for.

One of the most interesting, especially in a live demo, was a live chat server. After all, what could possibly go wrong, right? That said, people were, gladly, very respectful, and didn't interact childishly. What's more, the demo's, allowing for glitches with the projector, worked flawlessly.

Throughout the demos, Christian showed just how fast PHP can perform. I was a bit doubtful at first about the performance figures quoted. But that was just initially. Perhaps I was too stuck in a mindset of what PHP could achieve.

It was impressive to see that PHP (without any extensions) could perform so highly. Thanks for setting me straight Christian.

A Special Bonus

Sara, the diversity ElePhPant

Before I finish up, I want to say a special thank you to Holger woltersdorf (the event's main organiser), who was kind enough to give me “Sara”, the diversity ElePHPant.

She was sitting up on the podium the whole day, and right from when I first spied her, I hoped that there might be the opportunity to have her for my little girl.

I was guessing, however, that it might not happen, as these kinds of things, generally, go to people in the organising team, speakers, or others (more worthy than me wanting it on a whim) as a reward for all their hard work and committment.

However, as luck would have it, when I asked, at the end of the conference what it might take to acquire her, Holger just gave her to me. Let's just say that my little girl's been cuddling her every night in bed, ever since I gave her to her.

 Another Special Bonus

I got to meet @localheinz

And last — but definitely not least — at long last I got to meet Andreas Möller, otherwise known as @localheinz! Andreas and I worked together for a while at Refinery29, but have been chatting intermittently online for, actually, I don't remember how long.

He's been a very sagely person, one who I've looked up to as someone who I can learn so much from. I don't think I've ever told him that. But I've learned so much from him in the time we've known each other.

Whether from the development advice that he's shared with me, the feedback he's given me on PRs, or just by reading his code and discussing various programming concepts, I've definitely grown as a developer.

Anyway, he messaged me out of the blue a week or so before the conference, when he saw that I was going to be there and suggested that we meet up. From that moment on, I knew that the conference was going to be so much better of an experience.

After all, life's all about the people you know and connections you make with them - no?!

In Conclusion

On the whole, I really enjoyed the time in Dresden at PHP Developer Day 2017. I was impressed by just how well put together the conference was, how smoothly everything seemed to go, the quality of the talks, the food, the drinks, and the venue.

While it's my first time, it won't be my last. I'm definitely aiming to be there next year.


Like That?

Don’t miss my next post. Drop your email in the box below, and get it straight to your inbox, PLUS exclusive content only available by email. No spam, and you can unsubscribe at any time.