Kris Wallsmith

Our Montessori preschool’s annual fundraiser.

Thu, 10 May 2012 13:16:00 -0700

Our Montessori preschool’s annual fundraiser.

Symfony2 ESI error: File name too long

Wed, 09 May 2012 09:42:34 -0700

We recently came across a strange, intermittent error at OpenSky:

(36)File name too long: Cannot map GET /_internal… HTTP/1.1 to file

We use Varnish to cache large sections of our pages that include follow/unfollow buttons. If the user is following a certain curator we show the unfollow button, otherwise we show the follow button.

Our render tag looked like this:

{% render 'AppBundle:Curator:list' with
    { following: app.user.sortedFollowingSlugs }
    { standalone: true } %}

When the current user is following just a few curators this works fine. The app renders the curator list with follow/unfollow buttons accurate for the current user and Varnish caches it for us. However, when a user was following all or nearly all of our curators we see the “file name too long” error and Apache would render its 403 error template (no idea why it chooses 403 in this case).

Unpack the WTF

To understand why this happens we need to dig into how Symfony2 implements ESI. When ESI is enabled and your app sits behind a reverse proxy that supports ESI, any call to Twig’s {% render %} tag with the standalone option set to true will render an <esi:include /> tag instead of rendering the action inline. Included in the src attribute of that tag is an URL with all the values you passed to the {% render %} tag encoded in.

The routing pattern used for the ESI URL looks like this:

/{controller}/{path}.{_format}

In the case above the {controller} value would be AppBundle:Curator:list and the {path} value would be equivalent to the following:

php > echo http_build_query(array('following' => array('bar', 'foo')));
following%5B0%5D=bar&following%5B1%5D=foo

Now imagine what the {path} value will look like when a user is following 100+ curators. Big, right? Turns out it would be too big for Apache to handle as a filename, which cannot exceed 255 characters, hence the “file name too long” error.

Query String to the Rescue!

Fortunately the fix is easy and does not require any hacking on Symfony. By moving the potentially large parameter to the ESI URL’s query string our character limit jumps from 255 up to 8,190 — lots more room!

{% render 'AppBundle:Curator:list' {
    standalone: true,
    query: { following: app.user.sortedFollowingSlugs }
} %}

Of course you would also need to update CuratorController::listAction() to look for the following parameter in the query string rather than in the action arguments, but that’s an easy change.

Stay Curious

Symfony makes a lot of cool things very easy for you, but don’t become lazy. Open up the source code and figure out how it works, what technologies you’re using under the hood, and what constraints may be lurking in a dark corner somewhere, waiting to pounce.

The HTML5 placeholder attribute is not a substitute for the label element

Wed, 25 Apr 2012 05:15:21 -0700

The HTML5 placeholder attribute is not a substitute for the label element:

A good reminder from Roger Johansson. I admit I’ve been guilty of this in the past…

Type Matters

Wed, 11 Apr 2012 12:13:00 -0700

json_encode(array()) --> []
json_encode((object) array()) --> {}

Hello Spork! (aka "Forking PHP...")

Tue, 10 Apr 2012 08:42:03 -0700

A few months ago I was tasked with speeding up the upload of assets to the OpenSky CDN, which was taking a few minutes each deploy. I ended up dividing the upload into multiple processes using pcntl_fork() and bringing the total time of the upload down to a matter of seconds.

Since then I’ve been working on wrapping some of the complexities of working with a parent and child processes into an OO library and am happy to announce this experimental library: Spork.

Its usage is pretty straight forward.

<?php

use Spork\ProcessManager;
use Spork\Deferred\DeferredFactory;

$pm = new ProcessManager(new DeferredFactory());
$pm->fork(function() {
    // do something in a child process...
    echo posix_getpid();
})->then(function($output) {
    // do something in the parent process...
    printf('Parent %d forked child %d!', posix_getpid(), $output);
});

You can pass any callable into the process manager’s fork() method. In return you get a nice little deferred object which you can use to queue more callables to run after the child process exits. Just like the jQuery object I ♥ so much, there are three basic methods: always(), done(), and fail(), each of which accept a callable as an argument. There is also a then() method, which is a convenience method for adding a done and a fail callback in one method call.

Case Studies

If you end up using Spork I would like to hear about it. Please post your own blog and I’ll link to it, or send me a little description of what you’re doing and I’ll post it here.

jQuery Events: Stop (Mis)Using Return False

Sat, 17 Mar 2012 08:13:00 -0700

jQuery Events: Stop (Mis)Using Return False:

If you’re like me, this kind of rule doesn’t stick until there’s some meat behind it. Here is that meat.

Thanks for the tip, NiKo!

I ♥ Event Delegation

Fri, 16 Mar 2012 11:05:00 -0700

jQuery event delegation is ~~one of the coolest things since~~ way cooler than sliced bread.

This new hotness allows you to listen for an event farther up the DOM than where that event is triggered. If you understand event bubbling, you should be able to grok this fairly quickly.

It starts getting interesting when you look at the implications of adding this tool to your toolkit. Let’s look at a concrete example.

Ye Ole List

What application would be complete without a list? We all know the deal: a list of things, each with a “remove” button and then an “add” button at the bottom. Without event delegation we would wire up all these remove buttons something like this:

var $list = $("#list");
$list.find("a.remove").click(function(e) {
    e.preventDefault();
    $(this).closest("#list > li").remove();
});

This looks nice — but looks can be deceiving. The .click() function loops over the list of elements inside the current jQuery object and applies a listener to each one. So if there are n elements, you will have added n listeners. That bloat starts to show when you get into adding more rows to the list:

var template = $list.data("template");
$("#add_item").click(function(e) {
    e.preventDefault();
    $(template.replace(/__name__/, $list.children().length))
        .appendTo($list)
        .find("a.remove")
        .click(function(e) {
            e.preventDefault();
            $(this).closest("#list > li").remove();
        });
});

The remove listener is now defined in two places: first in the initial setup and again in the setup of each new row. We could move this listener to its own variable and reuse it, but that would only address the symptom of more code.

The more important fix is to reduce the number of listeners from n to 1. This is possible with event delegation:

var $list = $("#list");
$list.on("click", "a.remove", function(e) {
    e.preventDefault();
    $(this).closest("#list > li").remove();
});

This little beauty tells the #list element to listen for click events that bubble up from any of its a.remove progeny and run those events through a single listener. Since the listener lives on a common ancestor now, there is no need to add this listener when creating a new row:

var template = $list.data("template");
$("#add_item").click(function(e) {
    e.preventDefault();
    $(template.replace(/__name__/, $list.children().length)).appendTo($list);
});

There you have it! Go forth and profit with less, more performant code!

If you need to be able to tell others in the business when they can expect cached pages to...

Thu, 15 Mar 2012 11:17:27 -0700

If you need to be able to tell others in the business when they can expect cached pages to refresh:

$response->setPublic();
$response->setExpires(new \DateTime(sprintf('+%d seconds', 300 - time() % 300)));

$response->isNotModified($request)

Sun, 11 Mar 2012 16:22:00 -0700

This is one of my favorite methods in all of Symfony2 and it’s buried in the docs. Take a moment to glory in its simplicity:

public function someHeavyAction(Widget $widget, Request $request)
{
    $response = new Response();
    $response->setLastModified($widget->getUpdatedAt());

    if ($response->isNotModified($request)) {
        return $response;
    }

    // do some heavy lifting
    $response->setContent($this->renderView(/* ... */));

    return $response;
}

As you can see, this method makes implementing cache validation a snap. Once you’ve determined what you are going to use for validation — a last-modified timestamp and/or an e-tag — set that value on a new response object and this method will take care of the rest.

It accepts the current request as an argument and compares the cache headers coming in on the request with those you have set on the response. If the method returns true simply return the 304 response. If the method returns false, generate a fresh response.

It’s this sort of method that makes the Symfony2 HttpFoundation component the clear choice for anyone working with PHP and HTTP.

Faster PHPUnit

Tue, 21 Feb 2012 13:56:00 -0800

I made a simple optimization to the test suite at OpenSky over the weekend and we are reaping big benefits. The premise is pretty straight forward. We use the setUp() method to create a lot of mock objects through our test suite. If these are allowed to accumulate they end up wasting a lot of space and slowing down your suite.

Luckily there is also a tearDown() method you can use to cleanup, and you can do it automatically if you use this base class:

<?php

abstract class BaseTestCase extends PHPUnit_Framework_TestCase
{
    protected function tearDown()
    {
        $refl = new ReflectionObject($this);
        foreach ($refl->getProperties() as $prop) {
            if (!$prop->isStatic() && 0 !== strpos($prop->getDeclaringClass()->getName(), 'PHPUnit_')) {
                $prop->setAccessible(true);
                $prop->setValue($this, null);
            }
        }
    }
}

Our buddy Jenkins is much happier now — builds are approximately 20% faster.

Symfony2 Security Voters

Mon, 16 Jan 2012 21:14:00 -0800

I answered this question on StackOverflow today that is probably worth repeating here. The poster was asking how to implement subscription-based authorization logic in Symfony2. I imagine he models his problem something like this:

class Subscription
{
    const SECURED_AREA_FOO = 'FOO';
    const SECURED_AREA_BAR = 'BAR';

    // ...

    /** @ManyToOne(targetEntity="User", inversedBy="subscriptions") */
    public $user;

    /** @Column */
    public $securedArea;

    /** @Column(type="date") */
    public $start;

    /** @Column(type="date") */
    public $end;

    public function isActive()
    {
        $now = new DateTime();

        return $now >= $this->start && $now < $this->end;
    }

    // ...
}

class User implements UserInterface
{
    // ...

    public function getRoles()
    {
        $roles = $this->roles;

        foreach ($this->subscriptions as $subscription) {
            if ($subscription->isActive()) {
                $roles[] = 'ROLE_SUBSCRIPTION_'.$subscription->securedArea;
            }
        }

        return $roles;
    }

    // ...
}

He may then configure access control in his security.yml:

access_control:
    - { path: "^/sections/foo", roles: [ ROLE_SUBSCRIPTION_FOO ] }
    - { path: "^/sections/bar", roles: [ ROLE_SUBSCRIPTION_BAR ] }

This solution is nice enough, but we can do better. As the poster pointed out when someone suggested this solution, it doesn’t make sense to hydrate all of a user’s subscription objects (some of which may have expired years ago) just to fetch a string value. On top of that, fetching all of these objects every request is a waste of resources because the system will only be checking for the existence of one of them in any given request.

This authorization logic can be implemented much more lightly by encapsulating it in a custom security voter.

Voters

When questions about authorization are asked in Symfony2, the answer is arrived at by a process of voting. For example, when someone requests an URL that matches a configured access_control rule, a vote is held to decide whether to allow or deny access to that resource.

This voting process is similar in some ways to a US appeals court. There are a certain numbers of judges presiding over any given proceeding and in the end a decision is rendered. Occasionally judges recuse themselves from a case for this or that reason.

The authorization portion of the Symfony2 security component also includes a panel of judges called voters. These voters each have a say whenever questions of authorization come up in your application. Not every voter will have an opinion on every decision; some will abstain.

There are two basic types of votes: whether a user is granted a certain security attribute (i.e. the ROLE_USER attribute) and whether a user is granted a certain security attribute for a certain object (i.e. the EDIT attribute on blog post X). Each voter can be tuned to only chime in when certain votes are held. For example, you could write a voter that only participates when considering users with Gmail addresses.

In this particular case, we want to create a voter that only chimes in when questions regarding access to areas secured by subscriptions are raised. We can signify this by creating a new set of attributes that start with the string SUBSCRIPTION_.

access_control:
    - { path: "^/sections/foo", roles: [ SUBSCRIPTION_FOO ] }

This configuration proposes that only users with access to the security attribute SUBSCRIPTION_FOO should be granted access to any URL that starts with /sections/foo. Since there are no voters configured to evaluate this particular set of attributes, access with always be denied. But that is solved easy enough by creating a custom security voter.

This voter will look something like this:

class SubscriptionVoter implements VoterInterface
{
    private $em;

    public function __construct(EntityManager $em)
    {
        $this->em = $em;
    }

    public function supportsAttribute($attribute)
    {
        return 0 === strpos($attribute, 'SUBSCRIPTION_');
    }

    public function supportsClass($class)
    {
        return true;
    }

    public function vote(TokenInterface $token, $object, array $attributes)
    {
        $result = VoterInterface::ACCESS_ABSTAIN;
        $user = $token->getUser();

        foreach ($attributes as $attribute) {
            if (!$this->supportsAttribute($attribute)) {
                continue;
            }

            $securedArea = substr($attribute, strlen('SUBSCRIPTION_'));

            // use the entity manager to query for active
            // subscriptions that connect the current user to the
            // requested secured area
            // $success = ...

            if ($success) {
                return VoterInterface::ACCESS_GRANTED;
            }

            $result = VoterInterface::ACCESS_DENIED;
        }

        return $result;
    }
}

And be configured in the service container something like this:

services:
    subscription_voter:
        class: SubscriptionVoter
        public: false
        arguments:
            - @doctrine.orm.entity_manager
        tags:
            - { name: security.voter }

And that’s all there is to it. You have encapsulated your custom authorization logic in one clean class and added it to the Symfony2 security layer.

Other Applications

This is an example of one specific application of security voters, but there are many more. If you are struggling with how to implement some special access control logic that doesn’t fit nicely into either security roles or the security component’s ACL, consider creating a custom voter.

Twig Node Visitors (Part 2)

Fri, 06 Jan 2012 16:06:00 -0800

This is the second in a series of articles on Twig node visitors. Please read part one first.

Node visitors can be used for any number of things. The Twig_NodeVisitorInterface interface itself is just three methods:

interface Twig_NodeVisitorInterface
{
    /**
     * @return Twig_NodeInterface The modified node
     */
    function enterNode(Twig_NodeInterface $node, Twig_Environment $env);

    /**
     * @return Twig_NodeInterface The modified node
     */
    function leaveNode(Twig_NodeInterface $node, Twig_Environment $env);

    /**
     * @return integer The priority level
     */
    function getPriority();
}

The interface is simple and powerful. It provides a mechanism for manipulating nodes before a template is compiled down to a PHP class. It puts no constraints on what it can be used for. In the Twig core there are node visitors for escaping and optimization, both of which bear no semblance to what we are going to do here.

Our use case at OpenSky has to do with querying blocks of CMS content from the database eagerly, based on what blocks have been included in the template using the following function:

{{ cms_block('header') }}

We can accomplish this eager loading by using a node visitor to statically analyze each template and stashing the CMS blocks it calls for. The first method of the interface, enterNode(), can be used to look at every node in each template to see if it represents a call to this function.

public function enterNode(Twig_NodeInterface $node, Twig_Environment $env)
{
    if ($cmsBlock = $this->getCmsBlockKey($node)) {
        $this->cmsBlocks[] = $cmsBlock;
    }

    return $node;
}

// ...

private function getCmsBlockKey(Twig_NodeInterface $node)
{
    if ($node instanceof Twig_Node_Expression_Function
        && 'cms_block' == $node->getAttribute('name')) {
        return $node->getNode('arguments')->getNode(0)->getAttribute('value');
    }
}

This code looks at each node to see if it represents a call to the cms_block function and pushes the first argument (the name of the CMS block) to an internal array for use later.

After running this and debugging what was being stacked onto that array we found a few issues. First, the visitor was not smart enough to crawl included or imported templates and look for CMS blocks there. Second, the node visitor was not being reset for each template so by the end of cache warmup all CMS blocks called across the entire application were stacked on that internal array.

Solving the first issue meant adding a way to recursively crawl the graph of each template’s children — a child being a call to either {% include %} or {% import %} in our case. We did this by adding another internal stack:

public function enterNode(Twig_NodeInterface $node, Twig_Environment $env)
{
    if ($cmsBlock = $this->getCmsBlockKey($node)) {
        $this->cmsBlocks[] = $cmsBlock;
    } elseif ($templateName = $this->getIncludedTemplateName($node)) {
        $this->includes[] = $templateName;
    }

    return $node;
}

// ...

private function getIncludedTemplateName(Twig_NodeInterface $node)
{
    if ($node instanceof Twig_Node_Include || $node instanceof Twig_Node_Import) {
        return $node->getNode('expr')->getAttribute('value');
    }
}

We solved the second issue by listening for the root node, an instance of Twig_Node_Module, and clearing the internal stacks when we leave that node:

public function leaveNode(Twig_NodeInterface $node, Twig_Environment $env)
{
    if ($node instanceof Twig_Node_Module) {
        // todo: make these stacks available at runtime

        // reset
        $this->cmsBlocks = array();
        $this->includes  = array();
    }

    return $node;
}

We’re in pretty good shape at this point. We have built a node visitor that collects the information necessary for eagerly querying our CMS for the blocks that each template calls for. Now we just need to make this information available at runtime, when the eager query needs to be executed.

We’ll do this in the next post by wrapping the Twig_Node_Module in our own module node that compiles down the a PHP class with the necessary public methods. Stay tuned!

Getting Twiggy With It: Node Visitors

Wed, 30 Nov 2011 10:11:00 -0800

I am going to write about node visitors: one of the more obscure but powerful concepts in Twig. To help make sense of it I will be using a simple, real world example.

At OpenSky we recently added a basic CMS to our site that allows us to make edits to text without going through the hassle of editing a template and redeploying the entire codebase. We added a module to our admin that manages these CMS “blocks” as documents in MongoDB. Each document represents a block and includes a unique, descriptive key and the text content. In our templates we render these blocks using a simple Twig function. For example:

{{ cms_block('welcome') }}

When rendering a template, Twig would come across this function and issue a query to MongoDB for the welcome document in the collection of CMS blocks. Easy enough, right?

Not quite. We would like to speckle these blocks all over pages across the site: a paragraph here, a header there, an image over there, meta tags, Facebook tags… We could be looking at adding a dozen or more queries to a page for our little CMS, which is unacceptable.

Twig’s own Flux Capacitor

Imagine being able to look into the future to see what CMS blocks a template was going to use and issue a single query to prefetch them all from the database. That is exactly the sort of thing you can do by taking advantage of the static compilation phase, when Twig converts your templates into optimized PHP classes.

A Quick Primer on Twig Internals

Let’s take a step back and review some of the guts of Twig. I promise I’ll return to Back to the Future references later.

Compilation of a template into a PHP class is a four step process:

Load
Tokenize
Parse
Compile

The first step involves an implementation of Twig_LoaderInterface, of which only one method is pertinent to us: getSource(). This method accepts a template name and returns the raw content of that template. In the case of the default Twig_Loader_Filesystem implementation, this boils down to a simple call to file_get_contents().

The second step, tokenizing the loaded source, is handled by an implementation of Twig_LexerInterface which consists of one method, tokenize(). If you are having a hard time sleeping at night you can read up on lexical analysis on Wikipedia. For the purpose of this article, you only need to understand that the lexer converts what you’ve written in your template using Twig’s grammar into a stream of simple PHP objects called tokens.

In the third step the stream of tokens created by the lexer is parsed into a multi-dimensional tree of nodes. This work is done by the parser in cooperation with a collection of token parsers. This is the extension point you would hook into if you wanted to create a new {% foo %} tag, a topic outside the scope of this article.

In the final step the node tree created by the parser is compiled into runtime PHP code. Each node in the tree implements Twig_NodeInterface, which includes a compile() method that allows it to write arbitrary code to the resulting template class.

Great Scott!

That description of the Twig engine was criminally brief, but it should give you enough knowledge to understand where node visitors come in. After the parser creates the node tree but before the tree is compiled into PHP code, the parser recursively iterates over the tree and filters each node through its registered node visitors. Each visitor has a chance to inspect every single node in the tree, make changes, replace it with another, or even remove it altogether. It’s using this tool that we are able to inspect each template and magically anticipate what CMS blocks each template will need, before that template is rendered.

Coming Soon…

Dive into code with a working example of a Twig node visitor.

Cancer

Mon, 17 Oct 2011 16:32:00 -0700

I’ve been sitting on this for awhile and think I should share now.

My wife of 7 years, partner of 10 and mother of my three young children was diagnosed with stage 4 breast cancer a few months ago. It’s been an extremely difficult fact to come to terms with. The diagnosis is serious, but we are very hopeful. She has just finished her third round of chemotherapy and the scans say all the marshmallows are shrinking. That news and the outpouring of support from our family, friends and colleagues adds up to a lot to be grateful for.

If you pray, please pray for the complete eradication of cancer from Franya’s body. If you don’t pray, please send some happy thoughts our way.

Anyway… this is why I’ve been relatively quiet lately, will only be at ZendCon for less than 24 hours and won’t be coming to Cologne for Symfony Day at all. I’m not leaving anything, I just have less time and energy to spread around.

Blessings and protection,
Kris

My first passport...

Fri, 28 Jan 2011 09:32:25 -0800

…has expired! I have stamps for these countries:

The Bahamas
France
The Netherlands
The British Virgin Islands
Japan

What will the next 10 years will bring?

Old Glory

Fri, 03 Dec 2010 08:25:00 -0800

Old Glory

Unit Tests, Mocking, and PHPUnit 3.5's new Mock Builder

Fri, 29 Oct 2010 10:25:33 -0700

Unit Tests, Mocking, and PHPUnit 3.5's new Mock Builder:

My latest tidbit of testing goodness, this time on the OpenSky engineering blog.

Look Behind the "Feature Veil"

Wed, 27 Oct 2010 09:59:47 -0700

I’ve been thinking about a decision Apple made awhile ago to allow free iOS apps to offer in-app purchases. My recollection of their argument against doing this is that users would be frustrated by downloading a free app only to have to purchase something in-app to get it to work.

Around the same time Apple decided to allow free apps to offer in-app purchases, the App Store also began promoting each application’s “Top In-App Purchases.” This feature is pretty silly (who cares?), but it’s positioned prominently at the top of each app’s page.

It seems clear that Apple’s intention here is to denote which apps ask you to buy more stuff. This is a valid objective, but they’ve accomplished it in a strange way. The feature, when taken at face value, appears to do something unrelated.

This particular “feature veil” is pretty easy to see through, but I’m guessing the technique has been used before, by Apple and others, in less obvious instances. Can you think of any?

Who can find the jet lagged American?

Tue, 26 Oct 2010 05:13:44 -0700

Who can find the jet lagged American?

Keep a trim autoloader

Sun, 24 Oct 2010 05:46:00 -0700

The symfony 1.4 autoloader works by scanning your PHP class files and remembering where each class and interface is defined, so it can magically load it when needed. This class-to-filename mapping is stored as an array in your application’s cache directory.

You can (and should) look at this array by opening this cache file in your text editor from time to time: cache/%SF_APP%/%SF_ENVIRONMENT%/config/config_autoload.yml.php. Inside you’ll see a big array with // comment headers.

<?php
// auto-generated by sfAutoloadConfigHandler
// date: 2010/10/24 05:29:41
return array(

  // sfDoctrineGuardPlugin_lib
  'pluginsfguardgroupformfilter' => '/path/to/plugins/sfDoctrineGuardPlugin/lib/filter/doctrine/PluginsfGuardGroupFormFilter.class.php',
  'pluginsfguardpermissionformfilter' => '/path/to/plugins/sfDoctrineGuardPlugin/lib/filter/doctrine/PluginsfGuardPermissionFormFilter.class.php',
  'pluginsfguarduserformfilter' => '/path/to/plugins/sfDoctrineGuardPlugin/lib/filter/doctrine/PluginsfGuardUserFormFilter.class.php',

  // ...

A few things to look for in this file:

You should not see any reference to libraries that have their own autoloader. This includes the symfony core classes, Swiftmailer, Zend Framework, etc. If you see references to classes from one of these libraries, your autoloader is not configured correctly.
You should not see any non-runtime classes.

You’ll probably need to add some configuration to accomplish that second point. For example, your tasks and Doctrine migration classes will never be involved in a runtime request, so they should not be included in the autoloader’s cache.

Configure the autoloader

Fortunately, excluding these files is easy enough using autoload.yml.

Add this file to your project…

# config/autoload.yml
autoload:
  # extend the "project" configuration block defined in the symfony core
  project:
    exclude: [vendor, symfony, model, migration, task]

Clear your cache…

$ php symfony cache:clear

Visit your site in the browser to prime the cache, and re-inspect the cached config_autoload.yml.php file. Your task and Doctrine migration classes should no longer be represented there.

Add this to your installer

The new installer mechanism in symfony 1.4 is the perfect place to add this sort of thing since you’re going to want to do it on every project. For an example of how this is done, check out commit dede92e on my GitHub symfony-installer project.

If you want to learn more about configuring the symfony 1.4 autoloader, please read through The symfony Reference Guide, specifically the section on autoload.yml.

Kris Wallsmith

Our Montessori preschool’s annual fundraiser.

Symfony2 ESI error: File name too long

Unpack the WTF

Query String to the Rescue!

Stay Curious

The HTML5 placeholder attribute is not a substitute for the label element

Type Matters

Hello Spork! (aka "Forking PHP...")

Case Studies

jQuery Events: Stop (Mis)Using Return False

I ♥ Event Delegation

Ye Ole List

If you need to be able to tell others in the business when they can expect cached pages to...

$response->isNotModified($request)

Faster PHPUnit

Symfony2 Security Voters

Voters

Other Applications

Twig Node Visitors (Part 2)

Getting Twiggy With It: Node Visitors

Twig’s own Flux Capacitor

A Quick Primer on Twig Internals

Great Scott!

Coming Soon…

Cancer

My first passport...

Old Glory

Unit Tests, Mocking, and PHPUnit 3.5's new Mock Builder

Look Behind the "Feature Veil"

Who can find the jet lagged American?

Keep a trim autoloader

Configure the autoloader

Add this to your installer

Read more