Anthony FerraraA Followup To An Open Letter To PHP-FIG (17.10.2014, 11:00 UTC)
A few days ago, I wrote An Open Letter to PHP-FIG. Largely the feedback on it was positive, but not all. So I feel like I do have a few more things to say.

What follows is a collection of followups to specific points of contention raised about my post. I'm going to ignore the politics and any non-technical discussion here.

Read more »
Link
thePHP.ccJoomla PHPUnit Code Sprint (17.10.2014, 07:00 UTC)
Link
SitePoint PHPHow to use RabbitMQ with PHP (16.10.2014, 16:00 UTC)

AMQP (Advanced Message Queueing Protocol) is a network protocol that can deliver messages from one application endpoint to another application endpoint. It does not matter the platform or language of said applications, as long as they support AMQP.

Essentially, one of the application endpoints sends a message, thus being a Producer, through an AMQP broker. In turn the broker will deliver the message to another application endpoint, called the Consumer.

RabbitMQ is an AMQP broker that has support for several programming languages, such as PHP.

The advantage of having a message broker such as RabbitMQ, and AMQP being a network protocol, is that the producer, the broker, and the consumer can live on different physical/virtual servers on different geographic locations.

Also, since networks are unreliable, and applications might fail to process a message completely, AMQP supports message acknowledgements, either automatically or when an application endpoint decides to send them.

RabbitMQ implements the AMQP 0-9-1 protocol. At a glance, it follows the following model.

Hello world example routing

Glossary

Concept Definition Icon
Producer Application endpoint that sends messages Producer icon
Consumer Application endpoint that receives messages Consumer icon
Connection Handles protocol, errors, authentication, etc… The connection is done using TCP protocol. -
Channel Connections are multiplexed through channels. Even though all channels share the same tcp connection, communication from one channel is completely independent of another. -
Exchange Receives messages from producers and pushes them to queues. Depending on the situation, this can be transparent to the developer. Exchange representation
Queue Buffer that stores messages Queue icon
Message Piece of arbitrary information conforming to the AMQP format that is sent from the producer to a consumer through the broker. The broker cannot modify the information inside the message. -
Acknowledgements Notice sent back from the consumer to tell the server that a message has been received and processed, so the server can delete it from the queue. -

Another advantage of AMQP 0-9-1 is that the application defines the routing logic instead of a broker administrator. This gives the developer a lot of flexibility, without the need to learn a new programming/scripting/markup language.

You can learn more about AMQP and RabbitMQ at the “AMQP 0-9-1 Model Explained” guide. Although not necessary for this tutorial, I encourage you to read it completely.

Continue reading %How to use RabbitMQ with PHP%

Link
labs @ Qandidate.comUsing the Accept Header to version your API (16.10.2014, 14:00 UTC)

I investigated different ways to version a REST API. Most of the sources I found, pretty much all said the same thing. To version any resource on the internet, you should not change the URL. The web isn't versioned, and changing the URL would tell a client there is more than 1 resource. But actually there aren't multiple resources, it's just a different representation of the same resource. Of course there are cases where you should change the URL; for example if you are changing the API in such a way that its functionality alters. In this particular case you could consider changing the URL as you could reason that it is not the same resource anymore.

But another thing, and probably even more important, you should always try to make sure your changes are backwards compatible. That would mean there is a lot of thinking involved before the actual API is built, but it can also save you from a big, very big headache.

∞ labs @ Qandidate.com Permalink

Link
PHP ClassesCompiling PHP into Optimized Machine Code - Lately in PHP podcast episode 52 (16.10.2014, 09:29 UTC)
By Manuel Lemos
The recent release of a new PHP compiler written in PHP by a Google PHP developer, as well other solutions to compile PHP into optimized native machine code, is one of the main topics discussed by Manuel Lemos and Arturs Sosins on the episode 52 of the Lately in PHP podcast.

They also discussed the latest proposals for new features of PHP 7, as well the new MySQL plugin that allows accessing MySQL servers directly with HTTP exchanging data in JSON format.

