Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Anthony Ferrara:
All About Middleware
May 23, 2016 @ 11:06:10

Anthony Ferrara has written up a post for his site sharing more information about middleware and the PSR-7 proposal that's being discussed to help standardize interfaces with this popular form of application processing.

Last week, a proposal to standardize middleware for PSR-7 was introduced to the PHP-FIG. The general concept of middleware is not a new one, and has been in use in the PHP world for many years. Several people have raised significant concerns with the proposal, which have gone completely unheeded by the author. Let me go through the most major of these concerns, as well as show what a better proposal might look like.

He starts off with a brief look at the current proposal - the interface it defines and an example of a real world usage of it to check some attributes on the request/response. He gives a few more examples before getting into what he sees as the fundamental problem with the interface: that it passes in a response instance rather than creating its own ("what does $response mean inside the middleware?"). He's mostly talking about context and not knowing from one middleware to the next what kind of changes may have been made to the response. He also includes some of the arguments on the "for" side of including the parameter and an interesting list of middleware that does this modification prior to the next() call, making it difficult to determine the actual state.

He ends the post with a few other issue he has with the proposal including the use of the __invoke method name, a restriction on typing and the next method being callable. He makes a few suggestions of modifications to the proposal that he thinks could help make it better, correcting these issues.

tagged: middleware psr7 proposal opinion example problem

Link: http://blog.ircmaxell.com/2016/05/all-about-middleware.html

Paragon Initiative:
Solve All Your Cryptography Problems in 3 Easy Steps
May 12, 2016 @ 11:55:55

On the Paragon Initiative site there's a new post that promises a way to solve all of your cryptography problems in PHP with three simple steps.

Last year, we began developing Halite, a FOSS high-level wrapper for the PHP bindings to libsodium. We use Halite extensively in our own projects (including our upcoming CMS which has quite a few of its own innovative cryptography features baked-in).

As of version 2.1.0, we are confident that Halite solves all of the application-layer cryptography problems that most PHP developers face; and it does so in three easy steps. (For transport-layer cryptography, you should still use TLS, of course.)

Their three steps to effectively using Halite and libsodium in your application are:

  • Step One: Managing Cryptography Keys
  • Step Two: Encrypting or Authenticating with Halite
  • Step Three: Decrypt or Verify

Each step comes with example code showing how to use the tool to accomplish it. There's also a few other problems that are solved by using the library including generating encrypted password hashes and whole file cryptography.

tagged: cryptography problem halite libsodium steps keys authentication encrypt decrypt

Link: https://paragonie.com/blog/2016/05/solve-all-your-cryptography-problems-in-three-easy-steps-with-halite

HHVM Blog:
Improving Arrays in Hack
Nov 03, 2015 @ 11:46:14

On the HHVM blog there's a post talking about some of the updates they've made with array handling in Hack to help make it more efficient and overcoming some of the challenges in how they're being used.

Arrays are the ubiquitous data structure in PHP, used to represent everything from lists, associated lists, sets, tuples, or even a bag of data. This flexibility itself makes it challenging for Hack to understand how an array will be used. [...] If this was the only problem with PHP arrays, then the solution would be “simple”; make the type checker smarter (something we are working on). However there are a number of other semantic details around arrays that are nearly impossible to analyze statically.

They talk about some of the issues a bit more specifically including:

  • indexing of non-existent keys
  • key coercion
  • arrays containing references

They also talk about some of the legitimate use cases for arrays over the collections Hack offers, mostly do to with the values they could contain. The post ends with links to some of the other future improvements to the array handling in Hack and a look further out and their vision of replacing PHP arrays with Hack arrays and moving collections to a runtime library.

tagged: hhvm hack array improvement problem values collections

Link: http://hhvm.com/blog/10649/improving-arrays-in-hack

Michael Mikowski:
RESTful APIs, the big lie
Sep 09, 2015 @ 11:19:31

