Paul M. Jones

I was part of the organizing committee for yesterday's Tax Day Tea Party here in Memphis. That sounds kind of formal; it was just a bunch of folks who found each other on the internet and (with some amount of arguing, mostly from me ;-) got an event put together. Talk about an emergent phenomenon.

I can only call it a resounding success. We had at least 4000 (yes, four thousand or more) people in attendance, according to the professional sound crews in attendance and media folk who were on site. You'd be hard pressed to discover that from newspapers or television reporting today.

We're not the only ones who had high attendance; see more here http://pajamasmedia.com/instapundit/76810/ and elsewhere.

My duties kept me from actually watching any of the speakers. I helped direct traffic for 3 hours to get people safely in and out, with three other guys handling the arrangement of parking everyone on the grass (the lot overflowed immediately). That 4000 number seems pretty likely to me, given the traffic.

If you are interested in the Memphis Tea Party, take a look at thememphisteaparty.com website, or our Facebook group page, or contact me directly if you like.

I expect at some point I will write more about this. There's more to it than I'm hearing about on the news, for sure. One wonders how far it can go.

UPDATE: Oh, and the Facebook page for the Tax Day event itself is here.

UPDATE 2: Some of the Facebook albums:

• http://www.facebook.com/album.php?aid=85201&id=1313801738&ref=share
• http://www.facebook.com/album.php?aid=18048&id=1075848630&ref=share
• http://www.facebook.com/album.php?aid=73752&id=643768019&ref=share
• http://www.facebook.com/album.php?aid=2021593&id=1089695865&ref=share
• http://www.facebook.com/album.php?aid=116165&id=736976146&ref=share
• http://www.facebook.com/album.php?aid=2017021&id=1549014543&ref=share
• http://www.facebook.com/album.php?aid=72643&id=507637865&ref=share
• http://www.facebook.com/album.php?aid=22541&id=1020946181&ref=share
• http://www.facebook.com/album.php?aid=23387&id=1198467493&ref=share

Given yesterday's news that Honda can now connect thoughts to robotic actuators, we have been given permission to talk about the Solar PHP implementation of that interface: Solar_Mind_Read.

<?php
class Solar_Mind_Read extends Solar_Base {

    protected $_Solar_Mind_Read = array(
        'mind' => null,
    );

    protected $_mind;

    public function __construct($config = null)
    {
        parent::__construct($config);

        $this->_mind = Solar::dependency(
            'Honda_Thought_Interface',
            $this->_config['mind']
        );
    }

    public function fetchIntent($search)
    {
        return $this->_mind->recall($search);
    }

    public function doWhatIMean($subject, $callback)
    {
        $intent = $this->fetchIntent($subject);
        return call_user_func($callback, $intent);
    }

    public function fetchPhpCode($task)
    {
        throw $this->_exception('ERR_NOT_IMPLEMENTED', array(
            'task' => $task,
        ));
    }
}
?>

As you can see, we leverage Solar's base class and inherited configuration, along with its existing dependency injection functionality, to receive an existing Honda "thought" object at construction time. We can then see what the user's intent is given a particular subject using the fetchIntent() method.

Even better, we can pass a callback to the doWhatIMean() method. This means that the user will always get what he wants, not merely what he asks for.

Finally, as a developer tool, the fetchPhpCode() method will take a task description and generate PHP code for it. We are waiting on a related patch to the PHP RunKit extension for this to be fully implemented. In the mean time, the automatic exception system finds the right exception class and throws it, with localized translation, and information about the task.

Once Solar_Mind_Read is complete, we believe we will be able to move on to Solar_Mind_Write. Together, these tools should help the developer with convincing his clients that what they really need is something that's easier to implement, and then with actually implementing it.

Thanks for your attention; we hope this April Fool's Day article piques your interest in the power of the Solar Framework for PHP 5. Many thanks to Clay Loveless for the subject idea. :-)

Those of us who are developing Solar (or using it on our day jobs) are usually too busy adding value for our users to blog about the project on a regular basis. However, in the breaks available, we occasionally see these rays of light:

• Solar CLI: Make-Model
• The Solar configuration file
• Getting started with Solar

Thanks for taking the time, guys!

My regular readers (and perhaps the irregular ones as well ;-) know that I have been obsessed with baseline-responsiveness benchmarking of frameworks for years now.  The idea has always been that, in order to know how far you can optimize your framework-based applications, you need to know the limits imposed by the framework itself.  Only then can you have an idea of where to spend your limited resources on improvement.  For example, if you need 200 dynamic requests/second, but the framework itself (with no application code in use) is capable only of 100, then you know that no amount of application or database optimization will help you -- it's time to start scaling, either horizontally or vertically.

To perform these benchmarks, I have only employed the ab tool provided by the Apache web server.  It was easy to use, and relatively easy to parse the output to automate reporting.  However, it turns out that ab over-reports responsiveness of Apache when serving static HTML files, and when serving minimal PHP scripts such as <?php echo "hello world"; ?>.  I discovered this just recently when attempting to find out why PHP appeared to be faster than HTML, and then only with the assistance of Paul Reinheimer, whom I now owe a bottle of vodka for his trouble.  ;-)

It turns out that the siege tool from JoeDog Software is more accurate in reporting static HTML and PHP responsiveness.  This is confirmed through Paul Reinheimer as well, who reported the expected responsiveness on other systems.

The over-reporting from ab means that all my previous reporting on benchmarks is skewed too low when comparing framework responsiveness to PHP's maximum responsiveness.  As such, I have re-run all the previously published benchmarks using siege instead of ab.  Previous runs with ab are here ...

• http://paul-m-jones.com/blog/?p=236
• http://paul-m-jones.com/blog/?p=238
• http://paul-m-jones.com/blog/?p=315

... and below are the updated siege versions.  As with previous attempts, these benchmarks are performed on an Amazon EC2 "small" instance.  There is one difference to note: previous runs used Xcache for bytecode caching, but these use APC; I don't suspect this change in caching engines has a significant effect, but I have not tested that assertion.

Note the baseline-html and baseline-php numbers.  Using ab previously, these were reported as 2100-2400 requests/second and 1100-1400 requests/second, respectively.  The siege tool reports a much lower number for both, but the dropoff between static HTML and dynamic PHP is much smaller; with ab it looked like about 40-50%, but now with siege it looks like only about 15-18%.  This behavior is much more like what we would expect from a memory-based PHP script.

Note also the separate framework requests/second; they are very similar between ab and siege.  This means that the framework responsiveness numbers are almost unchanged.

Because the nearly-identical framework numbers are compared to a much smaller baseline PHP number, the frameworks now appear to be doing much better in relation to PHP's maximum responsiveness.  For example, Solar-1.0.0alpha1 with ab appeared to run at about 11% of PHP's max, but with siege it looks close to 17%.  All of the frameworks tested see this kind of comparative gain in their reporting.

However, when compared to each other, the framework rankings are the same as before:  Solar has the highest baseline responsiveness, followed by Cake and Zend (their respective releases are very close to each other in responsiveness), and Symfony trails with the lowest baseline responsiveness.

In summary, using ab skewed the "percentage of PHP" comparisons because it over-reported PHP's maximum responsiveness, but the framework requests/second numbers and the framework comparative rankings are unchanged from previous reporting.  The Google project for the benchmarking system has been updated to use siege, so all future reporting will reflect its results, not those of ab.

With the help of the great guys at Slicehost.com, I am attempting to run my benchmark series on a virtual private server, to compare with EC2. However, I'm seeing a very strange result for the baselines: a PHP page delivers more requests-per-second than a static HTML page.

The OS is a stock Ubuntu 8.10 installation; you can see the setup steps here.

The virtual private server has 2 gigs of RAM, and is on a box by itself, so there is no other external activity to skew the results.

I ran ab -c 10 -t 60 http://localhost/ on each of two files: index.html, which has only the static text "hello world"; and index.php, which has only the code <?php echo 'hello world'; ?>.

Here are the results without APC, averaged over 5 one-minute runs:

index.html : 7067.57 req/sec
index.php  : 7484.57 req/sec # faster???

Here are the results with APC, averaged over 5 one-minute runs:

index.html : 7013.50 req/sec
index.php  : 8041.06 req/sec # faster???

I haven't seen this behavior on EC2. I'm not complaining, but it does seem unintuitive; invoking the PHP interpreter should be more expensive than just delivering a static HTML file. Does anyone have ideas as to why this might be happening?

UPDATE: With the help of Paul Reinheimer, we appear to have found the culprit: the ab tool itself seems to be at fault. Running similar tests by hand with siege returns much more reasonable and expected numbers (~4000 req/sec for HTML, ~3200 for PHP). I'm going to re-work the test scripts to use siege later and report back. Thanks to everyone who provided suggestions, and special thanks to Paul Reinheimer for working through it with me today.

Congressmen, Senators, the President, and all the high advisors feel that "we need to do something!" about the current economic crisis. Leave aside that government action is at least 50% the reason we got into this mess (I'd rate it closer to 80%). These guys are succumbing to a major critical-thinking error:

1. We must do something!

2. This (the so-called "stimulus" package) is something.

3. Therefore, we must do this.

Merely that it's something to do doesn't mean it's a good idea.

I'd rather seem them subscribe to this: "Don't just do something -- stand there!" Government doing *nothing* is almost always much better than government doing *anything*.

I just discovered nosmarty.net in my Solar referrer logs. I have little love for Smarty, so it's nice to see this:

First released in January 2001, Smarty has become a stagnant, bug-ridden mess--and also the most popular PHP templating engine in use today. But it shouldn't be. No Smarty was created to warn developers about its use and encourage the use of superior alternatives.

Hey guys, you might want to add Savant to your list of PHP5 alternatives. Aside from that, great site!

UPDATE: To those who think my tone is inappropriate -- "I'm not disrespectful, I'm just ahead of the curve." </joker> ;-)

UPDATE (Thu 05 Jan): Please note that I am not affiliated with nosmarty.net in any way. I just saw it in my referrer logs and linked to it in this post. Thank, Ivo Jansch, for pointing out the need for clarity here.

UPDATE (Thu 05 Jan 10:56): A commenter below opines "If Smarty is used in the right manner, I don't see why it can't have it's place within the arsenal of tools for developers to use." I respond that there *is* no right manner in which to use Smarty; it's solving the wrong problem. I expound on that here:

You may have heard that you need to keep your PHP and HTML separated, but that’s not quite the case. Instead, what you need is to keep your "business logic" separate from your "presentation logic", and that’s a different thing entirely.

Thus, all that’s required is a way to keep your views and controllers separated, and perhaps provide helpers for common view tasks. Then you can use plain PHP in your view scripts (templates), without needing a whole new language.

In a long, long overdue move, I have updated the old "Getting Started" docs for Solar.

1. First Run (how to download and install a Solar system)
2. First Vendor (creating your own workspace in the system)
3. First Basic App (short CLI command to create app class files)
4. First Model (short CLI command to create model class files)
5. First Model App (short CLI command build a BREAD app based on a model)

My apologies to everyone who hit the brick wall of the bad old docs; their continued existence was nobody's fault but mine. Special thanks go out to Anthony Gentile at OmniTI, whose experience with the previous documentation embarrassed me into writing these new, much easier getting-started guides.

My PHP Advent article is up; therein I try to describe the parallels between public frameworks and business franchises. However, the PHP Advent site doesn't support comments; if you would like to comment, please do so on this blog post instead. Thanks!

This post is in response to http://terrychay.com/blog/article/challenges-and-choices.shtml, specifically this part:

When people put "design patterns" on their resume, I like to ask them a particular question -- especially when their background is J2EE or they say they know design patterns. The question I like to ask is define design patterns -- what does that term mean? I’d say about 90% of the people who put that on their resume bomb that question. It’s actually not an easy question. As soon as they answer it -- they give me some sort of pseudo-book definition -- I tear into them. I’ll give you an example:

The typical thing that they’ll say is, "Oh! A design pattern is this code thing that solves...umm...a problem."

And I’ll go, "Well, shit." laughter "Quicksort, right? That must be a fucking design pattern then." laughter

And then they’ll say, "Well no. Quicksort isn’t a design pattern."

Then I’m like, "Well, explain to me how it isn’t a design pattern. Your definition is that is solves a problem -- which I agree, design patterns do solve a problem -- but obviously that’s not a sufficient definition for design patterns."

You get where I’m coming from? And the reason isn’t...

And then they’ll say something like, "Well, you know. It doesn’t have like... It’s not an algorithm!"

"Umm...Yeah. So then design problems are something that solves a problem but isn’t an algorithm. So, code versioning! The practice of code versioning solves a problem and it’s not an algorithm clearly! (In fact this is what’s called a "best practice.") So how is a best practice not a design pattern?"

See no matter what they do they fall in a fucking trap. laughter

So I’ll give you my definition of design patterns. Well my honest-to-goodness definition of design patterns is to quote a famous Supreme Court justice when he was talking about it: He said that he’ll know it when he sees it.

Actually, he was talking about porn. laughter But there is pretty much no difference between design patterns and porn so we are all okay with that.

For Terry to say "design patterns are like porn, you know it when you see it" is funny and entertaining, but careless and unhelpful.

When a web developer talks about design patterns, it seems likely he means patterns of the type described by Martin Fowler in "Patterns of Enterprise Application Architecture". Regarding the definition of patterns, Fowler has this to say on page 9:

There's no generally accepted definition of a pattern, but perhaps the best place to start is Christopher Alexander ... "Each pattern describes a problem which occurs over and over again in out environment, and then describes the core of the solution to that problem, in such a way that you can use this soution a miillion times over, without ever doing it the same way twice."

Fowler then goes on for several paragraphs refining and explaining the concept. So while nobody has a rigourous definition of "design patterns", there does appear to be a rough outline of how to discover them, and then to agree on instances of patterns by naming and describing them. (Whereas the definition of porn cannot ever be agreed on, becuase it is in the eye of the beholder. I'd prefer not to take the analogy much further. ;-)

Patterns as Domain-Specific Vocabulary

Fowler (page 11) says "... the value of the pattern is not that it gives you a new idea; the value lies in helping you communicate your idea." That is, patterns are a common vocabulary to aid communication. Application design patterns are a vocabulary to aid communication about application design.

There are many kinds of patterns in the software world. To use Terry's examples, quicksort could easily be called a pattern of some kind, perhaps a sorting pattern. Code versioning could also be called a pattern of some kind, perhaps an organizing pattern. Best practices might be patterns of management. But they're not application design patterns.

Intellectual Bullying

As the interviewer, Terry does not appear to be seeking to tease out what the applicant thinks he means when he says "design patterns". Terry uses the term "design patterns" in a generic way, instead of in the way the applicant most likely intends -- "application design patterns". It sounds like Terry is attempting to trap the interviewee by subtly and purposely misleading him.

I have to wonder if that kind of questioning technique is appropriate behavior for someone in a position of power (and the interviewer does have a measure of power over the applicant). It sounds like an intentionally negative experience, one that is unnecessarily humiliating.

In fact, it sounds like bullying; intellectual bullying, to be sure, but bullying nonetheless. It reminds me of passages from the chapter on "Homo Logicus" in Alan Cooper's "The Inmates Are Running The Asylum". Cooper (101-104) compares and contrasts the physical/athletic jock and the mental/intellectual jock, both of whom exhibit immature bullying behavior.

The athlete bully, with great physical prowess, begins with the idea that "If I can beat you in a physical contest, then I am your master and I am better than you," but eventually is conditioned to accept that physical domination is not socially acceptable. He grows up when he realizes he can't get along with other adults by bullying them.

The intellectual bully, with great mental prowess, begins with the idea that "If I can beat you in a mental contest, then I am your master and I am better than you." However, the intellectual bully rarely learns that mental domination is similarly unacceptable in civil, adult discourse. "There is no maturation process to temper their exercise of that power." (Cooper, 104)

Closing Thought

When in a competition, physical or mental, try to win! But civil discourse is not competitive; you don't "win" a conversation. Mature adults attempt to work with each other to clarify meaning; they are both truthful and helpful when speaking to each other. They try to "find out what is right." Bullies and the immature, on the other hand, want to "be right" period, even if (maybe even because) that means knocking the other person around. Beware the mental bully in yourself, and point it out when you see it in others.