Now listen to the podcast, or watch the hangout video, or read the transcript to learn about the details of these interesting PHP related discussions.
Link
Qafoo - PHPUtilize Dynamic Dispatch (16.10.2014, 05:00 UTC)
A while ago I replied to the tweet by @ramsey
Traits are a nice way to provide common functionality to unrelated classes without using static methods on a global Util class.
with
Which makes them exactly as evil as static access. Funktionality you dispatch to becomes irreplaceable destroying a fundament of OO: Dynamic dispatch.
I want to use this blog post to illustrate the concept of dynamic dispatch which I use a lot recently to motivate creating clean OO structures in my trainings. In my experience, this helps people to understand why we want to write code in this way. After that I will show why traits are bad in this direction.
Link
PHP: Hypertext PreprocessorPHP 5.5.18 is available (16.10.2014, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 5.5.18. Several bugs were fixed in this release. A regression in OpenSSL introduced in PHP 5.5.17 has also been addressed in this release. PHP 5.5.18 also fixes 4 CVEs in different components. All PHP 5.5 users are encouraged to upgrade to this version. For source downloads of PHP 5.5.18 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
PHP: Hypertext PreprocessorPHP 5.4.34 Released (16.10.2014, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 5.4.34. 6 security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. Also, a fix for OpenSSL which produced regressions was reverted. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.34 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
PHP: Hypertext PreprocessorPHP 5.6.2 is available (16.10.2014, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 5.6.2. Four security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.2 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
Evert PotWhy Google's CardDAV server isn't. (15.10.2014, 19:03 UTC)

For fruux, we've decided to implement syncing with Google Contacts some time ago, allowing people to do bi-directional sync between their fruux and Google Contacts address book.

Bi-directional sync is not particularly easy, but since Google implemented CardDAV support some time ago, and I'm pretty well versed at that protocol, I thought it was doable.

I was wrong.

I'm writing this blog post as a general warning to not use Google's CardDAV server for well, pretty much anything. It's a huge mistake, and until they fix the massive mistakes in their interpretation of the protocol, you are much better off using their proprietary Contacts API.

Data-loss

Lets start with the most glaring issue, the loss of data. The primary data-format that's being used in CardDAV is vCard, in particular version 3.0.

There are certain things that you can expect when you use vCards with CardDAV. In particular, if you add some information to your vCard and send it to the server, with a PUT request, you also expect that information back with GET.

Google's CardDAV server silently wipes out all kinds of data it doesn't care about. Both the very important stuff, such as properties, but also other relevant meta-data such as parameters and groups that influence how a vCard may be interpreted.

The effect for the end-user is that a user may create vCards and add a bunch of information to a contact, which gets discarded by Google, and upon the next sync, also gets removed from the users local version.

Rejection of valid vCards and error handling

We've sent hundreds of thousands of valid vCards to Google's CardDAV server. The server rejects a whopping 15% of all the vCards we send it. Note that these are not vCards we produce. We receive them from other CardDAV clients, and since we get millions of them, this is statistically a decent source on what kind of vCards appear in the wild.

The biggest issue we're having with this though, is that we're not getting any feedback.

No, this isn't just a 400 Bad Request we're getting back, we're not actually receiving any TCP packets back, at all. Any (valid) vCard that the CardDAV server does not understand, will result in our HTTP requests timing out.

There's no clear pattern to what they do and do not support. We've noticed that almost every vCard with an attachment is rejected, and after dropping the attachments, things will start working... but there's also a large amount of cards that get rejected for certain Google accounts, but work fine in other accounts.

Slowness

Nearly any write operation you do on Google's CardDAV server will take 10-20 seconds to complete. This may not seem like a big deal, but many of our users have address books with well over 2000 contacts.

Given that our HTTP requests time out after 1 minute, we retry HTTP requests 2 times before failing, and 15% of requests fail by timing out, this means that for an address book with 2000 contacts, this would take over 22 hours to complete.

UID and urls

When syncing with a CardDAV system, especially with one that discards data whenever it feels like it, you'll need to keep some kind of reference to the vCard you're sending, so you can keep the important data local.

CardDAV provides two identifiers that are unique and stable id's.

Google's CardDAV server discards both, and replaces them with their own. From the perspective of any CardDAV client, Google makes it appear as if a new contact is sent. That contact is deleted on the server, and a new contact appears on the server that's similar, but not entirely (see Data-loss).

For very simple clients that may be sufficient, but even for example Apple's Contacts app on OS X, which uses ID's to group contacts together, loses this relationship as soon as the card is sent to Google.

Lack of documentation

The official documentation for the server conveniently just refers to the open standards, but since Google's system couldn't be further from being a CardDAV-compliant server, there's little to no information about why they do the things they do.

For instance, if they only choose to support an extremely limited subset of vCards, ignoring many often-used features, it would have been great if that was documented.

The response

Normally, when running into bugs like this, I

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

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