Michael Mikowski has a post to his site that suggests that a RESTful API is a big lie and that the concept should "rest in piece" and be replaced with something he calls a "JSON-pure API".

If you have read an internet developer resume or job posting in the past 10 years, then you might be forgiven if you think that RESTful APIs are gifts bestowed from the heavens by The One True Web Developer Deity. RESTful APIs are everywhere. Even the marketing folks are pushing them in sales material intended for CEOs and Human Resources-type folks. So how good of an idea are RESTful APIs really?

He starts with a look at where the concepts for a RESTful API originally came from and defines some of the most common concepts around them (verbs, request/response, etc). He then suggests that they're "pretty awful" and lists some of the larger problems he sees with them:

  • Problem #1: There is little agreement on what a RESTful API is
  • Problem #2: The REST vocabulary is not fully supported
  • Problem #3: The REST vocabulary is not rich enough for APIs
  • Problem #4: RESTful APIs are very hard to debug
  • Problem #5: RESTful APIs are usually tied to HTTP

He suggests that the way to move forward is to migrate to the "JSON-pure API" methodology, fixing most of the problems he listed. He describes this kind of API and how it simplifies the entire process and makes it "more reliable, easier to use, easier to port, and easier to debug."

tagged: restful rest api jsonpure problem lie opinion

Link: http://mmikowski.github.io/the_lie/

Dodge the thundering herd with file-based Opcache in PHP7
Aug 31, 2015 @ 11:55:37

The Tideways.io site has posted a tutorial showing you how to "avoid the thundering herd" of incoming requests to your application using a file-based PHP 7 opcode cache to reduce load and increase performance on your site.

In the last blog post about Fine-Tuning Opcache Configuration I mentioned the thundering herd problem that affects Opcache during cache restarts. When Opcache is restarted, either automatically or manually, all current users will attempt to regenerate the cache entries. Under load this can lead to a burst in CPU usage and significantly slower requests.

[...] In Rasmus talk at FrOsCon 2015 (Video at 12:30, Slides), he showed the persistent secondary file-based cache Opcache gets in PHP 7. It can read the generated opcodes from disk instead of having to recompile the code after cache restart. This happens only when the compiled opcaches are not found in shared memory.

They talk about the benefits that this caching can provide, not only to web-based applications but also to command line scripts. There's a mention of possible security issues if an attacker is able to read/write to the cache files (but permissions can help that). The post ends with how to install it on your own PHP 7 instance, using the --enable-opcache-file flag on compilation.

tagged: thunderherd opcode cache problem php7 example commandline

Link: https://tideways.io/profiler/blog/dodge-the-thundering-herd-with-file-based-opcache-in-php7

PHP Roundtable:
023: PHP's Major "Bus Factor" Problem
Jul 02, 2015 @ 08:27:16

The PHP Roundtable podcast has posted their latest episode - #23: PHP's Major "Bus Factor" Problem, hosted by Sammy Powers with guests from the PHP community: Samantha Quiñones, Davey Shafik, Chris Tankersly and Michelangelo van Dam.

Inspired by a lively Open Spaces session at php|tek 2015, we discuss how PHP's ecosystem could be threatened by a not-so-obvious bus factor and what we can all do to keep things thriving.

You can catch this latest episode either through the in-page video player or directly on YouTube. If you enjoy the show, be sure to subscribe to their feed too!

tagged: phproundtable podcast video ep23 busfactor language problem

Link: https://www.phproundtable.com/episode/how-the-bus-factor-may-negatively-impact-the-php-ecosystem

Frank de Jonge:
Packages vs. Components: The Dependency Problem.
Jun 26, 2015 @ 11:12:18

In a new post to his site Frank de Jonge makes a distinction between packages versus components, pointing out that components are always packages but packages are not always components, and what it really boils down to is a problem of dependency.

The PHP landscape has fully transitioned into its Package Age™ [...] However, due to PHP's nature, there are some problems. While packages are great for re-use outside of frameworks, dependencies are still an issue. Namespaces resolve conflicts between classnames, but they do not offer a solution to package versioning. Especially in a framework-context, this can become very problematic. A real-world-example for this is Guzzle.

In his Guzzle example he describes the main problem - when packages restructure or make changes incompatible with prior versions and dependencies conflict and both must be installed. He also points out that, while this is bad for just packages, it can be made even worse working with components (his name for framework-based packages). Problems he mentions are the previously mentioned dependency conflicts but also some unexpected quirks with how Composer chooses to install packages. He gives an example of this second one with the installation of the Symfony EventDispatcher component and how, upon closer inspection, Composer seems to be installing two versions of the library at once.

tagged: package component dependency problem conflict versions guzzle eventdispatcher

Link: http://blog.frankdejonge.nl/packages-vs-components/

Why Doctrine ORM is not suited for PHP
May 20, 2015 @ 12:09:42

The ByMyCTO.com blog has a recent post that makes the suggestion that the Doctrine ORM isn't suited for PHP...or to put it another way why they think it's not a good option for database integration.

I know, this title sounds like a troll. But it’s not, it’s a fact. I’m not saying Doctrine is a bad technology or shouldn’t be used. I’m just saying it’s not suited for PHP and this can lead to critical problems if misused.

He covers a few different topics including:

  • Differences between Java and PHP (and the fact that Doctrine's inspiration was Hibernate)
  • The "session problem" (entity serialization)
  • Identity Map, useless in a stateless environment
  • UnitOfWork, far too complex
  • EntityManager, too magical

Despite all of these points, he does remind the reader that Doctrine isn't useless or inherently bad, it's just that he sees it as reinforcing bad behaviors and suggests using something else.

tagged: doctrine orm avoid critical problem opinion

Link: http://blog.bemycto.com/software-architecture/2015-05-17/doctrine-orm-not-suited-php/

Peter Petermann:
A few thoughts about composer and how people use it
May 18, 2015 @ 10:17:43

In the latest post to Peter Petermann's site he shares a few thoughts about Composer and how people use it in the more modern PHP ecosystem.

Composer has changed the PHP ecosystem like now other tool introduced – almost everyone is using it today. Now, I have written about Composer before, and have always been a big proponent of using it. However, as i have spend some time with looking more closely on a few things, there is a few problems (some with Composer, some with how people (ab)use Composer) that I would like to write about.

He's broken the list up into six different point, each with a bit of explanation:

  • Composer gets slow and resource hungry
  • People are using composer as an installer
  • People use their own paths
  • People don’t adhere semver
  • People don’t tag their releases / don’t release
  • People release packages with dependencies to unstable versions

He ends the post by looking at each of these points and offering a brief one-liner way to help solve the issue (or at least minimize the problem).

tagged: composer opinion problem usage ecosystem package

Link: https://devedge.wordpress.com/2015/05/16/a-few-thoughts-about-composer-and-how-people-use-it/

/Dev/Hell Podcast:
Episode 58: I Have a Mouth Problem
Apr 06, 2015 @ 12:35:29

The /Dev/Hell podcast has posted their latest episode today: Episode 58: I Have a Mouth Problem with hosts and PHP community members Chris Hartjes and Ed Finkler.

So we kinda forgot we recorded this until a month after the fact. Whoops! This ep is all about side projects, kicking off with Chris and Ed talking about CBTTool, Ed’s electronic worksheet for folks with anxiety disorders. Then we discuss Chris’ new book The Grumpy Little Book of Hack, and Ed’s experience technical editing Modern PHP by Josh Lockhart. Then we get into a boring discussion about marketing. Plus we have STICKERS!

You can listen to this latest episode either through the in-page audio player or by downloading the mp3. If you enjoy the episode, you can catch previous episodes in their archives or subscribe to their feed for the latest shows as they're released.

tagged: devhell podcast ep38 mouth problem chrishartjes edfinkler

Link: http://devhell.info/post/2015-04-04/i-have-a-mouth-problem/