Paul ReinheimerManaged Accounts at WonderProxy (22.8.2014, 01:14 UTC)

I’ve made plenty of mistakes in the code powering WonderProxy, perhaps most famously equating 55 with ∞ for our higher-level accounts (issues with unsigned tinyint playing a close second). Something I think I got right though, was the concept of “managed accounts”. It’s a simple boolean flag on contracts, and when it’s set, the regular account de-activation code is skipped.

Having this flag allows us to handle a few things gracefully:

  • Large value contracts
    By marking them as managed, they don’t expire because someone was on vacation when the account expired. They stay happy, the revenue continues, the expiry date remains accurate.
  • Contracts with tricky billing processes
    The majority of our contracts pay us with PayPal or Stripe. A selection of contracts however have complex hoops involving anti-bribery policies, supplier agreements etc. This gives us some time to get this ironed out.
  • Contracts where we’ve failed to bill well
    We occasionally make mistakes when billing our clients. When we’ve screwed up in the past, this helps ensure that there’s time for everything to resolve amicably.

This doesn’t mean the system has been without flaw. We currently get daily emails reporting on new signups, expired accounts, etc. It mentions all accounts that were not expired because of the managed flag.

Like most features, that was added after mistakes were made: we’d left some managed accounts unpaid for months. With better reporting, though, now, we couldn’t be happier with it.

Link
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
Symfony CMF1.2 first release candidate (21.8.2014, 04:00 UTC)

It is time for another update. The release process for 1.2 has begun with RC1 releases of all of our components and bundles. We expect final releases in the next few weeks, certainly before the end of Q3. Note that the documentation on symfony.com is still for 1.1, as currently we can unfortunately only render a single version. So please check the dev branch on the symfony-cmf-docs repository to see the updated docs. That being said, as the main code development efforts are now complete, we will now focus our energy on fixing any bugs reported for these releases as well as documentation. So expect to see much better documentation to be added on the dev branch for all the new features and changed.

However, the biggest new feature in this release is that we finally are preparing a stable release of RoutingAutoBundle. This Bundle automates the creation of routes based on rules. For example the Bundle can automatically create a route to any new content that was created. Or it can be used to automatically create redirect routes whenever a route is moved. Also we moved everything to use PSR-4 autoloading, which will likely not have a big impact for development except for shorter directory names.

In parallel we are also working on improvements for Jackalope and PHPCR ODM. Especially Jackalope Doctrine DBAL as well as PHPCR ODM will see major performance improvements with the next releases. PHPCR ODM also has many improvements related to events. If you want to keep up with work on PHPCR related topics we recommend you keep an eye on the news section on the newly designed PHPCR homepage.

Link
PHP: Hypertext PreprocessorPHP 5.4.32 Released (21.8.2014, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 5.4.32. 16 bugs were fixed in this release, including the following security-related issues: CVE-2014-2497, CVE-2014-3538, CVE-2014-3587, CVE-2014-3597, CVE-2014-4670, CVE-2014-4698, CVE-2014-5120. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.32 please visit our downloads page, Windows binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
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
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP