Last week I wrote a post about a PHP parser / evaluator I wrote in Haskell. I explained some of the parts on how the parser itself was designed to process PHP code into an abstract source tree. Continuing from where we left off in the previous part, in this post I'll discuss the actual evaluation part.

He starts by introducing the structure of the evaluator script, how it's broken up into functionality based on the type of object/data type being handled. He uses a "custom monad transformer stack" to handle the environment for the evaluation as is progresses. He talks about handling statements and expressions, declaring custom functions and the actual execution of the function call. There's also a mention of handling conditionals/looping as well as dealing with PHP's type juggling.

if you're interested in seeing the final result (and maybe trying it out for yourself) you can find the full source on Github.

As long as you make sure you always use strict checking (=== and !==) where you can, and fall back to the loose checks when you must. As a PHP developer, I think it's very important to understand and memorize exactly how these work, whether you're writing new code, or maintaining existing code.

He points out a specific example of some code that seems counter-intuitive when you compare how it reads and how it actually works (strings converted to floats and evaluated)

The moral is: always do strict checks when you are able to.

Benfords Law is not an exciting new John Nettles based detective show, but an interesting observation about the distribution of the first digit in sets of numbers originating from various processes. It says, roughly, that in a big collection of data you should expect to see a number starting with 1 about 30% of the time, but starting with 9 only about 5% of the time.

He pulls data from the data.uk.gov site to illustrate and includes a simple PHP script to run through the data looking scoring it with a "Benford" rating. He plots these on a graph along side the data to show the (almost exact) match between the data and the Benford numbers. You can find more details on the law on Wikipedia.

As you all probably know, Zend has salespeople. Those sales people have sales engineers who show how to use our products. However, I personally hate being on the phone for a canned presentation when all I really want to do is tinker. So, in an effort to produce something of benefit today I decided to start a series of blog posts on how to evaluate Zend Server if you are a tinkerer, like me.

He gives a list of some of the features that the product comes with, but will only really focus on three of them in his series - application monitoring, code tracing and the Zend Server job queue (because he thinks they're the best of the crop). This post is just an introduction to the product and an overview of what it offers - expect more detail to come in future posts.

I thought I'd share a PHP library implementing this idea by Evans and Fowler. Written for PHP5, it's a library for defining custom specifications using composition and inheritance.

He gives the example of "Person" objects with name and age properties. A search might involve looking directly at the properties to location one that's, say, younger than 35 and has a last name of Johnson. His specification class replaces this and makes it more reusable by applying things like GreaterOrEqualSpecifications and EqualSpecifications to standardize the evaluation. Then its just a quick call to the isSatisfiedBy method to check for correctness.

This allows you to check for the existence of a variable (or check that the variable has a valid value) and assign a value accordingly. This is very useful when you are dealing with $_GET, $_POST, $_SESSION etc. variables, because you don't know whether the incoming variable will exist, and if it doesn't you might want to assign a default value.

An example is included and explained - evaluating an index in the _GET superglobal to see if it exists. It returns either the value itself or a false.

I got curious about which is actually more efficient at matching a random integer with a set of conditionals. So, I setup a script to create a set of large scripts to test the speed of these different constructs. Using the 'time' command, I measured the speed at which the condition could match a random number.

His results found that the switch statement is generally more than 2 times as fast at matching a simple integer. His tests, however, didn't go through much more than this simple test. It'd be interesting to see what it would do with something more complex (like longer strings or handling the result of an evaluation inside the definition of the switch().

Behavior-Driven Development (BDD) is an evolution of Test-Driven Development (TDD) which pushes the focus away from the concept of testing to one of specifying behaviours in a form more easily understood.

In asking about any of the tools that might happen to be out there, he also gives an example (from a Ruby perspective) on how the behaviour-driven method is put into practice. The code describes the behaviour by what "it should" do and evaluates based on that.

So far I've always thought false would evaluate to 0 when used in a computational context. Turns out that this isn't always the case.

His code example tries to check is a false value is greater than or equal to a negative number. The result, however (despite the thinking that false is a zero value) turns out to be false.

I randomly stumbled upon this when arguing with Mariano today if setting Model::recursive to 'false' has the same effect as setting it to '-1'. Turns out that cake uses a statement like this: if ($recursive > -1) in the core which in turn makes -1 and false do exactly the same thing.

Proper development on any kind of project requires you to stop and evaluate the project before development begins (hopefully long before, but that's not always the case).

Having said that, let's figure out what we want the guestbook to do. What's the guestbook for? In this case, it's simply to let users view other visitor's comments and to add their own. The guestbook is not a stand alone application - well it is, but it exists in the context of the web site

There's a few considerations mentioned before the code comes along (broken up into the business and technical sections). With the plan in place, Dhani shows the database layout chosen, the reasoning behind it, and the actual SQL you'll need to create it.