Zendcon 2017

I attended Zendcon, out in Las Vegas, this year. I've been wanting to attend this conference for years, so I was excited to finally be able to attend.

For those unaware, Zendcon is the PHP conference. It was originally put on by Zend Technologies, who are responsible for several high-profile PHP projects (Zend Engine, Zend Framework, Zend Studio). Now in its 13th year, the conference is hosted by Rogue Wave who acquired Zend Technologies in 2015.

This discussion is going to be the dumping ground for my notes, observations, etc. from the sessions I attended.

Comments

  • Keynote: The Possibility of PHP – The Weird and Wonderful Stories of the Web and Where We’re Headed

    Zeev Suraski, one of the founding members of Zend Technologies, presented the opening keynote.

    The first part of his talk primarily focused on the diverse usage of PHP. He tried to give unique usages of PHP on land (the presentation layer of entertainment systems in some BMWs), air (the presentation layer of entertainment systems in some planes) and sea. He faltered on a real-world "sea" example, so he showed a video of him running PHP code on a laptop in a sealed, waterproof bag in his bathtub at home. Zeev also gave a brief live demo of an Alexa app, built with PHP (although it didn't work very well).

    The second half of Zeev's talk discussed how far they've come with PHP and what they're planning for the future. He talked about how PHP 6 was originally supposed to utilize JIT compilation, but while the performance simulations were fantastic, the real-world performance was actually worse than PHP 5. They struggled to identify why. In the process, they overhauled data structures and memory utilization in the language. These under-the-hood improvements ultimately lead to the birth of PHP 7. JIT was tabled. They're still seeing great performance improvements with JIT in simulated performance tests (it was claimed they sometimes rivaled C applications), but only marginal gains in real-world usage. Zeev's hope is that PHP will grow beyond web applications and the JIT implementation will shine there.

  • There's a Middleware for That!

    Matthew Weier O'Phinney, project lead for Zend Framework and a member of PHP FIG, presented this session. Mr. O'Phinney was one of the few folks who was kind enough to share their slides. If you want to take a look, you can see them here: https://slides.mwop.net/2017-10-24-Middleware-For-That

    This guy was very, very excited about the middleware.

    In his presentation, Mr. O'Phinney gave an very thorough example of using various HTTP middleware in an example request. You'd really have to take a look at the slides to appreciate it all. However, the basic idea is this: you take all the processing steps of an HTTP request you plan to use (CORS, authentication, CAPTCHA, etc.) and build a PSR15-compatible middleware class just for that step (or use one of the ones already available). Once you have your classes, you can build a workflow that allows you to easily customize the actions taken, per-route.

    This was one of the sessions I was more excited about, because I can see implementing these types of things in Vanilla to great effect. The flexibility of being able to customize our request handling to this degree, using standardized interfaces, is very promising.

  • Let the Architecture Emerge

    This session was presented by Jason McCreary. I'm pretty sure I saw this guy at ConFoo in Montréal.

    Mr. McCreary is not a fan of traditional software development. The main point of this talk was to discuss why traditional architecting is bad. He attempted to do this by recounting the history of one of his personal projects, Laravel Shift, which makes it easier to upgrade Laravel code between versions of the framework. The original (very procedural) code for the site was put on display. The presenter justified the inelegant code by saying it was quick to produce and effective at what it did. However, he admitted that iterative development was imperative for this approach. Over time, the original code needed to be updated to be more flexible and add features. He claimed he tried to only improve the code a little bit at a time and never any more than was necessary. The presentation was ended by showing what the site's current code looks like and...unsurprisingly, I guess, it still looked very "ineligant".

    My takeaway from this was: don't over-architect a project. Don't try to plan for every contingency. Build for what you know needs to be done. Add and improve through small iterations, as necessary.

    This is where I wised up and started recording sessions. You can check it out here: Let the Architecture Emerge

    Recommended reading: The Value of Software Design

  • Keynote: The New Revolution

    Samantha Quiñones gave the first day's afternoon keynote.

    This talk kinda threw me for a loop, because while it didn't especially have anything to do with PHP or development, it was a very interesting talk on the advent of the Internet. The speaker discussed specifics of the creation of the Internet, their own personal history with it and noteworthy pitfalls of blindly relying on these technologies or taking them for granted.

    There wasn't a lot to necessarily "learn" here, but it was an entertaining session. I recommend you listen to The New Revolution, if you find some free time.

  • Test Driving Test-Driven Development

    Another session with Jason McCreary. This was a live-coding session, so there aren't any slides. The presenter very much steered the feedback he was getting into a very specific direction. Because of this, he was able to provide an example GitHub repo that more or less follows the session: https://github.com/jasonmccreary/td-tdd

    Jason mentions he's been part of an "extreme programming" team. You might ask "what the hell is that?" According to Mr. McCreary, it's when you hook two developers into a single machine: two keyboards, two mice and two monitors. One developer writes a dead simple, failing test. The other developer writes just enough code to make the test pass. After the test passes, they switch roles. This goes back and forth until the project is complete. In this session, the two "developers" were the presenter and the audience.

    The three main talking points of this session were:

    1. In test-driven development, you have to have a failing test before you start writing code.
    2. Do not write more in a test than is necessary for it to fail.
    3. Only write enough code to make the failing test pass.

    This one was a little frustrating. The presenter frequently rejected common-sense suggestions from the audience, because they weren't simple enough. He really wanted people to make the absolute least amount of effort possible to get a test to pass. This often included nonsensical implementations, like "always return true" when testing if a value was empty. It was important to realize this was more of a thought exercise and not an endorsement of how actual development should be done. The speaker attempted to get people in the mindset of solving a very specific current problem and not jumping straight to what they think should be happening.

    If you want to hear the live coding session, you can check it out by clicking here.