Bradley HoltNortheast PHP Conference 2014 (21.8.2014, 15:58 UTC)

The Northeast PHP Conference 2014 in Cambridge, Massachusetts is just over two weeks away (Saturday, September 6th and Sunday, September 7th). We’ve got a great lineup of talks this year including talks on coding standards, content strategy, unit testing, PHP 5.6 (and beyond), leadership and teamwork, object-oriented programming, profiling (Xdebug and Cachegrind), Internet of Things, code quality, continuous integration, web security, Composer dependency management, Hip Hop Virtual Machine (HHVM), responsive emails, REST APIs, automated web testing (Jenkins and Selenium RC), API first development, and much more. We also have two awesome keynote speakers. Steve Krug, author of “Don’t Make Me Think” and “Rocket Surgery Made Easy”, will be giving the opening keynote. Frances Berriman of Code for America and former front-end development lead for GOV.UK will be delivering the closing keynote.

Important Notes:

Link
Derick RethansOn Backwards Compatibility and not Being Evil (21.8.2014, 15:31 UTC)

On Backwards Compatibility and not Being Evil

This is a repost of an email I sent to PHP internals as a reply to:

And since you're targetting[sic] the next major release, BC isn't an issue.

This sort of blanket statements that "Backwards Compatibility is not an issue" with a new major version is extremely unwarranted. Extreme care should be taken when deciding to break Backwards Compatibility. It should not be "oh we have a major new version so we can break all the things"™.

There are two main types of breaking Backwards Compatibility:

  1. The obvious case where running things trough php -l instantly tells you your code no longer works. Bugs like the two default cases, fall in this category. I have no problem with this, as it's very easy to spot the difference (In the case of allowing multiple "default" cases, it's a fricking bug fix too).

  2. Subtle changes in how PHP behaves. There is large amount of those things currently under discussion. There is the nearly undetectable change of the "Uniform Variable Syntax", that I already wrote about, the current discussion on "Binary String Comparison", and now changing the behaviour on << and >> in a subtle way. These changes are not okay, because they are nearly impossible to test for.

    Changes that are so difficult to detect, mean that our users need to re-audit and check their whole code base. It makes people not want to upgrade to a newer version as there would be more overhead than gains. Heck, even changing the $ in front of variables to £ is a better change, as it's immediately apparent that stuff changed. And you can't get away with "But Symfony and ZendFramework don't use this" either, as there is so much code out there

As I said, the first type isn't much of a problem, as it's easy to find what causes such Backwards Compatibility break, but the second type is what causes our users an enormous amount of frustration. Which then results in a lot slower adoption rate—if they bother upgrading at all. Computer Science "purity" reasons to "make things better" have little to no meaning for PHP, as it's clearly not designed in the first place.

Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding << and >> is not one of those, and subtle changes to what syntax means is certainly not one of them.

Don't be Evil

Link
Brandon SavagePHP 5.6 is coming next week (21.8.2014, 13:46 UTC)
According to PHP.net, PHP 5.6 will be released next Thursday. This is an incremental release of the PHP language, offering a few new features. Yet even though this release is relatively small in features, the features included are powerful and will change the way each one of us develops. PHP 5.6 is easy to install, […]
Link
Liip Integrate Varnish and Nginx into PHP applications with FOSHttpCache (21.8.2014, 12:23 UTC)

Earlier this week, I released version 1.0 of the caching proxy library FOSHttpCache and the Symfony2 FOSHttpCacheBundle. The library implements talking to caching proxies to invalidate cache, the bundle integrates the library into Symfony2 and adds other caching related features to Symfony2.

The library is all about talking to caching proxies to do active cache invalidation. It also provides the foundations for the User Context caching scheme that allows to share caches that do not depend on individual credentials but common roles or permissions of users.

The Symfony2 bundle FOSHttpCacheBundle integrates those features into Symfony2, using the configuration, providing annotations for invalidation, invalidating by Symfony2 routes and a default user context implementation based on the user roles. On top of this, the bundle allows to configure caching headers on request patterns, similar to the Symfony2 security component, and adds support for cache tagging.

Both library and bundle are well documented and thoroughly tested. The testing setup includes integration tests running a Varnish or Nginx instance. The test cases can also be reused for functional testing in your applications.

The cache header rules concept has been ported over from the LiipCacheControlBundle which is now deprecated. A migration guide is provided to update your projects.

Development of this started when I met David de Boer from driebit at last years SymfonyCon in Warsaw. He presented DriebitHttpCacheBundle which started from the cache invalidation, while the LiipCacheControlBundle started at caching headers. But both bundles had started to overlap already. We decided to build one common codebase that does both tasks. After more than half a year of writing better tests, refactoring and properly documenting, the code is now in a very good state. Besides David, a shoutout has to go to Joel Wurtz for contributing the user context implementation, Simone Fumagalli for the Nginx integration, Christophe Coevoet (stof) for his valuable feedback and reviews, and all the other contributors of the library and the bundle (some of those coming from the LiipCacheControlBundle git history).

Link
SitePoint PHPPINQ – querify your datasets – introduction (20.8.2014, 16:00 UTC)

You may have heard of LINQ (Language-Integrated Query), a “set of features introduced in Visual Studio 2008 that extends powerful query capabilities to the language syntax of C# and Visual Basic”.

It provides necessary interfaces and syntax to perform various queries on a given dataset so that operations like filtering, sorting, grouping, aggregating, etc can be performed.

PINQ (PHP Integrated Query) is “based off the .NET’s Linq, and unifies querying across arrays/iterators and external data sources, in a single readable and concise fluent API”. (Excerpted from PINQ’s official site)

Why another query language?

PHPers are very much comfortable with executing queries with either raw SQL statements or via ORM. We select the data from a database, process it and display it in a chosen format (say, a table form). If we need another set of data, we issue another statement, process the returned dataset and display it.

In normal cirucumstances, this process is both sufficient and efficient.

But there are cases where this process simply won’t work. Take, for example, a typical e-Commerce website. The user enters one search keyword (say, “router”) and the site displays every matching item. The initial search may only search items with their description, category or tags containing the keyword. Next, the user will start to fine tune the search results by selecting a brand, a price range, etc.

This fine tuning process is called “faceted” search. Some database engines (like SOLR) have this capability built in (as described in this series: Using Solarium for SOLR Search) but obviously MySQL does not come with this functionality.

That does not mean, however, that MySQL can’t provide such features. After all, it is all about constructing a new SQL statement and fetching the data again. This has some disadvantages, however:

  1. The criteria of the SQL statement, i.e., the “where” and/or “group by” part, can get very complicated after SQL construction.
  2. As the SQL statement will be very dynamic, it can’t be optimized and will make indexing more difficult.
  3. It will create a huge overhead when communicating the SQL statement back to the db server.

In these cases, PINQ may come in handy. It is a PHP version of the LINQ library which provides filtering, sorting, grouping, aggregating, and indexing on a given dataset.

Preparation

In this series of two parts, we will demonstrate how to use PINQ to mimic a “faceted” search. We will use the sample book collection application’s data (see Data Fixtures in Symfony2 on how to dump the sample data) but with some slight modifications.

Also, we will use Silex, a very light-weight PHP framework and Bootstrap CSS to simplify the app setup. Please follow the instructions in their respective websites on how to set up a Silex web app and integrate Bootstrap CSS.

The sample data we used in this demo is slightly modified and I have uploaded to the repo for this demo. The source code can also be found there.

PINQ Installation

The recommended PINQ installation is to modify the composer.json file that comes with Silex and add one more line in its require section:

{
    "require": {
        "silex/silex": "~1.1",
        "twig/twig": ">=1.8,<2.0-dev",
        "doctrine/dbal": "2.2.*",
        "symfony/twig-bridge": "~2.3",
        "timetoogo/pinq": "~2.0"
    }
} 

Continue reading %PINQ – querify your datasets – introduction%

Link
Christopher JonesRouting PHP memcached calls to Oracle Coherence (19.8.2014, 18:30 UTC)

A new post Getting Started with the Coherence Memcached Adaptor from David Felcey shows how PHP memcached calls can automatically be routed to store data in Oracle Coherence 12c. This is possible now Coherence 12.1.3 supports Memcached clients using the Binary Memcached protocol. David's post shows how the Coherence Memcached adaptor can be configured as a proxy service that runs in the Coherence cluster. There's nothing particular to configure in the PHP application, except to enable memcached.use_sasl = 1

