Paul M. Jones

I think that there is probably a special place in hell reserved for politicians who betray our nation's most helpless children for the benefit of a sullen and recalcitrant teacher's union. There they spend all eternity explaining to their victims why they couldn't possibly have risked their precious babies' future in the public school system, yet felt perfectly free to fling other peoples' children into it by the thousands.

via Megan McArdle.

I am not a Constitutional Law scholar, but this looks pretty good to me, and very much within the spirit of the Tea Parties:

http://federalismamendment.com/

You can grab the amendment document here:

http://federalismamendment.com/The_Bill_of_Federalism.pdf

These look to be the kind of smaller-government Federal modifications, and ways to more-properly restrict the overreaching Federal government. A short run-down:

1. Limits the Federal use of the Inter-State Commerce Clause.
2. No unfunded Federal mandates, and no Federal spending on things the Federal government has no power to otherwise regulate.
3. Activity occurring entirely within a State may not be regulated by the Federal government.
4. States may rescind Federal law when 2/3ds of the States vote to do so. (Is this related to the drug war?)
5. No Federal taxes on estates or gifts (the "Death Tax"); repeals existing taxes and denies future implementations of same.
6. No Federal income tax; repeals the 16th Amendment, thus ending the income tax and denying future implementations of same. (Excise and sales taxes are explicitly allowed, paving a way for the Fair Tax.)
7. Term limits: 2 for Senators, 6 for Representatives.
8. Balanced budget veto. This looks like it gives the President a line-item veto power over any budget items that leave the Federal government with more debt than in the preceding budget.
9. More explicit protections for the liberties and privileges of the People, both enumerated and unenumerated.
10. This one's the kicker: "[No Judicial Alterations of the Constitution.] The words and phrases of this Constitution shall be interpreted according to their meaning at the time of their enactment, which meaning shall remain the same until changed pursuant to Article V." Gotta love that.

From PowerLine:

On April 21, the Special Inspector General for the Troubled Asset Relief Program Act of 2009--"SIGTARP"--submitted his quarterly report to Congress on his office's activities in relation to the TARP program. The report is a disquieting document that should be read by every American--certainly be every taxpayer.

The Inspector General's report documents the stunning and at least partly illegal expansion of TARP from the $700 billion originally allocated by Congress to what is now a $3 trillion complex of programs. This chart shows the various programs that are now included within SIGTARP's oversight, and how they have expanded from the initial $700 billion. Note that some of the programs are still incipient; $3 trillion is by no means a final number.

...

What conclusions can we draw? 1) The government's $3 trillion and counting TARP program represents the greatest opportunity for sharp operators to profit at taxpayer expense in history. 2) The Obama administration is either in favor of giving Wall Street sharks this opportunity or, at a minimum, doesn't much mind doing so. (If this seems odd, remember where Obama got the biggest chunk of campaign contributions in 2008.) 3) It may be that the TARP complex of programs is the beginning of a national-socialist type takeover of the financial services industry by the federal government. Thus, 4) we can only hope that this turns out not to be the case, and TARP is only the biggest--and perhaps, by the end of the day, the crookedest--waste of taxpayer money in history. Finally, 5) so far the only person or organization who appears to be looking out for the taxpayers is the Special Inspector General. We will be reading his future reports with great interest.

From http://taxprof.typepad.com/taxprof_blog/2009/04/david-walker-why-.html:

Unless we begin to get our fiscal house in order, there's simply no other way to handle our ever-mounting debt burdens except by doubling taxes over time. Otherwise, our growing commitments for Medicare and Social Security benefits will gradually squeeze out spending on other vital programs such as education, research and development, and infrastructure.

Another great line: "...additional accumulations of debt are, absent dramatic reductions in the size and role of government, basically deferred tax increases."

My buddy Benito has a nice writeup of his Manhattan Project, in which I have been a subject. The things we do for science. ;-)

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.