Wikipedia defines Aspect-Oriented Programming (AOP) as:

a programming paradigm which isolates secondary or supporting functions from the main program's business logic. It aims to increase modularity by allowing the separation of cross-cutting concerns, forming a basis for aspect-oriented software development.

That's pretty dense, but basically AOP tries to solve the problem of fragmented code.  Object-Oriented Programming did the same thing by adding classes and objects. AOP attempts to solve a different problems (cross-cutting concerns) with different constructs, namely Aspects.   Despite the fact that there has been some traction in other languages such as Java, C++ and C#, a PHP variant never caught on.

AOPHP was apparently started in early 2005 as a research project by John Stamey and Bryan Saunders but for unknown reasons it did not get popular and was loosely maintained for a number of years.  Since about 2007, the topic hasn't really been talked about much —  perhaps among other reasons, because PHP doesn't seem to attract the scholarly computer-science types.

So what the heck is a Cross-Cutting Concern?

To explain what it IS, it helps to explain, first, what it's NOT. The classic example is that if you consider an XML parser in procedural terms you would probably create dozens of functions and each one would take a reference to some data structure.  There isn't any clear boundary or encapsulation between the XML parser code and production code.

If we take that same example and apply Object-Oriented Programming methodologies, you would have an XmlParser class with functions and references attached to it.   With OOP you get clear boundaries defined, and common code related to XML parsing stays in one localized place.

If I tried to explain AOP using the XML parser example, I would fail to do it justice.  AOP actually works very well alongside Object-Oriented programming.  But, a good example is a logging system.  No doubt you've written something like this.

function foo()
{
    customLog("starting foo");
    // ... do some work
    customLog("finished foo");
}

The problem is that we repeat too much code.  A cross-cutting concern is one where related code (in this case, logging statements) is found scattered across an application.  Log calls are a good example because they are typically found all over an app.  If we, later, wanted to exchange our logging class for a different one, it would require updating every call (affecting many systems).  This would be a small issue with most websites, but if we're talking about corporate infrastructure code... Well, I wouldn't want to do it.

How does AOPHP  solve these problems?

AOP, as a theory, provides some interesting functionality.  For example, consider how difficult it would be to implement the phrase "Wherever we get data from the database log the transaction and inputs." Programming that could take weeks.  Just imagine modifying all of that (functioning) code and inserting the proper log statements for each situation. Errors would ensue. If code can smell, this one smells like duplication of effort.

Many programming languages try to simulate natural language with their syntax, and this is where AOP shines (theoretically).  We could produce some pseudocode like the following:

before each database transaction
    log input parameters and a timestamp

With AOPHP the implementation would look something like the following — very similar to the pseudocode.

aspect DatabaseLogging {
    pointcut databaseAccess = execr(mysql_query($sql));
    before($sql): databaseAccess {
        customLog("Accessing Database: {$sql}");
    }
}

Remember, this applies to every database call — and you don't need to write an adapter class!

Okay, so it might not be a stellar example, but think about patching all those oddites of PHP that you already do.  Things like escaping variables, CSRF protection, session handling, and various types of form validation.  Personally I would love to have these features and not have to think about check every time I need them.

Does PHP even need it?

At this point, PHP probably doesn't need AOP.  There are enough Reflection API functions like __call and __get which allow a programmer to intercept function calls dynamically.  And the PHP developers seem to be having enough difficulty adapting to unicode... So this kind of stuff will probably remain for just language nerds like myself.  (And actually I'm not using, just writing about it.)  But certainly, much of the acclaim made about Ruby is due to it's metaprogramming — which is very AOP-esque.

Notable attempts at Aspect-Oriented PHP:

• AOPHP (last updated 2007)
• AspectPHP (2005)
• Transparent PHP AOP (2006)
• PHP-AOP (???)

(As far as I know, none of these are production ready.)

PHP supports a number of different scope models for error suppression, which can be combined to produce sophisticated (or atrocious) use of errors. They seem to fall into a few categories; Per-environment, per-file, and per-command.