So what is Coherence? It is an "in-memory data grid solution", with a number of advanced features. You can read more in the Oracle Coherence 12C Data Sheet.

Link
Paul M. JonesOn Project Structure; or, The Framework/App Is Not Special (19.8.2014, 15:05 UTC)

(I apologize for the hasty writing here; this subject makes me impatient.)

Reading this post from Code Rabbi makes me reflect on project structure and organization. Frankly, most project structures (as from CodeIgniter, Cake, and all the popular frameworks since then) strike me as misdirected. They’re examples of why the project maintainers think their code is somehow special and different, and that the application built from it is also somehow special and different.

Your framework and application code are not special. Their code does not go in a special place. There’s no need for a top-level “app” directory with its own special subdirectories. There’s no need for a special naming convention to keep your different application-specfic code in specific places.

We had PSR-0, and now have PSR-4, and the Composer autoloader, to handle all that for you. Just use namespaces. All you need for code at the top level of your project is a “src” directory, where all your app code goes, just like all your library code goes in a “src” directory in a library package.

Instead of /app/controllers and /app/models, you have /src/Controller and /src/Model, or however else you want to organize your namespaced code. Then there’s no need for a special autoloading system or for hard-coded paths just for your application-level code. Add one single line to Composer that points to the src directory and voila, everything inside it loads for you.

That’s it. Nothing special. Just like every other library in your system.

(Again, this was hastily written. Please ask for clarficiation if you feel you need it.)

Link
labs @ Qandidate.comOpen sourcing our feature toggle API and UI (19.8.2014, 14:15 UTC)

In our previous post we released our toggle library and showed how to use it in your PHP project, but our goal was to toggle features without the need for a deploy. To accomplish this we created an API with an AngularJS frontend. In this blogpost we’ll show you how the API works and how we use it in combination with the AngularJS frontend.

∞ labs @ Qandidate.com Permalink

Link
Lorna MitchellRunning Multiple Versions of PHP (19.8.2014, 13:32 UTC)

When I advise people about upgrading their PHP version, I say things like "just run your test suite with the new version" "just grab the new version and try your site with the built-in webserver". A couple of people recently have asked for more detail on how to actually achieve these things so here's a quick primer on getting new PHP without touching anything to do with your existing PHP installation.

Install Your New PHP Version

(These instructions are for *nix systems; I have literally no idea how it works on Windows)

You will want to download the source code of your desired version of PHP, then compile it. The key thing here is that we'll put this version of PHP in a different location than your operating system would like to put PHP by default - and so we'll avoid overwriting anything.

Go and choose your version from http://php.net/downloads.php. Download it into its own directory somewhere and extract the files.

Now we'll configure the source, but here is the key ingredient: we set a prefix so that it'll be installed into a separate directory and not interfere with anything. Make a command like this with your path in:


./configure --prefix=/path/to/toy/php

Now we're all set and we can compile the code and install it to the related location:


make
make install

The make step builds the binaries and the make install step moves them to the correct location - so you may need to sudo make install if your user doesn't have write permission to the location you set in the prefix earlier on.

You're basically done :) Check everything is working by doing:


/path/to/toy/php/bin/php -v

This should show you what version of PHP you just built.

Checking Your Application With Your New PHP Version

Whatever you have in place for your usual test/build process, you can go through and have it use your /path/to/toy/php/bin/php everywhere it would usually run a php command. This can mean fiddling with environment variables or hardcoding paths in places while you try this out - so if you modify your tools make sure you're making those changes on a branch in your source control tool.

To test out your code with the webserver, you just need to start it using the new PHP version. For me, that command looks like this:


/path/to/toy/php/bin/php -S localhost:8080

I am seeing more PHP projects being upgraded now, where once they would have been shipped onto a set version, deployed to the server, and left there until they needed replacing. Now we build applications, not just websites, and those need to grow and live along with the companies they exist to serve. The much smoother upgrade process in PHP as well as tools like the webserver make upgrading platforms a perfectly advisable thing to do and I hope the outline above helps someone to make that leap!

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

Link
Cal EvansInterview with Tess Flynn and Larry Garfield (19.8.2014, 05:00 UTC) Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP