Paul M. JonesWhy MVC doesn’t fit the web (18.8.2017, 14:49 UTC)

[MVC is] a particular way to break up the responsibilities of parts of a graphical user interface application. One of the prototypical examples is a CAD application: models are the objects being drawn, in the abstract: models of mechanical parts, architectural elevations, whatever the subject of the particular application and use is. The “Views” are windows, rendering a particular view of that object. There might be several views of a three-dimensional part from different angles while the user is working. What’s left is the controller, which is a central place to collect actions the user is performing: key input, the mouse clicks, commands entered.

The responsibility goes something like “controller updates model, model signals that it’s been updated, view re-renders”.

This leaves the model relatively unencumbered by the design of whatever system it’s being displayed on, and lets the part of the software revolving around the concepts the model involves stay relatively pure in that domain. Measurements of parts in millimeters, not pixels; cylinders and cogs, rather than lines and z-buffers for display.

The View stays unidirectional: it gets the signal to update, it reads the state from the model and displays the updated view.

The controller even is pretty disciplined and takes input and makes it into definite commands and updates to the models.

Now if you’re wondering how this fits into a web server, you’re probably wondering the same thing I wondered for a long time. The pattern doesn’t fit.

Read the rest at Why MVC doesn’t fit the web.

Nomad PHPRefactoring Done Right (18.8.2017, 04:01 UTC)

November 2017 - US
Presented By

Brandon Savage
November 16, 2017
20:00 CST

The post Refactoring Done Right appeared first on Nomad PHP.

Nomad PHPAPI Tips From the Frontline (18.8.2017, 04:01 UTC)

November 2017 - EU
Presented By

Anna Filina
November 16, 2017
20:00 CET

The post API Tips From the Frontline appeared first on Nomad PHP.

SitePoint PHPHow to Master Your API Workflow with Postman (17.8.2017, 16:00 UTC)

Building good APIs is hard, and anyone who had the chance to do so can relate to this. A project can easily grow to become a mess. One can keep trying to adopt an approach to make it more enjoyable, like trying a documentation-first workflow, but something always feels clumsy.

I was trying out Postman lately, a tool we've briefly covered before, and I discovered that they're doing a great job by providing an integrated environment for different components of an API, like authorization, testing, documentation, versioning, etc.

Postman logo

In this article, we're going to walk through the different features that Postman provides and how we can organize them to make our API workflow less painful.

Making Requests

The first step to discovering Postman is making a simple API request and seeing the response.

Simple request

From the screenshot above we can see that the view incorporates different elements. The top bar contains the request method (in this case GET), and right next to it we specify the endpoint to make the request to. If the request has some params we can specify them by clicking the Params button, which will open a table for entering them. When ready, we can click the send button to initiate the request.

The next section contains five tabs:

  • Authorization: Specifies how to authorize the request. Like Basic Auth, OAuth2, etc.
  • Headers: Any header that should be sent with the request. Like content-type, Authorization, etc.
  • Body: Request body for request types like Post, PUT, etc.
  • Pre-request Script: JS code to be executed before performing the request. (More about this later)
  • Tests: JS code to validate the response payload.

The bottom section contains all the details about the response (status, time and size). The four tabs are self explanatory, except for Tests which contains the tests result if we have any (more about this later).


Postman supports all types of authorization, as we saw above. We're going to focus on token authorization set via header. You can read more about authorization here.

The header format that Postman will use is:

Authorization: Bearer <TOKEN>

Authorization header

Now, we'll go ahead and get a token we can use for our future requests. I'm testing on an in-development application of mine, but you can use any application you have lying around, or set one up quickly with Laravel as described here.

Not familiar with Laravel? Try our premium course - it's a comprehensive introduction, and you'll get the upcoming newer version of it automatically if you grab it in its current iteration!

Get token

At this point, we have a token to be used for querying data from the API as an authenticated user. However, copying and pasting the token for every request is tedious!

Environment Variables

This nice feature alleviates the pain of copy/paste and groups our variables in one place. An environment is an execution context: we may have a local environment, testing, staging, etc.

Postman has different scopes for variables:

  • Global
  • Environment
  • Local
  • Data

The global variables are available everywhere, separately from the selected environment. You can read more in the documentation.

We need at least three variables for now:

  • domain: current active subdomain company1, company2, etc.
  • url: our app URL.
  • token: Token for future authentication.

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