Per-Environment — Globally configured via PHP.ini, this is imperative for a production environments that you want to hide messy errors from. For example, you wouldn't want to hand out a stack trace to potential hacker or burden a casual user with cryptic error messages. Error suppression at this level is usually smart and can be part of good security.

Per-File — PHP doesn't just enforce a single global rule, but also supports overriding the above environmental setting manually. Since PHP is stateless, this change only applies to the current page lifespan, or until it is manually turned off — which can be useful for certain scenarios like showing errors. Or vice versa, not showing errors, the choice is yours. Generally these statements are less than sublime, but all-in-all, they are easy enough to find and do only one thing.

Per-command — Finally, PHP supports per-command error suppression in the form of an 'at' symbol "@". This is the one I have always told myself NEVER TO USE! It's not that I'm paranoid, it's just impractical to go through ALL of your code and add/remove these symbols whenever you move to production. These are often used like this:

if (DEBUG)
    mysql_connect($host,$user,$password,$db) or die( mysql_error() );
else
    @mysql_connect($host,$user,$password,$db);

The danger with this code is that you're duplicating EVERYTHING just to hide an error. Furthermore, most modules support decent error handling, so... I don't like it.

So, I've never been able to find a good use for it... until, perhaps, now.

First, an aside; I've always had some beef with ternary expressions like the following:

<?php echo (isset($dbResult->name)) ? $dbResult-&gt;name : '' ?>

These are particularly odd because despite PHP's dynamic nature I still need to verify that EVERY variable exists before using it. In contrast, in javascript if you access a variable that doesn't exist, you get a return type of undefined. That's slick, if a bit confusing for newbies. Beyond that, I've written this literally thousands of times, and I'm getting tired of it. All for the purpose of avoiding the following error:

Notice: undefined property $name; ...

Every time I write this, I tell myself, Surely, there must be a better way.

I've considered disabling "Notices" on PHP.ini (or even per-file), but truthfully I actually enjoy these errors; they allow me to avoid deprecated features and other little fixes a good developer keep track of.

So '@' fits for use in suppressing this particular Notice, but it doesn't stop there. The @ symbol also suppresses every other type of error and warning where applied. It is therefore a dangerous tool. Much like Spiderman's powers, the @ must be used responsibly.

An example of this danger is @mysql_query(). This can hide a version mismatch warning, an SQL syntax error, or it could hide a fatal error trying to explain that MySQL is not installed. These are dramatically different problems and I don't trust my code enough to make an assumption about the errors I'm suppressing.

So using @ on a function seems dangerous, too much is happening that can be hidden. Using @ on a variable however, seems like it should only suppress the error of whether or not it actually exists, which is exactly what I want.

<?php echo @$dbResult->name; ?>

Seems elegant enough. No unnecessary code. Suppresses asinine notices, and apparently nothing else.

Now, I'm sure there are problems with this; aside from the fact that it's good practice to provide fallbacks. I expect to see many problems with this choice, but I'll let you just tell me that I'm wrong.

Thanks.

<?php
    // at the top of your template
    $headers=$this->getHeadData();
    $headers['scripts'] = array();
    $this->setHeadData($headers);
 
    // make sure to eliminate any of the following
    //JHTML::_('behavior.framework', true);
    //JHTML::_('behavior.mootools', true);
?>

In Joomla 1.6 this can remain the same if you adjust a tiny bit of Joomla internals. Specifically we need to modify the setHeadData() function in joomla16/libraries/joomla/document/html/html.php (around line 116).

// original version
$this->_scripts = (isset($data['scripts']) && !empty($data['scripts'])) ?
                  $data['scripts'] : $this->_scripts;
 
// updated version ( !empty() replaced with is_arrray() )
$this->_scripts = (isset($data['scripts']) && is_array($data['scripts'])) ?
                  $data['scripts'] : $this->_scripts;

What this does is allow Joomla to accept an empty value for $headers['scripts'] where it would previously reject it.

Let me know if you have any questions.

Happy coding!

NodeJS is gonna kill PHP

There are some merits to that statement.

• NodeJS is moving along quickly, with new modules getting added daily.
• Many of the web methodologies transition easily to Node
• Javascript is a strong language with a strong history of development.
• Asynchronous from the top to the bottom. AWESOME!
• YOU GET TO USE ALL THE JAVASCRIPT YOU'VE EVER WRITTEN. (emphasis added)
• Atwood's Law (Anything that can be written in Javascript, will be written in Javascript)
• PHP is unable to advance.

At the same time, I (almost) never consider an argument valid unless there are counter-examples which help to paint a complete picture. If all I see is perfect, I must not be living in reality. As a side note, this is why if you ever listen to two programmers argue, you'll inevitably find that they will swap roles and start arguing against their original idea. It's really pretty funny if you watch for it. Regardless, I think the same rule is at play. We all want to explore the problem domain.

So what are the downsides to NodeJS (and yes, they do exist):

• Non-Classical inheritance structure — It's hard enough teaching someone inheritance, I won't even venture to try to explain prototypes.
• Heavy usage of anonymous functions — Another tricky thing to teach.
• Lack of a sponsor company to direct development in advantageous directions
• Will probably never catch on in enterprise environments (due to last point)

The nice thing about these problems that they are all pretty easy to overcome. John Resig has written a handy class that emulates classical inheritance. And anonymous functions can be rewritten to work as named functions, so that's out. What's left is the difficult problem of having a stable platform that can be used by enterprise environments. In the end this is a social problem and it will just take successful companies to take the leap and others to follow.

Programming is a complicated job. Many people see it as a craft, and as craftsmen, programmers must spend countless hours honing their skills and improving their expertise to reach a level to compete at the level they desire to be at. For example:

• If I want to build web pages at an amateur level, I simply need to know HTML, some CSS, and maybe some jQuery. For every question that might come up, there is usually a hundred answers on Google.
• If I want to do the same thing at an expert level, I must know about usability, cross-browser compatibility, form validation, race-condition debugging, and a host of other things—most importantly, however, I should be able to find answers to problems that are not Google-able.

So if you’re shooting for your “A” game, you need to practice, right?.

But there’s a problem too. If anyone has an issue with repetitiveness, it must be programmers. We have actually been taught that the sole purpose for our job is to reduce repetitiveness. So where does that leave practice and doing things multiple times?

A lot of the programmers I know, who are really good, attribute their success to the fact that they spend hours at home every night building cool stuff or researching—I think the same could be said of artists and writers as well.

This is great, but let’s consider the following quote by Geoffrey Colvin (emphasis added).

For example: Simply hitting a bucket of balls is not deliberate practice, which is why most golfers don’t get better. Hitting an eight-iron 300 times with a goal of leaving the ball within 20 feet of the pin 80 percent of the time, continually observing results and making appropriate adjustments, and doing that for hours every day - that’s deliberate practice.

So let’s make an assumption—perhaps an incorrect one, but bear with me.

Most programmers are not deliberate about what they practice or how they grow. They do not set clear goals, they do not continually measure results, however they are spending the necessary time.

Why are we just like the golfers?—”simply hitting a bucket of balls.”

• Programmers don't get out enough. In particular with other that practice the same craft.
• It’s still a fairly new craft. Many outsiders (your family, bosses, etc.) still think that we just “know computers” and they come to us for everything relating to computers. To them cleaning viruses and building web-pages are the same thing. So, to cater to their needs, we are often forced to become jacks-of-all-trades.
• The web it too noisy. How do we judge what is important given the thousands of new articles written every day? The best thing we can do is probably unplug from the web and go for a walk.

Here are some possible solutions. Certainly not an exhaustive list, but something to get started with.

• Local user groups. These allow for interaction, they expose people to higher-level talks and foster an environment for learning beyond amateur.
• Set clear learning goals like “I want to understand exactly how Object Oriented CSS works” or “Find out mathematically if database XYZ can scale for a certain use-case”.
• Continually measure results. Progress is important and it might seem daunting that understanding CSS in 13 browsers is a huge task, but every time you check one off, you’ll feel good about it.

And although I don’t follow my own advice fully yet, I’ve determined to move forward with some of my own goals:

• Develop a system for building web UI applications that actually simplifies things.
• Start a user group to empower other developers and designers.
• Build tools that empower people.

Beware, this is beta quality software. Use at your own risk.

As we understand already, Joomla doesn't have relevant searching. It's a shame since everything else is designed well, but this is a problem regarding implementation. This article explains how to setup sphinx to index your Joomla articles and use my plugin to search using Joomla.

In my own experiments I built a plugin that accomplished this. It works splendidly, and I had all intention of releasing the code to the public, but got distracted. This process is currently unrefined, but it works. I'm a fan of revision anyway, so if you see a way to improve this article, hit me up (email).

So why doesn't Joomla have relevant searching already? — Unfortunately it doesn't seem like they had much choice about it. Joomla relies on MySQL. MySQL is just now beginning to get some Full-Text searching mechanisms implemented and those that do exist are spotty. For example, it is only available in recent versions of the MyISAM database engine and not at all for InnoDB. Plus, I've heard some complaints about it not even being terribly good at it's own job.

A system like Sphinx can go beyond what MySQL supports anyway. It can use word stems and substitutions, so I could specify CPP to be used interchangeably with C++ in any search query and it doesn't get confused about plural or singular versions of words. It also supports weights, so I can tell Sphinx to prefer matches found in titles and move them higher in the search results.

Install & Configure Sphinx

There are a number of good articles on the web about this. I may revisit how to install Sphinx in detail, but for now defer to the follow links:

• Sphinx Homepage — Obviously the first place to start looking is the Sphinx homepage. Good documentation on Sphinx operation and internals.
• Build a custom search engine with PHP — IBM has a great article on using Sphinx in-the-field. This article describes setup of Sphinx as well as testing and integration with PHP.

Here is my configuration I've been using for my Joomla Setup. This is basically the same as any configuration setup on IBM's website, but adapted to Joomla. There are a few things you'll need to edit though:

• exampleuser — This should be the username you connect with to search your database
• examplepass — This should be the password for the username just described
• exampledb — This is the database sphinx will be searching on.
• Check your paths. I'm making some assumptions here. Your sphinx data should be outside of your web-root and readable/writable by whatever process searchd is running as.

/var/www/website/sphinx/config.conf:

source mywebsite_articles
{
    type            = mysql
    sql_host        = localhost
    sql_user        = exampleuser
    sql_pass        = examplepassword
    sql_db          = exampledb
    sql_sock        = /var/run/mysqld/mysqld.sock
    sql_port        = 3306

    # indexer query
    # document_id MUST be the very first field
    # document_id MUST be positive (non-zero, non-negative)
    # document_id MUST fit into 32 bits
    # document_id MUST be unique

    sql_query = \
        SELECT `id`, `title`, `alias`, `introtext`, `fulltext`, `created`, `modified`, `hits` \
        FROM jos_content ;

    # document info query
    # ONLY used by search utility to display document information
    # MUST be able to fetch document info by its id, therefore
    # MUST contain '$id' macro
    #

    sql_query_info = \
        SELECT * \
        FROM jos_content  \
        WHERE id=$id
}
index mywebsite_articles
{
    source                  = mywebsite_articles
    path                    = /var/www/website/data
    morphology              = none

    min_word_len            = 3
    min_prefix_len          = 0
    min_infix_len           = 3
}

searchd
{
    port          = 3312
    log           = /var/www/website/sphinx/search.log
    query_log     = /var/www/website/sphinx/query.log
    pid_file      = /var/www/website/sphinx/searchd.pid
}

Testing Sphinx

How do we know if Sphinx is setup correctly? We test it!

First we need to generate the index. So fire up your terminal and run the following (assuming your sphinx install lives in /usr/local/sphinx):

/usr/local/sphinx/bin/indexer \
--config /var/www/website/sphinx/config.conf \
--all --rotate

Second we need to start the search daemon. This will process search requests.

/usr/local/sphinx/bin/searchd \
--config /var/www/website/sphinx/config.conf

If you get any errors, I'd recommend going back and reviewing the configuration and re-running the indexer, then start searchd again.

If we don't have any errors, we can run a test outside of Joomla to see if everything is working correctly. For example:

/usr/local/sphinx/bin/search \
--config /var/www/website/sphinx/config.conf \
"Hello world"

Install & Configure Joomla Plugin

You can download the plugin here (Download) or at the bottom of this article.

Enable the plugin. Be sure to turn off other search modules while you're at it. It is much easier to determine if your search results are isolated to one plugin.

If you are hosting Sphinx on the same server as your web service, you'll probably want to keep these similar to what I have. Otherwise, be sure to fill-in the appropriate fields here and configure any firewalls that may be between the web server and the Sphinx server.

You will also want to be careful to use the same name of your index defined in your config file. In my example I'm using mywebsite_articles. This is what I fill-in for Resource Name.

Test Sphinx Plugin

The only thing left to do now is to actually test the thing. Go to your website and do a search!

Completing the solution

There are a few things still missing from this setup that I want you to be aware of.

First, if you don't update your index periodically, you will only see the content that you indexed the first time. One solution is to setup a scheduled task (or cron) to re-index your content. Notice as well I put --rotate at the end of my indexing operation. Once Sphinx has updated the index, it will begin to use the new index to search with. You don't need to restart your searchd process, just update the index.

Second, you should be aware that if your server restarts you'll need searchd to start automatically. An init script would work great, even something as simple as this:

/etc/init.d/searchd

#! /bin/sh
NAME=sphinx
DAEMON=/usr/local/sphinx/bin/searchd
CONFIG=/var/www/website/sphinx/config.conf
[ -x "$DAEMON" ] || exit 0
case "$1" in
  start)
    echo "Stopping any running daemons..."
    $DAEMON --config $CONFIG --stop
    echo "Starting sphinx search daemon..."
    $DAEMON --config $CONFIG
    ;;
  stop)
    echo "Stopping sphinx search daemon..."
    $DAEMON --config $CONFIG --stop
    ;;
  *)
    echo "Usage: $NAME {start|stop}"
    exit 3
    ;;
esac
:

plgSphinxContent-v2.zip (Sphinx Search Plugin)

Downloads: 162 File Size: 0.0 KB

If you've used Joomla before, you may be aware that there are built-in caching features which you can activate to reduce the number of expensive database calls needed to render a page. This feature is also available to your own custom code, whether that be in the form of components, modules, or plugins.

The actual mileage for this feature may vary due to the speed of the server and what Joomla decides to cache. Personally I think Joomla's use of caching, specifically how they use it for articles, leaves something to be desired. The downsides include content that doesn't get flushed out once it has changed or content that has too short of a lifetime to prove useful. Because of this, I don't think lot of developers realize that you can use it to cache your own components, plugins, and modules reliably and without affecting the user experience in a negative way, all the while in a modest environment (i.e. a server environment that doesn't have special software like memcached installed.)

You might consider implementing a little caching if:

• Your code is heavy and slow (Don't take it personally, mine is too sometimes)
• Your code is high-latency requiring network resources that may or may not actually be available
• You have a crazy number of visitors and your database is becoming a significant bottleneck

In my own recent project I was able to improve my access times of some SOAP requests by 500% (~1 second/request down to ~200ms/request).

Let's get our bearings

Here's a basic example of some code which initializes a JCache object and get's some data using it. You'll notice that there are two functions, one which just generically gets some data getData and another function getDataCached which instantiates the cache and calls getData. We need to do this so that our cache is aware of what the inputs and outputs are, that way it can do a lookup on the cache and return data without ever touching getData.

com_cachetest/cachetest.php:

class CacheTest {
    function getData($url) {
        // ... Get some data

        // in this case, I'm just returning some dummy data instead of
        // downloading a web page which if we plan for the worst case scenario,
        // might not be available.

        $data = $url;

        // send data back
        return $data;
    }
    function getDataCached($url) {

        $group = "cachetest";
        $function = array("CacheTest", "getData");

        // get a cache object and name it something useful
        $cache =& JFactory::getCache( $group );
        $cache->setCaching( 1 ); // enable caching (1 = enabled, 0 = disabled)

        // call our function "getData" through the cache
        $result = $cache->call( $function , $url);

        return $result;
    }
}

$data = CacheTest::getDataCached( "http://example.com" );
var_dump($data); // to see what we actually get

Fault Tolerant Caching

One issue in the above example is that if getData returns some bogus data, it's going to be stuck in the cache and you won't realize it until it's too late. This isn't a likely scenario for a quick database call but if you have a network request that is waiting and waiting and eventually reaches timeout, the cached data will possibly be empty. This can be problematic but it's also easily avoided. In the following example we do a quick check to see if the data is invalid, remove the old data and get a fresh copy.

com_cachetest/cachetest.php:

class CacheTest {
    function getData($url) {
        // ... Get some data

        // in this case, I'm just returning some dummy data instead of
        // downloading a web page which if we plan for the worst case scenario,
        // might not be available.

        $data = $url;

        // send data back
        return $data;
    }

    function getDataCached($url) {

        $group = "cachetest";
        $function = array("CacheTest", "getData");

        // get a cache object and name it something useful
        $cache =& JFactory::getCache( $group );
        $cache->setCaching( 1 ); // enable caching (1 = enabled, 0 = disabled)

        // call our function "getData" through the cache
        $result = $cache->call( $function, $url);

        // Check if we get sane data. Depending on your data this
        // could be more than just an empty check
        if ( empty( $result ) ) {

            // find the id to remove data for
            $id = $cache->_makeId( $function, $url );

            // invalidate this entry in the cache
            $cache->remove( $id, $group );

            // call our function again knowing the cache has been fixed
            $result = $cache->call( $function, $url );
        }
        return $result;
    }
}
$data = CacheTest::getDataCached( "http://example.com" );
var_dump($data); // to see what we actually get

In Closing

Joomla's caching API is simple and, by default, just writes these cache files to disk. Although not the fastest approach the default options are really handy for a less-than-stellar server setup. These caching options are available to even shared hosts. At the same time, I should mention that Joomla has done a fantastic job of integrating support for more advanced caching systems like memcache and xdebug so that the above code can be run even faster without any modifications.

joomla-caching-example.git (Programmatic Caching in Joomla 1.5 with Fault Tolerance)

Downloads: 159 File Size: 0.0 KB

The Problem:

Ajax requests don't seem to be working in IE, but there aren't any error messages and nothing fails like you'd expect it to—the only real issue is that the content is not updating. Everything works as expected in Firefox, Safari, Chrome, etc.

The Solution:

This problem is because IE has aggressive caching in place for Ajax requests. This is bad. Why is this bad? Because we commonly use Ajax to refresh content and make updates to our data. Unless we make some updates to our code, we will see stale information and mislead our visitors.

We can fix this pretty easily though. Some people claim that by switching our GET requests to POST that we'll solve the problem at hand. I didn't have any luck with that. Instead if you assign a header explicitly telling the browser to invalidate the page after viewing it, you can prevent IE from caching the page.

In PHP you do it like this:

http://kilianvalkhof.com/2009/javascript/cufon-vs-typefacejs-which-one-is-better/

Since reading about this article I've want to play with Cufón to see how it stacks up. Here's a little example for you.

Using Cufón for Text Replacement, an Example

and the source (SF_Foxboro_Script_400.font.js generated at http://cufon.shoqolate.com/generate/ ):

<script src="http://cufon.shoqolate.com/js/cufon-yui.js"
    type="text/javascript"></script>
<script src="/code/cufon/SF_Foxboro_Script_400.font.js"
    type="text/javascript"></script>

<script type="text/javascript"><!--
    Cufon.replace('h1');
// --></script>

Not the greatest example, but it works.

In conclusion, I like this approach in theory. I'm still not sure if it is a "too fast to notice", so I think I'll stick to the ugly web-fonts—but I love the fact that people are stepping outside of the box and being unconventional. Props for that!