Evert PotREST is in the eye of the beholder (26.7.2016, 17:47 UTC)

The first time I came across the term REST must have been around 2005 or 2006 via Flickr, which was back then in many ways a pioneer in terms of how web applications should be built and designed.

REST, at the time, was a breath of fresh air and it seemed very sane in a world where SOAP and XML-RPC were dominant. I can look at a webservice straight from my browser? Wow. Returning simple XML documents instead of using XML as the transport made a lot of sense.

I’m not really sure if Flickr was the first to use the term REST for that type of service, but in my memory it played a fairly big part in popularizing it.

I used the wayback machine to find these early examples, but then quickly realized that the Flickr API has actually not changed!

But it’s not REST

It took me some time, but I slowly started realizing that this was actually not a REST service. Not before I deployed a similar API and stamped it “REST” though.

As it turns out, REST is more than “simple documents”. We learn we also need to use correct HTTP Verbs such as GET, PUT and DELETE where appropriate.

Over time the definition for me and many people around me evolves, which eventually brought me to a point where I found out what the original definition was all along.

REST stands for “Representational State Transfer” and was invented by Roy Fielding, one of the authors of HTTP/1.1 and described in his dissertation.

REST has a specific meaning and a ‘best practice way’ to implement it when using HTTP, and Flickr and pretty much anyone else joining the REST hype is getting it wrong, much to Fieldings annoyance (2008).

And he’s not alone. What follows is a storm of articles, conference talks, tweets and even some books describing what REST is and describing in what way many people got it wrong.

So what is REST?

Well, over time we’ve gotten better at describing what REST is. We now have the term HATEOAS, which rolls off the tongue amazingly. A service cannot call itself REST unless it’s also HATEOAS.

We also now have the Richardson Maturity Model, which is a bit like the seven stages of grief, but for REST. Basically, you cannot call your service REST unless you’re on Level 3 of the Maturity Model.

I’d highly recommend reading the fowler article, because it’s one of the best overviews. The maturity model maps out my personal learning curve as well.

But here’s the issue

I believe that “REST” is widely believed to be the “right” way to implement web services. The term is also almost universally used to describe services that actually are not hypermedia-driven a.k.a. not comformant with Level 3 of the Maturity Model.

Almost everyone gets it wrong.

But the thing that they got wrong is not necessarily the API they’ve built. It might be good (enough) and appropriate for what they are trying to accomplish. The thing they get wrong is that according to purists, they should not be calling their service REST, because it aint.

I think doing HATEAOS correctly is overkill for most people. Modelling it correctly is actually quite hard. It’s also prone to a lot of round trips.

A comment from Fielding:

REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release. There are more than a few software methodologies that portray any long-term thinking as wrong-headed, ivory tower design (which it can be if it isn’t motivated by real requirements).

The reality is that a lot of us actually do see the value of achieving short-term goals, preferring ease-of-use over correctness. We’re not building an API for the library of congress. Having lots of people use an API is probably more important than that API being relevant for multiple decades.

Truncated by Planet PHP, read more at the original (another 2754 bytes)

Michael Kimsaldefining functions inside a constructor (26.7.2016, 16:04 UTC)

Recently came across some code on a project that looks like this (code changed – it wasn’t this simple!)

class foo {
 public function __construct() {
 function foobar() { echo 'abc'; }
$c = new foo();

It was a bit more convoluted than this originally, but that’s the gist of what’s going on. To ensure ‘foobar’ was defined as a function, the code would $f = new foo(); which would ensure the global ‘foobar’ function was defined.

Sort of blew my mind that someone would build a whole lot of code this way. It’s “wrong” on a lot of levels, but… still works. I was hoping it wouldn’t work in PHP7, and we could use that as an excuse to rewrite, but… it works in PHP7, at least this code does – haven’t tried the entire project in PHP7, and I’m sure something *will* break, but it may not be this pattern.

Have not seen much around the PHP blogs/forums about this pattern, so I thought I’d post it here.

Do you do this? If so, why? If not, why not? It’s certainly not demonstrated anywhere in PHP docs or any tutorials, so I’m wondering how this sort of code forms in someone’s thinking.

I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Web Developer Freelancing Handbook

Voices of the ElePHPantInterview with Steve Grunwell (26.7.2016, 09:00 UTC) Link
PHP ClassesPHP Multithreading using pthreads extension (26.7.2016, 06:37 UTC)
By Dmitry Mamontov
A lot of PHP developers face situations on which they need to execute multiple tasks in parallel. This is the case for using multithreading solutions.

Recently I tried the pthreads extension and was pleasantly surprised. It is an extension that adds the ability to work in PHP running multiple tasks in parallel within the same process without any emulation, no magic tricks, no fake parallel tasks, it is real.

Read this article to learn more about the pthreads extension and how you can use it in your PHP applications to execute multiple parallel tasks.
SitePoint PHPCan We Have Static Types in PHP without PHP 7 or HHVM? (25.7.2016, 16:00 UTC)

Now that PHP 7 has been out for a while with interesting features like error handling, null coalescing operator, scalar type declarations, etc., we often hear the people still stuck with PHP 5 saying it has a weak typing system, and that things quickly become unpredictable.

Vector illustration of programmer's desktop


Even though this is partially true, PHP allows you to keep control of your application when you know what you're doing. Let's see some code examples to illustrate this:

function plusone($a)
    return $a + 1;

var_dump(plusone("1 apple"));

// output


Our function will increment the number passed as an argument by one. However, the second and third calls are passing a string, and the function still returns integer values. This is called string conversion. We can make sure that the user passes a numeric value through validation.

function plusone($a)
    if ( !is_numeric($a) )
        throw new InvalidArgumentException("I can only increment numbers!", 1);

    return $a + 1;

This will throw an InvalidArgumentException on the third call as expected. If we specify the desired type on the function prototype...

function plusone(int $a)
    return $a + 1;

var_dump(plusone("1 apple"));

// output

PHP Catchable fatal error:  Argument 1 passed to plusone() must be an instance of int, integer given, called in /vagrant/test_at/test.php on line 7 and defined in /vagrant/test_at/test.php on line 2

This error seems a bit weird at first, because the first call to our function is using an integer!

If we read the message carefully, we'll see that the error message says "must be an instance of int" - it assumes that integer is a class, because PHP prior to version 7 only supported type hinting of classes!

Things get even more awkward with function return arguments in PHP 5. In short, we can't lock in their types automatically and we should check the expected value after the function call returns a value.

Augmented Types

Prior to the release of PHP 7, the team at Box came up with a nice idea to solve the typing safety problem on their PHP 5 application. After using assertions, type hints, etc., they decided to work on a cleaner solution for this problem.

We've seen how Facebook pushed PHP a little bit forward by launching HHVM and Hack, but the team at Box didn't want to fork the PHP source code or modify anything in the core. Their solution was to create a separate extension called augmented types to parse the method's phpDoc and assert types on runtime.

Continue reading %Can We Have Static Types in PHP without PHP 7 or HHVM?%

Peter Petermanncomposer – what you should know (23.7.2016, 22:47 UTC)

composer – what you should know.

Last year I wrote a piece called “a few thoughts about composer and how people use it“. In that post I had a list of things which are problematic about how composer is used.

That post got widely recognized, linked an visited, but in general those issues still exist.

However lately I’ve had even more people asking questions (either on related forums, irc or even irl) about problems that stem from issue number 2: people are using composer as an installer (and sometimes Number 3 because of Number 2).

In that Post I already gave a quick opinion on how workflows with composer should look like, In this post I’ll try to give a few more pointers on how to use composer without creating a mess.

starting a project vs installing

I’ve seen create-project abused as an installer quite a few times, and it seems convenient and simple to do that – as create-project + a hand full of scripts can easy do an initial install of a project. That is not what it is made for.

Now you might be wondering “why not? its only stupid if it doesn’t work!” – the thing is that this solution is one that usually leads to the question “is there a way to have composer update the create-project stuff??” very shortly after. No there is not and there shouldn’t be one.

So what is create-project for, if not to install your awesome web app on someones server? It is made so you can kickstart new projects by using skeletons that set up a basic project for you, usually adding all the things that might need updating at some point as dependencies, minus the code for your own project.

I wrote an a post on building project skeletons for binpress a few years ago, so if you are a framework builder, or if you have the need to build a custom project skeleton for you, your company, check it out.

You might find ways to make create-project work for you as an installer besides the no-real-update-path (I’ve seen people build quite elaborate scripts, and only have files that overwrite files from dependencies in their project-package), but the truth is, you will have a lot of effort, with not too much gain.

I mentioned it in the toughts-about post: composer is not a tool to run on live machines, (despite that environment checking thing that might make you think it is), and in professional environments, where servers are configured and or behind a firewall, so they are not allowed to pull data from everywhere your install simply won’t work. (The same goes for shared hosting where users might not even have access to a command line).

adding packages to a project

Now this is no starter-tutorial for composer, so I won’t go into how semver restrictions should look (rule of thumb: as tight as necessary, as lose as possible).

What I’d like to get of my chest here is: dear php devs, start thinking about what you add as composer dependencies. Your common day to day tools (like phpcs, phpunit and so on are no dependencies of your project. If you really really must (that is if you have a good reason)) add them as a dev-depepency (require-dev), but even that in a lot of cases doesn’t make sense (and this is a sin I’ve committed too). Believe me when I say there is no joy when you end up having version constraint conflicts because several of your dependencies insist on installing phpunit in different versions.

Another rule of thumb: the only thing that you should require is dependencies that are necessary to be there when you will run the app in the live environment – things that are only necessary on your dev environment (mockups, debugbars etc) belong in your require-dev, tools that you use over multiple projects (such as phpunit) should be installed on your dev (and ci) environment globally, not with the project.

globally installed composer packages

You might not know this, but composer allows you to install packages globally. STOP don’t get excited about this, whatever it is you are planing to use this for, if its not a composer plugin you are most likely wrong.

Take for example Laravel: Its tutorial tells you to do composer global require laravel/installer which will install 8(!) packages, including such commonly used ones as symfony/process or guzzlehttp/psr7. Why is this a bad thing? Well, in my stack I have quite a few tools, and many of them use quite common packages, which would lead to regular occurrences of having to use old tools because one tool is blockin

Truncated by Planet PHP, read more at the original (another 7573 bytes)

Remi ColletNew "remi-php71" repository (23.7.2016, 13:47 UTC)

I've just open the remi-php71 repository for Fedora ≥ 23 and Enterprise Linux ≥ 6.

Current version is PHP 7.1.0beta1 with about 75 extensions which are already compatible.

emblem-important-4-24.pngThis repository provides developement versions which are not suitable for production usage.

The repository configuration is provided by the latest version of the remi-release package:

  • remi-release-23-4.fc23.remi
  • remi-release-24-2.fc24.remi
  • remi-release-6.8-1.el6.remi
  • remi-release-7.2-1.el7.remi

emblem-notice-24.pngAs for other remi's repositories, it is disabled by default, so the update is an administrator choice.

E.g. to update the PHP system version:

yum --enablerepo=remi update remi-release
yum --enablerepo=remi-php71 update php\*

emblem-important-2-24.pngAs some extensions are not yet available, the update may fail, in this case you have to remove not yet compatible extensions, or wait for their update.

PHP 7.1 as Software Collection stay in "remi-safe" as there is no conflicts with the base packages.

SitePoint PHPCan We Use Laravel to Build a Custom Google Drive UI? (22.7.2016, 17:13 UTC)

In this tutorial, we’re going to build an app that talks to the Google Drive API. It will have file search, upload, download and delete features. If you want to follow along, you can clone the repo from Github. Creating a New Google Project The first thing that we need to do when working with […]

Continue reading %Can We Use Laravel to Build a Custom Google Drive UI?%

Voices of the ElePHPantInterview with Robert McFrazier (22.7.2016, 09:00 UTC) Link
PHP ClassesPHP and JavaScript Innovation Award Report July 2016 Edition - April 2016 nominees (22.7.2016, 05:34 UTC)
By Manuel Lemos
This is the July edition of the Innovation Award podcast hangout recorded by Manuel Lemos and Arturs Sosins to comment on the outstanding features of all the past month nominees and winners PHP and JavaScript packages, the prizes that the authors earned, starting with the nominees from the month of April 2016.

Listen to the podcast, or watch the hangout video to learn why the nominated packages were considered to be innovative, as well the current rankings of the Innovation Award Championship by author and by country.
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP