I’ve never really taken the time to read up on how DNS works. Ten years of web development mean I’ve gradually assumed a pretty good idea through trial and error, but I’ve never really felt 100% confident that I know what I’m doing when registering and administering domain names, particularly when it comes to more obscure record types like SPF. Things work, but I don’t really know why.

I was shopping for a domain name the other day and while on the DNSimple website I was invited to receive a series of emails that offered to outline the DNS basics. I batted away my initial reluctance to sign myself up for spam, and I’m glad I did - the lessons are nicely written, short and to the point, and thankfully aren’t just an excercise in advertising for the registrar. I’ve learned a couple things and reinforced my knowledge of others. I can’t find a signup link now, but I do recommend them to anyone who wants to learn more about DNS.

I’ve always enjoyed reading microblogs like Daring Fireball which briefly editorialise links to content elsewhere on the web - it’s like “Here’s something interesting, here’s some perspective on it, now go read it.”. While we’ve had a blog on the Box UK website for some time, the format of it has been very much long-form. While that means we produce lots of in depth, informative content, the downside is because it can take a while to turn posts around the blog doesn’t suit snappy, quick posts in the microblog style.

Internally, we’re always sharing links to posts or videos in HipChat - stuff that’s relevant to our day-to-day work, stuff that could be useful to us in future, that sort of thing. For a while it’s been on our roadmap to introduce a microblog on the Box UK website, and now we have - last week we lauched the Box UK developer blog. We’ve already had posts on varied topics like SSH, Objective-C, Vim and Amazon S3. Keep an eye on it!

The JSON API plugin is a great tool for exposing your WordPress data. I’ve used it to provide content to a few mobile applications; it’s well featured and most importantly, quite flexible. If your content providers are happiest using a CMS like WordPress, your project can benefit by allowing them to use the authoring tools they’re comfortable with while allowing you to easily access the content they’re creating, either to use directly within your application, or as I tend to do, by exporting the data into another application which then proxies the data to mobile applications. I find the latter approach gives you greater control over features like caching, while making it easier to relate the data to domain models that aren’t handled by WordPress.

But I digress! This post was conceived because when requesting all posts of a certain type through the plugin, response times were hideously slow. The request I was making looked like this:

http://domain.com/?json=get_posts&post_type=artist&count=1000&order=ASC

Reading the documentation for the plugin, I found that it was possible to filter the response to only contain properties that I wanted, which I figured should reduce the amount of work WordPress was having to do:

http://domain.com/?json=get_posts&post_type=artist&count=2&order=ASC&include=id,title,content,custom_fields,thumbnail_images

This proved to be true, but I hit a snag when trying to include the thumbnail_images property – adding it to the CSV of whitelisted fields had no effect. Through trial and error it transpired that including the thumbnail field also has the effect of including the thumbnail, thumbnail_size, and thumbnail_images fields. The final URL ended up looking like this:

http://domain.com/?json=get_posts&post_type=artist&count=2&order=ASC&include=id,title,content,custom_fields,thumbnail

Problem solved!

Twice today I’ve seen references to the benefits of iterative improvement, and I found that the topic resonated with me. At the moment I’m halfway though a pretty lengthy software project in which it’s sometimes hard to see the wood for the trees. The backlog is substantial, resulting in a hefty set of tasks for our team. In these situations, where the to-do list doesn’t seem to change day to day, it’s easy to feel crippled by inertia. However, these two references illustrate that we can succeed provided we ensure we’re making healthy, gradual progress.

One might expect that the references I’m alluding to originate from a tome of software development, like “The Pragmatic Programmer“, or from one of the many celebrated development gurus of Twitter, but in fact they are not directly concerned with software at all. The first comes from a talk discussing the pros and cons of iterative improvement , linked to by my colleague (and all-round good chap) Owen Phelps, by Tim Harford at last year’s Wired UK conference:

If you put together enough marginal improvements, in enough areas, you get something that’s truly outstanding.

Give it a watch – it’s entertaining and informative.

The second reference came from an altogether different source – an interview with renowned mix engineer Alan Moulder in this month’s issue of Sound on Sound magazine, in which he discusses his approach when applying VST plugins to his music projects:

All the things I use do something to make the sound a tiny bit better, and if  you add everything together, the end result will be a lot better… It’s simple: better is better, whether it’s a tiny bit better or a lot better.

Through never-ending sprints, features and tasks, iterative improvement is something all development teams should strive to achieve.

I’ve been working on a Symfony2 application whose user interface is presented as a single page application that makes heavy use of JavaScript. The app sends XHR requests to the Symfony2 backend API to retrieve and modify data, and it uses Symfony’s authorisation/authentication functionality to protect resources so they are only accessible to logged in users.

In an ideal world every request made by the application will succeed, but in reality things often go wrong; the user may have provided invalid data, their session may have expired meaning they are no longer logged in, or we may have a bug in our API code which causes a server error. With an out-of-the-box installation of Symfony2, each of these scenarios will result in the default error handler rendering a HTML page which isn’t much use to our client JavaScript application – instead we want the server to issue a JSON response to our AJAX request, complete with some contextual error details, with which we can give the user a meaningful error message.

I did a bit of Googling and came across a few posts which dealt with some of these challenges, and by putting them all together I arrived at a solution which I’ll detail here in case it’s of use to anyone else.

I’ve put together a demo app which hopefully illustrates everything. Have a play with it (installation instructions are in the README), then read on

The app consists of a few components:

Client side:

• A jQuery global AJAX error handler
• A login form – I have two, a Symfony2/Twig-based HTML login page which the user is redirected to if they try to access the app without a valid session, and a JavaScript login dialog which we will display if the server rejects an AJAX request due to authentication/authorisation failure, allowing the user to reauthenticate without leaving the app

Server side:

• An authentication failure handler
• An authentication success handler
• A kernel exception listener

As far as the rest of the app goes, I’m using the FOSUserBundle with a standard configuration, which supplies the rest of the auth functionality, including the HTML login page.

Let’s start with the server components – three classes and a bit of config:

View the code on Gist.

The XHRAuthenticationSuccessHandler and XHRAuthenticationFailureHandler class’ code is triggered when the user logs in, or fails to log in, respectively. We check to see if the original request was an AJAX (XHR) one, and if so we respond with JSON. If it’s a failure we’re dealing with, we also include the exception message to give the user some feedback – note that this is a quick solution; it might be prudent to vet the message, or to translate it. I’ve also included a ‘success’ property which is a JavaScript convention that some frameworks (like ExtJS) use to execute appropriate callbacks. Finally, we wire up these handlers with the security component in our application’s security configuration.

The XHRCoreExceptionListener class code is triggered whenever a kernel exception occurs – check the service definition for this listener, you’ll see we tell Symfony to call its onCoreException method whenever an exception event is fired. Again, we only want to act if the request that caused the exception was an AJAX one. Assuming it is, we try to work out the status code to return from the exception code – if it’s a valid HTTP code, we use that, otherwise we assume a server error (500). As before, we’re reusing the exception message to provide context – but in this case, where the exception could relate to anything in the system (like a database query) we’d really want to be cautious about exposing it to the user, so this code certainly isn’t suitable for a production environment.

That’s it for the server, now for the client. All the functionality is in src/Acme/DemoBundle/Resources/views/Welcome/index.html.js.

First we define a global error handler, which will be fired whenever an uncaught AJAX error occurs:

View the code on Gist.

If the problem is that the user does not have a valid authentication token, we invite them to log in.

View the code on Gist.

The login process is interesting – the modal login form is essentially a duplicate of the HTML one, but lacks the CSRF token which is automatically injected into the HTML form by Symfony. This helps prevent spoofing so I didn’t want to remove it, so the approach I took was to request the HTML login page, capture the value of the CSRF field in the response, then use that in a second request to actually authenticate the user. This meant I could reuse the same authentication code on the server.

The demo app also includes two other demonstrations – making a valid request (which will fail, and force a login, if the user does not have a valid session) and an invalid one (which displays the error message returned by the server). There’s not much to say about those, the code should be self explanatory.

That’s it really. The code is a little rough and ready, but hopefully it’ll give you enough to go on if you’re trying to do something similar!

I’m working on a Symfony2 application which makes use of roles to manage what Users of the system are able to do within the app. Symfony places no limit on the amount of roles the User can have, but in the context of my application, there are only two – a base user (ROLE_USER, in Symfony parlance), and an administrator (ROLE_ADMIN). As is Symfony custom, all users would possess the default role, but the administrator role would be granted on a per user basis. I’m using the FOSUserBundle and Doctrine, so a User’s roles are stored within an array on that User’ Doctrine entity.

I began crafting a form (using the Symfony Form component) to manage user details. When creating forms that are bound to Doctrine I’ve generally found that I’ve needed to do little in the way of form customisation; the form component does a good job of figuring out which form fields to use based on the type of the variable it is given. So name, being a string, gets modelled as a textfield, while their registration date, being a DateTime object, causes a series of select boxes to be created which allow dates and times to be entered. So far so good.

But of course there has to be a reason for a blog post, and this is mine: I wanted a checkbox to toggle on/of the administrator role for each user. Since roles are stored in an array on the bound entity, the default is to render a collection of fields, which leads to an array of values being submitted by the form. Trying to modify the field definition to a ‘single’ field, like a checkbox, led to an error as the Form component doesn’t know how to map an array to a single value. A multi-value field wasn’t an option as I didn’t want to expose the roles (which wouldn’t necessarily make sense to an end user), and I didn’t want to get into messing about with Twig templates if I could help it; a bit of Googling led me to this article on the cookbook, which describes how to dynamically add elements to forms using a Form event subscriber; this turned out to be just what I needed.

Reading through the cookbook article, the following plan took shape: when the form is created, add a checkbox to the form which is ticked depending on whether the User object bound to the form has the administrator role. When the form is submitted, if the checkbox is ticked, grant the user that role. If it is not, remove the role from their array of granted roles.

To implement this, I needed two classes; a Form class, of course, and a new class that implements Symfony\Component\EventDispatcher\EventSubscriberInterface and subscribes to events on the form. As in the cookbook example, when the ‘preSetData’ event fires I’d be adding a field to the form. In addition, when the ‘bind’ event fires, I’d be using the value of the field to modify the bound object, in this case the User being managed. This is what I ended up with:

View the code on Gist.

I’m manually adding the subscriber to the form in UserType::buildForm(), which feels a bit weird when the usual approach would be to define a service and tag it appropriately. I’m not sure if that’s possible with Form subscribers, that’s just how the cookbook approach went. I’d imagine there are other ways I could have achieved the same result, but I like this approach because I don’t have to modify my User class at all, and I don’t have to delve into form field customisation.

The only downside I’ve found so far is that there doesn’t seem to be a way to order the fields that get added in the listener – they are always placed at the start of the collection, regardless of when the subscriber is attached to the form. This means that some template work is necessary to place the field as desired.

A few times I’ve found myself cursing when trying to toggle XDebug on and off via Macports. Typically I’ll be debugging with it enabled, then disable it for development/testing to get the fastest experience possible (it tends to really impact performance on large codebases, such as a Symfony2 standard install), only to experience segfaults when I refresh the page I’m working on.

The solution I’ve found is when restarting Apache (which is necessary for the change to PHP’s installed modules takes effect), to use an explicit start/stop rather than a restart. According to the Apache docs restarting only kills off children processes, so the parent remains running:

Sending the HUP or restart signal to the parent causes it to kill off its children like in TERM, but the parent doesn’t exit. It re-reads its configuration files, and re-opens any log files. Then it spawns a new set of children and continues serving hits.

I imagine this leading to a discrepancy in the loaded PHP modules, which causes the issue.

So when wanting to toggle XDebug, I use these commands:

Install (first time only):
sudo port install php5-xdebug

Disable:
sudo port deactivate php5-xdebug
sudo apachectl stop
sudo apachectl start

Enable:
sudo port activate php5-xdebug
sudo apachectl stop
sudo apachectl start

I was having a nice, relaxing Saturday morning until I read through my Twitter timeline and was directed to Jeff Atwood’s latest post on Coding Horror, “The PHP Singularity“. After reading through it, and the comments from other readers, I got annoyed. Really annoyed.

I won’t repeat the article, but the gist of it is:

• PHP is a horrible language
• Something must be done
• Jeff is the person to do it

I quite enjoy blogging but I don’t do it very often. I try to make sure anything I talk about is well researched, because a baseless opinion is worthless, but I don’t have a lot of free time – so if I don’t have something I consider worth saying, I don’t say it.

Jeff doesn’t have the same concern. You may wonder why I read his blog, given that I clearly take exception to some of its content, but the funny thing is that when talking about things he is knowledgable of, he has some great advice.

Like when he talks about his children, because he obviously knows them, or routers, where he’s clearly done some investigation. Now, I’m about to become a father, so I really enjoyed the former post, and if I needed to buy a router, I’d probably just be lazy and pick one from the latter because he knows a lot more about them than I do.

But here’s the thing. Jeff doesn’t seem to know much about PHP. I’d guess he’s read some posts about it, seen a few Q&As on Stack Overflow about it (a site he deserves massive kudos for), read through the PHP Manual, whatever – but he’s not a PHP developer. When he says PHP is ‘terrible’ or ‘deeply flawed’, I wonder how he’s come to that conclusion? Has he ever developed anything substantial in PHP? What is he basing this opinion on? He’s played with his children, he’s bought and installed a router. But when it comes to PHP, is the extent of his knowledge that which he has gleaned from others? Because if that’s the case, he really should think twice about offering his opinion on it.

The most glaring statement in the entire article is this one:

Therefore, I’d like to submit a humble suggestion to my fellow programmers. The next time you feel the urge to write Yet Another Epic Critique of PHP, consider that:

1. We get it already. PHP is horrible, but it’s used everywhere. Guess what? It was just as horrible in 2008. And 2005. And 2002. There’s a pattern here, but it’s subtle. You have to look very closely to see it. On second thought, never mind. You’re probably not smart enough to figure it out.
2. The best way to combat something as pervasively and institutionally awful as PHP is not to point out all its (many, many, many) faults, but to build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible.

How anyone can offer a ‘humble’ suggestion and then go on to question the reader’s intelligence is besides the point (though it does nicely illustrate Jeff’s technique of drawing the reader in with deference only to hit them with a massive dose of self-righteousness) – but there’s two things I really take exception to here. Firstly, as anyone who has spent any real time with PHP knows, the language is far, far different now to what it was in 2002. For heaven’s sake, PHP5 (with a brand new object model that made proper OOP possible) didn’t make its debut ’til 2004, and support for register_globals (one of the worst features of PHP, ever) was removed in the most recent version, 5.4. Those facts are available under PHP’s entry on Wikipedia, but perhaps Jeff’s not smart enough to Google the history of PHP before commenting on it?

Secondly; assuming for a second that PHP is as horrible as he deems it to be – the best way to ‘combat’ it isn’t to ‘build compelling alternatives’ and ‘make sure these alternatives are equally pervasive, as easy to set up and use as possible’ – no, the ‘best’ thing to do (considering the amount of developers and sites worldwide who depend on the language and are getting things done with it every single day) is get involved with and actually understand PHP – read the internals mailing list, make requests for comments, code contributions, etc. It’s a silly person who decides to try something new before attempting to fix what’s broken, when there is so much invested in it. Perhaps if Jeff wasn’t trying to drum up interest in this new project of his, he’d have been a little less inflammatory?

Look, as someone who has used PHP successfully for the last decade, obviously I’m going to disagree with Jeff’s opinion. But the language has not only helped me get a great job, a nice house, and will shortly be helping me pay for one of those baby things, it’s also made Facebook the biggest website in the world, and enabled Yahoo! to build (ok, and throw away, but it’s not PHP’s fault) an empire. When Jeff’s got off his soap box and tried to build something equally successful in PHP and failed, I’ll start taking his opinion seriously.

As I said, I don’t like making statements unless I’ve researched them fully. I’ve read Coding Horror for a long time, and I feel qualified to say that Jeff Atwood is a muppet.

I’ve been asked a few times what the best resources are for learning Symfony2. With the project still relatively young there aren’t yet (to my knowledge, anyway!) any books (physical or otherwise) on Symfony2 available, but there is a good amount of information in the form of manuals and tutorials on the web to get on with.

This question on Stack Overflow lists most of them; specifically:

• The Book: The official documentation, also available as a PDF download from the same location. The best place to start, and covers most of Symfony’s functionality, but doesn’t have many ‘real-world’ examples, as opposed to…
• … The Cookbook: Complements The Book by providing some more complicated examples of how Symfony2 can be used – sometimes the example you’re desperately searching for doesn’t feature, but on the whole it’s necessary reading to understand what Symfony2′s capable of and the best ways to use it.
• It’s not strictly a Symfony2 resource, but Fabien Potencier’s ‘Build your own framework’ series of articles use the same components that make up Symfony2 to construct a similar framework, and as such are a really good way to familiarise oneself with the building blocks often become invaluable when trying to accomplish anything complex with Symfony2.

That’s it in terms of ‘official’ resources. There are some really good community efforts too, including:

• A series of screencasts at KnpUniversity which introduce the key features of Symfony2, from installation and configuration through to security, forms, and using Doctrine to work with data sources. These cost $$$, and I haven’t tried them myself, but KnpLabs have been very involved with the development of Symfony2 so they’re probably well worth a look.
• The Symblog tutorial is an excellent step-by-step guide to building a blog in Symfony2, covering most of the essential topics, in the spirit of the Jobeet tutorial from the original Symfony framework. Each part of the tutorial points to related articles in the official documentation, so it’s a nice way to work through that while building something tangible.
• Speaking of the Jobeet tutorial, there’s also a companion tutorial for Symfony2. Like the Symblog tutorial, this explains the MVC approach to development with Symfony2 and dips into functional/unit testing too.
• I’ve found the PHP and Symfony blog to be one of the best for learning about less common features of the framework, the sort of topics that are crucial when going beyond building the simple blog apps.
• Richard Miller‘s blog is also excellent for the same reason.

Each of those resources will probably give anyone with decent PHP experience enough information to start building applications with the framework. Questions will inevitably arise, in which case go to the following places for help:

• The Symfony2 Google Group is handy because often the problem you have has been answered already, so it’s a good resource as well as somewhere to get help from others using the framework.
• The Symfony2 IRC Channel is good for real-time assistance, and is populated with both experts and newbies. Following the chat is a great way to pick up hints and tips for problems you have yet to encounter.

If there are other good resources that I’ve missed, please let me know and I’ll add them. I’ll try to keep this article up to date in future as new resources emerge.

If you think app development and football have nothing in common, read on.

There was a discussion on our IRC server at work this morning which centred on how to best mitigate the risk involved with using third party tools in web applications. Not just at the code level, as in a JavaScript library like jQuery, or a PHP framework like Symfony2, but right through the stack – from the OS, to the web server, to the app codebase and beyond.

Much of the discussion was along the lines of what you’d expect when devops (or sysadmins) and developers collide – those responsible for managing the stack want things that can be easily automated, are verifiable (ideally through something like checksums) and reliable (i.e. not placed directly on a production server from a Pentium 3 machine in some teenager’s bedroom half way round the world), while those responsible for writing the code want to be able to use the best tool for the job, whether it be a tried and trusted web server or the newest, shiniest Symfony2 bundle.

The general consensus was that both have equal importance. Personally, I think that depending on the nature of the app, it’s wise to proportion risk accordingly; an app with a USP centred around some novel, interactive UX may want to incorporate a new innovative JavaScript toolkit even if it’s yet to reach version 1.0, whereas an app with paramount speed and scalability requirements might want to try PHP-FPM with nginx in place of a more familiar solution like mod-php with Apache.

In isolation, either of these decisions probably wouldn’t pose a problem. Combining many such scenarios, though, may eventually load the project with enough risk as to eventually make it untenable. The holy grail is to arrive at a point where we have an app that delivers its required functionality while making use of as many trusted, reliable tools as possible, and can be managed in such a way as to make deployment and maintenance safe and simple.

Now, to the title of this post. While this discussion was raging in IRC, there was much furore over the selection of the provisional England squad for the Euro 2012 tournament. It occurred to me that the new England manager, Roy Hodgson, is facing many of the same challenges myself and my coworkers face when trying to decide on a strategy for selecting the players he thinks will combine to great effect in a few month’s time. He wants a team that blends reliable, experienced, mature players with younger, modern ones – with maybe a sprinkling of unpredictable, yet highly creative, firebrands that can make the difference between a good squad and a great one. This is essentially what I was trying to articulate in the conversation, but swapping players for libraries, or tools, written by myself, or by others.

So when I was scanning the list of players that are going to Poland and the Ukraine this summer, I couldn’t help but think of them in a technical fashion. For example:

• John Terry (Defender) – Very experienced, but can be unreliable and prone to catastrophic behaviour. (Windows OS – ever tried hosting a PHP app on Windows?).
• Alex Oxlade-Chamberlain (Midfielder) – New kid on the block, has a speciality that offers a new dimension (see: nginx and content distribution networks)
• Stuart Downing (Midfielder) – Does what he does and does it well enough, but isn’t going to make a massive difference overall. Comes with baggage and divides opinion. (CodeIgniter/CakePHP/any other technically limited PHP framework)
• Wayne Rooney – Best of breed, unrivalled, links up with others very well, difficult to replicate or replace (jQuery)

It’s a popular argument at the moment that more people should be aware of, and be able to, code. But perhaps we’re missing a trick – perhaps a few games of Football Manager is all it takes to be able to understand how to compose a fabulous web app these days.