PHP: Hypertext PreprocessorPHP 7.2.0 Beta 3 Released (17.8.2017, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 7.2.0 Beta 3. This release is the third and final beta for 7.2.0. All users of PHP are encouraged to test this version carefully, and report any bugs and incompatibilities in the bug tracking system. THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION! For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. For source downloads of PHP 7.2.0 Beta 3 please visit the download page, Windows sources and binaries can be found at The first Relase Candidate will be released on the 31th of August. You can also read the full list of planned releases on our wiki. Thank you for helping us make PHP better.
Matthias NobackPreparing a Leanpub book for print-on-demand (16.8.2017, 14:35 UTC)

During the last few days I've been finishing my latest book, Microservices for everyone. I've used the Leanpub self-publishing platform again. I wrote about the process before and still like it very much. Every now and then Leanpub adds a useful feature to their platform too, one of which is an export functionality for downloading a print-ready PDF.

Let Leanpub generate a print-ready PDF for you

Previously I had to cut up the normal book PDF manually, so this tool saved me a lot of work. Though it's a relatively smart tool, the resulting PDF isn't completely print-ready for all circumstances (to be honest, that would be a bit too much to ask from any tool of course!). For example, I wanted to use this PDF file to publish the book using Amazon's print-on-demand self-publishing service CreateSpace, but I also wanted to order some copies at a local print shop (preferably using the same source files). In this post I'd like to share some of the details of making the print-ready PDF even more print-ready, for whomever may be interested in this.

Preparing the inside of the book

I found that several things needed to be fixed before all layout issues were gone:

  • Some lines which contained inline, pre-formatted code, like AVeryLongClassName, would not auto-wrap to the next line. Where this is the case, it triggers a warning in Createspace's automatic review process: the margin becomes too small for print. I fixed these issues by cutting these long strings in multiple parts, adding soft hyphens (\-) in between them.
  • Some images appeared to be too large. This was because Leanpub shows all images with a 100% width. Vertically oriented images will appear to be much larger than horizontally oriented ones. I added some whitespace in the images source file to force a "horizontal" rendering, but I later found out that you can also specify image positioning options, like width, float, etc.
  • Some images had a resolution that's too low for printing. When I realized, I started adding images and illustrations with higher resolutions than required. Unfortunately I had to redraw some of the illustrations manually in order to get a higher resolution version... Something to keep in mind from the beginning of the writing process!

The result of Leanpub's print-ready PDF export is a PDF containing colored code snippets and images. In order to turn it into a grayscale PDF document, I googled a bit and found a good solution. I now use Ghostscript to do the PDF conversion, using the following options:

gs  \
    -o /print/book.pdf \
    -sDEVICE=pdfwrite \
    -dHaveTransparency=false \
    -dProcessColorModel=/DeviceGray \
    -dEmbedAllFonts=true \
    -dSubsetFonts=false \
    -sColorConversionStrategy=Gray \
    -r300 \

This takes the book.pdf document from the /preprint directory, removes transparency, includes all used fonts, converts it to grayscale, and stores the images with a 300DPI resolution (which is excellent for print). It then saves the resulting PDF file in /print.

Preparing the cover

I designed the cover image using Gimp. The size and layout of the cover image are based on the number of pages, the thickness of the paper I wanted to use, the size of the PDF ("Technical", i.e. 7 x 9.1 inches) and the cut margin for the book printer. I put all this information in one spreadsheet (allowing me to use constants, variables, and simple derivations):

Guidelines for the cover image

I always miss Photoshop when I'm working with Gimp. It can do most of what I want; except store CMYK images... That's very unfortunate and frustrating. I've been trying to overcome this issue in various ways (upload an RGB image to a website to let it be co

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

Paul M. JonesThe “Micro” Framework As “User Interface” Framework (15.8.2017, 18:38 UTC)

(The following is more exploratory than prescriptive. My thoughts on this topic are incomplete and in-progress. Please try to treat it accordingly.)

tl;dr: “Micro” frameworks are better described as “user interface” frameworks; perhaps there should be corollary “infrastructure” frameworks; consider using two frameworks and/or two containers, one for the user interface and a separate one for the core application.


When we talk about “full stack” frameworks, we mean something that incorporates tools for every part of a server-side application:

  • incoming-request handling through a front controller or router
  • dispatching routes to a page controller or action (typically a class constructed through a DI container)
  • database, email, logging, queuing, sessions, HTTP client, etc.; these are used in a service, model, controller, or action to support business logic
  • outgoing-response creation and sending, often combined with a template system

Examples in PHP include Cake, CodeIgniter, Fuel, Kohana, Laravel, Opulence, Symfony, Yii, Zend Framework, and too many others to count.

When we talk about “micro” frameworks, we mean something that concentrates primarily on the request-handling and response-building parts of a server-side application, and leaves everything else out:

  • incoming-request handling through a front controller or router
  • dispatching routes to a page controller or action (typically a closure that receives a service locator, though sometimes a class constructed through a DI container)
  • outgoing-response creation and sending, often combined with a template system

Slim is the canonical PHP example here; others include Equip, Lumen, Silex, Radar, Zend Expressive, and (again) too many others to count.


I have asserted elsewhere that, in an over-the-network HTTP-oriented server-side application, the View (of Model-View-Controller) is not the template. The View is the entire HTTP response: not just the HTML or the body, but the status line, the headers, all cookies, and so on. That is, the full HTTP response is the presentation; it is the output of the server-side application.

If the HTTP response is the output, then what is the user input into the server-side application? It is not the form being submitted by the user, per se. It is not a key-press or button-click or mouse-movement. The input is the entire HTTP request, as sent by the client to the server.

That means the user interface for a server-side application is not “the HTML being viewed on the screen.” The user interface is the HTTP request and response.

Now, for the big jump:

If the user interface is the request (as input), and the response (as output), that means micro-frameworks are not so much “micro” frameworks, as they are “user interface” frameworks.

Consider that for a moment before continuing.


If it is true that “micro” frameworks are more accurately described as “user interface” frameworks, it opens some interesting avenues of thought.

For one: it means that full-stack frameworks combine user interface concerns with other concerns (notably but not exclusively infrastructure concerns).

For another: perhaps in addition to user interface (“micro”) frameworks, it would be useful to have something like a separate “infrastructure” framework. It might not even be a framework proper; it might only be a container for shared services that have no relation to any user interface concerns. (I can imagine extracting such a toolkit collection from any of the full-stack frameworks, to be offered on its own.)


Speaking of containers:

It is often the case, even with user interface (“micro”) frameworks, that developers will store their infrastructure and services objects in the framework-provided container. Or, that they will build “providers” or “configuration” for the framework-provided container, so that the container can create and retain the infrastructure and services objects.

But if it is true that the “micro” framework is a “user interface” system, why would we manage infrastructure and domain objects through a user interface container? (This a variation on “Why is your application/domain/business logic in your user interface controller?”)

Perhaps it would be better for the infrastructure and/or domain objects to be managed through a container of their own. Then that completely separate container can be injected into any user interface container. The benefit here is that the infrastructure and/or domain objects are now fully

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

SitePoint PHPPHPBot – Can a PHP Bot Help You Look up Documentation Faster? (15.8.2017, 16:00 UTC)

I came across PHPBot the other day (not to be confused with Botman or Fondbot) - a "chatbot" which helps you look up PHP manual entries and generates example code for them.

If you follow me on Twitter, you know I don't believe in chatbots being chatbots - as someone who's built some for both commercial purposes and personal ones, and as someone who was around in the age of IRC auto-responding scripts, I see chatbots as a little more than a marketing fad designed to impress today's Snapchat generation. However, every now and then one will appear that's actually useful. Could this be the one? Let's take a look.

Bot welcoming image


The idea is that you use the text input on the page to enter a PHP related term (like "ksort") and the application will reply with an explanation and some example code, like so:

PHPBot's reply to <code/>ksort input

Different queries will produce different responses. So, if you ask it for echo:

PHPBot's reply to <code/>echo

Continue reading %PHPBot – Can a PHP Bot Help You Look up Documentation Faster?%

thePHP.ccWhy Magic Quotes are gone in PHP 7 (15.8.2017, 07:00 UTC)
Nomad PHPA Practical Introduction to Snapshot Testing (14.8.2017, 04:01 UTC)

Speaker: Freek Van der Herten @freekmurze The basic idea of snapshot testing is that you compare the output of your code against a file that’s written on disk. That file is called a snapshot. If the output of your test matches up with the contents of that snapshot, it succeeds, otherwise, it fails. It’s a …

The post A Practical Introduction to Snapshot Testing appeared first on Nomad PHP.

LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP