Nearly two years ago, Eamon Leonard convinced me to start a new Pub Standards chapter in my hometown of Lancaster, PA. Ben Darlow graciously customized a Pub Standards beermat logo, I bought the pubstandards.us domain, and I started talking to my local network of developers.

Unfortunately, as I was actively trying to increase my presence on the web, I was simultaneously neglecting my budding network of developers/designers in the Lancaster community, and the dream of a local Pub Standards died before it really began.

That was until a few weeks ago, when I was inspired again to get this ball rolling by the urging of Eamon and an awesome turn out of tech talent at a local party/meetup downtown in the Infantree studio.

With a population of only 60,000 urban/500,000 metro, Lancaster is no doubt the smallest city with a Pub Standards chapter, but its thriving arts community coupled with its wide range of design/dev shops and startups makes it the best place in central PA for just such a meetup.

For Lancaster web folk that are interested:

We have not yet selected the bar in which Pub Standards will meet. Custom dictates that Pub Standards is to be held at the same bar every month, so we definitely want to choose a pub that has great drinks, isn't so loud that we can't chat, and that has enough space for a group every second Thursday at 6pm.

I imagine the upcoming Federal Taphouse would be a great option, but that likely will not be opening in time for the first meetup. Other bars under consideration are the Dispensing Company and the Spring House Taproom.

If you have any other pub suggestions or have a preference for one of these in particular, let me know @courtewing.

The following three error messages are as cryptic as they are common, but fortunately they are all easy to fix.

Fatal error: Parse error: syntax error, unexpected TPAAMAYIMNEKUDOTAYIM in /path/to/index.php on line 48

Paamayim Nekudotayim is hebrew for "twice colon", and it is the term adopted by Andi Gutmans and Zeev Suraski when they wrote the Zend engine for PHP 3. The more technical term for this is the Scope Resolution Operator, and it is used for accessing static properties and methods on classes. When you see this error, you are probably trying to access a static method or property on a non existent class name.

If you've never experienced this error before, chances are it wouldn't take you too long to hunt down the problem. Writer daleV from Greek Gumbo created this excellent write up detailing this particular bug last year.

Fatal error: Can't use function return value in write context in /path/to/index.php on line 48

This error is a little more insidious than TPAAMAYIMNEKUDOTAYIM since, without experiencing it before, you may not realize what the problem is with a given line of code even if you were staring straight at it. This issue crops up when you try to pass the returned value from a function directly into either the isset() or empty() functions. This is easily resolved by storing the returned value in a variable first, but it does seem a little inconsistent, especially for new developers that have no concept of a construct versus a built-in function.

At the time of this writing, there is actually an RFC that is in the voting phase for inclusion into the PHP core that addresses this issue for the empty() function. During the course of discussion about the RFC, it was decided that it was a bad idea to change this behavior for isset() as it is semantically confusing.

Fatal error: Exception thrown without a stack frame in Unknown on line 0

This is about as bad as error messages could possibly get as it requires you to have detailed knowledge about the technical implementation of the language for it to make any sense whatsoever. Also, no matter where this error occurs in your application, the error message still says that it happened in file "Unknown" and on line "0".

This error is triggered when any exception is thrown but not caught from within a class destructor (i.e. __destruct()).

When this happens, you do not really have many options other than hunting down the destructors in all of your objects to see which one may fail. May I suggest: grep --color -rn "n __destruct" to help hunt down the issue in a linux terminal.

Edit 2012-05-01: Larry Garfield has pointed out that exceptions being thrown from inside a destructor is not the only way this error can be triggered. The error is actually triggered any time an exception is thrown outside of the "normal" flow of a the program. Another place that this could occur, for example, is when an exception is thrown from inside another exception. Thanks Larry!

You can save yourself a whole lot of frustration in the future if you keep these three error messages in the back of your mind.

In the talk, I mention four things that you can do to help ensure that your app can scale horizontally in the cloud:

1. Store your file uploads on an external file storage service such as Amazon S3.
2. Do not keep your database on the localhost.
3. Use an external memcache server or service for PHP session storage.
4. Keep your VCS repo lean.

• As far as I know, array-oriented programming is not a thing. I sure hope it never becomes a thing.
• The code that I provided may have some cool components, but it is not good overall. It is very inflexible and extremely fragile. I broke it a half dozen times just trying to make simple changes, and it took me 10x longer to write than would be necessary in another coding style.
• Verbosity should not be a goal of any paradigm. If you choose to be verbose with your code, so be it. Good paradigms, like object-oriented and functional programming, empower you to make that sort of decision yourself.
• If you dig the usage of anonymous functions here, then I highly recommend that you try out some functional programming. It is fun.
• The new array syntax in PHP 5.4 is rad as hell.
• No core developers were harmed in the making of this blog article.

April Fools!

Programming on the web has come a long way since the wild-west early days of the 90s, and nowhere has this been more evident than in the PHP community. The earliest "apps" made with PHP were little more than some odd scripting bits that helped web pioneers and hobbyists to more easily maintain their HTML websites. At the turn of the century, larger, procedural PHP apps started to pop up that would eventually change the web as we knew it. Less than a decade later, the widespread adoption of object-oriented programming throughout most web development communities had led to some of the most sophisticated triumphs of software engineering (or hackery) in history.

But just as procedural coding proved insufficient for developing the types of applications that the consumers of the web demanded, the usefulness of object-oriented programming is rapidly reaching its limits. Object-oriented programming ultimately results in highly complex, bloated, and inconsistent code bases that cannot sustain the growing demand they will no doubt receive. Once an object-oriented app reaches a certain mass, those problems begin to create cracks in its very foundation.

To free us from these constraints, some look to new systems that boast event-driven, functional foundations such as node.js. Communities behind these systems make bold claims about the impact they will have on the web of tomorrow, but while this approach certainly has its benefits, it suffers from the very huge obstacle of being completely incompatible with their existing app architectures. To truly revolutionize the web as a whole, a new system or paradigm must allow users to incrementally update their existing apps and workflows.

Fortunately, there is now a new paradigm that originated within the PHP community that is rapidly changing the way we develop web and mobile apps. Array-oriented programming (AOP) combines all of the structure of object-oriented systems with the ease-of-use and efficiency that could exist in procedural apps, and it does so in a highly consistent way. Best of all, it can be done in any programming language that supports arrays, and it can be used to build entirely new apps or even incrementally refactored into existing apps regardless of whether they were procedural or object-oriented to begin with.

Array-oriented programming is based on one driving principle, an entire program structure and flow is defined as an array. It really is as simple as it sounds.

AOP is not a new concept, but it is just now gaining traction in the web development community. There are countless articles scattered across the web that go into great detail about the technical intricacies of this revolutionary paradigm, so I won't bore you by driving in all of those same points. Instead, let's take a look at a complete array-oriented program:

<?php
$app = array(
    'session' => array(),
    'request' => array(
        'method' => 'GET',
        'uri' => '',
        'data' => array()
    ),
    'response' => array(
        'body' => '',
        'headers' => array()
    ),
    'errors' => array(
        404 => function(&$request, &$response) {
            $response['body'] = '404 Not Found';
            $response['headers'][] = 'Status: 404';
        }
    ),
    'routes' => array(
        'GET /' => function(&$request, &$response, &$session) {
            $name = isset($session['name']) ? $session['name'] : 'World';
            ob_start();
            // not shown, but your standard php template
            include '../template/home.phtml';
            $response['body'] = ob_get_contents();
            ob_end_clean();
        },
        'POST /' => function(&$request, &$response, &$session) {
            if (isset($request['data']['name'])) {
                $session['name'] = $request['data']['name'];
            }
            $response['headers'][] = 'Location: /';
            $response['body'] = null;
        }
    ),
    'route' => null,
    'bootstrap' => array(
        'session' => function(&$app) {
            session_start();
            $app['session'] = &$_SESSION;
        },
        'request' => function(&$app) {
            if ($_SERVER['REQUEST_METHOD'] == 'POST') {
                $app['request']['is_post'] = true;
            }
            $app['request']['uri'] = '/' . trim($_SERVER['REQUEST_URI'], '/');
            $app['request']['method'] = strtoupper($_SERVER['REQUEST_METHOD']);
            $app['request']['data'] = $_REQUEST;
        },
        'router' => function(&$app) {
            $route = $app['request']['method'] . ' ' . $app['request']['uri'];
            if (!isset($app['routes'][$route])) {
                $app['route'] = $app['errors'][404];
                return;
            }

            $app['route'] = $app['routes'][$route];
        }
    ),
    'dispatch' => function(&$app) {
        $route = $app['route'];
        $route($app['request'], $app['response'], $app['session']);
    }
);

foreach ($app['bootstrap'] as $bootstrap) {
    $bootstrap($app);
}
$app['dispatch']($app);

foreach ($app['response']['headers'] as $header) {
    header($header);
}
if ($app['response']['body'] !== null) {
    echo $app['response']['body'];
}

As you can see, this is essentially a "Hello World" app on steroids, and its structure -- which is completed defined in arrays, is flexible and intuitive. This simple structure could be used to build both simple and complex apps alike.

At this point, I'd like to answer some of the common questions that people have when they first stumble upon array-oriented programming.

Q: Isn't this overly verbose?

Can there be such a thing? Way back in the day, there used to be a programming language called "perl" that was very succinct. People tried to make simple programs with perl, but they found its succinctness to be far too inflexible for the demands of even the early web. Fortunately for all of us, PHP did not evolve to emulate perl and instead evolved to emulate Java, and perl has since disappeared entirely. As a result, PHP has curly braces so that servers do not get confused, and there is now the long-standing tradition of building ultra-architected application architectures regardless of the nature of the final product. Array-oriented programming caters to that tradition.

Q: Can we use the short array syntax from PHP 5.4?

Of course you can! But don't. You see, there are still some rogue fans of the silly concept of succinct code that have voting rights for the PHP core. We call these people "perlites" and they recently pushed forth that radically antiquated short array syntax. The problem is, without the keyword "array" to indicate exactly what you're creating, it is difficult for both the developer and even the interpreter itself to figure out what you're trying to do. It is best to stick with the more verbose, traditional array() syntax.

Q: How is this better than object-oriented programming?

The biggest problems with object-oriented programming is clarity and consistency. What are objects? Where do they exist? What are they named? Who creates them? These fundamental questions are never completely answered in an object-oriented paradigm. With array-oriented programming, everything is an array. It doesn't get much more clear or consistent than that!

So there you have it. Array-oriented programming is changing the face of modern software development, and it is not too late to get on board. Its benefits are without question, and I'm confident that once you start developing applications in the paradigm, you will wonder why you ever bothered to write programs any other way.

Hacker News: news.ycombinator.org/item?id=3783641

For the uninformed, I started working at Echolibre in June of the previous year, and it was my first telecommuting gig. It took a few months to get completely accustomed to that type of workflow, so I guess you could say that I didn't really feel at "home" when actually working full-time out of my house until this year. In February, I think I finally came into my own as a telecommuting developer, and I documented my tips for staying productive in my first article of the year.

In the meantime, David Coallier, Eamon Leonard, and Helgi Þormar Þorbjörnsson had been planning and working on the then-secret Orchestra platform. I was eager to cut my teeth on the project, but we were self-bootstrapping its development through the consultant work, so every minute any of us spent on the project was one less dollar we had to keep the project afloat. Finally, I logged my first commit to Orchestra in March.

Early in the same month, a theme of blog articles started to spring up throughout the web. In numerous "Ideas of March" posts, open source developers discussed the merits of knowledge sharing through traditional blogging rather than through social networks and micro-blogging services such as twitter. This struck a chord with me as many of these authors had inspired me through their own blogs over the years. I had been trying to think of a way to explain my feelings on the matter for some time, so I jumped on the bandwagon with my own plea to "Think About the Little Guy".

When May rolled around, it was time to launch the first of three new client applications on which I worked. Redeem&Get is an application that allows businesses to manage coupon campaigns and customers; it is designed to give businesses an easy way to honor online deals and to maximize the benefits associated with the influx of new customers. At Echolibre, I managed the technical development of the project, from the very first line of code until the beta launch.

June marked another important client milestone at Echolibre as we helped to launch the RentView beta. RentView is the product of many months of hard work and over a decade of property management experience by its co-founders Colin Napper and Andreas Riha. The application is the culmination of their grand vision: to make the process of managing rental properties clearer for letting agents, landlords, and tenants while dramatically cutting the usual wastes in time and money associated with managing and renting properties. I joined the project after it was well underway, but I'm happy to have managed it through its final months of development.

In late July and into August, I started playing around with Symfony 2. It is a really impressive example of the power you can wield with all of the modern features of PHP 5.3 in a full-blown application framework. For a few weeks, I was actually completely hooked, and I even thought about making the switch from Zend Framework permanent. During that time, I wrote one of my initially-least successful blog articles about choice lists in Symfony 2 forms. Despite its lackluster traffic at first, the article has surprisingly grown into one of the biggest traffic generators from search engines over the long term.

Where the choice list article has proven to be a long term traffic boon, my second article in August was by far my biggest initial traffic-draw. More people visited "How PHP is Broken and How it Can Be Fixed" in the first three days than had visited my entire site in the previous two months. The responses in the comments, twitter, and google+ were numerous, and the discussion became heated. Feeling that any positive critiques I may have about the PHP project were being overshadowed by the confrontational nature of the article, I decided to write a follow up to the article that would hopefully be more constructive.

August concluded with a bang when the news broke that Engine Yard acquired Orchestra. It is hard to quantify how big of an event this was for us. We have an amazing team of developers that are entrenched in the open source and PHP communities, but Orchestra was only introduced in 2011 -- years after the Platform as a Service industry was pioneered. Fortunately for us, Engine Yard was one such pioneer, and their experience and product are in a league of their own. Together, all of the pieces started falling together, and as a result, Orchestra will truly shine in 2012 and beyond.

At this point, I wanted to start hacking away at the Orchestra platform, but we still had responsibilities at Echolibre. I worked on our final project at Echolibre throughout September and into October: WorldIrish has the ambitious goal of compiling the definitive online catalog of the "Irish Experience" throughout the world. Despite still being in beta, it has networked together more than 11,000 people who wish to share their own Irish stories, ideas, and experiences.

Three days after completing my work on WorldIrish, I was officially hired by Engine Yard to work full-time on the Orchestra platform. I guess you could call this a "dream come true" moment for me. Since then, I've been spending most of my time within the web application and APIs that power the platform. I wish I could talk about everything we're planning and/or working on because it is so damn cool.

As if October was not awesome enough, Elyse and I brought our month of October to an end with the purchase of our first house. It was relatively unexpected, but it is beautiful, and it is home, and we love it.

Compared to October, November was largely uneventful. I used this time to finally get back to something I promised weeks before; I wrote my followup to my "How PHP is Broken and How it Can Be Fixed" article. The followup generated less traffic than its predecessor, but I think I did a much better job offering criticisms of the PHP project while attempting to explain some of the steps that are being taken for improvement as well as offering some practical suggestions to improve the process further. It is what I wanted my original article to be, so I'm more than happy with it.

As the year came to a close, I flew out to hang out with the team and see the new Orchestra offices on Barrow Street in Dublin, Ireland. For the record, the offices are gorgeous. While I do love working from home, the offices are cool enough that I am almost jealous of the crew that works out of Dublin. They are still doing a lot of work on the space over there, but I'm confident there will be a bunch of pictures posted of the joint when it is all finished.

In my final days in Ireland, when I sat in David Coallier's kitchen in front of the fireplace drinking hot port until god-knows-when, I was awestruck when I thought back to all of the things that happened in my life this year. 2011 was an extraordinary year for me, and I cannot wait to see what awesome things await in 2012.

It is no secret that the PHP development process has never been a shining example of project organization or quality assurance. Until recently, some of the most important aspects of any project's development cycle were either entirely lacking or were ill-defined. Worse, there was little in the form of systemic quality assurance. Fortunately, the core devs did not ignore these issues, and they've been pushing really hard to improve on these areas over the past few years: They've created a new release process, a new voting procedure, and have been building up the automated test coverage. They're shaping the development process into a more open, clear, and modern process that the whole community can be proud of.

This type of transformation takes time, however, and they are not at the finish line yet. There are specific characteristics of the development team and process that are still very much a huge problem today. An acceptance of failing unit tests along with a lack of an automated release process that incorporates testing requirements resulted in the recent disaster that was the PHP 5.3.7 release. A lack of clear responsibilities continues to disrupt developer trust in the PHP project. Insufficient means of communication and insufficient use of those means frequently keeps the large number of non-contributing PHP developers in the dark. I'll address each of these individually for clarity sake:

Automated tests are ineffective if failures are acceptable

So much progress has been made in recent years with the PHP test suite -- the coverage for PHP 5.3 is at 70%. Obviously this isn't ideal, but PHP is a massive project, so it is understandable that it takes some serious time to build the testing suite toward 100% coverage. The big problem with the automated PHP tests is not that there are not enough but rather that it is not a requirement that tests pass. To make matters worse, it does not appear that new code is required to have significant test coverage either. At the time of this writing, there are 128 failing unit tests in PHP 5.3 (the current stable branch), and there are 129 failing unit tests in PHP 5.4. There is actually a small decrease in test coverage between the two versions as well (70.2% in 5.3 vs 70.0% in 5.4); I'm not sure whether this is the result of existing tests being removed or new code being committed without corresponding tests, but it is definitely not a trend that should continue.

The consequences of accepting failing tests were never more apparent than with the stable release of PHP 5.3.7. The details of which have been outlined numerous times all over the place (including in my last post), but the gist is that a serious bug that broke a common security component was introduced into the PHP repository, the automated tests actually identified that the bug existed, but the release happened anyway. There has been no official explanation for how this happened, but it appears to be the result of an unfortunate human error. At the time there were close to 200 tests failing, so it seems reasonable to assume that a human may have missed that one of those failed tests was actually due to a severe issue.

There are a couple things that could be done in order to solve this problem. Defining a coverage goal would be an excellent starting point. Ideally this goal would be 100%, but any goal above 80% would likely be a huge step in the right direction. Once a sufficient coverage goal has been defined, all new features committed to the HEAD should be required to have corresponding tests that match or exceed the coverage goal. Unless existing tests are removed, this will ensure that the test coverage can only increase over time. In addition, all current automated tests should run successfully. There appears to be an effort to identify which tests should be expected to fail, but that only partly addresses the problem. If a test is no longer applicable for some reason, then it should be removed. If it is applicable, then a bug exists that needs to be addressed.

The coverage goal and a requirement that all new commits need to exceed that goal can be done within the existing development process. Those are the easy parts of the issue to address. The more difficult issue is resolving the errors from the existing tests. Theoretically, more contributors could help a lot here; some of the failing tests probably belong to components that no longer have active maintainers, so the currently active core developers may not be the best to address the issue. Realistically, the hardest contributors to find are those that are comfortable writing C, and this is also the most difficult type of contribution to make when you're not already involved in the project. Resolving all of the failing tests will no doubt require both an increased effort by the existing core developers as well as an increase in the number of contributors.

Developer trust is shaken due to lack of communication

The developers managing the PHP project are only human, so mistakes are not only reasonable but also inevitable. The community (none more so than myself) needs to accept that fact and remember this when reacting to future mistakes. Nonetheless, incidents such as the failed release of 5.3.7 have shaken the trust that many community members place in the core developers to manage the project in a professional and stable way, and as a result there is a whole lot of mudslinging that happens when a mistake occurs.

Communication is the key, here. In my opinion, the worst single part of the release of PHP 5.3.7 was not the human error in deployment but rather a breakdown in sufficient communication. The two official means for people to follow important PHP announcements are the php.announce mailing list and the main news feed on the homepage of PHP.net. We are rapidly approaching 2012, but PHP has no developer blog much less an official social networking account (e.g. Twitter, Google+) to follow for technical updates.

The php.announce mailing list used to include security advisories in addition to releases, but this appeared to stop long ago. The announcement mailing list really should include all new releases, security advisories, and notices of unstable releases (e.g. 5.3.7). This should allow any one of the core developers to immediately draw attention to any stability-related/critical issues to anyone subscribed to the list. After 5.3.7 was released, it took four days for any official word to come down the chute that a problem existed. In that time, any number of people could have upgraded their production environments to the broken release, and it didn't have to play out that way! At least two core developers jumped on and fixed the issue the next day after release. That's pretty damn good turn-around. Unfortunately, it was still three days before an official notice was posted and a total of five days before a new release fixed the issue. In this case, a swift reaction from core developers was overshadowed by less-than-ideal communication, and that is truly a shame.

It would be nice to see an official development blog for PHP where any of the core developers could post articles about features that are being worked on and, more importantly, post-mortems for when things go to crap (again, 5.3.7). I know the core PHP developers didn't just brush 5.3.7 away from their minds the moment it happened. I know this because since then the number of failing unit tests has plummeted. I know this because I've been personally assured by a few core developers that measures are being taken to make sure similar problems do not happen for future releases. I do not know this based on any form of official communication from those managing the PHP project, and that is unfortunate.

We, the community, know that the core developers are working. We know that they're trying hard to make sure the core is stable. We know that they are introducing cool new features to help keep PHP competitive and modern. But we know all of this only because we've heard it through the grapevine. A developer blog would allow the core developers to speak, on their own terms, about failures that happen and what steps they're taking to avoid them. This is frequently all that is required to turn a horribly unfortunate situation into a positive experience for the community as a whole. If ever you needed a better example of that, compare the reactions from people losing their accounts and credit card information to Sony versus people losing their accounts and credit card information to Valve. For the former, the near-universal response was outrage. For the latter, most people responded positively. The gaming community did not rip Valve a new one because Valve did an excellent job communicating with them. Despite overwhelming failure, the community trusts Valve due to little more than communication alone.

Also, the features the core developers are working on are pretty damn sweet, so it definitely would be awesome to hear more from them about those ongoing pieces of development. I don't know if it would help on the "trust" front, but it would be awesome.

PHP itself is not broken; my title is sensational rubbish

I preserved the title from the previous article so that people can quickly make the connection between the two, but the original title really does not reflect my thoughts on the matter.

The PHP community is doing really awesome things. From extraordinary second generation frameworks down to one-click install applications that have unparalleled portability, the extent to which we lead the web is still amazing and humbling to me. The core PHP developers have long been a key component of that, and none of progress that modern PHP applications have made would be possible without their ongoing efforts. As a result of those efforts, PHP is a stable, secure, and beautifully-practical language that is both easy for novices to wrap their heads around and experts to build the most-used web applications the world has ever seen. PHP is not broken, but there are areas that can definitely be improved. Fixing unit tests and polishing methods of communication should seem minor in comparison to the monumental accomplishments of the past 15 years.

Edit (Aug 31 2011 8:05pm): When I started writing this article, my intentions were to criticize the PHP core developers for what I consider to be a severely broken process. I do want to make that clear. As a member of the community and a long-time PHP programmer, I find it indescribably irritating that a failure as significant as the release of PHP 5.3.7 could happen without the dev team at least backing up the release of PHP 5.3.8 with an analysis of exactly what happened and exactly what measures were being considered so that it never happened again. The problem here is not that a human made an error, the problem is that there were no measures in place to stop that error from happening, and so far there hasn't been (or I haven't seen) an official explanation of what measures will be put in place.

My irritation aside, this blog article does not do a good job identifying exactly what part of the process is broken, and it does an even worse job presenting practical solutions. The tone I set from the start of the article is more that of an offended user than someone interested in finding solutions, and it is certainly not inline with my original intentions. The core devs are no doubt responsible for the process in which they work, but they are also the group of people that will ultimately fix this problem.

I will be writing a follow-up to this article in the coming days that will hopefully address the concerns I have about PHP's development process without so much visceral rhetoric. Blog articles are a great way to present ideas to the public, but they are not a means to really enact change, so if I think my ideas can make a difference for the better, I will bring them to the PHP internals mailing list as well.

PHP's development process has been broken for a long time, and the failures of that process have swelled since the first ripples began to appear many years ago. The process didn't necessarily take a downward turn at any point; rather, it seems there was never really a sufficient or sustainable workflow from the start. This is no surprise given the very fluid history of PHP though, and the lack of any sustainable processes may have even been one of the key things that allowed PHP to evolve so quickly into one of the most used programming languages in the world. But that early success doesn't make the PHP development process any less broken.

Before I continue, I want to be perfectly clear: There are many reasons that people bring up for disliking PHP, and I will not be entertaining most of them here. If you do not like PHP because of things such as an inconsistent API, seemingly half-hearted additions (e.g. object model or namespace support), or any of the other language-specific beefs that spring up whenever someone leaps on their e-soapbox, please move along. This isn't the post for you. All things considered, I like PHP, and I think it is the best option for developing most of the applications that we see on the web today.

How PHP is Broken

The serious problems -- the ones that actually have long-term consequences, stem from the development process.

Through most of PHP's 16 year lifespan, it had a completely arbitrary release process. When core devs felt like they wanted to push a release, they got together, patched up some of the code that had been contributed for the many weeks, months, or years since the previous release, and tossed it out into the wild. The consequences of this still linger throughout the community (and the entire web) today: without any clear release planning, it was more efficient for organizations to leave their PHP versions un-upgraded than it was to incrementally upgrade their versions in a timely manner.

In addition to no sensible release cycle, the way new features were discussed, approved, or rejected was largely informal, difficult to follow, and without any sufficient time constraints. It was hard for anyone that didn't follow the mailing list and wiki word for word, every day to have much of any idea about what was going on.

PHP's test coverage is not good. To make matters worse, passing the existing unit tests is not a requirement for acceptance in the core. Why even write the unit tests if someone can simply choose to ignore them when merging in their code? This has to be the type of thing that Sebastian Bergmann has nightmares about.

Don't worry though, just because it is acceptable to commit code that breaks the unit tests doesn't mean that this will actually affect the stability of the releases, right? I mean, the stable releases of PHP at least pass the tests that they do have, right? Wrong. Surely you've all heard about the fiasco that was the PHP 5.3.7 release, but just in case you need a quick refresher:

Eleven days ago, PHP 5.3.7 was released as stable. One day prior to the release, a major bug was reported that identified an issue where using crypt() with md5 hashes was broken so badly that it was completely unusable across all platforms. Four days after the stable release, PHP.net finally got around to officially announcing the problem and a day after that they released PHP 5.3.8 with a fix. To their credit, many of the core devs did get the word out about this issue very quickly, but why it took four days to officially acknowledge the problem is completely beyond me.

The delay in an official acknowledgement of this issue is certainly disturbing, but here's the kicker: Even at only 70% code coverage, this bug was identified by the unit tests. The tests that were in place to make sure that bugs like this couldn't happen did their jobs -- they failed when they were suppose to fail. Without any automatic testing constraints in place for packaging releases, those failures went unnoticed, and a "stable" release of PHP with an application-breaking bug was released to the masses. For this to happen, one of two things had to occur: someone released a stable version without running tests on newly added code, or, more likely, someone didn't notice that there was a really important test failing because PHP 5.3 has 192 failing unit tests! What on earth is the point of writing unit tests when you consider it OK that some of the tests fail? The acceptance of these failures is perhaps the most backward-thinking decision that I have ever seen the PHP dev team make.

How This Can Be Fixed

PHP has made huge progress in recent months in getting its development process into an acceptable state. There is finally a detailed release process in place, so we know when to expect new code. There is finally a simple and visible voting process on new feature proposals, so we know what to expect in those upcoming releases. If the release of 5.3.7 is one of the worst blunders by the PHP dev team ever, then I'd say the addition of these two processes into the overall workflow is perhaps the single greatest decision they have ever made. Only in time will we be able to see what affect these two additions will have, but already the community is seeing clearer communications and expectations when dealing with proposals and releases.

Stop breaking tests. Stop it. Just, stop. The argument that is immediately brought up whenever someone like me talks about an issue like this is along the lines of "nothing is stopping you from contributing", but that isn't at all relevant here. Perhaps this argument would carry some weight if you were just considering the mountain of test failures that exist from the past, but that isn't all we're considering. PHP 5.4 has 26 more failed unit tests than PHP 5.3, and PHP HEAD has more still. Stop accepting code that isn't unit tested or that breaks existing tests.

Fix the broken tests. I know I just said that maybe you could argue for more contributors in this case, but really that is only one side of the coin. As a PHP user, it is not my responsibility to contribute to PHP. That's not how open source works, and it never will be how open source works. But as a user of the software, I can be upset when it doesn't work. I can be even more upset when it doesn't work due almost entirely to human negligence.

As core developers, you do have a responsibility to personally write good code and to, as a group, manage the project in a responsible manner. If you do both of these things -- if you do things like writing well-tested code and don't accept bush league crap like untested code (or worse, code that actually breaks tests), then I will be the first one to step to your defense whenever people get on your back.

More Contributors is Not the Solution

Throwing new contributors at the project will not fix these problems. If you want to expand the test coverage, improve the documentation, or do anything else that makes PHP better, then new contributors are the way to go. However, falling back on cavalier attitudes like the ones behind the statement "nothing is stopping you from contributing" is both insulting and counter-productive. It does absolutely nothing but decrease peoples' desire to contribute even more. As core developers, fixing the mistakes in the core development is your responsibility. Just because you are volunteering your time doesn't make this any less your responsibility. Volunteering is the act of taking on responsibilities at no cost, and that is something you chose to do. So, unless you're throwing in the towel and walking away from the project, don't insult the community by trying to offload your responsibilities (and failures) on us.

Also, stop it with stupid reactions like this (Sorry to single you out, Pierre. You are certainly not the only one with this attitude). If you are a core developer that helps to write and manage a project that powers websites and applications for billions of combined users, you don't get the luxury of demanding that people remain silent when your team makes an absolutely egregious mistake like the PHP 5.3.7 release just because those people didn't help you identify a mistake that your own processes should have identified. Next time we moan about features taking too much time to develop, feel free to play the "contribute or stfu" card.

When creating your choice field, you can specify which options are available by either passing an array of options ("choices") or by passing a custom object that implements \Symfony\Component\Form\Extension\Core\ChoiceList\ChoiceListInterface ("choice_list"). For this article, I will be focussing on the latter, but this can all be very easily adapted to a simple choices array.

Choice Lists and Doctrine 2 Entities

If the model that you bind to your form type is a doctrine 2 entity, then chances are the vast majority of your choice field's form logic will be taken care of for you. If you add a form field that matches an entity property that has an association to another entity, then Symfony guesses the correct form field type, retrieves the form field options, and even validates your input to make sure it is a valid option. It is, for the lack of a better term, awesome:

We'll need an entity:

<?php

namespace Epixa\\Entity;

use Doctrine\\ORM\\Mapping as ORM;

/**
 * @ORM\\Entity
 */
class Post
{
    // ... other post properties

    /**
     * @ORM\\ManyToOne(targetEntity="Epixa\\Entity\\Category")
     */
    protected $category;

    // ... appropriate getters an setters
}

We'll also need a form type:

<?php

namespace Epixa\\Form\\Type;

use Symfony\\Component\\Form\\AbstractType,
    Symfony\\Component\\Form\\FormBuilder;

class PostType extends AbstractType
{
    public function buildForm(FormBuilder $builder, array $options)
    {
        // ... add other appropriate form fields

        $this->add('category');
    }

    public function getDefaultOptions(array $options)
    {
        return array(
            'data_class' => 'Epixa\\Entity\\Post'
        );
    }

    public function getName()
    {
        return 'epixa_post';
    }
}

Tie it all together with your action:

<?php

public function addAction($topicId, Request $request)
{
    $post = new \\Epixa\\Entity\\Post($topic);

    $form = $this->createForm(new \\Epixa\\Form\\Type\\PostType(), $post);

    if ($request->getMethod() == 'POST') {
        $form->bindRequest($request);

        if ($form->isValid()) {
            // ... persist the $post in the db and redirect away
        }
    }

    return array(
        'form' => $form->createView()
    );
}

With that code in place, your form will have a select field that lists all categories as options, and validation will ensure that not only is a category provided but also that the category is one of the available options. Note: your category entity will need to have a __toString() method defined as this is used as the human-readable component of a select option.

Creating and Validating Non-Entity Models

Sometimes it is necessary to use a model in your form type that is not itself a Doctrine entity. Personally, I have encountered this mostly when dealing with deletion forms. Consider this scenario: let's say you are adding functionality to delete a specific Category entity (the same category that is referenced in our previous Post example), but in order to delete a category, you need to choose where all of its child posts should be moved. In this case, you want to display a select field with all possible categories, but you don't have the wonderful benefits of a doctrine entity with an association defined.

In this situation, create a new model to represent your deletion parameters, attach it to a form that is designed to render and validate the available parameters, and then use that model to perform the necessary business logic to move the child posts and delete the category. Again, let's go with an example.

The model here is a little more complex than the previous entity; pay careful attention to the "assert" annotations that I use here:

<?php

namespace Epixa\\Model;

use Epixa\\Entity\Category,
    Symfony\\Component\\Validator\\Constraints as Assert,
    Symfony\\Component\\Form\\Extension\\Core\\ChoiceList\\ChoiceListInterface,
    Symfony\\Component\\Validator\\ExecutionContext;

/**
 * @Assert\\Callback(methods = {"isInheritingCategoryValid"})
 */
class CategoryDeletionParams
{
    /**
     * @Assert\\NotBlank()
     */
    protected $inheritingCategoryId;

    protected $choices = null;

    public function setInheritingCategoryId($id)
    {
        $this->inheritingCategoryId = (int)$id;
        return $this;
    }

    public function getInheritingCategoryId()
    {
        return $this->inheritingCategoryId;
    }

    public function setInheritingCategoryChoices(ChoiceListInterface $choices)
    {
        $this->choices = $choices;
        return $this;
    }

    public function getInheritingCategoryChoices()
    {
        return $this->choices;
    }

    public function isInheritingCategoryValid(ExecutionContext $context)
    {
        $choiceList = $this->getInheritingCategoryChoices();
        if (!$choiceList) {
            throw new \LogicException('No choice list configured');
        }
        
        $choices = $this->getInheritingCategoryChoices()->getChoices();
        if (!array_key_exists($this->getInheritingCategoryId(), $choices)) {
            $propertyPath = $context->getPropertyPath() . '.inheritingCategoryId';
            $context->setPropertyPath($propertyPath);
            $context->addViolation('Invalid category', array(), null);
        }
    }
}

The NotBlank assertion on the $inheritingCategoryId ensures that a category id is required. The Callback assertion on the class ensures that the given category id is actually one of the available options. Note: Callback assertions cannot be placed on properties.

Now for the form type:

<?php

namespace Epixa\\Form\\Type;

use Symfony\\Component\\Form\\AbstractType,
    Symfony\\Component\\Form\\FormBuilder,
    Epixa\\Model\\CategoryDeletionParams;

class DeleteCategoryType extends AbstractType
{
    public function buildForm(FormBuilder $builder, array $options)
    {
        if (!isset($options['data']) || !($options['data'] instanceof CategoryDeletionParams)) {
            throw new \LogicException('No valid options provided');
        }

        $deletionParams = $options['data'];

        $builder->add('inheritingCategoryId', 'choice', array(
            'label' => 'Move all posts to:',
            'choice_list' => $deletionParams->getInheritingCategoryChoices()
        ));
    }

    public function getDefaultOptions(array $options)
    {
        return array(
            'data_class' => 'Epixa\\Model\\CategoryDeletionParams'
        );
    }

    public function getName()
    {
        return 'epxia_delete_category';
    }
}

In this form type, we have to do a little more leg work than we did before. The form builder doesn't have enough information to guess all of the field's details like it did with the doctrine entity, so we needed to specify that this is a "choice" field, with a custom label, and populated by a specific choice_list.

Next up? You guessed it; the action:

<?php

public function deleteAction($id, Request $request)
{
    // ... retrieve $category entity that matches the $id

    // This should be located in its own service. I am including it here to get the message across.
    $entityName = 'Epixa\\Entity\\Category';
    $em = $this->getDoctrine()->getEntityManager();
    $qb = $em->getRepository($entityName)->createQueryBuilder('c');
    $qb->where('c.id <> :category_id'); // we don't want to include the category we're deleting
    $qb->setParameter('category_id', $category->getId());
    $choiceList = new \\Symfony\\Bridge\\Doctrine\\Form\\ChoiceList\\EntityChoiceList($em, $entityName, null, $qb);

    $deletionParams = new \\Epixa\\Model\\CategoryDeletionParams();
    $deletionParams->setInheritingCategoryChoices($choiceList);

    $form = $this->createForm(new \\Epixa\\Form\\Type\\DeleteCategoryType(), $deletionParams);

    if ($request->getMethod() == 'POST') {
        $form->bindRequest($request);

        if ($form->isValid()) {
            // ... move all child posts to the category identified by $deletionParams->getInheritingCategoryId()
            // ... delete $category and redirect away
        }
    }

    return array(
        'form' => $form->createView()
    );
}

The controller above is a little rough. I included a lot of logic in there that should really go into a separate service, but I didn't want the complication of the example getting in way of the meat of the issue.

That's it! When you render the form, it will provided a Symfony 2 choice field rendered as a select field that is populated with all of the categories (except the one we're deleting). When you submit the form, it will check to make sure that not only is a category selected but also that the selection is actually one of the categories in the system.

I'm still only breaking the surface of the Symfony 2 form component, and I am finding that for all of incredible convenience that is provided for very common functionality there is likely an equal amount of frustration when trying to implement more specific pieces of functionality. That said, the component is certainly powerful, and I haven't yet come across a scenario that it couldn't handle.

Know of an easier way to do this? By all means let me know! I am eager to simplify processes like this as I expect to be doing this kind of thing frequently.

Edit (Aug 08 2010 4:40pm):

@Bernhard has provided an approach that seems to be much more in line with the usage that symfony devs envisioned. He notes that the entity field type takes care of validation for you and provides a convenient way to populate the select options as well. I've revised his example code only so much as to fit with the previous examples and execute properly:

Deletion parameters model:

<?php

namespace Epixa\\Model;

use Symfony\\Component\\Validator\\Constraints as Assert;

class CategoryDeletionParams
{
    protected $targetCategory;

    /**
     * @Assert\\NotBlank()
     */
    protected $inheritingCategory = null;

    // ... appropriate setters and getters
}

Form type:

<?php

namespace Epixa\\Form\\Type;

use Symfony\\Component\\Form\\AbstractType,
    Symfony\\Component\\Form\\FormBuilder,
    Symfony\\Component\\Form\\FormEvents,
    Symfony\\Component\\Form\\Event\\DataEvent,
    Doctrine\\ORM\\EntityRepository,
    Epixa\\Model\\CategoryDeletionParams;

class DeleteCategoryType extends AbstractType
{
    public function buildForm(FormBuilder $builder, array $options)
    {
        // creates the inheriting select field whenever the data (deletion params model) is set
        $builder->addEventListener(FormEvents::PRE_SET_DATA, function(DataEvent $event) use ($builder){
            $data = $event->getData();
            if (!$data instanceof CategoryDeletionParams) {
                return; // $data is null when form is first constructed
            }

            $event->getForm()->add($builder->create('inheritingCategory', 'entity', array(
                'label' => 'Move all posts to:',
                'class' => 'Epixa\\Entity\\Category',
                'query_builder' => function(EntityRepository $repo) use ($data){
                    $qb = $repo->createQueryBuilder('c');
                    $qb->where('c.id <> :category_id');
                    $qb->setParameter(‘category_id’, $data->getTargetCategory()->getId());
                    return $qb;
                }
            ))->getForm());
        });
    }

    // ...
}

Action:

<?php
public function deleteAction($id, Request $request)
{
    // ... retrieve $category that matches $id

    $params = new \\Epixa\\Model\\CategoryDeletionParams($category);
    $form = $this->createForm(new \\Epixa\\Form\\Type\\DeleteCategoryType(), $params);

    if ($request->getMethod() == 'POST') {
        $form->bindRequest($request);

        if ($form->isValid()) {
            // ... move child posts to inheriting category, delete target category, redirect away
        }
    }

    return array(
        'form' => $form->createView()
    );
}

I think this approach is much clearer than my original example. Thanks Bernhard!

Since then, something has changed. Writing blog articles is almost as time consuming as reading a couple dozen active blogs a day, and authors feel compelled to write only when they have a lot to say on a subject. Microblogging services such as twitter and identi.ca have made sharing thoughts and ideas much quicker, and they give the appearance of more active discussions because it is just so damn easy to write 140 characters about pretty much anything.

In recent years, and especially in recent months, my RSS reader has slowed down significantly. I have no less subscriptions than I did years ago, but there are only a fraction of the numbers articles each day in my feed. Since blogs had such a significant impact on me, this recent trend is absolutely crushing.

A lot of people are talking about Chris Shiflett's Ideas of March plea. Chris Cornutt rightfully points out that blogs are a fantastic way for people to archive their thoughts and experiences and share their knowledge. Elizabeth Naramore emphasizes that blogs help spur great conversations, and I personally believe these conversations can be as useful, if not more useful, than the articles themselves.

One key point that I feel like many people are missing is how unbelievably important blogging is to the new guy. When you're getting involved with any community, the first thing you do is start reading what those community members have to say. You look for aggregator sites such as PHP Developer and Planet PHP, and that immediately gives you access to the complete modern history of the community. At your fingertips is all of the shared knowledge that the best minds in the community have to offer.

When the community archives its collective knowledge on blogs, then new community members not only have an invaluable resource, but they also have the means to get involved in a real way. When you post a comment on a blog, it does not matter who you are; you do not need to prove your worth in order to get well-known "followers" so that your message gets heard. A person's contribution to the discussion is valued strictly on its quality rather than how prominent the individual is in the community. When that happens, the whole community wins.

Like many have already pledged to do, I will try to do more blogging this month in the spirit of the Ideas of March, and hopefully that habit will linger for some time to come. At the same time, I eagerly await the onslaught of blog articles in my dwindling RSS feed.

Since starting work with Echolibre in June of last year, I have learned a lot about how to work effectively and efficiently at home. I avoid the common pitfalls that make working from a home-office distracting and/or unproductive by the following principles:

Find a dedicated space to call your own

Before I began working from home, I had visions that doing so would involve lounging on the couch, sitting outside in the sunshine, and working pretty much anywhere other than a traditional desk, chair, small-office-plant type of environment. I quickly learned that I am more productive and organized when I have a dedicated work area. A dedicated space is any area of your house that is used for nothing other than your work -- it doesn't second as a dining room table, it isn't in the middle of your living room, and it isn't even a place to throw household mail. It is a place that you can always go to work without having to bother with the distractions of a normal household.

Don't get me wrong, working on the couch, outside, or in book stores/coffee houses can be really beneficial. I've found that I can often jumpstart my creativity by working in a fresh place. But a stable, dedicated space is ultimately where I am most productive on a regular basis.

Create a routine and try to stick to it

Set up a daily/weekly routine. It is awesome that you can deviate from that routine when necessary, but deviate from that routine only when necessary. Constant delays to your schedule will only prolong the amount of time in the day that you are ultimately dedicating to work. Seemingly "little" things such as watching a bunch of novelty videos online will make it seem like you are far less productive, and you will have to work much longer hours in order to make up for it.

If you don't tend to rise early, then go nuts and wake up at 9am, but do so consistently. You'll find that with a regular routine, it will be easier to fit other activities in your schedule (see "Get out more" below). I challenge anyone to cultivate a healthy social life, regular exercise, and a work/personal life balance when their work schedule completely varies from day to day.

Get out more

If you're lucky, your significant other will also work from home, so you'll have at least some social interaction throughout the day, but this is not enough. Go out with friends, take your significant other out to dinner and a show, get a cup of coffee and take some time to relax in a public space. It is too easy to stay home, and you will begin to feel lethargic and uninspired.

Get dressed

Pajamas are the enemy here. You're not going out, so you don't feel like you need to be presentable to the world, and those flannel pj's you have are really quite comfortable. It will be really tempting to stay in your lounging or sleeping clothes, but make getting dressed part of your routine. You don't need to dress up in business-wear or anything, but at least wear clothes that you would wear out to family restaurant or to run errands. Wearing PJs all day should be an event that is worth noting -- it should be something that happens infrequently enough that it feels rewarding to do so.

Love what you do

The easiest way to become unproductive, uncreative, and outright bored while working from home is to simply not enjoy the work that you do. Half of your life is spent working, and never is this more evident than when you spend the vast majority of your time in one place. If you don't absolutely love what you do, then it will be that much more difficult to avoid the myriad of other things that you prefer to do at home in your free time.

Plus, you only live once, so why waste any of that precious time doing something that you do not find rewarding?

The obvious solution to this hard-coding issue is to instead rely on objects being explicitly passed via a constructor and/or mutators. If your service requires a database adapter, create a setDbAdapter() method and whenever you instantiate a new service object, pass in the adapter. This solution provides an incredible amount of flexibility, but it does force you to set an adapter on every single service instantiation. For most applications, only one database adapter will ever be required, so it is tedious at best to pass in the adapter to each and every service.

This is where many developers (and frameworks) turn to a global registry. During the bootstrap process, they will configure a database adapter and store it in a singleton registry, and then their service object would retrieve the adapter from the registry. This gives you flexibility when configuring and setting your adapter, and it allows you to instantiate a new service without having to explicitly set commonly used dependencies, but you are ultimately just replacing one hardcoded object call with another. This means you are still limited in your ability to unit test the class properly, and you will have a difficult time debugging if you ever need to find out exactly when and where your database adapter was configured.

The Simple Solution

Use static methods to set a default database adapter for all services that need it but still allow database adapters to be set explicitly. In your bootstrap process, you configure your database adapter just like you would normally, then you set the adapter as the "default" adapter for all services. The service should have a getDbAdapter() method that pulls either the adapter set on that instance or, if there is no adapter set, it uses the default adapter instead.

This is what your abstract service could look like (adapted from my doctrine2 entity manager service):

<?php
namespace Epixa\\Service;

use Epixa\\Exception\\ConfigException,
    Zend_Db_Adapter_Abstract as DbAdapter;

abstract class AbstractDbService
{
    protected $dbAdapter = null;

    protected static $defaultDbAdapter = null;

    
    /**
     * Set the default database adapter for all database services
     * 
     * @param DbAdapter $dbAdapter
     */
    public static function setDefaultDbAdapter(DbAdapter $dbAdapter)
    {
        self::$defaultDbAdapter = $dbAdapter;
    }

    /**
     * Get the default database adapter for all database services
     * 
     * @return DbAdapter
     * @throws ConfigException If no default database adapter is set
     */
    public static function getDefaultDbAdapter()
    {
        if (self::$defaultDbAdapter === null) {
            throw new ConfigException('No default database adapter configured');
        }

        return self::$defaultDbAdapter;
    }

    /**
     * Set the database adapter for this service
     * 
     * @param  DbAdapter $dbAdapter
     * @return AbstractDbService *Fluent interface*
     */
    public function setDbAdapter(DbAdapter $dbAdapter)
    {
        $this->dbAdapter = $dbAdapter;
        
        return $this;
    }

    /**
     * Get the database adapter for this service
     *
     * If no database adapter is set, set it to the default database adapter.
     *
     * @return DbAdapter
     */
    public function getDbAdapter()
    {
        if ($this->dbAdapter === null) {
            $this->setDbAdapter(self::getDefaultDbAdapter());
        }

        return $this->dbAdapter;
    }
}

Then, in your bootstrap, you would just need to set the default adapter:

<?php

use Epixa\\Application\\Bootstrap as BaseBootstrap,
    Epixa\\Service\\AbstractDbService as DbService;

class Bootstrap extends BaseBootstrap
{
    /**
     * Set the default database adapter for database services
     */
    public function _initDbServices()
    {
        $db = $this->bootstrap('db')->getResource('db');
        DbService::setDefaultDbAdapter($db);
    }
}

This code is adhering to Zend Framework's bootstrapping implementation, but the premise is universal: set up your database adapter, and set it as the default on the abstract service. After that is done, any class that extends AbstractDbService will have access to the database adapter. However, if they needed to have their own database adapter set (either for unit testing purposes or if they happened to need to access another database), you can do so on an individual basis. In either case, the way you access the database adapter within your service remains unchanged.

And that's it! Go ahead and mock your dependencies for unit testing or throw around different database adapters at your pleasure.

Ok, ok... That isn't entirely it.

There is One Large Caveat

If your objects rely on a large [variable] number of dependencies, a single abstract class might not do the trick. My services generally do not require more than an entity manager and an ACL object, and I imagine many developers will be in a similar boat. That said, this is not the best solution out there for handling a lot of dependencies. If this is not sufficient for your needs, consider a more robust system such as Symfony's dependency injection framework.

A Final Note

With the addition of traits in the PHP trunk, this method of setting defaults for dependencies will actually be that much more powerful. Instead of having to deal with a single abstract class, each dependency can be managed by a single trait, and your objects will be able to pick and choose whichever traits they need. Neat, eh?

Fortunately, the PHP core offers sprintf()/printf() which can greatly improve the readability of your code and even limit the amount of work you need to do to perform common formatting and type casting on your strings.

Why is String Formatting so Great?

This is a pretty silly question, I know. Let's face it, whether or not you use sprintf, you format strings all the time. You cast variables to certain types, you format float representations of currency, you put multiple values together, etc. The key here is, sprintf makes all of that incredibly easy, and it does so while making your code easier to read.

Want to do any of the things I just mentioned? Piece of cake:

<?php
$money = 29.5;
printf('Approximately $%d.', $money);
// outputs: Approximately $29.
printf('Exactly $%01.2f.', $money);
// outputs: Exactly $29.50.

$total = 1;
printf("%d item%s total.", $total, $total != 1 ? 's' : '');
// outputs: 1 item total.
$total++;
printf("%d item%s total.", $total, $total != 1 ? 's' : '');
// outputs: 2 items total.

Visualize the Goal

We'd like to avoid doing it, but as developers of dynamic applications, we are frequently forced to build complex strings on the fly. If you handle this with concatenation, you are almost assuredly creating strings that are difficult to read without careful scrutiny. Consequently, it is difficult to determine the intent of the completed string which can cause unexpected results or trigger errors. The functionality offered by sprintf allows us to visualize the template of the string that we're ultimately trying to create, so it can greatly improve readability and save you some annoying debugging time.

Consider creating a fairly simple, dynamic email link in HTML:

<?php
$email = 'dynamic@email.com';

printf('<a href="mailto:%1$s">%1$s</a>', htmlentities($email));
echo '<a href="mailto:' . htmlentities($email) . '>' 
    . htmlentities($email) . '</a>';

These are both designed to output the same thing, but since the first one separates the string formatting into two distinct parts: it first sets up the goal string and then escapes the variable input. This separation makes it very clear what you are trying to accomplish and what has to be done to accomplish it, and it is easier to debug either step as a result.

The concatenation version is harder to read and all of your work is muddied throughout the process. This makes it more difficult to quickly identify bugs. Speaking of which, did you notice that the concatenation version is bugged in the example? If not, look closer (if so, thanks for proof reading my code so thoroughly!). This type of bug is especially heinous since some browsers may render it perfectly fine.

Now, take a look at a dynamic SQL query where I'll let the results speak for themselves. There is not a bug (that I'm aware of) in this code, so consider this simply from a readability standpoint:

<?php
$userId = 1;
$limit  = 10;
$offset = 30;

$columns = array(
    'b.id', 'b.title', 'b.date', 'b.content', 'u.name', 'u.email'
);

$where = array(
    $dbAdapter->quoteInto('u.id = ?', $userId),
    'b.date_published is not null'
);

$dbAdapter->query(sprintf(
    'SELECT %s 
        FROM Blog b INNER JOIN User u ON u.id = b.user_id 
        WHERE %s LIMIT %d OFFSET %d',
    implode(', ', $columns), implode(' AND ', $where), $limit, $offset
));

$dbAdapter->query(
    'SELECT ' . implode(', ', $columns) 
        . ' FROM Blog b INNER JOIN User u ON u.id = b.user_id 
            WHERE ' . implode(' AND ', $where) 
        . ' LIMIT ' . (int)$limit . ' OFFSET ' . (int)$offset
);

Concluding Thoughts

This is not a very complex concept; while you can do more with the PHP string formatting functions than what I've shown here, they are not miracle gifts to your programming arsenal that will instantly make you god's gift to the web. They can, however, make your code easier to read, and that translates to less animosity between you and the next sap that has to maintain your code, and they can even save you some time in identifying some common but frustrating mistakes.

Hint: Use sprintf when you're throwing exceptions. You may find yourself making clearer messages that also include more useful information for the user:

<?php
throw new InvalidArgumentException(sprintf(
    'Received value of type `%s` but expected value of type `integer`',
    gettype($param)
));

The First Problem

The problem stems from the initial decisions about the naming conventions for directories and classes for controllers and views. The convention that controllers would be stored in a directory called "controllers" and views would be stored in a directory called "views" throws any attempt at dynamic autoloading immediately out the window. Instead, this single design decision served to ensure that all attempts to autoload consistently-named module-based PHP classes would require some sort of explicit configuration. As a result, many developers decided to put their classes such as forms, models, and mappers into separate libraries -- not very modular, eh?

The Official Solution: AKA The Second Problem

Enter the current implementation of "resource" autoloading. This greatly anticipated addition to Zend Framework was to solve our insatiable hunger for module-specific classes (hereto referred to as "resources"). The immediate effect was our modules could finally autoload our most used module resources. Unfortunately, every single type of resource has to be explicitly defined for each module! To help make this configuration easier, a "module" autoloader was added to Zend_Application that pre-configures common resources such as models and forms. But think of that for a second. An entire class was added to the framework with no other purpose other than pre-configuring options. If that doesn't scream red-flag, I don't know what does.

Let's Talk Solutions

I am extremely opinionated, and I could probably rant for hours about a topic like this, but I digress. Instead, let's look at a proof of concept that I implemented:

http://github.com/epixa/Epixa

The premise is pretty simple: modules should be nothing less than near-independent libraries of code. When modules are treated like libraries in their own right, they gain all of the flexibility and speed that we get from autoloading library files. Better yet, the main autoloader in Zend Framework can handle the autoloading all on its own, which means your module resources can be namespaced.

With extensions in that library, you can achieve a directory structure like the following with little to no configuration:

What We're Missing

This is currently to serve only as a proof of concept, so there is still plenty that can be added. For instance, while I updated the dispatcher so controllers are namspaced like "Blog\Controller\Post", I did not remove the class loading logic from the dispatcher itself. To separate concerns, the controller class loading should be passed off entirely to the autoloader.

The library also still leaves a lot to be desired when it comes to efficient module bootstrapping and plugin loading. I'll post improvements in both of those regards along with module dependency loading in the near future.

In the meantime, I would love feedback about this approach. If I can refine it a bit further, I plan to campaign for its inclusion as the standard module setup in Zend Framework 2.

I'm saddened because I loved working at Modo. It was wonderful being a part of a rapidly growing company from very early on, and I was constantly challenged [in a good way] by the myriad of new and cutting edge technologies that we implemented in some of the most fantastic client projects I have come across to date. Modo is comprised of some of the most talented and inspiring individuals I have ever had the privilege of working with, and I truly wish them the best of luck in everything they do.

I am excited because I will be joining the team at echolibre on June 29th. They are an amazing bunch of guys with seemingly endless talent, and I cannot wait to start contributing to the team. I am always looking to expand my current skillset and work with the best people in the industry, and I believe I will do just that with the fellas from abroad.

Integrating with Salesforce CRM begins with the Force.com Web Services API. The API is SOAP based, so you can use PHP's built in soap extension to make calls to the service, but in this tutorial I'll be using the PHP Toolkit provided by Salesforce; you still need to have the php soap extension installed, but the toolkit provides convenient utility methods for all of the available api calls.

Generate your WSDL

The first thing you'll need to do to access your salesforce via the api is generate a WSDL. The soap client requires the WSDL in order to, among other things, know what calls it can make to the server.

You have a few options when it comes to generating WSDLs in salesforce; I prefer to use the strongly typed Enterprise WSDL whenever possible. Enter your salesforce 'setup' section, traverse to Develop > API, and click the "Generate Enterprise WSDL" link (see screenshot below). On the following step, just leave all the versions at the defaults and click the "Generate" button. Save the XML that is generated into a new file in your application.

Get your Security Token

To access the soap service, you will need to provide your username, password, and the security token that is generated for your account. The security token is a random 25 character string of uppercase and lowercase letters and numbers. If you are not sure what your security token is, you can generate a new one through the salesforce 'setup' page (see screenshot below). While you can reset your security token at any time, take heed of the notices that pepper the security-token section of the salesforce setup: if you change your security token, all existing api applications that rely on the token will break unless they are updated with the new token.

Get your Code On

Now that we have the boring salesforce groundwork out of the way, let's write some code! First up, get connected:

<?php

$wsdl  = 'enterprise-wsdl.xml';
$user  = 'example@epixa.com';
$pass  = 'supersecure';
$token = 'fAjfS4FkxLsoqPxmsZujj0Szr';

$client = new SforceEnterpriseClient();
$client->createConnection($wsdl);
$client->login($user, $pass . $token);

The five core method calls that you must know are upsert, retrieve, getUpdated, delete, getDeleted. There are many more, but knowing these powerful five is sufficient to do a large number of synchronization scripts.

SforceEnterpriseClient::upsert()

While the Salesforce API does offer create() and update() methods, you will probably find yourself using this nifty function to accomplish either task: upsert() will attempt to insert a new record, and if an existing record that matches the field you specify already exists, it will update that record instead. For those familiar with MySQL, this is basically the equivalent of INSERT ON DUPLICATE KEY UPDATE.

<?php

$first = new stdClass();
$first->Name = 'First Epixa Widget';
$first->Description = 'This Epixa Widget is the best product of all time!';

$client->upsert('Name', array($first), 'Product2');
// result: a new product is created in salesforce

$second = new stdClass();
$second->Name = 'Second Epixa Widget';
$second->Description = 'No, THIS Widget is the best product of all time!';
$client->upsert('Name', array($second), 'Product2');
// result: a new product is created in salesforce

$clonedFirst = clone $first;
$clonedFirst->Description = 'FINE, Second Widget.  You can be the best product.';
$client->upsert('Name', array($clonedFirst), 'Product2');
// result: the first object's description is updated in salesforce

SforceEnterpriseClient::retrieve()

The core method retrieve() allows you to query for one or more of a specified Salesforce object given a set of unique Ids:

<?php

$ids = array('01tA0000000YU4D', '01tA0000000YU48');

$results = $client->retrieve('Id, Name, Description', 'Product2', $ids);
print_r($results);
// results:
// Array
// (
//     [0] => stdClass Object
//         (
//             [Id] => 01tA0000000YU48IAG
//             [Description] => FINE, Second Widget.  You can be the best product.
//             [Name] => First Epixa Widget
//         )
//     [1] => stdClass Object
//         (
//             [Id] => 01tA0000000YU4DIAW
//             [Description] => No, THIS Widget is the best product of all time!
//             [Name] => Second Epixa Widget
//         )
// )

SforceEnterpriseClient::getUpdated()

Whenever you are polling for data from Salesforce, getUpdated() is probably the method you're going to use. This will return an object that contains an array of all the unique Ids of objects that match the supplied type that were updated between the timestamps you pass it. In addition to the array of Ids, the returned object also contains a timestamp in DATE_ATOM format of the last date covered in your getUpdated call that you can store and use for the start date in your next call to getUpdated(). Couple this with a call to retrieve(), and you can easily query for all objects updated since the last time your script ran.

<?php

$results = $client->getUpdated('Product2', strtotime('-7 days'), time());
print_r($results);
// stdClass Object
// (
//     [ids] => Array
//         (
//             [0] => 01tA0000000YU48IAG
//             [1] => 01tA0000000YU4DIAW
//         )
//     [latestDateCovered] => 2010-05-19T00:29:00.000Z
// )

SforceEnterpriseClient::delete()

This does not really require any explanation; however, it is worth noting that objects deleted through the delete() method are only logically deleted. This will simply set the IsDeleted flag to true.

<?php

$client->delete(array('01tA0000000YU4D', '01tA0000000YU48'));
// result: Two products with the passed Ids are marked as deleted in salesforce

SforceEnterpriseClient::getDeleted()

The method getDeleted() is very similar to getUpdated() -- it takes exactly the same parameters, but it returns a slightly different object. The returned object still has the latestDateCovered property, but it also has an earliestDateAvailable property which is a DATE_ATOM formatted timestamp of the last physically deleted object. Rather than having an array of Ids, the object returned by getDeleted() has an array of objects each with the Id of the deleted object and the timestamp of when that object was actually deleted.

<?php

$results = $client->getDeleted('Product2', strtotime('-7 days'), time());
print_r($results);
// stdClass Object
// (
//     [deletedRecords] => Array
//         (
//             [0] => stdClass Object
//                 (
//                     [deletedDate] => 2010-05-19T02:38:31.000Z
//                     [id] => 01tA0000000YU48IAG
//                 )
//             [1] => stdClass Object
//                 (
//                     [deletedDate] => 2010-05-19T02:38:31.000Z
//                     [id] => 01tA0000000YU4DIAW
//                 )
//         )
//     [earliestDateAvailable] => 2010-03-12T01:13:00.000Z
//     [latestDateCovered] => 2010-05-19T00:29:00.000Z
// )

Hold up, there are some 'gotchas'

1. Calls to retrieve() do not always return an array of objects! If only one result is returned, only that object will be returned. I cannot begin to imagine who made this bonehead-decision, but it can be frustrating if you're not expecting it.
2. The PHP Toolkit handles some errors by throwing exceptions. This is immensely convenient. However, not all errors are thrown! For methods such as create(), make sure you check the returned value for the property 'errors'. In addition to signifying that an error has occurred, the 'errors' object contains information that can be useful in debugging the issue.

Integrating with Salesforce can be a frustrating experience, but it is hard to avoid if you work with any small to medium companies that take their CRM solutions seriously. There are many more possibilities beyond what I outlined here, so I recommend that you familiarize yourself with the API documentation that I linked to throughout this article before beginning any Salesforce integration project.

While models do contain specific data, they are far more than simple data structures. They should contain all logic possible to manage, manipulate, and validate the correctness of data as it is updated. By treating your models as nothing more than a place to dump your data, you are doing yourself and your application a severe disservice; your business logic is going to be scattered throughout the rest of your application, and you will have a progressively more difficult time as you try to maintain and build upon your existing system. Do not fall into the anemic model trap.

In addition, models should be independent of the data-access layer. If I am modeling a blog article, the article should not know nor care to know whether it was created from a mysql database, an xml file, user input, or the divine spaghetti monster. No matter how it was populated or where it was persisted, the blog article is a blog article, and that is all that is important.

To manage my data access, I am a huge proponent of Doctrine 2. Of which, one of my favorite features is that my models are completely decoupled from Doctrine itself. This means there is no base model class that defines a ton of functionality for interacting with your data abstraction, so you have near endless flexibility when it comes to creating your models. However, just because you are not required to extend a base record class does not mean that working with many of your models cannot be improved with some simple, abstract implementations. Utilizing a simple abstract model and a few best practices can ensure your models remain incredibly versatile while still preserving the strict integrity of your data.

Let's start with a simple blog article model:

<?php
namespace Blog;

use Epixa\AbstractModel;

/**
 * @Entity
 * @Table(name="blog_article")
 */
class ArticleModel extends AbstractModel
{
    /**
     * @Id @Column(type="integer")
     * @GeneratedValue
     */
    protected $id;

    /**
     * @Column(type="string")
     */
    protected $title;

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

    /**
     * @Column(type="text")
     */
    protected $content;

    /**
     * For demonstration purposes only
     */
    protected $_hiddenProperty;
}

In our AbstractModel, we will utilize php's magic methods to provide access to our entity properties in both a convenient and secure way. All calls to retrieve a property's value will map through an appropriate accessor if one exists, and all attempts to set an entity property will map through an appropriate mutator if one exists.

<?php
namespace Blog;

abstract class AbstractModel
{
    /**
     * Map a call to get a property to its corresponding accessor if it exists.
     * Otherwise, get the property directly.
     *
     * Ignore any properties that begin with an underscore so not all of our
     * protected properties are exposed.
     *
     * @param  string $name
     * @return mixed
     * @throws \LogicException If no accessor/property exists by that name
     */
    public function __get($name)
    {
        if ($name[0] != '_') {
            $accessor = 'get'. ucfirst($name);
            if (method_exists($this, $accessor)) {
                return $this->$accessor();
            }

            if (property_exists($this, $name)) {
                return $this->$name;
            }
        }

        throw new \LogicException(sprintf(
            'No property named `%s` exists',
            $name
        ));
    }

    /**
     * Map a call to set a property to its corresponding mutator if it exists.
     * Otherwise, set the property directly.
     *
     * Ignore any properties that begin with an underscore so not all of our
     * protected properties are exposed.
     * 
     * @param  string $name
     * @param  mixed  $value
     * @return void
     * @throws \LogicException If no mutator/property exists by that name
     */
    public function __set($name, $value)
    {
        if ($name[0] != '_') {
            $mutator = 'set'. ucfirst($name);
            if (method_exists($this, $mutator)) {
                $this->$mutator($value);
                return;
            }

            if (property_exists($this, $name)) {
                $this->$name = $value;
                return;
            }
        }

        throw new \LogicException(sprintf(
            'No property named `%s` exists',
            $name
        ));
    }

    /**
     * Map a call to a non-existent mutator or accessor directly to its
     * corresponding property
     *
     * @param  string $name
     * @param  array  $arguments
     * @return mixed
     * @throws \BadMethodCallException If no mutator/accessor can be found
     */
    public function __call($name, $arguments)
    {
        if (strlen($name) > 3) {
            if (strpos($name, 'set') === 0) {
                $property = lcfirst(substr($name, 3));

                $this->$property = array_shift($arguments);
                return $this;
            }

            if (0 === strpos($name, 'get')) {
                $property = lcfirst(substr($name, 3));

                return $this->$property;
            }
        }

        throw new \BadMethodCallException(sprintf(
            'No method named `%s` exists',
            $name
        ));
    }
}

With these simple methods, our protected entity properties are accessible like public properties, but individual models can ensure that their access and modification is still bound by filtering/validation through mutators and accessors. Let's implement some of these in our article model:

<?php
// ...
class ArticleModel extends AbstractModel
{
    // ...

    /**
     * Constructor
     * 
     * Set the date to right now
     */
    public function __construct()
    {
        $this->setDate('now');
    }

    /**
     * @throws \BadMethodCallException Every time
     */
    public function setId()
    {
        throw new \BadMethodCallException('Cannot set article id directly');
    }

    /**
     * Set the article title
     * 
     * @param  string $title
     * @return ArticleModel *Provides fluid interface*
     * @throws \InvalidArgumentException If title is less than 3 characters
     */
    public function setTitle($title)
    {
        $title = trim($title);

        if (strlen($title) < 3) {
            throw new \InvalidArgumentException('Title must be more than 3 chars');
        }

        $this->title = $title;

        return $this;
    }

    /**
     * Set the article date
     * 
     * @param  mixed $date
     * @return ArticleModel *Provides fluid interface*
     * @throws \InvalidArgumentException If invalid date is given
     */
    public function setDate($date)
    {
        if (is_int($date)) {
            $date = new \DateTime("@$date");
        } else if (is_string($date)) {
            $date = new \DateTime($date);
        } else if (!$date instanceof \DateTime) {
            throw new \InvalidArgumentException(sprintf(
                'Expecting string, int or DateTime but `%s` given',
                gettype($date)
            ));
        }

        $this->date = $date;

        return $this;
    }

    /**
     * Get the article date in a human readable format
     * 
     * @return string
     */
    public function getFormattedDate()
    {
        return $this->date->format('F j, Y');
    }
}

With that, our article model filters and validates incoming and outgoing data. Our article date is set immediately upon instantiation, the title is always trimmed and its length validated, the date can be set by multiple different types of values but is always stored as a DateTime, and we can utilize a convenience accessor (even as a property) to get the date formatted as a string.

If you are the type of developer that insists on having 100% data integrity in your models at all times, you could take this filtering and validation one step further by passing all required fields as arguments in the constructor. On the other hand, if you're like me you would abstract out the logic for handling data validation, so you could reuse the validation in forms that accept input from the user to populate your models and create a prePersist lifecycle callback (Doctrine only) that runs through the validation before a new model is persisted in the database.

To finish this up, here are some ad hoc examples of code using the ArticleModel:

<?php

$article = new Blog\ArticleModel();

$article->title = '   My Article Title ';
echo $article->title;
// outputs: My Article Title

$article->title = 'My';
// throws exception: Title must be more than 3 chars

$article->date = 'yesterday';
echo $article->formattedDate;
// outputs: May 5, 2010

echo $article->setContent('This is my content')->getContent();
// outputs: This is my content

$article->_hiddenProperty;
// throws exception: No property named `_hiddenProperty` exists

Other Resources about Models

• Model Infrastructure - Matthew Weier O'Phinner
• Models in Zend Framework - Matthew Turland

Anyone who's written code in Java, C++, or for any language in ASP.NET has had the pleasure of working with them, but we PHP developers have had to settle with emulating namespaces by defining long class prefixes.

Prefixes serve their primary purpose well: when used correctly, they will ensure that your class names do not have naming conflicts. Unfortunately, they are long and pedantic, and provide no additional benefits. Take, for example, the following class name: ZendServiceDeveloperGardenResponseConferenceCall_CreateConferenceResponseType which can be found in Zend Framework. At 81 characters, the name of this class by itself breaks the recommended line length in Zend's own coding standard, and it is not even the longest class name in the framework!

Namespaces provide other benefits than shorter class names, though. Consider the following:

<?php
namespace Epixa\\Service;

use Epixa\\Model\\ArticleModel,
    Epixa\\Model\\AuthorModel;

class ArticleService extends AbstractService
{
    /**
     * @param  string      $title
     * @param  AuthorModel $author
     * @return ArticleModel
     */
    public function create($title, AuthorModel $author)
    {
        $article = new ArticleModel();
        $article->title = $title;
        $article->author = $author;
        return $article;
    }
}

The namespace declaration immediately gives you a clear indication of what type of class is being declared -- a service within the Epixa library.

Along with simply declaring a namespace, the file then uses other namespaces. In this particular case, I chose to import the specific classes ArticleModel and AuthorModel. I could have simply used the Epixa\Model namespace, and then I would be able to instantiate any models within the namespace, but importing the specific models that I plan to use is a clear way to define class dependencies.

At this point, we haven't even declared the class, yet we already know what type of class it will be and what dependencies it will have. Throughout the rest of the class declaration and definition, the concise class names are used. Long, ugly prefixes are left in the dust, and the code is cleaner and clearer as a result.

But Court, it'll be forever until the community adopts PHP 5.3!

While this sentiment might have been true for past releases of PHP, developers finally seem to be coming around to the notion that software drives the community forward. When software increases its requirements, server administrators will follow suit.

In less than a year, industry-leading frameworks such as Zend Framework and Symfony have decided to utilize these new features to such an extent that 5.3 will be a minimum requirement. The Doctrine team is well into its development roadmap which includes a new minimum requirement of PHP 5.3; they have already slated an end-of-life date for their 1.x branch and are taking the release of PHP 5.3 not as a challenge but as an opportunity to radically improve their codebase.

Don't be left in the dust; the PHP community is moving forward with version 5.3, and an easy upgrade path means you can start benefiting from incredible language features such as namespaces immediately.